🔁 Loop Engineering入門：AIコーディングエージェントを動かすシステムを設計する

Loop engineering は、AI コーディングエージェントを手動で逐次プロンプトする代わりに、エージェントを自律的にプロンプト・オーケストレートするシステムを設計する実践方法論です。本記事は方法論として、構成要素・論理構造・データモデル・実装パターン・運用・限界を整理します。

調査日: 2026-06-10 / 対象リポジトリ: cobusgreyling/loop-engineering / 起点記事: Addy Osmani "Loop Engineering"（2026-06-07）

この記事の全体像。以下、順に解説します。

概要

Loop engineering は、設計対象を「個々のプロンプト」から「ループ（システム）」へ移行させる方法論です。エンジニアがエージェントへ毎ターン指示するのではなく、エージェントへ指示するシステムそのものを設計します。

ループとは、ゴール達成または人間へのハンドオフまで反復する制御単位です。AI がサブエージェント・検証・外部状態を組み合わせ、目的を満たすまで自律的に回します。

Boris Cherny（Anthropic の Claude Code 責任者、Head of Claude Code at Anthropic）はこの転換を次のように表現しています。

"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"

Peter Steinberger も同様に述べています。

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

この概念は Addy Osmani（Google のソフトウェアエンジニア、Google Cloud / Gemini を担当）が 2026 年 6 月 7 日の記事 "Loop Engineering" で体系化したことで広く普及しました。Cobus Greyling がその実践的なリファレンスリポジトリ（cobusgreyling/loop-engineering）を整備し、パターン集・チェックリスト・CLI ツールを提供しています。

なぜ今登場したか

AI エンジニアリングは以下の段階を経て進化してきました。

単一セッションで完結しない複雑なタスク（継続的インテグレーション監視、依存関係管理、PR レビュー等）では、逐次プロンプトは非効率です。ループ設計により、スケジューリング・状態管理・検証・エスカレーションを人間の介在なしに実行できます。

ReAct（Reason + Act、Yao らが 2022 年に提唱）が「一回のエージェント推論サイクル」を定義したのに対し、loop engineering はその外側にある「複数サイクルを束ねる制御システム全体の設計」を対象とします。系譜としては、ReAct が推論と行動のインターリーブを、SWE-agent / Devin 等が単一タスクの自律解決を扱ってきたのに対し、loop engineering は「複数の自律ループを協調・統治するメタ設計」に焦点を移した点が新しさです。

Prompt Engineering / Context Engineering との比較

これらの層は相互排他ではなく積み重なります。ループはプロンプトで構成されるため、ループ内のずさんなプロンプトはずさんな作業を速く生産するだけになります。

特徴

1. 再帰的ゴール（Recursive Goal）

ループはゴールを定義し、検証条件を満たすまでエージェントが自律的に反復します。単一ターンの完結ではなく、複数サイクルにわたる収束が前提です。

2. 自己プロンプト（Self-Prompting）

人間がプロンプトを入力するのではなく、システム（オートメーション）が何をいつプロンプトするかを決定します。これがループをエンジニアリングの対象にする本質です。

3. Maker-Checker 分離（Sub-agents）

実装エージェント（Maker）と検証エージェント（Checker）を分離します。実装者が自分の成果を採点する自己評価バイアスを構造的に排除します。

本記事では Maker = Implementer = 実装者、Checker = Verifier = 検証者として扱います。以降は原則「実装者 / 検証者」で統一し、CLI 例や引用部分のみ英語表記を残します。

4. 段階的自律（L1 → L2 → L3）

自律度の段階を Autonomy Tier（自律ティア）と呼びます。以降の見出し・表では「自律ティア」で統一します。

5. 外部状態管理（Memory / State）

エージェントはセッション間で記憶を持ちません。ループは Markdown ファイル・課題トラッカー・永続ストアに状態を書き出し、次のサイクルがその状態を読み込みます。

6. トークンコストの増大

高頻度・高自律ループはトークン消費を増大させます。PR Babysitter（常時監視）は Daily Triage（日次）に比べコストが大幅に高くなります。設計段階でコストと自律レベルのトレードオフを計画することが必要です。

