Loop Engineering：AIとの協働を変える静かな革命

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." — Boris Cherny, Head of Claude Code, Anthropic (2026)

---

プロンプト時代の終わり

ここ数年、AIとの協働における主流のメンタルモデルは単純だった。入力すれば、応答が返ってくる。 巧みなプロンプトを書き、コンテキストを貼り付け、出力を読み、また入力する。人間は常に運転席に座り、テニスの試合のように一往復ずつやり取りする。この方法は――ある程度までは――うまく機能していた。

しかし、その時代は静かに終わりを迎えている。

**Loop Engineering（ループ・エンジニアリング）**の世界へようこそ。これはおそらく、2022年のGitHub Copilot登場以来、AI支援開発における最も重要な転換だ。目的は「より良いプロンプトを書くこと」ではない。プロンプトを入力する人間そのものを不要にすることだ。

---

ループとは正確には何か？

エージェント型AIにおいて、ループとはモデルが行動を取り、環境からフィードバックを受け取り、そのフィードバックを使って次の一手を決める――目標条件が実際に満たされるまで続く――繰り返しのサイクルである。これは連鎖（A → B → C）ではない。動的なのだ。エージェントはA→Bと進み、Bが失敗したことを発見し、アプローチを見直し、再試行する――すべて人間が見守ることなく行われる。

このアイデアはプリンストン大学とGoogleの研究から生まれたReActパターン（Reason + Act、推論と行動）に遡る。サイクルは次のようになる。

1. 目標を理解する
2. コードを書く／行動を取る
3. 実行して出力（またはエラー）を観察する
4. 何が間違っていたかを推論する
5. 修正して再実行する
6. 完了するまで繰り返す

このフィードバックループ――推論、行動、観察、繰り返し――こそがループ・エンジニアリングの核心である。 (2)

---

プロンプト → コンテキスト → ハーネス → ループへ

ループ・エンジニアリングがなぜ重要かを理解するには、私たちがどのようにここに至ったかの軌跡を見る必要がある。AI開発のパラダイムは、わずか4年で3回シフトしている。

ある鋭い比喩がこう言い表している。「2022年、私たちは完璧なメールの書き方を研究した。2025年、私たちは受信箱の管理を学んだ。2026年、私たちはメールシステムそのものを設計している。」 エンジニアリングの厳密さが消えたわけではない――それは単に移動したのだ。プロンプトからコンテキストへ、そしてコンテキストからシステムアーキテクチャへ。 (4)

ループ・エンジニアリングはこのスタックの頂点に位置する。Peter Steinbergerは見事に言い当てた。「あなたはもうコーディングエージェントにプロンプトを入力すべきではない。エージェントにプロンプトを与えるループを設計すべきだ。」 (1)

---

優れたループを構成する五つの柱

すべてのループが平等ではない。設計が不十分なループはトークンを浪費し、永遠に実行され続け、進捗を幻覚する。堅実なループは五つの要素――加えて一つの重要な記憶層――で構成される。

自動化（心拍）

タイマー、gitイベント、またはCI信号によって、自律的に発見とトリアージを行う定期トリガー。これこそがループを本当のループにする要素であり、単なる一回きりの実行ではない。Claude Codeの/loopや/goalコマンド、あるいはCodexのAutomationsタブがこれを体現している。 (1)

ワークツリー（混乱のない並行実行）

複数のエージェントが同時に作業する場合、それぞれに分離された環境が必要になる。Gitワークツリーは各エージェントに独自の作業ディレクトリを与え、互いに上書きし合わないようにする――これは人間同士の協調でも起きる問題を、システムレベルで解決したものだ。

スキル（体系化された知識）

すべてのプロンプトに巨大な指示ブロックを貼り付ける代わりに、プロジェクトの知識を再利用可能なSKILL.mdファイルに符号化し、エージェントが名前で呼び出せるようにする。これによりループは長期的に保守可能で一貫性のあるものになる。

プラグインとコネクタ（ツールへのアクセス）

