実装者からリーダーへ: エージェントと働く開発者の役割の変化

エージェントによって、コードを書くコストは大きく下がりました。一方で、何を作るべきかを理解することや、できあがったものを検証することのコストは下がっていません。だから、エージェントとの仕事で最も興味深いことは、コードを書く前と後に起きます。誰がタスクを決め、誰が成果の良し悪しを判断し、どれだけの作業をエージェントに任せるかをどう選ぶのか。

ここでは、過去2年間の調査やレポートをもとに、エージェントとの4つの協業方法、タスクに応じた方法の選び方、そして"意図と品質基準"と呼ばれるものを見ていきます。後半では、開発者の役割がコードを書くことより広がっている理由を考えます。データは2026年9月時点のものです。数値は出典へのリンクとともに個別の枠に記載します。著者の見解を紹介するときは著者名を挙げ、私自身の考察はそうと明記します。

エージェントとの4つの協業方法

最もわかりやすい枠組みを示したのは、Microsoftのジャレッド・スパタロです。2026年5月、人とAIが仕事を分担する4つの方法を整理しました。開発者なら、ツールとともに歩んできた自分の道のりをそこに重ねられるでしょう。

段階が上がるほど、自分で書くコードは減り、事前に決めることと事後に確認することが増えます。実装者は書きながら品質を見極めます。ディレクターはコードができる過程を見ないため、重要なことは作業前に伝え、完了後に確認しなければなりません。オーケストレーターについては名前だけ触れました。専用のツールも関わる大きなテーマなので、最初の3つの方法に慣れてから考えるとよいでしょう。

階段ではなく、タスクに合う方法を

この分類は階段のように見えるかもしれません。まず実装者として始め、やがてオーケストレーターへ進み、高い段階ほどよいという見方です。しかしスパタロは、そうではないと明言しています。すべてのタスクを4つ目の方法に移すのではなく、作業の流れごとに適した方法を選ぶのが目的です。

実際に選ぶときは、次の4つを考えます。

• 目的がどれだけ明確か。どんな結果が必要か自分でも分からないうちは、タスク全体を任せるのは早すぎます。
• 結果を自動で検証できるか。テストがしっかりしていれば、ミスを見つけるのはあなたの注意力ではなくテストになるので、エージェントにより先まで任せられます。
• 失敗のコストはどれくらいか。ヒント文の誤字なら簡単に直せますが、金額の計算ミスは高くつきます。
• タスクが繰り返し発生するか。一度きりのタスクのために専用のプロセスを作るのは割に合いませんが、毎週のタスクなら検討できます。

具体的なタスクに当てはめると、こうなります。

この数値は頭に入れておくとよさそうです。多くの人が慎重だからといって、遅れているわけではありません。失敗のコストに応じて方法を選ぶのは適切な判断です。ミスが大きな損失につながるタスクで編集者のように働いても、エージェントを"十分に活用できていない"わけではありません。

Claude Codeでは、この選択を直接調整できます。計画モードや権限ルールは、自分で設定する調整つまみのようなものです。失敗のコストが高いタスクでは、修正前に計画を立て、リスクのある操作には確認を求めます。定型作業なら、より先までエージェントに任せます。

意図と品質基準

任せる作業が増えるほど、開始前に伝えることが重要になります。Microsoftの調査は、AIを最も効果的に使うのは、より多く、より速く作業する人ではなく、人にしかできないことを軸に自分の価値を築く人だと述べています。つまり、明確な意図を示すこと、すなわち望む成果と品質基準を言葉にし、作業を人とAIでどう分担するかを考えることです。

開発では、この考え方に以前から馴染みのある呼び名があります。意図とは仕様、つまり何を、なぜ作るのかです。品質基準とは受け入れ条件であり、ScrumでいうDefinition of Done、つまり作業完了とみなすための条件一覧です。ここでは"完了基準"と呼ぶことにします。