7. Comprehension Debt（理解負債）

ループの生成速度がコードレビュー速度を上回ると、コードベースへの実際の理解が追いつかなくなります。自動化はジャッジメントを削除するのではなく、レバレッジポイントを移動させます。

構造

loop engineering の論理構造を C4 モデルの読み替えで記述します。各図はコンポーネント名と責務のみを示します。

システムコンテキスト図

アクターと loop engineering システム本体、外部システムの関係を示します。

アクター

外部システム

コンテナ図

ループを構成する主要プリミティブ（コンテナ）とその依存関係を示します。

コンポーネント図

ループの実行フロー（アナトミー）を構成するコンポーネントと制御の流れを示します。

自律度ごとのゲート構成図

Human Gate は自律度ティア（L1 / L2 / L3）によって構成が変わります。

Maker-Checker と Human Gate の構造的役割

Implementer と Verifier は同一エージェントにしません。Implementer が自身の成果物を検証すると自己採点になり、エラーを見逃す確率が高まります。Verifier を別エージェントに分離し、テスト実行・CI 結果確認・品質ゲートを独立した視点で適用します。この分離は無人実行時の品質保証の基盤になります。

Human Gate は変更の危険度を path allowlist と denylist の両方で判定します。L3 では allowlist 内かつ denylist 非該当の変更のみ Auto-commit / PR へ直進し、denylist 該当・allowlist 外・大規模リファクタ・新パターン追加は人間レビューキューへ転送されます。L1 では Gate 自体が存在せず全件を人間に回します。L2 では Gate はあるが自動マージを行いません。L3 では Gate が安全判定した変更のみ自動適用します。

データ

loop engineering が扱う概念をモデル化します。方法論のため明示的な ER 図はなく、登場する概念を一次ソースから抽出して構成します。

概念モデル

情報モデル

構築方法

前提条件

loop engineering を導入する前に、以下の環境を整備します。

概念的な前提は以下のとおりです。

• 外部状態ファイル（STATE.md など）の設計
• スキル（SKILL.md）によるプロジェクト規約の文書化
• maker / checker（実装者と検証者の分離）パターンの理解
• worktree 隔離による並列実行の理解

loop-audit によるレディネス評価

既存リポジトリに loop を導入する前に loop-audit でスコアリングします。

# リポジトリのレディネスをスコアリングする
npx @cobusgreyling/loop-audit /path/to/your/repo

# 改善提案付きで表示する（テンプレートからのコピーコマンドを提示）
npx @cobusgreyling/loop-audit /path/to/your/repo --suggest

# JSON 出力（CI 組み込み用）／ Markdown レポート出力
npx @cobusgreyling/loop-audit /path/to/your/repo --json > audit.json
npx @cobusgreyling/loop-audit /path/to/your/repo --md > audit.md

主なフラグは --json / --md / --suggest（--fix も同義）です。CLI の exit code はスコア 40 以上で 0、40 未満で 2、実行エラーで 1 を返します。

スコアと自律ティアの対応（tools/loop-audit/src/auditor.ts の computeScore を根拠とする 4 段階）は以下のとおりです。

loop-init による scaffolding

# daily-triage パターンを Grok で scaffolding する
npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok

# Claude Code を使う場合
npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude

# Codex を使う場合
npx @cobusgreyling/loop-init . --pattern daily-triage --tool codex

loop-init は以下のファイルを生成します（生成物は tools/loop-init/ を参照）。

• STATE.md — ループの状態ファイル（High Priority / Watch List セクション）
• トリアージスキル（エージェントランタイムに応じた配置）
• 検証者サブエージェント定義
• LOOP.md — ループ設計の正本

pattern-picker によるパターン選択

導入するループが決まらない場合は docs/pattern-picker.md の意思決定フローを使います。

迷ったときは Daily Triage の L1 から始めます。state discipline を学べ、auto-merge リスクがありません。

最初の L1 ループ立ち上げ

Daily Triage を例に、最小構成で立ち上げます。

# Step 1: State ファイルを作成する
printf '# Loop State\n\nLast run: never\n\n## High Priority\n\n## Watch List\n\n## Recent Noise (ignored this run)\n' > STATE.md

