なぜ、ループエンジニアリングの普及がウォーターフォール開発を復活させるのか？

はじめに

生成AIによるソフトウェア開発は、当初、自然言語で作りたいものを伝えれば、AIがコードを書いてくれる方向へ進むと考えられていました。厳密な仕様書や詳細な計画を先に作らず、生成された画面や動作を見ながら、その場で指示を追加していく開発です。しかし、AIコーディングエージェントを本格的な開発へ投入すると、事情が変わります。AIが実装、試験、修正を自律的に繰り返すループエンジニアリングでは、AIへ仕事を渡す前に、目的、作業範囲、設計方針、検証方法、完了条件、停止条件を明確にしなければなりません。

ループエンジニアリングという言葉は、2026年6月ごろから広く使われ始めました。AIへ一回ずつ指示を出す技能から、AIが継続的に作業できる仕組みを設計する技能へ、開発の重点が移り始めたことを表しています。名称には「ループ」とありますが、開発はアジャイルには進みません。AIの内部では高速な試行錯誤が行われても、その前提となる要求や設計を人間が先に決めているからです。ループエンジニアリングは、下流工程をAI化した、少人数の計画主導(ウォーターフォール)型開発へ近づいていきます。

ループがあってもアジャイルとは限らない

ループという言葉からは、試作品を作り、その結果を見て要求や設計を見直していく開発を想像しやすくなります。ループエンジニアリングにも、実装、試験、修正の繰り返しがあります。AIはコードを調査し、変更し、試験を実行します。試験に失敗すれば、原因を分析して修正します。ただし、そこで主に修正されるのは実装です。仕様が利用者の問題に合っているか、選んだ設計が適切か、そもそも作る価値があるかといった判断は、通常、AIの実装ループが始まる前に人間が行います。

仕様と受入試験が先に決まり、AIはそこへ到達するようにコードを修正します。開発全体として見れば、要求や設計を先に定め、その内容に従って下流工程を進める構造です。ウォーターフォールを、工程が一方向に一度だけ進む方法と考える必要はありません。重要なのは、上流で決めた内容が下流の作業を強く拘束することです。その意味では、AIの内部に何度ループがあっても、開発全体はウォーターフォール的になり得ます。

内側のループだけが速くなる

ループエンジニアリングには、AIの実装ループだけでなく、人間による設計の見直しや、利用者の反応を製品へ戻す仕組みも含まれます。したがって、ループエンジニアリングでは要求が変更されない、という話ではありません。問題は、AIの実装と、人間の判断を同じ速さで回せるかどうかです。AIによる実装、試験、修正は、数分から数時間で繰り返せます。一方、利用者の反応を確認し、関係者の意見を調整し、予算や製品方針を変更するには、数日以上かかることがあります。

AIが試作品をすぐに作り、利用者も即座に評価できる環境なら、人間側の判断も速くできます。その場合、AIはアジャイル開発を強化します。しかし、多くの組織では、利用者の観察、合意形成、投資判断まで同じ速さにはなりません。AIだけが高速化すると、人間が途中で判断する回数の割合は下がります。その結果、人間の仕事は、AIへ渡す仕様、制約、受入条件を事前に整える方向へ移ります。

自律稼働には詳しい事前条件が必要になる

AIエージェントへ長時間仕事を任せる価値は、人間が途中で逐一指示しなくても、作業が進むことにあります。ところが、人間とのやり取りを減らすほど、AIは途中で新しい情報を受け取れなくなります。仕様に矛盾があった場合、AIは人間へ確認する代わりに、与えられた情報からもっともらしい解釈を選ぶか、作業を停止します。未定義の例外が発生した場合も同様です。

そのため、自律稼働時間を延ばすには、開始前に与える情報を増やさなければなりません。目的や作業範囲だけでなく、変更してはいけない部分、既存設計で守るべき条件、優先順位、例外時の判断方法、試験方法、完了条件、再試行回数、人間へ確認する条件まで定める必要があります。自律性を高めるほど、途中の質疑応答は減ります。質疑応答を減らすほど、事前の設計と作業指示は詳しくなります。

