自律ループスキル

互換性に関する注記 (v1.8.0): autonomous-loops は1つのリリースサイクル保持されます。 規範的なスキル名は現在 continuous-agent-loop です。新しいループガイドはこちらに記述され、このスキルは既存のワークフローの破損を避けるため利用可能なままです。

ループ内で Claude Code を自律的に実行するパターン、アーキテクチャ、リファレンス実装。シンプルな claude -p パイプラインから、完全な RFC 駆動型マルチエージェント DAG オーケストレーションまでをカバーします。

使用時期

• 人間の介入なしで実行可能な自律開発ワークフローを確立する
• 問題に対して適切なループアーキテクチャを選択する（シンプル vs 複雑）
• CI/CD スタイルの継続的開発パイプラインを構築する
• マージ調整を使用した並列エージェントを実行する
• ループイテレーション内でコンテキスト永続性を実装する
• 自律ワークフローに品質ゲートとクリーンアップステップを追加する

ループパターンスペクトラム

最もシンプルから最も複雑なものまで：

パターン	複雑度	最適用途
順序パイプライン	低	日常的な開発ステップ、スクリプト化ワークフロー
NanoClaw REPL	低	インタラクティブな永続セッション
無限エージェントループ	中	並列コンテンツ生成、仕様駆動型作業
継続的 Claude PR ループ	中	CI ゲート付きの複数日間にわたるプロジェクトイテレーション
スロップ除去パターン	追加	実装ステップ後の品質クリーンアップ
Ralphinho / RFC 駆動型 DAG	高	大規模機能、マージキュー付きのマルチユニット並列作業

---

1. 順序パイプライン (claude -p)

最もシンプルなループ。 日常的な開発を一連の非インタラクティブな claude -p 呼び出しに分解します。各呼び出しはクリアなプロンプトを備えた焦点を絞ったステップです。

コア洞察

そのようなループを想像できない場合、それはインタラクティブモードで LLM を動かしてコードを修正することすらできないということです。

claude -p フラグはプロンプトを伴い、非インタラクティブに Claude Code を実行して完了時に終了します。呼び出しをチェーンしてパイプラインを構築します：

#!/bin/bash
# daily-dev.sh — Sequential pipeline for a feature branch

set -e

# Step 1: Implement the feature
claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD). Do NOT create any new documentation files."

# Step 2: De-sloppify (cleanup pass)
claude -p "Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks, or testing of language features (e.g., testing that TypeScript generics work). Keep real business logic tests. Run the test suite after cleanup."

# Step 3: Verify
claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."

# Step 4: Commit
claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."

主要な設計原則

1. 各ステップは隔離される — 各 claude -p 呼び出しは新しいコンテキストウィンドウで、ステップ間にコンテキストリークはありません。
2. 順序が重要 — ステップは順序通りに実行されます。各ステップは前のステップが残したファイルシステム状態の上に構築されます。
3. 否定命令は危険 — 「型システムをテストしないでください」と言わないでください。代わりに、個別のクリーンアップステップを追加します（スロップ除去パターンを参照）。
4. 終了コードは伝播する — set -e は失敗時にパイプラインを停止します。

バリアント

モデルルーティングを使用：

# Research with Opus (deep reasoning)
claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."

# Implement with Sonnet (fast, capable)
claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."

# Review with Opus (thorough)
claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."

環境コンテキストを使用：

# Pass context via files, not prompt length
echo "Focus areas: auth module, API rate limiting" > .claude-context.md
claude -p "Read .claude-context.md for priorities. Work through them in order."
rm .claude-context.md

--allowedTools 制限を使用：

# Read-only analysis pass
claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."

# Write-only implementation pass
claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."

---

2. NanoClaw REPL

ECC に組み込まれた永続ループ。 セッション対応 REPL で、完全な会話履歴を使用して claude -p 呼び出しを同期します。

# Start the default session
node scripts/claw.js

# Named session with skill context
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js

仕組み

1. ~/.claude/claw/{session}.md から会話履歴を読み込む
2. 各ユーザーメッセージが完全な履歴をコンテキストとして claude -p に送信される
3. 応答はセッションファイルに追記される（Markdown をデータベースとして使用）
4. セッションは再起動後も永続化される

NanoClaw vs 順序パイプラインの選択

ユースケース	NanoClaw	順序パイプライン
インタラクティブな探索	はい	いいえ
スクリプト化自動化	いいえ	はい
セッション永続性	組み込み	手動
コンテキスト累積	ラウンドごとに増加	各ステップは新規
CI/CD 統合	不十分	優秀

詳細については、/claw コマンドドキュメントを参照してください。

---

3. 無限エージェントループ

デュアルプロンプトシステムで、並列サブエージェントを仕様駆動型生成に対してオーケストレーションします。disler により開発（謝辞：@disler）。

