こんにちは、株式会社TIMEWELLの濱本です。
AIがコードを書けるのに、なぜ一部のエンジニアの市場価値はむしろ上がっているのか。この問いに、データで答えた研究が出ています。
Anthropicが2026年6月16日に公開した「Agentic coding and persistent returns to expertise」という論文です。約23万5,000人による約40万セッションを、2025年10月から2026年4月まで7か月分、プライバシーを保護した形で分析しています1。ベンチマークではなく実際の利用データである点が重要です。
読んで、いくつか自分の前提が崩れました。順に書きます。
40万セッションが示した分業
いちばん明確な発見はここです。原文の表現を引きます。
people make about 70% of the planning decisions but only 20% of the execution decisions1
**人は計画の意思決定の約70%を行い、実行の意思決定は約20%しか行っていない。**裏を返せば、どうやるかの約80%はAIが決めています。
この数字が良いのは、「AIが人の代わりにコードを書く」という粗い理解を壊してくれるところです。**役割が置き換わったのではなく、層で分かれた。**人が建築家として残り、AIが施工を担う。そういう構造が、誰かの号令ではなく自然に発生していました。
セッションの中身も出ています1。
| 用途 | 割合 |
|---|---|
| コードの作成・修正・テスト | 約56%（作成25%、修正26%） |
| ソフトウェアの操作 | 17% |
| 計画・探索 | 14% |
| 分析・文書作成 | 13% |
半分近くがコードを書くこと以外、というのは意外でした。
そして時系列の変化がもっと面白い。7か月のあいだに、デバッグ用のセッションは33%から19%へほぼ半減しました。一方で1セッションあたりの推定価値は27%上昇しています。種類別に見ると、構築が43%、操作が34%、修正が32%の上昇1。
壊れたものを直すために使う道具から、作るために使う道具へ移っている、という読み方ができます。
専門性は消えない。増幅される
ここが最大の発見だと思います。
「AIが普及すれば専門知識は要らなくなる」という話をよく聞きます。このデータは逆を示しました。
検証済みの成功、つまりテストが通った、コミットされたといった確認できる証拠を伴う成功の割合はこうです1。
- 初心者と評価されたセッション：15%
- 中級以上：28%から33%
Sessions rated expert reach verified success more than twice as often as those rated novice1
専門家のセッションは、初心者の2倍以上の頻度で検証済みの成功に到達する。
さらに分かりやすいのが出力量です。1セッションあたり、初心者が約600語、専門家が約3,200語。約5倍の差があります1。同じAIに、同じように話しかけているのにです。
トラブルが起きたときの差はもっと開きます。初心者4%、専門家15%1。うまくいかなくなってからの立て直しに、専門性がはっきり効いている。
なぜか。専門性が高い人は良いタスクの切り出し方と正しい成功条件の定義ができるからだと思っています。AIは指示の質を忠実に増幅します。曖昧な指示は曖昧な成果に、精密な指示は大きな成果になる。
そして、ここが重要なのですが、**その専門性はソフトウェア工学の経験である必要はありません。**職種別の検証済み成功率は、ソフトウェア関連職が30%、その他の職種が26%1。
Every one of the ten largest occupations in our dataset lands within seven points of software engineers1
**データセット上位10職種のすべてが、ソフトウェアエンジニアから7ポイント以内に収まっている。**効いているのはコードが書けることではなく、自分の領域を深く知っていることです。
自社のAI活用がどの段階にあるかを測っておきたい方は、AIリテラシー診断で現在地を確認できます。
測るべきは「どれだけ長く任せられるか」
モデルの比較というとベンチマークの点数になりがちですが、実務で知りたいのは別のことです。
AI安全性の研究機関METRは、こういう問いを立てました。「人間の専門家なら何時間かかるタスクを、どのくらいの成功率で完遂できるか」。これをタスク・ホライズンと呼びます。「50%タスク・ホライズンが1時間」なら、人が1時間かけるタスクを50%の確率で成功させられる、という意味です2。
METRは約230のタスクで測っています。結果はこうです2。
| モデル | 50%タスク・ホライズン |
|---|---|
| GPT-2 | 2秒 |
| Claude 3.7 Sonnet | 50分 |
| o3 | 約2時間 |
| Opus 4.6 | 約12時間 |
2019年の4秒から2026年には16時間超。長期の平均で約7か月ごとに倍増しています2。
ただし、ここは素材にした資料より新しい話があります。直近は加速しています。2024年から2025年にかけては約4か月ごとに倍増しており、この速さが続けば2027年には1か月規模のタスクに届く計算になるとされています2。
この指標が良いのは、問いの立て方を変えてくれるところです。「このAIはコードを書けるか」ではなく、「どのくらい大きな塊を、途中で見張らずに任せられるか」。
そして、**任せ方を設計するスキルの価値は複利で増えます。**今日3時間分しか任せられなくても、倍増が続けば来年は9時間分、その先は日単位です。**設計の腕が同じでも、預けられる仕事の量だけが増えていく。**これが今このスキルを身につける理由だと思っています。
長いタスクで壊れるのは、モデルのせいではない
では大きく任せればいいのかというと、そう単純ではありません。
Anthropicは、複数のコンテキストウィンドウをまたいで本番品質のWebアプリを作らせる実験を行い、その失敗を公開しています3。
用語をひとつ。コンテキストウィンドウとは、AIが一度に保持できる情報量の上限です。会話やコードがこれを超えると古いものから失われます。長い作業では必ずぶつかるので、仕事は複数のセッションに分かれます。
結果、最先端モデルでもシステムは崩れました。原因はモデルの知能ではなく環境設計です。壊れ方は2つ。
**一度に全部やろうとする。**タスク全体を1セッションで片付けようとして、中途半端なまま力尽きる。
**記憶が切れる。**新しいセッションのエージェントは、前回何があったかを一切知りません。毎回ゼロから始めてしまう。
交代制のチームなのに、引き継ぎが一切なく、毎シフト新人が白紙で出勤してくる状態です。
解決策は、拍子抜けするほど普通でした。人間のチームが昔からやっていることを、そのままやらせる3。
初期化を担うエージェントがタスク全体を理解して機能単位に分解する。コーディングを担うエージェントは一度に1機能だけを実装し、テストを走らせ、コミットし、進捗ファイルを更新する。次のセッションは、まず進捗ファイルを読んで続きから始める。
要は、記憶をエージェントの頭の中ではなく外に置くということです。git履歴、進捗メモ、テスト結果。これらはコンテキストが切り替わっても消えません。エージェントは全部覚えている必要はなく、書き残されたものから状態を復元できればいい。
動くシステムを分ける3つの原則
この実験で作られたハーネス（エージェントを取り巻く足場と制御環境）の中核にある考え方は、モデルやツールを問わず使えます。
原則1。既定は不合格にする。
すべての成功基準を最初は「未達成」から始めます。エージェントが「終わりました」と宣言するだけでは完了になりません。満たしたことを示す証拠が要る。
これが無いと、エージェントは自分の宿題を自分で採点し、いつも満点をつけます。「テストは通りました（実際は走らせていない）」が普通に起きる。過剰な自信を、構造で封じるという発想です。
原則2。評価する人格を分ける。
合否の判定は、作業したエージェントとは別の、まっさらな文脈を持つ評価役が行います。この評価役は修正できません。できるのは合否と理由を返すことだけ。
人のチームでコードを書いた本人がレビューしないのと同じ理屈です。書いた本人は成果物に近すぎて欠陥が見えません。
Anthropicの記事には、この点について強い表現があります。評価役のいないハーネスは、最先端モデルが凡庸な出力を出しているとき、静かに失敗する3。エラーが出ないぶん、気づけない。ここは怖いところです。
原則3。引き継ぎメモを自分で書かせる。
コミットのたびに進捗ファイルを更新させる。何をやったか、何が残っているか、次が知っておくべきことは何か。この習慣ひとつで、毎回リセットされるシステムが、積み上がるシステムに変わります。
エージェントに何を読ませ、その結果を誰に渡すかという統制の設計は、Cloudflare OSはなぜOSSなのかでも扱いました。権限をゼロから始める、読んだものを記録する。発想は同じ方向を向いています。
ただし、何でもエージェント化しない
反対側の知見も置いておきます。
「Agentless」という研究では、自律エージェントを使わず、問題箇所の特定、修正、パッチの検証という3ステップのパイプラインだけで、低コストのまま高い成果を出せることが示されました4。
ここから学ぶべきは「エージェントが常に優れている」ではありません。複雑さはタスクに見合わせるということです。単純な問題なら単純な仕組みが勝ち、複雑で長期の問題で初めて複雑なエージェントが割に合う。
そして、自分がいまどちらにいるかを見極めること自体が、スキルの大部分です。釘を1本打つのにロボットアームを組み立てる必要はありません。
一方で環境の重要性を裏づける研究もあります。プリンストン大学のSWE-agentは、モデルは新しい種類のコンピュータ利用者であり、専用に設計されたインターフェースを必要とするという洞察を示しました。人間用のエディタをそのまま使わせるのではなく、エージェントの動き方に最適化した道具を与えたところ、モデルは何も変えていないのに性能が上がった5。
ハーネスはモデルの付属品ではなく、システムの半分です。
何から始めるか
長くなったのでまとめます。
人が計画の70%を決め、AIが実行の80%を決める。専門性は無価値にならず、出力量で5倍の差になって現れる。任せられるタスクの長さは倍増を続け、直近は4か月で倍。そして差を作るのはモデルではなく、その周りに置く環境です。
実務としては、この順番だと思っています。
ひとつめ。完結する小さなタスクを1つ任せて観察する。「関数を書いて」ではなく「このバグを直し、直ったことを証明するテストを書き、両方コミットして」。始まりと中間と終わりがある単位で渡す。そして指示と成果のどこがずれたかを見る。
**ふたつめ。2回以上説明した規約をファイルに書き出す。**技術スタック、触ってはいけない場所、テストの書き方、コミットの流儀。一度書けば毎回読み込まれます。同じ説明を繰り返す時間が消えます。
**みっつめ。進捗ファイルを導入し、同じタスクを2回走らせる。**引き継ぎ有りと無しで、2回目の冒頭に何が起きるかを比べる。外部記憶の効果は、体感しないと信じられません。
**よっつめ。評価役を分ける。**書き込み権限なし、作業履歴の知識なし。仕事は成果物を読んで合否と理由を返すことだけ。校正は簡単で、**失敗すると分かっているタスクと成功すると分かっているタスクの両方にかける。**前者を落とし後者を通せば信頼できます。
コードベースを構造として持たせる話はグラフエンジニアリングとは何かに、Claude Codeの具体的な機能はClaude Code完全ガイドにまとめました。
正直なところ、この研究でいちばん励まされたのは職種の話です。上位10職種すべてがソフトウェアエンジニアから7ポイント以内。プログラミングができるかどうかではなく、自分の仕事を深く知っているかどうかが効いている。
経理のベテランが月次処理を任せるときも、営業のエースが提案書を任せるときも、勝敗を分けるのは同じ3原則です。**証拠で確認する。別の目で見る。引き継げる形で残す。**エージェント・エンジニアリングは、エンジニアだけの話ではないと思っています。
AI活用の設計や、社内でどう任せる仕組みを作るかについて相談したい方は、WARPの考え方が参考になるかもしれません。個別のご相談はこちらからどうぞ。
Footnotes
-
Anthropic「Agentic coding and persistent returns to expertise」（Zoe Hitzig、Maxim Massenkoff、Eva Lyubich、Shaoyi Zhang、Ryan Heller、Peter McCrory、2026年6月16日公開）。約23万5,000人による約40万件の対話セッションを2025年10月から2026年4月にかけてプライバシーを保護した形で分析したもの。「people make about 70% of the planning decisions but only 20% of the execution decisions」、セッションの内訳（コードの作成・修正・テスト約56%（作成25%、修正26%）、ソフトウェア操作17%、計画・探索14%、分析・文書作成13%）、デバッグセッションの比率が33%から19%へ低下したこと、1セッションあたりの推定価値が27%上昇し種類別に構築43%・操作34%・修正32%であったこと、検証済み成功率が初心者評価15%・中級以上28%から33%であること、「Sessions rated expert reach verified success more than twice as often as those rated novice」、トラブル発生時の成功率が初心者4%・専門家15%であること、1セッションあたりの出力が初心者約600語・専門家約3,200語であること、職種別の検証済み成功率がソフトウェア関連職30%・その他26%であること、および「Every one of the ten largest occupations in our dataset lands within seven points of software engineers」は、いずれも同研究による。https://www.anthropic.com/research/claude-code-expertise ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10
-
METR「Measuring AI Ability to Complete Long Software Tasks」および関連する更新。タスク・ホライズンは、あるエージェントが特定の成功率で解けるタスクについて、人間の専門家が要する時間として定義される。約230のタスク（多くはコーディング、一部は一般的推論）で測定され、50%タスク・ホライズンは2019年の4秒から2026年には16時間超まで伸び、長期では約7か月ごとに倍増している。ただし2024年から2025年にかけては約4か月ごとの倍増となっており、この速さが続けば2027年には1か月規模のタスクに達しうるとされる。モデル別ではGPT-2が2秒、Claude 3.7 Sonnetが50分、o3が約2時間、Opus 4.6が約12時間。https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/ ／ https://theaidigest.org/time-horizons ↩ ↩2 ↩3 ↩4
-
Anthropic「Effective harnesses for long-running agents」（エンジニアリングブログ）。エージェントは記憶を持たない離散的なセッションで作業する必要があり、コンテキストウィンドウが有限であるため複雑なプロジェクトは単一のウィンドウで完了できないという課題、初回実行時に環境を整える初期化エージェントと各セッションで漸進的に進捗を作り次のセッションのために明確な成果物を残すコーディングエージェントという構成、および評価エージェントを持たないハーネスは最先端モデルが凡庸な出力を出しているときに静かに失敗するという指摘は、同記事による。https://anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩ ↩2 ↩3
-
Xia et al.「Agentless」（arXiv:2407.01489）。自律エージェントを用いず、問題箇所の特定、修正、パッチの検証という3段階のパイプラインにより、低コストで高い成果を出せることを示した研究。https://arxiv.org/abs/2407.01489 ↩
-
Yang et al.「SWE-agent」（arXiv:2405.15793）。プリンストン大学の研究チームによるもので、AIモデルは新しい種類のコンピュータ利用者であり専用に設計されたインターフェースを必要とすること、エージェント向けに最適化した道具を与えることでモデル自体を変更せずに性能が向上することを示した。https://arxiv.org/abs/2405.15793 ↩