# Step 2: トリアージスキルを配置する（正規手順は loop-init。以下は手動配置の代替）
mkdir -p .claude/skills/loop-triage
cp templates/SKILL.md.loop-triage .claude/skills/loop-triage/SKILL.md

# Step 3: audit で L1 ゲートを確認する
npx @cobusgreyling/loop-audit . --suggest

スコアが L1 ゲートを満たせば L1 運用を開始できます。

利用方法

必須パラメータの整理

ループを起動する前に、以下のパラメータを確定します。

skill / starter の使い方

Claude Code では /loop コマンドでループを起動します。

L1 レポートのみ（Week 1）:

/loop 1d Run $loop-triage. Read STATE.md. Merge findings into High Priority and Watch List. Update Last run. Do not edit code.

L2 自動修正（Week 3 以降）:

/loop 1d Run $loop-triage. For high-priority items that are single-file bugfixes: spawn implementer in worktree, then verifier agent. Update STATE.md. Escalate ambiguous items.

CI Sweeper（15 分ごと）:

/loop 15m $ci-triage — update ci-sweeper-state.md. Classify failures first. Fix only clear regressions in a worktree with verifier. Max 3 attempts. Escalate infra and security test failures.

Dependency Sweeper（6 時間ごと）:

/loop 6h $dependency-triage — patch-only with verifier in worktree. Update dependency-sweeper-state.md. Escalate majors and high-severity CVEs.

PR Babysitter（5 分ごと）:

/loop 5m For each open PR I care about: triage CI and reviews. Propose minimal fixes in worktree. Verifier agent must approve before commenting. Update pr-babysitter-state.md. Max 3 attempts per PR.

Changelog Drafter（日次またはタグトリガー）:

/loop 1d Run $changelog-drafter. Read merged PRs since the last tag from git log. Draft a RELEASE_NOTES_DRAFT.md entry grouped by feat/fix/chore. Do not push. Update changelog-state.md.

単一の到達状態を一発で満たすワンショット実行には /goal を使います。

/goal PR #1234 has green CI, no blocking review comments, and is rebased on main

worktree 隔離の設定

自動修正を行う L2 以上のループでは、worktree 隔離が必須です。Claude Code では subagent のフロントマターに isolation: worktree を指定します（実装例。examples/claude-code/ を参照）。

---
isolation: worktree
---
You are an implementer. Work only in your isolated worktree.
After completing the fix, signal the verifier. Do not merge directly.

• isolation: worktree を subagent のフロントマターに指定する
• 1 アイテム = 1 worktree を原則とする
• verifier が REJECT した場合、または人間がエスカレーションした場合は worktree を破棄する

LOOP.md の worktree 運用ルールは以下のとおりです。

• unattended でのコード変更実験はすべて isolated git worktree で行う
• タスク完了または手動エスカレーション後に worktree を削除する

GitHub Actions による定期起動

GitHub Actions は、エージェントランタイムが常時起動していない環境でループを継続するために使います。以下は examples/github-actions/ をベースにした実装例です。エージェント起動ステップはプレースホルダー（ランタイムを差し込む設計）です。

# 実装例 — examples/github-actions/daily-triage.yml をベースに改変
name: Daily Triage Loop

on:
  schedule:
    - cron: '0 8 * * 1-5'
  workflow_dispatch:

permissions:
  contents: read
  issues: read
  pull-requests: read
  checks: read

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Gather CI context
        run: gh run list --limit 10 --json conclusion,name,headBranch,createdAt
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Ensure STATE.md exists
        run: |
          if [ ! -f STATE.md ]; then
            printf '# Loop State\n\nLast run: never\n\n## High Priority\n\n## Watch List\n' > STATE.md
          fi

      # ここをエージェントハーネスに置き換える（以下は実装案の 3 通り）
      # 案1: Codex CLI headless（GitHub Actions 上で直接実行）
      #   run: codex exec --skip-git-repo-check "Run loop-triage. Update STATE.md. Report only."
      # 案2: repository_dispatch で外部ランナー（常駐エージェント）を呼ぶ
      #   run: gh api repos/${{ github.repository }}/dispatches -f event_type=run-loop-triage
      # 案3: 自前スクリプトでエージェントを起動する
      #   run: ./scripts/run-loop.sh loop-triage --state STATE.md --report-only
      - name: Run triage agent
        run: |
          echo "Prompt: Run loop-triage skill. Update STATE.md. Report only unless L2 enabled."

      - name: Upload state artifact
        uses: actions/upload-artifact@v4
        with:
          name: loop-state
          path: STATE.md
          if-no-files-found: ignore

