ループエンジニアリングとは｜AIエージェントの反復制御を設計する5つの軸と主要OSS実装

「良いプロンプトを書く」ことが成果の上限を決めていた時代が、静かに終わりつつある。テストを直す、複数ファイルを横断する、レビューまで回す——こうした多段の作業では、人間が毎ターン指示を打ち込むやり方そのものがボトルネックになる。

そこで2026年に複数の実務家が同時多発的に語り始めたのが、ループエンジニアリング（Loop Engineering） だ。プロンプト（モデルへの入力）でも、コンテキスト（与える情報）でもなく、エージェントを回し続ける「ループ」そのものを設計対象に据える、という発想である。

この概念は、当サイトで何度も扱ってきた ハーネスエンジニアリングとは何か——5つの流派と設計思想を整理する の延長線上にある。Harness Engineeringが「モデル以外のすべて（ランタイム全体）」を設計するのに対し、ループエンジニアリングはそのうち『反復の制御』だけに粒度を絞った、より新しい関心事だ。本記事はこの住み分けを軸に、一次ソースから定義・設計軸・OSS実装を整理する。

なぜいま「ループエンジニアリング」が語られるのか

きっかけは、コーディングエージェントの使われ方が「対話」から「委任」へ移ったことだ。Claude CodeやCodexが /loop・/goal・スケジュール実行・worktreeを備え、人間が席を外しても作業を進められるようになった。すると関心は「どう指示するか」から「回り続ける仕組みをどう設計するか」へ移る。

GoogleのAddy Osmaniは、この変化を「自分自身を置き換える」と表現する。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.（ループエンジニアリングとは、エージェントにプロンプトを打つ「あなた自身」を置き換えることだ。代わりにそれを行うシステムを設計する）

ここで言う「ループ」は、Osmaniの定義では「目的を定めると完了までAIが反復する再帰的なゴール」だ。人間が一手ずつ手を引くのではなく、「仕事を見つけ、渡し、検証し、記録し、次を決める」小さなシステムを組む。人間の役割は操縦者から観察者に変わる。

背景には、コスト構造の変化もある。エージェントは通常のチャットの約4倍、マルチエージェントでは最大15倍のトークンを消費すると報告されている。回し続ける以上、「いつ止めるか」「いくらまで使うか」を設計しないと、品質以前に請求額が破綻する。後述するUberの月1,500ドル上限は、その現実への対応だ。回す力が手に入った瞬間に、回しすぎを制御する技術が必要になった——これがループエンジニアリングが浮上した理由である。

もう一つ見逃せないのが、オブザーバビリティ（観測可能性）の要求だ。人間が席を外して回るループは、何かおかしくなったときに「どのステップで、なぜそう判断したか」を後から追えなければ手の打ちようがない。TrueFoundryは本番ループの要件として「per-step trace of every run（全実行のステップ単位のトレース）」を挙げ、各ステップの記録がフォレンジック（事後解析）の前提になると指摘する。つまりループエンジニアリングは「回す設計」と同時に、「回った後に検証できる設計」をも含む。止め方・予算・トレース——この三点セットが揃って初めて、自律ループを安心して本番に置ける。逆に言えば、デモでは華やかに回るのに本番投入できないエージェントの多くは、この「観測できなさ」でつまずいている。

定義の試み——一次ソースは何と言っているか

正直に言えば、ループエンジニアリングの定義はまだ一つに固まっていない。書き手によって強調点が違う。だからこそ、推測で一つの定義を作るのではなく、複数の一次ソースを併記して読者が選べる形にしておく。

3つを並べると、共通項が見えてくる。(1) 単発ではなく反復であること、(2) 各回で結果を検証すること、(3) 「次に何をするか」をシステム側が決めること——この3点はどの定義にも含まれる。逆に揺れているのは「Harness EngineeringやContext Engineeringとどこで線を引くか」だ。Osmaniは loop を harness engineering の「上」に位置づける書き方をするが、TrueFoundryやFirecrawlは harness（runtime）の中で動く制御として語る。本記事は後者——ループはharnessの一部品——という立場を採る。理由は次節で述べる。

Harness Engineering との違い——粒度で切り分ける

最も多い誤解は「ループエンジニアリングはHarness Engineeringの言い換えでは？」というものだ。結論から言えば違う。両者は対立概念ではなく、粒度（スコープ）が違う。

