マルチエージェント・オーケストレーション

597以上の本番環境コードベースでの実際のエージェント派遣から抽出されたメタ・オーケストレーション・パターン。このスキルはオーケストレーション戦略を作業形態にマッピングし、プロンプト構造をエージェントタイプにマッピングし、バックグラウンド/フォアグラウンドを依存関係グラフにマッピングします。

コア原則: 戦略を作業に合わせ、エージェントを独立性で分割し、並列性が実現できるだけのコンテキストを注入し、信頼が得られるにつれてレビューのオーバーヘッドを適応させます。以下の戦略は参照パターンです。適切なものを選択し、作業が混在している場合は2つをブレンドし、パターンが当てはまらない場合は独自に発明してください。

戦略選択

digraph strategy_selection {
    rankdir=TB;
    "What type of work?" [shape=diamond];

    "Research / knowledge gathering" [shape=box];
    "Independent feature builds" [shape=box];
    "Sequential dependent tasks" [shape=box];
    "Same transformation across partitions" [shape=box];
    "Codebase audit / assessment" [shape=box];
    "Greenfield project kickoff" [shape=box];

    "Research Swarm" [shape=box style=filled fillcolor=lightyellow];
    "Epic Parallel Build" [shape=box style=filled fillcolor=lightyellow];
    "Sequential Pipeline" [shape=box style=filled fillcolor=lightyellow];
    "Parallel Sweep" [shape=box style=filled fillcolor=lightyellow];
    "Multi-Dimensional Audit" [shape=box style=filled fillcolor=lightyellow];
    "Full Lifecycle" [shape=box style=filled fillcolor=lightyellow];

    "What type of work?" -> "Research / knowledge gathering";
    "What type of work?" -> "Independent feature builds";
    "What type of work?" -> "Sequential dependent tasks";
    "What type of work?" -> "Same transformation across partitions";
    "What type of work?" -> "Codebase audit / assessment";
    "What type of work?" -> "Greenfield project kickoff";

    "Research / knowledge gathering" -> "Research Swarm";
    "Independent feature builds" -> "Epic Parallel Build";
    "Sequential dependent tasks" -> "Sequential Pipeline";
    "Same transformation across partitions" -> "Parallel Sweep";
    "Codebase audit / assessment" -> "Multi-Dimensional Audit";
    "Greenfield project kickoff" -> "Full Lifecycle";
}

戦略	使用する場面	エージェント数	バックグラウンド	キーパターン
Research Swarm	知識収集、ドキュメント、SOTA調査	10-60+	あり (100%)	ファンアウト、各自がドキュメント作成
Epic Parallel Build	独立したエピック/機能による計画	20-60+	あり (90%+)	サブシステム別ウェーブ派遣
Sequential Pipeline	依存タスク、共有ファイル	3-15	なし (0%)	実装 → レビュー → 修正チェーン
Parallel Sweep	モジュール全体への同じ修正/変換	4-10	なし (0%)	ディレクトリ別パーティション、ファンアウト
Multi-Dimensional Audit	品質ゲート、深い評価	6-9	なし (0%)	同じコード、異なるレビューレンズ
Full Lifecycle	ゼロからの新規プロジェクト	すべて	混合	調査 → 計画 → 構築 → レビュー → 強化

---

戦略1: Research Swarm

バックグラウンドエージェントを大量展開して知識コーパスを構築します。各エージェントは1つのトピックについて調査し、1つのMarkdownドキュメントを作成します。エージェント間に依存関係はありません。

使用する場面

• 新規プロジェクトのキックオフ (すべてのテクノロジーのSOTAが必要)
• スキル/プラグインの構築 (包括的な領域知識が必要)
• テクノロジー評価 (複数のオプションを並列比較)

パターン

フェーズ1: 調査部隊の展開 (すべてバックグラウンド)
    ウェーブ1 (10-20エージェント): コアテクノロジー調査
    ウェーブ2 (10-20エージェント): 専門トピック、統合
    ウェーブ3 (5-10エージェント): 初期結果に基づくギャップ補充

