GoogleとMITの研究 — マルチエージェント導入で性能が70%低下する理由

구글·MIT 연구 — 멀티에이전트 도입하면 성능 70% 떨어지는 이유

GoogleとMITの研究 — マルチエージェント導入で性能が70%低下する理由

最近、AI開発者の間で複数のエージェントを複雑に組み合わせる「グラフエンジニアリング」が大きな人気を博しています。LangGraphのようなツールを使ってマルチエージェントシステムを構築すれば、どんな複雑な業務でも難なくこなしてくれるように思えますが、現実は少し異なります。最近、GoogleとMITの共同研究チームは、無計画にエージェントを増やす設計が、むしろ性能を最大70%も低下させる可能性があるという衝撃的な結果を発表しました。

GoogleとMITの警告 — 順次的な思考への「毒」

エージェントが多いほど複雑で難しい仕事もこなせそうに思えますが、実際はそうではありません。GoogleリサーチとMITメディアラボの共同研究チームが計180種類のエージェント構成を設計してテストした結果、設計方法によっては業務効率が極端に低下する可能性があるという事実が明らかになりました。

特にコーディングや緻密な企画のように、前の段階の結果が次の段階に影響を与える順次的な推論作業において、問題は深刻でした。独立した複数のエージェントが順に作業を引き継ぐ過程で、小さなミスが次の段階へと渡るうちに雪だるま式に膨れ上がってしまったからです。その結果、単一のエージェントを使用する場合と比べて、性能が最小39%から最大70%も低下しました。

一方で、データ収集や分散処理のように、相互干渉なしに独立して処理できる並列作業では正反対の結果が出ました。各エージェントに役割を分割して割り振り、結果を一箇所に集める中央統制型のグラフ構造を使用したところ、性能がなんと81%も向上しました。

結局のところ、マルチエージェントが常に正解というわけではありません。解決しようとする問題が、一歩ずつ慎重に進めるべきものなのか、それとも一度に展開して並列処理できるものなのかに合わせて構造を組む必要があります。

エージェントダイエット — 無駄な会話の削減

複雑にエージェントの数を増やして構造をややこしくする代わりに、単一エージェント内部の実行サイクルを精査する「ループエンジニアリング」が代替案として注目されています。エージェントを1つ賢く管理するだけでも、かなりの複雑なタスクをはるかに安定して終わらせることができるからです。

ここで重要な解決策として挙げられるのが「エージェントダイエット(AgentDiet)」という手法です。エージェントがツールを使用して動作する過程で蓄積される不必要な会話履歴や重複情報、期限切れのコンテキストデータをリアルタイムで削減(剪定)する仕組みです。複雑な仕事をする際、デスクの上に溜まった無意味な落書きや書類をその都度捨てることで集中力を維持するのと似ています。

実際の学術ベンチマークの結果によれば、この手法を適用することで、本来の性能を100%維持しながら、入力トークン使用量を39.9%から最大59.7%まで劇的に削減しました。おかげでトークン費用を節約できるだけでなく、コンテキストウィンドウが肥大化してエージェントが的外れな回答をしてしまうという慢性的な問題まで解決可能です。

状態管理と速度のトレードオフ — LangGraphのレイテンシ

多くの開発者がLangGraphを愛用するのは、強力な状態保存機能があるからです。複雑なマルチエージェント間で会話データや作業状態を失うことなく、慎重に管理してくれるためです。しかし、どんな便利さにも予期せぬ性能コストが伴うものです。

インフラのベンチマークデータを見ると、LangGraphの内部調整オーバーヘッドが、実際のサービス環境において無視できない遅延を引き起こしていることがわかりました。最も遅いケースを指すP95レイテンシ基準で、LangGraphは約16.8秒を記録したのに対し、Rustベースの高性能エージェントフレームワークであるAutoAgentsは約9.6秒に留まりました。

毎秒処理量(スループット)でも差は歴然としています。AutoAgentsは毎秒4.97件のリクエストを処理し、LangGraphの2.70件よりも約84%高い効率を示しました。LangGraph自体の基本的な動作オーバーヘッドはわずか数ミリ秒レベルで非常に軽量ですが、複数のエージェントの状態を毎回追跡・調整する過程が複雑に絡み合うと、システム全体が重くなってしまいます。

結局、誤った設計のマルチエージェントグラフは、サービス全体を巨大で低速にする「分散型モノリス」になりかねません。リアルタイムの応答速度が重要なサービスであれば、無計画に複雑なグラフ構造に固執するより、状態保存が不可欠なコアフローにのみLangGraphを限定的に活用するバランスが求められます。

いつグラフを描き、いつループを回すべきか

エージェントシステムを設計する際に覚えておくべき基準は明確です。解決しようとする作業の性質に合わせて構造を単純化することです。

最初の段階の結果が次の段階の入力となる順次的な推論作業では、単一エージェントのループを最適化するほうがはるかに優れています。一人の賢いエージェントが自ら問いかけ、答えを洗練させていくように入念に調整するほうが効率的です。

一方で、互いに完全に独立した下位業務を同時に実行し、最後に結果だけをまとめればよい並列型の作業であれば、マルチエージェントグラフの出番です。

複雑なシステム地図を描く前に、単一エージェントのループの効率を最大限に高めてみてはいかがでしょうか?時に、無駄のないシンプルな設計こそが、最も確実な成功の方程式です。