2026年の6月、3人の人物が独立して1週間のうちに同じアイデアにたどり着いた。
OpenClaw の開発者である Peter Steinberger は、コーディングエージェントにプロンプトを与えるのをやめ、それらにプロンプトを与えるループを設計すべきだと公言した。ほぼ同時期に、Anthropic で Claude Code を率いる Boris Cherny は、もはや Claude に直接プロンプトを与えることはなく、Claude にプロンプトを与えて何をすべきかを判断するループを実行しており、自身の実際の仕事はループを書くことだと述べた。その数日後、Google のエンジニアである Addy Osmani がこの概念を書き留め、「ループエンジニアリング」と名付けた。
彼らの誰もがゼロからこの手法を発明したわけではない。彼らは、すでに起こっていたことに名前をつけた。その背後にあるツールが静かに閾値を超えていたからだ。コーディングエージェントは、無人でも実際のタスクを完了できるほど信頼できるようになっていた。スケジューリングは、タイマーでタスクを繰り返し実行しても無駄に思えないほど安価になっていた。単一のエージェント実行のコストは、慎重に一度考えるよりも、5回試行する方が安価になるほど下がっていた。
この閾値こそ、このロードマップが存在する理由である。プロンプティングは、人間がキーボードに座ってエージェントを一行ずつ指示する必要があった時代のスキルだった。ループエンジニアリングは、エージェントに目標を与えて放置できるようになった今のスキルである。これは、一方から他方への完全な20ステップの道のりであり、順序が重要である。なぜなら、順序は個々のステップよりも重要だからだ。
ステップそのものの前に、順序が特に重要である理由を説明する。ループエンジニアリングは、持っているか持っていないかの単一のスキルではない。それは積み重ねであり、各層はその下の層が実際にしっかりしていることに依存している。ステップ14のスケジューリングトリガーを、ステップ10の実際の停止条件を持つ前に構築することは、あなたが見ている間だけでなく、無人でもお金を無駄に使うことができるシステムを自動化したことを意味する。ステップ11の永続化を、ステップ6と7の実際の検証を持つ前に構築することは、不良出力を承認するだけのジャッジから学んだ教訓を注意深く記録していることを意味し、永続化層を単に役に立たないだけでなく、積極的に有害にする。このリストで先に進むことは、単に機能を逃すことを意味するわけではない。それは、実際に支えられない基盤の上にエキサイティングに見える部分を構築し、何かが大規模にすでにうまくいかなくなった後にのみそれを発見することを意味する。
フェーズ1: マインドセットの転換 (ステップ1から4)
ステップ1: ボトルネックはモデルではなく、あなた自身であることを受け入れる
最初の本当のステップは技術的なものではない。現在のワークフローにおける制限要因はモデルの能力ではなく、ループ内におけるあなた自身の存在であることを認めることだ。毎回座って応答を待ち、それを読み、次の指示を入力するたびに、あなたはシステムの中で最も遅い部分である。モデルは、あなたが監督できるよりもはるかに速く行動し、検証し、再試行できる。
このステップにはプロンプトは付属しない。それは決断である。これを実際に信じるまでは、それ以降のすべてのステップが、本来の目的である実際のボトルネックの除去ではなく、不必要なオーバーヘッドのように感じられるだろう。
ステップ2: より長いプロンプトをより良いシステムと混同するのをやめる
何かがうまくいかないときの本能は、同じプロンプトに別の指示を追加することだ。何ヶ月も続けると、これは密度が高く、自己矛盾したルールの壁のようなプロンプトを生み出し、モデルはもはやワーキングメモリにすべてを保持できなくなり、最も最近のもののように見えるパターンにマッチして、残りを静かにドロップする。
ループエンジニアリングはこの本能を完全に置き換える。プロンプトに別のルールを追加する代わりに、システムに別のコンポーネントを追加する。検証ステップ。メモリファイル。スケジュールされたトリガー。プロンプト自体は、周囲のシステムがより有能になるにつれて、時間の経過とともに短くなるべきであり、その逆ではない。
ステップ3: すべてのタスクを5つの動きとして見ることを学ぶ
ループの個々のターンは、特定のドメインに関係なく、5つの動きに分解される。ディスカバリー（発見）、実際に何が起こる必要があるかを把握する。ハンドオフ（引き継ぎ）、タスクを実行するものに渡す。ベリフィケーション（検証）、結果を実際の何かと照合する。パーシステンス（永続化）、何が起こったかを記録して失われないようにする。スケジューリング（スケジューリング）、次にいつ実行するかを決定する。
ほとんどの人の現在のワークフローでは、これらの動きのうち2つだけが明示的であり、ディスカバリーとハンドオフは、チャットウィンドウで手動で行われている。他の3つは存在しないか、本人の頭の中で目に見えない形で行われている。ループエンジニアリングとは、これら5つの動きすべてを明示的かつ自動的にする実践である。
ステップ4: 最初の実際の候補タスクを特定する
何かを構築する前に、あなたがすでに繰り返し行っているタスクを1つ選び、その基準を尋ねられたら書き留められるようにする。最も難しい問題ではない。まったく新しいことではない。明確な完了の定義があり、同僚が見てすぐに正しく完了したかどうかを判断できるタスク。この制約は見た目以上に重要である。完了の明確な定義がないタスクには、ステップ3の検証を構築することができず、実際の検証のないループはループではなく、単なる無人での推測に過ぎない。
フェーズ2: 最初のループの構築 (ステップ5から9)
ステップ5: プロンプトを書く前に、完了の定義を書く
これはほとんどの人がスキップするステップであり、その後のすべてが機能するかどうかを決定するステップである。エージェントに1つの指示を書く前に、平易な言葉で、正しい結果がどのように見えるかを正確に書き留める。具体的でチェック可能な基準であり、あいまいな品質感覚ではない。
[タスク名] の完了の定義 (DEFINITION OF DONE):
- [具体的でチェック可能な基準 1]
- [具体的でチェック可能な基準 2]
- [具体的でチェック可能な基準 3] このタスクは、上記のいずれかが欠けている場合、アウトプットが完全または洗練されて見えても、完了したとは見なされない。
選択したタスクに対してこれを記入できない場合は、ステップ4に戻って別のタスクを選ぶ。
ステップ6: ビルダーとジャッジを分離する
あらゆるループにおける最も重要なアーキテクチャ上の決定。作業を生成する役割と作業をチェックする役割は分離されなければならない。なぜなら、モデルが自身のアウトプットを生成したのと同じ文脈でレビューすると、そのアウトプットを真に精査するのではなく、擁護する傾向があるからである。
ビルダーは創造的な自由度を与えられ、最初の試行を生成する。ジャッジは、ビルダーのアウトプットとステップ5の完了の定義を受け取り、それ以外は何も与えられない。理想的には、ジャッジはビルダーが持っていないもの、つまりテストスイート、元のソースドキュメント、ライブデータにもアクセスできるため、その判定は、最初のものと同じ方法で形成された単なるセカンドオピニオンではなく、実際の証拠に基づくものとなる。
ステップ7: ジャッジに単なる意見ではなく、グラウンドトゥルースを与える
ビルダーのアウトプットしか見ないジャッジは、それが一貫しているように見えるかどうかを教えてくれる。しかし、それが実際に正しいかどうかを教えてくれるわけではない。コーディングタスクの場合、グラウンドトゥルースはテストスイートと実際の実行出力である。コンテンツタスクの場合、それは元のソースマテリアルとブリーフを、ドラフトと並べて比較することである。リサーチタスクの場合、それは使用されるべきだった実際のドキュメントである。
ジャッジがチェックする具体的なグラウンドトゥルースを指定できない場合、ジャッジの言葉の自信に関係なく、あなたのループにはまだ実際の検証がない。
ステップ8: ハンドオフプロンプトを書く前に、ハンドオフフォーマットを書く
ビルダーのアウトプットとジャッジの判定はどちらも、自由な散文ではなく、定義された構造を持つ必要がある。そうでなければ、次のステップのマネージャーはルーティングするための信頼できるものを持てない。
ビルダーアウトプット: 成果物 + 自信度 + 既知の不確実性
ジャッジ判定: パス / 不合格 / 修正が必要 + 特定された問題 + これがチェックされたグラウンドトゥルース
ステップ9: 自動化する前に、一度手動で完全に実行する
スケジューリングや自動リトライを配線する前に、ビルダー→ジャッジのシーケンス全体を自分で手動で一度実行する。ジャッジの判定を批判的に読む。あなたはそれに同意しただろうか？ もしジャッジがあなたが間違っていると知っているものをパスした場合、または実際には問題なかったものを不合格にした場合、先に進む前にグラウンドトゥルースまたは基準を修正する。壊れた検証ステップを自動化することは、より速く壊れた結果を生み出すだけである。
ステップ5から9までの実例
最後の5つのステップを具体的にするために、実際の一般的なタスク、つまり生のソースドキュメントを完成されたコンテンツに変換するタスクでそれらがどのように機能するかを示す。
ステップ5の完了の定義: ドラフト内のすべての事実の主張は、ソースドキュメントに実際に存在するものに遡ることができる。ドラフトは、ブリーフ内のすべての特定の要件（長さ、トーン、必要な構造）を満たしている。コアとなる議論は、フィラーによって薄められることなく、明確に生き残っている。
ステップ6のビルダーは、ソースとブリーフを受け取り、ドラフトを生成する。また、執筆中に不確かだった点、つまりソースに完全には含まれているか確信が持てなかった数字、明示的に述べられるのではなく推測した主張を明示的に記述する。
ステップ7のジャッジは、ドラフトと元のソースを並べて受け取り、ドラフトだけを見ることは決してない。そして、3つの完了の定義の基準をそれぞれ個別にチェックし、1つのブレンドされた全体スコアではなく、各基準に個別にパスまたは不合格を返す。3つの異なるチェックを単一の判定にまとめることは、実際にどの次元が失敗したかを正確に隠してしまう。これは、機能しているループが静かに有用なフィードバックを与えなくなる最も一般的な方法である。
ステップ8のハンドオフフォーマットは、ジャッジの判定が、ヘッジされた散文の段落ではなく、構造化されたオブジェクトとして届くことを意味する。3つの明示的なパスまたは不合格の結果に、それぞれの失敗に特定の理由が付けられる。
ステップ9に従って、自動化する前にこれを一度手動で実行することは、ジャッジが寛大すぎる場合、つまり、執筆スタイルが洗練されていたため、捏造された統計を含むドラフトをパスしてしまう場合や、厳しすぎる場合、つまり、実際にはブリーフに含まれていなかったスタイル上の好みのためにドラフトを不合格にしてしまう場合をキャッチする。どちらの失敗モードも最初の試行では一般的であり、どちらも、ループがすでに50回無人で実行された後に発見するよりも、手動で一度キャッチする方がはるかに安価である。
フェーズ3: ループの欠けているピースを追加する (ステップ10から14)
ステップ10: マネージャーとその停止条件を構築する
マネージャーはジャッジの判定を読み、次に何が起こるかを決定する。ここにループの停止条件も存在し、それはハードロジックとして記述されなければならず、モデルが回避できるソフトな指示であってはならない。
停止条件:
最大修正回数: 3回。3回目の不合格判定で、完全な履歴とともに人間にエスカレーションする。4回目のサイクルを試みない。
品質しきい値: 完了の定義のすべての項目が「パス」を示さなければならない。
予算上限: このタスクが [X] コストまたは [Y] 時間を超えた場合、現在の状態に関係なく直ちに停止する。
実際の停止条件のないループはシステムではない。それは、タスクが本当に解決不可能であることが判明した日のための責任である。ソフトな指示がここで失敗する特定の理由は、単に受け入れるのではなく、理解する価値がある。プロンプト内の「十分に良くなったら止める」は提案であり、十分なプレッシャー（すでに数回の修正に失敗している）の下にあるモデルは、タスクに満足のいく解決策を生み出したいという欲求から、現在の試行がパスするのに十分近いと自分自身に信じ込ませることがよくある。コードによって機械的にチェックされるハードな反復カウンター、またはマネージャーが回避できない明示的なルールには、そのような失敗モードはない。
ステップ11: 永続化を追加する。ループが実行間で記憶できるようにする
毎回ゼロから始まるループは、前回学習したことを記憶していない。シンプルな永続化層を追加する。真に新しい教訓ごとに1つのファイルとし、上部に1行の要約を付け、何が学習され修正されたか、そしてなぜそれが重要だったかを記録する。重要なのは、他の場所で既にキャプチャされていないものだけを記録することである。重複したメモリはノイズであり、知識ではない。
このステップを長期にわたって実際に機能させる規律は、書き込み時の抑制である。本能はセッションで起こったすべてをログに記録することであり、これはまさに、このロードマップがステップ2で警告した、肥大化したトランスクリプトの問題を、プロンプトの代わりにメモリフォルダに移動しただけのものを生み出す。書き留める価値のある教訓とは、忘れられた場合に再発見するのに実際の時間がかかるものであり、期待通りに成功したルーチンワークの記録ではない。
ステップ12: スケジュールに従って統合パスを追加する
永続化だけでは、最終的には肥大化したプロンプトと同じ問題、つまり多数のファイルが、同じことのわずかに異なるバージョンを言っている状態を生み出す。定期的なスケジュール（週1回が妥当）で、メモリファイルをレビューし、重複を単一のよりシャープな教訓にマージし、後に誤りであることが証明されたものを削除する。目標は、ファイル数を減らし、各ファイルの密度を高めることであり、決して増え続ける山ではない。
このステップは、ほとんどの人が完全にスキップするステップである。なぜなら、それ自体では目に見える新しい機能を生み出さず、将来の問題を防ぐだけだからである。その見えにくさこそが、メモリフォルダが扱いにくくなったことに誰かが気づいたときに任せるのではなく、明示的にスケジュールする必要がある理由である。実際には、矛盾した、半分だけ関連する教訓が同じコンテキストウィンドウを競い合い、ループのパフォーマンスがすでに低下し始めるまで、それは決して起こらない。
ステップ13: リコールステップを追加する
新しい実行の開始時に、ループにメモリ内の1行の要約をスキャンさせ、現在のタスクに実際に関連する教訓を特定させ、それらのみをロードさせる。メモリが適用されない場合にはそのように明示的に述べるように指示し、メモリが存在するという理由だけで、関連のない過去の教訓を新しい状況に無理やり当てはめないようにする。
ステップ14: スケジューリングトリガーを追加する
このループを手動で起動しなくても実行するタイミングを決定する。cron ジョブ。ファイル監視。定期的なカレンダー駆動のトリガー。このステップは、オンデマンドで実行するシステムを、あなたが寝ている間に実行するシステムに変えるステップであり、通常、このリスト全体の中で最も簡単なステップであり、他のすべてを構築した後でも、ほとんどの人が実装しようとしないステップである。
フェーズ4: スケーリングと強化 (ステップ15から18)
ステップ15: 信頼する前にループをストレステストする
このループを実際の何かに依存する前に、4つの失敗モードに対して意図的にテストする。
本当に解決不可能なバージョンのタスクを与え、マネージャーが実際に無限ループするのではなく停止することを確認する。完了できるタスクでのみテストされたループは、優雅に失敗する方法を知っていることを実際に示したことがないからである。
ジャッジに、あなたが微妙に間違っていると知っているアウトプット、つまり、よく読めるが、あなたが意図的に仕込んだ特定の事実上または論理上の誤りを含むものを与え、もっともらしく聞こえるものをパスするのではなく、実際にその欠陥をキャッチすることを確認する。
ビルダーとジャッジが同じ基礎モデルを共有している場合、そのモデルが特徴的に犯す間違いをジャッジに与え、それがその間違いを素通りするかどうかを確認する。ビルダーの盲点を共有するジャッジは、ステップ6の分離の目的全体を無効にする。
最も高価なモデル呼び出しと最も長い合理的な出力を使用して、ループが最大修正回数制限まで実行された場合の最悪のコストを計算し、その数字が実際の請求書に表示された場合にあなたを驚かせるかどうかを正直に判断する。
これらの4つのテストを、重要なものにループを任せる前に実行することは、そうでなければクライアント、上司、またはあなた自身の銀行取引明細書の前で初めて現れるであろう失敗の大部分を、意図的に実行した管理されたテストではなく、キャッチする。
ステップ16: 毎回同じモデルではなく、適切なモデルにタスクをルーティングする
ループが機能するようになったら、そのすべての部分をあなたのお気に入りの単一のモデルで実行する習慣に抵抗する。ビルダーの役割は通常、最も有能なモデルの恩恵を受ける。なぜなら、それは実際の難しい推論を行っており、ここで弱いモデルを使用すると、最初のドラフトが悪化し、それを修正するためにより多くの修正サイクルを必要とし、最初からうまく生成するよりもコストがかかるからである。
特定の書面による基準に対してチェックするジャッジの役割は、多くの場合、より小さく、より安く、より速いモデルでも同様に信頼性が高い。なぜなら、創造的であることを求められているのではなく、一貫性があることだけを求められており、非常に明確に指定されたチェックリストに対してチェックする小さなモデルは、多くの場合、コストとレイテンシのごく一部で、より大きなモデルに匹敵するからである。
すでにあなたが書き留めたルールに基づいてルーティングするマネージャーは、ほとんどあなたの最も高価なモデルを必要としない。なぜなら、その仕事は、あなたがすでに指定したロジックを実行することであり、オープンエンドの推論ではなく、ビルダーとジャッジのパフォーマンスに関係なく、少なくとも反復ごとに1回実行されるため、その呼び出しあたりのコストは、生の能力よりも重要になるからである。
この階層化されたアプローチ、つまり、構築には高価なモデル、ルーチンチェックには安価で一貫性のあるモデル、ルーティングには安価なモデルというアプローチは、通常、ループ内で実際のコスト削減がもたらされる場所である。ほとんどの人は、コスト管理とはループの数を減らすか、修正回数を減らすことだと思い込んでいる。実際には、それは、すでに構築したループ内の各特定の役割の実際の難易度にモデルコストを一致させることから生じる。
ステップ17: 2つ目のループに拡張する。一度に5つではなく
最初のループが機能すると、すぐにさらにいくつかを構築し、アーキテクチャが技術的にサポートするようになったという理由だけで、並行して5つの異なるタスクに取り組みたくなる誘惑がある。快適に感じるよりも長くこれに抵抗する。1つのループを、その出力を注意深くチェックするのを本当にやめるほど確実に実行できるようにする。つまり、誰もが注意深く見守った単一の成功したデモ実行だけでなく、実際の期間にわたってあなた自身の手動スポットチェックに一貫して合格するようにする。その後にのみ、2つ目のループを、異なるタスクで、理想的には最初のものとは完全に異なるものにマッピングするタスクで開始する。これにより、基礎となるスケルトンが一般化するかどうかをテストし、同じタスクをさらに調整するだけではないことを確認する。
ステップ18: 実行中のすべてのループにわたる共有ビューを自分自身に与える
複数のループが実行されたら、すべてのループにわたるコストと停止条件トリガーの共有ビューを追跡し、ループごとに個別に追跡しない。タスクあたりの予算が妥当な単一のループは、それ自体では完全に問題なく見える。それぞれが予算内にある10のループでも、各ループの個別の追跡が問題なく見えたため、誰も集計請求書が届くまで気づかない alarming な合計になる可能性がある。
特に停止条件トリガーをすべてログに記録し、成功した完了だけでなく記録する。あるループが常に修正回数上限に達しているのに、他のループがほとんど達していない場合、それはジャッジの基準が調整を誤っていること、つまり厳しすぎて実際にパスできないこと、またはまったく間違ったグラウンドトゥルースに対してチェックしていることを示している。これは、根本的なタスクが単に難しいというわけではない。そのパターンは、成功のみを追跡し、すべてのエスカレーションを、その特定のループの設計に関するデータポイントではなく、孤立した取るに足らないイベントとして扱っている場合には見えない。
フェーズ5: システムデザイナーになる (ステップ19と20)
ステップ19: 書いたプロンプトの数で自分を測るのをやめる
シフトが実際に起こった最も明確な兆候は、日々何に注意を払うかが変わることである。プロンプターは、どれだけ良いプロンプトを書いたかを追跡する。システムデザイナーは、いくつのループが実行されているか、それぞれがどれだけ信頼できるか、そして監督を必要としなくなったシステムによってどれだけの自分の時間が返されたかを追跡する。もしあなたがまだ自分の生産性を入力したプロンプトの数で測定しているなら、ステップ1のマインドセットの転換は、技術的にいくつのループを構築したかに関係なく、まだ完全には定着していない。
ステップ20: 他の誰かに5つの動きを教える
最後のステップは、もはやあなた自身のシステムに関するものではない。それは、専門用語を使わずに他の誰かに説明することで、あなたが実際にシフトを内面化したことを確認することである。ディスカバリー、ハンドオフ、ベリフィケーション、パーシステンス、スケジューリング。これらの5つの動きと上記のステップだけを使用して、他の誰かが自分自身の最初のループを構築するのを導くことができるなら、あなたはこのロードマップが説明する実際の移行を遂げたことになる。あなたはもはやループの中にいて次の指示を入力する人ではない。あなたはそれを設計し、外に立って、それが実行されるのを見ている人である。
ステップをスキップすると静かに蓄積される4つのコスト
警告で締めくくる価値がある。このロードマップのステップをスキップすることは、大きな音を立てて失敗するのではなく、静かに失敗し、ずっと後になってからしか現れない方法で失敗するからである。
検証負債は、ステップ6と7をスキップし、実際のジャッジや実際のグラウンドトゥルースなしでループを構築すると蓄積される。アウトプットが問題なく見えるため、ループは機能しているように見える。誰も気づかないうちに、間違いが数十回の実行にわたって静かに増幅されるまで。
理解の腐敗は、ステップ20をスキップし、一度構築したが、壊れた場合に説明したりデバッグしたりできなくなるループを実行すると発生する。なぜなら、各ピースがなぜ存在するのかを内面化する必要がなかったからである。
認知の降伏は、ステップ1が本当に定着せず、検証システムがすでに実証されているのに、習慣からすべてのアウトプットを手動で再確認し続け、システムを構築する目的全体を無効にすることで起こる。
トークン吹き出しは、ステップ10をスキップし、実際の停止条件なしでループを実行し、請求書が届いたときにのみ実際のコストを発見することで発生する。
これらのコストはすべて回避可能であり、すべて同じ規律によって回避される。ステップを順番に構築する。華やかでないと感じるステップをスキップしない。退屈なステップ、つまり完了の定義、停止条件、グラウンドトゥルースこそが、実際に仕事をしているステップである。面白そうに聞こえる部分、つまり巧妙なプロンプト、精巧なアーキテクチャ図は、あなたが構築したシステムが、自分が正しいとき、間違っているとき、そして停止するときを実際に知っているかどうかよりもはるかに重要ではない。
それが、プロンプターとシステムデザイナーの完全な違いである。巧妙さではない。構築するのが退屈でスキップしやすい部分に対する規律である。
このロードマップのすべてのステップの背後にある正確なループテンプレートとビルダー・ジャッジ・マネージャー設定については、@cyrilXBT をフォローしてください。
