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

2026年6月7日、PSPDFKitの創業者として知られるiOS開発者のPeter Steinberger氏が、わずか6語のツイートを投げた。表示回数は数日で200万を超え（Firecrawl報告）、コーディングエージェントを使う開発者のタイムラインを二分した。

もうコーディングエージェントにプロンプトを打つのはやめろ。エージェントにプロンプトを打つ「ループ」を設計しろ。
原文：“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”（Peter Steinberger / @steipete, 2026-06-07）

賛否は割れた。「これはAI開発の次の抽象化レイヤーだ」と歓迎する声がある一方、「いや、ただの『帽子をかぶったcron job』だろ」と冷ややかに見る声、そして「自律で回したらトークン代が青天井になる」という不安の投稿も並んだ。この記事は、その渦中にある ループエンジニアリング（Loop Engineering） を、現場の発言・動画・議論を引きながら、設計の骨格まで掘り下げる。宣言の熱量だけで終わらせず、「どう仕分け、どう組み、どこで止めるか」という実装の輪郭まで一気に降りていく。

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

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

この変化を、Claude Codeの作者であるBoris Cherny氏は最も率直に言語化している。WorkOS主催の「Acquired Unplugged」ステージでの発言は、ループエンジニアリングという言葉が広まる引き金のひとつになった。当該箇所を動画から引用する。

私はもうClaudeに指示を出していません。ループが実行されているんです。そのループがClaudeに指示を出し、何をすべきかを判断しています。私の仕事はループを書くことです。
原文：“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”（Boris Cherny, Acquired Unplugged / WorkOS, 2026-06-02）

作者本人が「自分の仕事はループを書くこと」と言い切った。これは比喩ではなく、実際の運用の話だ。背景には、コスト構造の変化もある。エージェントは通常のチャットの約4倍、マルチエージェントでは最大15倍のトークンを消費すると報告されている。回し続ける以上、「いつ止めるか」「いくらまで使うか」を設計しないと、品質以前に請求額が破綻する。回す力が手に入った瞬間に、回しすぎを制御する技術が必要になった——これがループエンジニアリングが浮上した理由である。

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

現場の宣言——「プロンプトを書くな、ループを設計しろ」

冒頭のSteinberger氏のツイートは、空気を可視化した。プロンプトエンジニアリングの次は何か、という問いに対する「ループだ」という回答が、短い言葉で刺さったからだ。実際の投稿を埋め込む。

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

— Peter Steinberger (@steipete) June 7, 2026

宣言は強い。だが宣言だけでは設計はできない。同じスレッドで設計者向けに「ループには開いたものと閉じたものがある」という軸を持ち込んだのが、エージェント運用について発信する開発者Shann Holmberg氏のツイートだ。これがループの分類で最初に効いてくる補助線になる。

What is agent looping, really? Two shapes: open loops that run until a goal holds, and closed loops that run a fixed number of times. Most people reach for the wrong one.

— Shann Holmberg (@shannholmberg) June 7, 2026

Holmberg氏が「多くの人は間違ったほうを選ぶ」と書いたのは正鵠だ。一発で形が決まる作業にオープンループを当てると暴走し、探索が必要な作業にクローズドループを当てると未完で止まる。どちらの形を選ぶかが、停止条件の設計と表裏一体だという指摘である。

議論は割れている——Redditの温度感

新しい概念は、賞賛と冷笑の両方を呼ぶ。r/myclaw のスレッド「So is “loop engineering” the next AI dev buzzword?」では、肯定・否定・不安の3方向に意見が分かれた。編集部で論点を要約したカードを示す（個々の発言の逐語引用ではなく、スレッドで観測された代表的な立場の整理）。

この3つは、そのまま本記事の地図になる。「冷笑（ただのcron jobだ）」への答えは設計軸と解剖学で、「不安（トークン代が青天井）」への答えは3つのハードガードで示す。「次の抽象化レイヤーか」という肯定への答えは、最後のテイストの節に置いた。

3つの設計レイヤー——プロンプト / ワークフロー / ループ

「cron jobと何が違うのか」に答えるには、設計の粒度を3段に分けるのが早い。プロンプトエンジニアリング、エージェント・ワークフロー、ループエンジニアリングは、対立ではなく抽象度の階段だ。

