9月29日、River Lynn Baileyが「AI tooling may have solved coding, but not solutions delivery」と題した記事を公開した。この記事では、AIコーディングツールが個人の開発速度を上げてもソフトウェアのリリース速度は改善されないという現象を、制約理論（Theory of Constraints）の観点から分析している。
「コードを速く書けるようになったのに、リリースが遅くなった」
AIコーディングツールを導入したチームで、ある共通パターンが観察されている。PRのマージ速度は上がり、コード量も増えた。だが数ヶ月後、リリースカレンダーを見ると変化がない——むしろ遅くなっている。
この現象を正確に予言した人物がいる。1984年に工場経営の本を書いた物理学者、エリヤフ・ゴールドラットだ。
ゴールドラットは40年前に見通していた
ゴールドラットが『ザ・ゴール』で提唱した制約理論（ToC: Theory of Constraints）の核心は単純だ。「どんなシステムにも、スループット全体を規定する制約（ボトルネック）が必ず1箇所存在する。そこ以外を速くしても、システム全体は速くならない。制約の手前に仕掛品が積み上がるだけだ」。
高速道路の合流車線を増やしても、橋が詰まっていれば都心到着は早まらない。この比喩がそのままAI時代のソフトウェア開発に当てはまる。
ゴールドラットの理論は既にソフトウェア業界に持ち込まれていた。David J. Andersonは2003年に著書でToCをソフトウェアデリバリーに適用し、2004年にMicrosoftで実践したプル方式は後にKanbanメソッドとして広まった。『The Phoenix Project』はこれをDevOps世代に伝えた。警告は書棚にずっとあった。
コード速度向上のデータは矛盾している
個人レベルの速度改善については、研究間で結論が割れている。
- GitHub Copilotの実験：55.8%の速度向上（ただし合成タスク）
- Microsoft・Accenture・Fortune 100企業での実地実験：26.08%の完了タスク増加
- METRのランダム化比較試験：AIありで19%遅くなった
最後のMETRの研究が特に興味深い。経験豊富なオープンソース開発者16名が自分のよく知るリポジトリで実際のタスクを実施したところ、AIなしの方が速かった。しかも彼らは事前に「24%速くなる」と予測し、終了後には「20%速くなった」と感じていた。実測は19%遅化、体感は20%向上という正反対の結果だ。
「感覚は信頼せず、計測せよ」——この教訓はコード速度だけでなく、ボトルネックの特定にも直接適用される。
組織レベルのデータは方向が一致している
個人速度の研究は割れているが、組織レベルのデータは揃って同じ方向を向いている。
- DORA 2024レポート：AI採用でindividual productivityは上昇、一方でデリバリースループットと安定性は悪化。2025年版ではスループットが回復したものの、不安定性はAI採用増加と共に上昇し続け、「AIは既存の強みと弱みを増幅するアンプ」と表現された。
- Faros AI（1万人以上の開発者のテレメトリ）：AI採用率の高いチームでレビュー時間が91%増加、PR規模が154%拡大。
- CircleCI（2800万件のCIワークフロー分析）：フィーチャーブランチのスループットは15%向上した一方、mainブランチのスループットは7%低下、mainブランチのビルド成功率は過去5年で最低の**70.8%**を記録。CircleCIは「コードを書くことはもはや制約ではない。レビュー、検証、インテグレーション、リカバリが遅延の蓄積場所だ」と結論した。
- AWS企業戦略チーム：AI加速によるコード量の増大が、旧来のスケール感で設計されたマージ・テスト・デプロイプロセスを圧倒しつつあると警告した。
コード量増加→レビュー負荷増大→マージ成功率低下→システム安定性悪化。制約が下流に移動している。
制約の候補は4つ
記事はボトルネックの移動先として4つの候補を挙げている。ただしこれらは相互排他ではなく、網羅的なリストでもない。あくまで計測の出発点だ。
① レビューと検証
Simon Willisonは元記事中で「ボトルネックはもはやコードを書く速さではなく、信頼できる人間がレビューに自信を持てる速さだ」と述べる。最も可視化されやすいキューだが、「声が大きい＝制約」とは限らない。
② プロダクト決定と仕様
Andrew Ngは元記事中で「チームは今や、何を作るかを決める速度より速くビルドできる」と主張する。計測データは存在しないが、現場からも同様の声が上がっている。
③ デプロイとインテグレーションのバッチング
レビューではなくデプロイバッチングが本当の制約という反論もある。CircleCIのmainブランチデータとAWSのパイプライン分析はこの仮説とも整合する。
④ 理解負債とコーディネーション
Anthropicの調査では、AIを使ってライブラリを学習したジュニアエンジニアの理解度テストのスコアが50%（AI利用）対67%（非利用）だった。完了時間の差はわずか約2分。「コードがシステムに入るのが人間の理解より速い」という理解負債（comprehension debt）はダッシュボードに現れるのが遅く、最も静かな候補だ。
診断のワナ：一番声が大きいところを制約だと思い込む
Bailey氏が特に強調するのは、業界でのデータの「エコーチェンバー」問題だ。AWSが引用する「77%の組織が1日1回以下のデプロイ」という数字はDORAのデータの再引用だ。FarosのPRレビュー数値はInfoQやLogRocketに転載され、ひとつのデータソースが独立した複数のエビデンスに見え始める。
加えて、誰が何を売っているかも確認すべきだ。レビューボトルネックという診断はレビューツールのベンダーと、デプロイバッチングという診断はデプロイ自動化ベンダーとセットで提示されている。唯一クリーンな製品が紐付いていない診断——プロダクト決定——は、計測データも存在しない。
ゴールドラットの答え：まず計測せよ
ゴールドラットは制約が移動した後の対処法も残している。Five Focusing Steps（5つの集中ステップ）だ。原典では "Identify → Exploit → Subordinate → Elevate → Repeat" と定式化されており、記事はこれをソフトウェアデリバリーに次のように対応させている。
- 制約を特定する（Identify the constraint） — 「アイデア→本番稼働」の全ステージをエンドツーエンドで計測する。最も声が大きいステージではなく。
- 制約を徹底活用する（Exploit the constraint） — 追加投資なしで制約ステージの出力を最大化する。例：レビューが制約ならPRを小さくする。
- 他の全工程を従属させる（Subordinate everything else） — 制約の前に仕掛品を積み上げないよう、速いステージを意図的に抑える。
- 制約を強化する（Elevate the constraint） — 安価な改善を尽くした後で初めて、実質的な投資を行う。
- 繰り返す（Repeat） — 制約が移動したら最初から始める。
「計測してからツールを買え」
Bailey氏の結論は明確だ。AIツールを導入してもデリバリーが速くならないなら、それはやり方が間違っているのではない。問題は制約がどこへ移ったかを把握していないことだ。
「アイデア→本番稼働」をステージごとに計測せよ——ディスカバリー、仕様化、コーディング、レビュー、インテグレーション、デプロイ、バリデーション。どのステージが全体を律速しているかを見つけ、そこを改善し、また計測する。
METRの研究の開発者たちは体感20%速くなりながら実測19%遅くなっていた。速度への感覚は今や信用できない。チームがボトルネックの名前を挙げるとき、それは計測から導いた名前か、それとも最も声が大きかったものの名前か。
詳細はAI tooling may have solved coding, but not solutions deliveryを参照していただきたい。