OpenAIの内部実験では、人間がソースコードを一行も直接書かず、約5か月かけて百万行規模の製品を構築しました。当初3名、最終的に7名の技術者が、変更内容の確認や自動試験の仕組みを通じて、AIエージェントを誘導しています。そこで人間が担当したのは、ソースコードの置き方、作業規約、自動検査、評価方法、AIから参照できる情報環境の設計でした。自律化によって計画が不要になったのではなく、自律化を成立させるために、計画と検証の仕組みが必要になったのです。

AIは下流工程を置き換える

従来のウォーターフォール開発では、上流のアーキテクトやシステムエンジニアが、要件定義書、基本設計書、品質基準、試験方針を作り、詳細設計や実装を担当する社内チームや協力会社へ渡していました。下流チームは、渡された設計を基に、詳細化、実装、単体試験、不具合修正を行います。上流側は、完成した成果物と試験結果を確認し、設計どおりに作られているかを判断します。

ループエンジニアリングでも、基本構造は変わりません。要件定義書や基本設計書に相当するものが、設計文書、AI向け作業規約、タスク指示、自動試験、変更禁止範囲、停止条件へ変わります。AGENTS.mdは、その一例です。AIエージェントへ、プロジェクト固有の作業方法、使用する道具、検証手順、禁止事項などを伝えるためのファイルです。AIエージェントは、これらを受け取り、調査、実装、試験、修正を繰り返します。最後に、変更内容、試験結果、実行記録などを人間へ返します。

従来の下流チームや協力会社が、AIエージェントへ置き換わった構造です。AIの内部で何度修正が行われても、上流が仕事を定義し、下流が成果物を作り、上流が受け入れるという流れは変わりません。

下流からの異論も上流で先回りする

従来のウォーターフォール開発では、設計書に書かれていない問題を、下流の熟練者が補っていました。優秀な詳細設計者や実装者は、仕様に矛盾があれば質問します。既存機能への影響を発見すれば警告し、より保守しやすい構造があれば代案を出します。公式には下流工程であっても、質疑票、レビュー、会議、日常的な会話を通じて、上流の設計は修正されていました。ウォーターフォール開発が現実に成立していた理由の一つは、下流の人間が単純な命令実行者ではなかったことです。

AIエージェントも質問や提案はできます。しかし、疑問が生じるたびに停止して人間へ確認していては、長時間自律稼働させる意味が薄くなります。そこで、従来は下流から出ていた質問や異論を、事前に予測して設計へ組み込む必要が生じます。アーキテクトはAIとの対話を重ね、この仕様にはどのような解釈の余地があるか、既存設計と矛盾しないか、未定義の異常処理はないか、試験だけを形式的に通過する抜け道がないかを検討します。

AIは、実装を始める前には、仮想的な下流リーダーや設計レビュー担当者として使われます。設計が十分に固まった後には、実装者として使われます。AI時代の開発には、上流で設計を詰める反復と、下流で実装を直す反復があります。曖昧な要求を、実行可能で検証可能な仕様へ変える難しさは、上流側に残ります。

バイブコーディングとは反対方向へ進む

バイブコーディングとは、生成されたコードを十分に理解しなくても、動作結果を見ながらAIへ次の指示を出していく開発方法です。判断基準は人間のその場の感覚に残っています。出力を見て、気に入らなければ指示を追加します。事前に体系的な受入条件を作る必要はありません。成熟したループエンジニアリングでは、人間が不在でもAIが作業を続けられるように、判断基準を仕様、試験、制約、予算、停止条件として外へ書き出します。

