なぜ「3人のエージェント」には飲み水がないのでしょうか?科学者が失敗の14の理由を発見

2025年はエージェント爆発の年です。

大規模言語モデル (LLM) によって駆動されるエージェント システム、特にマルチエージェント システム (MAS) は、複雑で多段階のタスクを処理し、さまざまな環境とリアルタイムで対話する能力に基づいて、現実世界の問題を解決するのに非常に適していると考えられています。そのため、ソフトウェアエンジニアリング、創薬、科学シミュレーション、汎用エージェントシステムなど、さまざまな分野でますます使用されるようになっています。

ただし、シングルエージェント システムやさらに単純なベースラインと比較すると、マルチエージェント システムは、現実世界の問題を処理する際にエラーが発生しやすくなります。下の図に示すように、 AppWorldの失敗率は86.7%にも達することがあります。

図 | GPT-4o と Claude-3 を使用した 5 つの一般的なマルチエージェント LLM システムの故障率

これはなぜでしょうか?カリフォルニア大学バークレー校とイタリアのインテーザ・サンパオロ銀行の研究チームがその答えを出しています。

彼らは、マルチエージェントシステムが直面する課題について初の包括的な研究を実施し、 14の固有の障害モードを特定し、それを3つのカテゴリーに分類しました。(1)仕様とシステム設計の障害。 （２）エージェント間の不整合（３）タスクの検証と終了

「なぜマルチエージェント LLM システムは失敗するのか？」と題された関連研究論文が、プレプリント ウェブサイト arXiv で公開されています。

論文リンク: https://arxiv.org/abs/2503.13657

具体的には、彼らは、マルチエージェントシステムの障害を理解し、軽減するための構造化されたフレームワークを提供する、経験に基づいた最初のマルチエージェントシステムの障害分類法であるMASFTを提案しました。

同時に、新しいマルチエージェントシステムのパフォーマンスを分析し、障害モードを診断するためのスケーラブルな「LLM を審査員とする」評価パイプラインも開発しました。

さらに、エージェントの仕様、対話管理、検証戦略に関する介入研究も実施しました。タスク完了率は 14% 増加しましたが、マルチエージェントシステムの障害の問題を完全に解決することはできず、マルチエージェントシステムの構造的再設計の必要性が浮き彫りになりました。

さらに、彼らは以下の研究成果もオープンソース化しました。

150 を超える注釈付きマルチエージェント システムの会話トレース。

スケーラブルな LLM を審査員として評価するパイプラインと 150 を超える軌跡に対する LLM 注釈。

選択された 15 の軌跡に関する専門家による詳細な注釈。

最大14の故障モード

この研究では、研究チームは、事前に定義された仮説をテストするのではなく、経験的データから直接理論を構築する定性的な研究方法であるグラウンデッド・セオリーを使用し、有機的に発生する故障モードの特定を可能にしました。

彼らは、理論的サンプリング、オープンコーディング、継続的な比較分析、メモ、理論化を通じて、マルチエージェントシステムの実行トレースを繰り返し収集し、分析しました。マルチエージェントシステムのトレースの記録を取得し、予備的な調査結果について議論した後、観察された障害モードを収集して MASFT を導き出しました。

図｜マルチエージェントシステム手法フローの体系的研究

自動障害識別を実現するために、LLM ベースのアノテーターを開発し、その信頼性を検証しました。

次に、アノテーター間の合意調査を実施し、合意に達するまで定義を追加、削除、結合、分割、または変更して、障害モードと障害クラスを繰り返し調整しました。このプロセスは学習アプローチを反映しており、安定性が達成されるまで分類法が継続的に改良され、カッパ係数を使用して注釈者間の一致が測定されます。

図｜マルチエージェントシステムの故障モード分類法

最終的に、MASFT には、仕様とシステム設計の障害という 3 つの全体的な障害カテゴリが含まれます。エージェント間の不整合;タスクの検証と終了、マルチエージェントシステムが実行中に遭遇する可能性のある 14 の詳細な障害モードを識別します。

