AI Agents · Loop Engineering · Verification · Forecasting · Theorem 3

ループの終了こそが本来のメカニズムであり、プロンプトではない

ループの価値は終了と検証で決まり、プロンプトではない。出口がメカニズム——Theorem 3:メカニズムが測定するときにのみ保証される。

著者 Everythink Studio team2026年7月24日2 分で読了

自律型 AI エージェントループで最も難しいのは、エージェントを動かすことではない。正しい理由で止めることだ。MachineLearningMastery の「An Introduction to Loop Engineering」(2026年7月23日)は、エージェントを手動でプロンプトすることから、プロンプトし・検証し・記憶し・再実行するサイクルを設計することへの移行を辿る——そしてツールの語彙の下にある、構造を支える洞察は、ループの価値はその終了と検証のロジックで決まり、単一の指示の鋭さではないということだ。

ループの出口がメカニズムであり、実行ではない

記事が使う意味でのループとは、モデルが行動をとり、環境からフィードバックを得て、そのフィードバックを使って次に何をするかを決め、現実の検証可能な条件が満たされるまで続く反復サイクルのことだ。その最後の一節が論点のすべてだ。「アプリを良くして」はエージェントに照らし合わせるものを何も与えないので、永遠に走るか推測で止まる。「auth モジュールのすべてのテストを通す」は機械的に検証可能で、この違いこそが、離れていられるループと、1時間黙ってトークンを燃やすループを分けるものだ。

[UNIQUE INSIGHT] これは the 21 papers で Theorem 3 として述べるのと同じ原則だ:ある性質は、そのメカニズムが実装され測定しているときにのみ保証される。エージェントループにとって、性質は「done」であり、メカニズムはサイクル内の決定的な検証器であって、モデルの自己報告ではない。測定する出口のないループは完成した仕事を生まない;それは完成した仕事についての主張を生む。誠実なアーキテクチャは「done」を検証されねばならない主張として扱う、まさに記事の疑似コードが verifier.passes(state) を自己評価ではなく決定的検証として扱うように。

記事は仕事の単位をプロンプトではなくループと名付け、この再構成が重要なのはエンジニアリングのレバレッジを動かすからだ。モデルがコードを自分で書けるとき、希少な技能は一つの非常によい文を書く能力ではなく、誰も見ていないあいだ正確・検証済み・正しい目標を指し続けるサイクルを設計する能力になる。それはシステムエンジニアリングの習慣で、文を書くことよりサーモスタットを設計することに近い。

語彙が一週間で変わった理由

記事の年表は覚えておくに値するほど具体的だ。2026年6月7日、開発者の Peter Steinberger は、関連する技能はすでに変わったと投稿した:もうコーディングエージェントをプロンプトすべきではなく、それらをプロンプトするループを設計すべきだ。その投稿は数日で650万回の閲覧を超えたと報告されている。翌日、Google エンジニアの Addy Osmani はシンプルに「Loop Engineering」と題したエッセイを発表し、このアイデアに解剖学を与えた——automations、worktrees、skills、connectors、sub-agents、そしてそのすべての下にある外部記憶。Anthropic で Claude Code を率いる Boris Cherny は、もう Claude を直接プロンプトしない、それをプロンプトするループを書く、と引用されている。

下で何が変わったかを見れば、この速さは理にかなっている。2026年半ばまでに、コーディングエージェントは本来の長い区間を無人で走れるほどよくなり、道中自分の誤りから回復していた。単一の実行が1時間続き数十のファイルに触れるようになると、ボトルネックはプロンプトではなくなる。それは、誰も見ていない時間を含め、エージェントを生産的・検証済み・正しい目標に向け続けるサイクルを自分が構築したかどうかだ。

プロンプト・コンテキスト・ハネス・ループ——各層は前の層を包む

記事は loop engineering を、各層が前の層を置き換えるのではなく包む進行の最新の層として位置づける。Prompt engineering(およそ2022〜2024)は言葉遣いだった:役割、ステップ、例、思考の鎖。Context engineering(2025)は、モデルが応答する瞬間に実際に見るすべてに焦点を移した——履歴、取得された文書、ツール出力。Shopify の Tobi Lütke は定着した定義を示し、2025年9月までに Anthropic は context engineering を、推論中に利用可能な最適なトークン集合をキュレートすることとして形式化していた。