アーキテクチャ：デュアルプロンプトシステム

PROMPT 1（コーディネーター）        PROMPT 2（サブエージェント）
┌─────────────────────┐             ┌──────────────────────┐
│ 仕様ファイルを解析   │             │ 完全なコンテキストを受取│
│ 出力ディレクトリをスキャン │ デプロイ│ 割り当て番号を読取      │
│ イテレーションを計画 │────────────│ 仕様に厳密に従う       │
│ クリエイティブディレクトリを割り当て│ N個エージェント│ ユニークな出力を生成     │
│ バッチを管理         │             │ 出力ディレクトリに保存  │
└─────────────────────┘             └──────────────────────┘

パターン

1. 仕様分析 — コーディネーターが生成するコンテンツを定義する仕様ファイル（Markdown）を読取
2. ディレクトリ偵察 — 既存の出力をスキャンして最高のイテレーション番号を検出
3. 並列デプロイ — N 個のサブエージェントを起動、各々：
   • 完全な仕様
   • ユニークなクリエイティブ方向
   • 特定のイテレーション番号（競合なし）
   • 既存イテレーションのスナップショット（ユニーク性を確保）
4. ウェーブ管理 — 無限モードの場合、コンテキスト枯渇まで 3～5 エージェント単位でウェーブをデプロイ

Claude Code コマンドで実装

.claude/commands/infinite.md を作成：

$ARGUMENTS から以下のパラメータを解析：
1. spec_file — 仕様 Markdown ファイルのパス
2. output_dir — イテレーション結果を保存するディレクトリ
3. count — 整数 1-N または "infinite"

フェーズ 1： 仕様を読取し、深く理解する。
フェーズ 2： output_dir をリスト表示し、最高のイテレーション番号を検出。N+1 から開始。
フェーズ 3： クリエイティブ方向を計画 — 各エージェントは**異なる**テーマ/アプローチを取得。
フェーズ 4： サブエージェントを並列デプロイ（Task ツールを使用）。各エージェント受け取る：
  - 完全な仕様テキスト
  - 現在のディレクトリスナップショット
  - 割り当てられたイテレーション番号
  - 割り当てられたユニークなクリエイティブ方向
フェーズ 5（無限モード）： コンテキスト不足になるまで 3～5 個単位でループ。

呼び出し：

/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite

バッチ戦略

数	戦略
1-5	すべてのエージェント同時実行
6-20	5 個ごとのバッチ
無限	3～5 個ごとのウェーブ、段階的に複雑化

重要な洞察：割り当てによるユニーク性

エージェントが自己区別することに依存しないでください。コーディネーターが各エージェントに特定のクリエイティブ方向とイテレーション番号を割り当てます。これは並列エージェント間での概念的重複を防ぎます。

---

4. 継続的 Claude PR ループ

本番レベルのシェルスクリプトで、継続的なループで Claude Code を実行し、PR を作成、CI を待機、自動マージします。AnandChowdhary により作成（謝辞：@AnandChowdhary）。

コアループ

┌─────────────────────────────────────────────────────┐
│  継続的 CLAUDE イテレーション                       │
│                                                     │
│  1. ブランチを作成 (continuous-claude/iteration-N)  │
│  2. 拡張プロンプトで claude -p を実行               │
│  3. （オプション）レビュアーパス — 別の claude -p    │
│  4. 変更をコミット (claude がコミットメッセージ生成)│
│  5. プッシュ + PR を作成 (gh pr create)             │
│  6. CI チェックを待機 (gh pr checks をポーリング)   │
│  7. CI 失敗？ → 自動修復経由 (claude -p)            │
│  8. PR をマージ (squash/merge/rebase)               │
│  9. main に戻る → 繰り返し                          │
│                                                     │
│  制限： --max-runs N | --max-cost $X                │
│        --max-duration 2h | 完了信号                 │
└─────────────────────────────────────────────────────┘

インストール

curl -fsSL https://raw.githubusercontent.com/AnandChowdhary/continuous-claude/HEAD/install.sh | bash

使用法

# Basic: 10 iterations
continuous-claude --prompt "Add unit tests for all untested functions" --max-runs 10

# Cost-limited
continuous-claude --prompt "Fix all linter errors" --max-cost 5.00

# Time-boxed
continuous-claude --prompt "Improve test coverage" --max-duration 8h

# With code review pass
continuous-claude \
  --prompt "Add authentication feature" \
  --max-runs 10 \
  --review-prompt "Run npm test && npm run lint, fix any failures"

# Parallel via worktrees
continuous-claude --prompt "Add tests" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refactor code" --max-runs 5 --worktree refactor-worker &
wait

イテレーション間コンテキスト：SHARED_TASK_NOTES.md

重要な革新：SHARED_TASK_NOTES.md ファイルがイテレーション間で永続化：

