AI コーディングの世界ではこんな主張が広まっています。「コーディングエージェントにプロンプトを送るのはやめて、エージェントにプロンプトを送るループを設計しよう」と。新しいものにありがちな話で、この手の主張はよく繰り返される割に、その理由が説明されることはほとんどありません。ここでは実践的な観点から、エージェントループとは何か、なぜ重要なのか、そして本番環境ではどんな姿になるのかをお伝えします。
以下は、私が（Claude の助けを借りて）いくつかの実験、研究、そして 受講生、テクニカルファウンダー、AI エンジニア、スタートアップとの会話から得た考えの一部です。
また、最近のライブセッション「自律型長期実行コーディングエージェント」も、このテーマの入り口としておすすめです。
この主張の出典
「もうコーディングエージェントにプロンプトを送るべきじゃない。エージェントにプロンプトを送るループを設計すべきなんだ。」Peter Steinberger（
@steipete ）、2026年6月7日。220万回再生。
Claude Code の生みの親である Boris Cherny も、別の角度から同じ主張をしています。
「私はもう Claude にプロンプトを送っていない。ループが動いている。ループが Claude にプロンプトを送り、何をすべきか判断している。私の仕事はループを書くことだ。」Boris Cherny（
@bcherny ）。
ここで言いたいのは、プロンプトエンジニアリングが終わったということではありません。ループエンジニアリングによって、作業のレベルが一段上がり、コードを書くことから、コードを書くシステムを書くことへと移行するのです。この道を最も進んだ開発者たちは、IDE を一度も開かずに何百もの PR を出荷し、コードの1行1行がエージェントによって書かれた月があったと報告しています。
ループとは実際には何か
ループとは、あなたが書く小さなプログラムで、以下の4つのことを行います。
- コーディングエージェントに代わってプロンプトを送る
- エージェントが生成したものを読む
- それが完了したかどうかを判断する
- 完了していなければ、エラーまたは次のステップとともに再度プロンプトを送る
ループの中に座ってプロンプトを手打ちするのをやめ、ループを書けば、モデルはそれが呼び出すサブルーチンになります。
形は常に同じです：目標を設定し、行動し、確認し、エラーをフィードバックし、確認が通るかループが停止するまで繰り返します。
「ループ」には少なくとも5つの意味がある
意見の相違の多くは、1つの言葉を5つの異なる概念に使っていることに起因します。以下が、最も古いものから新しいものへの発展です。
- ReAct（2022年）。 元祖の研究パターン：思考、行動、観察、反復。
- AutoGPT（2023年）。 自己プロンプト型目標ループ。いつ止めるべきかを知らないことで有名。
- ralph ループ。 エージェントが自身の履歴に埋もれないように、反復の間に意図的にコンテキストをリセットする。
- /loop と /goal。 実行ペースと完了条件がエージェントに組み込まれており、ターンごとに状態を保持する。
- オーケストレーション。 1人の作成者が多数のエージェントを分岐させ、あなたの GitHub、Slack、チャットを読み取り、次に何を構築すべきかを決定する。
実際に組み立てる部品
この発展の流れは、人々がループで 意味している ことを説明しています。ここからは、ループが 何から構築されているか です。毎回同じ6つの部品が登場し、現在ではそのほとんどが、自分でメンテナンスするカスタムスクリプトではなく、コーディングツールに組み込まれて出荷されています。
- トリガー。 あなたが「実行」を押さなくてもループを開始するもの：スケジュール、Webhook、ファイル変更、PR に付けられたラベル。これが、手動で繰り返す1回きりの実行と、本当のループを区別するものです。
- 分離。 エージェントごとにプライベートなチェックアウト（通常は git worktree）を用意し、2つのエージェントが同時に実行してもお互いのファイルを上書きできないようにします。複数のエージェントを実行するなら、これは必須です。
- 文書化されたコンテキスト。 規約、ビルド手順、プロジェクト固有のルールは、エージェントが実行のたびに読み取れる場所に保管します。これを怠ると、ループは毎回ゼロからプロジェクトを再導出し、ギャップを推測することになります。
- ツールへの到達。 課題トラッカー、CI、データベース、チャットへのコネクタ。ループが PR をオープンし、チケットをリンクし、結果を投稿できるようにするためです。「修正しました、あとはよろしく」と印刷して、あなたが残りの作業を引き継ぐのを待つ代わりに。
- 別のエージェントがチェックする。 出力を評価する独立したワーカーを、出力を生成したエージェントとは別に用意します。なぜなら、自身の作業をレビューするモデルは、ほぼすべてを通してしまうからです。
- ディスク上の状態。 マークダウンファイル、ボード、キューなど、会話の外にあって、何が完了し、次に何があるかを記録するもの。モデルは実行の間で忘れますが、ファイルは忘れません。
これら6つを組み合わせれば、ループエンジニアリングの良い出発点になります。以前はすべてを手作業で構築する必要がありましたが、現在ではほとんどが組み込み機能として出荷されているため、このパターンは一部のテクニックから一般的な用途へと移行しました。
具体的なループ：PR ベビーシッター
今日すぐに構築できる具体例：
- トリガー。 15分ごと。
- 範囲。 agent-watch とラベル付けされたオープン PR。
- アクション。 CI が決定論的な理由でレッドの場合、1回の修正を試みる。メインブランチが移動した場合、1回リベースする。
- 予算。 PR あたり1回の修正試行、5分、変更ファイル数10まで。
- 停止条件。 CI がグリーンになる、または予算を使い果たす。その後停止し、人間に通知する。
壊れたビルドのバックログではなく、マージされた PR を確認することになります。同じ形は、ほとんどの運用業務にも当てはまります。
- CI ヘルス。 30分ごとに、失敗した実行を取得し、シグネチャでクラスタリングします。これにより、1つの根本原因を持つ10個のレッド PR が、1つの確認事項になります。
- デプロイ検証。 プッシュ後、エンドポイントにアクセスし、200 と期待されるコンテンツを確認し、ユーザーが気付く前にリグレッションを報告します。
- フィードバックのクラスタリング。 30分ごとに、チャンネルからコメントを取得し、テーマごとにグループ化し、各クラスターをそれを担当するファイルやドキュメントにマッピングします。
/goal を使った具体的な Claude Code ループ
ベビーシッターは自分で配線するループですが、エージェントに組み込まれているループを見るのも役立ちます。Claude Code において、最小の完全なループは /goal です。検証可能な最終状態を渡すと、その状態が真になるまでターンを続けます。
以下は、Claude Code で /goal をセッション内コマンドとして使用する例です。セッションを起動し、その中で目標を設定します。
1$ claude # Claude Code を起動2$ /goal tests in test/auth pass # セッション内で目標を設定
これは、先ほどと同じ「行動、確認、反復」の形であり、検証機能が組み込まれています。
ここで明らかなのは、優れた /goal はプロンプトというよりも、むしろ契約のように読めるということです。優れたゴールは4つのことを指定します：あなたが望む 最終状態、それを達成したことを証明する 証拠、エージェントがそこに到達するまでに破ってはならない 制約、そして費やすことが許される作業の 予算。これらのいずれかを曖昧にすると、モデルは最も簡単な解釈でギャップを埋めます。つまり、早期に停止したり、近道をしたり、トランスクリプト上は完了したように見せかけるために成功を再定義したりするのです。その間、実際のシステムは壊れたままです。
- 条件を設定する。 /goal とチェック可能な最終状態を入力します。例：/goal tests in test/auth pass。最初のターンがすぐに開始されます。
- エージェントが1ターン作業する。 編集し、テストを実行し、結果をセッションに表示します。
- 評価者がチェックする。 高速なモデルがトランスクリプトを読み、目標が「達成された」か「未達成」かを判断します。これにより、エージェント自身が自分の作業を採点することはありません。
- ループするか終了するか。 「未達成」の場合は、ガイダンスとともに次のターンに進みます。「達成」の場合は、ゴールが自動的にクリアされ、実行が停止します。
状態はターン間で保持されるため、早期に終了したり、途中で制約を見失ったりすることはありません。いくつかのコントロールにより、信頼性を保ちます。
- チェックを測定可能にする。 テスト結果、終了コード、ファイル数、空のキューなど。 npm test exits 0 はゴールですが、「もっと良くする」はゴールではありません。
- 実行に上限を設ける。 「または20ターン後に停止」のように追加することで、スタックしたループがターンを消費し続けるのではなく停止します。
- 自動モードと組み合わせる ことで、ターンを無人で実行できます。早期に中止するには /goal clear を使用します。
評価者のステップには、便利な微妙な点があります。チェッカーはコーダーと同じモデルである必要はないということです。ループに明確な役割（プランナー、実行者、評価者、ビジョンレビューアー）が割り当てられれば、それぞれを異なるモデルで実行でき、どのモデルがどの役割を担うかを選ぶことが、単一の「最良の」コーディングエージェントに賭けるのではなく、アーキテクチャ上の決定になります。あるモデルは計画が得意で、別のモデルはより安価に実行でき、また別のモデルはスクリーンショットをより正確に判断します。優れたオーケストレーターを使えば、1つのベンダーがすべてのカテゴリで勝つのを待つのではなく、役割ごとにモデルを交換できます。
これは、API マイグレーション（すべての呼び出し箇所を移動してコンパイルとテストが通るようにする）、リファクタリング（各モジュールが予算内に収まるまでファイルを分割する）、課題バックログ（ラベル付けされたキューが空になるまで処理する）、評価ループ（スコアがしきい値を超えるまでプロンプトを調整する）などに適しています。/loop は、単一の終了ラインがない作業のためのカウンターパートです。完了条件の代わりに、スケジュールに従って再プロンプトを送ります。これが、PR ベビーシッターのようなループが動き続ける仕組みです。
多数のループを無人で実行する
単一の /goal ループは、1つのエージェントが1つのゴールラインに向かって作業するものです。多くの無人プロセスを実行すると、リスクが高まります。なぜなら、ループは自身の作業をチェックする能力と同じだけ信頼できるからです。Cherny が Opus を数時間自律的に実行するためのセットアップは、以下の5つのステップに集約されます。
- アクセス許可を自動承認する ことで、エージェントがツール呼び出しのたびに確認を求めて停止しないようにする。
- 動的ワークフローを使用する（プロンプトに Ultracode をドロップする）ことで、1つの逐次スレッドではなく、多数のエージェントに分散させる。
- /goal または /loop を使用する ことで、処理を継続させる。/goal は完了条件を設定し、/loop はスケジュールに従って再プロンプトを送ります。どちらも状態を保持するため、早期に終了しません。
- クラウド上で実行する（デスクトップまたはモバイルアプリ）ことで、ラップトップを閉じてもセッションが存続する。
- エンドツーエンドで自己検証する方法を与える。ウェブ用の Chrome 内 Claude、モバイル用のシミュレーター MCP、バックエンド用のライブサーバー。このステップが、他の4つを安全にします。
完全なシーケンス：
1claude --permission-mode auto # 1 · 承認プロンプトなし2ultracode orchestrate sub-agents to ship the feature # 2 · 分散3/goal all tests pass and the demo loads clean # 3 · 継続4→ cloud / desktop app # 4 · ラップトップを閉じる5→ chrome ext · sim MCP · live server # 5 · 自己検証、そして停止
crabfleet：プロダクトとしてのオーケストレーション
オーケストレーションは、具体的なツールを使うとイメージしやすくなります。Peter Steinberger の crabfleet は、「エージェント実行のミッションコントロール」と謳われた OpenClaw プロジェクトで、ループをプロダクトとしてパッケージ化したものであり、その形状は上記のすべてにマッピングされます。
- ボード上のカードとしての作業。 タスクは、プロンプト、GitHub の issue、または PR から構築されたカードとして入力され、TODO、実行中、人間によるレビュー、完了の状態を遷移します。このボードはループのキューであり、停止して報告するステップであり、可視化されています。
- ファイアアンドフォーゲットではない、耐久性のある実行。 各実行はハートビート付きで追跡される試行であるため、あなたが目を離しても実行は継続され、ラップトップを閉じても存続します。ランタイムがハンドオフをサポートしていると通知した場合にのみ、あなたが引き継ぎます。
- エージェントを生み出すエージェント。 実行は子セッションを開始したり、メッセージを送信したり、トランスクリプトを読んだり、サンドボックス内から自身のサマリーを更新したりできます。これにより、ディスク上のメモリと分岐が1つの場所に集約され、1人の作成者と多数のエージェントが存在することになります。
これは、ブラウザベースのターミナルを備えた使い捨てのクラウドサンドボックス上で実行され、無人実行から離れても安全であることを意味します。重要なのは特定のツールではなく、ループがインフラストラクチャへと進化したことです。キュー、耐久性のある実行、分岐、人間によるレビューのゲートが、もはや毎回手動でスクリプト化するものではなく、設定するものになったのです。
コストは今どこにいくのか
2年の間、AI コーディングにおけるコストの問いは単純でした。どのモデルを使うか、そして何トークン使うか。ループの中では、その直感は間違ったレイヤーを指します。支出はもはや単一の呼び出しではなく、ループが何周するかです。つまり、収束するまでに6回再試行するループは、同じモデルでも1回目で成功するループの6倍のコストがかかるのです。
これにより、最適化する価値のあるものが変わります。
- コストラインはトークンではなく、反復回数である。 2倍の頻度でループする安価なモデルは、実際には安価ではありません。したがって、呼び出しあたりのコストではなく、完了したタスクあたりのコストを追跡します。
- 脆弱な検証機は、出荷できる最も高価なバグである。 「完了」を判断するチェックが緩い場合、ループは壊れた作業で早期に停止するか、すでに問題ない作業で延々と動き続けます。どちらにせよ、反復全体を無駄にします。これを何よりも先に厳格にします。
- 迅速な失敗はコスト管理である。 連続失敗に上限のないループは、最終的に成功するのではなく、最終的にアカウントを使い果たします。したがって、停止条件はコードベースと同様に請求書も守ります。
以前はプロンプトを調整していましたが、今はループを調整します。なぜなら、そこにコストが蓄積されるからです。
ループを使うべきでない時
ループは、タスクが繰り返し発生し、機械がいつ完了したかを判断できる場合に効果を発揮します。それ以外の場合、ループは単にムダな作業を自動化するだけです。以下のケースでは使用を避けてください。
- 1回限りの編集。 1回のパスで完了できる場合、ループは純粋なオーバーヘッドです。
- 範囲が定まっていない、または探索的な作業。 「ユーザーが離脱している理由を突き止める」には合格条件がないため、ループは決して収束しません。
- 安価な自動チェックがないもの。 唯一の検証機があなた自身の目である場合、あなたはまだループの中にいます。まずチェックを構築するか、タスクを手動で行います。
何が問題になり得るか
あなたが眠っている間に実行されるループは、あなたが眠っている間に間違いも犯します。そして、その失敗モードは予測可能です。
- 検証の負担は人間に残る。 ループはあなたがレビューできるよりも速くコードを書きます。そのため、差分を読むのをやめた場合、作業をなくしたわけではなく、先延ばしにしただけです。
- 理解のギャップが広がる。 自分で書いていないコードを、吸収できる速度よりも速く出荷することは、自身のシステムに対するモデルを侵食し、その負債は次のインシデントの際に顕在化します。
- 緩いチェックによる静かなドリフト。 脆弱な検証機は、間違っているがチェックは通る作業をすべての反復で通過させるため、ループは穴を掘りながら生産的に見えます。
これらのどれも、ループに対する反論ではありません。これこそが、ループを設計するエンジニアがより重要になり、決して軽視されない理由です。
自分で構築する方法
- 1つの反復可能なタスクを選ぶ。 PR のベビーシッター、CI の修正、デプロイの検証など、ルーチンワークから始めます。
- 範囲を厳しく絞る。 「請求書 Webhook のバリデーションを修正する、触っていいのは app/api/billing と lib/billing だけ」は、「バグを修正する」よりも優れています。範囲が緩いループは迷走します。
- 予算と停止条件を設定する。 最大試行回数、最大実行時間、最大ファイル数、最大支出、最大連続失敗数。無人で実行されるループは、無人で間違いも犯します。
- 独立した検証機を追加する。 別のサブエージェントが作業を評価します。なぜなら、コードを書いたエージェントは、その作業が完了したかどうかの最悪の判断者だからです。
- 一定の間隔で実行する。 間隔には /loop、スケジュールには cron、ライフサイクルポイントにはフック、または GitHub Actions を使い、ラップトップを閉じても実行が継続されるようにします。
- メモリをディスクに保持する。 モデルは実行の間で忘れるため、状態はコンテキストウィンドウ内ではなく、マークダウンまたはボードに保持します。
結論：高価で失敗しやすい部分は、モデルではなく、今やループです。実行を開始するだけの人ではなく、出力に対して責任を持つエンジニアであり続けるつもりで、ループを構築しましょう。
もし誤りや、さらに明確にする必要がある点があれば、遠慮なくご連絡ください。
