TL;DR:
- 「AIで10倍速くなる」という主張は一次研究では確認できない。厳密なRCTの幅は+55.8%〜−19%。
- 75日・486 Issue（単独オペレーターの観測）で変わったのは、タスク単体の速度ではなく、1人が同時に動かせる作業範囲だった。
- ただしその範囲が広がるほど、仕様の甘さ・レビュー待ち・意思決定の遅れも一緒に膨らむ。ボトルネックは消えたのではなく、AIから人間の判断スループットに移った。
「10倍」という数字はどこから来るのか
「AIを使えば生産性が10倍になる」という言説は2023年頃から広まったが、一次論文を確認できていない。出典を辿ると企業ブログやCEOの発言が引用元になっているケースがほとんどだ。
厳密なRCT（ランダム化比較試験）が出した数字を並べると事情はかなり異なる。+55.8%という数字はGitHub CopilotでJavaScriptのHTTPサーバーを実装するという単発タスク実験の値で（Peng et al., arXiv:2302.06590, 2023）、現実の業務に近い設定になるほど数字は小さくなる。Microsoft・Accenture等3社のフィールドRCTではn=4,867で+26%、コールセンター業務の自然実験ではn=5,179で+14%（Brynjolfsson et al., NBER WP31161, 2023）。そして熟練OSSコントリビュータを対象にした直近RCTでは、Cursor Proを使った群が使わなかった群より19%遅かった（METR, arXiv:2507.09089, 2025年7月）。
知覚と実測の乖離: このMETR実験で開発者は「24%速くなるはず」と予測し、終了後も「20%速くなった」と回答した。しかし実測は19%遅い。体感と計測の間には39ポイントの乖離がある。
ここで疑問が残る。委譲型なら同じ罠を避けられると言えるのか——正直、これは検証できていない。仮説として考えられるのは、①②のような補完・対話型は人間の思考の流れにAIの提案が割り込む形で文脈の分断を発生させるのに対し、④委譲型はIssue単位でまとまった文脈を渡し切ってから結果だけを受け取るため、人間側の作業フローが分断されにくい、という違いだ。ただしこれは筆者の推測であり、METRのような厳密な検証を経た主張ではない。この問いには、この後も明確な答えを出せていない。
利用型を分けないと議論がかみ合わない
「AIで何%速くなるか」という問いが空回りするのは、利用型を混同しているからだ。筆者がこのプロジェクトの経験から整理した作業フレームワークとして、AIコーディングツールの使い方を6つに分類してみた。これは外部で確立された分類ではない。AI導入時にボトルネックがどこへ移るかを見分けるための、実務上のレンズとして使う。
| 型 | Humanの役割 | AIの役割 | 粒度 | 研究 |
|---|---|---|---|---|
| ①補完型 | 実装者 | 補完 | 行・関数 | 豊富 |
| ②対話型 | 質問者 | 回答 | Q&A | 少ない |
| ③レビュー型 | 生産者 | 評価 | 成果物 | 少ない |
| ④委譲型 | 指示者 | 計画+実行 | Issue | 少ない |
| ⑤自律型 | 目標設定者 | 計画+実行+判断 | 機能・目標 | ほぼなし |
| ⑥並列型 | 方向付け | 並列実行 | プロジェクト | 実験1例 |
ここで注意したいのは、①〜③と④〜⑥では軸が違うという点だ。①〜③は人間とAIの責任分担がどこまで踏み込むかというグラデーションだが、③から④への移行は地続きのステップアップではなく、人間が手を動かすモードからAIが計画・実行を主導するモードへの、アーキテクチャごとの断絶だ。さらに⑥並列型は責任分担の軸ではなく「同時にいくつ走らせるか」という運用形態の軸で、④委譲型を複数並列で走らせても⑥になるし、⑤自律型を複数走らせても⑥になる。表としては便宜上6つ並べているが、実際には2つの異なる軸が混在している。
自分がどの型にいるか、先に確認しておこう。 コードを書きながらタブキーで補完を受けているなら①補完型、「〜はどうすればいいですか？」と聞いているなら②対話型、自分で書いたものをAIに見せてフィードバックをもらっているなら③レビュー型だ。「このIssueを実装して」とIssue単位で委ねているなら④委譲型、「この機能を作って、設計から任せる」と渡しているなら⑤自律型、複数のAIが同時に別々のIssueを処理しているなら⑥並列型になる。本稿はここから、筆者がこの75日間主に運用していた④委譲型を中心に見ていく。
既存の研究がほぼ測定しているのは①と②だ。④以降はデータがほとんどない。委譲型エージェントをGitHub公開OSSリポジトリに導入した効果を分析した研究（Agarwal, He & Vasilescu, arXiv:2601.13597, MSR 2026）では、コミット数+36.3%・追加LOC+76.6%という正の効果が報告されている。ただし静的解析警告+17.7%・認知的複雑性+34.9%という品質劣化も同時に記録されており、一面的に読むべきではない。これは公開OSSリポジトリでの研究であり、非公開・特定ドメインのコードベース（本プロジェクトを含む）にそのまま一般化できるとは限らない。
興味深いのは、AIツールを作っているAnthropicやOpenAI・Googleの3社が、自社の開発では④委譲型止まりで完全自律型は使っていないことだ（Anthropic社内エンジニア132名調査、2025年）。設計・プランニングの最終判断は人間が担い続けている。
委譲型から先で起きること — 両方向のレバレッジ
①②補完型・対話型は「Human自身の作業時間が短縮される」という速度の改善だ。Humanが主体でAIがアシストする。④委譲型から先は構造が変わる。Issueを渡せばAIが計画・実装・テスト・PRまで実行する。Humanが次のIssueを考えている間にAIが前のIssueを進める。
これは厳密には「速度とは無関係の別次元」ではない。リトルの法則（L = λW）に従えば、並列に処理できる仕掛かりの数が増えれば、単位時間あたりの完了量（スループット）は上がる——これも広い意味では速度の一種だ。より正確に言うと、変わったのは1タスクの処理速度ではなく、Humanが実行のボトルネックにならずに同時に持てる仕掛かりの数だ。前節で留保したMETRの問い（委譲型は同じ罠を避けられるか）にはまだ答えていない。以下は、たとえ1タスクあたりの速度がMETRの実験と同様に改善していなかったとしても成立する話として読んでほしい。
このプロジェクトでは75日間、ClaudeCodeとCodexを委譲型で走らせた結果:
- Issue起票: 486件
- クローズ: 336件
- 本番コード: 約58,000 LOC
- テストコード: 約24,000 LOC
- 従来開発換算: 4〜5人月相当のボリューム（生産性の量ではなく、仕掛かりの量の見積もり）
少なくとも自分の運用では、補完型のCopilotだけでこの量の仕掛かりを同時に持つのは現実的ではなかった。
ここで踏んでおくべき区別がある。METRが問題にしたのは「自分が速くなったと感じる」という主観的な知覚だった。ここで言う「4〜5人月相当」は主観的な体感ではなく、Issue数・LOCという外形的に数えられる量であり、種類が異なる測定だ。とはいえ、この数字が「価値」を測っていないという弱点は残る。Anthropicの社内調査でも、Claude支援タスクの約27%は「AIがなければ着手されなかった潜在タスク」だったと報告されている（自社調査・自己申告ベース——これも同種の弱点を持つ出典であることは付言しておく）。
また、この数字が示すのは処理された作業の規模であり、品質を示すものではない。バグ率・技術的負債の増減・複雑性の変化はこのプロジェクトでは追跡しておらず、それは本稿の限界である。前節のAgarwalらの研究でも認知的複雑性+34.9%という品質面のコストが報告されており、自分のコードベースで同様のコストが生じていないとは断言できない。
このレバレッジは悪い方向にも効く。Issue仕様が曖昧だとAIは解釈して実装し、間違った解釈のまま全速前進する。後から気づいたときには大量のコードが積み上がっている。これは補完型では起きにくい規模の損失だ。ルールが間違っていれば全タスクに一貫して適用されるし、技術的負債もスケールする。レバレッジは方向性を増幅する——正しい方向なら速く遠くへ、間違った方向なら速く深みへ、というのが感覚としては近い。実際にどちらに転んだかは、次の節で見るボトルネックの実測が答えの一部になる。
75日の実測とボトルネック
75日走らせて、ボトルネックがどこにあるかが見えてきた——ただし、これは単独オペレーターである私1人のプロジェクトにおける観測であり、チーム開発にそのまま当てはまるとは限らない。複数人のチームなら、Issue投下はチームで分担されるため、この構造は成立しない可能性が高い。Issueを投下する私自身のスループットが上限になっている。
「4〜5人月相当のボリュームがあった」ことと「ボトルネックは私の意思決定スループットだった」ことは矛盾しない。前者は同時に存在した仕掛かりの量、後者はその仕掛かりが検証・マージまで完了する速度の話であり、別の変数だ。検証されないまま積み上がる仕掛かりの一部は、生産性ではなく負債の在庫になっているはずだ。どれだけの割合がそうなっているかは、後述するPR acceptance rateの数字が一つの手がかりになる。
「並列化で壁時計時間はO(√E)に短縮されるが、累積人的労力はO(E)のまま変わらない」— Jacky Liang, arXiv:2603.27438「The Novelty Bottleneck」, 2026年3月。「10倍速い」と「人員1/10」は数学的に別の主張だ。
この歪みは、おそらく筆者のプロジェクトに限った話ではない。LinearBの2026年レポート（810万PR・4,800団体調査。ただし対象は委譲型に限定されたデータではなく、AI生成PR全般の統計である点には留意）は、AI生成PRの初回レビュー待ち時間が人間作成PRの4.6倍に延びている一方、レビューが始まってからはむしろ2倍速い（194分 vs 252分）ことを示している。コードを作る速度と人間がレビューできる速度は別の話だ。
このプロジェクトの現在のKPI（2026-07-02時点）:
| KPI | 値 | 意味 |
|---|---|---|
| PR acceptance rate | 79.5% | AI提出PRのうちマージされた割合 |
| PR平均latency | 7.5h（中央値2.6h） | PR作成→マージまでの時間 |
| Issue cycle time | 平均14.9h（中央値6.4h） | Issue投下→クローズまでの時間 |
| Claude session使用率 | 23% | 直近セッションの消費状況 |
PR latencyの平均7.5hに対して中央値2.6hという開きは、一部のPRが長時間止まっていることを示している。レビューが追いつかない場面がすでに発生しており、これがボトルネックの実測値だ。
⚠️ このPR acceptance rate（79.5%）は筆者自身の受け入れ基準による数字であり、外部審査を経た客観的な品質保証ではない。人間だけで開発した場合のPR受け入れ率という比較基準は持ち合わせていないため、79.5%が高いか低いかを判断する材料は正直に言ってない。少なくとも100%ではないという事実だけはここに書いておく。単一プロジェクト・単一オペレーターの観測値として読んでほしい。
測るべきは、AIの速度ではなく人間の詰まりだ
だから、私の答えは「AIエージェントは常に開発を10倍速くする」ではない。変わったのは、1タスクの速度よりも、1人が同時に動かせる作業範囲だ。ただし、その範囲が広がるほど、仕様の甘さ・検証の甘さ・レビューの手薄さも大きくなって返ってくる。ボトルネックは消えたのではなく、Humanの意思決定スループットに移動した。
自分がどの型でAIを使っているかは、前節のセルフチェックで確認した通りだ。型を一段上げること自体は、今の課題を解決しない。むしろ先に必要なのは、今いる型のままHumanのボトルネック（意思決定・レビュー・仕様確定にかかる時間）をどう減らすかだ。Issue仕様のテンプレート化、テストの自動化による判断コストの引き下げは、型を上げるよりも先に効くはずだ、というのが今の実感だ。
Anthropicの研究者Nicholas Carliniは、16エージェントで約2週間かけてCコンパイラを構築した実験（Anthropic Engineering Blog, 2026年2月）で「タスク検証器がほぼ完璧であることが重要だ。そうでなければClaudeは間違った問題を解いてしまう」と書いている。これは委譲型にも、そのまま当てはまる言葉だ。
AIエージェントが強くなるほど、最後に残るのは人間の判断だ。だから次に測るべきなのは「AIが何倍速いか」ではなく、自分がどこで仕様・レビュー・判断を詰まらせているかだ。そこを測らないまま自律度だけを上げると、速くなるのは生産性ではなく、検証されていない仕掛かりが積み上がる速度かもしれない。
本記事のプロジェクトデータは2026年7月2日時点。単独オペレーター（筆者1人）による観測であり、チーム開発への一般化は未検証。ベンダー自己評価数値（Devin等）は独立検証がないため参照していない。6型分類は筆者の作業フレームワークであり、確立された外部タクソノミーではない。コード品質（バグ率・技術的負債・複雑性の変化）はこのプロジェクトでは追跡しておらず、生産性についての主張は稼働範囲とスループットの実測に限定される。
参照文献
- Peng et al. (2023) — GitHub Copilot RCT: arXiv:2302.06590
- Brynjolfsson et al. (2023) — コールセンター自然実験: NBER Working Paper 31161
- METR (2025年7月) — 熟練OSS開発者RCT: arXiv:2507.09089
- Agarwal, He & Vasilescu (2026) — AI IDEs or Autonomous Agents?（MSR 2026）: arXiv:2601.13597
- Liang (2026) — The Novelty Bottleneck: arXiv:2603.27438
- LinearB 2026 Software Engineering Benchmarks Report (810万PR・4,800団体): https://linearb.io/resources/software-engineering-benchmarks-report
- Huang, Seethor, Durmus, Handa, McCain, Stern & Ganguli (2025) — How AI Is Transforming Work at Anthropic（132名調査）: https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
- Carlini / Anthropic 16エージェントCコンパイラ実験 (2026年2月): https://www.anthropic.com/engineering/building-c-compiler
