図解
はじめに
「AIがコードを書くなら、エンジニアは何をするのか」。
この問いには、これまで感想しかありませんでした。データで答えた研究が出ています。
Anthropic が2026年6月に公開した Agentic coding and persistent returns to expertise です。約40万セッションを分析したもので、結論の1行目がこれでした。
In practice, there is a clear division of labor in agentic coding—people decide what to build, and the agent decides how to build it.
（実際のところ、エージェント型コーディングには明確な分業がある。人が何を作るかを決め、エージェントがどう作るかを決める）
「何を」と「どう」で線が引かれた。しかもその線は、誰かの主張ではなく40万件の実測から引かれています。
この記事では、この研究が何を測り、何を見つけたのかを整理します。
結論を先に言うと、価値の源泉が「書けること」から「その領域で何をすべきか分かっていること」へ移っていたという話です。
この記事で扱うこと
- 何が、どう調べられたのか
- 「何を」と「どう」の分かれ方（70%と80%）
- コード力より効いていたもの
- 職種の壁がどれだけ消えたか
- 7ヶ月で仕事の中身がどう動いたか
- この研究が測れていないこと
📊 何が調べられたのか
まず調査の規模と方法です。ここを押さえないと、数字の重みが分かりません。
| 項目 | 内容 |
|---|---|
| 対象 | Claude Code の約40万セッション |
| 人数 | 約23万5千人 |
| 期間 | 2025年10月 〜 2026年4月（7ヶ月） |
| 公開 | 2026年6月16日 |
| 著者 | Zoe Hitzig、Maxim Massenkoff、Eva Lyubich、Shaoyi Zhang、Ryan Heller、Peter McCrory |
分類はすべて分類器（モデル）が行っています。専門性は5段階で評価され、判断は「計画（planning）」と「実行（execution）」に分けられました。
ここで注目すべきは、規模ではありません。成功の定義です。
「うまくいったように見える」だけでは、成功と数えていません。
成功には2段階あります。部分成功（partial success） は判定器がそう見なしたもの。検証済み成功（verified success） は、それに加えてコミット・テスト通過・ユーザーの明示的な肯定といった、外部から確認できる証拠が揃ったものです。
この図の右端の緑が、記事中の「成功率」です。外部の証拠まで揃ったものだけを数えているので、数字は保守的に出ています。
同じ「成功率」でも、部分成功なら9割を超え、検証済み成功なら3割前後まで落ちます。以降この記事で「成功率」と書くとき、断りがなければ後者を指します。
数字が低く見えたら、厳しく数えているからだと思ってください。
⚖️ 人間は「何を」、AIは「どう」
この研究の中心的な発見です。数字がきれいに割れました。
On average, people make about 70% of the planning decisions but only 20% of the execution decisions.
（平均して、人は計画判断の約70%を行うが、実行判断は約20%しか行わない）
この図の色が濃く塗られた2つが、それぞれの持ち場です。人は上流の判断を握り、実装の判断は手放している。
大事なのは、これが「そうすべきだ」という提言ではないことです。23万5千人が実際にそう使っていた、という観測結果です。
そして人間側の70%は、エージェントの能力が上がっても崩れていません。
より強いエージェントを渡されても、何を作るかは人が決め続けていました。手放されたのは実装の判断だけです。
🎯 効くのはコード力ではなく領域の理解
ここからが本題です。何が成果を分けたのか。
Domain expertise, and not coding proficiency, amplifies effective use of the tool.
（ツールの効果的な利用を増幅するのは、コーディング能力ではなく領域の専門性である）
差の出方が具体的です。
| 専門性 | 1指示あたりの Claude の動作数 | 検証済み成功率 | 部分成功率 |
|---|---|---|---|
| 初心者 | 約5 | 15% | 77% |
| 中級〜熟練 | 約12 | 28〜33% | 91〜92% |
1指示あたりの仕事量が2.4倍、成功率がおよそ2倍。 同じツールを渡しても、これだけ差が出ます。
研究側の説明はこうです。
The more domain expertise a person brings to a session, the more work Claude does per instruction.
（セッションに持ち込む領域の専門性が高いほど、1つの指示で Claude がこなす仕事量が増える）
この図の下の経路が、成果を出している側です。指示の精度は、その領域を分かっているかで決まります。
言い換えると、AIに任せられる量は、AIの性能ではなく依頼する側の理解度で決まっていた、ということになります。
同じモデルを使っていても、引き出せる量は人によって2倍以上違う。差はツールの外にありました。
👥 職種の壁が消えた
もっと踏み込んだ結果があります。ソフトウェアエンジニアかどうかが、ほとんど効いていませんでした。
In code-producing sessions, every one of the ten largest occupations in our dataset lands within seven points of software engineers in terms of their success.
（コードを生成するセッションにおいて、データ中の上位10職種のすべてが、成功率でソフトウェアエンジニアの7ポイント以内に収まっている）
数字で見ると、差はさらに小さくなります。
| 検証済み成功率 | 部分成功率 | |
|---|---|---|
| ソフトウェアエンジニア | 30% | 89% |
| 非ソフトウェア職 | 26% | 88% |
この図の右側、2本の棒がほとんど同じ高さになっているところが、この章の要点です。部分成功では1ポイント差。
そして最も高い検証済み成功率を出したのは、ソフトウェアエンジニアではなく管理職でした。
研究側の言い方は率直です。
It appears that coding agents are making a coding background less relevant to successful programming.
（コーディングエージェントは、プログラミングを成功させるうえでコーディングの経歴を重要でなくしつつあるように見える）
もう1文、影響の向きを示すものがあります。
A person with such command, in any field, may now be able to do technical work they previously could not.
（その領域を掌握している人であれば、どの分野の人でも、以前はできなかった技術的な仕事ができるようになるかもしれない）
これは、エンジニアにとって二重の意味を持ちます。自分の守備範囲が広がると同時に、コードが書けることだけでは守れなくなる。
壁が消えるのは、こちらから出ていくときも、向こうから入ってくるときも同じです。
📉 7ヶ月で仕事の中身が変わった
期間中の推移も測られています。ここが一番はっきり動いていました。
| セッションの内容 | 2025年10月 | 2026年4月 |
|---|---|---|
| 壊れたコードの修正（デバッグ） | 33% | 19% |
| ソフトウェアの操作 | 14% | 21% |
| 執筆・データ分析 | 約10% | 約20% |
The share of sessions spent fixing broken code fell from 33% to 19%.
（壊れたコードの修正に費やされたセッションの割合は、33%から19%へ下がった）
この図で下に落ちている1本と、上に伸びている2本が、7ヶ月で起きたことです。後始末が減り、作ることと考えることが増えた。
デバッグが14ポイント減ったのは、単に「AIが賢くなった」だけの話ではありません。
壊れたものを直す時間が、別の何かに置き換わったということです。その受け皿が、操作と執筆・分析でした。
空いた時間がどこへ流れたかは、これから何が仕事になるかを示しています。
🪜 では、どこへ移るのか
研究は「何が起きたか」までを示しています。「だからどうするか」は書かれていません。
その先を仮説として出しているのが、Claude Code の開発を率いる Boris Cherny 氏です。従来の職種区分ではなく、5つのアーキタイプで捉え直す案を提示しています。
| アーキタイプ | 役割 |
|---|---|
| プロトタイパー | 新しいアイデアを大量に試す。大半は世に出ない |
| ビルダー | アイデアや試作を本番品質へ持っていく |
| スイーパー | UI・コード・システムを整理し、削除・単純化・高速化する |
| グロワー | 作られた製品を反復改善し、市場との適合を高める |
| メンテナー | 成熟したシステムの安全性・信頼性・性能を維持する |
この図の中央にある軸の違いが要点です。「何ができるか」から「何に責任を持つか」へ、区分の基準がずれています。
ただし、これはあくまで仮説として提示されたものです。
Cherny 氏自身が将来こうなるのではという言い方をしていますし、日本語でもすでに批判的な整理が書かれています。
ここまでの実測と、この章は分けて読んでください。
⚠️ この研究が測れていないこと
数字が強いぶん、限界も押さえておく必要があります。研究側が明記しています。
We cannot measure real-world outcomes, like whether code written in a session is actually used or discarded thereafter.
（セッションで書かれたコードがその後実際に使われたのか捨てられたのかといった、現実世界の結果は測定できない）
つまりこの研究が測っているのは、セッションの中で起きたことまでです。そのコードが本番で動き続けたか、事業の役に立ったかは分かりません。
もう1つ、分類そのものの限界もあります。
All of our classifications of sessions depend on a model's reading of the transcript.
（セッションの分類はすべて、モデルによるトランスクリプトの読み取りに依存している）
「専門性が高いほど成功率が高い」も、専門性の判定自体がモデルの読み取りである以上、専門家らしい書き方をする人が高く出ている可能性は残ります。
数字は強い。ただし万能ではない。そう読むのが正確です。
📝 まとめ
40万セッションが示したことは、3つに絞れます。
1つ目。分業の線は「何を」と「どう」の間に引かれた。 人が計画判断の70%を握り、実行判断の80%はエージェントが持つ。
2つ目。差を作るのはコード力ではなく領域の理解だった。 熟練者は1指示あたり2.4倍の仕事をさせ、成功率はおよそ2倍。
3つ目。職種の壁はほとんど消えた。 上位10職種すべてがソフトウェアエンジニアの7ポイント以内で、部分成功では1ポイント差。最も成功率が高かったのは管理職。
この記事を読んで最初に試すことを1つだけ挙げるなら、これをおすすめします。
次にAIへ指示を出す前に、「何をもって完了とするか」を自分の言葉で書けるか確かめること。
書けなければ、そこが領域の理解の足りていない箇所です。ツールを変えても埋まりません。
コードが書けることは、もう差になりません。何を作るべきか分かっていることが、差になります。
📚 参考
一次資料
- Agentic coding and persistent returns to expertise — Anthropic、2026年6月16日。Zoe Hitzig ほか5名。本記事の数字はすべてここから
関連する整理
- 最近話題の「AI時代の開発者5つのアーキタイプ」について考える — @Toyo_m。Boris Cherny 氏の分類と、それへの批判をまとめたもの
💡 この記事について
本記事は2026年9月2日時点で公開されている情報をもとにまとめています。筆者の一次調査は含まれず、数字はすべて Anthropic の公開研究からの引用です。英文の引用はすべて原典と照合しています。日本語訳は筆者によるもので、公式訳ではありません。
5つのアーキタイプは Boris Cherny 氏が仮説として提示したもので、研究の実測結果ではありません。本文でも節を分けています。
研究自体が「現実世界の結果は測定できない」「分類はモデルの読み取りに依存する」と限界を明記しています。数字の解釈にはこの前提が付きます。
エンジニアがAIを活用して次のレベルへ。上流はさらに上へ、下流は上流へ。
そのために何をするかを書いていきます。