フェーズ2: モニタリングと補完
    - 完成したドキュメントが到着したら確認
    - ギャップを特定し、ターゲット化されたフォローアップエージェントを展開
    - 完成した調査を読んで残りの派遣に情報を提供

フェーズ3: 統合
    - すべての調査ドキュメントを読む (フォアグラウンド)
    - アーキテクチャ計画、設計ドキュメントを作成
    - Planエージェントを使用して調査結果を統合

プロンプトテンプレート: 調査エージェント

[PROJECT]の[USE CASE]のため、[TECHNOLOGY]を調査してください。

[OUTPUT_PATH]/[filename].md に、以下をカバーする包括的な調査ドキュメントを作成してください:

1. 最新[TECH]バージョンと機能 ("[TECH] 2026"または"[TECH] latest"を検索)
2. [プロジェクトに関連する特定機能]
3. [関連する別の機能]
4. [スタックの他のコンポーネントとの統合パターン]
5. [パフォーマンス特性]
6. [既知の問題と制限事項]
7. [本番環境使用のベストプラクティス]
8. [主要パターンのコード例]

可能な限りコード例を含めてください。WebSearchとWebFetchを使用して最新のドキュメントを取得してください。

優れた調査エージェントプロンプトの特徴:

• 明示的な出力ファイルパス (どこに書くかについてあいまいさなし)
• 年付きの検索ヒント ("search [TECH] 2026") により、エージェントに最新性ガイダンスを提供
• 番号付きカバレッジリスト (8-12項目) で調査を正確にスコープ化
• バックグラウンド派遣をデフォルトに (調査トピックは相互依存がない)

派遣頻度

• エージェント派遣間で3-4秒間隔を置くと通常レート制限を回避できます
• 10-20エージェントの主題別ウェーブは管理可能なサイズになる傾向があります
• ウェーブ間で15-25分のギャップを確保すると、初期結果でのギャップ分析に余裕が生まれます

---

戦略2: Epic Parallel Build

バックグラウンドエージェントを展開して、独立した機能/エピックを同時に実装します。各エージェントは独自のディレクトリ/モジュールで1つの機能を構築します。2つのエージェントが同じファイルを触りません。

使用する場面

• 10以上の独立したタスクを含む実装計画
• 分離されたパッケージ/モジュールのMonorepo
• 重複しない機能を持つスプリントバックログ

パターン

フェーズ1: スカウト (フォアグラウンド)
    - 1つのExploreエージェントを派遣してコードベースをマッピング
    - 依存チェーンと独立したワークストリームを特定
    - ファイル競合を防ぐためにタスクをサブシステム別にグループ化

フェーズ2: ビルド部隊の展開 (すべてバックグラウンド)
    ウェーブ1: インフラ/基盤 (Redis、DB、認証)
    ウェーブ2: バックエンドAPI (各自が独自のモジュールディレクトリ)
    ウェーブ3: フロントエンドページ (各自が独自のルートディレクトリ)
    ウェーブ4: 統合 (MCPサーバー、外部サービス)
    ウェーブ5: DevOps (CI、Docker、デプロイメント)
    ウェーブ6: レビュー検出からのバグ修正

フェーズ3: モニタリングと調整
    - 完成したコミットのgitステータスを確認
    - gitインデックスロック競合に対応 (30以上エージェントで予想)
    - エージェント完了時に残りのタスクを派遣
    - SibylタスクまたはTodoWriteで追跡

フェーズ4: レビューと強化 (フォアグラウンド)
    - 完成した作業について`/hyperskills:cross-model-review`を実行
    - 重大な検出事項について修正エージェントを派遣
    - 統合テスト

プロンプトテンプレート: 機能構築エージェント

**タスク: [DESCRIPTIVE TITLE]** (task\_[ID])

/path/to/project/[SPECIFIC_DIRECTORY]で作業してください

## コンテキスト

[既に存在するもの。特定のファイル、パターン、インフラストラクチャを参照してください]
[例: "Redisは`app.state.redis`で利用可能"、"`src/auth/`からパターンに従ってください"]

## あなたの仕事

1. `src/path/to/module/`を作成してください:
   - `file.py` -- [説明]
   - `routes.py` -- [説明]
   - `models.py` -- [スキーマ定義]

