マルチエージェントアーキテクチャ：闇雲に分割すると逆効果になる

「エージェントを複数に分割すれば、もっと賢くなるのでは？」

よく聞かれる質問だが、答えは「場合による」だ。Anthropicの研究では、マルチエージェントシステムが単一エージェントを90%上回るケースが報告されている。ただし、それは適切なアーキテクチャを選んだ場合に限る。実際には、タスクの性質によってパフォーマンスの差は劇的に変わる。

ここでは、各パターンがどんな場面で真価を発揮するのか、3つの代表的なシナリオから見ていこう。

4つのパターンを俯瞰する

まず、マルチエージェントアーキテクチャの代表的な4パターンを整理しておく。

• Subagents（サブエージェント）：メインエージェントが専門エージェントをツールとして呼び出す。並列実行に強いが、すべての結果がメインエージェントを経由する必要がある
• Skills（スキル）：単一エージェントが必要に応じて専門プロンプトを動的にロードする。軽量だが、時間とともにコンテキストが蓄積していく
• Handoffs（ハンドオフ）：ステージごとにアクティブなエージェントを切り替える。逐次ワークフローに特化した設計で、並列実行はできない
• Router（ルーター）：クエリを分類し、並列にディスパッチし、結果を集約する。ステートレスなので会話コンテキストは保持されない

それぞれに得意・不得意がある。大事なのは「どれが最強か」ではなく、「どのタスクにどれが合うか」だ。

シナリオ1：単発リクエスト

「コーヒーを買ってきて」 - 単発のリクエストで、専門エージェントが buy_coffee ツールを呼び出す。

パフォーマンス：Subagents は4回の呼び出し。Skills・Handoffs・Router は3回。

ポイント：単発タスクには状態管理が不要だ。Skills、Handoffs、Router が最も効率的で、Subagents は余計なラウンドトリップが1回増える分、レイテンシが上乗せされる。

実務への示唆：FAQボット、シンプルなコマンド実行、一回限りの検索 - こういった用途に複数エージェントは過剰設計だ。単一エージェントで十分に対応できる。

シナリオ2：繰り返しリクエスト

「もう一杯コーヒーを」 - 同じリクエストが2回目。前回のコンテキストを引き継げるかどうかで差がつく。

パフォーマンス（2回目）：Subagents は4回 → 合計8回。Skills・Handoffs は2回 → 合計5回（40%削減）。Router は3回 → 合計6回（25%削減）。

ポイント：ステートフルなSkillsとHandoffsが圧倒的に有利だ。コンテキストを再利用し、ルーティングや初期化のステップを省略できる。一方、Subagents はステートレスなので毎回フルサイクルが走る。ただし、その代わりにコンテキストの分離が保たれるため、セキュリティ面では利点がある。

実務への示唆：チャットボット、会話型アシスタント、セッションベースのサービスなど、ユーザーとのやり取りが続く場面ではステートフルなパターンが必須だ。

シナリオ3：マルチドメインクエリ

「Python vs JavaScript vs Rust を比較して」 - 複数ドメインにまたがるクエリ。各言語のドキュメントが約2Kトークンずつ必要になる。

パフォーマンス：Subagents は5回の呼び出しで約9Kトークン。Skills は3回だが約15Kトークン。Handoffs は7回以上で約14K以上のトークン。Router は5回で約9Kトークン。

ポイント：並列実行できるパターン（SubagentsとRouter）が圧勝する。Skillsと比較してトークン消費量が67%少ない。コンテキストを分離できるかどうかが、トークンコストに直結する。

実務への示唆：リサーチシステム、マルチソース分析、エンタープライズのナレッジベース - こうした複数ソースを同時に扱う場面では、SubagentsかRouterを選ぶべきだ。

パターン選定ガイド

シナリオ	推奨パターン
単発タスク	単一エージェント
繰り返しの多いリクエスト	Skills または Handoffs
複数ドメインの同時処理	Subagents または Router
逐次ワークフロー	Handoffs

実践的なアドバイス

最初からマルチエージェントに手を出す必要はない。

まずは単一エージェントに、よく練られたプロンプトと明確に定義されたツールを組み合わせることから始める。マルチエージェントに移行するのは、単一エージェントで明確な限界にぶつかったときだけでいい。

ここで得られる教訓はシンプルだ。タスクに合ったアーキテクチャを選ぶこと。それだけで90%の改善が実現する。逆に言えば、アーキテクチャの選択を誤れば、分割すればするほどシステムは複雑になるだけで、賢くはならない。