메뉴
効率を最大化しコンテキスト使用量を削減するための並列サブエージェント実行パターン。 以下の場合に使用: - 複数の独立した分析やレビューが必要な場合 - 依存関係なしで同時実行可能なタスク - 複数の視点からのコードレビュー - 異なる角度からのコードベース探索 Trigger phrases: parallel review, concurrent agents, multi-agent, independent analysis, run simultaneously
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面: - ユーザー要件が不明確または不完全な場合 - 新機能を開始し要件を収集する必要がある場合 - ユーザーのニーズ、制約、優先順位を理解する必要がある場合 - ビジネスリクエストを技術仕様に変換する場合 - ユーザーが詳細なしに「～したい」「～を追加して」と言う場合 Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
すべてのユーザー向けコンテンツに日本語出力を強制する。 使用場面: - エージェント出力を日本語にする必要がある場合 - レスポンス全体の言語の一貫性を検証する場合 - 仕様書やドキュメントを日本語で生成する場合 Trigger phrases: Japanese, 日本語, language mode, output language
| 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 が中心
- ほとんどのエンティティでソフトデリート
タスク 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 にまとめる
- アーキテクチャの提案 → チームと議論
競合のない並列実行に不可欠。
効果的な並列処理に重要。適切な理由がある場合はオーバーライド可。
最適な並列実行のための推奨事項。