MASFT は、マルチエージェント システムの実行を実行前、実行中、実行後の 3 つのフェーズに分割し、各細分化された障害モードが発生する可能性があるマルチエージェント システムの実行フェーズを識別します。

図｜マルチエージェントシステムにおける故障カテゴリーの相関行列

さらに、研究者らは、マルチエージェントシステムは複雑な人間組織と同様の問題に直面しており、その障害モードは人間組織で観察される一般的な障害モードと一致していることを発見しました。 「説明を求めないこと」は「専門知識の尊重」を損ない、「エージェントの不一致」は階層的な区別を強化し、役割の割り当てを調整する必要性を反映しています。

マルチエージェントコラボレーションの有効性はまだ改善する必要がある

上記のすべての断層カテゴリに対して、研究チームは戦術的および構造的な戦略を提案しました。

戦術的な戦略には、プロンプトの改善、エージェント ネットワークのトポロジ、ダイアログ管理など、特定の障害モードを対象とした直接的な変更が含まれます。しかし、2 つのケーススタディは、これらのアプローチの有効性が一貫していないことを示しています。

構造戦略、つまりシステム全体に影響を及ぼすより総合的なアプローチ：強力な検証、強化された通信プロトコル、不確実性の定量化、メモリと状態の管理。これらの戦略には、より徹底した研究と慎重な実施が必要であり、今後も研究されるべきテーマとして残っています。

図｜マルチエージェントシステムの解決戦略と障害分類

研究チームは、これらの戦略的アプローチを 2 つのケーススタディに適用しました。

最初のケースでは、 AG2のMathChatシナリオ実装をベースラインとして使用しました。このシナリオでは、学生エージェントが、Python コードを実行して問題を解決できるアシスタント エージェントと連携します。

ベンチマークのために、GSM-Plus データセットから 200 個の演習をランダムに選択しました。最初の戦略は、元のプロンプトを改善して、明確な構造と検証専用の新しいセクションを追加することです。 2 番目の戦略は、エージェント構成を、3 つの異なる役割を持つより特殊なシステムに改良することです。問題解決者は、思考チェーン アプローチを使用してツールなしで問題を解決します。最終的な答えに到達するために Python コードを記述して実行するコーダー。検証者は議論をレビューし、解決策を批判的に評価して、回答を確認するか、さらなる議論を促します。

この場合、解決策が見つかったらバリデーターだけが会話を終了できます。

2 番目のケースでは、 ChatDev は、CEO、CTO、ソフトウェア エンジニア、監査人など、さまざまなエージェントが異なる役割を持ち、協力してソフトウェア生成タスクを解決しようとするマルチエージェント ソフトウェア会社をシミュレートします。

彼らは2つの異なる介入を実施しました。 1 つ目は、階層と役割の一貫性を強化するために、特定の役割のプロンプトを改善することです。 2 回目の試みでは、フレームワークのトポロジに根本的な変更が加えられ、フレームワークのストップ構造が有向非巡回グラフ (DAG) から巡回グラフに変更されました。

現在、プロセスは、CTO エージェントがすべてのレビューが適切に満たされたことを確認した場合にのみ終了し、無限ループを防ぐために最大反復期限が設定されています。このアプローチにより、反復的な改善とより包括的な品質保証が可能になります。

図 |各種ソリューションのパフォーマンス精度

研究チームは、「明白な」解決策の多くには実際には重大な限界があり、より一貫した改善を達成するには概説された構造的戦略が必要であると述べている。

現在のマルチエージェント調整における情報の冗長性と競合、およびコラボレーションにおけるモデルの偏差の増幅を考慮すると、将来のマルチエージェントシステムは、チームコラボレーションの有効性を向上させるために、迅速な応答、リアルタイム検証、および動的調整を実現する必要があります。

「LLM ベースのマルチエージェントは、分散型科学研究コラボレーションや緊急対応システムなどの分野で依然として一定の可能性を秘めています。」

著者: ユー・ケ