## はじめに
2026年6月、AIコーディングの界隈で「ループエンジニアリング（Loop Engineering）」という言葉が一気に広がった。発端は、OpenClawの作者として知られるPeter Steinberger氏が6月7日にXへ投稿した、たった2文のポストだった。「もうコーディングエージェントにプロンプトを打つのはやめろ。エージェントにプロンプトを打つ”ループ”を設計しろ」。この投稿は数日で200万回以上表示され、開発者のタイムラインを賛否で二分した。
翌日、GoogleのエンジニアであるAddy Osmani氏が、この議論を「Loop Engineering」と題したブログ記事で体系化し、概念として定着させた。さらにこの潮流を象徴したのが、AnthropicでClaude Codeを率いるBoris Cherny氏の発言である。「私はもうClaudeにプロンプトを打っていない。プロンプトを打つループを走らせているだけだ。私の仕事はループを書くことだ」。
本稿では、この新しい設計思想が「何を指し」「なぜ今登場したのか」「どう組み、どこで止めるのか」を、一次情報をもとに普通の説明記事として整理する。
## ループエンジニアリングの定義
ループエンジニアリングとは、AIエージェントに毎回プロンプトを打つ「人間の役割」そのものをやめ、エージェントに指示を出し続ける”仕組み（ループ）”を設計する考え方である。
ここで言う「ループ」とは、一度ゴール（目的）を定義すれば、AIが完了条件を満たすまで自律的に反復していく「再帰的なゴール」のことだ。従来は「人間がプロンプトを打つ → AIが応答する → 人間が次の指示を考える → また打つ」という、人間が毎ターン駆動する往復だった。ループエンジニアリングはここから一歩進み、「プロンプトを生成し、実行し、結果を検証し、ゴールに達するまで繰り返すシステム」そのものを設計対象にする。
言い換えれば、勝負どころが「1回のプロンプトの質」から「プロンプトを生成・検証し続ける仕組みの質」へ移った、ということだ。
## なぜ今なのか──AI工学が積み上げてきた4つの階段
この概念は突然現れたものではなく、ここ数年でAIとの付き合い方の抽象度が一段ずつ上がってきた延長線上にある。重要なのは、各層は下の層を「置き換える」のではなく、その上に「積み上がる」という点だ。
第一が「プロンプトエンジニアリング」（〜2024年）。1回の指示の質を最大化する段階である。第二が「コンテキストエンジニアリング」（2025年）。モデルに渡す情報・文脈の全体を設計する段階だ。第三が「ハーネスエンジニアリング」（2026年初頭）。1体のエージェントが動く実行環境・ツール・検証ゲートといった”足回り”を設計する段階。そして第四が「ループエンジニアリング」（2026年6月〜）。その実行環境を自走させ、反復制御まで設計する段階である。
Osmani氏の整理では、ハーネスが「1体のエージェントが動く環境」なのに対し、ループはその一つ上の階に位置する。タイマーで動き、補助エージェントを生み出し、自分自身に仕事を供給し続ける仕組みだ。
注意したいのは、プロンプトエンジニアリングの基礎が不要になるわけではないことだ。ループは結局プロンプトの集合体でできているため、雑なプロンプトをループに入れれば、雑な仕事が高速で量産されるだけになる。土台は依然として効いている。
## ループを構成する5つの部品（＋メモリ）
Osmani氏は、機能するループは5つの構成要素＋外部メモリでできていると整理した。この枠組みはClaude CodeとOpenAI Codexの双方にほぼそのまま対応するため、ツール固有の話ではなく「ループそのものの構造」だと言える。
ひとつ目は「Automations（自動化トリガー）」。タイマーやgitイベント、CIシグナルなどをきっかけに、発見とトリアージを自律的に行う。これがループを「一度きりの実行」ではなく本物のループにする心臓部だ。
ふたつ目は「Worktrees（並列作業ツリー）」。複数のエージェントが同時に作業するとき、別々の隔離された作業ディレクトリを与え、互いのファイルを上書きしないようにする仕組みである。
みっつ目は「Skills」。プロジェクトの文脈や手順を書き残し、エージェントが毎回当てずっぽうで判断しないようにする。「あなたしか知らない」暗黙知を「エージェントも知っている」構造化された入力に変える作業だ。
よっつ目は「Connectors／Plugins（連携）」。GitHub、Linear、Slack、データベースといった既存ツールへエージェントを接続する。ループは現実の状況を読み取り、結果を現実に書き戻す必要があるため、この双方向のチャネルが欠かせない。
いつつ目は「Sub-agents（サブエージェント）」、とりわけ実装者と検証者の分離だ。これが構造的に最も効く設計だと多くの実務家が口を揃える。理由は単純で、コードを書いたモデルは自分の成果に甘い採点をしがちだからだ。実装するエージェントとは別に、文脈をきれいにした検証エージェントに粗探しをさせて初めて、「本物の問題」が表面化する。
そして見落とされがちな六つ目が「外部メモリ／状態」である。エージェントは実行と実行の間に文脈を忘れてしまうため、進捗や決定事項をマークダウンファイルやタスクボードなど、ディスク上の永続的な場所に書き出しておくことが必須になる。「エージェントは忘れるが、リポジトリは忘れない」というわけだ。
## 設計で最も難しいのは「自律」ではなく「止め方」
ループエンジニアリングというと完全自律ばかりが注目されがちだが、本当に難しいのは検証・停止条件・人間へのエスカレーションの設計である。
なかでも核心が「検証可能なゴール」だ。「いい感じにしておいて」のような曖昧な目的では、機械はいつ止まればよいか判断できない。「全テストが通る」「ビルドがexit 0になる」「キューが空になる」といった、真偽を機械が判定できる終了状態を設計することが、ループ設計の肝になる。Claude Codeの「/goal」やCodexの「/goal」は、まさにこの完了条件方式を製品として実装した例だ。
## 最大のリスクと「3つのガード」
「ただのcron jobに帽子をかぶせただけだろう」という冷ややかな見方に対する、実務的な答えがここにある。
第一のリスクはコストの爆発だ。エージェントは通常のチャットの約4倍、マルチエージェントでは最大15倍のトークンを消費すると報告されている。実際、Uberは4ヶ月で年間のAI予算を使い切り、Claude CodeとCursorを1人あたり月1,500ドルに制限した。回し続ける以上、「いつ止めるか」「いくらまで使うか」を設計しなければ、品質以前に請求額が破綻する。
この対策が「3つのハードガード」である。すなわち、(1) 反復回数の上限、(2) 直近数回で差分（diff）が変わらなくなったら止めるチェック、(3) トークンまたは金額の上限。この3つが揃っていなければ、それはループではなく”開いた請求書”だ、とまで言われる。
第二のリスクは、より静かで根が深い「理解の負債（comprehension debt）」だ。ループが自分の書いていないコードを速く出荷するほど、リポジトリに実際に存在するものと、自分が理解しているものとの差が広がっていく。唯一の解毒剤は、ループが作ったものを実際に読むこと。ループがスムーズに回っているからといって、中身の理解をやめてはいけない。
第三のリスクは「思考停止（cognitive surrender）」である。ループが自動で回りはじめると、返ってきた結果をそのまま受け入れるのが最も楽になる。だが、同じループを2人が使っても、片方はそれで時間を空けてより深く考え、もう片方は思考の回避に使う。3ヶ月後の差は大きい。ループは違いを知らない。違いを知っているのは人間の方だ。
## おわりに
ループエンジニアリングは、流行語というより「エージェントが賢くなった結果、人間の仕事の重心が”指示”から”設計”へ移った」ことの呼び名である。コードを書く仕事から、ループを書く仕事へ。レバレッジの支点が動いた、ということだ。
ただし、これは「仕事が楽になった」という話ではない。むしろ設計の比重が増し、検証とコスト管理の責任は人間に残り続ける。Osmani氏の締めの言葉が、この技術との向き合い方を言い当てている。「ループを作れ。ただし、ただ”go”ボタンを押す人ではなく、これからもエンジニアであり続けるつもりの人として作れ」。
—
主な参照元：
– Addy Osmani「Loop Engineering」addyosmani.com（2026年6月7日）
– Peter Steinberger / Boris Cherny の公開発言（2026年6月）
– 日本語・英語・中国語の各解説記事（OptiMax、Qiita、Zenn、AI Heartland、Fyve、日経クロステック、Lushbinary、explainx.ai、Firecrawl、菜鸟教程、知乎、CSDN 等）
※本稿は信頼できる公開情報をもとに再整理した説明記事です。ツールの仕様・コマンド・価格は変更される場合があるため、利用前に各公式サイトでの確認を推奨します。