はじめに
本記事は「2026年4月 AIエージェント開発の最前線」シリーズの一部として執筆している。シリーズ全体の概観はこちらの記事を参照してほしい。
入門編では ECC の全体像を、アーキテクチャ編では五層構造の設計思想とクロスハーネスアダプタを、フック実践ガイドではフックの全容と run-with-flags.js の実行モデルを、先進機能編では Instinct 学習・AgentShield・Eval-Driven Development を扱った。
本記事はシリーズ第5弾として、ECC が体系化した自律エージェントループのパターンと、次世代コントロールプレーン ECC 2.0 Alpha を取り上げる。
-
自律ループの6パターン — 単純な
claude -pパイプラインから RFC 駆動 DAG オーケストレーションまでのスペクトラム - ECC 2.0 Alpha — Rust 製コントロールプレーンによるセッション管理・リスクスコアリング・TUI ダッシュボード
なお、本記事はこれまでのシリーズ記事を読んでいることを前提とする。ECC のインストール方法や基本概念は入門編を参照してほしい。
注記: 本記事の情報は2026年4月時点（v1.10.0 HEAD、コミット 125d5e6）のものであり、各リポジトリの機能・数値は変動する可能性がある。最新の情報は各リポジトリの README を参照してほしい。
自律ループの6パターン — スペクトラムで理解する
skills/autonomous-loops が定義する6パターン
ECC の skills/autonomous-loops/SKILL.md は、単純なパイプラインから高度な DAG オーケストレーションまでを6つのパターンとして体系化している。
注記: v1.8.0 から
autonomous-loopsスキルの正規名はcontinuous-agent-loopに変更されている。autonomous-loopsは後方互換のため1リリース維持される。
| パターン | 複雑度 | 最適な用途 |
|---|---|---|
| Sequential Pipeline | 低 | 定型化された日常ワークフロー |
| NanoClaw REPL | 低 | インタラクティブな永続セッション |
| Infinite Agentic Loop | 中 | 仕様駆動の並列コンテンツ生成 |
| Continuous Claude PR Loop | 中 | CI ゲート付きの複数日プロジェクト |
| De-Sloppify Add-On | —※ | 実装ステップ後のクリーンアップパス |
| Ralphinho RFC-Driven DAG | 高 | 大規模機能の並列ワーク + マージキュー |
※ De-Sloppify は独立パターンではなく他パターンへのアドオンのため、複雑度は非該当。
パターン1: Sequential Pipeline
最もシンプルなパターン。claude -p で非インタラクティブに呼び出し、各ステップを set -e でつないだシェルスクリプトとして記述する。
#!/bin/bash
# daily-dev.sh — Sequential Pipeline の例
set -e
# Step 1: 実装（TDD）
claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD)."
# Step 2: De-sloppify（クリーンアップ）
claude -p "Review all files changed by the previous commit. Remove unnecessary type tests and overly defensive checks. Keep real business logic tests. Run the test suite after cleanup."
# Step 3: 検証
claude -p "Run the full build, lint, type check, and test suite. Fix any failures."
各 claude -p 呼び出しはコンテキストが独立している（フレッシュウィンドウ）。ステップ間の文脈はファイルシステムの状態で受け渡す設計だ。
パターン2: NanoClaw REPL
scripts/claw.js で実装された ECC 組み込みの永続セッション。会話履歴を ~/.claude/claw/{session}.md に Markdown として蓄積し、セッションをまたいでコンテキストが維持される。
# デフォルトセッション起動
node scripts/claw.js
# セッション名とスキルコンテキスト指定
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
Sequential Pipeline とは用途が異なる。探索的な対話や、前のセッションの文脈を引き継いだ継続作業向けだ。
パターン3: Infinite Agentic Loop
仕様ファイル（Markdown）を読み込み、オーケストレーターが N 個のサブエージェントを並列デプロイする2プロンプトシステム（@disler に帰属）。
オーケストレーターは各エージェントに「ユニークなクリエイティブ方向性」と「固有のイテレーション番号」を割り当てる。エージェント自身に自己分化を期待せず、オーケストレーターが割り当てることで並列エージェント間の重複を防ぐ設計だ。
# 5バリエーションを並列生成
/project:infinite specs/component-spec.md src/ 5
# 無限モード（コンテキスト消費まで継続）
/project:infinite specs/component-spec.md src/ infinite
パターン4: Continuous Claude PR Loop
CI ゲート付きで PR → CI 待機 → マージを繰り返すシェルスクリプト（@AnandChowdhary に帰属）。
Create branch → claude -p 実装 → コミット → PR 作成 → CI 待機
→ CI 失敗 → auto-fix パス → 再 push → CI 待機 → マージ → 繰り返し
SHARED_TASK_NOTES.md でイテレーション間の文脈を橋渡しするのが重要な設計ポイントだ。各 claude -p 呼び出しはフレッシュだが、前のイテレーションの進捗を Markdown ファイルに書き残すことで文脈が維持される。
# 10イテレーション、最大$5コスト制限
continuous-claude --prompt "Fix all linter errors" --max-runs 10 --max-cost 5.00
# コードレビューパス付き
continuous-claude \
--prompt "Add authentication feature" \
--max-runs 10 \
--review-prompt "Run npm test && npm run lint, fix any failures"
パターン5: De-Sloppify — 専念エージェントの哲学
De-Sloppify は単体のパターンではなく、任意のループに追加するクリーンアップパスだ。
ECC ドキュメントに記された設計哲学がある。
"Rather than adding negative instructions which have downstream quality effects, add a separate de-sloppify pass. Two focused agents outperform one constrained agent."
LLM に「型システムのテストを書くな」と制約を加えると、正当なエッジケーステストまで省略するという品質劣化が起きる。制約を付けた1エージェントよりも、「実装」と「クリーンアップ」に専念する2つのエージェントに分けるほうが良い結果を出すという観察だ。
# Step 1: 実装（制約なし）
claude -p "Implement the feature with full TDD. Be thorough with tests."
# Step 2: De-sloppify（別コンテキストで専念）
claude -p "Review all changes in the working tree. Remove:
- Tests that verify language/framework behavior rather than business logic
- Redundant type checks the type system already enforces
- Over-defensive error handling for impossible states
- Console.log statements and commented-out code
Keep all business logic tests. Run the test suite after cleanup."
パターン6: Ralphinho RFC-Driven DAG — 最高複雑度パターン
@enitrat が設計した RFC 駆動の多エージェント DAG オーケストレーション。大規模機能の並列実装に向けた最も高度なパターンだ。
アーキテクチャ概観:
複雑度ティアと品質パイプライン段階数:
| ティア | パイプライン段階 |
|---|---|
| trivial | implement → test |
| small | implement → test → code-review |
| medium | research → plan → implement → test → PRD-review + code-review → review-fix |
| large | research → plan → implement → test → PRD-review + code-review → review-fix → final-review |
著者バイアスの排除: 各ステージは独立したコンテキストウィンドウで別エージェントが実行する。レビュアーは自分が書いたコードをレビューしない設計で、著者バイアスによる見落としを構造的に防ぐ。
マージキューのエビクション回復: コンフリクトや CI 失敗で「エビクション」されたユニットには、コンフリクトの全文脈（差分・失敗ログ）が付与される。次の Ralph パスでは文脈付きで再試行されるため、盲目的なリトライではなくインテリジェントな回復が可能だ。
dmux-workflows スキルとの統合: skills/dmux-workflows/SKILL.md では tmux ペインマネージャ dmux による並列エージェントオーケストレーションが定義されている。scripts/orchestrate-worktrees.js がワーカーごとに git worktree / ブランチ / タスクファイルを生成し、ファイルコンフリクトを構造的に防止する。
6パターンの使い分け判断ツリー
タスクが単一の集中した変更か？
├─ Yes → Sequential Pipeline または NanoClaw
└─ No → RFC/仕様書があるか？
├─ Yes → 並列実装が必要か？
│ ├─ Yes → Ralphinho DAG
│ └─ No → Continuous Claude PR Loop
└─ No → 同一仕様の多バリエーション生成か？
├─ Yes → Infinite Agentic Loop
└─ No → Sequential Pipeline + De-Sloppify
ここまでの実務的な要点: 6パターンのうち、まず Sequential Pipeline + De-Sloppify で自律ループの基本を掴み、チーム規模や仕様の複雑度に応じて上位パターンを検討する順番がよい。Ralphinho DAG は設計としては野心的だが、採用には自チームの並列開発規模との見合いが必要だ。
ECC 2.0 Alpha — Rust 製コントロールプレーン
なぜ Rust で再構築するのか
ECC 2.0（ecc2/）は v1.x のフックとコマンドに分散していたセッション管理・メトリクス収集・デーモン実行を一元化する Rust 製コントロールプレーンのアルファ版だ。
CHANGELOG に「real and usable for local experimentation, but the broader control-plane roadmap remains incomplete and should not be treated as GA」と明記されている。プロダクション利用は v1.x の安定版を推奨するスタンスだ。以下で紹介する機能はいずれもこのアルファの文脈で読んでほしい。
実装規模は ecc2/src/main.rs で12,570行（wc -l で確認）。依存ライブラリはパフォーマンスと機能の観点から選定されている。
| ライブラリ | バージョン | 役割 |
|---|---|---|
| ratatui | 0.30 | TUI レンダリング |
| tokio | 1 | 非同期ランタイム |
| rusqlite | 0.32 | SQLite（ビルトイン） |
| git2 | 0.20 | Git 操作 |
| sha2 | 0.10 | セッションハッシュ（SHA256） |
CLI コマンド体系
ecc2 の代表的なコマンドを3グループに整理すると以下のようになる（ecc2/src/main.rs の Commands enum より。約30のトップレベルコマンドのうち主要なものを抜粋）。
コア操作:
ecc2 dashboard # TUI ダッシュボード
ecc2 start # 新規エージェントセッション起動
ecc2 delegate # 既存セッションから子セッション生成
ecc2 sessions # 全セッション一覧
ecc2 status # セッション状態検査
ecc2 resume # 失敗/停止セッションの再開
ecc2 stop # グレースフルシャットダウン
協調・オーケストレーション:
ecc2 template # オーケストレーションテンプレート起動（動的変数対応）
ecc2 assign # 既存デリゲートへのルーティングまたは新規生成
ecc2 drain-inbox # リードセッションの未読タスクハンドオフ
ecc2 auto-dispatch # 複数リードセッションを横断した自動ディスパッチ
ecc2 coordinate-backlog # フルディスパッチ + リバランス + ヘルスチェック
ecc2 maintain-coordination # バックログ圧力に基づく条件付き協調
リモートタスク + マイグレーション（サブコマンド構造）:
ecc2 remote add # リモートタスクリクエストのキューイング
ecc2 remote computer-use # 汎用 computer-use ゴール
ecc2 remote serve # トークン認証リモートインテーク（127.0.0.1:8787）
ecc2 migrate audit # Hermes/OpenClaw ワークスペース分析
ecc2 migrate plan # ECC2 移行戦略生成
TUI ダッシュボードの10項目（アルファ実装）
ecc2/src/tui/dashboard.rs で実装されたダッシュボードは以下の情報を表示する（ファイル実体から確認）。アルファ段階のため、項目や表示形式は今後変わりうる。
- セッショングリッド — 状態バッジ（Running / Paused / Completed / Failed）付きマルチセッション概観
- ハーネス検出 — 10ハーネスを自動識別（Claude Code, Codex, OpenCode, Gemini, Cursor, Kiro, Trae, Zed, FactoryDroid, Windsurf）。v1.x の9ハーネスから Zed・FactoryDroid・Windsurf が追加され、CodeBuddy・Antigravity が除外されている
- ワークツリー Diff ペイン — staged/unstaged 変更のハンク表示、コンフリクト指示
- 出力ストリーム — リアルタイムセッション出力（設定可能バッファ）
- バジェット追跡 — トークンメーター + 通貨メーター、3段階アラート（Advisory / Warning / Critical）
- ツールコールログ — リスクスコア + 実行時間付きツール呼び出し記録
- ファイルアクティビティ — セッション間のオーバーラップ / コンフリクト検出
- 決定ログ — コンテキストグラフ観測（priority 付き）
- デーモンアクティビティ — dispatch / rebalance / auto-merge / auto-prune メトリクス
- 承認キュー — ハンドオフキュープレビュー
リスクスコアリング — 4次元評価（アルファ実装）
ecc2/src/observability/mod.rs で実装。各ツール呼び出しを4つの独立した次元（各 0〜1 スケール）で評価する設計になっている。スコアの閾値やカテゴリはアルファ段階の値であり、チューニング途上と考えるのが妥当だ。
| 次元 | 内容 | スコア例 |
|---|---|---|
| Base Tool Risk | ツール種別の基本リスク | bash: 0.20、write/multiedit: 0.15、edit: 0.10 |
| File Sensitivity | ファイルの機密度 | シークレットファイル（.env 等）: +0.25、共有インフラ（package.json 等）: +0.15 |
| Blast Radius | 影響範囲 | 共有状態（git push --force 等）: +0.35、大範囲（** 等）: +0.25 |
| Irreversibility | 不可逆性 | 高（rm -rf, drop table 等）: +0.45、中（rm -f, delete from 等）: +0.40 |
合計スコアに応じて Allow / Review / RequireConfirmation / Block の4段階で処理が決定される。
ワークツリー管理とセッション管理
ecc2/src/worktree/mod.rs では、セッションごとに独立した git worktree を作成する。ブランチ名は SHA256 ハッシュで決定論的に命名されるため、並列セッション間のコンフリクトが構造的に防止される。
SQLite ベースのセッション管理（ecc2/src/session/store.rs）では DaemonActivity の中に chronic saturation streak（≥3連続） というメトリクスがあり、デーモンが3回以上連続して飽和状態に達した場合に自動的にクールオフして recovery dispatch を行うインテリジェンスが実装されている。
まとめ
本記事ではシリーズ第5弾として、ECC の自律ループパターンと次世代コントロールプレーンを取り上げた。
自律ループ6パターン は単純な claude -p パイプラインから RFC 駆動 DAG まで複雑度に応じて選択できる。Ralphinho の「著者バイアス排除」（レビュアーは実装者とは別コンテキスト）と「エビクション回復」（コンフリクト時の文脈付き再試行）は、大規模な並列開発に向けたアプローチのひとつとして設計されているように見える。De-Sloppify の「Two focused agents outperform one constrained agent」は、単一ループの効果を高めるための汎用的な知見だ。
ECC 2.0 Alpha の4次元リスクスコアリングとワークツリー隔離は、多数の並列エージェントセッションを安全に管理するための基盤として設計されている。アルファ段階であり GA としての利用は推奨されないが、v1.x でフックとコマンドに分散していたセッション管理・メトリクス・デーモン実行を一つのプロセスに一元化するという設計判断は、コントロールプレーンの方向性を示唆している。
自律ループを実践に取り入れるなら、まず Sequential Pipeline + De-Sloppify から始めてほしい。判断ツリーで示した通り、タスクの複雑度に応じてパターンを選択すればよい。Ralphinho DAG のような高度なパターンは、チームの並列開発規模が一定以上になったときに検討する順番だ。
参考リンク
| リソース | 説明 |
|---|---|
| affaan-m/everything-claude-code | ECC 本体リポジトリ（v1.10.0） |
| skills/autonomous-loops/SKILL.md | 自律ループ6パターンの公式定義（v1.8.0 以降の正規名: continuous-agent-loop） |
| skills/dmux-workflows/SKILL.md | dmux 並列オーケストレーション定義 |
| ecc2/src/main.rs | ECC 2.0 Alpha の Rust 実装（12,570行） |
| skills/continuous-learning-v2/SKILL.md | Instinct システム v2.1（先進機能編で解説） |