Addy Osmani氏が「Loop Engineering」と題したブログを公開し、AIコーディングエージェントの使い方を「プロンプトを書く」段階から「ループを設計する」段階へ移す見方を示した。この言葉が示しているのは新しいアルゴリズムの登場ではない。開発者が毎回プロンプトを書いて返答を読む働き方から、エージェントを繰り返し動かす仕組みそのものを設計する働き方へ、操作の中心が移っているということだ。
エージェントが自分で調査し、コードを書き、別のエージェントへ確認を渡し、失敗を次の修正へ戻すほど、人間は「どこで止めるか」「何をもって完了とするか」「どの出力を信じてよいか」を先に決めなければならない。ループは手数を減らすが、責任の置き場所を消すわけではない。
プロンプトを書く人から、仕事の流れを設計する人へ
Google CloudのAddy Osmani氏は2026年6月7日のブログで、ループエンジニアリングを「エージェントにプロンプトを出す人間を、プロンプトを出すシステムに置き換えること」と説明した。そこでいうループは、目的を定義するとAIが完了まで反復する再帰的なゴールに近い。人間が一問一答で次の指示を出すのではなく、仕事を見つけ、割り振り、確認し、記録し、次の作業を決める小さなシステムを組む。
実務上の変化はもっと地味だ。よいプロンプトを一回書く能力よりも、定期的に実行する調査、作業を分けるエージェント、結果を確認する別エージェント、作業状態を残すメモ、失敗時に戻る検証条件をどう組み合わせるかが問われる。短い指示文の上手さではなく、仕事が繰り返されても破綻しない手順の設計が価値になる。
Osmani氏は、ループに必要な部品として、スケジュール実行のための自動化、並列作業を隔離するworktree、知識や手順を記録するskills、外部ツールにつなぐplugins/connectors、発案者と確認者を分けるsub-agents、会話の外に残る状態管理を挙げている。この一覧が示すのは、ループエンジニアリングが「AIに長く考えさせる技術」ではなく、エージェントの周囲に置く運用部品の設計だということである。
製品側はループの部品をすでにそろえ始めている
この話が流行語として片づけにくいのは、主要なコーディングエージェントの製品側が、すでに同じ方向へ機能を積み上げているからだ。OpenAIのCodexドキュメントでは、skillsは指示、資料、任意のスクリプトをまとめ、Codexが特定のワークフローを安定して実行するための仕組みとして説明されている。毎回長い前提を会話に貼る代わりに、作業の型を外部化する部品である。
Codexのsubagentsも同じ文脈にある。ドキュメントでは、Codexは専門化したエージェントを並列に走らせ、その結果を集約できると説明している。複雑な探索や複数段階の実装では、ひとつの会話にすべてを詰め込むより、別のエージェントに調査や確認を分けたほうが文脈を保ちやすい。ただし、各subagentは独自にモデルとツールを使うため、単一エージェントより多くのトークンを使う。ループを組むほど、速さと費用の設計が同じ画面に出てくる。
AnthropicのClaude Codeも、ループの部品を明示的に持つ。Claude Codeのドキュメントは、Routines、デスクトップのscheduled tasks、CLI内でプロンプトを繰り返す/loopを、定期的な作業を自動化する方法として並べている。hooksは、セッション開始、ユーザー入力、ツール実行前後、停止時など、Claude Codeのライフサイクルの特定時点で自動的に動く仕組みであり、ツール呼び出しごとに処理を差し込める。
Claude Codeのskillsとsubagentsは、プロジェクト知識や反復ワークフローをファイルにまとめ、専門エージェントへ仕事を切り出すための仕組みとして説明されている。subagentsは主会話の文脈を汚さず、ツール権限を限定し、必要なら安価なモデルへタスクを振ることにも使える。ここで見えてくるのは、ループが一つの巨大な自律エージェントではなく、スケジュール、記憶、権限、検証者、外部ツールを組み合わせた運用形態だということだ。
完了条件を持たないループは、作業を増やすだけになる
ループを製品機能として組めるようになるほど、中心になるのは自動化そのものではなく検証である。OpenAIの「Build iterative repair loops with Codex」では、ループをReview、Repair、Validateの三段階で説明している。まず成果物を見て構造化した指摘を返し、次にその指摘と直近の検証結果に沿って限定的に修正し、最後に関連するチェックを走らせる。残った失敗は、次の修正入力になる。
この考え方は、AIエージェントを継続実行させる際の基本線になる。ループが価値を持つのは、エージェントが何度も動くからではない。失敗が観測され、次の入力へ変換され、同じ基準で再確認されるからである。テスト、スキーマ検証、実行ログ、評価用データ、レビューコメント、Pull Requestの承認など、何を検証条件にできるかで、ループの実用性は大きく変わる。
OpenAIの「Agent Improvement Loop」も、同じ問題をより長い周期で扱っている。実行トレースを集め、人間とモデルのフィードバックを加え、それを評価に変換し、次のハーネス変更としてCodexへ渡す流れである。ここでいうハーネスは、モデルへの指示、ツール、ルーティング、出力条件、検証チェックを含む。プロンプトだけを直すのではなく、モデルを取り巻く契約全体を更新する。
この仕組みには、人間の入口を複数置ける。トレースを読む段階、評価を調整する段階、Pull Requestを承認する段階、マージやデプロイの段階で、人間が確認できる。完全自動に寄せることも、レビュー付きのループにとどめることもできる。ループエンジニアリングの実力は、AIをどれだけ長く走らせられるかではなく、人間の判断をどこに残すかを設計できるかで決まる。
コストと理解の負債が、ループの上限を決める
ループにはわかりやすい利点がある。定期的な調査、CI失敗の確認、依存関係更新、レビュー前の形式確認、脆弱性の一次調査のように、繰り返し発生し、結果を検証しやすい作業では、人間が毎回同じ段取りを始める必要がなくなる。作業の起点と検証条件を決めておけば、エージェントが先に候補を作り、人間は判断に集中できる。
一方で、ループは実行回数を増やす。スケジュールで起動し、subagentを呼び、別モデルで確認し、外部ツールを読み、失敗すれば再試行する。Osmani氏は、使い方によってトークン消費が大きく変わるため注意が必要だと書いている。Codexのsubagentsドキュメントも、各subagentが独自にモデルとツールを使うため、通常より多くのトークンを消費すると明記している。Claude Code側でも、subagentの用途として安価なモデルへのルーティングによるコスト制御が挙げられている。
もう一つの制約は、理解の劣化である。ループが速く成果物を作るほど、人間が読んでいないコード、把握していない設計、見逃した前提が増える。Osmani氏は、ループが仕事を変えるのであって、人間を仕事から消すわけではないと結論づけている。自分でレビューせず、全体を自動ループに頼るなら品質は悪化し得るという警告も添えている。
ループを組む人間が対象のコードや業務を深く理解していれば、エージェントは調査と反復を速める。理解していない領域でループを回すと、もっともらしい変更が大量に積み上がり、問題の発見が遅れる。ループは判断を増幅する道具であり、判断の不足も同じように増幅する。
導入の基準は「自動化できるか」ではなく「確認できるか」
ループエンジニアリングを実務へ入れるなら、最初に見るべきなのは自動化の範囲ではない。確認できる成果物を持つ作業かどうかである。テストがあるコード修正、再現手順のある不具合、定型形式のレポート、決まった評価指標を持つモデル改善、既知のセキュリティチェックの初期調査は、ループ化しやすい。失敗が見え、次の入力へ戻せるからだ。
逆に、要件が曖昧で、正解の基準がまだ合意されておらず、失敗時の損害が大きい作業は、ループの前に人間が設計すべき領域が多い。仕様の優先順位、顧客影響、法務やセキュリティ上の判断、組織内の承認線は、エージェントが反復しても自然には固まらない。こうした作業でループを使うなら、作業を小さく切り、観測できる部分だけを任せるほうがよい。
「プロンプトエンジニアリングからループエンジニアリングへ」という言い方は、少し派手に聞こえる。実際の変化は、AIとの会話がエンジニアリングの中心だった段階から、AIを含む作業システムの設計が中心になる段階への移行である。そこでは、指示文の美しさより、状態が残るか、検証が走るか、別の確認者がいるか、費用が読めるか、人間が最後に理解して承認できるかが問われる。
ループを組む価値は、プロンプトを書く人間を消すことではない。人間が毎回手で回していた反復を外へ出し、判断すべき場所を見える形にすることだ。エージェントが自分で動くほど、エンジニアの仕事は軽くなる部分と重くなる部分に分かれる。軽くなるのは、調査、候補作成、定型確認である。重くなるのは、何を正しいとみなすかを決め、その基準をループの外側から守る仕事である。
