自律ループスキル
互換性に関する注意（v1.8.0）：
autonomous-loopsは1リリース分保持されています。 現在の正規スキル名はcontinuous-agent-loopです。新しいループガイダンスは そちらに作成する必要があります。このスキルは既存のワークフローを壊さないために利用可能です。
Claude Codeを自律的にループで実行するためのパターン、アーキテクチャ、およびリファレンス実装。単純なclaude -pパイプラインから完全なRFC駆動マルチエージェントDAGオーケストレーションまでをカバーします。
使用するタイミング
- 人間の介入なしで実行される自律的な開発ワークフローをセットアップする場合
- 問題に適したループアーキテクチャ（単純か複雑か）を選択する場合
- CI/CDスタイルの継続的開発パイプラインを構築する場合
- マージコーディネーションを伴う並列エージェントを実行する場合
- ループ反復間でコンテキストを永続化する実装を行う場合
- 自律ワークフローに品質ゲートとクリーンアップパスを追加する場合
ループパターンスペクトラム
最も単純なものから最も洗練されたものまで：
| パターン | 複雑さ | 最適な用途 |
|---|---|---|
| シーケンシャルパイプライン | 低 | 日々の開発ステップ、スクリプト化されたワークフロー |
| NanoClaw REPL | 低 | インタラクティブな永続セッション |
| 無限エージェントループ | 中 | 並列コンテンツ生成、仕様駆動の作業 |
| 継続的Claude PRループ | 中 | CIゲートを伴う複数日の反復プロジェクト |
| De-Sloppifyパターン | アドオン | 任意の実装ステップ後の品質クリーンアップ |
| Ralphinho / RFC駆動DAG | 高 | 大規模機能、マージキューを伴う複数ユニットの並列作業 |
1. シーケンシャルパイプライン（claude -p）
最も単純なループ。 日々の開発を、一連の非インタラクティブなclaude -p呼び出しに分割します。各呼び出しは、明確なプロンプトを持つ焦点を絞ったステップです。
核となる洞察
このようなループを理解できない場合、それはインタラクティブモードでもLLMを使ってコードを修正することができないことを意味します。
claude -pフラグは、Claude Codeをプロンプト付きで非インタラクティブに実行し、完了すると終了します。呼び出しをチェーンしてパイプラインを構築します：
#!/bin/bash
# daily-dev.sh — 機能ブランチ用のシーケンシャルパイプライン
set -e
# ステップ1: 機能を実装する
claude -p "specs/auth-spec.mdの仕様を読んでください。src/auth/にOAuth2ログインを実装してください。最初にテストを書いて(TDD)。新しいドキュメントファイルは絶対に作成しないでください。"
# ステップ2: デスロップファイ（クリーンアップパス）
claude -p "前回のコミットで変更されたすべてのファイルをレビューしてください。不要な型テスト、過度に防御的なチェック、または言語機能のテスト（例：TypeScriptのジェネリクスが動作することをテストするなど）を削除してください。実際のビジネスロジックテストは維持してください。クリーンアップ後にテストスイートを実行してください。"
# ステップ3: 検証
claude -p "完全なビルド、リンター、型チェック、テストスイートを実行してください。失敗を修正してください。新しい機能は追加しないでください。"
# ステップ4: コミット
claude -p "ステージングされたすべての変更に対して、Conventional Commitsを作成してください。メッセージは「feat: OAuth2ログインフローを追加」としてください。"
主要な設計原則
- 各ステップは分離されている —
claude -p呼び出しごとに新しいコンテキストウィンドウが使われるため、ステップ間でコンテキストの混ざりが発生しません。 - 順序が重要 — ステップは順次実行されます。それぞれが前のステップによって残されたファイルシステムの状態に基づいて構築されます。
- 否定命令は危険 — 「型システムをテストしないで」と言わないでください。代わりに、個別のクリーンアップステップを追加してください（De-Sloppifyパターンを参照）。
- 終了コードは伝播する —
set -eにより、パイプラインは失敗時に停止します。
バリエーション
モデルルーティングを使用：
# Opusでリサーチ（深い推論）
claude -p --model opus "コードベースのアーキテクチャを分析し、キャッシュ追加の計画を書いてください..."
# Sonnetで実装（高速で有能）
claude -p "docs/caching-plan.mdの計画に従ってキャッシュ層を実装してください..."
# Opusでレビュー（徹底的）
claude -p --model opus "すべての変更をセキュリティ問題、競合状態、エッジケースについてレビューしてください..."
環境コンテキストを使用：
# プロンプトの長さではなく、ファイルを介してコンテキストを渡す
echo "フォーカスエリア: authモジュール、APIレート制限" > .claude-context.md
claude -p "優先順位については.claude-context.mdを読んでください。順番に処理してください。"
rm .claude-context.md
--allowedTools制限を使用：
# 読み取り専用分析パス
claude -p --allowedTools "Read,Grep,Glob" "このコードベースをセキュリティ脆弱性について監査してください..."
# 書き込み専用実装パス
claude -p --allowedTools "Read,Write,Edit,Bash" "security-audit.mdからの修正を実装してください..."
2. NanoClaw REPL
ECCの組み込み永続ループ。 完全な会話履歴とともにclaude -pを同期的に呼び出すセッション対応REPL。
# デフォルトセッションを開始
node scripts/claw.js
# スキルコンテキスト付きの名前付きセッション
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
動作の仕組み
~/.claude/claw/{session}.mdから会話履歴を読み込む- 各ユーザーメッセージは、完全な履歴をコンテキストとして
claude -pに送信される - 応答はセッションファイルに追加される（データベースとしてのMarkdown）
- セッションは再起動後も持続する
NanoClaw vs シーケンシャルパイプライン
| ユースケース | NanoClaw | シーケンシャルパイプライン |
|---|---|---|
| インタラクティブな探索 | はい | いいえ |
| スクリプト化された自動化 | いいえ | はい |
| セッションの永続性 | 組み込み | 手動 |
| コンテキストの蓄積 | ターンごとに増加 | 各ステップで新規 |
| CI/CD統合 | 不十分 | 優れている |
詳細については、/clawコマンドのドキュメントを参照してください。
3. 無限エージェントループ
2つのプロンプトからなるシステムで、仕様駆動の生成のために並列サブエージェントをオーケストレーションします。dislerによって開発されました（クレジット: @disler）。
アーキテクチャ：2プロンプトシステム
プロンプト1 (オーケストレーター) プロンプト2 (サブエージェント)
┌─────────────────────┐ ┌──────────────────────┐
│ 仕様ファイルをパース │ │ 完全なコンテキストを受け取る │
│ 出力ディレクトリをスキャン │ デプロイ │ 割り当てられた番号を読む │
│ 反復を計画 │────────────│ 仕様に正確に従う │
│ クリエイティブな方向性を割り当てる│ Nエージェント │ ユニークな出力を生成する │
│ 波を管理する │ │ 出力ディレクトリに保存する │
└─────────────────────┘ └──────────────────────┘
パターン
- 仕様分析 — オーケストレーターが、生成するものを定義した仕様ファイル（Markdown）を読み取る
- ディレクトリ偵察 — 既存の出力をスキャンして最も高い反復番号を見つける
- 並列デプロイ — N個のサブエージェントを起動し、それぞれに以下を提供する：
- 完全な仕様
- ユニークなクリエイティブ方向性
- 特定の反復番号（競合なし）
- 既存の反復のスナップショット（ユニーク性のため）
- 波管理 — 無限モードの場合、コンテキストが尽きるまで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つのバッチ |
| infinite | 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 | 完了シグナル │
└─────────────────────────────────────────────────────┘
インストール
警告: コードを確認した後、リポジトリからcontinuous-claudeをインストールしてください。外部スクリプトを直接bashにパイプしないでください。
使用方法
# 基本: 10反復
continuous-claude --prompt "テストされていないすべての関数にユニットテストを追加" --max-runs 10
# コスト制限付き
continuous-claude --prompt "すべてのリンターエラーを修正" --max-cost 5.00
# 時間制限付き
continuous-claude --prompt "テストカバレッジを改善" --max-duration 8h
# コードレビューパス付き
continuous-claude \
--prompt "認証機能を追加" \
--max-runs 10 \
--review-prompt "npm test && npm run lintを実行し、失敗を修正"
# ワークツリーによる並列実行
continuous-claude --prompt "テストを追加" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "コードをリファクタリング" --max-runs 5 --worktree refactor-worker &
wait
反復間のコンテキスト: SHARED_TASK_NOTES.md
重要な革新：SHARED_TASK_NOTES.mdファイルが反復間で永続化されます：
## 進捗
- [x] authモジュールのテストを追加 (iteration 1)
- [x] トークンリフレッシュのエッジケースを修正 (iteration 2)
- [ ] まだ必要: レート制限テスト、エラーバウンダリテスト
## 次のステップ
- 次にレート制限モジュールに集中
- tests/helpers.tsのモックセットアップは再利用可能
Claudeは反復開始時にこのファイルを読み、反復終了時に更新します。これにより、独立したclaude -p呼び出し間のコンテキストギャップを橋渡しします。
CI障害からの回復
PRチェックが失敗した場合、Continuous Claudeは自動的に：
gh run listを介して失敗した実行IDを取得- CI修正コンテキストを持つ新しい
claude -pを起動 - Claudeは
gh run viewを介してログを検査し、コードを修正、コミット、プッシュ - チェックを再度待機（
--ci-retry-max回まで試行）
完了シグナル
Claudeは魔法のフレーズを出力することで「完了した」ことをシグナルできます：
continuous-claude \
--prompt "課題トラッカー内のすべてのバグを修正" \
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
--completion-threshold 3 # 3回連続のシグナルで停止
3回連続の反復で完了がシグナルされるとループが停止し、完了した作業に対して無駄な実行が行われるのを防ぎます。
主要な設定
| フラグ | 目的 |
|---|---|
--max-runs N | N回の成功した反復後に停止 |
--max-cost $X | $Xを費やした後に停止 |
--max-duration 2h | 経過時間後に停止 |
--merge-strategy squash | squash、merge、またはrebase |
--worktree <name> | gitワークツリーによる並列実行 |
--disable-commits | ドライランモード（git操作なし） |
--review-prompt "..." | 反復ごとにレビューパスを追加 |
--ci-retry-max N | CI障害を自動修正（デフォルト: 1） |
5. De-Sloppifyパターン
任意のループに追加できるアドオンパターン。 各実装ステップの後に、専用のクリーンアップ/リファクタリングステップを追加します。
問題
LLMにTDDで実装するように依頼すると、「テストを書く」という指示を文字通りに受け取りすぎます：
- TypeScriptの型システムが機能することを検証するテスト（
typeof x === 'string'のテスト） - 型システムがすでに保証していることに対する過度に防御的なランタイムチェック
- フレームワークの動作に対するテスト（ビジネスロジックではない）
- 実際のコードを不明瞭にする過剰なエラーハンドリング
なぜ否定命令がダメなのか？
実装プロンプトに「型システムをテストしない」や「不要なチェックを追加しない」を追加すると、下流に影響が出ます：
- モデルはすべてのテストに対して慎重になる
- 正当なエッジケーステストをスキップする
- 品質が予測不能に低下する
解決策：個別のパス
実装者を制約する代わりに、徹底的にやらせてください。その後、焦点を絞ったクリーンアップエージェントを追加します：
# ステップ1: 実装（徹底的にやらせる）
claude -p "完全なTDDで機能を実装してください。テストは徹底的に行ってください。"
# ステップ2: デスロップファイ（個別のコンテキスト、焦点を絞ったクリーンアップ）
claude -p "ワーキングツリー内のすべての変更をレビューしてください。以下を削除：
- ビジネスロジックではなく、言語/フレームワークの動作を検証するテスト
- 型システムがすでに強制している冗長な型チェック
- 不可能な状態に対する過度に防御的なエラーハンドリング
- Console.log文
- コメントアウトされたコード
すべてのビジネスロジックテストは維持してください。クリーンアップ後にテストスイートを実行し、何も壊れていないことを確認してください。"
ループコンテキスト内で
for feature in "${features[@]}"; do
# 実装
claude -p "$featureをTDDで実装してください。"
# デスロップファイ
claude -p "クリーンアップパス: 変更をレビュー、テスト/コードの怪しい部分を削除、テストを実行。"
# 検証
claude -p "ビルド + リンター + テストを実行。失敗を修正。"
# コミット
claude -p "メッセージ: feat: $featureを追加 でコミット"
done
重要な洞察
下流の品質に影響を与える否定命令を追加する代わりに、個別のデスロップファイパスを追加してください。2つの焦点を絞ったエージェントは、1つの制約されたエージェントよりも優れています。
6. Ralphinho / RFC駆動DAGオーケストレーション
最も洗練されたパターン。 RFC駆動のマルチエージェントパイプライン