バイブコーディングは、考えながらAIに書かせる方法です。ループエンジニアリングは、AIへ任せられるところまで考えた後で、仕事を引き渡す方法です。両者は、自然言語でAIへ指示し、人間がコードを一行ずつ入力しない点では似ています。しかし、開発に必要な理解と検証を、いつ行うかが異なります。ソフトウェア開発の難しさは、コードを文字として入力することだけではありません。曖昧な要求を解釈し、機能の境界を決め、既存システムとの整合を取り、異常処理を考え、検証可能な仕様へ変えることにあります。

コード入力が自動化されたことで、従来は実装作業の中に隠れていた難しさが表面に出てきます。その難しさを出力後の追加指示で処理するのがバイブコーディングであり、実行前に処理しようとするのがループエンジニアリングです。

人月がトークンへ置き換わる

ウォーターフォール開発では、上流の設計判断が、下流で必要になる人月を決めていました。仕様が曖昧であれば、質問、設計変更、実装のやり直し、試験項目の追加が発生します。機能の分け方が悪ければ、複数チームの調整が増えます。PMやアーキテクトは、この設計を下流へ渡した場合に何人月かかるか、どれほど手戻りが発生するか、予算と納期に収まるかを考えていました。

ループエンジニアリングでは、下流で消費される主な資源が、人月からトークンと計算資源へ変わります。トークンは、AIが読み書きする情報量の単位であり、AI利用費を左右します。曖昧な仕様は、AIが調べなければならない範囲を広げます。大きすぎる仕事は、AIが一度に扱う情報を増やします。弱い完了条件は、修正の繰り返しを増やします。複数のAIを使って、実装、レビュー、試験を分担させれば、呼び出し回数も増えます。

Anthropicが調査用のAIエージェントについて公表した計測では、単一のエージェントは通常の対話の約4倍、複数のエージェントを組み合わせた構成は約15倍のトークンを使用しました。コーディングの数値ではありませんが、AIを自律的かつ並列に動かすほど、費用が増えることを示しています。従来の「この設計を協力会社へ渡したら何人月かかるか」という問いは、「この設計をAIへ渡したら、どれだけのトークンと計算資源を使うか」という問いへ変わります。上流の曖昧さを、下流の資源投入によって吸収する構造は同じです。

アーキテクトの技術判断が原価判断になる

従来の大規模開発では、アーキテクトが技術構造を決め、PMが見積もり、要員、納期、契約、予算を管理するという分業が可能でした。AIを使う開発では、技術判断と原価判断の距離が短くなります。仕事の分け方、使用するAIモデル、AIへ渡す情報量、変更を許可する範囲、試験の範囲、再試行の上限が、そのままトークン消費量を左右するからです。一つのAIへ広い仕事を任せるのか、複数の案を並行して作らせるのか、毎回すべての試験を実行するのかを決めた時点で、費用のかなりの部分が決まります。

アーキテクトは、技術的に正しい構造を作るだけでは足りなくなります。その構造をAIに実装させるために、どれほどの探索が必要になるか、費用に見合う価値があるか、どこで作業を打ち切るかまで考える必要があります。役割分担が完全になくなるわけではありません。組織によっては、アーキテクトが技術的な範囲を決め、エンジニアリングマネジャーが予算と進行を管理し、プロダクトマネジャーが投資価値を判断するでしょう。

それでも、技術判断と原価判断を完全には切り離せません。費用超過の原因が、AIの単価だけでなく、仕事の分け方、試験方法、情報の与え方、終了条件にもあるからです。日本のSIerのように、上級システムエンジニアやPMが、要件調整、基本設計、協力会社管理、見積もり、品質管理を横断的に担当する組織では、AIの実行設計と利用費の管理も同じ人物へ集まりやすくなります。

人間の要員管理が減る代わりに、AIへ任せる範囲、実行予算、並列数、継続判断、成果物の受入を管理する仕事が増えます。アーキテクトは設計者であると同時に、AIへの発注者、工程設計者、原価判断の技術責任者、検収責任者になります。

超少人数のウォーターフォールが成立する