Agileの考え方でエージェントを開発するMicrosoftのダニエル・エプスタインは、Agentic-Agileシリーズの最初の記事（2026年5月19日）で、こう簡潔に述べています。"Every capability is an issue. Every issue has acceptance criteria.（機能はすべて課題であり、課題にはすべて受け入れ条件がある）"

タスクは、人向けとエージェント向けの2つの観点で書くと便利です。人には、なぜ必要で誰が使うのかを説明します。エージェントには、何を作り、どんな条件で確認し、何に手を加えてはいけないかを伝えます。同じ依頼がどう変わるか、学習用の例を見てみましょう。改善後の最初の段落は人向けで、それ以降はエージェント向けです。

変更前:

経費をCSVにエクスポートできるようにして。いい感じに。

変更後:

背景: 経理担当者は毎月、チームの経費を手作業で自分の表に転記しています。
毎回1時間かかり、金額の入力ミスも起きています。

タスク: 月次経費ページに"CSVにエクスポート"ボタンを追加する。

完了条件:
- ファイルをダブルクリックで表計算ソフトで開けて、文字コードを手動設定せずに日本語の項目名が読める。
- 1行につき1件の経費を記録し、1行目に列名を入れる。
- セルを編集せずに数式で合計を計算できる。

変更しないもの: 経費の保存形式と既存の一覧画面。
まず計画と、各項目の確認方法を提示してください。

変更後の依頼なら、エージェントが推測することはほとんどありません。さらに大切なのは、結果と照らし合わせる基準があることです。3つの条件は数分で手動確認できます。変更前の"いい感じ"は検証できず、信じるしかありません。

エージェントは"良い"の意味を知らない

ここからは、データそのものより、そこから考えられることが中心です。調査結果と私の意見を混同しないよう、先にお伝えしておきます。

エージェントにできることはたくさんあります。見慣れないプロジェクトを読み、エラーの原因を見つけ、実装し、テストを実行して、何をしたか説明できます。しかし、ひとつだけできないことがあります。そのユーザーとそのビジネスにとって"良い仕事"とは何かを、自分で決めることです。基準がなければ、もっともらしい無難な案を選び、完成したものとして自信たっぷりに報告します。コードはきれいでも、解決策が的外れということはあります。

"良さ"はコードの中にあるわけではありません。誰が結果を使うのか、その人にとって何が重要か、どんなミスが許されないかによって変わります。先ほどのエクスポートの例なら、技術的には正しいCSVを作れても、経理担当者の環境では文字化けするかもしれません。コードとしては正しくても、タスクの目的は果たしていません。

結論はシンプルです。基準を決め、その基準に沿って結果を確認することは、委任できない仕事です。エージェントは基準を言葉にする手助けをし、確認のための質問を投げかけ、検証方法を提案できます。ただし、その基準が正しいかを決めるのはあなたです。

まず業務の流れを理解する

基準はどこから生まれるのでしょうか。コードから生まれることはほとんどありません。業務の流れから生まれます。誰がファイルを開き、その後どう使うのか。行が欠けたり、金額が意図しない形で丸められたりしたら、何が起きるのか。

"文字コードを手動設定せずに日本語の項目名が読める"という要件は、CSVの書き方として正しいから生まれたのではありません。誰かが経理担当者にファイルの開き方を尋ね、インポートウィザードを使わずにダブルクリックで開くと知ったからです。業務を理解している開発者なら、最初からこの条件を書けます。そうでなければ、1か月後に苦情を受けて気づくことになります。

企業もこの変化に気づき、役割を見直し始めています。

この動きとは異なる見方もあります。知っておく価値はあるでしょう。たとえばコンサルティング会社Converteoは、自社ブログで、プロダクトマネージャー、デザイナー、AI product builderは競合するのではなく、互いを補う役割だと説明しています。プロダクトマネージャーは"なぜ"を、デザイナーはユーザーを、AI product builderはアイデアを動くプロトタイプに素早く変えることを担当します。Converteo自身もこの分野のサービスを販売しています。どちらか一方に賭けるつもりはありません。実務上の結論は同じです。依頼者の業務を理解する開発者は、完璧に書かれたチケットを待つ人より価値があります。