## 進捗
- [x] 認証モジュールテスト追加（ラウンド 1）
- [x] トークンリフレッシュのエッジケース修正（ラウンド 2）
- [ ] 未完了：レート制限テスト、エラー境界テスト

## 次のステップ
- 次はレート制限モジュールに焦点
- `tests/helpers.ts` のテストでモック設定を再利用可能

Claude はイテレーション開始時にこのファイルを読取り、イテレーション終了時に更新します。これは独立した claude -p 呼び出し間のコンテキストギャップを埋めます。

CI 失敗回復

PR チェックが失敗した場合、継続的 Claude は自動的に：

1. gh run list で失敗したランの ID を取得
2. CI 修正コンテキストで新しい claude -p を生成
3. Claude が gh run view でログをチェック、コード修正、コミット、プッシュ
4. チェックを再待機（最大 --ci-retry-max 回試行）

完了信号

Claude はマジックフレーズを出力して「完了した」を合図できます：

continuous-claude \
  --prompt "Fix all bugs in the issue tracker" \
  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
  --completion-threshold 3  # Stops after 3 consecutive signals

連続 3 イテレーションで完了信号を出力するとループが停止し、既に完了した作業での実行浪費を防ぎます。

主要設定

フラグ	目的
--max-runs N	N 回の成功イテレーション後に停止
--max-cost $X	$X 消費後に停止
--max-duration 2h	時間経過後に停止
--merge-strategy squash	squash、merge または rebase
--worktree <name>	git worktrees 経由で並列実行
--disable-commits	ドライランモード（git 操作なし）
--review-prompt "..."	各イテレーションにレビュアーレビューを追加
--ci-retry-max N	CI 失敗を自動修復（デフォルト：1）

---

5. スロップ除去パターン

任意のループへの追加パターン。 各実装ステップの後に専用のクリーンアップ/リファクタリングステップを追加します。

問題

LLM に TDD で実装するよう要求すると、「テストを書く」の理解が過度に字句的：

• TypeScript の型システムが機能するかを検証するテスト（typeof x === 'string' をテスト）
• 型システムが既に保証するものの過度に防御的な実行時チェック
• フレームワーク動作をテスト（ビジネスロジックではなく）
• 実際のコードを曖昧にする過剰なエラーハンドリング

なぜ否定命令を使用しないのか？

実装プロンプトに「型システムをテストしないでください」または「不要なチェックを追加しないでください」を追加すると、下流への影響：

• モデルがすべてのテストに対して躊躇するようになる
• 正当なエッジケーステストをスキップする
• 品質が不確実に低下

解決策：個別ステップ

実装者を制限する代わりに、徹底させます。次に専用のクリーンアップエージェントを追加：

# Step 1: Implement (let it be thorough)
claude -p "Implement the feature with full TDD. Be thorough with tests."

# Step 2: De-sloppify (separate context, focused cleanup)
claude -p "Review all changes in the working tree. Remove:
- Tests that verify language/framework behavior rather than business logic
- Redundant type checks that the type system already enforces
- Over-defensive error handling for impossible states
- Console.log statements
- Commented-out code

Keep all business logic tests. Run the test suite after cleanup to ensure nothing breaks."

ループコンテキスト内

for feature in "${features[@]}"; do
  # Implement
  claude -p "Implement $feature with TDD."

  # De-sloppify
  claude -p "Cleanup pass: review changes, remove test/code slop, run tests."

  # Verify
  claude -p "Run build + lint + tests. Fix any failures."

  # Commit
  claude -p "Commit with message: feat: add $feature"
done

重要な洞察

下流品質への影響がある否定命令を追加する代わりに、個別のスロップ除去ステップを追加します。2 つの焦点を絞ったエージェントが 1 つの制約を受けたエージェントより優れています。

---

6. Ralphinho / RFC 駆動型 DAG オーケストレーション

最も複雑なパターン。 RFC 駆動型マルチエージェントパイプラインで、仕様を依存関係 DAG を持つ作業単位に分解し、階層品質パイプラインで各単位を実行、エージェント駆動型マージキューで落地します。enitrat により作成（謝辞：@enitrat）。

アーキテクチャ概要

RFC/PRD ドキュメント
       │
       ▼
  分解（AI）
  依存関係 DAG を持つ作業単位に RFC を分解
       │
       ▼
┌──────────────────────────────────────────────────────┐
│  RALPH ループ（最大 3 ラウンド）                     │
│                                                      │
│  各 DAG レイヤー（依存関係順）に対して：              │
│                                                      │
│  ┌── 品質パイプライン（各単位並列） ───────┐         │
│  │  各単位を独立したワークツリーで：        │         │
│  │  リサーチ → 計画 → 実装 → テスト → レビュー│      │
│  │  （深さは複雑度レイヤーに基づき変動）    │         │
│  └────────────────────────────────────────────────┘  │
│                                                      │
│  ┌── マージキュー ─────────────────────────────────┐ │
│  │  main へリベース → テスト実行 → マージまたは削除  │ │
│  │  削除された単位は冲突コンテキストで再度入力      │ │
│  └────────────────────────────────────────────────┘ │
│                                                      │
└──────────────────────────────────────────────────────┘