ループエンジニアリングによって復活するのは、大人数と大量の文書を前提とした、かつての開発体制そのものではありません。上流には、利用者の要求を理解し、技術構造を決め、AIと対話しながら仕様を詰め、受入条件を作れる少数の熟達者が残ります。下流では、多数の人間に代わって、AIエージェントが実装、試験、修正を繰り返します。顧客や利用部門から得た要求を、少人数のPM、製品責任者、アーキテクトが解釈します。アーキテクトはAIを設計の検討相手として使い、要求の矛盾、技術的な危険、異常処理、試験条件を洗い出します。

設計が固まった段階で、仕様と制約をAIエージェントへ渡します。AIは、その範囲内で高速に実装を繰り返します。開発全体では、上流から下流へ仕様を渡す計画主導型の工程です。AIの内部では、実装、試験、修正が高速に繰り返されます。アジャイル開発は、計画どおりに進めることより変化への対応を、契約上の受け渡しより顧客との対話を重視します。しかし、AIエージェントを長時間自律稼働させるほど、人間が途中で協議し、方向を変える機会は減ります。利用者を含む人間側の判断も同時に高速化できない組織では、自律稼働を可能にするための事前設計が、再び合理的になります。

復活するのは上流責任である

AI時代に復活するのは、昔と同じ工程表ではありません。上流で定めた情報が下流の生産を決め、その情報の品質について上流が責任を負う構造です。AIエージェントは、下流工程の速度を上げます。しかし、何を作るべきかを単独で決定する主体ではありません。要求を採用するかどうかは、価値判断です。価値判断には、その選択によって生じる利益と損失を引き受ける主体が必要です。

AIが要求案や仕様案を作れるようになっても、どの案を採用するかは人間が決めます。AIの能力が上がり、多数の案を生成できるようになるほど、人間が選択し、承認する仕事は増える可能性があります。完了条件が間違っていれば、AIは間違った状態へ効率よく到達します。停止条件が弱ければ、トークンを消費し続けます。仕事の分け方が悪ければ、複数のAIが矛盾する変更を同時に生成します。

AIが高性能になるほど、上流の問題設定能力が、開発全体の成果を左右します。ウォーターフォール開発では、上流の設計書に書かれた一行が、下流の何十人月を左右していました。ループエンジニアリングでは、上流の一行が、何百万トークンの消費と、大量の生成物を左右します。

まとめ

ループエンジニアリングは、AIが実装、試験、修正を繰り返すため、アジャイル開発の延長に見えます。しかし、AIの内部で主に修正されるのは、事前に決めた仕様へ適合するための実装です。要求、設計、受入条件、停止条件は、人間が上流で定めます。AIの実装だけが高速化し、利用者の観察、組織内の合意、投資判断が同じ速度で進まなければ、人間の仕事は実装途中の判断から、実行前の設計へ移ります。

従来は、上流のアーキテクトやPMが基本設計を作り、下流の社内チームや協力会社へ渡していました。ループエンジニアリングでは、その下流がAIエージェントへ置き換わります。人間の詳細設計者、実装者、試験担当者が減り、代わりにトークン、計算資源、AIによる反復が投入されます。上流の曖昧さを、下流の資源投入によって吸収する構造は変わりません。AIを長時間自律稼働させるほど、事前の仕様、制約、試験、停止条件を詳しくする必要があります。アーキテクトはAIを使って要求の穴を探し、異常処理を洗い出し、AIへ渡せる形まで設計を詰めます。

さらに、仕事の分け方、試験範囲、再試行回数といった技術判断が、AI利用費へ直接結びつきます。アーキテクトの設計判断と、PMの原価判断は切り離しにくくなります。ループエンジニアリングによって成立するのは、少人数の熟達者が上流を設計し、AIが下流を大量に処理する開発体制です。AIは、ウォーターフォール開発が抱えていた人海という弱点を小さくします。その一方で、上流で決めた仕様が下流の生産と費用を左右し、上流がその結果に責任を負うという計画主導型開発の本質を、AI時代の条件の下で復活させるのです。