CI Sweeper はワークフロー失敗をトリガーに起動します。

# 実装例 — examples/github-actions/ci-sweeper.yml をベースに改変
name: CI Sweeper Loop

on:
  workflow_run:
    workflows: ['*']
    types: [completed]
    branches: [main]

permissions:
  contents: read
  pull-requests: write
  checks: read

jobs:
  sweep:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Record failure context
        run: |
          echo "Failed: ${{ github.event.workflow_run.name }}"
          echo "Branch: ${{ github.event.workflow_run.head_branch }}"

      - name: Invoke fix agent
        run: echo "Wire to agent: classify failure, worktree fix, verifier, open PR."

エージェントの起動方法は「Codex CLI / API（CI 内 headless 実行）」「repository_dispatch で外部ランナー（Grok / Claude）を呼ぶ」「カスタムスクリプト（ルールベースの triage のみ。L0 限定）」の 3 通りです（examples/github-actions/README.md より）。

maker / checker サブエージェントの構成

maker（実装者）と checker（検証者）を別のエージェントセッションで走らせることで、自己承認を防ぎます（実装例。examples/claude-code/ を参照）。

実装者エージェント:

---
isolation: worktree
---
You are an implementer sub-agent for loop-engineering.
Apply only the specific fix described in the task.
Do not self-merge. Signal the verifier when done.

検証者エージェント:

You are an adversarial reviewer.
Run the test suite, check the diff against CONVENTIONS.md,
and reject anything that is not verifiably done.
Use a fresh context — do not share memory with the implementer.
Report APPROVE or REJECT with reasons.

maker / checker の設計原則（docs/loop-design-checklist.md より）は以下のとおりです。

• 実装者は自分の成果物を承認できない
• 検証者は独立したテスト実行で確認する（実装者のセッションを再利用しない）
• 検証者には強力なモデルを使うことを推奨する
• stop condition の評価にも fresh model を使う

自律ティアを上げる手順（L1 → L2 → L3）

段階的ロールアウトが必須です。本番リポジトリで新パターンの L1 をスキップしません（docs/operating-loops.md より）。

L1 → L2 移行チェックリスト（docs/loop-design-checklist.md より）:

運用

稼働中ループの監視

稼働中ループの健全性は、以下の 4 軸で継続的に計測します。

各ループ実行時は、以下のフィールドをログに記録します（loop-run-log.md または JSON）。

run_id: 20260610-001
pattern: daily-triage
duration_sec: 42
findings: 3
actions: 1
escalations: 0
token_estimate: 18000
outcome: completed

週次ダッシュボードで追跡する集計指標は、実行完了数・自動修正提案数・人手エスカレーション数・false positive 率・平均検知時間（MTTA）・ループ別トークン消費量です。

トークンコストは二次関数的に拡大しがちです。naive に毎ステップ全会話履歴を再送し、各ステップの追加コンテキスト量が同程度と仮定すると、累積コストは概算で 1 ステップ分の N(N+1)/2 倍に近づきます（context reset・要約・prompt caching を入れると緩和されます）。この特性を踏まえ、コスト監視を必須とします。

STATE.md の週次レビュー

STATE.md はループの外部記憶（durable spine）として機能します。ループが停止しても状態は残りますが、放置するとクローズ済みチケットや解決済み PR への参照が蓄積し、state rot（状態腐敗）が発生します。

週次レビューの手順は以下のとおりです。

1. STATE.md の全アイテムをライブ API（GitHub / Linear）で実在確認する
2. クローズ済みアイテムを削除または done セクションへ移動する
3. 48 時間以内に 2 回以上エスカレーションされたアイテムを人手インボックスに移す
4. LOOP.md と照合し、各ループの cadence・停止条件が実態と一致しているか確認する
5. 週次サマリを loop-run-log.md に追記する

