# AIボトルネック：コードが速くなっても製品が速く届かない理由

*この記事はAIの支援を受けて執筆し、agenthouseチームが編集しました。イラストはAIで生成しています。*

[[ai|AI]]によって、ソフトウェアのコードを書くコストは下がり、スピードは大きく向上しました。多くのチームは、機能も同じスピードで顧客に届くと期待していました。しかし、ほとんどのチームはそうならないことに気づいています。その理由は、1984年に生まれたある考え方で説明できます。

![一列に並んだ五つの工程：中央の工程が光り、作業項目を次々と送り出し、その先の狭いゲートの前に積み上がっている（AI生成イラスト）](/assets/images/academy/the-ai-bottleneck/hero.webp)

## プロセスは最も遅い工程の速さでしか進まない

1984年、物理学者でありマネジメント思想家のエリヤフ・M・ゴールドラットは、経営難の工場を立て直そうとする工場長を描いた小説『ザ・ゴール』（*The Goal*）を出版しました。この本で紹介されたのが**制約理論（TOC）**です。その中心にある考え方はシンプルです。プロセスの各工程にはそれぞれのスループットがあり、システム全体は最も遅い工程、つまり制約以上の成果を出すことはできません。他の工程を速くしても効果はありません。ボトルネックの前に在庫が積み上がるだけです。

ゴールドラットはまずこの考え方を製造現場に適用しました。その後、プロジェクトマネジメントにも広げ、『The Phoenix Project』などの書籍によってITやソフトウェアデリバリーの世界にも取り入れられました。

## 仕事を前に進めるリズム

プロセスにはリズムがあります。リーン生産方式では、これを**タクト**（ドイツ語で「拍」を意味する言葉）と呼びます。仕事がある工程から次の工程へ進むべきペースのことです。ゴールドラットは同じものを、制約が叩き、他のすべての工程にペースを伝える「ドラム」として説明しました。

その合図は、ほとんど目に見えないことも少なくありません。料理が出来上がったことをホール係に知らせるレストランの厨房のベルや、列車に発車を許可する笛を思い浮かべてください。すべての工程が同じリズムで動くとき、プロセスは調和しています。

![厨房のカウンターに置かれた呼び出しベルと、発車する列車のそばの笛が、一本の共通のリズムラインでつながっている（AI生成イラスト）](/assets/images/academy/the-ai-bottleneck/takt.webp)

ソフトウェア開発がそうなることはまれです。ウォーターフォールでもアジャイルでも、完全にバランスの取れた流れは例外です。要件は滞り、レビューは溜まり、リリースはテスト待ちになります。

## AIが変えたこと：一つの工程だけが大幅に速くなった

生成AIが加速させたのは、チェーンのうちただ一つの工程、コードを書くことです。以前は数日かかっていた作業が、今では数時間、ときには数分で終わります。その結果、プロセスは両側から圧力を受けます。

**上流では、「何をつくるべきか」という問いが空白になります。** 実装がもはや制約でなくなると、インプットの質がはるかに重要になります。事業開発とプロダクトマネジメントは、これまで以上に速く、正確に顧客の本当のニーズを理解しなければなりません。そうしなければ、チームは誰も欲しがらず、誰もお金を払わない機能を効率よくつくることになります。速いコードは悪いアイデアを良くするわけではありません。悪いアイデアを早く世に出すだけです。

**下流では、新たなボトルネックが生まれます。** AIが生成したコードをレビューする開発者、テストマネージャー、アーキテクト、DevOpsエンジニアは、突然はるかに多くのインプットを評価しなければならなくなります。コードを書く工程は桁違いに速くなりましたが、レビュー、テスト、運用の工程はそうではありません。

結果は、ゴールドラットが予測したとおりです。仕掛かり中の仕事が新たな制約の前に積み上がります。コード生成で感じるスピードは、機能リリースの速さにはつながりません。保守しやすく、きちんと動くソフトウェアを今も重視している企業では、なおさらです。そして、その姿勢は正しいのです。

## 解決策：一つの工程ではなく、チェーン全体を調和させる

一つの工程をさらに速くしても、この問題は解決しません。必要なのは、すべての工程を同じ[[agentic|エージェント型]]の仕組みで支え、最初の市場仮説からリリースノートまで、各工程に明確な期待値を設定することです。私たちはこの仕組みを**エージェンティック・エンジニアリング・ハーネス**と呼んでいます。

**市場検証。** エージェントは、何かを引き渡す*前に*、チームが仮説を検証し、根拠を集め、プロダクトマーケットフィットに到達できるよう支援します。成果物は、ばらばらのアイデアではなく、構造化されたアーティファクトです。

**プロダクトマネジメント。** プロダクトマネジメントは、そのアーティファクトを意味のあるユーザーストーリーに落とし込みます。同じフレームワークを使うことで、各ストーリーは適切なスコープを持ち、テスト可能で、開発開始前に明確なDefinition of Ready（DoR）を満たします。

**開発とテスト。** テスト駆動開発（TDD）は、チーム独自のガバナンスルールとあわせて、ユーザーストーリーに直接ひもづけて計画されます。品質はレビューで見つけるものではなく、源流で組み込まれます。

**レビューと運用。** レビュアーはもはやゼロから始める必要はありません。合意された基準に沿ってすでにつくられた成果物を確認します。車検の検査員がラインの最後で待つのではなく、整備士の隣で一緒に作業するようなものです。

![リフトに載った車の下で、整備士と車両検査員が並んで作業している。そばにはチェック済みの項目が並ぶチェックリストがある（AI生成イラスト）](/assets/images/academy/the-ai-bottleneck/inspector.webp)

**ドキュメントと市場投入。** AIを活用したドキュメントは、作業の一部として作成されます。プロダクトマーケティングとサポートチームは、製品の変化と同じペースで正確な資料を受け取れます。

すべての工程が同じリズムで動くようになって初めて、AIによるコーディングで得たスピードが顧客に届きます。

### 18秒でわかるストーリー

[![アニメーション：検証工程に仕事が届かない一方でレビューの前に仕事が滞り、エージェンティック・エンジニアリング・ハーネスがすべての工程に同じリズムを与えるまでを描いています](/assets/images/academy/the-ai-bottleneck/animation-poster-ja.webp)](/assets/motion/the-ai-bottleneck/index.ja.html)

[アニメーションを別ページで開く（18秒、音声なし）](/assets/motion/the-ai-bottleneck/index.ja.html)

## 導入の第一歩

このハーネスのすべての要素は、**agenthouseのオープンソースのエージェンティック・エンジニアリング・フレームワーク**で利用できます。市場検証からデリバリー、サポート、学習まで、再利用可能なロール、スキル、プロダクトプロセスを提供しています。

[GitHubでエージェンティック・エンジニアリング・フレームワークを見る](https://github.com/agenthouse-org/agentic-engineering)