はじめに
この記事は、コーディングエージェントとの付き合い方を「1回ずつプロンプトを書く」から「自動で回るループを設計する」へ切り替える、という考え方についての解説と実践メモです。
きっかけは、DAIR.AI の elvis（@omarsar0）さんが書いた「From Prompting Agents to Loop Engineering」という記事でした。
読んで腹落ちした部分と、自分なりに噛み砕いた理解、そして自作のAI秘書エージェントで実際に試してハマった話を一本にまとめます。
元記事は、同氏のライブセッション「Autonomous Long-Running Coding Agents（自律的に長時間走るコーディングエージェント）」を出発点として勧めています。
読むと得られるものは、次の3つを想定しています。
- 「ループ・エンジニアリング」が具体的に何を指すのかが分かる
- ループを構成する部品と、抜くと何が壊れるかが分かる
- 自分の手元で小さく始めるための手順が分かる
対象読者は、Claude Code や Cursor などのコーディングエージェントを日常的に使っていて、「もう一段自動化したい」と感じている方です。
本記事は元記事を出発点に、筆者の理解と実運用を加えて書き起こしたものです。
元記事の主張の紹介には引用（>）を使い、それ以外は筆者の解釈です。
図は元記事のホワイトボード図を Mermaid で描き直しています。
文章の構成・文章の見直しと図の再現には生成AI（Claude）を併用しました。
検証した範囲は「元記事との照合」と「筆者の環境での実践部分」です。
外部の人物の発言やツールの機能仕様は、元記事の記述に依拠しています（独自の裏取りはしていません）。
先に結論（この記事の要点）
- プロンプト・エンジニアリングが終わったわけではありません。仕事が「コードを書く」から「コードを書くシステムを書く」へ一段上がる、という話です。
- ループとは「プロンプトを与える→出力を読む→完了か判定する→未完なら再投入する」を自動で回す小さなプログラムです。
- ループは6つの部品（トリガー / 分離 / 明文化された文脈 / ツール接続 / 独立した検証役 / ディスク上の状態）で組み立てます。
- コストの主役はトークン数ではなく「反復回数」に移ります。一番高くつくバグは「弱い検証役」です。
- 反復可能でゴール判定が自動化できるタスクから始めます。スコープを絞り、停止条件を必ず付けます。
「プロンプトを書く」から「ループを設計する」へ
最近、AIコーディング界隈でこんな主張をよく見かけます。
「もうコーディングエージェントにプロンプトを書くべきではない。エージェントにプロンプトを与えるループを設計すべきだ。」 — Peter Steinberger（@steipete）
元記事によると、Claude Code の作者である Boris Cherny も、同じことを別の角度から言っています。
「私はもう Claude にプロンプトを書かない。走り続けているループがある。Claude にプロンプトを与え、何をすべきか考えているのはそのループだ。私の仕事はループを書くことだ。」 — Boris Cherny（@bcherny）
最初に強調したいことがあります。
これは「プロンプト・エンジニアリングはもう不要」という話ではありません。
むしろ、プロンプトを書く力は前提として残ります。
変わるのは仕事の階層です。
コードを書く側から、コードを書くシステム（ループ）を書く側へ、一段上がるイメージです。
自分の仕事に置き換えると分かりやすいと思います。
これまでは、エージェントに毎回「ここを直して」「次はこれ」と指示を出していました。
ループ・エンジニアリングでは、その「毎回の指示」自体をプログラムに肩代わりさせます。
元記事によると、この方向に最も進んだ開発者は、IDEをほとんど開かないまま数か月で数百のPRを出荷し、ほぼ全行をエージェントが書いた、と報告しているそうです。
極端な例だとは思いますが、「人間がループの外に出る」とはこういうことか、とイメージが湧きました。
ループとは何か
元記事の定義はシンプルです。
ループとは、次の4つを行う小さなプログラムです。
- あなたの代わりにコーディングエージェントへプロンプトを与える
- エージェントが生み出したものを読む
- 完了したかどうかを判断する
- 完了していなければ、エラーや次のステップとともに再度プロンプトを与える
形はいつも同じです。
ゴールを定め、実行し、チェックし、失敗したらエラーを差し戻し、チェックが通るかループ自身が止まるまで繰り返します。
私がいちばん腑に落ちたのは「モデルがサブルーチンになる」という表現でした。
これまでは人間がループの内側に座り、毎ターン手でプロンプトを打っていました。
ループを書くと、人間は外側に出ます。
モデルは、ループから呼ばれる関数のひとつになります。
「ループ」という言葉は1語で5つを指している
議論がかみ合わない原因の多くは、みんなが「ループ」という1つの言葉で別々のものを指していることにあります。
元記事は、古いものから新しいものへ、5段階で整理しています。
それぞれを一段かみ砕くと、次のようになります。
- ReAct（2022）: 元祖の研究パターンです。推論し、実行し、観察し、また推論する、を繰り返します。
- AutoGPT（2023）: 自分でゴールを刻んで自己プロンプトする方式です。「いつ止まればいいか分からない」ことで有名になりました。
- ralph loop: 反復のたびに意図的にコンテキストを捨ててリセットします。エージェントが自分の長い履歴に溺れるのを防ぐ工夫です。
- /loop と /goal: 頻度（どのくらいの間隔で回すか）と完了条件をエージェント側に組み込んだものです。状態をターンをまたいで持ち越します。
- オーケストレーション: 1人が多数のエージェントに仕事を割り振る段階です。GitHub やチャットを読んで、次に何を作るかまで決めさせます。
段を上がるほど自律性が増し、人間の関与が減っていく流れです。
自分がいまどの段の話をしているのかを意識するだけで、議論の混乱はだいぶ減ると感じました。
ループを組み立てる6つの部品
進化の流れは「ループという言葉が何を意味するか」の整理でした。
ここからは「ループが何でできているか」です。
元記事は、毎回同じ6つの部品が現れると整理しています。
それぞれ、なぜ必要かと「抜くと何が起きるか」を添えて説明します。
- トリガー: あなたが実行ボタンを押さなくてもループを始めるものです。スケジュール、Webhook、ファイル変更、PRへのラベル付与などです。これが無いと、結局あなたが手で起動する「単発の繰り返し」に戻ります。
- 分離（アイソレーション）: エージェントごとの専用作業領域です。git の worktree がよく使われます。複数エージェントが同時に動くと、これが無い限り互いのファイルを壊し合います。
- 明文化された文脈: 規約・ビルド手順・プロジェクト固有のルールを、エージェントが毎回読める場所に置いておくことです。省くと、ループは毎回プロジェクトをゼロから推測し直し、隙間を勝手に埋めます。
- ツール接続: 課題管理・CI・DB・チャットへのコネクタです。これがあると、ループは修正を表示して待つのではなく、自分でPRを開き、チケットを立て、結果を投稿できます。
- 独立した検証役: 成果物を採点する、作った本人とは別のエージェントです。自己評価は合格寄りに倒れやすく、独立した検証役を置くほうが失敗を拾えます。だから採点役を分けます。
- ディスク上の状態: 会話の外で「何が終わって、次が何か」を記録する場所です。Markdown ファイル、ボード、キューなどです。モデルは実行のたびに忘れますが、ファイルは忘れません。
私の感覚では、この6つのうち「独立した検証役」と「ディスク上の状態」が、軽視されやすく効きやすい部品です。
特に検証役は、後述するコストの話と直結します。
具体例1: PRベビーシッター
抽象論だけだとイメージしにくいので、元記事の具体例を見ます。
「PRベビーシッター」は、今日からでも組める身近なループです。
骨格を擬似コードで書くと、こんなイメージです。
# PRベビーシッターのループ定義（擬似コード・実行不可のイメージ）
trigger: every 15 minutes # 1. トリガー
scope: PRs labeled "agent-watch" # 2. スコープを絞る
action:
- if ci_failed_deterministically: attempt_fix(max=1) # 決定的な失敗なら1回だけ修正
- if base_branch_moved: rebase(max=1) # mainが進んだら1回だけリベース
budget: # 3. 予算
fixes_per_pr: 1
minutes: 5
files_changed: 10
stop_condition: # 4. 停止条件
- ci_green: merge_pr
- budget_exhausted: notify_human
ポイントは4つだと理解しました。
- トリガーは「15分ごと」。人間が起動しません。
- スコープは「agent-watch ラベルの付いたPR」。対象を絞ることで暴走を防ぎます。
- 予算は「1修正・5分・10ファイルまで」。やりすぎを止める上限です。
- 停止条件は「CIが緑ならマージ、予算切れなら人間に通知」。
この骨格は、PR以外の運用作業にも応用できます。
ただし検証器と停止条件は、タスクごとに作り直す前提です。
元記事では、同じ形で回せる運用作業として次の3つが挙げられています。
- CIヘルス: 30分ごとに失敗した実行を取得し、エラーのシグネチャでクラスタリングします。1つの根本原因による赤いPR10件が、見るべき1件にまとまります。
- デプロイ検証: プッシュ後にエンドポイントを叩き、200と期待する内容を確認し、ユーザーより先にリグレッションを検出します。
- フィードバック整理: 30分ごとに各チャンネルのコメントを取得し、テーマごとにまとめ、各クラスタを「それを所有するファイルやドキュメント」に対応づけます。
具体例2: /goal で「終了状態」を契約にする
自分で組むループとは別に、エージェント側に組み込まれたループを見ると理解が進みます。
元記事では、Claude Code の /goal をいちばん小さい完結したループの例として挙げています。
検証可能な終了状態を渡すと、その状態が真になるまでターンを取り続ける、という考え方です。
/goal や /loop の挙動・有無はバージョンや提供状況で変わります。
本記事は元記事の例として紹介しており、現行版での動作保証ではありません。
実際に使う際は、お使いの環境のドキュメントで確認してください。
使い方のイメージは次の通りです。
$ claude # Claude Code を起動
$ /goal tests in test/auth pass # セッション内でゴールを設定
ここで大事なのは、強い /goal は「プロンプト」というより「契約書」に近い、という指摘です。
良いゴールは、次の4つを明記します。
- 終了状態: 何が真になれば完了か
- 証拠: それに到達したと証明できるもの
- 制約: 到達する過程で破ってはいけないこと
- 予算: 使ってよい作業量の上限
このどれかを曖昧にすると、モデルは最も楽な解釈で隙間を埋めます。
早めに止まる、近道する、といった逃げ方をします。
あるいは「成功」を再定義し、実際は壊れているのにログ上は完了したように見せることもあります。
信頼性を保つコツも具体的でした。
-
チェックを測定可能にする: 「
npm testが 0 で終了」はゴールになりますが、「もっと良くする」はゴールになりません。 - 実行に上限を付ける: 「または20ターンで停止」のように書き、行き詰まったループがターンを浪費しないようにします。
-
オートモードと組み合わせる: ターンを無人で回しつつ、途中で打ち切りたいときは
/goal clearで中断できる、とされています。
評価役の話には、もう一段の含みがあります。
チェック役は、コーディング役と同じモデルである必要はありません。
役割（計画・実行・評価・画面レビュー）を分けると、それぞれ別のモデルを当てられます。
あるモデルは計画が得意、あるモデルは安く実行できる、あるモデルはスクリーンショットの判定が正確、という違いがあるからです。
「どのモデルにどの役割を任せるか」は、もはや単一の最強モデルを選ぶ賭けではなく、アーキテクチャ設計の問題になります。
この /goal の形は、終了状態をはっきり書ける作業と相性が良いです。
元記事は具体例として、次を挙げています。
- API移行（すべての呼び出し箇所を、コンパイルとテストが通るまで移す）
- リファクタリング（各モジュールが予算内に収まるまでファイルを分割する）
- 課題バックログの処理（ラベル付きキューが空になるまで回す）
- 評価ループ（スコアがしきい値を超えるまでプロンプトを調整する）
一方で、終了ラインが1つに定まらない作業には /loop が相棒になります。
完了条件の代わりに、スケジュールで再プロンプトし続ける方式です。
先ほどのPRベビーシッターが走り続けるのも、この /loop 型の考え方です。
多数のループを無人で走らせる
単一の /goal は、1つのゴールへ向かう1体のエージェントです。
多数を無人で走らせると、賭け金が上がります。
ループは「自分の仕事を自分でチェックできる能力」の分しか信頼できないからです。
元記事が挙げる、長時間の自律運転に必要な5ステップは次の通りです。
- 権限を自動承認する: ツール呼び出しのたびに止まって確認しないようにします。
- 動的なワークフローで展開する: 1本の直列スレッドではなく、多数のエージェントに分散させます。
-
/goalか/loopで走らせ続ける: 完了条件かスケジュールで回し、状態を持ち越します。 - クラウドで走らせる: ラップトップを閉じてもセッションが生き残るようにします。
- 自己検証の手段を与える: Webならブラウザ操作、モバイルならシミュレータ、バックエンドならライブサーバーで、エンドツーエンドに確認させます。
5番目が、他の4つを安全にする要だと書かれています。
権限を開放して無人で走らせるほど、「自分で結果を確かめられること」が効いてきます。
元記事では、この5ステップを1つの流れとして次のように示しています（コマンド名は元記事のままで、現行版での動作保証ではありません）。
claude --permission-mode auto # 1. 確認プロンプトを出さない
ultracode orchestrate sub-agents to ship the feature # 2. 多数のエージェントへ展開
/goal all tests pass and the demo loads clean # 3. 完了条件を与えて走らせ続ける
→ cloud / desktop app # 4. ラップトップを閉じても継続
→ chrome ext · sim MCP · live server # 5. 自己検証してから出荷
権限の自動承認は、安全側の前提を置いて初めて成り立ちます。
具体的には、隔離されたサンドボックス、対象リポジトリやブランチの限定、支出上限、保護ブランチへの直マージ禁止、人間のレビューゲートです。
これらが無いまま全許可で走らせるのは危険です。
前述のPRベビーシッターも、いきなり本番へマージするより、まずは「マージ可能な状態にして人間に通知」から始めるほうが安全だと考えています。
プロダクト化されたループ — crabfleet
ここまでは「自分で組むループ」と「エージェント内蔵のループ」を見てきました。
オーケストレーションは、プロダクトとして見ると一気にイメージしやすくなります。
元記事は、Peter Steinberger の crabfleet（OpenClaw のプロジェクト。「エージェント実行のミッションコントロール」と銘打たれています）を、ループをそのまま製品化した例として挙げています。
形は、これまで述べた部品の組み合わせそのものです。
- ボード上のカードとして作業する: タスクはプロンプト・GitHub課題・PRからカード化され、未着手→実行中→レビュー待ち→完了へと動きます。このボードがループのキューであり、「停止して報告する」ステップを可視化したものです。
- 撃ちっぱなしではなく永続実行: 各実行はハートビート付きで追跡され、目を離しても走り、ラップトップを閉じても生き残ります。引き継ぎ対応が告知されたときだけ人間が代わります。
- エージェントがエージェントを生む: 1つの実行が子セッションを起動し、メッセージを送り、トランスクリプトを読み、サンドボックス内で自分の要約を更新します。ディスク上のメモリと展開（fan-out）が1か所に揃います。
これは使い捨てのクラウド・サンドボックスとブラウザ内ターミナルの上で動きます。
それが、無人実行から立ち去ることを安全にしている要素です。
要点は特定のツールではなく、ループがインフラへと固まったことです。
キュー・永続実行・展開・人間レビューのゲートは、毎回手書きするものから「設定するもの」へ変わりました。
このボード図を見て、自分の秘書エージェントの「出力前チェック」も、まさに human review ゲートと同じ役割だと気づきました。
誰が作っても、結局は同じ形に収束していくのだと感じます。
コストの考え方が変わる
ここは個人的にいちばん視点が変わった部分です。
この2年、AIコーディングのコストの問いは「どのモデルで、何トークンか」でした。
ループの内側では、その直感が指す層がずれます。
支出はもう単一の呼び出しではなく、「ループが何回回るか」だからです。
収束までに6回リトライするループは、同じモデルでも、1回で着地するループの6倍かかります。
だから最適化の対象が変わります。
- 見るべきはトークン単価より反復回数: 厳密にはコストは「トークン単価 × 入出力トークン × 反復回数 + ツール実行コスト」です。2倍の頻度で回る安いモデルは結局安くありません。呼び出し単価ではなく、完了タスク単価で見ます。
- 弱い検証役は、出荷しうる最も高くつくバグ: 「完了」の判定が緩いと、壊れた作業で早く止まるか、すでに良い作業を延々と回し続けます。どちらも反復まるごとを無駄にします。
- 早く失敗することはコスト管理: 連続失敗に上限が無いループは、いずれ成功するのではなく、いずれ口座を空にします。停止条件は、コードベースと同じくらい請求額を守ります。
「プロンプトをチューニングする」から「ループをチューニングする」へ。
コストが積み上がる場所が移った、という整理がしっくりきました。
ループにすべきでないとき・何が壊れるか
ループは万能ではありません。
元記事は「ループにすべきでない場面」も明示していて、ここが誠実だと感じました。
ループが報われるのは、タスクが繰り返され、かつ機械が完了を判定できるときです。
逆に、次の場合は空回りを自動化するだけになります。
- 単発の編集: 一発で終わるなら、ループは純粋なオーバーヘッドです。
- スコープ未定義・探索的な作業: 「ユーザーが離脱する理由を探れ」には合格条件がなく、収束しません。
- 安価な自動チェックが無いもの: 唯一の検証役が自分の目なら、まだループの内側にいます。
無人で走るループは、寝ている間に間違いも犯します。
失敗の型も予測できます。
- 検証の負担は人間に残る: ループは読むより速く書きます。差分を読むのをやめると、作業を消したのではなく先送りにしただけになります。
- 理解のギャップが広がる: 自分が書いていないコードを吸収より速く出荷すると、システムへの理解が痩せ、次の障害対応で跳ね返ります。
- 緩いチェックでの静かなドリフト: 弱い検証役は「間違っているが通る」作業を毎回通します。生産的に見えて、穴を掘り続けます。
どれもループ反対論ではなく、「だからループを設計する人の重要性が上がる」という話だと受け取りました。
自分なりの実践: AI秘書を「ループ」として設計してみた
ここからは自分の体験です。
私は Claude Code 上で、自作のAI秘書エージェントを運用しています（本記事では仮称として「秘書エージェント」と表記し、実際のディレクトリ名やファイル名は伏せます）。
役割は、私の代わりに調査・執筆・集計・実装を各担当（サブエージェント）に振り分けるオーケストレーターです。
作っている途中で、これはまさに元記事の言う「ループ」だと気づきました。
6つの部品に対応づけると、こうなりました。
- トリガー: 「日報」などのキーワードや、定期実行で起動します。
- 分離: 担当ごとに別コンテキストで動かします。ただし元記事の言う「ファイル衝突を防ぐ分離（worktree など）」までは至っておらず、いまは文脈の分離に留まっています。ここは弱点として残っています。
- 明文化された文脈: 文体や禁止事項などの規約をファイルに置き、毎回読ませます。
- ツール接続: 検索やファイル保存などを担当が内部で完結できるようにします。
- 独立した検証役: 成果物を私に出す前に、別エージェントの「出力前チェック」を通します。
- ディスク上の状態: 学びやガードレールをMarkdownに追記し、次回参照させます。
「出力前チェック」が何を見ているかを、機密を伏せて例示すると、次のようなものです。
- 成果物のファイルが実在し、中身が空でないこと
- 引用や事実に出典（URLや一次情報）が付いていること
- 「テストが緑」だけで完了にせず、実物や本番経路の確認結果が添えられていること
実際に運用して痛感したのは、元記事の「弱い検証役が一番高くつく」という指摘でした。
私のセットアップでは、最初これを甘く見ていて、痛い目を見ています。
ひとつは「誤green」です。
テストが通った（green）から完了、と判定したのに、本番の経路を通っていなかった、という失敗です。
チェックが「テストが緑かどうか」だけだと、ループは「緑だが間違っている」状態をすり抜けます。
それ以来、「テストが緑」だけで完了とせず、実物や本番経路で確認する一文を検証役に足しました。
もうひとつは、委譲したサブエージェントが「完了しました」とだけ返し、中身が空、という失敗です。
これは検証役の問題というより、委譲時の「返却契約」が弱かったことが原因でした。
何をどの形式で返すか、成果物をどこに保存するか、完了の判定条件は何かを、契約として渡していませんでした。
対策として、委譲時に「最終メッセージに成果物を全文含める」「重要な成果物はファイルに保存させ、返り値が空でもファイルから回収する」を契約に含めました。
ディスク上の状態を正にする、という6番目の部品が効いた瞬間でもありました。
この記事自体も、その秘書エージェントに「元記事を読んで全文と図をMarkdown化する」「日本語訳を作る」「Qiita記事化する」というループを回してもらいながら書きました。
ループの内側に座って毎回プロンプトを打つより、停止条件と検証役を先に決めるほうが、結果的に速くて安全でした。
自作システムの話は、再現性が環境に強く依存します。
ここで挙げた失敗と対策は「私の構成ではこう効いた」という一例です。
ベストプラクティスは状況によって変わるので、断定ではなく参考として読んでいただければと思います。
ループ設計のはじめかた
最後に、小さく始めるための手順を、自分の言葉で整理します。
- 反復可能なタスクを1つ選ぶ: PRのお守り、CIの修正、デプロイ検証など、定型作業から始めます。
- スコープをきつく絞る: 「課金まわりのバリデーションを直す。触るのはこのモジュールだけ」のように、対象を限定します。
- 予算と停止条件を与える: 最大試行回数・最大時間・最大ファイル数・最大連続失敗。無人で走るループは、無人で間違うループでもあります。
- 独立した検証役を足す: 別のエージェントに採点させます。コードを書いた本人は、完了判定の審判には向きません。
- 一定の頻度で走らせる: 間隔実行、cron、フック、CIなど。ラップトップを閉じても生き残る形にします。
- メモリをディスクに置く: モデルは実行のたびに忘れます。状態はコンテキストではなくファイルに残します。
順番にも意味があると感じます。
特に「3. 停止条件」と「4. 検証役」を先に決めておくと、暴走とコスト爆発の両方を同時に抑えられます。
まとめ
ループ・エンジニアリングは、「プロンプトを書く」から「コードを書くシステムを書く」への一段の引き上げです。
ループは6つの部品で組み立てられ、コストの主役はトークン数から反復回数へ移ります。
そして、いちばん効くのも壊れやすいのも「検証役」でした。
元記事の言葉を借りれば、いまや高コストで失敗しやすいのはモデルではなくループそのものです。
だから「実行を始める人」ではなく「成果物に責任を持つエンジニア」としてループを設計する、という姿勢が要になると考えています。
私自身、自作の秘書エージェントを「ループ」として捉え直したことで、停止条件と検証役を先に設計する癖がつきました。
自分はまず身近な反復作業を1つ選び、スコープ・予算・停止条件・検証役を決めて、小さく回すところから始めました。
同じ進め方が合う方もいると思います。
参考文献
- elvis (@omarsar0), "From Prompting Agents to Loop Engineering"（本記事の出発点となった元記事）
- Peter Steinberger (@steipete), ループの設計について: https://x.com/steipete
- Boris Cherny (@bcherny), エージェントを自律的に走らせることについて: https://x.com/bcherny
- Addy Osmani (@addyosmani), AI支援コーディングのループについて: https://x.com/addyosmani
- Matt Van Horn (@mvanhorn), "WTF Is a Loop?": https://x.com/mvanhorn
本記事の構成・文章の見直しと図の再現には生成AI（Claude）を併用しました。解釈・実践内容は筆者によるものです。検証した範囲は元記事との照合と筆者の環境での実践部分で、外部の発言やツール仕様は元記事に依拠しています。