下の表は、Firecrawlが整理した3カラム比較を日本語化したものだ（モバイルでは横スクロールで全列を確認できる）。

「ただのwhileループ」との違いは、最右列の「最適化対象」に集約される。cron jobが最適化するのはスケジュールだが、ループエンジニアリングが最適化するのはループの中のルーブリック——つまり「何をもって良しとし、いつ止めるか」という判断基準だ。そこにモデルの非決定性と検証が絡む点で、素朴な反復処理とは別物になる。

そのタスクは本当にループ向きか——3つのチェック

ループは万能ではない。回す価値のないタスクを自律ループに乗せると、コストだけがかさむ。着手前に3つの問いで仕分ける。

3つすべてにYESなら、ループ化の筋が良い。逆にひとつでもNOなら、ワークフロー（決め打ちの段）か、そもそも人間が手でやるべき領域だ。「自動化できる」と「自動化する価値がある」は別であり、この仕分けを飛ばすと「動くが割に合わないループ」が量産される。

動くループの解剖学——7つの構成要素

Firecrawlは、本番で実際に回っているループを解剖し、7つの構成要素に分けた。当サイトのClaude Code/Codex運用の文脈に置き換えながら、ひとつずつ見る。これは抽象論ではなく、/loop を本気で運用するときに必ず必要になる部品リストだ。

7要素のうち、4（分業）と7（永続メモリ）が見落とされやすい。デモのループは1エージェント・状態メモリなしでも華やかに回るが、本番では「自己採点バイアス」と「途中クラッシュ」で必ずつまずく。解剖学が示すのは、ループの強さは中央のモデルではなく、周辺の地味な部品で決まるという事実だ。

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

解剖学が「部品リスト」なら、5つの設計軸は「制御の論点」だ。複数の一次ソース（Steinberger / Cherny / Osmani / Firecrawl / MindStudio / TrueFoundry）を横断すると、ループ制御の論点は概ね5つに集約できる。これは筆者がソース群の共通要素を整理した枠組みであり、公式に確立した分類ではない点は断っておく。

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

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

3. 予算ゲート（budget）：コスト・遅延・品質に上限を設け、超えたら止めるか昇格する。予算枯渇自体を「別戦略へ移れ」というシグナルとして使う発想が要る。

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

5. エスカレーション（escalation）：行き詰まったら人間・別モデル・別ツールに渡す。cascadeflowは品質検証に失敗したら大型モデルへ昇格する switch_model を持つ。

この5軸は独立ではなく連鎖する。停止条件が発火しなければ再計画し、予算を超えれば昇格し、それでもダメなら人間へ——という流れだ。源流は論文にある。ReAct（arXiv:2210.03629）が推論と行動を交互に折り返す原子的なループを定義し、Reflexion（arXiv:2303.11366）がその外側に自己反省のループを巻いた。これが軸4（自己修正）の理論的源流だ。そしてReasoning in Token Economies（arXiv:2406.06461）は「multi-agent debateやReflexionは計算予算を増やすとかえって悪化しうる」と示し、「もっと回せば良くなる」は嘘であることを学術的に裏づけた——軸3（予算ゲート）の必要性そのものだ。

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

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

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

OpenHandsの StuckDetector は、停止条件の中でも「false continue（止まるべきなのに回り続ける）」を検出する仕組みだ。同じ行動が同じ観測を4回以上生む、同じ行動が3回以上エラーになる、といったパターンを意味内容ベース（タイムスタンプの差は無視）で検出して止める。Aiderの max_reflections = 3 は逆に「自己修正は3回まで」と上限を切り、それを超えたら打ち切る。cascadeflowは小型モデルで投機実行し、品質検証に失敗したら大型モデルへ昇格する設計で、予算ゲートとエスカレーションを兼ねる（詳細は cascadeflow解説 を参照）。LangGraphは recursion_limit と条件付きエッジでループ・分岐を、interrupt() / Command(resume=...) で人間の割り込みを表現する（入門は LangGraph入門）。

第6の軸「メモリ」とmem0AIのMemory Loop論

ここまでの5軸は、ループを「どう止め、どう直し、どこへ渡すか」という制御の話だった。 だがその制御がすべて成立しても、ループはもうひとつの理由で壊れる。 エージェントが「自分が何をしてきたか」を忘れたときだ。

