parallel-execution

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 より:

1. サブエージェントはコンテキストを保持 - 探索は分離して実行
2. 結果のみが返る - メインコンテキストはクリーンに保たれる
3. 独立性が並列性を可能にする - 依存関係なし = 同時実行
4. 集約はメインで実行 - 結果をインテリジェントに統合

並列実行の使用場面

適したタスク

タスクタイプ	エージェント	並列が有効な理由
コードレビュー	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 のクロスチェック

実行

オーケストレーターは:

1. 全エージェントを同時に起動
2. 各エージェントが分離されたコンテキストで実行
3. エージェント完了順に結果がストリーム
4. メインコンテキストが発見を集約

結果の集約

並列完了後:

## 統合レビュー結果

### 重大な問題（修正必須）
- [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: 対立する発見を人間のレビュー用にフラグすることを検討