2. 実装要件:
   [コードスニペット、Pydanticモデル、APIコントラクトを含む詳細仕様]

3. テスト:
   - `tests/test_module.py`を作成してください
   - カバー: [特定のテストシナリオ]

4. 統合:
   - [メインアプリケーションエントリポイント]に接続
   - [パス]でルートを登録

## Git

コミットメッセージ: "feat([module]): [description]"
あなたが作成したファイルだけをステージしてください。コミット前に`git status`を確認してください。
他のエージェントのファイルをステージしないでください。

優れたビルドエージェントプロンプトの特徴:

• 各エージェントは独自のディレクトリスコープを取得 (ファイル所有権の重複はマージコンフリクトと失われたロードを生成)
• 従うべき既存パターン ("パターンXに従ってください") で、エージェントが1つを発明する手間を省く
• インフラコンテキスト ("RedisはXで利用可能") で、エージェントが既に存在するものを再発見するのを防ぎます
• 明示的なgit衛生 (30以上並列エージェントでは、これは負荷を支える、オプションではありません)
• スウォーム全体での追跡可能性のためのタスクID

並列エージェントのGit調整

10以上のエージェントを同時に実行する場合、いくつかの現実が重要です:

• index.lock競合は予想される エージェントは自動的に再試行します。これを防ごうとしないでください
• 各エージェントは独自のファイルのみをコミット プロンプトでこれを明示的に述べないと、エージェントは兄弟のWIPを回収します
• git add .とgit add -AはNGです 特定のパスのみ
• 定期的にgit log --oneline -20でモニタ して、停滞またはパターン外のエージェントを検出
• プッシュはオーケストレーターの判断です。統合後の、エージェントではなく

---

戦略3: Sequential Pipeline

依存タスクを1つずつ実行し、レビューゲートで実行します。各タスクは前のタスクの出力に基づいて構築されます。

使用する場面

• 共有ファイルを変更するタスク
• 統合境界作業 (JNIブリッジ、認証チェーン)
• 各修正が前のレビュー検出事項に依存するレビュー・修正サイクル
• 実装順序が重要な複雑な機能

パターン

各タスクについて:
    1. 実装者を派遣 (フォアグラウンド)
    2. 仕様レビュアーを派遣 (フォアグラウンド)
    3. コード品質レビュアーを派遣 (フォアグラウンド)
    4. 検出事項を修正
    5. 次のタスクに移動

信頼勾配 (時間とともに適応):
    初期タスク:  実装 → 仕様レビュー → コードレビュー (完全な儀式)
    中期タスク: 実装 → 仕様レビュー (軽度)
    後期タスク:   実装のみ (パターン実証、高い信頼度)

信頼勾配

パターンが信頼性を証明するにつれて、あらゆるタスクで完全な儀式を実行する代わりにレビューオーバーヘッドを軽減します。12番目の同一CRUD エンドポイントで完全レビューのコストは実在しており、信号雑音比は低下します:

フェーズ	レビューオーバーヘッド	通常
完全な儀式	実装 + 仕様レビュー + コードレビュー	最初の3-4タスク
標準	実装 + 仕様レビュー	タスク5-8、パターンが安定した後
軽度	実装 + 簡易スポットチェック	確立されたパターンの後期タスク
コスト最適化	ホストの設定高速レビュアーを使用	公式化されたレビューパス

これは得られた信頼であり、コーナーを切ることではありません。タスクが確立されたパターンから逸脱するたびに勾配がリセットされます。本当に新しいものについては完全な儀式に引き上げてください。

---

戦略4: Parallel Sweep

コードベースの分割領域全体に同じ変換を適用します。すべてのエージェントは同じ種類の作業を行いますが、異なるファイルで実行します。

使用する場面

• モジュール全体のLint/フォーマット修正
• パッケージ全体への型アノテーション追加
• 複数モジュールのテスト作成
• コンポーネント全体のドキュメント更新
• ページ全体のUI ポーランド

パターン

フェーズ1: スコープを分析
    - ツール (ruff、tyなど) を実行して完全な問題リストを取得
    - 可能なものを自動修正
    - 残りの問題をモジュール/ディレクトリ別にグループ化