ループの停止と再開

状況に応じて 3 段階の対応を使い分けます。

停止基準は LOOP.md に明記します。

## 停止条件
- token_daily_budget: 2,000,000
- pause_at_budget_pct: 80
- kill_on_consecutive_s2_failures: 2
- kill_on_cost_inversion_weeks: 2

Autonomy Tier の昇降

ループのリスクレベルは L1 → L2 → L3 の 3 段階で管理します。昇格は慎重に、降格は即座に行います。

昇格の前提条件は累積的です（下位層の前提が引き継がれます）。

新しいパターンをプロダクションリポジトリに適用するときは、必ず L1 から開始します。L1 の検証なしに L2 以上を起動することは禁止します。

Multi-loop の協調

複数のループが同一リポジトリを操作する場合、以下の 5 原則を適用します。

1. ブランチ排他所有 — 1 ブランチにつき同時に操作できるループは 1 つのみとする
2. 状態ファイルの分離 — 各ループは専用の状態ファイルを持つ（例: state-triage.md / state-pr-watcher.md）
3. 役割の分離 — Triage ループは L1 でレポートのみ。Action ループは独立して実行し競合しない
4. 統一 denylist — 全ループが同一の path denylist を共有する
5. 予算の合算管理 — 全ループのトークン消費を合算して日次予算上限を管理する

衝突検出は、各 Action ループが実行前にピア状態ファイルの acting_on フィールドを確認して行います。

# ピア状態ファイルを確認して acting_on の重複を検出する
grep -h "acting_on:" state-*.md | sort | uniq -d

acting_on が重複している場合、後発のループが処理をスキップして run ログに記録します。優先順位は CI 失敗 → アクティブ PR → 依存関係アップデート → クリーンアップ → レポートの順です。推奨開始構成は Daily Triage / PR Babysitter / Post-Merge Cleanup の 3 ループです。

人手ゲートの運用

ゲートはループが止まって人間が判断する点であり、自律性と安全性のバランスを調整する主要な制御点です。ゲートを設ける状況の目安は以下のとおりです。

• medium-risk な変更（security / schema / public API の変更を含む）
• verifier が拒否理由ありと判定した変更
• 同一アイテムへの 2 回目以上のエスカレーション
• auto-merge が有効なパスへの変更

ゲートの通知先は Slack / Linear への Ping とし、状態ファイルの human_inbox セクションに待機アイテムを列挙します。ゲートの応答がない場合、ループは当該アイテムをスキップして次のサイクルに進みます（無限待機しません）。

ベストプラクティス

段階的ロールアウト（L1 → L2 → L3）

段階的導入の原則は「測定してから拡大する」です。

Week 1-2: L1 Report-only
  └─ triage 精度を計測（false positive 率 < 30% が目標）
Week 3-4: L2 Assisted
  └─ verifier 設置 + worktree 分離 + 小規模自動修正
Week 5+: L2+ Connectors
  └─ PR / チケット自動更新
Month 2+: L3 Unattended（条件達成後のみ）
  └─ denylist + 予算 + metrics + 人手ゲートがすべて確立済み

新しいパターンを既存ループに追加するときも、同じ L1 → L2 の順序を踏みます。既存ループが L3 であっても、新機能は L1 から開始します。

Maker-Checker（Verifier 必須）

単一エージェントによる自己検証は確証バイアス（confirmation bias）を生みます。コードを書いたエージェントと、それをレビューするエージェントは必ず分離します。

Verifier の設計原則は以下のとおりです。

• デフォルトの姿勢を「拒否」とする（承認ではなく拒否する理由を探す）
• プロンプトに CI テスト出力と lint 結果を含める
• モデルは実行エージェントより強力なもの、または別系統のものを使う

Verifier が承認しても CI が失敗する場合（Verifier Theater）は、verifier のプロンプトが曖昧か、テスト実行を省いていることが多いです。

停止条件を First-Class に設計する

ループを作るより先に、ループをどう止めるかを設計します。

# LOOP.md の停止条件セクション（テンプレート）

