■ 1. ループエンジニアリングとは
- 定義と背景:
- 生成AIによる開発は当初、自然言語で指示しその場で次の指示を出すバイブコーディングへ向かうと考えられていた
- しかしAIコーディングエージェントを本格的な開発へ投入すると、逆方向へ進み始める
- AIが実装、試験、修正を自律的に繰り返すループエンジニアリングでは、AIへ作業を引き渡す前に目的、作業範囲、設計方針、検証方法、完了条件、停止条件を明確にする必要がある
- この言葉は2026年6月ごろから広く使われ始めた
- コーディングエージェントへ一回ずつ指示を出す技能から、エージェントへ継続的に指示を出す仕組みそのものを設計する技能へ重点が移り始めたことを表す
- まだ初期段階の概念であり、実行結果やトークン費用の変動幅には注意が必要
- 本稿の主張:
- 重要なのはループが存在することではなく、その反復によって何が修正されるのか
- 典型的なループエンジニアリングで修正されるのは、事前に定められた仕様や受入条件へ適合するための実装
- 利用者の反応を受けて要求や製品の目的そのものを見直す反復とは階層が異なる
- 開発工程全体を見れば、ループエンジニアリングは下流工程をAI化した計画駆動型開発へ近づく
- フィードバックとフィードフォワード、上流と下流、人月とトークン、アーキテクトとPMという観点から整理する
■ 2. ループとフィードバックの違い
- スパイラルモデルとの相違:
- 「ループ」という言葉からはバリー・ベームのスパイラルモデルを連想しやすい
- スパイラルモデルでは各周回で目的を定め、代替案とリスクを評価し、開発と検証を行い、その結果を次の周回へ反映する
- ベーム自身もスパイラルモデルをリスク駆動の開発方式として位置づけている
- ループエンジニアリングの典型的な反復はこれとは階層が異なる
- 人間が事前に目的と受入条件を定め、AIがコードを調査し、実装し、試験を実行する
- 試験に失敗すればAIは原因を分析してコードを修正する
- フィードバックが変更する範囲:
- フィードバックによって変更されるのは、原則として実装方法のみ
- 仕様が利用者の問題に合っているか、選択したアーキテクチャが適切か、そもそも作る価値があるかという目標値そのものは、通常、内側の実装ループの手前に置かれている
- 制御系として表すなら、仕様や受入試験が目標値であり、コードベースが制御対象である
- AIエージェントは操作器としてコードを変更し、試験や静的解析がセンサーとして目標との差を検出する
- これは目標値への追従制御である
- 要求、設計、品質基準、例外処理、権限、停止条件などは、ループ開始前に人間が予測して与える
- 開発全体として見れば、計画と仕様はフィードフォワードであり、実装部分だけが閉ループになっている
- これはウォーターフォール開発が持つ計画駆動性を強く受け継いだ構造である
■ 3. 外側ループと速度差
- 外側ループの位置づけ:
- ループエンジニアリングの議論には外側のループも含まれる
- アンドリュー・ングは、エージェントによる実装ループ、開発者によるフィードバックループ、利用者の反応を製品の方向へ戻す外部フィードバックループという三層で整理している
- アディ・オスマニも、内側の実行ループと、人間が制約、検証、承認、責任を担う外側のループを区別している
- したがって、ループエンジニアリングでは要求が一切見直されないという主張は成立しない
- 問題は外側のループが存在するかどうかではなく、内側と外側のループをどこまで同じ速度で回せるか
- 速度差の帰結:
- AIによる実装、試験、修正は数分から数時間で繰り返せる
- 利用者の反応の観測、利害関係者の意見調整、投資判断や製品方針の変更にはより長い時間を要する場合がある
- ただし外側のループが必ず数週間単位になるとは限らない
- AIが試作品や途中成果を高速に生成し、それを利用者へすぐ提示できる環境では外側のループも短縮できる
- 本稿が想定するのは、内側の実装速度の向上に、利用者の観察、組織的な合意、価値判断の速度が追いつかない場合である
- 内側が数時間で回る一方、外側の判断に数日以上かかるようになれば、一定期間に生産される成果物のうち人間の判断が挟まった回数の割合は低下する
- 人間の関与は実装ループの途中から、ループへ投入する仕様、制約、受入条件の設定へ集中していく
- 本稿ではウォーターフォールを、工程が一方向に一度だけ進む方式と狭く定義していない
- 要求や設計を下流工程の開始条件として外部化し、上流で定めた内容が下流の生産を強く拘束する性質に注目している
- 外側のループが存在していても、内側との速度差が拡大すれば実務上の開発は計画駆動型へ寄る
- 逆に内側の高速化が外側の高速化も引き起こし、要求や製品仮説を短周期で変更できるなら、ループエンジニアリングはアジャイル開発を強化する可能性もある
■ 4. 自律時間とフィードフォワード性
- 自律稼働の代償:
- AIエージェントへ長時間仕事を任せる価値は、人間が途中で逐次指示を出さなくても作業が進むことにある
- 人間とのやり取りを減らすほど、AIは途中で新しい情報を受け取れなくなる
- 仕様に矛盾があった場合、利用者に確認せず、与えられた情報からもっともらしい解釈を選ぶ
- 未定義の例外が発生した場合も、人間が介入しなければ自ら判断するか停止するしかない
- そのため自律稼働時間を延ばすには、開始前に与える情報を増やす必要がある
- 目的だけでなく、変更してよい範囲、変更してはいけない範囲、既存設計の不変条件、優先順位、例外時の判断方法、試験方法、完了条件、再試行回数、人間へ引き上げる条件まで定義しなければならない
- 自律性を高めるほど途中の質疑応答が減り、質疑応答が減るほど事前仕様が重くなる
- OpenAIの内部実験:
- 人間がソースコードを一行も書かない条件で、約5か月かけて百万行規模の製品が構築された
- 当初3名、最終的に7名の技術者が、プルリクエストと継続的統合の仕組みを通じてエージェントを誘導した
- 人間が担った仕事は、リポジトリ構造、作業規約、機械的な検査、評価方法、エージェントから見える情報環境の設計だった
- エージェントにとって、実行中に文脈へ取り込めない情報は存在しないのと同じである
- 希少資源として扱われたのは、コード入力時間ではなく人間の時間と注意だった
- 自律化によって計画が不要になるのではなく、自律化を成立させる条件として計画、制約、検証方法が必要になる
■ 5. 下流委託のAI化
- 従来のウォーターフォールとの対応:
- 従来のウォーターフォール開発では、上流のアーキテクトやSEが要件定義書、基本設計書、品質基準、試験方針を作り、詳細設計や実装を担う社内チームまたは協力会社へ流していた
- 下流チームは渡された設計に基づいて詳細化、実装、単体試験、不具合修正を行い、成果物と試験結果を上流へ返す
- 上流側は設計どおりに作られているかを確認して受け入れる
- ループエンジニアリングでも基本構造は変わらない
- 要件定義書や基本設計書に相当するものが、設計文書、AGENTS.md、タスクプロンプト、機械実行可能な試験、変更禁止範囲、停止条件へ変わる
- AGENTS.mdは、エージェントへプロジェクト固有の作業規約や検証手順を伝えるための設定ファイルである
- 開発環境、権限、道具、履歴管理、コマンド実行機構はAI用の実行基盤として整備される
- AIエージェントはそれらを受け取り、内部で調査、実装、試験、修正を繰り返し、最後にプルリクエスト、試験結果、実行記録などを上流へ返す
- つまり下流の協力会社がAIエージェントに置き換わった形である
- AI内部で何度ループが回っても、委託構造そのものはフィードフォワード型である
- 発注側が先に仕事を定義し、受注側がその仕様に従って成果物を作り、発注側が検収する
- ループという名称はAIエージェント内部の動作を表すが、PMやアーキテクトから見た本質は上流から下流への委譲である
■ 6. AIは下流熟練者の補正機能まで奪う
- 従来の非公式フィードバック:
- 従来のウォーターフォール開発には、設計書に明記されていない非公式なフィードバック経路があった
- 優秀な詳細設計者や実装者は、上流の仕様に矛盾があれば質問し、既存機能への影響を発見すれば警告し、より保守しやすい構造があれば代案を提示した
- 公式には下流工程であっても、実際には質疑票、レビュー、会議、日常的な会話を通じて上流設計が修正されていた
- ウォーターフォールが現実に成立していた理由の一つは、下流の人間が単純な命令実行機ではなかったことである
- AIによる代替と限界:
- AIエージェントも質問や提案はできる
- しかし長時間自律ループの目的は人間との往復を減らすことにある
- 疑問が生じるたびに停止して人間へ確認していては自律化の便益が小さくなる
- そのためループを安定して動かすには、下流から来るはずだった質問や異論を事前に予測して設計へ埋め込む必要がある
- アーキテクトはAIとの壁打ちを繰り返し、仕様の解釈の余地、既存設計との矛盾、未定義の異常系、受入試験だけを形式的に通す抜け道の有無を検討する
- ループ開始前のAIは、仮想的な下流リーダー、設計レビュー担当者、反証者として使われる
- 設計が十分に収束した後、別のAIまたは同じAIが下流の実装主体として動く
- AI時代の開発には、上流での対話と下流での実装という二種類の反復が存在する
- 本質的な難所は、曖昧な要求を実行可能で検証可能な仕様へ変換する前者の反復に残る
■ 7. バイブコーディングとの対比
- バイブコーディングの原義:
- 生成された差分を十分に読まず、コードの理解を失っても気にせず、動作結果を見ながら追加の指示を出す開発態度を指す
- サイモン・ウィルソンも、AIを使ってコードを書くこと一般と、生成物を理解せずに進めるバイブコーディングを区別している
- バイブコーディングでは判断基準が人間のその場の感覚に残る
- 出力を見て気に入らなければ次の指示を出し、事前に体系的な受入条件を作る必要はない
- ループエンジニアリングとの対比:
- 成熟したループエンジニアリングでは、人間が不在でもAIが進めるように、判断基準を仕様、試験、制約、予算、停止条件として外部化する
- バイブコーディングは考えながらAIに書かせる方法であり、ループエンジニアリングはAIを自律稼働させられるところまで考えた後で引き渡す方法である
- 両者は、自然言語でAIへ指示し人間がコードを一行ずつ入力しないという外見だけは似ている
- しかしその外見はプログラミング未経験者が想像しやすい開発像にすぎない
- 実際のソフトウェア開発の難しさは、曖昧な要求を解釈し、責務と境界を定め、既存システムとの整合を取り、異常系を考え、検証可能な仕様へ変換し、実装から得た知見を要求や設計へ戻すことにある
- 頭の中に完成しているプログラムを文字として入力する作業はその一部にすぎない
- コード入力という目立つ工程が自動化されたことで本来の難所が露出する
- その難所を省略しようとするのがバイブコーディングであり、事前に徹底して処理しようとするのがループエンジニアリングである
- 両者は開発に必要な理解と検証をどこへ置くかという点で対極にある
■ 8. 人月からトークンへ
- ウォーターフォール時代の人月:
- 上流の設計判断が下流で消費される人月を決めていた
- 仕様が曖昧であれば、下流からの質問、設計変更、実装のやり直し、試験項目の追加が発生する
- 責務分割が悪ければ複数チームの調整が増える
- PMやアーキテクトは、この設計を下流へ流した場合に何人月かかるか、どれほど手戻りが発生するか、納期と予算の範囲に収まるかを考える必要があった
- トークンへの置き換え:
- ループエンジニアリングでは、この資源がトークンと計算資源へ置き換わる
- 曖昧な仕様はAIの探索範囲を広げ、大きすぎるタスクは文脈を肥大化させ、弱い完了条件は反復回数を増やす
- 複数のエージェントを使って実装、レビュー、試験を分担させればモデル呼び出しが重なる
- Anthropicが自社の調査用複数エージェント機能について公表した計測では、単一エージェントは通常の対話の約4倍、複数エージェント構成は約15倍のトークンを使用している
- これはコーディングではなく調査用途の数値だが、追加費用を正当化できる高価値な仕事に限定すべきだという結論は開発にも通じる
- AIエージェントの費用は、入力文脈、出力、推論、反復回数、並列数、試験実行、レビュー、失敗後の再試行の組み合わせで決まる
- 「この設計を協力会社へ流したら何人月かかるか」という問いは、「この設計をAIループへ流したら、どれだけトークンと計算資源を消費するか」という問いへ置き換わる
- 上流の曖昧さを下流資源の投入によって吸収する構造は変わっていない
■ 9. 技術判断が原価判断になる
- 従来の分業とAIループでの変化:
- 従来の大規模開発では、アーキテクトが技術構造を決め、PMが見積もり、要員、契約、納期、予算を管理する分業が可能だった
- 実際には重複する部分もあったが、技術設計と原価管理の間には組織的な距離があった
- AIループでは、その距離が短くなる
- タスクの分け方、モデルの選択、文脈の大きさ、変更範囲、試験範囲、再試行上限といった技術的判断がそのままトークン消費量を左右する
- 責務を一つのエージェントへ渡す、複数案を並列探索させる、試験を毎回全件実行すると決めた瞬間に消費構造が決まる
- そのためアーキテクトは技術的に正しい構造を作るだけでは足りず、どれほどの探索が必要か、費用に見合う価値があるか、どこで打ち切るべきかまで判断する必要がある
- 役割分担の残存と限界:
- 役割分担が消えるわけではない
- 細分化された組織では、スタッフエンジニアやアーキテクトが技術的な探索範囲を決め、エンジニアリングマネジャーが予算と遂行を管理し、プロダクトマネジャーが投資価値を判断し、費用管理の担当者が消費を追跡する形になる
- 財務担当も、AIの原価はトークン単価だけでは判断できず、品質と性能を含めて課金方式や構成を比較する必要があるとしている
- しかし役割を分けても技術判断と原価判断を完全には切り離せない
- 費用超過の原因が、単なる単価ではなく責務分割、試験戦略、文脈設計、終了条件にあるため
- 日本のSIerのように、上級SEやPMが要件調整、基本設計、協力会社管理、見積もり、品質管理を横断的に担う組織では、AI工程設計とトークン原価管理も同じ人物へ上乗せされやすくなる
- 人間の要員管理が減る代わりに、AIの探索範囲、実行予算、並列数、継続判断、成果物の受入を管理する仕事が増える
- 結果としてアーキテクトは、設計者であると同時にAI下流工程への発注者、工程設計者、原価判断への技術的責任者、検収責任者になる
■ 10. 超少人数のウォーターフォール
- 復活する体制の性質:
- ループエンジニアリングによって復活するのは、大人数と大量文書を前提とした20世紀型の開発体制そのものではない
- 上流には、利用者の要求を理解し、技術構造を決め、AIと壁打ちを繰り返し、受入条件を作れる少数の熟達者が残る
- 下流では、多数の人間の代わりにAIエージェントが実装、試験、修正を反復する
- 先のOpenAIの実験は、この体制が実際に動く可能性を示した
- 百万行規模の製品を3名から7名の技術者が誘導し、人間の仕事は環境設計、意図の記述、機械的な検査の整備へ集中した
- 開発組織の構造:
- 顧客や利用部門から得た要求を、少人数のPM、プロダクト責任者、アーキテクトが解釈する
- アーキテクトはAIを反証者として使い、要求の矛盾、技術的リスク、異常系、試験条件を洗い出す
- 十分に設計が固まった段階で、仕様と制約をAIエージェントへ渡す
- マクロでは上流から下流へ仕様を流す計画駆動型の工程であり、ミクロではAIが実装、試験、修正を繰り返す高速な反復型工程である
- 中央集権的な設計と局所的な高速反復を組み合わせた開発方式である
- アジャイルソフトウェア開発宣言は、計画に従うことより変化への対応を、契約交渉より顧客との協調を重視している
- AIエージェントを長時間自律稼働させるほど、人間による途中の協調や変更は減る
- 外側のフィードバックも同時に高速化できない環境では、自律性を得るための事前設計がウォーターフォール的な工程を再び合理的なものにする
■ 11. 復活するのは上流責任
- 復活の本質:
- 工程の順序が昔のまま戻るわけではない
- AI時代に復活する本質は、上流で定めた情報が下流の生産を規定し、その情報の品質について上流が責任を負う構造である
- AIエージェントは下流工程の速度を上げるが、何を作るべきかを単独で決定する主体ではない
- 要求の採否は価値判断であり、価値判断にはその選択の結果に対して資本と責任を負う帰属先が必要である
- AIが要求案や仕様案を生成できるようになっても、この構造は変わらない
- 生成された案のどれを採用するかという判断は損失を引き受ける主体へ帰属する
- 能力が上がるほど案は増え、帰属先が行う選択と承認の回数はむしろ増える可能性がある
- 上流の問題設定能力の重要性:
- ループの完了条件が間違っていれば、AIは間違った完了状態へ効率よく到達する
- 停止条件が弱ければトークンを消費し続け、作業分割が悪ければ複数のAIが矛盾する変更を並列に生成する
- AIが高性能になるほど上流の問題設定能力が全体の成果を決める
- これはウォーターフォール開発が長く抱えてきた構造と同じである
- 上流の一行が下流の何十人月を左右していたのに対し、ループエンジニアリングでは上流の一行が何百万トークンの消費と大量の生成物を左右する
■ 12. 現場で観測されるはずの変化
- 予測される観測項目:
- 本稿の整理が正しければ、AIエージェントを本格導入した組織ではいくつかの変化が観測されるはずである
- 第一に、実装開始前に外部化される制約、受入条件、作業規約、機械検証可能な規則の量が増える
- ここでいう量は自然言語の仕様書のページ数だけでなく、自動試験、型、静的解析規則、権限設定、実行方針、評価器、停止条件なども含む
- 第二に、開発における人間の総作業時間のうち、問題設定、環境設計、評価方法の構築、成果物の受入といった上流側の作業が占める割合が上がる
- 第三に、長時間の自律ループへ投入された後に人間が要求や設計を変更する頻度は、逐次対話型の開発より下がる
- 第四に、人員構成が上流側へ偏り、詳細設計、実装、試験を専門に担う人員が減る
- 先のOpenAIの事例は、少なくとも人間の作業が環境設計と意図の記述へ集中し、直接実装する人員が存在しなかったことを示している
- 反証条件:
- 逆に、AIエージェントの導入によって実装開始前に外部化される制約や評価規則が薄くなり、要求変更の受付頻度が上がり、利用者を含む外側のループも内側と同程度に高速化するという観測が広く得られるのであれば、本稿の整理は誤りである
- その場合、内側ループの高速化は上流の計画駆動性を強めるのではなく、外側の学習速度を高め、開発をアジャイル側へ寄せていることになる
- 判定材料は今後数年で揃う
- 導入企業における実装前の制約や評価規則の量、要求変更の頻度、人間の作業時間の内訳、職種別の人員構成、AI利用費の責任分担が検証データになる
■ 13. まとめ
- ループエンジニアリングの位置づけ:
- ループエンジニアリングは反復という言葉を含むため、アジャイル開発やスパイラルモデルの延長に見える
- 典型的な内側のループで修正されるのは、事前に定めた仕様へ適合するための実装である
- 要求を見直す外側のループも存在するが、内側の実装速度に利用者の観察、組織的な合意、価値判断の速度が追いつかなければ、両者の速度差は開いていく
- 資源の置き換えとその非対称性:
- 開発全体では、要求、設計、受入条件、停止条件を上流で事前に定め、下流のAIがそれに従って成果物を作る
- これは従来のアーキテクトが基本設計を下流チームや協力会社へ渡していた構造と同じである
- 変わるのは下流で投入される資源である
- 人間の詳細設計者、実装者、試験担当者が減り、代わりにトークン、計算資源、AIエージェントの反復が投入される
- ただしこの置き換えは等価ではない
- 人間の増員に働いていた雇用や対人調整の制約は小さくなる一方、成果物間の整合、選別、統合の必要は残る
- ウォーターフォール時代には、アーキテクトとPMが人月を燃やす責任を負っていた
- ループエンジニアリング時代には、設計者の技術判断がトークンを燃やす量を決める
- 技術設計が探索範囲と反復量を決めるため、アーキテクチャ判断と原価判断は不可分になる
- AIが途中で人間からフィードバックを受けずに長時間動くほど、開始前の壁打ちと設計は重くなる
- アーキテクトはAIを使って要求の穴を探し、異常系を洗い出し、受入条件を作り、AIへ委託可能な仕様へ仕上げる
- その後、AIエージェントが下流で高速な実装ループを回す
- 結論:
- ループエンジニアリングによって成立するのは、少人数の熟達者が上流を設計し、AIが下流を大量に処理する世界である
- それはマクロではフィードフォワード、ミクロでは閉ループという構造を持つ、超少人数・設計主導・AI下流型のウォーターフォールである
- AIは人海という弱点を取り除き、上流設計者の技術判断をトークン原価へ直結させることで、ウォーターフォールが持っていた計画駆動性と上流責任を、新しい経済条件の下で復活させる