なぜ1体のLLMでは限界があるのか
LLMに対して長い複合タスクを投げると、いくつかの問題が構造的に発生します。
コンテキスト汚染：会話が長くなるにつれ、初期の指示や前提条件が後半の出力に反映されにくくなります。LLMはトークン列を確率的に処理するため、文脈が長くなるほど初期情報の影響が希薄化します。
直列処理の限界：1体のエージェントは同時に複数の観点から情報を収集できません。「業界トレンド・競合・規制・海外事例」を同時に調べることができず、順番に処理するため観点が混ざりやすく、時間もかかります。
検証機能の欠如：出力を評価する役割が存在しないため、矛盾した情報や品質の低い出力がそのまま最終結果になります。自己評価を指示しても、同一モデルによるバイアスが入ります。
これらは「プロンプトを工夫すれば解決できる」問題ではなく、単一エージェント構成の構造的な限界です。
マルチエージェントの基本概念
マルチAIエージェントとは、役割を持った複数のLLMエージェントが連携して1つのタスクを達成する仕組みです。人間組織における「分業と品質管理」をAIで実現する設計思想と言えます。
重要な原則は関心の分離です。各エージェントは自分に割り当てられたタスクのみを処理し、全体を把握する必要がない。これによりコンテキストが短く保たれ、精度が安定します。
3層アーキテクチャ
実用的な構成として、以下の3層が基本になります。
Orchestrator（統括エージェント）
タスク全体を受け取り、サブタスクに分解して各Workerへ割り振る役割です。ここでの設計判断が全体の品質を左右します。
Orchestratorに求められるのは、タスク分解の粒度の判断です。細かすぎると管理コストが増え、粗すぎると各Workerの負荷が高くなりコンテキスト汚染が再発します。タスクの性質に応じた分解粒度の設計が重要です。
Worker（実行エージェント）
Orchestratorから割り当てられた個別タスクを実行します。複数のWorkerが並列で動作するため、処理速度と観点の独立性が確保されます。
各Workerはシステムプロンプトで役割を明示的に定義します。「あなたは競合分析の専門家です」という形でペルソナを固定することで、出力の一貫性が上がります。
Checker（検証エージェント）
全Workerの出力を受け取り、矛盾・欠落・品質の問題を検出して統合する役割です。同じLLMでも、「生成」ではなく「評価」という指示を与えることで異なる出力特性を引き出せます。
Checkerの設計で注意すべきは、評価基準を明示することです。「品質を確認してください」では曖昧すぎます。「以下の観点で矛盾を検出してください」と具体的な評価軸を与えることが精度に直結します。
エージェント間のデータ受け渡し
マルチエージェント設計で見落とされやすいのが、エージェント間でどのようにデータを受け渡すかという設計です。
基本的なパターンは2つあります。
逐次受け渡し（Sequential）：前のエージェントの出力をそのまま次のエージェントの入力にする。Orchestrator → Worker → Checkerという直線的な流れです。シンプルで実装しやすい反面、前段のエージェントが失敗すると後段に影響が連鎖します。
集約受け渡し（Aggregation）：複数のWorkerが並列で動き、全ての出力をCheckerが受け取って統合する。情報収集タスクのように、複数の独立した結果を最後にまとめる場合に適しています。
データの形式も重要です。エージェント間の受け渡しをJSONなどの構造化形式に統一することで、後段のエージェントが前段の出力を確実にパースできるようになります。自然文のまま渡すと、後段エージェントが解釈に余計なトークンを使い、意図しない読み取りが発生しやすくなります。
マルチエージェントが適さないケース
設計コストに見合わない場面があります。判断基準として以下を使っています。
単一ターンで完結するタスク：「この文章を要約して」「このコードのバグを直して」のように、1回のLLM呼び出しで十分な精度が出るタスクに対してマルチエージェントを使うのは過剰設計です。コストと複雑性が上がるだけで、精度は変わりません。
タスク間の依存関係が強いケース：各サブタスクが独立して処理できることがマルチエージェントの前提です。「Aの結果を見てからBを決める」という依存関係が強い場合、並列化できず、直列に動かすことになります。この場合は単一エージェントにチェーン構造で処理させる方がシンプルです。
レイテンシが最優先のケース：エージェント間の受け渡しとLLMの複数回呼び出しは、レスポンスタイムを増加させます。リアルタイム性が求められる用途には向いていません。
失敗パターンと設計上の注意点
実際に構築して遭遇しやすい失敗パターンをまとめます。
Orchestratorへの過負荷：タスク分解・割り振り・結果の受け取りに加えて、最終統合まで全部Orchestratorにやらせると、結局コンテキストが長くなります。OrchestratorはあくまでCoordinatorに徹し、統合はCheckerに委ねる設計にする方が安定します。
Workerのスコープ汚染：「競合分析担当のWorker」に「気になったら業界トレンドも調べて」という指示を入れると、関心の分離が崩れます。各Workerの指示は担当スコープに厳密に絞る必要があります。余計な情報を取りに行くほどコンテキストが汚染されます。
Checkerの評価基準の曖昧さ：「内容を確認してください」では機能しません。「以下の観点でWorkerの出力を評価してください：①矛盾する記述がないか ②情報ソースが明示されているか ③論点が問いに答えているか」のように、評価軸を構造化して渡すことが品質に直結します。
エラー伝播の未設計：あるWorkerがタスクに失敗したとき、その情報をCheckerやOrchestratorがどう扱うかを事前に設計しておかないと、エラーが静かに伝播して最終出力が壊れます。失敗したWorkerの出力を明示的にフラグ立てして、Checkerがそれを認識できるようにする設計が必要です。
プロンプト設計の考え方
各エージェントへの指示の切り方は、全体の品質に直接影響します。
役割・制約・出力形式の3点セットで渡す：「あなたは〇〇の専門家です（役割）。以下のスコープのみを扱ってください（制約）。結果はJSON形式で返してください（出力形式）」という構造が基本です。この3点が揃っていないと、出力が不安定になります。
ネガティブ制約を明示する：「〇〇はしないでください」という制約をシステムプロンプトに入れることで、スコープ汚染を防ぎやすくなります。特にWorkerには「担当外のテーマには触れないこと」を明示的に記述する方が安定します。
Orchestratorには判断軸を渡す：タスク分解の質はOrchestratorへの指示の質に依存します。「このタスクを適切な粒度のサブタスクに分解してください」という指示だけでは不十分で、「各サブタスクは独立して処理可能であること、1つのWorkerが扱える情報量に収まること」という判断軸をセットで渡すと分解の精度が上がります。
単一エージェントとの比較
| 観点 | 単一エージェント | マルチエージェント |
|---|---|---|
| コンテキスト長 | 長くなりやすい | 各エージェントで短く保てる |
| 処理方式 | 直列 | 並列化可能 |
| 品質確認 | なし | Checkerが担保 |
| 設計コスト | 低い | 高い |
| 適したタスク | 単純・短い処理 | 複合・長い処理 |
| エラー処理 | 単純 | 設計が必要 |
マルチエージェントは銀の弾丸ではありません。設計コストと複雑性が上がる分、それに見合うタスクに使う判断が重要です。複合的で長い処理、並列化できる独立したサブタスクがあり、品質の一貫性が求められる場面で本領を発揮します。
Nakano AI Labo（株式会社Anfini）