Loop Engineering：プロンプトを書く代わりに、エージェントが自律実行するループを設計する方法

2026年6月7日、Addy Osmaniがブログで「Loop Engineering」という長文を公開し、Anthropic Claude Codeの責任者Boris Chernyの言葉を引用した。「自分はもうClaudeにプロンプトを書いていない。ループにClaudeへのプロンプトを書かせている。ループが次に何をすべきかを自分で決める。私の仕事はループを書くことだ。」

この言葉はPeter Steinbergerにより「もうエージェントにプロンプトを書くべきではない。エージェントが自律実行するループを設計すべきだ」というスローガン風に翻訳され、その後数日のうちにLoop Engineeringという用語はAI開発コミュニティで急速に広まった。

なぜLoop Engineeringが突然共感を呼んだのか？

二つの変化の重なりがこの概念を生み出した。

変化一：単一プロンプトのレバレッジが崩壊している。 Claude Code、Cursor Composer、Clineといったツールにより、「一つのプロンプト → 一つの観測可能な作業」は数十秒から数十分、さらには数時間にまで引き伸ばされた。一度の対話で一つのフィーチャーを提供できるようになった今、「プロンプトを磨くために30秒を費やすことの限界利益は希釈されている」。

変化二：エージェントが24時間走れるようになった。 GitHub Actions、cron、Claude Codeの/loopコマンドは、誰も見ていなくてもエージェントに作業を継続させられる。エージェントがセッションから独立して存在できるようになると、「誰がエンターキーを押すか」が新たなボトルネックになる。

Osmaniの言葉を借りれば、「Loop engineeringとは、エージェントにプロンプトを書く自分自身を置き換えることだ」。つまり、エンターキーを押すあなたの代わりにループを使うのだ。

五つのコンポーネント + 一つのState

Osmaniは、実行可能なループを五つのコンポーネントと一つの共有Stateに分解する。重要度の高い順に並べる。

1. State（共有メモリ）

ループをまたがって読み書きできる場所。Markdownファイル、SQLite、TODO.mdなど媒体は問わない。単一の情報源であることが重要だ。

Stateはループの外に置かなければならない。Stateを会話履歴の中に詰め込むのは反パターンだ。「前回どこまで話したか」というセッションコンテキストに依存するループは、コンテキストウィンドウが一杯になると存続できない。

2. Sub-agent（検証/分業）

二つ目のエージェントを使って、最初のエージェントの出力を検証する。Maker-Checkerパターンだ。

重要な詳細：審査エージェントは独立したコンテキストを持つ必要がある。もし同じセッション内で「もう一度考えて問題がないか確認せよ」と頼むと、モデルは自分自身を肯定する傾向がある。物理的に二つのプロセスを分離して初めて効果がある。

3. Automation（トリガー）

ループをいつ起動するか。三つの種類がある：

• スケジュール駆動：固定時間に実行する（cron）
• イベント駆動：特定のイベント（PRのコミット、issueの作成）で起動する
• ゴール駆動：検証可能な目標条件を与え、ループが自ら実行し、目標に達したかを判断し、達したら停止する

ゴール駆動は最も過小評価されやすいパターンだ。ゴールがなければ、ループは最大反復回数で強制停止するか、人間が停止ボタンを押すのを待つしかない。

4. Skill（コンテキストの再利用）

「このプロジェクトでX系のことをどう行うか」を再利用可能な単位にまとめる。Claude CodeではSKILL.md、Cursorでは.cursorrulesだ。

Skillはプロンプトのエンジニアリング版だ。「よく書かれたプロンプトの断片」から「プロジェクト内全員が使用し、バージョン管理され、複数のループから参照可能なプロンプト」へと格上げされる。

5. Worktree（並列分離）

並列実行される各エージェントが独立したgit worktreeを持ち、互いに汚染しないようにする。

6. Plugin/Connector（外部ツール）

MCPサーバー、APIコネクタ、CLIラッパーなど。エージェントがテキストを出力するだけでなく、データベースの変更、コミットの実行、PRの送信などを行えるようにする。

これは最も目立つコンポーネントだが、最も過大評価されやすい。StateやSub-agentなしに、プラグインを大量に接続するのは自分自身に地雷を埋めるようなものだ。

階層関係

エージェント工学：このシステムが目標を確実に達成できるかどうか
└── ハーネス工学：エンジンの外にある機械
    ├── Loop Engineering：ループ自体の設計方法
    ├── 他のハーネスサブ項目：ツール呼び出し、可観測性、ガードレール
    └── コンテキスト工学：ウィンドウに何を詰め込むか
        └── プロンプト工学：一文をうまく書く方法

Loop Engineeringは五番目の層ではなく、ハーネス層内で独立して名付けられたエンジニアリングのサブ分野だ。

三つの負債：ループが順調に動くほど、あなたは崩れ落ちるかもしれない

1. 検証負債（Verification Debt）

ループが実行完了すると「タスク完了」と出力するが、この四文字はエージェントの主張に過ぎず、証明ではない。CIがグリーンになってもロジックが正しいとは限らないし、PRが提出されてもコードが保守可能だとは限らない。

返済方法は一つしかない。手動による検証ステップをループに書き込み、物理的にループを停止させて人間や実行可能なテストを待つようにする。

2. 理解負債（Comprehension Debt）

ループにより一晩で10個のPRをマージできるようになったが、あなたはその10個のPRが何を変更したのか本当に理解しているだろうか？ 6ヶ月後にプロダクションでバグが発生し、自分のリポジトリの前で見慣れないコードを見つめることになる。

返済方法は減速して読むことだ。重要なモジュールについて、ループで書き終わったらすぐにマージせず、自分で一度読み、「なぜこのように書いたのか」と一言二言注釈を付ける。

3. 認知降伏（Cognitive Surrender）

ループが順調に動けば動くほど、あなたはさらに実行させたくなる。「押せば結果が出る」体験があまりに心地よすぎるからだ。そしてある日、「このことをすべきかどうか」という思考をやめ、「どのループに実行させるか」だけを考えている自分に気づく。

Osmaniの言葉を借りれば、「心地よい姿勢こそが危険な姿勢だ」。この負債はツールで返済できない。自覚に頼るしかない。

一文で要約する

ループが変えるのはあなたの仕事内容であり、あなたを削除するのではない。 検証負債にはあなたの確認が、理解負債にはあなたの読解が、認知降伏にはあなたの思考が必要だ。三つ全てを返済して初めてLoop Engineeringはレバレッジとなる。どれか一つでも未返済なら、それは慢性毒薬となる。