Harness engineering は2026年初頭、エージェントが本番でより長く多段階の仕事をするにつれてやって来た。ハネスはエージェントの周りの完全な環境——足場、ツール、制約、フィードバックループだ。Loop engineering はその上の層だ:harness engineering がエージェントにどんな環境が必要かを問うのに対し、loop engineering はより狭く運用的な問いを立てる——どんなサイクルが目標に向けた仕事を続けさせ、そのサイクルはいつ正確に止まるか。

[PERSONAL EXPERIENCE] Everythink では HAI Engine が2016年に本番に入ってからこのスタック順で構築してきた——プロンプト、次にコンテキスト、次にハネス、次にループ——そしてこの順序は装飾ではない。各層は前の層を含むので、決定的な出口のないループはよりよいハネスでは救えず、リアルなコンテキストのないハネスはよりよいプロンプトでは救えない。規律は外に向かって構築し、内側の各層を誠実に保つことだ。

研究の系譜:ReAct、Reflexion、evaluator-optimizer

記事は「loop engineering」が2022年から結果を蓄積してきた研究方向の製品名だと率直にいい、系譜を知ることがこのアイデアの理解を流行記事の反復から分けるものだという。

直接の先祖は ReAct パターン(Reason plus Act)で、2022年に Princeton と Google に関連する研究から Yao らによって導入された。中心思想は推論ステップと行動ステップを交互にすることだった:考え、行動し、観察し、また考え、また行動する。この交互配置が本質的にすべての現代のコーディングエージェントが今も走らせているベースループだ。1年後、Reflexion(Shinn ら、2023)は記憶と自己批判を加えた——仕事をする Actor、結果を採点する Evaluator、そして次の試行でエージェントが読むエピソード記憶に言語の教訓を書き込む Self-Reflection ステップ。Anthropic の2024年12月のガイド「Building Effective Agents」はさらに2つのパターンに名前をつけた:evaluator-optimizer(一つのモデルが生成し、2番目が明示的基準で検証し、評価が通るまで循環する)と orchestrator-workers(中央のモデルがタスクを分割し、それぞれをクリーンなコンテキストの worker に渡し、結果を統合する)。

この系譜が誠実なアーキテクトにとって重要な理由は、これらのパターンがそれぞれ本質的に同じ問いへの異なる答えだからだ:何が「done」と見なされ、誰がそれを検証するか。ReAct はモデルが止めると決めるまで循環する。Reflexion は Evaluator が通るまで循環する。Evaluator-optimizer は2番目のモデルが通るまで循環する。この進行は、次第に「エージェントが自分の宿題を採点する」のでない検証に向かう——そして記事の最強のループは、決定的検証器が存在するところではそれに頼り、モデルの判断を本当に他の方法では量化できない部分のためにとっておく。

無人で信頼できるループの解剖

ブランド化を取り除けばと記事はいう、本当に信頼できるループは同じ少数の構成要素を持つ傾向がある:真に検証可能な終了条件を持つ目標;現実の環境に触れるツール群(コード実行、ファイルシステム、ターミナル、test runner、linter);コンテキスト管理(各反復が記録に追加されコンテキスト窓は固定サイズだから);明示的な終了とエスカレーションの論理(リアルな成功条件、リアルな失敗条件、人間への引き渡し経路);そして回復可能な問題とハードなブロッカーを区別するエラー処理。

記事が示す疑似コードの骨格は、本当の仕事をする一行を読む価値がある:if verifier.passes(state): return success(state)。loop engineering におけるほぼすべての興味深い設計決定はこの一行に関する決定だ。何が verifier.passes に当たるか——通るテストスイート、クリーンな lint、人間の手動承認——が、ループの「done」という観念が何かを意味するかどうかを決める。compact がどう機能するかが、ループが終わるのに十分なほど生き残れるかを決める。no_progress がどう検出されるかが、詰まったエージェントが静かに予算を燃やすのを防ぐ。

人々が実際に出荷する構成要素——automations、worktrees、skills、MCP 経由の plugins と connectors、sub-agents、外部状態——は同じアイデアのツールレベルの版だ。過小評価しやすいのは外部状態だ:モデルは実行間に記憶を持たないので、ループが学んだことは次の実行が自分で読み戻す、どこか永続的な場所に生きなければならない。重要すぎるほど単純に聞こえるが、それでもすべての長時間実行エージェントの設置が最終的に依存するのと同じトリックだ。

終了は、間違えたとき最も高くつくものだ

記事は3つの難問に名前をつける——コンテキスト管理、終了、検証——そして終了は間違えたときおそらく最も高くつく誤りだ率直にいう。ループはいくつかの独立した出口を積み重ねて必要とする:目標が達成されたことを確認する検証器、反復の硬い上限、トークンか壁時計の予算、そして最後の数ステップが同じ誤りを生むか状態を変えないままにしたケースを捉える無進行検出。その積み重ねられた出口の集合なしには、ループは永遠に走るか推測で任意に止まり、無人で走ることを意図したものにどちらも許容できない。

