Loop Engineeringとは？AIエージェントを「設計」する時代へ

はじめに

2026年6月、AI開発の現場に一つの言葉が広まった。Loop Engineering（ループエンジニアリング）。

Anthropic で Claude Code の責任者を務める Boris Cherny（Head of Claude Code）は、あるインタビューでこう語った。

「私はもう Claude にプロンプトを打たない。Claude にプロンプトを送るループが動いていて、次に何をするかを判断している。私の仕事はループを書くことだ。」

この言葉は、元Google AI担当ディレクターの Addy Osmani が自身のブログ "Loop Engineering" で紹介し、広く知られるようになった。Osmani は PSPDFKit 共同創業者（当時 OpenAI エンジニア）の Peter Steinberger の言葉も同記事で引用している。

「エージェントにプロンプトを送るのをやめて、エージェントにプロンプトを送るループを設計すべきだ。」— Peter Steinberger

こうして "Loop Engineering" という概念が業界全体に波及した。本記事では、Loop Engineering の本質・構造・設計パターン、そして Claude Code と Codex での実践的な実装例を解説する。

---

Loop Engineering とは何か？

定義

Loop Engineering とは、AI エージェントに手動でプロンプトを送ることをやめ、エージェントにプロンプトを送り続けるシステムそのものを設計・構築する手法だ。

従来のAI活用は「1プロンプト → 1レスポンス」という一問一答モデルだった。Loop Engineering はそれを超え、エージェントがトリガー → アクション → 検証 → 再試行のサイクルを自律的に繰り返すシステムを設計することを指す。

従来の「プロンプトエンジニアリング」との違い

観点	プロンプトエンジニアリング	Loop Engineering
焦点	1回のプロンプトの質	システム全体の設計
実行	手動でプロンプトを送る	ループが自動で送る
検証	人間が目視確認	自動検証器が判定
失敗時	人間が再試行	サーキットブレーカーが制御
スケール	1人の注意力に依存	複数ループを並列実行
コスト管理	実行するたびに手動確認	停止ルールで自動制御

誕生の背景

2026年初頭、AIモデルの能力が急速に向上し、プロンプトの文章力よりもシステム設計の品質がボトルネックになった。個々のプロンプトをいくら磨いても、エージェントは一度しか動かない。複数回の試行・検証・修正のサイクルを設計することの方が、何倍もの価値を生み出すと認識され始めた。

---

ループの解剖学：4つの構成要素

Loop Engineering では、すべてのループを以下の4要素で設計する。

1. Trigger（トリガー）

ループを起動するきっかけ。3種類ある。

種別	例
イベント駆動	PRがオープン、CIが失敗、issueが割り当て
スケジュール	毎15分、毎朝、毎週金曜
手動指示	claude コマンドによるワンタイム起動

2. Topology（トポロジー）

ループ内のエージェント構成。どのエージェントが何を担当するか。

3. Verifier（検証器）

エージェントの成果物がゴール条件を満たしているか確認するコンポーネント。

• テストが全件グリーンか
• Lintエラーがゼロか
• 型チェックが通るか
• コードレビュールールに準拠しているか

検証器はエージェントとは独立した別のモデル・スクリプトが担当するのが原則。また、検証は「エージェントの自己申告」ではなく、外部から実行される決定論的なチェック（テストランナー・静的解析ツール等）で行うこと。LLM が自分の出力を評価する自己参照的な検証は、同じ誤りを再現する傾向がある。

4. Stop Rules（停止ルール）

ループをいつ止めるかを定義するルール。必ず明示的に設計する。

✅ 成功停止: CI グリーン + Lint クリーン + 型チェック通過
❌ 失敗停止: 連続 3 回失敗でサーキットブレーカー発動
⏰ タイムアウト停止: 30 分経過で自動中断

重要: 停止ルールは「エージェントが完了したと申告したとき」ではなく、外部から検証可能な条件（テスト通過・ファイルハッシュ一致・HTTP ステータスコード等）で定義すること。

---

設計パターン

Pattern 1: シンプルループ（最初に試すべきパターン）

最もシンプルな構成。単一エージェントが検証結果を受けて再試行する。

Pattern 2: Maker + Checker（最も費用対効果が高いパターン）

「書く役割」と「チェックする役割」を分離する。

Checker に軽量モデルを使うことでコストを抑えられるが、Checker の能力不足は誤検証（false positive）を引き起こす。検証タスクの複雑度に応じてモデルを選択すること。単純な Lint チェックや構文検証であれば軽量モデルで十分だが、コードの意味的な正しさを判定する場合は Maker と同等以上の能力が必要になる。