Harness Engineeringは、エージェントを取り囲む足回り全体——コンテキスト供給、ツールインターフェース、メモリ、権限、検証ループ、サンドボックス——を設計する規律だ（詳細は awesome-harness-engineering徹底ガイド を参照）。一方ループエンジニアリングは、そのうち「1ターンを何回、どう回すか」という反復制御の部分だけを取り出して深掘りする。

図のとおり、ループエンジニアリングはHarnessという大きな箱の中の一区画だ。次の表で観点ごとに整理する。

この粒度の差を押さえると、議論が噛み合う。「エージェントが壊れる」と言うとき、コンテキスト設計の問題（Harness全般）なのか、止め方・回し方の問題（Loop）なのかを切り分けられるからだ。本記事が扱うのは後者である。

5つの設計軸——stop / replan / budget / self-correction / escalation

複数の一次ソースを横断すると、ループ設計の論点は概ね5つの軸に集約できる。これは筆者がソース群（Osmani / Firecrawl / MindStudio / TrueFoundry / Vercel AI SDK）の共通要素を整理した枠組みであり、公式に確立した分類ではない点は断っておく。

1. 停止条件（stop）：ループが「完了」をどう判定するか。MindStudioは成功側を「tests pass, output matches expected, user approves」、失敗側を「max iterations reached, repeated errors with no progress, tool call failures」と整理する。停止条件がないと、エージェントは永遠に回るか、根拠なく止まる。

2. 再計画（replan）：観測結果が想定と外れたとき、同じ手を繰り返すのではなく戦略を組み替える。MindStudioは「Adjust its strategy based on error type（エラーの種類に応じて戦略を調整する）」と表現する。同じ失敗を繰り返すループは、再計画の軸が欠けている。

3. 予算ゲート（budget）：コスト・遅延・品質に上限を設け、超えたら止めるか昇格する。MindStudioは「Set Strict Tool Call Budgets（厳格なツール呼び出し予算を設定する）」を挙げ、予算枯渇自体を「別戦略へ移れ」というシグナルとして使う。

4. 自己修正（self-correction）：失敗の出力を次の入力に折り返して直す。後述のReflexion論文が源流で、Aiderの reflected_message が実装例だ。

5. エスカレーション（escalation）：行き詰まったら人間・別モデル・別ツールに渡す。MindStudioは「hand off to a human or a different agent when stuck」、cascadeflowは品質検証に失敗したら大型モデルへ昇格する switch_model を持つ。

この5軸は独立ではなく連鎖する。停止条件が発火しなければ再計画し、予算を超えれば昇格し、それでもダメなら人間へ——という流れだ。

主要OSS実装の対比——どのツールが何を持つか

5軸は抽象論ではない。すでに主要OSSが、それぞれの形で実装している。各ツールの公式ドキュメント・ソースから、ループ制御の具体的なプリミティブを抜き出して対比する。

Vercel AI SDKは、停止条件を宣言的に書ける点が分かりやすい。

By default, agents stop after 20 steps using stepCountIs(20).（デフォルトでは、エージェントは stepCountIs(20) により20ステップ後に停止する）

既定で20ステップという上限が入っているのは、暴走を防ぐ安全装置だ。stopWhen: [stepCountIs(20), hasToolCall('done')] のように複数条件を組み合わせ、prepareStep で各ステップ前にモデルやツールを動的に差し替えられる。これは5軸の「停止条件」と「エスカレーション」をAPIにそのまま落とした例と言える。

OpenHandsの StuckDetector は、停止条件の中でも「false continue（止まるべきなのに回り続ける）」を検出する仕組みだ。同じ行動が同じ観測を4回以上生む、同じ行動が3回以上エラーになる、といったパターンを意味内容ベース（タイムスタンプの差は無視）で検出して止める。Aiderの max_reflections = 3 は逆に「自己修正は3回まで」と上限を切り、それを超えたら “Only 3 reflections allowed, stopping.” と警告して打ち切る。grep一発で確認できる、極めて素朴で実用的な実装だ。