会話も仕事の道具

以前、soft skillsは技術に添えるとよいものとして語られがちでした。エージェントと働くと、その位置づけが変わります。品質基準はリポジトリではなく人の頭の中にあり、会話を通じてしか引き出せません。

実際には、次のようなことも仕事の一部です。

• 尋ねる。"何を作るか"ではなく"結果をどう使いますか"と聞くと、より具体的な答えが返ってきます。
• 確認する。エッジケースがバグになる前に質問しましょう。カテゴリのない経費はどう扱えばよいでしょうか。
• 記録する。会話だけで決めたことはエージェントには読めず、同僚も忘れてしまいます。
• 範囲を合意する。何がタスクに含まれ、何が含まれないかを決め、"ついでに直して"と頼まれたら"それは別のタスクです"と伝えます。
• トレードオフを説明する。"期間を選べない形なら1日、選べるようにするなら3日でできます"。決めるのは依頼者ですが、選択肢を示すのはあなたです。

どれもコードを書くスキルではありませんが、エージェントの成果に直接影響します。つまり、人との会話の質が、エージェントへの依頼の質につながります。

誰もが少しCEOになる

ここまでをまとめると、見慣れた姿が浮かびます。目標を定め、基準を決め、仕事を分担し、結果を確認して責任を持つ。これはリーダーの仕事です。エージェントと働く開発者は、小さな規模ながら毎日それを担います。

CEOという比喩のよいところは、誰が責任を持つのかを正しく示している点です。CEOは結果への責任以外なら、ほとんど何でも委任できます。エージェントとの仕事も同じです。エージェントが経理担当者の表を壊すようなエクスポートを作っても、責任を負うのはエージェントではありません。

この比喩が意味しないこともお伝えしておきます。昇進の話ではなく、エージェントを3つ起動したからといってリーダーになるわけでもありません。むしろ、リーダーのスキルが従来より早く、最初の仕事から必要になるということです。そしてリスクもあります。開発者は長い間、自分でコードを書くことで成長してきましたが、その道筋が変わりつつあります。エージェントから受け取るコードを理解することは、今も欠かせません。それがなければ、検証が"たぶん動く"だけで終わってしまいます。

データの読み解き方

ここまでの数値は、いずれもAIや関連製品を販売する企業が発表したものです。だからといって誤りとは限りませんが、その点は意識しておきましょう。簡単にまとめると、次のとおりです。

ここにある割合はすべて、ある時点における人々の自己評価です。実際に何が起きたかではなく、人々が何を考え、何を予想しているかを示しています。Work Trend Index 2026の著者も、分析で見られた関連性は統計的な相関であり、因果関係ではないと明記しています。

AIと仕事に関する数値を見たら、3つのことを尋ねるとよいでしょう。誰が調査費用を出したのか。何を測ったのか、意見か、予想か、それとも実際の結果か。誰に尋ね、その人たちはあなたに近いのか。答えに納得できるなら、その数値を参考にできます。そうでなくても興味深い情報ではありますが、重みは小さくなります。

この話を実務に活かす

ここまでのレポートのような話は、Claude Codeを使うと具体的な習慣に置き換えられます。

• 修正前に計画を確認する - これが意図を伝えることです。エージェントに、何をどう変更するか先に示してもらい、自分の希望と照らし合わせます。
• 依頼に受け入れ条件を書く - 完了基準を示すことです。"いい感じに"ではなく、検証できる条件を2、3個書きます。
• 作業モードと権限ルールを選ぶ - どの方法で進めるかを決めます。失敗のコストが高いほど、エージェントが停止して確認する頻度を上げます。
• diffを見て、きちんと検証する - エージェントの報告ではなく、自分の基準で結果を評価します。
• 何を行い、何を検証し、何を検証していないかを簡潔にまとめる - エージェントには委ねられない結果への責任を果たします。

データは2026年9月時点。関連する調査は頻繁に発表され、数値は考察より早く古くなります。