「もうエージェントにプロンプトを打つな」——2026年6月、開発者コミュニティで広がったこの主張は、単なる煽りではありません。AnthropicのClaude Code責任者Boris Cherny氏は、自分はもうClaudeに直接指示せず、ループがClaudeに指示を出す仕組みを書いていると述べています（参考）。この考え方に名前を付けたのがGoogleのAddy Osmani氏で、6月7日のブログ記事でLoop Engineering（ループ工学）と定義しました。
この記事では、話題の11ページPDFガイド「Loop Engineering橙皮书」が整理する設計思想と、実務で使える5つの動き・6つの部品を解説します。
この記事でわかること
- Loop Engineeringが従来のプロンプト設計と何が違うか
- 1周のループを構成する5つの動き（Discovery〜Scheduling）
- Claude Codeで使える
/loopや/goalなどの具体手段 - ループ導入時に見落としやすい4つのコスト
なぜ「ループ」を設計するのか
AIコーディングエージェントの利用は、長い間「良いプロンプトを書き、返答を読み、次の指示を打つ」という対話型でした。1回のやり取りをうまくする技術は、プロンプトエンジニアリングからコンテキストエンジニアリング、ハーネスエンジニアリングへと段階を重ねてきました。
Loop Engineeringは、その一段上の層です。人間が毎回指示を出すのではなく、仕事を見つけ、渡し、検証し、記録し、次を起動する仕組みを先に組み立てます。OpenAIのPeter Steinberger氏も「コーディングエージェントにプロンプトを打つな。エージェントにプロンプトを打たせるループを設計しろ」と同趣旨を発信しています（参考）。
課題は「エージェントの能力」ではなく「人間が常に傍にいなければ回らない構造」にあります。ループ設計は、このボトルネックを外すための発想転換です。
11ページPDFが示す5つの動き
英語版ガイド「Loop Engineering: The Complete Guide」（全11ページ）は、GitHub上の橙皮书シリーズとして公開されています。
https://github.com/alchaincyf/loop-engineering-orange-book
一次情報としてAddy Osmani氏のブログ、Anthropicのエンジニアリング記事、Claude Code公式ドキュメントを参照してまとめられています。1周のループは、次の5つの動きで回ります。
| 動き | 役割 |
|---|---|
| Discovery（発見） | CIの失敗、未解決のissue、直近のコミットなどから、エージェント自身がやるべき仕事を探す |
| Handoff（引き渡し） | git worktreeなどで作業環境を分離し、並列エージェント同士の衝突を防ぐ |
| Verification（検証） | 成果物を客観的にチェックし、質の低い出力を弾く |
| Persistence（永続化） | 結果をディスク上のファイルに書き、コンテキストウィンドウが消えても状態を残す |
| Scheduling（スケジュール） | cronや/loopで次の周回を自動起動し、人間の手を離す |
X上で話題になった「Schedule → Discover → Build → Verify → Repeat」という表現は、マクロな循環として捉えると理解しやすいです。スケジュールで起動し、仕事を発見して実装し、検証してから繰り返す——この一連の流れが、ループ工学の中核です。
検証を分離するのが設計の要
5つの動きのうち、最も重要なのがVerificationです。コードを書いたエージェントに自分の成果を採点させると、自分の作業を褒めがちになる——これは複数の解説で繰り返し指摘されています（参考）。
対策はGenerator（生成）とEvaluator（評価）の分離です。実装担当のサブエージェントとは別に、レビュー専用のエージェントを立てます。評価側には「コードは壊れている前提で調べろ」という指示を与え、テスト実行やlint結果など機械的に判定できる根拠を使わせます。
Claude Codeの/goalコマンドも同じ思想です。各ターンのあと、別の小さなモデルが「完了条件を満たしたか」を判定し、満たすまでループを続けます。作業したモデル自身が「終わった」と宣言するのではなく、独立したチェッカーが止めどきを決めます。
ループを形にする6つの部品
Addy Osmani氏の整理では、ループを実装する部品は6つあります（参考）。
- Automations — 定期実行やイベント起動。Claude Codeでは
/loop、cron、hooks、GitHub Actionsが該当します。 - Worktrees — 並列作業の隔離。
git worktreeやサブエージェントのisolation: worktree設定で衝突を防ぎます。 - Skills —
SKILL.mdにプロジェクト知識を固定し、毎回ゼロから説明する手間を減らします。 - Connectors — MCP経由でissueトラッカーやDBなど外部ツールに接続します。
- Sub-agents — 探索・実装・検証を役割分担させます。
- Memory —
AGENTS.mdや進捗ファイルなど、会話外に状態を残す仕組みです。
Codexアプリも同型の部品を備えており、ツール選びより「ループの形」を先に設計する方が実務では効きます。
Claude Codeでの始め方
Claude Code公式ドキュメントでは、セッション内の繰り返しに/loop、完了条件付きの自律実行に/goalが案内されています。/loop 5m check the deployのように間隔とプロンプトを指定すれば、5分ごとにデプロイ状況を確認するループが動きます。間隔を省略すると、ビルド待ちなど状況に応じて1分〜1時間の待機をエージェントが選ぶモードになります。
Boris Cherny氏がよく挙げる入門例は、PRのCI失敗を5分おきに監視し、修正を提案するループです。検証コストが低い領域——テストやlintで機械的に正誤が分かる作業——から始めるのが定石です。
見落としやすい4つのコスト
ループは生産性を上げる一方で、次のコストが静かに積み上がります（参考）。
- 検証負債 — 無人で回すほど、検証の質が成果の上限を決めます。
- 理解の腐敗 — 自分が書いていないコードが増えると、システム全体の把握が遅れます。
- トークン爆発 — サブエージェントや反復実行は課金を一気に増やします。
- 認知的降伏 — 「ループが出したものをそのまま採用する」姿勢に陥ると、設計判断が放棄されます。
Addy Osmani氏は「ループを組む。だがエンジニアであり続けろ」と締めくくっています。同じループ設計でも、深く理解した上で使う人と、理解を避ける人では結果が正反対になる——この警告は導入前に頭に入れておく価値があります。
Anthropic公式の位置づけ
https://www.anthropic.com/engineering/building-effective-agents
Anthropicの「Building effective agents」では、エージェントはツール結果など環境からのフィードバックをループで受け取り、停止条件を設けるべきだと述べられています。Loop Engineeringは、この公式見解を「人間がプロンプトを打つ段階」から一段先へ押し出した実践論と読めます。複雑さは成果が証明されたときだけ足す——という原則は、ループ設計でもそのまま有効です。
プロンプトの巧拙で勝負する時代は終わりつつあります。次に問われるのは、何を自動で回し、何を人間が判断するかを設計できるかです。Loop Engineeringは、その設計図を11ページに凝縮した現場ガイドとして、エージェント開発の実務に直結するフレームワークです。