マルチエージェントシステム: オーケストレーター + サブエージェントの実践
単体のAIエージェントは、狭いタスクをうまくこなします。シナリオが大きくなると - チケット、ドキュメント、コード、CRM、サポート - 「万能」な1体のエージェントは役割を混ぜ始め、コンテキストを膨らませ、一歩ごとにコストが上がります。マルチエージェントシステムは別のやり方です。オーケストレーターが目標を受け取り作業を調整し、サブエージェントが別々のツールと指示で狭い役割を実行します。以下では - 実務での仕組み、パターンが報われるタイミング、パイロットを殺す失敗についてまとめます。
- オーケストレーター - 計画、ルーティング、制限の制御、結果の組み立て
- サブエージェント - 狭い役割: 調査、コード、レビュー、執筆、CRM
- コンテキスト - 各エージェントは自分のステップに必要なものだけを受け取る
- コントロール - 重要なアクションでは human-in-the-loop
- スタート - 2-4の役割と測定可能な1シナリオであり、「エージェント動物園」ではない
- リスク - 無限ループ、ツールの競合、曖昧な責任分界
マルチエージェントシステムとは
マルチエージェントシステムとは、複数のAIエージェントがコーディネーターの下で共同してタスクを解くアーキテクチャです。あらゆるケース用の「太い」プロンプトを持つ1体のエージェントと違い、役割は分割されます。
| 役割 | やること | やらないこと |
|---|---|---|
| オーケストレーター | 目標を理解し、分解し、サブエージェントを呼び、回答を組み立てる | 必要なく他のツールに触らない |
| サブエージェント | 自前のツールで狭いサブタスクを実行する | プロジェクト全体を再計画しない |
| 人間 | リスクを承認する: 金銭、削除、公開、顧客メール | すべての tool call をマイクロマネジメントしない |
同じ発想はワークフロー自動化ですでになじみがあります。ディスパッチャーとワーカーがある点は同じです。違いは、ステップと分岐の一部を硬い if-then だけでなく LLM が選ぶことです。
なぜオーケストレーターとサブエージェントを分けるのか
すべてのAPIにアクセスできる1体のエージェントは便利に見えます - そしてすぐに問題になります。
- コンテキストが膨らむ。 1つのダイアログにログ、メール下書き、コード断片、CRMエクスポートが混ざり - モデルは焦点を失います。
- コストが増える。 「共有」チャットの余分なトークンは、毎ターン支払われます。
- 権限が広すぎる。 コードも書き顧客にメールも送るエージェントは、狭いワーカーより危険です。
- デバッグが難しくなる。 すべてが1つのループにあると、壊れたのが計画か、ツールか、文言かわかりません。
役割分離がもたらすもの:
- サブエージェントごとの狭いシステムプロンプト - 「役割外」幻覚が減る。
- 別々のツールセット - リサーチャーが誤ってCRMの案件を削除できない。
- 並列性 - 複数のサブエージェントが同時に動ける（検索 + 下書き + ファクトチェック）。
- 観測可能性 - ログで誰が、どんな入力で、どんな出力で呼ばれたかが見える。
基本設計: オーケストレーター + サブエージェントプール
実務向けの最小スケルトン:
User / trigger
│
▼
Orchestrator
(plan, routes, limits)
│
┌────┼────┬────────┐
▼ ▼ ▼ ▼
Research Coder Reviewer Writer
│ │ │ │
└────┴────┴────────┘
│
▼
Summary + artifacts
(+ human approval on risk)
オーケストレーターがやること
- 目標と制約を受け取る（時間、トークン予算、禁止事項）;
- どのサブエージェントを、どの順で呼ぶかを選ぶ;
- 生のチャット全体ではなく、各エージェントに圧縮したブリーフを渡す;
- ステップ上限を守り、ループを止める;
- ビジネスが求める形式で成果を組み立てる（レポート、diff、案件カード）。
オーケストレーターは「薄い」（ルーティングのみ）にも「厚い」（自ら計画・再計画する）にもできます。ビジネスでは、薄いオーケストレーター + 強い狭いサブエージェントがだいたい勝ちます。テストしやすく、制御コストも低いからです。
ビジネスと開発でよく見るサブエージェント
| サブエージェント | 仕事 | ツール（例） |
|---|---|---|
| Research | 事実、ドキュメント、競合を集める | search、RAG、browser、MCP |
| Analyst | 表、指標、結論 | SQL、Excel/Sheets、レポート倉庫 |
| Coder | パッチ、スクリプト、テスト | repo、terminal、CI |
| Reviewer | 品質とリスクのチェック | linters、チェックリスト、diff |
| Writer | メール、仕様、リリースノート、FAQ | テンプレート、ブランドボイス基盤 |
| CRM-agent | カード、タスク、ステータス | CRM API、webhooks |
| Ops | デプロイ、アラート、定型ランブック | SSH/API、監視（硬いガードレール付き） |
初日にすべての役割は不要です。パイロットに必要なのはだいたいオーケストレーター + 2-3のサブエージェントだけです。
パターンが実際に報われるとき
マルチエージェント設計が意味を持つのは、次のうち少なくとも2つが当てはまるときです。
- タスクが複合的（検索 + 要約 + アクションなど複数スキル）;
- システムへの異なるアクセス権が必要;
- コンテキスト量が多い - 1体では品質を落とさず「収まらない」;
- 著者の自己チェックではなく、別のレビュアーが必要;
- シナリオが繰り返し、役割ベースのパイプラインとして記述できる。
実務例
- サポート: オーケストレーター → Research（ナレッジベース/RAG） → Writer（返信） → 人間が送信を承認。
- リードとCRM: 資格審査 → エンリッチメント → CRMへ書き込み → マネージャーのタスク; 重要フィールドは人間またはルールで確認。
- 開発: Cursor / エージェントランタイムのオーケストレーター → explore サブエージェント → coder → reviewer; デプロイは承認後のみ。
- コンテンツとGEO: トピック調査 → writer → ファクトチェック サブエージェント → チェックリストで公開。
- オペレーション: 着信メールを解析 → 分類 → n8n/APIでアクション → 例外は人間へエスカレーション。
タスクが単純な if-then（「フォーム送信 → 案件作成」）なら、マルチエージェントは過剰です。ネイティブ自動化や n8nの方が適しています。
1日で役割を設計する方法
短い実務チェックリスト:
- ハッピーパスを紙に書く: 入力 → 3-6ステップ → 出力アーティファクト。
- 動詞で役割を名付ける: 「探す」「確認する」「書く」「CRMに書く」 - 「賢いエージェント #3」ではない。
- 各役割について固定する: 入力、出力（スキーマ/JSON）、ツール、禁止事項。
- 誰がオーケストレーションするか決める: LLMプランナーか、決定的グラフか（多くはハイブリッド: グラフ + ノード内のLLM）。
- エラーコストが高いところにhuman-in-the-loopを入れる。
- 停止条件を設定する: 最大ステップ、最大コスト、タイムアウト、「確信がなければエスカレート」。
「きれいなプロンプト」よりサブエージェント契約
良い契約の例:
- 入力:
{ task, constraints, sources[] } - 出力:
{ status, summary, artifacts[], confidence, needs_human } - 禁止: 「URLを捏造しない」「本番を変えない」「顧客に直接メールしない」
これでオーケストレーターは回答を確実にマージし、次に誰を呼ぶかを決められます。
うまくいくオーケストレーションパターン
| パターン | 仕組み | いつ使うか |
|---|---|---|
| Sequential pipeline | A → B → C | 安定したプロセス、分岐が少ない |
| Dispatcher | リクエスト種別に1体のサブエージェントを選ぶ | 着信リクエストの種類が多い |
| Parallel + merge | 複数の調査を走らせ、要約 | 複数ソースからの事実 |
| Debate / reviewer | 著者と批評者 | テキスト、コード、判断の品質 |
| Hierarchy | オーケストレーター → チームリード → ワーカー | サブプロジェクトのある大規模プログラム |
SMBでは、pipeline + dispatcherで十分なことが多いです。「エージェント討論」はデモでは映えますが、硬いトークン予算なしでは本番で高くつきます。
コントロール、セキュリティ、コスト
ガードレールのないマルチエージェントシステムは、すぐに高くつく混沌ボットになります。
最低限の必須事項:
- 役割ごとの別APIキーと権限（最小権限）。
- 制限: ステップ、トークン、並列度、タイムアウト。
- 冪等なアクション（リトライで案件が5件できてはいけない）。
- 監査ログ: 誰 → どんな入力 → どのツール → どの出力。
- シークレットはプロンプトの外へ: vault、env - 「システムメッセージにトークンを貼る」ではない。
- 不可逆アクションへの人間の承認: 支払い、削除、メール配信、本番デプロイ。
コストは「モデル料金」ではなくチェーン料金で数えます: オーケストレーター × Nサブエージェント呼び出し × リトライ。JSONをやり取りする弱い5回より、良いコンテキストの強い1回の方が安いこともあります。
よくある実装ミス
- 動くシナリオが1つもないのに、将来用に10体のサブエージェントを作る。
- 全員にすべてのツールへの同じアクセスを渡す。
- 短いブリーフではなく、オーケストレーターの完全ログをサブエージェントに渡す。
- ループを制限しない - オーケストレーターとレビュアーが永遠に議論する。
- マルチエージェント設計をプロセスの代替にする: 明確な Definition of Done がないと、システムは忙しいふりをするだけ。
- バイブコーディングと混同する: 役割と契約なしで「エージェントに任せよう」は技術的負債への道。
2-3週間のパイロットの始め方
- 測定可能なKPIのあるシナリオを1つ選ぶ（応答時間、エラー率、マネージャーの分数）。
- オーケストレーター + 2体のサブエージェントを組む（例: research + writer、または coder + reviewer）。
- 入出力契約と、人間へのエスカレーションチェックリストを凍結する。
- 実ケースを20-50件回し、失敗を種類別にラベル付けする。
- それから3つ目の役割や並列を足す。
ツールはエージェントフレームワーク（LangGraph、Crew系、IDEランタイム）、決定的エッジ用のn8nへの橋渡し、または自前のPythonで構いません。フレームワークのロゴより、役割アーキテクチャの方が重要です。
まとめ
オーケストレーター + サブエージェントは、タスクが1スキルより大きく、異なる権限・コンテキスト・品質チェックが必要なときの実用パターンです。強みはエージェントの数ではなく - 明確な役割、狭いツール、硬い停止条件です。小さなループと測定可能なシナリオから始めましょう。そうすれば、マルチエージェントシステムは高くつく自律の演出ではなく、スピードのレバーになります。
よくある質問
長いプロンプトの1体エージェントとマルチエージェントシステムの違いは？
長いプロンプトの1体エージェントは、1つのコンテキストと1つの権限セットで「何でも一度に」やろうとします。マルチエージェント設計は役割を分割します。オーケストレーターが調整し、サブエージェントが狭く実行します。制御しやすく、長いチェーンではトークンも安く、各ワーカーのアクセス面が小さいため安全です。
常にLLMオーケストレーターが必要？
いいえ。 多くの場合、ノード内にLLMがある決定的グラフ（ステートマシン / ワークフロー）の方が良いです。LLMオーケストレーターは、入力が非構造でルートを事前にハードコードできないときに報われます。本番ではハイブリッドが最も一般的です。
開始時の最適なサブエージェント数は？
だいたい2-4です。オーケストレーター1体に research と writer で、すでにコンテンツとサポートの動くループになります。開発なら coder と reviewer。役割を増やすのは、パイロットがKPIを安定して満たし、ログが読めるようになってからで十分です。
トークンでお金を燃やさずに済むには？
ブリーフを圧縮し、「ダイアログ全体を復唱する」を禁じ、安定したシステムプロンプトをキャッシュし、最大ステップを制限し、見せ物ではなく壁時計時間を減らすところだけ並列化する。きれいなデモ返信ではなく、エンドツーエンドシナリオのコストを測りましょう。
エージェントが「賢い」なら、まだ人間は必要？
はい、リスクがあるところでは。 モデルは金銭、個人データ、法的文言、本番への責任を取り除きません。Human-in-the-loop はアーキテクチャの弱点ではなく - ビジネスがエージェントを実システムに近づけるための条件です。