プロンプトからループへ — AIを「自分で回す」loop engineering の正体

概要

AIは何年も前から誰の手にもある。だが毎日使う人の多くが、最も遅い使い方を続けている。要求を打ち、待ち、直し、また聞く。すべて手作業だ。

別の使い方がある。goal（目標）を一度だけ渡し、AIに手順そのものを回させるやり方だ。AIが計画し、作業し、自分で結果を検証し、弱い所を直し、目標を満たすまで繰り返す。人は途中で抜ける。作業は止まらない。

これを loop engineering（ループ工学） と呼ぶ。Claude Code のエンジニア Boris Cherny や Addy Osmani が広め、開発者 Peter Steinberger はこう言い切った。

「coding agent にもうプロンプトを打つべきではない。agent にプロンプトを打つ loop を設計すべきだ」 — Peter Steinberger（X, 2026年6月8日）

prompt は1回の指示だ。loop は、達成するまでAIが回し続ける goal だ。この違いが、いまトップエンジニアが最も注目している一点になっている。

詳細

prompt と loop は何が違うか

prompt は1つの答えを返し、次にどうするかをあなたの判断待ちにする。loop は5段階のサイクルを自分で回す。

DISCOVER  →  何をすべきか洗い出す
PLAN      →  どうやるか決める
EXECUTE   →  作業する
VERIFY    →  goal に照らして検証する
ITERATE   →  未達なら結果を戻して繰り返す

観点	prompt	loop
渡すもの	1つの指示	goal + 完了判定 + 諦める条件
駆動するのは	あなた（エンジン）	AI自身
止まるとき	毎回あなたの判断	成功 or 上限到達
あなたが抜けたら	止まる	動き続ける

肝は3つ。ここを外すと壊れる

5段階のうち、実質的な仕事をするのは3つだ。そしてここで皆つまずく。

Verify（検証）がループの心臓だ。 結果への本物のチェックがなければ、それは loop ではなく「agent が自分に賛成し続けるだけ」になる。チェックはハードテスト（コードが通るか）、測定可能な条件（数値がX以上か）、rubric による採点のいずれかだ。ゲートがなければ、作業したモデルが自分の宿題を採点する。採点者として甘すぎる。

State（状態）がループを学習させる。 各周回でAIが「何を試したか」を覚えていなければ、同じ失敗を永遠に繰り返す。本物の loop は、何が done で何が failed で次は何かを外部に小さく記録する。翌日の実行はゼロからではなく再開になる。

Stop condition（停止条件）が正気を保つ。 出口のない loop は、成功するか壊れるか口座を空にするまで走る。本気の loop は2つの止め方を持つ。成功と、ハード上限（8回試したら止めて報告）だ。

prompt はAIに指示を渡す。loop はAIに、仕事と、完了の判定基準と、諦めるルールを渡す。

そもそも loop が必要か

多くの記事は loop を売り込むが、いつ「罠」になるかを言わない。本気の人が使う判定はこうだ。4つすべてが真のときだけ loop を作る価値がある。

条件	説明
反復する	最低でも週1回。一度きりなら1つの良いプロンプトで十分
自動で不合格にできる	test・type check・build・linter・ハードルール。失格機構がなければ空回りする
AIが端から端まで自走できる	途中で人に投げ返さない
「完了」が客観的	品質が主観なら人間が勝つ

1つでも欠けたら、手動プロンプトのままにする。loop engineering は本物だが、多くの人にまだ重い版は要らない。

コードでの実装 — 5つの構成要素

loop はソフトウェアで先に普及した。コードは検証が世界一簡単だからだ。test は通るか落ちるかで、議論の余地がない。Claude Code と Codex は、本物の loop を組む5要素をすべて備える。

要素	役割	Claude Code での例
自動化（心拍）	スケジュールで自走させる	`/loop`・`/goal`・hooks・cron / GitHub Actions
skill	再利用する指示をファイル化	`.claude/skills/` に保存し名前で呼ぶ
sub-agent	作る側と検証する側を分離	writer は速く安く、reviewer は厳しく
connector	提案でなく実行させる	PR を開く・ticket を起票・通知する
verifier	不合格にするゲート	test / type check / build

最も効くのは sub-agent による「作る側」と「検証する側」の分離だ。コードを書いたモデルは自分の採点に甘い。別の指示を持つ第二の agent（時に強いモデルを高 effort で）が、第一の agent が言いくるめた穴を捕まえる。この分離が品質のほとんどを生む。

Ralph Wiggum loop — 最小構成の本質

loop の本質を最も裸に示すのが、Geoffrey Huntley が2025年に提唱した Ralph Wiggum loop だ。Anthropic は後にこれを公式プラグイン化した。

仕組みは拍子抜けするほど単純だ。同じプロンプトを agent に繰り返し食わせる。 進捗は LLM のコンテキストではなく、ファイルと git 履歴に溜める。

# Ralph Wiggum loop の骨格（概念）
while true; do
  # 毎回 PROMPT.md + AGENTS.md + specs/* を読み直す
  # IMPLEMENTATION_PLAN.md（ディスク上の state）から続きを判断
  agent run --prompt PROMPT.md
  # 失敗は次の周回にコンテキストとして戻る
done

肝は IMPLEMENTATION_PLAN.md がディスクに残り、孤立した各周回の共有 state になる点だ。各周回で agent は過去の試行と失敗を突きつけられる。Huntley はこれを「contextual pressure cooker（文脈の圧力鍋）」と呼ぶ。モデルは自分の散らかしと向き合い、最終的に loop を抜ける正解にたどり着く。

