プロンプトを書くのをやめた。ループを設計してAIエージェントを自律化する
1. 同じ週に三人が同じ言葉に辿り着いた
2026年6月のある一週間、三人のエンジニアが示し合わせたわけでもなく、ほぼ同時に同じ結論に至りました。
Peter Steinberger（OpenClaw作者、800万ビュー超の投稿で知られる）、Boris Cherny（AnthropicでClaude Codeを率いるエンジニア）、そしてAddy Osmani（GoogleのChromeチームのエンジニア）。三人は「自分でエージェントにプロンプトを入力するのをやめた、代わりにループを書いている」という趣旨の発言を、それぞれ独立して同じタイミングで公開しました。
Osmaniがその言葉を自身のブログ記事にまとめ、「Loop Engineering」と命名しました。同日Substackに転載され、一週間でこの用語は定着しました。
用語がこれほど速く浸透した背景には、コーディングエージェントがちょうど「放置してもそれなりの仕事をこなせる」水準に到達したタイミングがあります。スケジューリング機能がメジャーなハーネスに組み込まれ、エージェント一回の実行コストが下がり、繰り返し実行することが「もったいない」から「当たり前」に変わりました。その転換点が技術の側から言語の側へ表れた瞬間が、あの一週間でした。
2. 4層スタックの中のループの位置
2-1. プロンプト、コンテキスト、ハーネスの積み重ね
「XX Engineering」という命名スタイルはここ数年で馴染みになりました。プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリングは、それぞれが下の層の上に積み上がっています。
各層が「気にかける範囲の大きさ」を一段ずつ広げています。プロンプトは一回の交換で何を言うかを担い、コンテキストはそのウィンドウに何を詰めるかを、ハーネスは一回の実行をどう装備するかを扱います。ハーネスがあれば、エージェントは一度クリーンに動くようになります。ただし止まります。次のターンを始めるのはまた人間です。
2-2. ループが一フロア上に加えるもの
ループは「人間が待つ」という行為を自動化します。ハーネスの上に乗り、タイマーで目を覚まし、ヘルパーを生成し、自分の出力を次のラウンドの入力に戻します。「タイマーで起動する」「ヘルパーを生成する」「自己入力する」の3動詞がハーネスとループを分けます。
ただし、各層のどれかが不要になることはありません。プロンプトはなくならず、コンテキストもハーネスも残ります。ループはその上の層として乗り、実行するのでなく実行させ続ける仕組みを担います。
3. 一ターンを構成する5つの動作
3-1. Five Movesの全体像
論文が「一ターン」と呼ぶのは、ループが一回目を覚ましてから次の目覚めに備えるまでの全行程です。その行程は5つの動作で構成されます。
Discovery（発見） はそのターンで何を扱うかを決めます。エージェントが自ら仕事を見つけることが、このターンの品質の天井を決めます。誰かが毎朝「今日はこれを直してくれ」と入力する運用はDiscoveryをスキップしたブラインドループになります。Discoveryはskillファイルに書かれた知識として永続化され、毎ターン呼ばれます。
Handoff（引き渡し） はタスクを切り出してエージェントの手に渡します。一つの発見ごとに一つのworktreeが開かれ、並列エージェントが互いのファイルを踏み荒らさないよう物理的に隔離します。
Verification（検証） は「ノー」と言える唯一のチェックポイントです。コードを書いたエージェントが自分の出力を採点する運用では機能しません。検証は別のエージェント、別のモデル、できれば実際に動かして判断するエージェントに委ねます。
Persistence（永続化） は会話の外にある記憶です。コンテキストウィンドウが流れてもリポジトリは流れません。ループの記憶はdiskのMarkdownかボードに書かれてはじめて翌朝まで届きます。
Scheduling（スケジューリング） がループを「一回きりの実行」から「ループ」にします。タイマーかイベントで起動し、人間の記憶に依存しません。スケジューリングが欠けると、手動で毎回実行する「スクリプト」に成り下がります。
3-2. 各動作が欠けると何が起きるか
5つの動作は独立していますが、失敗は連動します。検証に無頓着なチームはたいてい永続化にも無頓着です。「ちゃんと動いているから大丈夫」という認識が全チェックを一緒に甘くします。逆に、最初の小さなループで5つ全部を入れた設計は、スケールしたときの恩恵が倍増します。
4. ループを動かす6つのパーツ
「5つの動作」が何をするかを定義するなら、「6つのパーツ」はそれをどう実現するかを定義します。
Automations はスケジューリングを担う実体です。GitHub Actionsのcronやclaude.aiのCloud Routinesがそれにあたります。Automationがない状態でSkillを呼び出すと一回きりの実行になります。
並列実行を支えるのがWorktreesです。gitの並列作業ディレクトリ機構で、`--worktree`フラグ一つで並列エージェントが同じリポジトリ内で独立したブランチに閉じ込められます。単一エージェントでは問題なく見えますが、5エージェントを走らせた翌朝に解決不能なコンフリクトが発覚するのがWorktreeなしの結末です。
Skills は「プロジェクト知識の永続化」です。プロジェクトのルール、トラップ、文脈をSKILL.mdに書いておけば、毎ターン再説明するコストが消えます。cronのwallにペーストされたプロンプトとは違い、誰かが更新できます。
Connectors はループを外部世界に繋ぐMCPフックです。イシュートラッカー、データベース、Slack、ステージングAPIに繋がり、コネクタがループの視野の広さを決めます。コネクタ1本の書き方が共通化できれば、別のループにそのまま持ち込めます。
Generator/Evaluatorパターン（次節で詳述）の実体がSub-agentsです。「書く者」と「採点する者」を物理的に分離する役割を担います。
会話が閉じてもリポジトリは残ります。その差を活かすのがMemoryです。state/triage.mdのような単純なMarkdownが、ループをまたぐ記憶になります。エージェントは忘れますが、リポジトリは忘れません。
5. 生成者と評価者の分離：自己採点バイアスの構造
5-1. なぜ生成者は自分の出力を褒めるか
AnthropicのエンジニアPrithvi Rajasekaranが実証した観察があります。エージェントに自分が生成したコードの採点を依頼すると、品質が明らかに凡庸であっても高得点をつける傾向があります。問題の根本は構造にあり、モデルが十分賢くても同じことが起きます。
コンテキストウィンドウには、そのコードをそう書いた理由が既に詰まっています。エージェントは自分の出力を「その出力に至った経緯」の光の中で見ています。問題のある出力を見ても「なぜそうなったか」の説明が手元にあるため、問題として見えにくいのです。ループではこのバイアスが増幅します。毎ターン「良い」と自己判定し、その判定が次のターンを走らせます。
5-2. 独立した懐疑的評価者の設計
解決策は構造にあります。プロンプトのwording（批判的な言葉を加える）を工夫するより、別のエージェントに委ねることが本質的な対策です。生成者のコンテキストを引き継がない評価者エージェントが、コードを「壊れている前提」で検査します。この考え方はGenerative Adversarial Networks（GAN）から借りています。GANでは一方が生成し、一方が欠陥を探します。
評価者が「読む」だけでは不十分という指摘もあります。RajasekaranはPlaywright MCPを経由して、実際にページを開き、ボタンをクリックし、スクリーンショットを撮って判断させました。判断の根拠が「このJSXは見た目が良い」から「ボタンを押したらここがスクリーンショットだ」に変わりました。行動して判断する評価者は、読んで判断する評価者より遥かに強いです。
評価者のデフォルト姿勢は「信頼するまで疑う」。褒めるのでなく、通過できない理由を探します。Claude Codeの評価者エージェント設定では次の一行が中心にあります。
ROLE: Adversarial code reviewer.
ASSUME: this code is BROKEN until proven otherwise.
DO NOT praise. Find what fails.ループの品質の天井は評価者が決める、とIEEE論文は断じています。生成者をどれだけ精密に調整しても、評価者が甘ければその天井を超えられません。
6. ループが壊れる5つのパターン
ループが動いているのに成果が出ない状況は、たいてい5つのうちどれかの動作がスキップされているか壊れています。失敗パターンを知ることは、設計のチェックリストとして使えます。
6-1. ノーディングループとアムネジアックループ
Nodding Loop（検証スキップ） が最も多い失敗です。ループが回る、エージェントがコードを書く、同じエージェントが「良い」と判定します。数百ターンを経て「一度もノーと言わなかった」ループは、現実のどんな作業負荷にもあり得ません。検証が機能していない証拠です。症状は「テストが全てパスしているのに、本番でのみバグが出る」という形で現れることが多いです。
Amnesiac Loop（永続化スキップ） は「発見した、やった、忘れた」を繰り返します。翌朝同じ問題を再発見し、場合によっては前のターンと競合する修正を入れます。disk上のstate fileが一行あれば防げる失敗です。エージェントは忘れますが、ファイルは忘れません。その差がループの累積的な進歩を生みます。
6-2. 残り3つのパターン
Manual Loop（スケジューリングスキップ） は毎回手で実行するスクリプトです。デモした当日は動き、翌日から注意が散り、気づけば最後の実行日がリリースデモの日だったループになります。トリガーは人の記憶に依存しない形（タイマーかイベント）でなければなりません。
Blind Loop（Discoveryスキップ） は毎朝「これを直せ」というリストを人が渡すループです。Discoveryの自動化を節約しているように見えますが、仕事を選ぶコストが最も高い部分を人間が肩代わりしています。Discoveryをスキルに書いてループが自ら仕事を見つけるようにすることが、真の自律化の入り口です。
Tangled Loop（Handoffスキップ） は複数エージェントが同じworking directoryを共有します。シングルエージェントでは問題なく見えますが、5エージェントを走らせた翌朝にマージできないコンフリクトが発覚します。一発見ごとに一worktreeが原則であり、タングルドループを防ぎます。
5つは独立していますが実際には連動します。検証に無頓着なチームはたいてい永続化にも無頓着です。節度のある最初のループが5つ全部を持っているのに対し、急ぎで作ったループはDiscoveryとHandoffの2つだけ持つ傾向があり、出力は出ますが制御できません。
7. 実例から読む「動いているループ」の条件
7-1. Stripeの週1,300件PR
Steve Kaliski（Stripeエンジニア）がポッドキャスト「How I AI」で語った内容によると、Stripe内部のMinionsはSlackのリアクションまたはメンションをトリガーにして起動します。モデルが動く前に決定論的なオーケストレーターが先に動きます。Sourcegraphでコードを検索し、Jiraのチケットを引き、MCPで関連ドキュメントを集めます。コンテキスト組み立ての「ルールで書ける部分」を全て確定論的処理で固め、その後にLLMがコードを書きます。
信頼性はモデルの規模からでなく制約の質から来る、というのが最も反直感的な教訓です。MinionsはGooseのフォーク上に動き、大規模モデルを使っているわけでもありません。強力な制約と確定論的ゲートが、モデルのキャパシティ以上の信頼性をもたらしています。
週1,300件のPRは今もエンジニアがレビューしています。「人間が去った」のでなく「人間がコードを書く席から、コードをレビューする席に移った」のです。この区別がループ設計の現実的な目標を定めます。
7-2. Osmaniの朝のトリアージループ
Osmaniが個人で組んだトリアージループは一人一台の機械で動きます。毎朝automationが起動し、Skills経由で前日の失敗CIテスト、未解決イシュー、最近のコミットを読みます。一つの発見ごとにworktreeを開き、サブエージェントがフィックスを書き、別のサブエージェントがプロジェクトのskillsとテストに照らして検証します。コネクタがPRを開きチケットを更新します。判断できなかった案件はinboxに落ちます。人間の手が必要な場所だけに人間が待っています。
Stripeとは規模が対照的ですが、骨格は同じです。トリガー、skill経由のdiscovery、worktreeでのisolation、独立evaluator、disk上のstate file、human checkpointの6つが揃っています。スケールが違っても設計の原則は変わりません。
8. ループが静かに積み上げる4つのコスト
8-1. Verification DebtとComprehension Rot
ループは「稼ぐ」だけでなく「積み上げる」側面もあります。4つのコストは音もなく発生し、まとめて請求書が届きます。
Verification Debt はテストが検出しない隙間に積まれた未検証の出力です。毎回PRをレビューせず通した分が、いつか本番インシデントになって返ってきます。20件のPRが全てグリーンテストで通ったとき、そのうち3件に微細なエラーが眠っていても気づきません。独立evaluatorが唯一の防御線です。
Comprehension Rot はコードを読む速度よりコードが書き換わる速度が速いときに起きます。ループは人間が書かなかったコードを積み上げます。読んでいないコードが増えるほど、変更の影響を予測できなくなります。サンプリングして定期的に読み、説明できる状態を保つことが唯一の対処です。
8-2. Cognitive SurrenderとToken Blowout
Cognitive Surrender は「ループが何とかしてくれる」という態度の慢性化です。ループは実行しますが、決定はできません。判断を外注し続けた先に「自分がloopの設計者か、それともloopが通じない機械の番人か」という分岐があります。その分岐は6ヶ月後に可視化されます。片方はloopの上に乗り、もう一方はloopに乗っ取られています。
Token Blowout は唯一直接財布に当たるコストです。バグを抱えたまま夜通しhelperを生成しリトライし続けたループが、予想の3倍の請求書を出すことがあります。一回あたりの予算上限、日次上限、最大リトライ数の3本のキャップが、ループの支出権限を取り上げます。これはコスト節約でなく、バグ一件がquotaを使い切ることを防ぐ回路ブレーカーです。
4つのコストは互いを強化します。未検証の出力が積まれるほど人間の理解は遅れます。理解が遅れるほどループに任せたくなります。任せるほど長く走ります。長く走るほど請求が膨らみます。切るのは「独立した検証チェックを入れる」一手です。
9. 生成コストが安くなると判断の価値が変わる
生成コストが限りなくゼロに近づくとき、それを中心に組まれていた活動が再編されます。コード、プラン、PRは「ほぼ無償」になります。残るのは「どれを残すかの判断」です。
エンジニアとしての価値が「高速タイピング、API暗記、ボイラープレートを厭わない忍耐」に置かれていた人は、ループがそれを全部やり始めたとき価値が消えます。判断に価値を置いていた人は、ループがその判断を百倍の速度で実行し始めたとき価値が増幅します。
ループは掛け算の記号です。持ち込んだものを増幅します。怠惰を持ち込めば怠惰を増幅し、判断を持ち込めば判断を増幅します。これが同じループを二人が組んで逆の結果を得る理由であり、ツールの差でなく設計思想の差で決まります。
「エンジニアとして残る」か「ボタンを押す役になる」かの分岐は、ループの有無ではありません。ループの中に入れたチェックポイントの数で決まり、6ヶ月後に分かります。
10. 静かに回るループを維持する3つの運用規律
サンプリングを毎日読む。 ループの全出力を読むことが目的でなく、毎日代表的なサンプルを一つ取り出し、なぜそうなったかを一文で説明できる状態を保ちます。説明できないときは、メンタルモデルがコードベースに遅れをとっています。静かな朝にそれを発見できれば、本番インシデントになる前に対処できます。
出荷前にキャップを設定する。 予算上限、日次上限、最大リトライ数の3本は、ループが初めて夜通し放置される前に入れます。最初に驚く請求書が来てから入れるのでは遅いです。この数字はコスト節約でなく、バグが1件のquotaを使い切ることを防ぐ回路ブレーカーとして機能します。
ループには必ず一ヶ所、人間が介入できるポーズを入れます。全てをauto-mergeにしたエンジニアは、いざ介入が必要な日にループの鍵を持っていないことに気づきます。PRは開きます。auto-mergeはしません。不確かな案件は./inboxに落とします。これがドアを開けておく書き方です。
11. 最初のループを今日作る
Stripeのパイプラインは終着点であり、出発点ではありません。最初のループは「タイマーで何かをチェックするだけの、ほとんどシステムに見えない小さなもの」でかまいません。
Claude Codeなら`/loop 5m check the deploy`から始められます。ただしこれはSchedulingとDiscoveryの部分だけです。翌日には状態ファイルを追加し、その翌日には評価者を追加します。評価者を追加した瞬間、はじめて「ループ」になります。
6要素のうち、最初の2つ（DiscoveryソースとState file）がループを回るかどうかを決め、残り4つがループが問題に入ったとき止まれるかどうかを決めます。多くの初期ループが最初の2つだけで出荷した結果、誰も見ておらず誰も止められないループが完成します。
最初のループに検証と人間レビューのポイントを入れることは過剰に見えます。しかし6ヶ月後、そのループが1,000ターン走った先で「どこかで最初にノーと言えたはずなのに」という状況を避けるために、最初のループにノーを言える仕組みを入れます。
「ループを組め、ただしエンジニアとして組め」とOsmaniは最後に書きました。ループを設計する人が増えるほど、その一行の意味の重さが増します。
参考資料：