ループは、エージェントが実世界とやり取りできる場合にのみ機能する――テストの実行、ファイルの読み取り、APIの呼び出し、LinearやGitHubへの書き込みなど。ツールセットの質が、ループの効果を直接左右する。エージェントが自分のコードを実行できないなら、ループは単なる当て推量にすぎない。 (2)

サブエージェント（発想と検証）

一つのエージェントが提案し、別のエージェントが検証する。この関心の分離――コードを書いたエージェントが、それを採点するエージェントではない――は、エージェント型システムにおいて最も強力な信頼性パターンの一つである。 (3)

記憶（接着剤）

Markdownファイル、Linearのボード、単一の会話の外側に存在するものなら何でもよい。モデルは実行ごとにすべてを忘れる。しかしリポジトリは忘れない。この外部記憶こそが、複数セッションにわたるループをつなぎ止める糸である。

---

なぜこれがすべてを変えるのか

その影響は深い。ループ・エンジニアリングは開発者の役割を操作者から設計者へと変える。あなたはもうクランクを回す人間ではない。クランクを回す機械を設計する人間になるのだ。

これはソフトウェア開発において特に強力だ。なぜならソフトウェア開発は本質的に反復的だからだ。経験豊富なエンジニアでさえ、一度で完璧なコードを書くことはない。実行し、エラーを見て、修正し、再度実行する。ループ・エンジニアリングはAIエージェントに同じフィードバックサイクルを与え――そのプロセスの中間にいる人間のボトルネックを取り除く。 (2)

Claude CodeとCodexの両方にある/goalプリミティブは完璧な例だ。「test/authのすべてのテストが通過し、lintがクリーンである」といった検証可能な停止条件を定義し――その場を離れる。別の小型モデルが各ターンの後に完了したかどうかをチェックするため、コードを書いたエージェントがそれを採点するエージェントにはならない。 (1)

---

正直な留意点

ループ・エンジニアリングは本当にワクワクするものだ――しかしそのリスクについて正直である必要がある。

• トークンコストが急激に膨らむ可能性がある。 自律的なループは、慎重に制限しなければ莫大な量のトークンを消費する可能性がある。「トークンが豊富な」チームと「トークンが乏しい」チームでは、使用パターンが大きく異なる。
• 曖昧な目標は無限ループを生む。 「アプリをより良くする」はループ条件ではない。「すべての単体テストを通過させる」はそうだ。
• 監査対象がコードから軌跡へと移る。 決定論的なワークフローでは、すべてのステップがソースコード内で追跡可能だ。エージェント型ループでは、その軌跡は実行過程の中に存在する――これはロギングと人間の承認チェックポイントに関する新しいパターンを必要とする。 (3)
• まだ初期段階にある。 Addy Osmaniがこのテーマに関する基礎的な投稿で述べたように：「私は懐疑的だし、絶対に注意を払わなければならない。」 ツールは急速に成熟しているが、ベストプラクティスはまだ書かれている最中だ。 (1)

---

結論

ループ・エンジニアリングは誇大広告ではない。単発的なプロンプトでできることを使い果たした後の、自然な次の一歩――真のアーキテクチャ上の転換である。2026年以降に活躍するエンジニアは、最も巧みなプロンプトを書く人たちではない。最も洗練され、信頼性が高く、自己修正する仕組みを設計する人たちだ。

ループこそが、新しい作業の単位である。それを設計する方法を学べ。

---

参考資料

1. Addy Osmani, "Loop Engineering", addyosmani.com, June 7, 2026 — addyosmani.com
2. MindStudio Team, "What Is Loop Engineering? The New Meta for AI Coding Agents", mindstudio.ai, June 9, 2026 — mindstudio.ai
3. Molisha Shah, "What Are Agentic Design Patterns? 2026 Pattern Catalog", augmentcode.com, May 18, 2026 — augmentcode.com
4. "From Prompts to Harnesses — Four Years of AI Agentic Patterns", bits-bytes-nn.github.io, April 5, 2026 — bits-bytes-nn.github.io