フェーズ2: ファンアウト修正エージェント (4-10エージェント)
    - モジュール/ディレクトリごとに1つのエージェント
    - 各自には: カテゴリ別問題数、領域固有ガイダンス
    - すべてフォアグラウンド (各自が完了することを確認する必要があります)

フェーズ3: 確認と繰り返し
    - ツールを再度実行して残りの問題をチェック
    - 問題が残っている場合は別のウェーブを派遣
    - クリーンになるまで繰り返し

プロンプトテンプレート: モジュール修正エージェント

[PATH]の[MODULE_NAME]ディレクトリのすべての[TOOL]問題を修正してください。

現在の問題 ([COUNT]件合計):

- [RULE_CODE]: [説明] ([count]) -- [領域固有の修正ガイダンス]
- [RULE_CODE]: [説明] ([count]) -- [領域固有の修正ガイダンス]

`[TOOL_COMMAND] [PATH]`を実行して正確な問題を確認してください。

[DOMAIN]コードの重要な注意:
[領域固有のガイダンス、例: "GTKインポートはgi.repositoryインポート前にGI.require_version()が必要"]

修正後、`[TOOL_COMMAND] [PATH]`を実行して問題がゼロになったことを確認してください。

優れたスウィープエージェントプロンプトの特徴:

• 「すべて修正」ではなくカテゴリ別の問題数で、エージェントが検証する対象を持つ
• 領域固有ガイダンス (そうしないとエージェントはカーゴカルトまたはオーバーライド)
• ディレクトリパーティション (重複を防ぐ)
• ウェーブ形状: 修正 → 確認 → 残りを修正 → 確認 (問題数が収束するまで)

---

戦略5: Multi-Dimensional Audit

複数のレビュアーを展開して同じコードを異なる角度から同時に検査します。各レビュアーは異なるフォーカスレンズを持っています。

使用する場面

• 主要機能完了、包括的レビューが必要
• リリース前の品質ゲート
• セキュリティ監査
• パフォーマンス評価

パターン

6つの並列レビュアーを派遣 (すべてフォアグラウンド):
    1. コード品質・安全性レビュアー
    2. 統合正確性レビュアー
    3. 仕様完全性レビュアー
    4. テストカバレッジレビュアー
    5. パフォーマンス分析者
    6. セキュリティ監査人

すべての完了を待ってから:
    - 検出事項を優先アクションリストに統合
    - 重大な問題については標的修正エージェントを派遣
    - 検出事項があった次元のみを再レビュー

プロンプトテンプレート: 次元レビュアー

[COMPONENT]実装の[DIMENSION]レビュー。

**レビューするファイル:**

- [file1.ext]
- [file2.ext]
- [file3.ext]

**分析:**

1. [この次元に対する特定の質問]
2. [この次元に対する特定の質問]
3. [この次元に対する特定の質問]

**レポート形式:**

- 検出事項: 重大度別の番号付きリスト (Critical/Important/Minor)
- 評価: 承認 / 変更が必要
- 推奨事項: 優先アクションアイテム

---

戦略6: Full Lifecycle

Greenfieldプロジェクトの場合、すべての戦略を順序付けて結合します:

