はじめに：求人票はスキル一覧だけでは足りなくなる
AI コーディングエージェントを使うようになると、仕事の渡し方に対する見方が変わります。
たとえば、AI にコードを書かせるときに、次のような依頼だけでは安定しません。
いい感じに修正してください。
人間であれば、過去の経緯、チームの空気、暗黙のルール、レビューで怒られそうなポイントをなんとなく読んで作業することがあります。
しかし AI コーディングエージェントに作業を渡す場合は、もう少し明示的な情報が必要になります。
- このプロジェクトは何を目的としているのか
- どのファイルを読めばよいのか
- どこを変更してよいのか
- どこは変更してはいけないのか
- どの規約に従うのか
- どのテストを実行するのか
- 何を満たせば完了なのか
- どこから先は人間に確認すべきなのか
ここで見えてくるのは、AI 特有の問題だけではありません。
本来、人間に仕事を渡すときにも、これらの情報は必要だったはずです。
ところが求人票では、今でも次のような表現がよく使われます。
WordPress プラグインを作れる方
デザイナーと連携できる方
自走できる方
顧客の課題を理解して提案できる方
AI を活用して業務改善できる方
これらの表現は、一見すると自然です。
しかし、AI コーディングエージェントを前提にして読むと、かなり曖昧です。
「自走できる」とは、どのステージで自走することなのか。
調査なのか、提案なのか、合意形成なのか、実装なのか、レビューなのか、運用改善なのか。
「顧客の課題を理解して提案できる」とは、どこまでを本人が判断し、どこから先を営業・ディレクター・経営者・顧客と合意するのか。
このあたりが曖昧なままだと、求人票は単なるスキル一覧になってしまいます。
この記事では、AI コーディングエージェント時代の求人票を、単なる採用広報ではなく、人間に仕事を渡すためのハーネスとして考えます。
結論から言うと、AI 時代の求人票は「人間向け AGENTS.md」になる、というのがこの記事の主張です。
AGENTS.md は仕事を渡す条件を書く文書である
AI コーディングエージェントを使うプロジェクトでは、AGENTS.md のような文書が重要になります。
AGENTS.md は、AI に対してプロジェクトの前提や作業ルールを伝えるための文書です。
たとえば、次のような情報を書きます。
# AGENTS.md
## プロジェクトの目的
## 技術スタック
## ディレクトリ構成
## 作業してよい範囲
## 変更してはいけない範囲
## コーディング規約
## テスト方法
## レビュー観点
## 作業完了条件
## 人間に確認すべきこと
これらは、単なるコーディング規約ではありません。
AI に対して、次のような仕事の受け取り方を伝えています。
- この目的に沿って作業してほしい
- この範囲なら変更してよい
- この範囲は勝手に変更しないでほしい
- この観点で品質を確認してほしい
- この条件を満たしたら完了とみなしてよい
- 判断に迷う場合は人間に確認してほしい
つまり AGENTS.md は、AI に対する作業指示書であると同時に、仕事を渡す条件を書く文書です。
これは、AI だけに必要な文書ではありません。
人間に仕事を渡す場合でも、本来は同じような情報が必要です。
新しく入ったエンジニアやデザイナーに対して、何を任せたいのか。どこまで判断してよいのか。どこから先は確認してほしいのか。何を成果物とみなすのか。
これらを言語化しないまま「自走してください」と言っても、期待値はズレやすくなります。
AI コーディングエージェントは、この曖昧さを可視化します。
人間同士なら空気や経験で埋めていた部分を、AI に渡すためには文書化せざるを得ないからです。
AGENTS.md は、コードを書くためだけの文書ではなく、仕事を渡す条件を書く文書である。
求人票も仕事を渡す条件を書く文書になる
求人票も、本来は候補者に対して仕事を渡すための文書です。
もちろん、求人票には採用広報としての役割があります。
会社の魅力を伝えること、働く環境を伝えること、応募してもらうことも重要です。
しかし、それだけでは不十分です。
求人票には、少なくとも次のような情報が必要です。
- この職種は何のためにあるのか
- どのステージから仕事に関わるのか
- 何を担当するのか
- 何を自分で判断してよいのか
- 何をチームに確認すべきなのか
- 誰と合意する必要があるのか
- 何を成果物として期待するのか
- 何を満たせば完了なのか
- AI ツールをどこまで使ってよいのか
- AI が生成した成果物を誰がレビューするのか
こう考えると、求人票は AGENTS.md とかなり似ています。
| AGENTS.md | 求人票 |
|---|---|
| プロジェクトの目的 | 事業・チーム・職種の目的 |
| 技術スタック | 使用技術・制作環境 |
| 作業してよい範囲 | 担当範囲 |
| 変更してはいけない範囲 | 権限外の範囲 |
| 人間に確認すべきこと | 上長・顧客・チームに確認すべきこと |
| レビュー観点 | 評価・レビュー観点 |
| 作業完了条件 | 成果物・期待役割 |
AI に仕事を渡すときには、作業範囲や完了条件を書く。
それなら、人間に仕事を渡す求人票にも、同じように作業範囲や完了条件を書くべきです。
求人票をスキル一覧としてだけ書くと、次のような表現になりがちです。
PHP 経験者
WordPress 経験者
Figma が使える方
顧客折衝経験のある方
自走できる方
しかし、これでは「どの仕事を、どの条件で渡すのか」が見えません。
AI 時代の求人票では、スキル名だけではなく、仕事の受け渡し条件を書く必要があります。
求人票は、候補者に対する「この仕事をどう受け取ってほしいか」の説明書である。
曖昧な求人表現はステージごとの課題に分解する
求人票でよく使われる曖昧な表現の一つに、「自走できる人」があります。
この言葉自体が悪いわけではありません。
実際、どの会社でも、細かく指示されなくても状況を見て動ける人は必要です。
ただし、「自走できる」とだけ書くと、どのステージで何を判断してほしいのかが分かりません。
仕事には複数のステージがあります。
たとえば、エンジニアやデザイナーの仕事でも、次のように分けられます。
| ステージ | 任せたい課題 | 必要な判断 |
|---|---|---|
| 調査 | 既存コード・既存サイト・既存業務を把握する | どこを読むべきか |
| 整理 | 課題や制約を整理する | 何を論点化するか |
| 提案 | 複数案を出す | どの案を推すか |
| 合意 | 関係者と認識を合わせる | 何を決定事項にするか |
| 実装 | コードやデザインに落とす | どこまで変更するか |
| レビュー | 品質を確認する | 何を許容しないか |
| 運用 | 継続的に改善する | 何を次の課題にするか |
このステージを分けると、「自走できる人」という表現の曖昧さが見えてきます。
会社が本当に求めているのは、次のどれでしょうか。
- 既存コードを読んで、修正箇所を特定できる人
- 顧客の要望を整理して、技術的な論点に変換できる人
- 複数の実装案を出して、メリット・デメリットを説明できる人
- 顧客やディレクターと合意形成できる人
- 決まった仕様を安全に実装できる人
- AI が生成したコードをレビューできる人
- 運用後の課題を見つけて改善提案できる人
これらは、すべて違う能力です。
もちろん、一人の人が複数のステージを担当することもあります。
しかし、その場合でも、求人票には「どのステージをどこまで任せるのか」を書くべきです。
たとえば、次のような求人表現があったとします。
顧客の課題を理解し、自走して提案・実装できる方
この表現は、かなり広い範囲を含んでいます。
調査、整理、提案、合意、実装、レビューまで全部を期待しているようにも読めます。
もし実際には、顧客との最終合意や見積もり判断はディレクター・営業が担当するのであれば、そこまで書いたほうがよいです。
たとえば、次のようにできます。
既存サイトや顧客要望をもとに、技術的な課題を整理し、実装方針の選択肢を提示できる方。顧客との最終合意や見積もり判断はディレクター・営業と連携して進めます。実装時には、AI コーディングエージェントを活用しながら、生成コードの品質・セキュリティ・保守性をレビューできることを期待します。
このように書くと、候補者は次のことを理解できます。
- 調査と整理は期待されている
- 技術的な選択肢の提示も期待されている
- 顧客との最終合意は一人で背負わなくてよい
- 見積もり判断は営業・ディレクターと連携する
- AI 活用は前提になる
- AI の生成結果をレビューする責任がある
求人票の文章は少し長くなります。
しかし、期待値は明確になります。
AI 時代には、短く曖昧な求人票より、多少長くても仕事の渡し方が分かる求人票のほうが重要になるはずです。
「自走できる人」と書く前に、どのステージで何を判断してほしいのかを書く。
求人票から面接 FAQ と交渉設計を作る
求人票は、会社が候補者に向けて出す文書です。
一方で、候補者から見ると、求人票は面接準備の材料にもなります。
特に AI 時代には、求人票を AI に読ませて、面接 FAQ や交渉論点を作ることができます。
ここでいう交渉設計とは、給与交渉だけではありません。
むしろ重要なのは、仕事の前提をすり合わせることです。
- 何を任されるのか
- 何を任されないのか
- 何を自分で判断してよいのか
- 何を確認すべきなのか
- どのステージから関わるのか
- 誰と合意するのか
- AI 利用はどこまで許可されるのか
- 成果は何で評価されるのか
これらを事前に整理することで、面接は単なる自己 PR ではなくなります。
候補者と会社が、仕事の渡し方をすり合わせる場になります。
たとえば、求人票をもとに AI に次のようなプロンプトを投げることができます。
以下の求人票をもとに、面接で確認すべき FAQ を作成してください。
特に以下の観点で整理してください。
- 仕事のステージ
- 担当範囲
- 判断してよい範囲
- チームに確認すべき範囲
- 顧客と合意すべき範囲
- AI ツール利用の可否
- 成果物
- 評価基準
- 入社後に期待値ズレが起きそうな点
すると、次のような FAQ を作れます。
## 面接で確認したいこと
### Q1. この職種は、調査・提案・実装・レビュー・運用のどのステージから関わりますか？
### Q2. 候補者が自分で判断してよい範囲はどこまでですか？
### Q3. 顧客との合意形成は誰が担当しますか？
### Q4. 技術的な選択肢を提示した場合、最終決定者は誰ですか？
### Q5. AI コーディングエージェントの利用は許可されていますか？
### Q6. AI が生成したコードのレビュー責任は誰が持ちますか？
### Q7. 成果は、実装量・提案数・品質改善・顧客満足のどれで評価されますか？
### Q8. 入社後、最初の3か月で期待される成果物は何ですか？
このような FAQ は、候補者だけでなく会社側にも役立ちます。
なぜなら、候補者が聞きそうなことは、求人票に書いておくべきことでもあるからです。
面接で毎回同じ質問が出るなら、それは求人票やオンボーディング資料に不足があるということです。
求人票の曖昧さは、面接で確認すべき論点になります。
そして、その論点は、会社側から見れば求人票を改善する材料になります。
求人票の曖昧さは、面接で確認すべき論点になる。
交渉設計から逆に求人票を作る
通常、求人票は次の順番で考えられがちです。
求人票を書く
↓
応募者が来る
↓
面接する
↓
入社後に仕事を説明する
しかし AI 時代には、逆向きに考えることもできます。
どんな合意が必要かを整理する
↓
面接 FAQ を作る
↓
ステージごとの担当範囲を決める
↓
判断範囲・確認範囲を決める
↓
成果物・評価基準を決める
↓
求人票を書く
つまり、求人票を最初に書くのではなく、交渉設計から逆算して求人票を書くという考え方です。
この方法の利点は、求人票が単なるスキル一覧になりにくいことです。
たとえば、先に次のような論点を整理します。
- 候補者にどのステージを任せるのか
- 顧客との合意形成は誰が担当するのか
- 技術的な判断はどこまで任せるのか
- AI ツール利用をどこまで許可するのか
- 成果物はコードなのか、設計メモなのか、issue なのか、提案資料なのか
- 入社後 3 か月で何を期待するのか
そのうえで求人票を書けば、「自走できる方」「提案できる方」といった曖昧な表現を減らせます。
AI を使うなら、次のようなプロンプトも使えます。
以下の面接 FAQ と交渉論点をもとに、エンジニア求人票の草案を作成してください。
求人票では、単なるスキル一覧ではなく、以下を明確にしてください。
- この職種が関わる仕事のステージ
- 任せたい課題
- 判断してよい範囲
- チームや顧客に確認すべき範囲
- 期待する成果物
- 評価・レビュー観点
- AI ツール利用に関する方針
ここで重要なのは、AI に求人票を書かせること自体ではありません。
重要なのは、求人票を書く前に、仕事の渡し方と期待値調整の論点を整理することです。
AI は、その整理を支援できます。
求人票、AGENTS.md、DESIGN.md、面接 FAQ、オンボーディング資料は、別々の文書のように見えます。
しかし実際には、どれも「仕事をどう渡すか」を扱っています。
そのため、相互に変換できます。
求人票
↓
AGENTS.md / DESIGN.md
↓
issue / 受け入れ基準
↓
面接 FAQ / 交渉設計
逆方向も可能です。
面接 FAQ / 交渉設計
↓
必要な責任範囲
↓
AGENTS.md / DESIGN.md
↓
求人票
AI 時代の特徴は、この相互変換が現実的になることです。
求人票は採用のためだけの文書ではなく、開発ドキュメント、デザインドキュメント、面接設計、オンボーディング資料と接続するようになります。
良い求人票は、面接で揉めそうな論点を先に整理した文書である。
AI時代の求人票に書くべき項目
では、AI 時代の求人票には何を書けばよいのでしょうか。
最低限、次の項目を整理するとよいと思います。
仕事の目的
この職種は何のために存在するのか。
単に「エンジニアを募集します」ではなく、何を改善したいのか、何を作りたいのか、どの課題に取り組むのかを書く。
関わるステージ
調査、整理、提案、合意、実装、レビュー、運用のどこを担当するのか。
すべてを一人で担当するのか、一部のステージだけを担当するのかを明確にする。
担当する課題
各ステージで何を解決してほしいのか。
たとえば「既存サイトの保守」なのか、「新規機能の実装」なのか、「顧客要望の技術的整理」なのかで、必要な能力は変わる。
判断してよい範囲
候補者が自分で決めてよいことは何か。
技術選定、実装方針、デザイン調整、顧客への提案、スケジュール調整など、どこまで任せるのかを書く。
確認すべき範囲
誰に確認すべきことは何か。
上長、営業、ディレクター、デザイナー、エンジニア、顧客、経営者など、確認先を明確にする。
合意が必要な相手
どの判断について、誰と合意する必要があるのか。
特に顧客との合意、見積もり、契約、納期、仕様変更、デザイン変更は、責任範囲が曖昧になりやすい。
成果物
何を作るのか。
コード、デザイン、仕様メモ、issue、PR、FAQ、提案資料、議事録、README、AGENTS.md、DESIGN.md など、成果物を具体化する。
受け入れ基準
何を満たせば完了なのか。
動けばよいのか、テストが通ればよいのか、レビューを通ればよいのか、顧客が承認すればよいのかを明確にする。
AI利用方針
AI コーディングエージェントや生成 AI をどこまで使ってよいのか。
利用可能なツール、禁止事項、情報管理、コードレビュー、著作権・ライセンス確認などを書く。
レビュー責任
AI が生成した成果物を誰が確認し、何を基準にレビューするのか。
AI を使う場合でも、最終的な品質責任は人間が持ちます。
そのレビュー観点を求人票に書けると、期待値が明確になります。
まとめ：求人票は仕事の渡し方を表すハーネスになる
AI コーディングエージェントを使う時代には、仕事を曖昧なまま渡すことが難しくなります。
AI に仕事を渡すために AGENTS.md が必要になるように、人間に仕事を渡す求人票にも、目的・前提・制約・判断範囲・受け入れ基準が必要になります。
特に重要なのは、次のことです。
どのステージで、何を判断し、誰と合意し、何を成果物にするのか。
「自走できる人」と書くだけでは、候補者にどこまで責任を渡すのかが分かりません。
「顧客の課題を理解して提案できる人」と書くだけでは、調査、整理、提案、合意、実装、レビューのどこまでを任せるのかが分かりません。
これからの求人票は、採用広報であると同時に、面接 FAQ、交渉設計、入社後オンボーディングにつながる文書になります。
求人票は、会社の仕事の渡し方を表すハーネスです。
AI 時代の求人票は、「人間向け AGENTS.md」になる。
そう考えると、求人票の書き方も、求人票の読み方も変わってくるはずです。