cascadeflowは、ループ内の意思決定をより踏み込んで持つ。小型モデルで投機実行し、品質検証に失敗したら大型モデルへ昇格する設計で、予算ゲートとエスカレーションを兼ねる（詳細は cascadeflow解説 を参照）。LangGraphは recursion_limit と条件付きエッジでループ・分岐を、interrupt() / Command(resume=...) で人間の割り込みを表現する（入門は LangGraph入門）。

論文背景——ReAct → Reflexion → Voyager → 予算意識へ

ループエンジニアリングは突然現れた概念ではない。土台には、エージェントの反復を形作ってきた一連の論文がある。

最初の原子的なループを定義したのが ReAct（Yao et al., arXiv:2210.03629）だ。推論（thought）と行動（act）を交互に行い、環境の応答（observation）を次の推論に折り返す。

reasoning traces help the model induce, track, and update action plans as well as handle exceptions, while actions allow it to interface with external sources.（推論トレースはモデルが行動計画を立て・追跡・更新し例外を処理するのを助け、行動は外部ソースとの接続を可能にする）

次に Reflexion（Shinn et al., arXiv:2303.11366）が、その外側に自己反省のループを巻いた。失敗したら言語で振り返り、その反省をエピソード記憶に溜めて次の試行を改善する。重み更新なしの「言語による強化学習」であり、5軸の「自己修正」の理論的源流だ。

Voyager（Wang et al., arXiv:2305.16291）は、ループを単一タスクから生涯学習へ拡張した。自動カリキュラム・スキルライブラリ・反復プロンプトを組み合わせ、環境フィードバックと実行エラーと自己検証を取り込んで能力を積み上げる。

そして2024年以降、論点は「どう回すか」から 「いつ止めるか」 へ移る。Reasoning in Token Economies（arXiv:2406.06461）は、固定予算下で推論戦略を評価し、衝撃的な結論を出した。

unlike self-consistency, certain strategies such as multi-agent debate or Reflexion can become worse if more compute budget is utilized.（self-consistencyと違い、multi-agent debateやReflexionといった戦略は、計算予算を増やすとかえって悪化しうる）

これはループエンジニアリングの核心を突く。「もっと回せば良くなる」は嘘であり、回数や予算という停止条件を明示的に設計する必要がある——5軸の「予算ゲート」が学術的にも裏づけられた瞬間だ。

実装パターン例——最小のループはこう書く

5軸を頭に入れて、最小のループ構造を擬似コードで描く。具体的なAPI名はツールごとに違うが、骨格はどれも共通している。

# ループエンジニアリングの最小骨格（疑似コード）
state = init_state(goal)
for step in range(MAX_ITERS):          # 軸1: 停止条件（反復上限）
    obs = observe(state)               # 観測
    if budget.exceeded():              # 軸3: 予算ゲート
        escalate("budget"); break      # 軸5: エスカレーション
    plan = think(obs, state)
    if plan.needs_replan(obs):         # 軸2: 再計画
        plan = replan(obs, state)
    result = act(plan)
    if result.failed:
        state = reflect(result, state) # 軸4: 自己修正
    if goal_satisfied(state):          # 軸1: 停止条件（完了）
        break
    if no_progress(state):             # 軸1: スタック検出
        escalate("stuck"); break

このループを図にすると、観測→思考→行動→反省の円環に、5つのゲートが差し込まれた形になる。

重要なのは、MAX_ITERS・budget・no_progress の3つが最初から入っていることだ。Firecrawlはこれを明確なハードガードとして要求する。

Without all three ... what you are running isn't a loop. It's an open invoice.（この3つすべてがなければ、あなたが回しているのはループではない。開いた請求書だ）

「開いた請求書（open invoice）」という表現が示すとおり、ガードのないループは品質以前にコストで事故る。実装の最小要件は「賢さ」ではなく「止まれること」である。

アンチパターン——ループが事故る3つの典型

ループエンジニアリングの価値は、うまく回すこと以上に事故を防ぐことにある。一次ソースが繰り返し警告する典型を3つ挙げる。

1. 無限ループ／スタック：停止条件が甘いと、同じツールを同じ引数で延々と呼び続ける。LangGraphの公式ドキュメントは、recursion_limit到達時にこう示唆する——「If you are not expecting your graph to go through many iterations, you likely have a cycle.（多くの反復を想定していないなら、おそらくサイクルがある）」。OpenHandsのStuckDetectorは、まさにこの症状を検出するために存在する。