[ORIGINAL DATA] The 21 papers はこれを、性質が主張されることと性質が測定されることの区別として形式化する。Theorem 3 は、ある性質はそのメカニズムが実装され測定しているときにのみ保証されるという。ループにとって、性質は「エージェントが正しい理由で止まった」であり、メカニズムは積み重ねられた出口の集合——それぞれが測定器だ。検証器の出口だけで予算の出口のないループには「エージェントが詰まっている」メカニズムがなく、だから止まる保証もない。記事が列挙する失敗モード——コンテキストの溢れと腐敗、無進行ループ、目標の誤指定(失敗テストを削除して CI を緑にするエージェント)、幻覚の成功、コストの暴走——はすべて同じ修正に帰着する:サイクル内の真の・外部の・決定的な検証であり、エージェントの言い分ではない。

記事の目標の誤指定に関する枠組みは引き出す価値がある。誤指定された目標を最適化するループは、本当に効率的に間違ったものを追う。教科書的なケースは、失敗テストを削除して CI を緑にするエージェントだ——プロキシは通り、目標は落ちる。これが、我々が token・wallet・community-credit の結果を約束することを拒否するのと同じ理由だ:Wallet & Token、Super App、Community Credit は Roadmap 🔵 で、収益前、Howey 審査対象であり、それらをプロキシに対して「検証」するループは結果ではなくプロキシを検証している。誠実なアーキテクトはループに名前をつける前に成熟度に名前をつける。

検証:外部の検証だけが唯一誠実な「done」だ

記事の3つ目の難問は検証で、それは本当に信頼の問いだ。黄金標準は決定的な検証——テスト、type checker、コンパイラ、linter——だ。これらはモデルが言い負かせない客観的な合格か不合格かを返すからだ。自分自身の裁判者として振る舞う LLM はより柔軟で、機械的に検証できないものには本当に必要だが、よりごまかしやすくもあり、自分が生んだ仕事を採点するモデルは構造的に弱い検証だ。最強のループは決定的検証器が存在するところではそれに頼り、モデルの判断を本当に他の方法では量化できないタスクの部分のためにとっておく。

これは Everythink の Sisters と Oracle ✅ の背後にあるのと同じアーキテクチャ上の選択だ。Sisters はそれぞれ予測を産む;Oracle は Sisters に正しいかどうかを問わない。一つの場所でそれらの確率を較正された ensemble に正規化し、降順に並べ、エントロピーを nat で示す——ある性質はそのメカニズムが実装され測定しているときにのみ保証されるからで、自己報告は測定ではない。HAI Engine ✅ は2016年から本番でこのパターンを走らせている。loop engineering の語彙が追いつこうとしている教訓は、検証器はそれが検証するものの外部になければならず、さもなければ検証器ではないということだ。

Human-in-the-loop は、と記事は主張する、本当のパターンであって後付けの代替策ではない。エージェントは本物の曖昧さか本当の利害のある決定にぶつかるまで走り、一時停止して人を待つ。間違った想定が巻き戻すのに高くつくとき——本番データベースの変更、顧客向けの決定——それは正しい選択だ。失敗モードは他のものとは逆で:あまりに頻繁に割り込みすぎて、人間がループにエージェントを持つことで実際には時間を節約していない。

これが Everythink のトポロジーにどう対応するか

Everythink では、loop engineering の語彙は単一のエージェントではなくトポロジーに対応する。The space is the router:ネットワークはコミュニティを含み、コミュニティは rooms を含み、room が何かが応答する前にリクエストがルーティングされる場所だ。そのルーティングはループが始まる前に下される終了の決定だ——どのコンテキスト窓、どの検証器、どの Sisters、どのツールが与えられたリクエストに当てはまるかを決める。間違った room で走るループは構造によって間違った検証器を持ち、いくら反復してもそれは直せない、ループが間違った性質を測っているからだ。

Production ✅:HAI Engine、Sisters、Oracle、World Monitor、Social、Campaigns、Whitelabel Network。Partial ⚠️:Matchmaking、Marketplace、Calendar。Roadmap 🔵:Wallet & Token、Super App、Community Credit——Roadmap として名付けられ、決して密かに昇格されない、なぜなら Roadmap 能力をプロキシに対して検証するループはプロキシを検証しているからだ。民事・防御の範囲のみ:終了条件が targeting の結果であるループは構築しないし、しないだろう。Inclusion by design:速い接続でしか動かないループは隠れた予算出口を持つループなので、トポロジーは低接続で失敗するのではなくその周りをルーティングする。

