AI導入の失敗は、気づきにくい。プロジェクトが炎上するわけでも、品質がその場で崩れるわけでもない。誰も困っていないように見えるまま、投じた費用に見合う結果だけが、返ってこない。
今回取り上げるのは、そうした失敗のなかでも、とくに厄介なケースだ。設計も実装も倍の速さになり、報告される数字はどれも伸びている。それなのに、肝心の納期だけが縮まらない。しかも、どれだけ試行錯誤を重ねても、改善されない。
たったこれだけのことで、AI投資は成果に結びつかなくなる。思いつきで言っているのではない。GoogleのDORAは2025年の調査で「AIは開発を加速するが、その加速が下流の弱点を露呈させる」と報告している。開発者22,000人規模のテレメトリー分析でも、プルリクエストのレビュー時間の中央値は441%増加していた。
そしてこの構造は、40年以上前に製造業で解明されている。以下、この失敗がどう進行したのかを順に見ていく。
AIで設計も実装も速くなったのに納期が縮まらない失敗が、どう進行し、なぜ増員や並列化では解決しないのか。そして、どの順序で手を打てば解消するのかがわかります。
AI駆動開発を始めて、半年。設計書のドラフトはAIが書き、実装のスピードも明らかに上がった。現場からは「どちらも体感で倍は速い」という声が上がっていた。プルリクエストの数も、生成されるコード量も、月次レポートの数字は右肩上がり。
ところが、案件ごとの納期を振り返ると、導入前と変わっていなかった。
経営側から見れば、これは理解しがたい状況だ。AI利用料を払い、現場は「速くなった」と言い、生産性の数字も伸びている。にもかかわらず、納期は一日も短縮していない。
現場に確認すると、返ってきたのは「レビュー待ちが溜まっていて」という答えだった。作られたものは確かに増えていた。ただし、それは世に出たのではなく、レビューを待つ列として積み上がっていただけだった。
この時点で見えていた数字を並べると、こうなる。設計書の作成期間は短縮、生成コード量は増加、プルリクエスト数は増加、現場の体感速度も向上。すべて改善している。唯一動いていないのが、着手からリリースまでの期間、つまりリードタイムだった。
納期が短縮されなかった理由は、ここにある。設計と実装がどれだけ速くなっても、承認を通らないかぎり次の工程へは進まない。着手からリリースまでの時間が変わらない以上、納期は前倒しできない。
「納期が縮まらないなら、もっと速く、もっと良いものを作らせればいい」——この判断は自然だ。実際、多くの現場が同じ方向に進む。
これまで人が手で書いていた部分も、AIに任せるようにした。一人あたりが出すプルリクエストの数は増え、AIの利用料も上がった。納期は変わらなかった。
複数のタスクを同時に流し、実装のスループットをさらに引き上げた。だが、並行して上がってくるプルリクエストは、それぞれ別の機能で、別の設計意図を持つ。レビュアーは一件ごとに頭を切り替えることになり、一件あたりに要する時間はむしろ伸びた。納期は変わらなかった。
レビューで指摘が多いから遅いのだ——そう考えて、指示の出し方を練り直し、コーディング規約や設計方針をAIに読み込ませた。指摘は、確かに減った。だが、レビュアーが読む量は減らない。むしろ生成量が増えたぶん、読む総量は増えていた。納期は、やはり変わらなかった。
三つとも、レビューの手前で完結する打ち手だった。作る量を増やし、成果物の品質を改善した。だが、レビュアーが一日に処理できる量は考慮していなかった。ここまで来て、ようやく「そもそも実装が問題なのか」という問いが出てくる。
この構造には名前がある。制約理論（TOC：Theory of Constraints）だ。イスラエルの物理学者エリヤフ・ゴールドラット博士が提唱し、1984年の小説『ザ・ゴール』で広く知られるようになった経営科学の理論である。
その主張は単純だ。「つながり」と「ばらつき」のある仕事の流れには、必ずどこかに全体の産出量を決めている制約（ボトルネック）が存在する。そこに集中して改善しない限り、全体の成果は増えない。
ゴールドラット博士はこの場所を当初「ボトルネック（瓶の首）」と呼んだ。瓶から流れ出る液体の量は、瓶をどれだけ大きくしても、注ぎ口の細さで決まってしまう。仕事の流れにも同じ因果が働いている、という指摘だ。その後、詰まりの原因が機械の処理能力のような物理的要因だけでなく、人の能力・意思決定・組織のルールといった広い要因でも起きるため、「制約（Constraints）」という言葉が使われるようになった。
この事例で起きていたのは、制約の移動だ。AI導入前、制約は製造工程——コードを書く工程——にあった。AIがそこを解消した。しかし制約は消えたのではなく、人によるレビューへ移っただけだった。
ここで言うレビューとは、レビュアーがコードを読んでいる時間のことではない。依頼してから順番が回ってくるまでの待ち時間、指摘を受けて直し、もう一度並び直す往復まで含めた工程全体を指す。AI時代に効いてくるのは、コードレビューそのものの速さより、この待ち行列のほうだ。
ここで見落とされやすいのが、設計の扱いだ。設計工程は、そもそも制約ではなかった。設計書が早く上がれば、その分だけ実装が早く始まり、レビュー待ちの行列に並ぶものが早く増える。制約の上流をどれだけ速くしても、増えるのは行列の長さだけである。
誤解のないように書いておくと、設計をAIで速くすること自体には価値がある。手戻りが減り、着手が早まり、検討の幅も広がる。ただし納期短縮という目的に対しては、そこが制約でないかぎり効果は限定される。同じ改善でも、制約に当たったかどうかで意味がまるで変わる。
後工程についても同じことが言える。テストの自動化やリリース作業の効率化も進んでいたが、そこも制約ではなかった。この事例で起きていたことを図にすると、次のようになる。
円の大きさは、その工程が1日にこなせる量を表しています。工程の時間が短縮されれば円は大きくなりますが、流れが細くなっている場所より多くは、アウトプットに出ていきません。
この移動は、実際に観測されている。GoogleのDORAが2025年に公表した調査では、AI導入とスループット（こなせる量）の間に正の関係が確認された一方、ソフトウェアデリバリーの安定性とは引き続き負の関係にあることが報告されている。同じくDORAは、生成の段階で節約された時間が、監査と検証の作業に再配分されているという分析も示している。
下流で何が起きているかも、数字がある。開発生産性計測ツールを提供するFaros AIが22,000人規模の開発者のテレメトリーを分析したところ、プルリクエストのレビュー時間の中央値が441%増加していた（同社の前年データセットでは91%増）。あわせて、プルリクエスト1件あたりのサイズが51.3%増加している。
DORAが開発生産性の全体傾向を示しているとすれば、Faros AIの数字は、その傾向がどの工程で何として現れているかを示している。二つを重ねると、行き先はひとつしかない。加速の代償を引き受けているのは、レビュー工程だ。
この事例には、もう一段の落とし穴がある。行列が長くなり続けると、現場は無意識に処理を軽くして帳尻を合わせようとするのだ。
「レビューが遅いから納期が守れない」。自社のPMから納期を問われ、承認基準を緩め、一部はレビューなしでマージするようになった。行列は短くなった。進捗は、初めて改善した。
しかし後工程で差し戻しが増え、戻された分が、またレビュー待ちの列に並んだ。
ここで起きているのは、単なる品質の低下ではない。制約を軽くしたつもりが、制約に戻ってくる仕事を増やしていた。差し戻された変更は、もう一度レビューの列に並ぶ。レビューを緩めた分だけ、あとで同じ列がまた伸びる。
注意したいのは、この判断の引き金だ。現場が手を抜いたわけではない。「AIを入れたのに、なぜ納期が縮まらないのか」——上から降りてくるこの問いが、承認基準を緩めさせている。しかもその問い自体は、正当だ。制約を放置したまま納期だけを求めれば、現場に残された手は二つしかない。レビュアーを増やすか、レビューを緩めるかだ。前者にはコストがかかる。残るのは、後者だけだった。
先ほどのFaros AIの分析では、レビューを経ずにマージされるプルリクエストが31%増加していることも報告されている。同じ逃げ道が、この事例に限らず選ばれているということだ。
これは制約の解消ではない。レビューを緩めただけだ。DORAが観測した「スループットは上がるが、安定性は下がる」という組み合わせは、この構図と整合している。速さの代金を、あとから差し戻しと手戻りとして支払っているにすぎない。
TOCには「5つの集中ステップ」という手順がある。この事例で効かなかった打ち手①〜③は、いずれもこの手順を飛ばしていた。正しい順序は次のとおりだ。
工程ごとに待ち時間を測り、行列ができている場所を一つ特定する。この事例では、実装ではなくレビューだった。ここを間違えると、以降の改善はすべて空振りになる。
レビュアーの時間を、人にしか判断できないことだけに使わせる。書式・命名・明らかな不具合といった機械的な指摘は、AIによる一次レビューで人の手前に潰しておく。ただしこれは、人のレビューをAIに置き換えることではない。置き換えれば、打ち手④と同じ結果になる。
制約とは、レビュアーが一度に読み切れる量のことだ。実装側は、その一回分に収まる大きさで出す。AIに全速力で書かせるのは構わないが、出てきたものをまとめて列に流さない。Googleの開発者向けガイドでも、変更を小さくすると早く、かつ深くレビューされることが利点として挙げられている。
ここで初めて増員や体制変更を検討する。レビュー担当のローテーション、レビューできる人の育成など。費用を払ってでも納期を優先する判断であり、選択肢のひとつだ。品質を差し出した打ち手④とは違う。ただし①〜③を先に済ませないと、必要以上にコストを支払うことになる。
レビューの詰まりが解ければ、制約は次の場所へ移る。テスト環境、受入確認、あるいは発注者側の意思決定。制約は消えず、移動し続ける。定期的にどの工程がボトルネックになっているか見直す必要がある。
補足すると、②と③を飛ばして④に向かう判断は、待ち行列理論の観点からも不利になりやすい。処理する側の稼働率が100%に近づくほど、待ち時間は比例ではなく非線形に悪化することが知られているためだ。高速道路が混みはじめると、前の車が軽くブレーキを踏んだだけで後続がずるずると渋滞するのと同じ現象で、行列に入ってくる量だけを増やす打ち手は、この悪化を加速させる。
この事例が示しているのは、AIが期待外れだったということではありません。AIは実際に設計工程や実装工程を速くしました。問題は、速くした工程が制約ではなかったことです。
発注する側として、確認すべき視点を整理します。
| 確認すべき視点 | 見るべきポイント |
|---|---|
| 制約（ボトルネック）の位置 | AI導入後、いま待ちが発生しているのはどの工程か、把握できているか |
| 成果の測り方 | 作った量ではなく、リリースできた範囲と納期で見ているか |
| 手の打ちどころ | その改善は、制約になっている工程に対して行われているか |
| 品質 | 納期と引き換えに、品質を犠牲にしていないか |
この視点を持つだけで、「AIを入れたのに速くならない」という漠然とした不満は、「どこがボトルネックになっているのか」という具体的な問いに変わります。
AI駆動開発は、開発全体を一様に速くするわけではありません。
増員や追加投資を決める前に、まずこの問いに答えられるかどうか。それが、AI時代の発注者に求められる視点ではないでしょうか。
その原因はAIではなく、制約の場所を見誤っているだけかもしれません。
まずは工程ごとの待ち時間と納期を、一緒に確認してみませんか。