Loop Engineering とは
AI エージェントが 観測 → 計画 → 実行 → 検証 → 修正 → 繰り返し のサイクルを自律的に回します。開発者は ループ全体の設計とゴール設定 を行い、最終的な安全確認は必ず人間が行う前提で運用します。
Loop Engineering の全体像
1. 解決したい課題
従来の開発フローは人間がプロンプトを書き、AI がコードを生成し、再度人間が結果を確認してプロンプトを修正する、というターン制です。このサイクルを繰り返すとプロンプト作成に時間が取られ、タスクが大きくなるほど非効率になります。
Loop Engineering は 観測 → 計画 → 実行 → 検証 → 修正 → 繰り返し のループ全体を自律的に回すことで、開発者は ループ設計とゴール設定 に集中できるようにします。
2. 背景と主要人物
- 2026 年 6 月、Google の Addy Osmani が「Loop Engineering」という名称で概念を整理し、ブログで公開しました。
- 同時期に Anthropic の Claude Code 責任者 Boris Cherny と、OpenClaw の作者 Peter Steinberger が「直接プロンプトを書かず、ループがプロンプトを出す」実践例を語り、概念の拡散に貢献しました。
- これら 3 名の発言がきっかけとなり、AI エージェントを自走させる設計手法として業界に浸透し始めました。
3. 基本構成要素（6 つの部品）
各部品はループ全体のどのフェーズで主に活躍するかを意識して選択します。
自動化
観測 フェーズの開始やタスクのトリアージを定期的にジョブで起動し、手作業を排除します。作業ツリー
git worktreeなどで作業領域を分離し、実行 フェーズで複数エージェントが同時に書き換える際の衝突を防ぎます。スキル
プロジェクト固有のビルド手順や禁止事項をSKILL.mdに記載し、エージェントが参照できるようにします。SKILL.mdは一般的に推奨されるファイル名で、外部ツールに依存しない「スキル情報の外部共有」手法として広く利用されています。接続プラグイン
モデルコンテキストプロトコルを介して GitHub、Linear、Slack など外部ツールと連携し、実行 後の PR 作成やタスクステータス更新、通知を自動化します。サブエージェント
実装担当エージェントと検証担当エージェントを分離し、検証 フェーズで自己評価バイアスを排除します。状態・記憶
STATE.mdや課題ボードに「完了した作業」や「次にやること」を永続化し、セッションが終了しても再開できるようにします。STATE.mdも同様に一般的に推奨されるファイル名で、ツール非依存の「状態永続化」手法として利用されています。
用語解説
- サブエージェント：実装と検証をそれぞれ担当する AI エージェント。
- 自動外部監査プロセス：事前に人間が定義した禁止リストや自動評価ロジックに基づき、無人モードでも安全性をチェックする仕組み。
4. ループの基本フロー
flowchart TD
A[観測] --> B[計画]
B --> C[実行]
C --> D[検証]
D -->|成功| E[収束判定]
D -->|失敗| F[修正]
F --> C
E -->|継続| A
観測
CI の失敗や未処理課題を取得します。計画
取得情報をもとにタスクを分解し、ゴールと検証条件を設定します。実行
作業ツリーを作成し、実装サブエージェントがコードを書き、検証サブエージェントがテスト・Lint で評価します。検証
テストがすべて通過すれば成功とし、失敗した場合は 修正案を生成 します。修正
生成された修正案を実装サブエージェントがコードに反映し、再度 実行 に戻ります。収束判定（停止条件）
- ゴール：全テスト合格＋開発者が設定した非機能要件がすべて満たされた状態。
- 例外停止：リソース上限到達、連続失敗 3 回以上、設定したイテレーション数・トークン予算の上限、外部 API のタイムアウトやデッドロック検知など。
5. 実装例：日次トリアージループ
自動化
毎朝 9 時にスケジュールジョブが起動し、トリアージを開始します。タスク取得
CI の失敗や新規課題を API で取得し、観測フェーズを完了します。作業ツリー作成
git worktree addで隔離ブランチを生成し、計画フェーズの準備を整えます。実装サブエージェント
Claude がコード修正案を生成し、作業ツリーに書き込みます。検証サブエージェント
CodeRabbit が自動レビューとテスト実行を行い、合格すれば次へ、失敗すれば修正案生成へ進みます。接続プラグイン
PR が作成されたら GitHub にマージ依頼を送信し、Linear のタスクステータスを「完了」に更新、Slack に結果を通知します。状態永続化
STATE.mdに「実行日時」「処理件数」「次回開始ポイント」を追記し、次回はこの情報から再開します。
この流れは 1 つのスケジュールジョブと状態ファイルだけで完結 し、手動でプロンプトを書く手間が大幅に削減されます。
6. 自律度の段階と人間介在の位置付け
L1（報告）
エージェントが結果をレポートし、最終判断は人間が行う。L2（支援）
エージェントが修正案を提示し、人間が承認する。L3（無人）
事前に定義した禁止リストと 自動外部監査プロセス が走るモード。
実務ではまず L1 の「報告」だけのループ を構築し、段階的に L2、L3 と拡張します。L3 でも 最低限のガードレール（禁止リストと自動外部監査プロセス）は必ず残すことが推奨されます。
7. 注意点とベストプラクティス
停止条件の設計
- ゴール：全テスト合格＋開発者が設定した非機能要件。
- 例外停止：リソース上限、連続失敗 3 回以上、イテレーション数・トークン予算の上限、外部 API のタイムアウトやデッドロック検知など。
これらは設定ファイルで明示し、ループ実行時に自動でチェックされます。
検証の自動化
生成モデルだけに評価を任せず、別モデルや別ロジックでテスト・Lint を実行させ、バイアスを排除します。
トークンコストの管理
ループは通常のチャットに比べて数倍のトークンを消費します。loop‑cost コマンドで事前に見積もり、上限を設定すればコスト増大のリスクを抑制できます。
理解負債への対策（独立見出し）
- 概要レビューの実施：各イテレーションの終わりに人間が AI に要約を書かせ、差分だけを確認します。
- 重要変更の人間介入：設計変更や依存関係の追加は必ず人間がレビューします。
- エスカレーション：連続失敗が一定回数を超えたら即座に人間に通知し、全体の流れを見直します。
ガードレールの設置
- 許可リスト／禁止リスト：危険な操作は人間の承認が必要です。
- エスカレーション：ループが失敗し続けたら自動で人間に通知します。
外部メモリの活用
AI はセッションを跨いで記憶しないため、ディスク上の Markdown や課題ボードに状態を書き出すことで、次回セッションでも前回の続きが再現できます。
8. 最初の一歩：シンプルな CI 失敗分析ループ
- CI が失敗したら Slack に通知するジョブを作成。
- 通知をトリガーにして、AI エージェントに失敗原因の分析と簡易修正案の提示を依頼。
- エージェントのレポートを人間が確認し、必要なら手動で PR を作成。
このミニマルなループだけでも、プロンプト作成の手間が削減され、Loop Engineering の感覚を掴むことができます。
ツールとリソース
cobusgreyling/loop‑engineering リポジトリ が提供する CLI
loop‑init：テンプレート（手順書・状態ファイル）を生成loop‑audit：ループの実行可能性をスコア化loop‑cost：トークン消費量を見積もりloop‑sync：定義と実態の乖離を検知
詳細はリポジトリの README をご参照ください。
AI プラットフォームの組み込みコマンド
- Claude Code の
/loop、/goal、/schedule - OpenAI Codex の
/goal、/schedule
- Claude Code の
※ これらのコマンドは執筆時点の最新仕様に基づいています。実際に利用する際は、各ツールのリリースノートや公式ドキュメントで最新情報を確認してください。
まとめ
- Loop Engineering は「人がプロンプトを書く」から「システムがプロンプトを出す」への転換点です。
- 必要な部品は 自動化・作業ツリー・スキル・接続プラグイン・サブエージェント・状態管理 の 6 つです。
- ループは 観測 → 計画 → 実行 → 検証 → 修正 → 繰り返し のサイクルで、ゴール（全テスト合格＋開発者が設定した要件） と 例外停止条件 を明確に設定することが不可欠です。
- 自律度は L1 → L2 → L3 と段階的に導入し、まずは報告だけのシンプルなループから始めると安全です。
- トークンコスト、理解負債、検証の自動化は導入時の最大リスクです。適切に設計すれば、開発者は ループの設計・監視 にシフトし、実装作業から解放されます。
Loop Engineering を自分のプロジェクトに取り入れ、AI コーディングエージェントを自走させる開発ラインを構築してみてください。