役割	推奨モデル	適用条件
Maker	高性能モデル（Opus等）	複雑な実装・設計
Checker	軽量モデル（Haiku等）	構文検証・Lint・機械的チェック
Checker	高性能モデル（Sonnet以上）	コードの意味的正しさの判定

Pattern 3: サーキットブレーカー（必須の安全装置）

連続失敗時に自動停止するパターン。これなしでループを本番に投入してはいけない。

注意: MAX_CONSECUTIVE_FAILURES=3 はあくまでサンプル値。タスクの性質（冪等性・コスト単価・外部APIの副作用）に応じて調整すること。AWS リソースを操作するループでは 3 回の失敗で数万円の請求が発生しうる。

---

Claude Code での実践

/loop コマンド：スケジュール駆動ループ

Claude Code の /loop コマンドを使うと、スラッシュコマンドを定期実行できる。

# PR の CI 状態を 5 分ごとに確認して自動修正するループ
/loop 5m /babysit-prs

内部的には ScheduleWakeup を使ってループが自己ペーシングする（※ 内部実装の仕組みであり、公開 API ではない）。

// ScheduleWakeup の動作イメージ（Claude Code 内部の仕組み）
// ループ継続中は 270s（プロンプトキャッシュウィンドウ内 = 約90%割引）
// アイドル時は 1200s（コスト最小化、キャッシュミスを許容）
ScheduleWakeup({
  delaySeconds: 270,
  reason: "CI結果をポーリング中",
  prompt: "<<autonomous-loop-dynamic>>"
})

Stop Hook：終了前の検証

Stop Hook は Claude が作業を終了しようとした瞬間に割り込み、本当に完了条件を満たしているか確認する。

// .claude/settings.json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "bash scripts/verify-completion.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# scripts/verify-completion.sh
# ⚠️ exit 2 はエージェントに作業継続を指示する。
#    必ず MAX_ITERATIONS などのループ上限と組み合わせること。
#    上限なしで exit 2 を返し続けると無限ループになる。

npm test 2>/tmp/test.log
TEST_RESULT=$?

npm run lint 2>/tmp/lint.log
LINT_RESULT=$?

if [ $TEST_RESULT -ne 0 ] || [ $LINT_RESULT -ne 0 ]; then
  # 失敗内容を stderr に出力（デバッグのために必ずログを残す）
  cat /tmp/test.log >&2
  cat /tmp/lint.log >&2
  exit 2  # Claude に作業を続けさせる（停止を拒否）
fi

exit 0  # 完了を承認

実践例：PR 自動ケアループ

⚠️ セキュリティ上の注意: 以下のループは AI が自律的にコードを編集・commit・push する。必ず以下を守ること。

• Branch Protection Rules（必須レビュー・CI 通過要件）を設定する
• AI による自動マージは行わせない
• ループの上限回数・コスト上限を設定する

# ルーティン作成（Claude Code CCR）
# ⚠️ prompt に「commit・push は行わないこと」等の制約を明示すること
mcp__claude_ai_Claude_Code_Remote__create_trigger \
  --name "PR babysitter" \
  --cron_expression "*/15 * * * *" \
  --prompt "オープンPRのCIを確認し、失敗があれば原因を分析してコードを修正してください。ただし git commit / git push は行わず、編集内容を提示するのみとしてください。連続3回失敗したら中断してコメントを残してください。"

実践例：週次スキルメンテナンスループ

---

Codex での実践

/goal コマンド：セッションをまたぐ耐久目標

Codex CLI v0.128.0（2026年4月30日）で追加された /goal コマンドは、セッションが切れても消えない耐久的なゴールを設定する。

# 今週中に認証モジュールの型エラーをすべて解消するゴールを設定
codex /goal "src/auth/ 以下の TypeScript 型エラーをすべて解消し、テストカバレッジを 80% 以上にすること。期限: 今週末"

ゴールは Codex のメモリに永続化され、次回セッション開始時も引き継がれる。

Automations：スケジュール駆動の自動化

# .codex/automations.toml
# ※ フィールド名は公式ドキュメントで要確認（バージョンにより異なる場合あり）
[[automation]]
name = "daily-pr-review"
schedule = "0 9 * * 1-5"  # 平日毎朝 9 時
prompt = """
昨日からのオープン PR を確認してください。
1. コードスタイル違反を検出してコメント
2. セキュリティ上のリスクがあれば警告
3. テストが欠けているPRにラベルを追加
マージは行わないこと。
"""
max_iterations = 5

[[automation]]
name = "flaky-test-detector"
schedule = "*/30 * * * *"  # 30 分ごと
prompt = """
過去30分のCI結果を確認し、フレイキーテストを検出してください。
同じテストが3回以上ランダムに失敗している場合は issue を作成。
"""

Stop Hook in Codex：完了基準を強制