Claude Code はこの用途を /loop（プロンプトを間隔実行）、/goal（条件が真になるまで継続）、/batch の3プリミティブで吸収する。

コストは静かに膨らむ

loop は token で動く。token は金だ。問題は、コストが複利で膨らむことだ。

1 agent・中程度のタスク1回:      約 5万 – 20万 token
周回ごとに再送されるコンテキスト:  毎回大きくなる
並列で agent を fleet 化:         上記すべてを掛け算

周回のたびに agent は goal・コード・直前の結果・失敗を読み直す。10回回す loop は「10プロンプト」ではなく「毎回大きくなる10プロンプト」のコストになる。maker-checker で品質を上げると、2つのモデルが読むので請求も倍になる。

本当に見るべき指標は cost per accepted change（採用された変更あたりのコスト） だ。10個の結果のうち6個を捨てるなら、loop が省くはずのレビューを自分でやっている。採用率が50%を切れば、loop は与えるより多くを奪う。

loop は静かに失敗する。Huntley の言う「Ralph Wiggum loop の罠」は、agent が早すぎる段階で「完了した」と判断し、半端な仕事で抜け、loop は何も生まないまま金を使い続ける状態だ。ハードゲートがなければ、loop はクラッシュせず、沈黙のまま請求する。

作る順序が、道具より大事

production で生き残る loop を作る人は、全員この順序を守る。

1. まず手動の1回を確実に動かす
2. それを skill 化する（指示を保存）
3. skill を loop で包む（ゲート + 停止条件を足す）
4. それから初めてスケジュールに載せる

手で確実にしていないものをスケジュールに載せるのが、寝ている間に loop が暴発する典型だ。一度証明し、固め、それから自動化する。

どのLLMでも作れる最小ループ

coding agent がなくても、プロンプト1枚で loop の感触はつかめる。goal・厳格な成功基準・自己検証を強制するプロトコルを一度に渡すのがコツだ。

タスクが基準を満たすまで loop で作業せよ。

TASK:
[作りたいものを正確に記述]

SUCCESS CRITERIA（厳格に。甘い合格を出さない）:
- [基準1]
- [基準2]

LOOP PROTOCOL（毎ターン繰り返す）:
1. PLAN   - 次の1ステップを述べる
2. DO     - 作業を生成 or 改善する
3. VERIFY - 各基準を1-10で採点。残る弱点を正直に列挙
4. DECIDE - 全基準8以上なら "FINAL" と出して停止。
            それ未満なら "ITERATING" と出し、最弱点から直して継続

RULES:
- 全基準8以上になるまで done としない
- 各周回は前回 VERIFY の最弱スコアを必ず直す
- 質問はせず、妥当な仮定を置いて進める

開始。FINAL になるまで loop を回せ。

ただし、この自作版に欠けているものに注意する。トリガーがあなた自身だ。 タブを閉じれば消える。スケジュールも、イベント起動も、向こうから連絡してくる機能もない。自走する loop が欲しければ、前述の重い世界（道具・ホスティング・ゲート・請求）に踏み込むことになる。

日本への示唆

日本のエンジニアにとって、loop engineering は2つの意味で効く。

第一に、検証文化との相性だ。loop の心臓は VERIFY、つまり自動で不合格にできるゲートだ。test・type check・CI を整備している現場は、そのまま loop の verifier に転用できる。逆にテストが薄い現場は、loop を載せても「agent が自分に賛成し続ける」だけになる。loop の前提は、まず検証基盤の整備だ。

第二に、コスト管理の規律だ。日本企業はAI導入で「最強モデルを選ぶ」議論に時間を使いがちだ。だが loop で効くのは cost per accepted change の管理である。安いモデルを退屈な工程に、強いモデルを検証だけに割り当てる。iteration 上限と token 予算を必ず置く。これは地味だが、請求書を破滅させない唯一の防具だ。

観点	重い版（自走 loop）	軽い版（手動 loop）
向く相手	予算とガードレールを持つチーム	個人・小規模
必要なもの	道具・ホスティング・監視	プロンプト1枚
主なリスク	沈黙の暴走課金	ほぼなし
着手の順序	手動 → skill → loop → 自動化	いますぐ試せる

結論はシンプルだ。まず無料・手動の loop から始める。 足りないと体感してから、初めて重い版に何が必要かを考える。最初から fleet を組むのは、ほとんどの場合ただ金を燃やす。

まとめ

prompt は1回の指示、loop は達成まで回す goal。トップエンジニアの関心はいま loop の設計にある
5段階は DISCOVER → PLAN → EXECUTE → VERIFY → ITERATE。肝は Verify（ゲート）・State（記録）・Stop（停止条件）
loop を作る価値があるのは「反復する・自動で不合格にできる・自走できる・完了が客観的」の4条件が揃うときだけ
コードでの実装は5要素（自動化・skill・sub-agent・connector・verifier）。Claude Code は /loop・/goal・/batch で吸収
最小構成は Geoffrey Huntley の Ralph Wiggum loop。state をディスクに置き、同じプロンプトを回す
コストは複利で膨らむ。見るべきは cost per accepted change。採用率50%未満なら loop は損
作る順序は「手動 → skill → loop → 自動化」。手で確実にしていないものを自動化すると暴発する

AIがあなたを待つのをやめ、仕事そのものを回し始める。それが loop だ。ただし、合わない場所に押し込めば金を燃やすだけになる。まず無料で手元のものを使い、足りないと感じてから次を考える。

概要

詳細