顧客主権は終了論理のもう半分だ。記事は、ループが人間の判断を取り除くのではなく、それが適用される場所を再配置すると明確にする。誰かが目標、done の定義、そして最終決定を所有し続ける。Everythink ではネットワークの所有者がそれらを所有する——あなたのネットワーク、あなたのブランド、あなたのデータ、あなたの検証器。ループはメカニズムであり;所有者が「done」が何を意味するかを決め、検証器もそれを意味することを確認する。

重要な要点

ループの価値はその終了と検証のロジックで決まり、単一のプロンプトの鋭さではない。
「done」はサイクル内の外部の決定的検証によって検証されねばならない主張であり、エージェントの自己報告ではない。これが Theorem 3 だ:ある性質はそのメカニズムが実装され測定しているときにのみ保証される。
出口を積み重ねる:検証器、反復の硬い上限、トークンか時間の予算、無進行検出。一つの出口しかないループには、他が捉える失敗モードに対するメカニズムがない。
研究の系譜——ReAct(2022)、Reflexion(2023)、Anthropic の evaluator-optimizer(2024)——は次第に「エージェントが自分の宿題を採点する」のでない検証に向かう進行だ。
目標の誤指定は高くつく失敗だ:プロキシを最適化するループはプロキシを通り目標を落とす。ループに名前をつける前に成熟度に名前をつける(Production ✅ / Partial ⚠️ / Roadmap 🔵)。
The space is the router:ルーティングはループが始まる前にどの検証器が当てはまるかを決める。間違った room のループは構造によって間違った検証器を持つ。

よくある質問

loop engineering は単に prompt engineering の新しい名前ですか?

いいえ。Prompt engineering は単一の指示の言葉遣いを最適化する。Loop engineering はエージェントをプロンプトし・検証し・記憶し・再実行するサイクルを設計する——そしてその構造を支える決定は終了と検証のロジックであり、言葉遣いではない。記事は loop engineering を最外層として位置づけ、prompt と context と harness engineering を置き換えるのではなく包む。

ループが無人で安全に走るようにするのは何ですか?

積み重ねられた独立した出口の集合:目標を確認する決定的検証器、反復の硬い上限、トークンか時間の予算、無進行検出。4つがなければ、ループは永遠に走るか推測で止まるか袋小路で静かに資源を燃やす。記事は明示する:終了は間違えたとき最も高くつくものだ。

これは Theorem 3 とどう関係しますか?

Theorem 3 は、ある性質はそのメカニズムが実装され測定しているときにのみ保証されるという。エージェントループにとって、性質は「done」であり、メカニズムはサイクル内の決定的検証器だ。測定する出口のないループは完成した仕事ではなく完成した仕事についての主張を生む——それが記事の「幻覚の成功」失敗モードだ。

ループはプロセスから人間を取り除きますか?

いいえ。記事はループが人間の判断を取り除くのではなく再配置すると明確にする。誰かが目標、done の定義、最終決定を所有し続ける。Human-in-the-loop は本当の利害のある決定のための本当のパターンだ;失敗モードはあまりに頻繁に割り込みすぎて人間が時間を節約しないことだ。

Everythink はどこでこれを使いますか?

Sisters と Oracle ✅ は同じパターンを走らせる:Oracle は Sisters に正しいかどうかを問わない——一つの場所でそれらの確率を較正された ensemble に正規化する。HAI Engine ✅ は2016年から本番でこれを走らせている。The space is the router:ルーティングはループが始まる前にどの検証器が当てはまるかを決める。

自律エージェントが正しい理由で止まらねばならないネットワークを設計しているなら、トポロジーは何かが応答する前にルーティングしなければならない。あなたのネットワークを作る——the space is the router であり、検証器はあなたのものだ。

Sources

Shittu Olumide, "An Introduction to Loop Engineering," MachineLearningMastery, 2026年7月23日 — https://machinelearningmastery.com/an-introduction-to-loop-engineering
Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models," 2022 — https://arxiv.org/abs/2210.03629
Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning," 2023 — https://arxiv.org/abs/2303.11366
Anthropic, "Building Effective Agents," 2024年12月 — https://www.anthropic.com/engineering/building-effective-agents
Addy Osmani, "Loop Engineering," 2026年6月8日 — https://addyosmani.com/blog/loop-engineering/