## 停止条件
### ループ: daily-triage
- slow_down: token_daily_pct > 80
- pause: release_freeze == true
- kill: consecutive_s2_failures >= 2 OR cost_inversion_weeks >= 2

## 人手インボックス
- escalation_channel: #eng-alerts
- notify_on: escalation, s2_failure, kill_trigger

停止条件なしに L3 を起動してはならない、を不変ルールとします。

Token 予算管理

トークンコストは無制限に拡大する性質を持つため、予算管理を設計に組み込みます。

• 日次上限を設定し、80% 到達で一時停止トリガーを用意する
• 安価なモデルで triage パスを実行し、処理すべきアイテムがある場合のみサブエージェントを起動する
• アイテムが空のウォッチリストに対しては早期終了する（コスト削減の最大の機会）
• 会話履歴のリセット（state reset）を phase 境界ごとに実施し、蓄積コストを抑える

コスト圧縮パターンの効果比較は以下のとおりです（一般的なエージェント設計の参考値であり、loop engineering 固有の計測値ではありません）。

Denylist / MCP スコープ制約

MCP コネクターは最小権限の原則に基づきます。

# MCP 設定例（実装案）
connectors:
  github:
    read: [repo, issues, pulls]
    write: [pull_request_comments]
    deny: [branch_protection, secrets, admin]

path_denylist:
  - "**/.env"
  - "**/credentials*"
  - "**/secrets*"
  - "**/migration/*.sql"
  - "**/infrastructure/**"

段階別の権限設定は以下のとおりです。

denylist は全ループで共有します。ループごとに個別 denylist を持つと、一部ループからの侵害が検知されなくなります。

Security（最小権限化）

無人自動化は攻撃対象領域を広げます。以下を必ず実施します。

• クレデンシャル・.env・シークレットファイルを denylist に含める
• シークレットがログに出力されないことを確認する
• allowlist 外のパスへの変更は人手レビューを必須とする
• 依存関係の初回更新は auto-merge しない（supply chain attack 対策）
• コネクターのトークンは短命・タスクスコープ型にする（長命な広権限トークンを避ける）

Comprehension Debt の管理

ループの速度が上がるほど、人間の理解が追いつかない Comprehension Debt（理解債務）が蓄積します。放置すると Cognitive Surrender（認知的降伏）に至り、チームがループの出力をそのまま受け入れる状態になります。

防止策は以下のとおりです。

• 週次ダイジェストを義務化し、auto-merge された変更を人間が定期的にレビューする
• medium-risk 以上の変更には人手ゲートを設ける
• 「ループが解決した」ではなく「チームがループを使って解決した」という姿勢を維持する
• 成功指標を処理量ではなく品質に紐付ける

Cognitive Surrender に陥っていないかは、以下の判定基準で確認します。

• 週次レビューで auto-merge された変更を 1 件ずつ自分の言葉で要約できるか
• 変更の意図と根拠を、ループの出力に頼らず説明できるか
• ループが承認した変更に後追いの Revert が 2 週連続で発生していないか（発生したら当該ループを L2 へ降格する）

トラブルシューティング

頻出 Failure Mode 一覧

Context Rot（コンテキスト腐敗）

会話履歴が蓄積されるにつれモデルの実効性能が低下し、ループの後半ターンで提案の品質が低下します。phase 境界（triage → fix → verify の切り替え時）でコンテキストをリセットし、外部ファイル（STATE.md / git）に状態を引き渡します。10-15 ツール呼び出しごとに文脈トリミングを実施し、スペシャリストにはタスクスコープの文脈のみ渡します。

トークン爆発（Token Explosion）

1 ステップごとに全会話履歴を再送する naive ループ、または空のウォッチリストへの継続処理が原因でコストが急増します。token-per-task を監視して 2 倍超でアラートを発火し、「アイテムなし → 即時終了」パスを実装します。安価なモデルで triage パスを通し、アクションが必要な場合のみ強力なモデルを起動します。

無限ループ（Infinite Loop）