# .codex/hooks/stop_hook.py
# ⚠️ exit 2 はエージェントに継続を指示する。
#    ループ上限（max_iterations等）と必ず組み合わせること。
import subprocess
import sys

def check_completion():
    """テスト・型チェック・Lint の全通過を検証する"""
    checks = [
        (["npm", "test", "--", "--passWithNoTests"], "テスト"),
        (["npx", "tsc", "--noEmit"], "型チェック"),
        (["npm", "run", "lint"], "Lint"),
    ]

    failures = []
    for cmd, name in checks:
        # ⚠️ shell=False + リスト渡しを徹底（引数インジェクション対策）
        result = subprocess.run(cmd, capture_output=True, text=True, shell=False)
        if result.returncode != 0:
            failures.append(name)
            print(result.stderr, file=sys.stderr)  # ログを必ず残す

    if failures:
        print(f"完了条件未達: {', '.join(failures)} が失敗", file=sys.stderr)
        sys.exit(2)  # エージェントに継続を指示

    sys.exit(0)  # 完了を承認

if __name__ == "__main__":
    check_completion()

Worktrees による並列ループの分離

複数のループを同時実行する際は、git worktree で作業領域を分離することでワーキングツリー レベルの競合を防ぐ。なお、.git オブジェクト層（config・hooks・LFS オブジェクト）の競合は worktree では防げないため、別途制御が必要な点に注意する。

---

Loop Engineering のベストプラクティス

1. シンプルなループから始める

最もシンプルなループで始め、改善を測定できたときだけ複雑さを追加する。

まず「シングルエージェント → 検証 → 再試行」のループを作る。Maker + Checker の分離は、シングルループで測定可能な問題が生じてから導入する。

2. サーキットブレーカーは全ループ必須

サーキットブレーカーなしのループは本番環境に投入しない。黙ってループし続けるとコストが青天井になる。

MAX_CONSECUTIVE_FAILURES=3  # タスクの性質に応じて調整（副作用が大きい場合は1〜2に）

Anthropic の Claude Code 自身のコードベースには、20か所以上のサーキットブレーカー定数がある（MAX_CONSECUTIVE_FAILURES = 3〜5）。

3. コストを見積もってから実行する

ループを本番投入する前に、最悪ケースのコスト上限を試算する。

最大コスト = 1反復あたりのトークン消費 × MAX_ITERATIONS × モデル単価

例（Opus 4.8 を Maker に使う場合）:
  1反復 ≈ 5,000 input + 2,000 output トークン
  MAX_ITERATIONS = 10
  → 最大 $0.75〜$1.50 程度

cron頻度の影響:
  */15 分 × 24時間 = 96回/日
  1回あたり10反復なら → 最大 960反復/日

また、15分ごとの cron を設定する前に、まず 1時間ごとでテストし、コストと効果を測定してから頻度を上げること。

4. メモリを永続化する

ループ間で情報を引き継ぐ永続メモリを設計する。Markdown ファイルはシンプルで有効だが、複数エージェントが並列で書き込む場合の競合制御が必要になる点に注意する。

memory/
├── loop-state.md        ← ループの現在状態
├── failed-attempts.md   ← 失敗ログ（再試行時の参考）
└── completed-tasks.md   ← 完了タスクの記録

5. 観測可能性（Observability）を設計に組み込む

ループが正常動作しているか監視できる仕組みを最初から入れる。

---

まとめ

Loop Engineering は「AIに何を指示するか」から「AIが自律的に動く仕組みをどう設計するか」へのパラダイムシフトだ。

3つのポイント

1. 設計する — トリガー・トポロジー・検証器・停止ルールの4要素でループを設計する
2. 検証する — 人間の代わりに自動検証器がゴール達成を判断する（外部から検証可能な条件で定義すること）
3. 止める — サーキットブレーカーで暴走を防ぎ、コストを制御する

Claude Code の /loop・Stop Hook・ScheduleWakeup、Codex の /goal・Automations・Worktrees は、どれもこの考え方を具体的なツールとして実装したものだ。

「プロンプトを磨く時代は終わった。ループを設計する時代が来た。」— Addy Osmani, 2026

---

参考文献・出典

• Loop Engineering — Addy Osmani (addyosmani.com)
• Loop Engineering: A Guide for Engineers and Practitioners — Adnan Masood, PhD. (Medium)
• The Anthropic leader who built Claude Code says he ditched prompting (The New Stack)
• From Prompts to Loops: A Practical Guide (Medium)
• Agentic Loops: From ReAct to Loop Engineering (Data Science Dojo)
• Claude Code Hooks reference (code.claude.com)
• How to Build an Agentic Loop with Claude Code (MindStudio)