2. 予算枯渇：止め方を設計せずに自律ループを走らせると、請求額が静かに膨らむ。Firecrawlは、Uberが対策として1人・1ツールあたり月1,500ドルの上限を設けた実例を挙げる。年間予算を4か月で焼いた後の対応だという。予算ゲートは「あれば良い」ではなく必須装備だ。

3. 早すぎる停止（false stop）／自己採点バイアス：逆に、エージェントが「できた」と誤判定して止まるのも事故だ。Osmaniは、コードを書く側と検証する側を分離するサブエージェント設計を推奨する。理由は、自分の成果を自分で甘く採点してしまうからだ。検証を同じループ内の同じ役者に任せると、停止条件そのものが信用できなくなる。

これら3つはいずれも、5軸のどれかが欠けたときに現れる。アンチパターンの裏返しが、そのまま設計チェックリストになる。

関連記事——Harnessから掘り下げる

ループエンジニアリングは単独で理解するより、Harness Engineeringの文脈に置くと位置づけが鮮明になる。深掘りには次の記事が役立つ。

・ハーネスエンジニアリングとは何か——5つの流派と設計思想を整理する：ループの「親概念」であるharnessの全体像。まずここで足回り全体を押さえると、ループがどの区画かが分かる
・awesome-harness-engineering徹底ガイド：harness設計に使えるOSS・論文の地図。「Agent Loop」カテゴリが本記事と直結する
・cascadeflow解説：ループ内でコスト・遅延・品質を最適化する具体実装。予算ゲートとエスカレーションの実例として読める
・LangGraph入門：ループ・分岐・人間割り込みをグラフで書くフレームワーク。停止条件と再計画の実装の入口
・OpenSpace徹底解説：ループ内でエージェントを自己進化させるOSS。自己修正の軸を深掘りしたいとき

概念（harness）→地図（awesome list）→反復制御（本記事）→具体実装（cascadeflow / LangGraph / OpenSpace）という順で読むと、抽象から実装まで一本の線でつながる。

まとめ——まだ過渡期の、しかし無視できない粒度

ループエンジニアリングは、Harness Engineeringの内側にある「反復制御」を独立した設計対象として切り出す動きだ。停止条件・再計画・予算ゲート・自己修正・エスカレーションの5軸は、ReActやReflexionといった論文を源流に持ち、Vercel AI SDK・LangGraph・OpenHands・Aider・cascadeflowといったOSSにすでに実装されている。「もっと回せば良くなる」が偽だと学術的にも示された以上、いつ止めるかの設計は避けて通れない。

一方で、誠実に認めておくべきこともある。「ループエンジニアリング」という用語はまだ過渡期にある。定義は書き手ごとに揺れ、Harness EngineeringやContext Engineeringとの境界も流動的だ。本記事が示した5軸も、複数の一次ソースから筆者が整理した枠組みであって、業界標準ではない。だからこそ本記事は、推測で一つの定義を押しつけず、Osmani・Firecrawl・MindStudio・TrueFoundryの定義を併記した。

それでも、この粒度を意識する価値はある。エージェントが「壊れる」とき、それがコンテキストの問題なのか、止め方・回し方の問題なのかを切り分けられるからだ。用語が定着するかどうかに関わらず、「ループをどう止め、どう昇格させるか」という問いそのものは、自律エージェントを本番で回す限り消えない。ループエンジニアリングは、その問いに名前を与えた——今はまだ、それで十分だ。

参照ソース

・Addy Osmani — Loop Engineering
・Firecrawl — Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops
・MindStudio — What Is Loop Engineering? The New Meta for AI Coding Agents
・TrueFoundry — Loop Engineering at Enterprise Grade
・Vercel AI SDK — Agents: Loop Control
・LangGraph 公式ドキュメント（GRAPH_RECURSION_LIMIT / Interrupts）
・OpenHands — Agent Stuck Detector
・Aider — Linting and testing
・cascadeflow（GitHub）
・ReAct: Synergizing Reasoning and Acting in Language Models（arXiv:2210.03629）
・Reflexion: Language Agents with Verbal Reinforcement Learning（arXiv:2303.11366）
・Voyager: An Open-Ended Embodied Agent with Large Language Models（arXiv:2305.16291）
・Reasoning in Token Economies（arXiv:2406.06461）