セッション1: 調査 (Research Swarm)
    -> 30-60バックグラウンドエージェントが知識コーパスを構築
    -> アーキテクチャ計画エージェントが調査結果を統合
    -> 出力: docs/research/*.md + docs/plans/*.md

セッション2: 構築 (Epic Parallel Build)
    -> Scoutエージェントが既存をマッピング
    -> 30-60バックグラウンドエージェントがエピック別に機能を構築
    -> モニタリング、git競合を処理、完了を追跡
    -> 出力: コミット付きの動作するコードベース

セッション3: イテレート (Build-Review-Fix Pipeline)
    -> コードレビューエージェントが作業を評価
    -> 修正エージェントが検出事項に対応
    -> 深い監査エージェント (フォアグラウンド) が各サブシステムを評価
    -> 出力: 品質評価されたコードベース

セッション4: 強化 (Sequential Pipeline)
    -> 統合境界レビュー (フォアグラウンド、順序付け)
    -> セキュリティ修正、競合状態修正
    -> テストインフラ設定
    -> 出力: 本番環境対応コードベース

セッション5: 統合 (Dream)
    -> 耐久性のあるパターン、落とし穴、アーキテクチャの決定事項をキャプチャ
    -> Sibylのプロジェクトコンテキストに学習をリンク
    -> 出力: 将来のセッションのための更新された知識グラフ

各セッションはオーケストレーション戦略を作業の性質に合わせてシフト。可能な限り並列、必要な場合は順序付け。

---

バックグラウンド vs フォアグラウンド決定

digraph bg_fg {
    "What is the agent producing?" [shape=diamond];

    "Information (research, docs)" [shape=box];
    "Code modifications" [shape=box];

    "Does orchestrator need it NOW?" [shape=diamond];
    "BACKGROUND" [shape=box style=filled fillcolor=lightgreen];
    "FOREGROUND" [shape=box style=filled fillcolor=lightyellow];

    "Does next task depend on this task's files?" [shape=diamond];
    "FOREGROUND (sequential)" [shape=box style=filled fillcolor=lightyellow];
    "FOREGROUND (parallel)" [shape=box style=filled fillcolor=lightyellow];

    "What is the agent producing?" -> "Information (research, docs)";
    "What is the agent producing?" -> "Code modifications";

    "Information (research, docs)" -> "Does orchestrator need it NOW?";
    "Does orchestrator need it NOW?" -> "FOREGROUND" [label="yes"];
    "Does orchestrator need it NOW?" -> "BACKGROUND" [label="no - synthesize later"];

    "Code modifications" -> "Does next task depend on this task's files?";
    "Does next task depend on this task's files?" -> "FOREGROUND (sequential)" [label="yes"];
    "Does next task depend on this task's files?" -> "FOREGROUND (parallel)" [label="no - different modules"];
}

597以上の派遣で観察されたパターン:

• 依存関係がない調査エージェント → バックグラウンド (本質的には常に)
• コード作成エージェント → フォアグラウンド (並列実行中でも)
• レビュー/検証ゲート → フォアグラウンド (パイプラインの進行をブロックするため)
• 順序付け依存 → フォアグラウンド、1つずつ

---

プロンプトエンジニアリング・パターン

パターンA: ロール + ミッション + 構造 (調査)

あなたは[PROJECT]の包括的なドキュメントを作成するために[DOMAIN]を調査しています。

あなたのミッション: [TOPIC]のすべての機能をカバーする包括的なリファレンスドキュメントを作成します。

これらの領域を詳細にカバー:

1. **[カテゴリ]** -- 特定アイテム
2. **[カテゴリ]** -- 特定アイテム
   ...

WebSearchとWebFetchを使用して、ブログ記事、GitHubリポジトリ、公式ドキュメントを見つけてください。

パターンB: タスク + コンテキスト + ファイル + 仕様 (機能構築)

**タスク: [TITLE]** (task\_[ID])

/absolute/path/to/[directory]で作業してください

## コンテキスト

[何が存在し、何を読み、どのインフラストラクチャが利用可能か]

## あなたの仕事

1. [説明]付きの`path/to/file`を作成
2. [詳細な実装仕様]
3. [テスト要件]
4. [統合要件]

## Git

コミットメッセージ: "feat([scope]): [message]"
あなたのファイルのみをステージしてください。

パターンC: レビュー + 確認 + レポート (監査)

[SCOPE]の[DIMENSION]の包括的な監査。

以下を探してください:

1. [特定のもの #1]
2. [特定のもの #2]
   ...
3. [特定のもの #10]

[スコープの境界 -- どのディレクトリ/ファイル]

レポート形式:

- 検出事項: 重大度付き番号付き
- 評価: パス / 作業が必要
- アクションアイテム: 優先付け

パターンD: 問題 + 場所 + 修正 (バグ修正)

**タスク:** [ISSUE]を修正 -- [SEVERITY]

**問題:** [ファイル:行参照を含む説明]
**場所:** [正確なファイルパス]

**必要な修正:**

1. [特定の変更]
2. [特定の変更]

**確認:**

1. [コマンド]を実行して修正を確認
2. テスト実行: [テストコマンド]

---

コンテキスト注入: 並列性の実現者

並列エージェントはオーケストレーターが事前にコンテキストを読み込むときだけ並列で機能します。それなしでは、すべてのエージェントが有用な作業をする前にコードベースを再探索し、並列性は順序付け発見に崩壊します。

ほとんどのプロンプトに注入する価値がある:

• 相対的ではなく絶対ファイルパス (エージェントは予期しないcwdから実行される場合があります)
• 従うべき既存パターン ("パターンから従ってくださいsrc/auth/jwt.py")
• 利用可能なインフラ ("Redisはapp.state.redis")
• デザイン言語と慣行 ("SilkCircuit Neon palette")
• ツール使用ヒント ("WebSearchを使用して...")
• Git指示 ("あなたのファイルのみをステージしてください")

並列エージェントの場合:

• 共有コンテキストブロックを各プロンプトに複製します。コンテキストは無料ではありませんが、冗長なコンテキストは順序付け探索を上回ります
• 明示的な除外メモを追加 ("エージェント11-Sibylが X を処理、触らないでください")
• プロンプト全体で共有ユーティリティを同一に記述して、ドリフトを防ぐ

---

並列エージェントのモニタリング

10以上のバックグラウンドエージェントを実行する場合:

1. 定期的にチェック -- コミットについてgit log --oneline -20
2. 出力ファイルを読む -- 進行状況についてエージェント出力ファイルをtail
3. 完了を追跡 -- SibylタスクまたはTodoWriteを使用
4. ギャップフィラーを派遣 -- 初期エージェントが完了するにつれて、欠落した作業を特定
5. 競合を処理 -- gitインデックスロックは予想されており、エージェントは自動的に再試行

ステータスレポートテンプレート

## エージェント・スウォーム・ステータス

**[N]エージェント派遣** | **[M]完了** | **[P]進行中**

### 完了:
- [エージェント説明] -- [主要結果]
- [エージェント説明] -- [主要結果]

### 進行中:
- [エージェント説明] -- [ステータス]

### 特定されたギャップ:
- [欠落した領域] -- フォローアップエージェント派遣

---

アンチパターン

アンチパターン	修正
同じファイルに触れるエージェントを派遣	ディレクトリ/モジュール別にパーティション; 1つの所有者スコープごと
独立した調査エージェントをフォアグラウンドで実行	バックグラウンド調査; 完了後に統合
"すべて修正"プロンプトで50エージェントを送信	各エージェントに特定のスコープ、問題リスト、完了シグナルを提供
ビルドスプリントのスカウトフェーズをスキップ	最初に探索して依存関係とファイル所有権をマッピング
すべての後期タスクで完全レビュー儀式を維持	パターンが安定を証明した後は信頼勾配を適用
エージェントにgit add .またはgit pushを実行させる	すべてのビルドプロンプトで明示的なgit衛生を実装
統合コードのバックグラウンドエージェントを派遣	バックグラウンドは調査用; コード変更を調整

Hyperskills統合

スキル	使用先	場合
brainstorm	Full Lifecycle	方向が開いているときの調査前
research	Research Swarm	決定前の知識収集
plan	Epic Parallel Build	スコープを依存性安全ウェーブに変換
implement	すべてのビルド戦略	実行ループと検証頻度
cross-model-review	すべての戦略	統合後の独立した品質ゲート
security	Multi-Dimensional Audit	セキュリティレビューレンズ
git	Epic Parallel Build	マルチエージェント・ステージング、リベース、リカバリー
dream	Full Lifecycle	大規模実行後の耐久性のある学習をキャプチャ

このスキルではないこと

• ホスト環境がそれを禁止する場合にエージェントを生成する許可ではありません。
• 計画の代替ではありません; オーケストレーションはタスクグラフを実行します。
• 1つのエージェントがより速く直接完了できる小さな変更には役立ちません。
• ファイル所有権を回避する方法ではありません; 重複編集はまだ順序付けが必要です。