自律ループスキル
互換性に関する注意 (v1.8.0):
autonomous-loopsは1リリースの間保持されます。 正規のスキル名はcontinuous-agent-loopです。新しいループガイダンスは そちらに記述する必要があり、このスキルは既存のワークフローを壊さないために残されています。
Claude Codeを自律的にループで動作させるためのパターン、アーキテクチャ、およびリファレンス実装。単純な claude -p パイプラインから完全なRFC駆動型マルチエージェントDAGオーケストレーションまでをカバーします。
使用するタイミング
- 人間の介入なしで動作する自律的な開発ワークフローのセットアップ
- 問題に適したループアーキテクチャの選択(単純 vs 複雑)
- 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 "docs/auth-spec.md の仕様を読んでください。src/auth/ にOAuth2ログインを実装してください。まずテストを書いてください(TDD)。新しいドキュメントファイルは作成しないでください。"
# ステップ 2: De-sloppify(クリーンアップパス)
claude -p "前のコミットで変更されたすべてのファイルをレビューしてください。不要な型テスト、過度に防御的なチェック、または言語機能のテスト(例:TypeScriptのジェネリクスが動作するかどうかのテスト)を削除してください。実際のビジネスロジックのテストは残してください。クリーンアップ後にテストスイートを実行してください。"
# ステップ 3: 検証
claude -p "完全なビルド、lint、型チェック、テストスイートを実行してください。失敗を修正してください。新しい機能は追加しないでください。"
# ステップ 4: コミット
claude -p "ステージングされたすべての変更に対して、従来のコミットを作成してください。メッセージは 'feat: add OAuth2 login flow' としてください。"
主要な設計原則
- 各ステップは分離されている —
claude -p呼び出しごとに新しいコンテキストウィンドウがあるため、ステップ間でのコンテキストの漏洩はありません。 - 順序が重要 — ステップは順次実行されます。各ステップは、前のステップが残したファイルシステムの状態に基づいて構築されます。
- 否定的な指示は危険 — 「型システムをテストしないでください」と言わないでください。代わりに、別のクリーンアップステップを追加してください(De-Sloppifyパターンを参照)。
- 終了コードが伝播する —
set -eは失敗時にパイプラインを停止します。
バリエーション
モデルルーティングを使用:
# Opusでリサーチ(深い推論)
claude -p --model opus "コードベースアーキテクチャを分析し、キャッシングを追加するための計画を書いてください..."
# Sonnetで実装(高速、高性能)
claude -p "docs/caching-plan.md の計画に従ってキャッシングレイヤーを実装してください..."
# Opusでレビュー(徹底的)
claude -p --model opus "セキュリティ問題、競合状態、エッジケースについてすべての変更をレビューしてください..."
環境コンテキストを使用:
# プロンプトの長さではなく、ファイルを介してコンテキストを渡す
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 制限を使用:
# 読み取り専用の分析パス
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 — 仕様マークダウンファイルへのパス
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 | 完了シグナル │
└─────────────────────────────────────────────────────┘
インストール
警告: コードを確認した上で、リポジトリから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モジュールのテストを追加 (反復 1)
- [x] トークンリフレッシュのエッジケースを修正 (反復 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で実装するように依頼すると、LLMは「テストを書く」を文字通りに受け取りすぎます:
- TypeScriptの型システムが動作することを検証するテスト(
typeof x === 'string'のテスト) - 型システムがすでに保証しているものに対する過度に防御的なランタイムチェック
- ビジネスロジックではなくフレームワークの動作に対するテスト
- 実際のコードを不明瞭にする過剰なエラーハンドリング
なぜ否定的な指示がダメなのか
実装プロンプトに「型システムをテストしないでください」や「不要なチェックを追加しないでください」を追加すると、下流で以下のような影響があります:
- モデルがすべてのテストに対してためらうようになる
- 正当なエッジケーステストをスキップする
- 品質が予測不能に低下する
解決策: 別のパス
実装者を制限する代わりに、徹底的にやらせてください。その後、焦点を絞ったクリーンアップエージェントを追加します:
# ステップ 1: 実装(徹底的にやらせる)
claude -p "完全なTDDで機能を実装してください。テストは徹底的に行ってください。"
# ステップ 2: De-sloppify(別のコンテキスト、焦点を絞ったクリーンアップ)
claude -p "ワーキングツリー内のすべての変更をレビューしてください。以下を削除:
- ビジネスロジックではなく、言語/フレームワークの動作を検証するテスト
- 型システムがすでに強制している冗長な型チェック
- 不可能な状態に対する過度に防御的なエラーハンドリング
- console.log ステートメント
- コメントアウトされたコード
すべてのビジネスロジックテストは維持してください。クリーンアップ後にテストスイートを実行して、何も壊れていないことを確認してください。"
ループコンテキストでの使用
for feature in "${features[@]}"; do
# 実装
claude -p "$feature をTDDで実装してください。"
# De-sloppify
claude -p "クリーンアップパス: 変更をレビューし、テスト/コードのスロップを削除し、テストを実行してください。"
# 検証
claude -p "ビルド + lint + テストを実行してください。失敗を修正してください。"
# コミット
claude -p "メッセージ付きでコミット: feat: $feature を追加"
done
重要な洞察
下流の品質に影響を与える否定的な指示を追加する代わりに、別のde-sloppifyパスを追加してください。2つの焦点を絞ったエージェントは、1つの制約されたエージェントよりも優れています。
6. Ralphinho / RFC駆動DAGオーケストレーション
最も洗練されたパターン。 RFC駆動のマルチエージェントパイプライン