| name | parallel-execution |
| description | 効率を最大化しコンテキスト使用量を削減するための並列サブエージェント実行パターン。
以下の場合に使用:
- 複数の独立した分析やレビューが必要な場合
- 依存関係なしで同時実行可能なタスク
- 複数の視点からのコードレビュー
- 異なる角度からのコードベース探索
Trigger phrases: parallel review, concurrent agents, multi-agent, independent analysis, run simultaneously
|
| allowed-tools | Read, Glob, Grep, Task |
| model | sonnet |
| user-invocable | true |
| context | fork |
| agent | general-purpose |
並列エージェント実行
複数のサブエージェントを同時実行し、効率を最大化しメインコンテキスト使用量を最小化するテクニック。
基本原則
Claude Code Best Practices より:
- サブエージェントはコンテキストを保持 - 探索は分離して実行
- 結果のみが返る - メインコンテキストはクリーンに保たれる
- 独立性が並列性を可能にする - 依存関係なし = 同時実行
- 集約はメインで実行 - 結果をインテリジェントに統合
並列実行の使用場面
適したタスク
| タスクタイプ | エージェント | 並列が有効な理由 |
|---|
| コードレビュー | qa、security、style | 独立した視点 |
| コードベース探索 | 複数の Explore | 異なる検索角度 |
| テストカバレッジ | unit、integration、e2e | 独立したスコープ |
| ドキュメント | API ドキュメント、ユーザーガイド、変更ログ | 異なる対象読者 |
| アーキテクチャ分析 | フロントエンド、バックエンド、インフラ | 異なるドメイン |
適さない場合
- 依存関係のあるタスク（順次実行が必要）
- 同じファイルを変更するタスク（競合）
- 共有状態が必要なタスク
- シンプルな単一ファイル操作
並列レビューパターン
多角的コードレビュー
可能な限り並列でこれらのチェックを実行:
1. qa-engineer エージェント
タスク: [ファイル] のテストカバレッジをレビュー
出力: 確信度スコア付きテストギャップレポート
2. security-auditor エージェント
タスク: [ファイル] のセキュリティ監査
出力: 脆弱性の発見（確信度 >= 70）
3. code-quality スキル（メインコンテキストで実行）
タスク: [ファイル] のリントとスタイルチェック
出力: 品質の問題と修正
4. verification-specialist エージェント
タスク: 他の並列エージェントの発見を検証
出力: 検証ステータス（VERIFIED/PARTIAL/UNVERIFIED）と file:line のクロスチェック
実行
オーケストレーターは:
- 全エージェントを同時に起動
- 各エージェントが分離されたコンテキストで実行
- エージェント完了順に結果がストリーム
- メインコンテキストが発見を集約
結果の集約
並列完了後:
## 統合レビュー結果
### 重大な問題（修正必須）
- [security-auditor より] auth.ts:45 の SQL インジェクション（確信度: 95）[VERIFIED]
- [qa-engineer より] 支払いフローのテスト不足（確信度: 92）[VERIFIED]
### 重要な問題（修正推奨）
- [code-quality より] utils.ts の未使用インポート [VERIFIED]
- [qa-engineer より] バリデーションのエッジケース未カバー [PARTIAL]
### 提案（検討）
- [code-quality より] 早期リターンパターンの使用検討 [UNVERIFIED]
### 検証サマリー
- [verification-specialist より] 3 VERIFIED、1 PARTIAL、1 UNVERIFIED
並列探索パターン
コードベース発見
不慣れなコードベースの理解時:
探索エージェントを並列で起動:
1. Explore エージェント
タスク: 全 API エンドポイントとそのハンドラーを検索
2. Explore エージェント
タスク: ログインからセッションまでの認証フローを追跡
3. Explore エージェント
タスク: データベースモデルとその関連をマッピング
インサイトの統合
結果がメインコンテキストの探索消費なしに包括的な全体像を作成:
## コードベースの理解
### API 層（エージェント 1 より）
- /api/ に 23 の REST エンドポイント
- ミドルウェアパターンの Express を使用
- /api/protected/* に認証ミドルウェア
### 認証（エージェント 2 より）
- JWT ベースの認証
- リフレッシュトークンローテーション
- Redis にセッションを保存
### データ層（エージェント 3 より）
- Prisma を使用した PostgreSQL
- 15 モデル、User が中心
- ほとんどのエンティティでソフトデリート
順次 vs 並列の判断
順次を使用する場合
タスク A: データベーススキーマの作成
↓
タスク B: Prisma クライアントの生成（A に依存）
↓
タスク C: リポジトリ層の作成（B に依存）
並列を使用する場合
タスク A: フロントエンドコードのレビュー ──┐
タスク B: バックエンドコードのレビュー ──┼── 結果を集約
タスク C: インフラのレビュー ──┘
確信度スコアの集約
複数のエージェントが同じ問題を報告した場合:
| エージェント数 | 確信度の調整 |
|---|
| 1 エージェントが報告 | エージェントのスコアを使用 |
| 2 エージェントが一致 | スコアを +10 ブースト |
| 3+ エージェントが一致 | 確認済みとして扱う |
| エージェント間で不一致 | スコアを平均し、レビュー用にフラグ |
実装チェックリスト
並列エージェント起動前:
バックグラウンドエージェントパターン
長時間の分析:
バックグラウンドで起動:
- フルセキュリティ監査（時間がかかる可能性）
- 完全なテストスイートの実行
- 依存関係の脆弱性スキャン
同時に続行:
- 実装作業
- ドキュメント
- 他のレビュー
準備ができたらバックグラウンド結果を確認。
アンチパターン
| アンチパターン | 悪い理由 | 代わりに |
|---|
| 依存関係のある並列 | 競合状態、誤った順序 | 依存タスクは順次実行 |
| 多すぎる並列エージェント | 圧倒的、集約困難 | レビューは最大 3-4 |
| 同じファイルの並列書き込み | 競合、変更の喪失 | ファイルアクセスを調整 |
| 集約計画なし | インサイトが散乱 | マージ戦略を定義 |
例: フル機能レビュー
## 並列レビュー起動: ユーザーダッシュボード機能
### 起動するエージェント
1. **code-explorer**（バックグラウンド）
- ダッシュボードコンポーネントの全データフローを追跡
- コンポーネント階層をマッピング
2. **qa-engineer**（並列）
- テストカバレッジのレビュー
- 不足しているエッジケースの特定
3. **security-auditor**（並列）
- XSS 脆弱性のチェック
- 全エンドポイントの認証を検証
4. **architect**（並列）
- コンポーネント構造の評価
- 結合の問題をチェック
### 集約戦略
- 任意のエージェントからの重大な問題 → 対処必須
- パフォーマンスの懸念 → 影響度で優先順位付け
- スタイルの問題 → 1 つのクリーンアップ PR にまとめる
- アーキテクチャの提案 → チームと議論
Rules (L1 - Hard)
競合のない並列実行に不可欠。
- ALWAYS: 並列化の前にタスクが独立していることを確認する（競合状態の防止）
- NEVER: 同じファイルを変更する並列エージェントを実行しない（競合の原因）
- NEVER: 結果の集約をスキップしない（散乱したインサイトは無用）
Defaults (L2 - Soft)
効果的な並列処理に重要。適切な理由がある場合はオーバーライド可。
- 起動前に集約戦略を定義する
- エージェント出力に確信度スコアを含める
- 管理性のため並列エージェントは 3-4 に制限
- エージェント間で一貫した出力形式を使用
Guidelines (L3)
最適な並列実行のための推奨事項。
- consider: 長時間の分析にはバックグラウンドエージェントの使用を検討
- prefer: 複数のエージェントが一致した場合の確信度スコアのブーストを推奨
- consider: 対立する発見を人間のレビュー用にフラグすることを検討
