17:16 - 18:22

規模拡大のボトルネックと、作れるか・作るべきかの判断

ここまで、アイデアの調査、設計、実装、開発中の検証、CI、レビュー、保守という流れを見てきました。最後に話者は、この流れにはまだ残っている段階があると述べます。たとえば、モニタリング（monitoring）です。

ただし、話者はこの場面でモニタリングの具体的な方法や指標までは説明していません。したがって、ここで確認できるのは「開発が終わった後も、ソフトウェアを見守る段階が残る」という点です。エージェントがコードを速く作れるようになっても、ソフトウェア開発の全体が自動的に終わるわけではありません。

生成が速くなると、制約が移る

エージェントによる生成が速くなると、次の問題が目立つようになります。コードを書くことではなく、そのコードを安全に検証し、運用し、どの仕事を選ぶかという問題です。

話者は、規模を拡大したときの制約として、次のものを挙げています。

インフラストラクチャー（実行に必要な計算資源や共有基盤）
CI（変更をビルドし、テストする共有自動化）
検証
実験
意思決定

ここでいうボトルネック（bottleneck）は、システム全体の処理量を制限する箇所です。たとえば、エージェントが一時間に100件の変更を作れても、CIが一時間に20件しか処理できなければ、全体の流れはCIに制限されます。生成能力だけを増やしても、後ろの段階に待ち行列ができるだけかもしれません。

図：エージェント型SDLCの段階と、再利用できるプラットフォームの構成要素。 動画の17分23秒付近で見る

この図は、ライフサイクルの各段階と、これまで説明された六つのプラットフォーム構成要素を結び付けています。図にはモニタリングも示されていますが、モニタリングの中身はこの資料からは分かりません。重要なのは、実装だけでなく、その前後の段階を含む一つのシステムとして考えていることです。

モニタリングは別の検証ループです

開発中の検証と、本番環境でのモニタリングは、同じものではありません。開発中の検証は、出荷前に「決められた条件を満たしているか」を調べます。一方、本番でのモニタリングは、出荷後に「実際の環境でどう動いているか」を知るためのものです。

補足・例：スタジアムの送迎機能

ワールドカップのスタジアムで、混雑を避けた乗車場所を案内する機能を考えます。この機能が、開発中のコード検査、画面の比較、バックエンドとの連携確認を通過したとします。それでも、出荷した時点で仕事がすべて終わったとは限りません。

出荷前の証拠は、用意した検査に合格したことを示します。モニタリングは、本番で機能が想定どおり使われているかを調べる、次のループです。この例は、検証を増やせばよいという意味ではありません。開発中の証拠と、運用中に得られる情報は、答える質問が違うという意味です。

共有資源が新しい制約になる

ソフトウェア工場の出力が増えると、共有資源への負荷も増えます。インフラは、エージェントの実行環境や関連する処理を支えます。CIは、多くの変更を同じ検査基盤で処理します。検証には、コード、画面、複数サービスの連携など、それぞれの確認が必要です。

さらに、実験にも限界があります。複数の案を作れても、すべての案を同時に試せるとは限りません。実験の環境、検証の時間、結果を読む人の時間には上限があります。つまり、生成の速度が上がるほど、後の段階の容量（capacity）が全体の速度を決める可能性があります。

図：インフラ、検証、実験、意思決定が、規模拡大時のボトルネックとして示されています。 動画の17分34秒付近で見る

この図は、問題の中心が「エージェントは作れるか」から「システム全体は次の段階を処理できるか」へ移ることを示しています。ここでの話者の主張は、個別の数字や特定の対策ではありません。生成を速くするだけでは、インフラ、CI、検証、実験、意思決定のどこかが新しい制約になる、という見方です。

「作れるか」から「作るべきか」へ

生成能力が低いときは、まず「これは作れるか」と考えます。エージェントやプラットフォームによって実装が容易になると、別の問いが重要になります。「作れるとしても、これは作るべきか」という問いです。

この二つは似ていますが、判断の対象が違います。

作れるか：必要なコードや環境を用意できるか。
作るべきか：限られた検証、実験、運用の資源を、この仕事に使う価値があるか。

補足・例：五つの案から二つを試す

スタジアムの乗車場所を案内する機能について、チームが五つの画面案を実装できるとします。しかし、実験と検証に使える容量は二つ分しかありません。

この場合、五つとも作れることは、五つとも作るべきだという結論になりません。チームは二つを選び、限られた実験の機会を使います。残りの三つを作らない判断は、実装能力の不足ではありません。検証と保守に使える資源を、より価値のある選択肢に配分する判断です。

この例から分かるように、ソフトウェア工場の目的はコードの量を最大にすることではありません。作ったものを検証し、運用し、学習できる範囲で、価値のある仕事を選ぶことです。話者が最後に示す転換はここにあります。AIによって「作れること」の範囲が広がるほど、最適化すべき対象は生成量ではなく、全体の価値になります。