# サブエージェント・オーケストレーションの設計パターン——プランナー／エグゼキューター分離と委譲設計

> マルチエージェント構成でサブエージェントを分割・連携させる4つのオーケストレーションパターンと、コンテキスト引き継ぎ・最小権限・反復制限の委譲設計を解説します。

- Canonical: https://kuucorp.com/blog/subagent-orchestration-design-patterns/
- Date: 2026-05-29
- Last modified: 2026-05-29
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
AIエージェントをスケールさせようとしたとき、「オーケストレーターに全責任を集中させる」設計は急速に破綻します。プロンプトが肥大化し、ツール呼び出しが干渉し合い、1本のエージェントが本来持つべきでない文脈を抱え込む。サブエージェントへの分割は解決策ですが、**どう分割し、どう連携させるか**の設計判断を誤ると、遅延・コスト爆発・制御不能という別の問題を生みます。

## サブエージェントを分割・連携させる設計の全体像

> サブエージェント設計は責任を独立した実行単位に分解する構造で、4パターンの使い分けが設計の出発点です。

[エージェントガバナンス](/glossary/agent-governance/)の文脈で「マルチエージェント」とは、あるエージェントが別のエージェントを呼び出す構成を指します。Microsoft Azure Architecture CenterのAIエージェント設計ガイドは、設計の複雑さを「直接モデル呼び出し → ツール付き単一エージェント → マルチエージェントオーケストレーション」の3段階に分類しています。マルチエージェントへ踏み込む判断基準は「単一エージェントがプロンプトやツールの過負荷なく確実に動作できなくなったとき」です。単一エージェントで解決できる問題にマルチエージェントを適用するとオーバーヘッドが無意味に膨らむため、この原則は設計の大前提になります。

分割がもたらす利点は4点あります。①各エージェントのコード・プロンプト複雑さを削減できる専門化、②システム全体を再設計せず追加・変更できるスケーラビリティ、③個別テスト・デバッグが容易な保守性、④タスクごとに最適なモデルを割り当てられるコスト最適化です。ただしオーケストレーション調整のオーバーヘッド・遅延・障害モードが増加するため、複雑さに見合うメリットがあるかを設計時に常に問い直す必要があります。

本記事は[AIエージェントガバナンス](/ai-governance/)のピラーコンテンツに連動しています。[エージェントハーネスの全体像](/blog/agent-harness-architecture/)も合わせて参照してください。

## 4つのオーケストレーション・パターンと使い分け

> 4つのオーケストレーションパターンが実践標準で、タスクの依存関係・並列性・事前知識量によって使い分けを決定します。

### 1. シーケンシャル（直列パイプライン）

定義済みの線形順序でエージェントをつなぎ、前エージェントの出力を次エージェントが処理するパターンです。「ドラフト → レビュー → 完成」のように明確な依存関係があるワークフローに適します。各段階が前段の結果に基づくため、初期段階のエラーが後段まで伝播するリスクがあります。各ステージの出力に品質ゲート（バリデーション）を設け、低品質な中間結果がパイプラインを通過しないよう設計します。バックトラッキングや動的ルーティングが必要なワークフローには不向きです。

### 2. コンカレント（並列ファンアウト）

同一の入力を複数の専門エージェントに同時に処理させ、結果を集約するパターンです（スキャッター・ギャザー、マップ・リデュースとも呼ばれます）。異なる視点の並行分析による待機時間の短縮が主な利点です。各エージェントは互いの結果を受け渡しません。集約戦略（多数決・加重マージ・LLM合成）を事前に定義しておくことが運用安定の鍵で、矛盾する結果への対処方針も明示します。エージェント間で可変状態を共有するとデータ整合性が壊れるため、各エージェントは独立した状態で動作させます。

### 3. プランナー／エグゼキューター分離

プランナーエージェントが包括的な実行計画を立案し、エグゼキューターが各ステップを実行するパターンです（Plan-then-Execute）。Anthropicが提示するオーケストレーター・ワーカー構造の典型形で、サブタスクを事前定義せず入力に応じて動的に決定できます。プランニングには高度な推論が必要ですが、エグゼキューターは個々のステップに特化できるため軽量なモデルで代替でき、コスト最適化にも有効です。事前にソリューションパスが不明な複雑な問題に適します。

### 4. ハンドオフ（動的委譲）

最初のエージェントがタスクを評価し、自分の能力限界を認識したら適切な専門エージェントへ制御を渡すパターンです。処理中に専門知識の要件が出現する場合や、タスクに最適なエージェントが事前に特定できない場合に使います。1度に1つのエージェントだけがアクティブになり、完全な制御を次のエージェントへ転送します。無限ループを防ぐためにハンドオフ回数の上限を必ず設定し、上限到達時の人間エスカレーション経路を定義します。

## 委譲設計の3つの判断軸

> 委譲設計の核心は「何をどこまで渡すか」の3軸——コンテキストの粒度・権限スコープ・反復上限——の明示的な決定です。

### コンテキスト引き継ぎの粒度

サブエージェントに渡すコンテキストは必要最小限に絞ります。前エージェントの生出力をすべて渡すと、コンテキストウィンドウが急速に拡大してコストと応答品質の両方を悪化させます。多くのケースでは生の全文ではなく**要約または構造化した中間結果**を渡す設計が適切です。長時間タスクでは外部ストアに中間状態を永続化し、障害後にコンテキストを再構築できるようにします。

### 最小権限の原則

[AIエージェントの権限管理設計](/blog/ai-agent-permission-management-design/)と同様に、各サブエージェントにはそのタスクに必要な最小限の権限のみを付与します。エージェント間通信には認証を実装し、ユーザーがアクセスできないデータをサブエージェントが返さないようにセキュリティトリミングを全エージェントに適用します。

### 反復上限と失敗設計

プランナー分離型やハンドオフ型では、エージェントが無限ループに陥るリスクがあります。各オーケストレーションにイテレーション上限を設け、上限到達時のフォールバック（人間エスカレーション、最善結果での打ち切り）を事前定義します。障害は隠蔽せず上流に伝播させ、ダウンストリームのエージェントが適切にハンドリングできる設計にします。

### 規模別の留意点（SMB / エンタープライズ）

**SMBの場合**: まず単一エージェント＋ツールで解決できないかを確認し、シーケンシャルパターンから始めるのが現実的です。Kuuの[AIエージェント運用管理サービス](/services/ai-ops/)では、適切な分割設計の判断を含めた伴走支援を提供しています。

**エンタープライズの場合**: 複数チームが使うエージェント基盤では、IAM/SCIMと連動した権限スコープ設計、LLMゲートウェイによるモデルルーティング、部門別トークンコスト配賦が必要です。大規模マルチエージェント基盤の設計・実装は[RDEサービス](/services/rde/)で支援しています。

## 参考

- [AI エージェント オーケストレーション パターン（Microsoft Azure Architecture Center）](https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
- [Building Effective Agents（Anthropic Engineering）](https://www.anthropic.com/engineering/building-effective-agents)

## まとめ

サブエージェントのオーケストレーション設計は「どのパターンを選ぶか」だけでなく、コンテキストの粒度・権限スコープ・反復上限という委譲設計の3軸を明示的に決定することで完結します。シーケンシャル → コンカレント → プランナー分離の順に複雑さを上げ、必要最小限のパターンから着手することが安定した本番運用への最短経路です。

マルチエージェント構成の設計・運用について相談したい場合は、Kuuの[AIエージェント運用管理サービス](/services/ai-ops/)にお問い合わせください。