attempt cap の未設定、または verifier の誤承認が自動修正を再トリガーすることで、同一アイテムへのリトライが収束しません。attempt cap を 3 に設定して上限到達時は人手インボックスにエスカレーションし、ループ cadence をサブ分単位にせず数分以上に設定します。kill switch を LOOP.md に明記します。

Verifier すり抜け

Verifier プロンプトの曖昧さやテスト実行の省略、path denylist の未設定により、承認された変更が CI で失敗します。Verifier プロンプトを「拒否する理由を探す」フレーミングに変更し、CI テスト出力と lint 結果を必須入力にします。auto-merge を path allowlist 限定にし、allowlist 外は人手レビュー必須にします。

競合する Multi-loop

worktree 分離なし、acting_on フィールド未確認により、マージコンフリクトや状態ファイル破損が発生します。全 Action ループで isolation: worktree を設定し、実行前に全ピアの acting_on を確認して重複時はスキップします。状態ファイルをループごとに分離します。

コスト暴走

予算上限の未設定、サブ分 cadence、triage パスなしによりトークン予算を大幅超過します。日次上限を設定して 80% 到達で自動一時停止し、triage パス（安価なモデル）→ action パス（強力なモデル）の 2 段構造にします。「アイテムなし → 即時終了」を実装し、cadence を 5-10 分以上に設定します。observability プラットフォームでリアルタイム監視します。

限界と適用条件

loop engineering は強力な方法論ですが、以下の点を過信しません。

• 無人ループは無人ミスも生む。自動化はスループットを上げるが、判断の品質は保証しない
• ループは良い判断も悪い判断も増幅する。verifier が弱ければ、速度が上がるほど被害が広がる
• Verification は人間の責任。ループが承認したことは、人間が確認した代替にならない
• Comprehension Debt は静かに蓄積する。ループを高速化するほど、積極的な読書と週次レビューが必要になる
• コストは予測通りにいかない。token 消費の二次関数的性質を前提に予算設計する
• L3 は目標ではなく、条件が揃ったときの選択肢。多くのパターンは L2 で十分な価値を生む

まとめ

Loop engineering は、AI コーディングエージェントを「手で動かす」段階から「動かすシステムを設計する」段階へ引き上げる方法論です。6 つのプリミティブと L1 → L3 の段階的自律、実装者・検証者の分離、停止条件の先行設計を押さえれば、暴走やコスト爆発を避けながら自動化のレバレッジを効かせられます。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

関連記事

• AI Harness Engineering入門 — loop を回す実行層そのものを、責務と証跡の契約として定義する
• Context Engineering入門 — loop の各ターンでエージェントに何を渡すかを設計する
• プロンプトエンジニアリングの進化 — 各ターンの 1 回の model 呼び出しに与える指示を設計する

参考リンク

• 公式リポジトリ（cobusgreyling/loop-engineering）
  • GitHub - cobusgreyling/loop-engineering
  • README.md
  • LOOP.md
  • AGENTS.md
  • STATE.md
  • SECURITY.md
• 概念・系譜
  • Loop Engineering - Addy Osmani
  • Loop Engineering - Addy Osmani (Substack)
  • Loop Engineering - Cobus Greyling (Medium)
  • docs/concepts.md
  • docs/primitives-matrix.md
  • ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al. 2022)
  • AI Coding Just Evolved Again - Princeton AI Newsletter
• 実装・パターン・examples
  • docs/pattern-picker.md
  • docs/loop-design-checklist.md
  • docs/operating-loops.md
  • examples/claude-code/daily-triage.md
  • examples/github-actions/README.md
  • .github/workflows/audit.yml
  • .github/workflows/daily-triage.yml
• 反証・運用・失敗モード・セキュリティ
  • docs/anti-patterns.md
  • docs/failure-modes.md
  • docs/multi-loop.md
  • AI Agent Loop Token Costs - Augment Code
  • Agentic AI Cost Runaway and Token Budget 2026 - LeanOps
  • Least Privilege Access for AI Agents - Security Boulevard
• 解説記事
  • Loop Engineering: AI Coding Agents Guide - LushBinary
  • What is Loop Engineering? - MindStudio
  • Loop Engineering Concepts - LoomStack
  • Context Engineering: Agent Reliability Playbook 2026 - Digital Applied