■ 1. AI駆動開発の全体像
- AI駆動開発とは:
- 要件定義、設計、実装、テストといった開発プロセス全体にAIを組み込むアプローチ
- 人間が判断と監督を担いながら開発を進める
- 実装速度の飛躍的向上:
- 実装プロセスにおけるAIを用いたコーディングはここ1年で大きく進歩した
- コードを書くスピードは飛躍的に上昇した
- リリース日数は変わらないという実感:
- 実装は速くなったのにリリースまでの日数はあまり変わっていないと感じる声がある
- 従来指標の限界:
- プログラムの行数やPR数だけでは変化を捉えきれない
- 負荷が要件や設計の意思決定、レビューやテスト、AIを監督する作業へ移り始めている
- 変わったのはボトルネックと測り方:
- 開発のボトルネックと生産性の測り方そのものが変わり始めている
- 第1回の構成:
- 上流、下流、認知負荷、開発指標の4つの観点から開発全体の変化を見る
■ 2. コード生成だけが先に高速化
- AIツール利用の普及:
- JetBrainsの開発者調査では85%がAIツールを日常的に利用している
- DORAの2025年レポートでは業務でAIを利用する技術者が90%に達した
- MCPサーバーの登録数は2026年8月時点で7万件を超えた
- OpenAIの社内開発事例:
- 3人のエンジニアがCodexを活用し、5カ月で約100万行のコードと約1,500件のPRを生み出した
- 人間はコードを直接書かず、AIへの指示や成果物の確認に注力している
- 組織全体の作る速度の向上:
- Faros AIは22,000人の開発者、4,000以上のチームを分析した
- AI利用が増えた組織では開発者あたりのエピック完了数が66%増加した
- タスクスループットは33.7%増加した
- レビュー側の負荷増大:
- 同じ調査でレビュー着手までの時間は156.6%増加した
- レビューに要する時間は441.5%増加した
- 負荷の上流と下流への移動:
- 現在起きているのは開発全体の高速化ではなく、実装だけが先に高速化した状態
- 負荷は上流と下流へ移動している
- 上流と下流の相対的な重要性の上昇:
- 何を作るべきかを決める上流の重要性が相対的に高まる
- 生成されたものが正しいかを確かめる下流の重要性が相対的に高まる
- 同時に扱える仕事が増えることで開発者の認知負荷も高まる可能性がある
■ 3. 上流工程: 意思決定の重み
- 上流工程自体は遅くなっていない:
- Vella & Blincoeの調査では設計に費やす時間はわずかに減少している
- 上流はAIに委譲できていない:
- Jellyfishの2026年レポートではAIの利用用途はコードを書くが53.1%
- 要件分析は35.8%、仕様作成は24.2%にとどまる
- 曖昧さがコードとして返る:
- 人間は曖昧な仕様を渡されるとAかBかを質問して止まることがある
- AIエージェントは足りない前提を推測し、それらしい実装を生成できる
- 上流の曖昧さは質問ではなく、動いてしまうコードとして返ってくる可能性がある
- 誤った判断も高速に実装される:
- 実装コストが下がるほど、誤った要求や設計判断も高速に実装できるようになる
- 重要なのは仕様書の量ではない:
- 要求や制約を具体化することが重要
- AIに任せる判断と人間が持つ判断を切り分けることが重要
■ 4. 下流工程: 確かめる仕事へのシフト
- 判断する仕事の増加:
- コード生成が速くなるほど、この変更を本当に通してよいのかを判断する仕事が増える
- AI生成PRの低い受理率:
- LinearBによる810万件規模のPR分析でAI生成PRの受理率は32.7%
- 人間が作成したPRの受理率は84.4%
- AIがコードを書けば終わりというわけではない
- 時間配分のシフト:
- Vella & Blincoeの研究では82%がコードを書く時間が減ったと回答した
- レビューでは40%、テストでは42%が以前より時間を使う方向に変化した
- 作る仕事から確かめる仕事へのシフトは統計的にも確認されている
- レビューの性質の変化:
- これまでのレビューは人間が書いたコードを別の人間が読む工程だった
- AI駆動開発では大量に生成されるもっともらしいコードを検証する工程へ変わりつつある
- 検証の基準は、要求や設計意図に照らして本当に正しいかどうか
■ 5. 新しいボトルネックとしての認知能力
- 並列作業の増加:
- エージェントを使えば一つひとつの作業時間は短くなる
- あるエージェントに実装を依頼しながら、別の出力やテスト結果を確認できる
- 複数のPRをレビューする進め方が可能になる
- 判断対象とコンテキストスイッチの増加:
- 手を動かす負荷は減る一方、判断対象とコンテキストスイッチは増える
- 開発者体験の悪化:
- Vella & Blincoeの研究では84%が生産性の改善を感じた
- 開発者体験が悪化した参加者は14%から27%へ増加した
- Triple Debt Model:
- Margaret-Anne Storeyが長期的なソフトウェアの健全性から問題を整理したモデル
- Technical Debtはアーキテクチャやコード品質に蓄積する負債
- Cognitive Debtはシステムに対する人間の理解や推論能力が失われる負債
- Intent Debtは目的、制約、仕様、設計判断など意図が残らない負債
- 理解が形成されにくい構造:
- AIが生成するコードでは人間が実装過程を経験しない
- なぜこの構造なのか、どこを変えると何が壊れるのかという理解が形成されにくくなる
- 人間側のスケール限界:
- AIが並列実行できるタスク数は増えても、人間が理解し判断できる量は同じ速度で増えない
■ 6. AI時代の生産性指標
- コード量と品質の非同一性:
- コード量が増えていることと、コードベースが良くなっていることは同義ではない
- 従来指標の失効:
- AIによって仕事の形が変わった以上、時間、行数、コミット数だけでは生産性を測りにくい
- 見るべき指標:
- 要求からリリースまでのリードタイム、レビュー待ち時間
- 手戻り、障害
- 最終的にどれだけ価値を届けられたか
■ 7. まとめ
- 本質的な変化:
- AI駆動開発の本質的な変化は単なるコーディングの高速化ではない
- 実装コストが下がった結果、ボトルネックは上流の意思決定、下流の検証、人間の認知能力へ移動した
- これから重要になること:
- AIにどれだけコードを書かせたかではない
- 何を作るべきかを正しく決め、生成物を検証できたか
- チームが理解可能な状態を維持しながら価値へ変換できたか
- 開発者の役割の変化:
- 開発者の仕事はコードを書く実装者から重心を移しつつある
- AIに方向を与え、正しさを判断し、開発全体を監督する役割へ向かう
- 測り方の再設計:
- 開発方法だけでなく、生産性の測り方も再設計する必要がある