RFC 分解

AI が RFC を読取り、作業単位を生成：

interface WorkUnit {
  id: string;              // kebab-case identifier
  name: string;            // Human-readable name
  rfcSections: string[];   // Which RFC sections this addresses
  description: string;     // Detailed description
  deps: string[];          // Dependencies (other unit IDs)
  acceptance: string[];    // Concrete acceptance criteria
  tier: "trivial" | "small" | "medium" | "large";
}

分解ルール：

• より少なく、よくまとまった単位を優先（マージリスクを最小化）
• ユニット間ファイルオーバーラップを最小化（競合を回避）
• テストと実装を一緒に保持（「X を実装」+「X をテスト」を分割しない）
• 実際のコード依存関係が存在する場所のみに依存関係を設定

依存関係 DAG が実行順序を決定：

レイヤー 0: [unit-a, unit-b]     ← 依存なし、並列実行
レイヤー 1: [unit-c]             ← unit-a に依存
レイヤー 2: [unit-d, unit-e]     ← unit-c に依存

複雑度レイヤー

異なるレイヤーが異なる深さのパイプラインを取得：

レイヤー	パイプラインステージ
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

これはシンプルな変更に対する高コスト操作を防ぎながら、アーキテクチャ変更が徹底的にレビューされることを確保します。

独立したコンテキストウィンドウ（作成者バイアスを排除）

各ステージは独自のエージェントプロセスで実行され、独自のコンテキストウィンドウ：

ステージ	モデル	目的
Research	Sonnet	コードベース + RFC を読取、コンテキストドキュメントを生成
Plan	Opus	実装ステップを設計
Implement	Codex	計画に従いコードを記述
Test	Sonnet	ビルド + テストスイート実行
PRD Review	Sonnet	仕様コンプライアンスチェック
Code Review	Opus	品質 + セキュリティチェック
Review Fix	Codex	レビュー問題に対処
Final Review	Opus	品質ゲート（大規模レイヤーのみ）

重要な設計： レビュアーは編集中のコードをレビューしません。これは作成者バイアスを排除 — 自己レビューで問題が見落とされる最一般的な原因。

削除機能付きマージキュー

品質パイプライン完了後、単位がマージキューに進行：

単位ブランチ
    │
    ├─ main へリベース
    │   └─ 冲突？→ 削除（冑突コンテキストをキャプチャ）
    │
    ├─ ビルド + テスト実行
    │   └─ 失敗？→ 削除（テスト出力をキャプチャ）
    │
    └─ 通過 → main へ高速前進マージ、プッシュ、ブランチ削除

ファイルオーバーラップ インテリジェンス：

• 非オーバーラップ単位は推測的に並列に落地
• オーバーラップ単位は 1 つずつ落地、毎回リベース

削除回復： 削除時、完全なコンテキスト（冑突ファイル、差分、テスト出力）がキャプチャされ、次の Ralph ラウンドの実装者にフィードバック：

## マージ冑突 — 次のプッシュ前に解決

前回の実装は、別のユニットで既に先にプッシュされたものと冑突しました。
以下の冑突したファイル/行を回避するようにしてください。

{完全な削除コンテキスト及び差分}

ステージ間データフロー

research.contextFilePath ──────────────────→ 計画
plan.implementationSteps ──────────────────→ 実装
implement.{filesCreated, whatWasDone} ─────→ テスト、レビュー
test.failingSummary ───────────────────────→ レビュー、実装（次ラウンド）
reviews.{feedback, issues} ────────────────→ レビュー修正 → 実装（次ラウンド）
final-review.reasoning ────────────────────→ 実装（次ラウンド）
evictionContext ───────────────────────────→ 実装（マージ冑突後）

ワークツリー隔離

各単位は隔離されたワークツリーで実行（git ではなく jj/Jujutsu を使用）：

/tmp/workflow-wt-{unit-id}/

同じ単位のパイプラインステージは同じワークツリーを共有、research → plan → implement → test → review 間で状態を保持（コンテキストファイル、計画ファイル、コード変更）。

重要な設計原則

1. 決定論的実行 — 事前分解により並列性と順序をロック
2. レバレッジポイントで人間レビュー — 作業計画は単一の最高レバレッジ介入ポイント
3. 関心の分離 — 各ステージが独立したコンテキストウィンドウで、独立したエージェントが責任
4. コンテキスト付き冑突回復 — 完全な削除コンテキストがインテリジェントな再試行をサポート（ブラインド再試行ではなく