マルチエージェント化すると速くなる、は半分だけ正しい
AI エージェントを 1 体で回していると、どこかで限界が来ます。
- 調査と実装を同じコンテキストで回してノイズが増える
- 独立した作業なのに直列で処理して遅い
- 専門性の違う判断を 1 つのプロンプトに押し込んで精度が落ちる
- 生成結果の自己採点がなく、そのまま本番に流れる
この段階で「じゃあエージェントを増やそう」と考えるのは自然です。ただ、複数エージェント = 高度 ではありません。設計が雑だと、速くなるどころか、責任分界が曖昧になり、コストもログも増え、失敗原因が追えなくなります。
この記事では、実務でよく使うマルチエージェントオーケストレーションを 4 パターンに分けて整理します。
- Sequential（逐次）
- Concurrent（並列）
- Hierarchical（階層）
- Feedback Loop（自己修正）
Claude Code の subagents と OpenAI Agents SDK の manager / handoffs を補助線にしつつ、どの業務にどの型を当てるべきかまで判断できるようにします。MCP や権限境界を含む運用面は、先に公開した「MCP エンタープライズ運用ガイド」と合わせて読むと繋がります。
まず前提: 1エージェントで十分な仕事は多い
マルチエージェント化の前に、単一エージェントで十分なケースを切り分けるべきです。
Anthropic の Claude Code ドキュメントでも、subagent は「タスク固有の専門化」「独立コンテキスト」「ツール制限」が必要なときに効く一方、頻繁な往復や強い共有文脈が必要な作業は main conversation の方が向いていると整理されています。
私の基準はこうです。
単一エージェントで十分
- 仕様確認から実装まで文脈を切りたくない
- 作業量が小さい
- 途中で人間が細かく方向修正する
- 出力をすぐ目視レビューする
マルチエージェント化すべき
- 独立タスクを並列化したい
- 専門性ごとに役割を分けたい
- 大量ログや調査結果を main context に入れたくない
- 生成物に機械的な再評価を挟みたい
つまり、マルチエージェントは「高度だから採用する」のではなく、1 体で回すと遅い・汚れる・責任が曖昧になるときに使うものです。
パターン1: Sequential（逐次） — 最も壊れにくい基本形
Sequential は、一つ前の結果を次のエージェントに渡して順番に処理する型です。
例:
- 調査エージェントが論点を整理
- 設計エージェントがアウトラインを作成
- 実装エージェントがコードや原稿を作成
- 検証エージェントが差分や品質を確認
OpenAI Agents SDK の documentation でも、コードによるオーケストレーションとして「1つの出力を次の入力へ渡す chaining」が基本パターンとして挙げられています。Claude Code 側でも、subagents を sequence でつなぐ「Chain subagents」が明示されています。
向いている仕事
- 記事執筆
- PR レビュー
- 調査 → 実装 → テスト
- 障害切り分け → 修正 → 再現確認
強み
- デバッグしやすい
- 各段階の責任が明確
- 失敗点を途中で止めやすい
弱み
- 遅い
- 前段の質が悪いと後段が全部汚れる
- 逐次依存が強いので並列化しにくい
実務では、最初に採るべき既定値はこの型です。マルチエージェント導入を急ぐチームほど、いきなり並列や階層に行きがちですが、まず逐次で業務分解できるかを見た方が事故りません。
パターン2: Concurrent（並列） — 独立タスクだけに使う
Concurrent は、依存関係のない複数タスクを同時に走らせる型です。
Anthropic の subagents ドキュメントでも、独立した調査は「parallel research」で分けるとよいとされています。認証、DB、API のように対象が独立しているなら、別 subagent が同時に調べて、最後に親が統合する形です。
向いている仕事
- 複数モジュールの調査
- 複数競合サービスの比較
- API / DB / frontend の並行監査
- 複数記事候補の一次調査
強み
- 速い
- コンテキストが分離される
- 調査ノイズを main context に持ち込みにくい
弱み
- 独立していないタスクを並列化すると破綻する
- 戻り値の統合が雑だと重複や矛盾が出る
- 並列数を増やしすぎると、コストと要約負荷が跳ねる
ここで重要なのは、並列にできるのは「依存のない仕事」だけという点です。Claude Code の docs でも、各 subagent が詳細な結果を返しすぎると、結局 main conversation の context を消費すると注意されています。速くしたくて並列化したのに、統合フェーズで詰まるなら逆効果です。
私なら、並列で回すのは次の条件を満たすときだけにします。
- 入力が共通でも、作業領域が分かれている
- 途中の相互相談がいらない
- 出力フォーマットを先に固定できる
パターン3: Hierarchical（階層） — Manager が最終責任を持つ型
Hierarchical は、上位の manager / triage agent が下位の specialist を呼び分ける型です。
OpenAI Agents SDK では、代表的な構成として次の 2 つが整理されています。
- Manager（agents as tools）
- Handoffs
Manager は親が会話の主導権を持ち続け、specialist を tool として使います。Handoffs は振り分け後に specialist が会話を引き継ぎます。
向いている仕事
- 問い合わせの一次振り分け
- AI オペレーションデスク
- 開発支援チャットの triage
- 役割別の業務受付
強み
- ルーティング責任を 1 箇所に集約できる
- ガードレールやレート制御を manager に置ける
- specialist を差し替えやすい
弱み
- 親の設計が悪いと全体が悪化する
- handoff 型は責任境界が見えにくくなりやすい
- nested delegation を増やすと追跡困難になる
実務では、ユーザーに見える窓口を 1 つに保ちたいなら manager 型が扱いやすいです。逆に、専門家に会話ごと引き渡したいなら handoff 型が向きます。
ただし、Claude Code の subagents には「subagents cannot spawn other subagents」という制約があります。つまり、1 セッション内で深い階層をネストする設計には向きません。Claude Code で長く並列・階層を回したいなら、docs にある通り agent teams の方が適しています。
パターン4: Feedback Loop（自己修正） — 品質を上げるが、止めどころが重要
Feedback Loop は、生成エージェントと評価エージェントを組み合わせ、合格するまで繰り返す型です。
OpenAI の Agent orchestration ガイドでは、while ループで「実行する agent」と「評価する agent」を回し、評価が通るまで改善する型が明示されています。これはコード、記事、要約、分類、抽出タスクでかなり強いです。
向いている仕事
- テスト付きコード生成
- 記事や提案書の下書き改善
- structured output の整形
- ガイドライン準拠チェック
強み
- 単発より品質が上がりやすい
- 合格基準を明示できる
- 人間レビュー前の粗いミスを減らせる
弱み
- ループが止まらない
- 評価者の質が低いと誤った最適化をする
- コストが読みにくい
この型で一番大事なのは、終了条件をコードで持つことです。
- 最大反復回数
- 評価スコア閾値
- 必須チェック項目
- 人間にエスカレーションする条件
ここを曖昧にすると、永遠に自己批評して終わらないワークフローになります。
4パターンの使い分け早見表
| パターン | 速さ | 安定性 | 向く用途 |
|---|---|---|---|
| Sequential | 低〜中 | 高 | 執筆、レビュー、実装フロー |
| Concurrent | 高 | 中 | 独立調査、横断監査 |
| Hierarchical | 中 | 中 | 受付、振り分け、窓口統合 |
| Feedback Loop | 低 | 中〜高 | 品質改善、評価ゲート |
私のおすすめは、Sequential を既定値にして、必要に応じて Concurrent と Feedback Loop を足し、最後に Hierarchical を検討する順番です。いきなり manager を立てて全部自動化しようとすると、たいてい観測不能になります。
本番運用で見るべき指標
マルチエージェント設計は、動いた時点では成功に見えます。問題は運用 1 週間後です。見るべきは次です。
- 1 タスクあたりの総レイテンシ
- エージェントごとの失敗率
- handoff / delegation の回数
- 人間エスカレーション率
- トークン消費とコスト
- 同じ失敗の再発回数
特に Hierarchical と Feedback Loop は、ログ設計が弱いと何が起きたか分からなくなります。MCP や社内ツールまで絡むなら、権限境界と監査を先に決めておくべきです。この点は「MCP エンタープライズ運用ガイド」の前提そのものです。
また、オーケストレーションをうまく回すには、個々のエージェント性能より ハーネス側の設計 が効きます。役割分担、権限制限、出力フォーマット、評価基準まで含めて設計する考え方は、「Harness Engineering とは？」で詳しく整理しています。
まとめ
マルチエージェントオーケストレーションは、「複数に分ければ賢くなる」話ではありません。依存関係、責任境界、終了条件を設計する話です。
実務では、次の順番で考えるとぶれにくいです。
- まず単一エージェントで足りるか確認する
- 順番に渡すだけなら Sequential
- 独立タスクなら Concurrent
- 窓口統合が必要なら Hierarchical
- 品質を上げたいなら Feedback Loop
この順番を飛ばして最初から複雑化すると、速くなる前に壊れます。逆に、4 パターンを明示的に使い分けるだけで、AI ワークフロー設計はかなり安定します。
一次情報としては、Anthropic の Claude Code subagents docs と、OpenAI Agents SDK の Agent orchestration guide が特に参考になります。