11月1日、TechRadarが「Scaling smart: How LLM developers are solving multi-agent orchestration bottlenecks」と題した記事を公開した。マルチエージェントシステムの開発において生じるトークンコスト爆発・カスケードエラー・状態同期エラーといったボトルネックと、その実践的な解決策について詳しく紹介されている。
パラメータスケーリングの限界と、次の戦場「マルチエージェント」
LLMの性能改善手法として長らく主流だったパラメータ数の増加は、収穫逓減が顕著になりつつある。そこで注目されているのがマルチエージェント協調だ。複数のAIエージェントが役割分担しながら連携するアーキテクチャで、たとえばコードを書くエージェントと、そのコードを検証するエージェントが並走するような構成を指す。
しかしエージェント数が増えると、問題は掛け算で複雑化する。記事によれば、エージェント数をnとすると、協調の複雑度はn²のオーダーで増加する。3エージェントで9倍、5エージェントで25倍だ。マルチエージェントシステムの障害原因の36.9%が協調のミスアライメントによるものというデータも示されている（いずれも元記事中で引用されている数値）。
最大の問題：トークンコストの爆発とカスケードエラー
トークン爆発
マルチエージェント構成では、エージェント間で会話履歴をそのまま受け渡す設計になりがちで、トークン消費が指数的に膨らむ。記事ではAmazonの事例が具体的に挙げられている。書籍データベースの著者情報マッピングを自動化するプロジェクトで、あるソフトウェア開発チームが予期せず180万ドル（約2.7億円）のトークンコストを計上した。Amazon社内のエンジニアすら「AIにかかるコストを把握するのは非常に難しい」と認めており、世界最大のクラウドプロバイダーでさえこの状況だ。また、名前は伏せられているが、トークン上限を設定しなかった大企業がClaude AIで月5億ドルの請求を受けたという話も紹介されている（元記事に明記されている数値であり、桁の大きさは原文の記述に基づく）。
コスト爆発への対策として、記事は主に三つのアプローチを挙げている。まずコード駆動のステートマシンへの移行だ。エージェントが自由に次の発言者を決めるモデル駆動型ではなく、「条件XならエージェントAが発言する」という決定論的なフローにすることで、発言権の調整に使われる余分なトークンを排除できる。次にトークン上限とタイムアウト回路の明示的な設定、そして厳格な逐次ハンドオフの実装によってエージェント間の自由なチャットを制限することだ。これらは地味に見えるが、設計フェーズで盛り込んでおくかどうかで、Amazonの事例のような事態を防げるかどうかが変わってくる。
カスケードエラーとハリュシネーションの伝播
マルチエージェント構成でより深刻なのが、あるエージェントが生成したハリュシネーションが下流エージェントに「事実」として伝播する問題だ。エージェント間のハンドオフを経るたびに情報に権威性が付与されていくため、最終的なアウトプットは確からしく見えてしまう。上流エージェントが幻覚したデータを共有DBに書き込み、複数の下流エージェントがそれを読み込んで誤りを複合させる、というシナリオが典型例として挙げられている。
この問題への対処は多層的になる。Model Context Protocol（MCP）やLangGraphといったフレームワークを用いて厳格な実行パスを定義し、無制限ループを排除することが出発点となる。加えて、エージェントの役割を「生データ取得専用」「推論専用」「データ生成専用」のように明確に分離し、LLMが集約する前に独立した検証エージェントがクレームに異議を唱える仕組みを挿入することが推奨されている。厳格なJSONスキーマ・リトライ予算・API型チェックの設定と、全プロンプト・エージェント呼び出し・ハンドオフのログ記録もカスケードエラー発生時の原因追跡に不可欠だ。
見落とされがちな問題：共有状態とキャッシュ無効化
キャッシュはコスト削減と高速化のために広く使われるが、マルチエージェント環境ではキャッシュ管理が一段と難しくなる。共有システムプロンプトにわずかな変更を加えるだけで、全エージェントのキャッシュが同時に無効化される。またエージェント間でコンテキストをシリアライズして渡す際にプロンプトの順序が変わると、キャッシュがリセットされる。
記事が示す対策は三点だ。まずプロンプトの静的コンテンツを先頭に、動的コンテンツを末尾に配置すること（先頭のトークンが変わるとキャッシュ全体が無効化されるため、この順序が重要になる）。次にAgent Step Graphでプロンプト実行順を追跡し、将来のエージェント起動タイミングに基づいてキャッシュを退避すること。そして、ユーザーの探索的なクエリ（毎回内容が異なるもの）ではキャッシュを使わず、定型クエリに絞ってキャッシュを適用することだ。
汎用的な緩和戦略
記事後半では、特定のボトルネックに限らず全般的に有効な設計指針も挙げられている。
- エージェント数を最小限に保つ：「8エージェントでできることが5でできるなら5にする」というシンプルな原則。複雑性とヒューマン監視コストをともに下げる
- タスクとファイルアクセスを分離する：顧客メール読み取り専用のエージェントにDBスキーマ変更権限を与えない、といった最小権限設計。複数エージェントが同一ファイルを同時編集して競合するリスクを下げる
- 階層的な監視構造：中央エージェントが全ログを集約・要約し、開発者はこの中央エージェントを主に監視する。5エージェントを並列監視するより、認知負荷が大幅に減る
これらの指針は実装コストが低い割に効果が大きく、マルチエージェントシステムの設計初期段階から意識しておく価値がある。
詳細はScaling smart: How LLM developers are solving multi-agent orchestration bottlenecksを参照していただきたい。