この一点を真正面の主張に据えたのが、AIエージェント向けメモリ層を開発する mem0 の公式アカウント（@mem0ai）が米国時間2026年6月17日に公開したX Article「Loop Engineering Works On Memory（ループエンジニアリングはメモリの上で動く）」だ。 mem0は「Memory Layer for your AI agents」を掲げるOSSで、GitHubスター約5.9万・ライセンスはApache-2.0・実装はPython（2026年6月時点）。 LangGraphやCrewAIなどのフレームワークと統合し、エージェントの長期記憶を外部に持たせる用途で使われている。

Loop Engineering Works On Memory. The binding constraint on a long-running loop is not intelligence, tools, or prompting. It is memory. (In Context #13)

— mem0 (@mem0ai) June 18, 2026

記事の主張は短い言葉に集約されている。 「長時間回るループの律速は、知能でもツールでもプロンプトでもない。メモリだ」。 本記事がここまで5軸と7要素で組み立ててきた制御は、メモリという土台がなければ空転する、という指摘である。 7要素の最後に挙げた「永続メモリ」を、設計の付け足しではなくループを回す前提条件へ格上げする読み筋だ。

ループが壊れる場所は、すべて記憶の問題

mem0AIは、長時間ループの既知の失敗を並べ、そのどれもが記憶の欠落に還元できると論じる。 本記事の「3つのハードガード」がコスト側の暴走を止める装置だとすれば、こちらは記憶側の崩れを説明する地図だ。

mem0AIは、最も野心的なループを公開運用するCursorも同じ敵を名指ししていると引く。 Cursorはドリフトとトンネルビジョンを避けるため「定期的なリフレッシュ」を要し、共有状態の管理には楽観的並行制御（読み取りは自由だが、読んだ後に状態が変わっていれば書き込みを失敗させる）を採用したという（Cursor — scaling-agents）。 これは並行ループにおける記憶の規律そのものだ。

なぜループはメモリを「以前より難しく」するのか

「コンテキストに全部積めばいい」という反論は、ループの規模では成り立たない。 mem0AIは3つの理由を挙げる。

そして記憶はコストにも直結する。 古い履歴を毎ターン引きずれば、それは品質リスクである前に毎回課金される行になる。 Boris Cherny氏の「モデルが考えられる程度にコンテキストを軽く保て」という助言と、トークン請求は同じ事実の裏表だ、というのがmem0AIの整理である。

Memory Loopの構造は「読んでから動き、動いてから書く」

mem0AIが描く処方は明快だ。 作業メモリ（毎イテレーションで捨てる、ウィンドウ内の文脈）と、永続メモリ（イテレーションを越えて残す、ウィンドウ外の知識）を分ける。 そして各パスの前に想起し、各パスの後に書き込む。 この往復を図にすると、5軸の制御ループに「メモリ層との読み書き」が一本加わる形になる。

図の左が既存5軸の制御ループ、右が新しく第6軸として据える永続メモリ層だ。 ループは47回目を回すとき、1〜46回目が書き残したものを読んで動く。 作業メモリを毎回リーンなアンカーファイル（VISION.md / CLAUDE.md / PROMPT.md / MEMORY.md / SKILL.md）にリセットしつつ、生き残るべき知識だけを外の層へ逃がす設計である。

第6軸のメモリは、既存5軸と独立して働くのではなく、他の軸へ栄養を送る。 自己修正（軸4）は「前回どう失敗したか」を想起できて初めて同じ轍を避けられる。 再計画（軸2）は「これまで何を試したか」の履歴がなければ、同じ手を繰り返すだけだ。 分業（7要素の4）で検証役が下した判定も、次パスが読むべき記憶になる。 メモリは制御軸の下に敷かれた土台であり、ループを「円」から「螺旋」に変える。

実装の4ルールと、メモリ層をどこに置くか

mem0AIは、ループにメモリを組み込む際の指針を4つ挙げる。 末尾に MEMORY.md を1枚足して終わり、にしないための原則だ。

ルール3が、専用メモリ層の出番になる箇所だ。 フラットファイルと専用メモリ層の差を整理すると次のようになる。

実装の入口は2系統ある。 ループのコードを自分で握っているなら、SDK（mem0のv3 API）で「想起→行動→保存」をコードから駆動する。 エージェント側にツールとしてメモリを呼ばせたいなら、mem0はMCPサーバ・Claude Codeプラグイン・LangGraph / CrewAI連携を提供している（mem0 docs）。 マネージドで使うことも、OSS版を自前で立てることもできる。

メモリをループの「能動的な一手」に引き上げる動きは、mem0だけではない。 Cloudflareの Agent Memory は圧縮の瞬間に介入し、文脈を捨てる代わりに残す価値のある事実を抽出・重複排除する（Cloudflare blog）。 研究側では「Memory as Action（MemAct）」（arXiv:2510.12635）が、エージェント自身に作業メモリの編集を「行動」として学習させ、平均文脈長を51%削減したと報告する。 ただしMemActは査読前のプレプリントで、著者自身のベンチマーク上の数値だ。 方向性を示す材料として読むのが妥当で、確定した成果として扱うべきではない。

mem0AIは末尾でこう締める。 「肝心なのはベンダーではない。ループが1つのコンテキストウィンドウより長く回った瞬間、その信頼性はメモリの問題になり、フラットなファイルはメモリ系ではない」。 本記事の5軸に、第6軸としてメモリを足すべき理由は、この一文に尽きる。

止まらないループが最大のリスク——3つのハードガード

Redditの「不安」枠が突いた論点——トークン代の青天井——は、ループエンジニアリングで最も現実的なリスクだ。Firecrawlはこれを名言で締めている。

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

「3つ」とは、止め方を担保する3つのハードガードを指す。

この警告は実例に裏打ちされている。TechCrunchの報道（2026-06-02）によれば、Uberは対策として1人・1ツールあたり月1,500ドルの上限を導入した。Claude CodeやCursorといったエージェント型コーディングツールが対象で、年間のAI予算をわずか4か月で焼き切った後の対応だと報じられている（同社CTOの公表をTechCrunchが報告）。予算ゲートは「あれば良い」ではなく必須装備だ、というのがこの数字の意味である。

そしてもうひとつ、金額に表れない負債がある。Google Chromeのエンジニアリングマネージャである Addy Osmani 氏がブログ記事（2026-03-14）で提唱する 「理解負債（Comprehension Debt）」 だ。Osmani氏はこれを「システムに存在するコード量と、人間が実際に理解しているコード量とのあいだに広がるギャップ」と定義する。ループが大量のコードを自走生成すると、出力は積み上がるが、それを書いた人間が中身を理解していない、という状態が生まれる。技術的負債が「汚いが動くコード」だとすれば、理解負債は「テストは通るが誰も把握していないコード」だ。止め方の設計（コスト）と、追える設計（オブザーバビリティ）が揃って初めて、自律ループを安心して本番に置ける。逆に言えば、デモでは華やかに回るのに本番投入できないループの多くは、この「止まらなさ」と「追えなさ」でつまずいている。

4ファイルで再現するループ——builder / checker / loop / 停止ルール

ここまでの設計軸（停止条件・再計画・予算・自己修正・エスカレーション）は概念の地図だ。それをClaude Codeの設定ファイルに落とすと何行になるのか、という問いに、AI＆ファイナンス領域の起業家 darkzodchi（@zodchiii）氏が具体的な配置を公開している。同氏のX長文記事「How to Build a Claude Code Agent Team That Runs in Loops」は、builder（作る人）と checker（検査する人）を分け、両者を回すオーケストレーターと停止ルールを置く、という4ファイル構成を示す。閲覧120万・ブックマーク3,000超と反応が大きく、5軸の抽象論を最小実装で確かめる素材になる。

How to Build a Claude Code Agent Team That Runs in Loops (Exact Setup Inside)

Most setups run agents once and hand you whatever comes out. A team that runs in loops keeps going until the work actually passes.

— darkzodchi (@zodchiii) June 16, 2026

zodchi氏が一回きりのチームを批判する言い方は明快だ。

一度だけ走るチームは、ゴール判定のないリレー競走だ。書き手が書き、検査役が検査し、レビュー役がレビューして、壊れた部品ごとすべてが自分の手元に落ちてくる。
原文：“A team that runs once is a relay race with no finish line check.”（darkzodchi — X記事）

「ゴール判定（finish line check）」を欠いた一直線の受け渡しでは、検査役が失敗を見つけても報告して終わる。ループが閉じれば、その失敗は自動でbuilderへ戻り、緑になるまで回り続ける。本記事の言葉で言えば、これは再計画（replan）と自己修正（self-correction）を分業で固定した最小形だ。

File 1: 作る人と検査する人を分ける（.claude/agents/）

builderは実装と修正だけを担い、checkerは検査だけを担う。同じエージェントに両方をやらせると、バグを生んだ盲点のまま自分の仕事を採点してしまう——分業はそれを避けるための線引きだ。

# .claude/agents/builder.md
---
name: builder
description: Writes and fixes code. Invoke to implement a task or to fix failures the checker found.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
---

You build and you fix. Nothing else.

- On a new task: implement it, matching existing style.
- On a fix request: read the failure, find the cause, fix that cause only.
- Never weaken a test to make it pass. Fix the code.
- Report what you changed in one line.

# .claude/agents/checker.md
---
name: checker
description: Runs all checks and reports what failed. Invoke after the builder. Never edits code.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You check, you never fix.

Run all three, in order:
1. Tests: `npm test` (or `pytest -q`, `cargo test --quiet`)
2. Types: `npx tsc --noEmit` (or `pyright`, `cargo check`)
3. Lint: `npm run lint` (or `ruff check`, `cargo clippy`)

Then report in this exact format:
- All pass: "ALL GREEN"
- Any fail: "FAILED" then each cause as
  `file:line - what broke - which check caught it`

Never paraphrase a failure. Copy the real error.

checker側の「失敗を言い換えるな、実エラーをそのまま貼れ」という指示が効いている。検査結果はそのままbuilderの入力になるため、要約してしまうと修正の手がかりが落ち、サイクルを1周丸ごと無駄にする。

File 2: 回す（.claude/commands/loop.md）

オーケストレーターは build → check → 失敗なら再びbuild、という循環そのものだ。failを人間が中継せず、checkerの出力をbuilderへ自動で渡す点が肝になる。

# .claude/commands/loop.md
---
description: Run the builder and checker in a loop until all checks pass
argument-hint: <task>
allowed-tools: Read, Grep, Glob, Bash, Task
model: opus
---

Run this task as a loop: $ARGUMENTS

1. Write a one-line brief: goal, files in scope, definition of done.
2. Dispatch the builder to implement the task.
3. Dispatch the checker to run all checks.
4. If checker says ALL GREEN: stop, show me the result.
5. If checker says FAILED: send the failures to the builder to fix,
   then go back to step 3.
6. Repeat up to 5 cycles. Track the cycle count out loud.

Stop conditions are in CLAUDE.md. Follow them exactly.

オーケストレーター側に model: opus、実働エージェントに model: sonnet を割り当てているのが目を引く。判断（どの失敗を誰にどう渡すか）に強いモデルを置き、反復作業は安いモデルで回す——本記事の「予算」軸を、モデル選択の粒度で実装した形と読める。

File 3: 止める（CLAUDE.md）

ブレーキのないループは永遠に回るか、緑を偽装する。停止ルールはオーケストレーターが従う4条件として CLAUDE.md に置く。

## Loop stop rules

The team loops until one of these is true:

- ALL GREEN: every check passes. Stop and report success with proof.
- 5 cycles used: stop. Report what still fails and what was tried.
- Same failure twice in a row: stop. The builder is guessing, not
  fixing. Escalate to me.
- A fix makes a previously passing check fail: stop. Something is
  being broken to fix something else.

Never report success without checker output from the final cycle.
Never weaken or delete a check to reach ALL GREEN.

zodchi氏が4条件のうち最重要に挙げるのが「同じ失敗が2回続いたら止める（same failure twice）」だ。同じエラーが連続するのは、builderが直しているのではなく当て推量で叩いている兆候であり、サイクル4を使う前に人間が見るべき瞬間だ、と説明する。本記事のエスカレーション軸——「ループが自力で抜けられない壁に当たったら人間へ昇格する」——を、判定可能な1行のルールに落としたものになっている。

4ファイルは5軸のどこを埋めるか

zodchi氏の構成を本記事の5つの設計軸に重ねると、最小実装が軸のどこを担保しているかが見える。逆に、この表で空欄に近い軸（再計画の中身・予算キャップの金額制御）が、OSS実装やcascadeflowが踏み込む領域だと分かる。

zodchi氏が挙げる「よくある失敗」も、本記事のハードガードと一対一で対応する。サイクル上限がなければ詰まったチームがトークンを焼き尽くす（＝イテレーション上限）。builderに自己採点させれば盲点が残る（＝分業）。同一失敗2連続ルールがなければ当て推量に4周目を費やす（＝差分ゼロチェックの思想）。検査役がテストを消して緑にできてしまえばいずれそうする（＝「検査を弱めて緑にするな」）。最小構成でも、止め方の設計を省くと「ループ」ではなく「開いた請求書」に戻る、という先の警句がそのまま当てはまる。

Google CEO Sundar Pichai が語るエージェント運用

ループを設計する動きは、個人開発者の現場にとどまらない。 GoogleとAlphabetのCEOである Sundar Pichai 氏も、組織規模で同じ移行を語っている。 CEO就任10年の節目にあたる2026年5月20日、Pichai氏はForward Futureの Matthew Berman 氏による約30分のインタビューに応じ、エンジニアの仕事がコードを書くことからエージェントを動かすことへ移りつつある、という観測を述べた。

このインタビューで、Pichai氏はフロンティアの開発者がエージェントを動かす側に回っていると述べている。逐語で引用する。

開発者は実際にエージェント型のワークフローを回している。フロンティアにいる開発者は、実際にエージェントを配備し、エージェントを動かしている。
原文：“developers are actually doing agentic workflows. The developers on the frontier are actually deploying agents, orchestrating agents.”（Sundar Pichai, Forward Future インタビュー / Matthew Berman, 2026-05-20）

組織側の運用は、別の公式発表に数字として残っている。2026年4月22日のCloud Next ‘26基調講演で、Pichai氏はGoogle社内の状況を次のように報告した（いずれもGoogle公式ブログ blog.google の逐語）。

これらの発言は、本記事がここまで整理してきた枠組みと素直に重なる。 「エージェントを動かす（orchestrating agents）」という表現は、Boris Cherny氏の「私の仕事はループを書くことだ」という実務者の言葉を、経営者の側から裏づける。 「自律的なタスクフォースを走らせる」運用は、解剖学でいう分業（writer / reviewer）と永続メモリを前提にする。 複数のエージェントを同時に走らせる以上、隔離と状態の持ち越しがなければ成り立たないからだ。 そして「1年前の6倍速」という数字は、5つの設計軸でいう予算ゲートの必要性を裏側から照らす。 速度が出るからこそ、止め方と上限を設計しないとコストが先に破綻する。 一方で「新規コードの75%がAI生成」という比率は、前述した理解負債（Comprehension Debt）の量がそれだけ増えていることも意味する。 書かれたコードと、人間が把握しているコードの差は、生成比率が上がるほど開く。

引用にあたって、ひとつ注意すべき点がある。

公式発表に残る数字は、エージェントを動かす運用が一部の先端開発者の実験から、CEOが業績の文脈で語る段階へ移ったことを示す。 個人開発者のSteinberger氏・Cherny氏と、CEOのPichai氏が、立場の違いを越えて同じ移行を語っている点に、この概念の現在地が表れている。

テイストという最後のボトルネック

「これは次の抽象化レイヤーか、それとも一過性のバズワードか」——冒頭でReddit民が割れた問いに、最後に向き合う。手がかりは、OpenAI共同創業者のGreg Brockman氏が掲げた「テイスト（taste）」の論点だ。Brockman氏はこう端的に言い切っている。

taste is a new core skill

— Greg Brockman (@gdb) February 16, 2026

「テイストは新しいコアスキルだ」。ソフトウェアを作ること自体がボトルネックでなくなった時代に、何を良しとするかの判断こそが希少資源になる、という主張である。Firecrawlはこの論点をループに引きつけて、次のように敷衍している（逐語引用ではなく要旨）。

ここにループエンジニアリングの本質がある。ループは賢さを生み出す魔法ではない。人間が「何をもって完了とするか（ルーブリック）」に込めた判断を、増幅する装置だ。良い判断を込めれば良い成果が増幅され、雑な判断を込めれば雑な成果が大量に増幅される。だからこそ、止め方・検証・分業の設計が成果を左右する。

この見方に立てば、「ただのcron jobだ」という冷笑は半分正しく、半分間違っている。仕組みとしてはwhileループに近い——そこは正しい。だが最適化対象が「スケジュール」ではなく「ルーブリックという人間の判断」である点で、決定的に違う。ループエンジニアリングは、コードを書く技能ではなく、判断を設計して増幅させる技能だ。用語が定着するかは分からない。だが「ループをどう止め、何をもって良しとするか」という問いそのものは、自律エージェントを本番で回す限り消えない。

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

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

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

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

まとめ——宣言から、設計へ

Peter Steinberger氏の6語の宣言「ループを設計しろ」は、コーディングエージェントの使われ方が委任へ移ったことを可視化した。Boris Cherny氏は「もうプロンプトは書いていない、ループを書いている」と作者の立場から裏づけ、Redditは肯定・冷笑・不安に割れた。本記事はその渦中で、ループエンジニアリングを宣言から設計へ落とし込んだ。

3つのチェック（繰り返し・検証可能・価値あり）でタスクを仕分け、7つの解剖要素（トリガー・隔離・コード化された文脈・分業・コネクタ・プラグイン・永続メモリ）で部品を揃え、5つの設計軸（停止条件・再計画・予算ゲート・自己修正・エスカレーション）で制御を組む。そして3つのハードガード（反復上限・差分チェック・スペンドキャップ）がなければ、それはループではなく「開いた請求書」だ。

mem0AIが2026年6月に投じた「Loop Engineering Works On Memory」は、その制御の下に第6の軸を敷いた。 ループが1つのコンテキストウィンドウより長く回った瞬間、信頼性はメモリの問題に変わる。 良い判断（テイスト）をルーブリックに込めても、それを次パスへ運ぶ記憶がなければ、ループは螺旋ではなく円を描いて同じ場所に戻ってくる。

一方で、誠実に認めておくべきこともある。「ループエンジニアリング」という用語はまだ過渡期にあり、これは2026年6月時点の議論だ。定義は書き手ごとに揺れ、Harness EngineeringやContext Engineeringとの境界も流動的である。Redditで観測された「結局これは帽子をかぶったcron jobだ」という冷笑も、用語のインフレを警戒する声として無視はできない。当サイト（AI Heartland）はこの概念の提唱者ではなく、あくまで一次ソースを整理する観察者の立場であり、定義を断定するのではなく、Steinberger・Cherny・Osmani・Brockman・Firecrawlの発言を出典付きで併記して読者が選べる形にした。

それでも、Brockman氏の「テイストは新しいコアスキルだ」という言葉が示すとおり、ループは人間の判断を増幅する装置である。良い判断を設計できる人にとって、ループは最大の増幅器になる——今はまだ、それで十分だ。

参照ソース

・Firecrawl（Hiba Fathima）— Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops
・Greg Brockman（OpenAI 共同創業者）— X投稿「taste is a new core skill」
・darkzodchi（@zodchiii）— How to Build a Claude Code Agent Team That Runs in Loops（X記事・builder/checker/loop/停止ルールの4ファイル構成）
・Addy Osmani（Google Chrome）— Comprehension Debt（理解負債）
・TechCrunch — Uber caps employee AI spending after blowing through budget in 4 months
・Peter Steinberger — X投稿（”design loops that prompt your agents”）
・Shann Holmberg — X投稿（open loop / closed loop）
・Boris Cherny — Claude Code & the Future of Engineering（Acquired Unplugged presented by WorkOS, YouTube）
・Reddit r/myclaw — So is “loop engineering” the next AI dev buzzword?
・Forward Future（Matthew Berman）— Google CEO: Agents, Open Source, Race to AGI（Sundar Pichai 公式インタビュー, YouTube）
・Singju Post — Google CEO Sundar Pichai on Agents, Open Source, Race to AGI（Transcript）
・Google 公式ブログ — Sundar Pichai shares news from Google Cloud Next 2026
・Addy Osmani — Loop Engineering
・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）
・Reasoning in Token Economies（arXiv:2406.06461）
・mem0（@mem0ai）— Loop Engineering Works On Memory（X Article, 2026-06-17）
・mem0 公式サイト ／ mem0ai/mem0 GitHub
・mem0 — BEAM benchmark解説（1M context window isn’t enough）
・Cloudflare — Introducing Agent Memory
・LongMemEval（arXiv:2410.10813） ／ Memory as Action / MemAct（arXiv:2510.12635, 査読前） ／ MemoryArena（arXiv:2602.16313）