[論文解読] なぜマルチエージェントシステムはしくじるのか？Why Do Multi-Agent LLM Systems Fail?

Posted at 2025-03-31

今回は、マルチエージェントシステムがどこで失敗するのかを体系的に調査した論文をご紹介します。
近い将来において、マルチエージェントシステムを開発する際のガイドラインになるのではないかと思うほど、失敗の原因について整理されていたのが印象的です。

全体概要

この論文は、大規模言語モデル(LLM)を用いたエージェント同士の協調的なシステム、すなわち「マルチエージェントシステム(Multi-Agent System; MAS)」に焦点を当てています。近年、複数のLLMエージェント同士が連携しあうことで複雑なタスクを解く手法に注目が集まっていますが、実際には単一エージェントに比べて大きな性能向上が得られていない現状があります。そこで著者らは、

なぜマルチエージェントシステム(MAS)は失敗するのか
どのような「失敗モード(typical failure modes)」があるのか
失敗を回避するためにはどんなことに気をつければよいのか

という研究課題に取り組んでいます。

論文の大きな貢献は、複数の既存MASフレームワークから実際の対話ログ(エージェント同士のやりとり)を大規模に収集・分析し、そこで確認された失敗パターンを 「MASFT (Multi-Agent System Failure Taxonomy)」 として体系化したことです。さらに、その失敗パターンがどういった場面で起こりやすいかを示し、いくつかの対処方法を試験的に導入した実験例を提示している点が特徴です。

第１章はじめに (Introduction)

論文冒頭では、

背景: 大規模言語モデル(LLM)が道具ツール呼び出しや高度な推論をできるようになり、「エージェント(Agent)」的な動作が注目されていること
問題: そういったエージェントを複数繋げたマルチエージェントシステム(MAS)も数多く提案されているが、実際にベンチマークを行うと、単一のエージェントを繰り返し呼び出すだけの方法を超える性能が出ない場合が多い
本研究の目的: その理由を徹底的に調べるために、既存のMASフレームワークを集め、実行ログ(対話ログ)を詳細に解析し、失敗の原因を体系化する

という流れが示されます。ここでは「なぜ失敗が多発するのか」がまだ十分に研究されておらず、多くの研究はマルチエージェントの“新しいフレームワーク構築”に注力しているが、失敗モードの網羅的・体系的な解析例は少ないと指摘しています。

第2章関連研究：マルチエージェントシステムの課題と高信頼性への道筋

この章では、マルチエージェントLLMシステムにおける失敗モードの研究に不可欠な背景となる、既存の関連研究について掘り下げていきます。
単一LLMエージェントにおける課題から出発し、マルチエージェントシステム特有の複雑性、そして人間社会における高信頼組織（HRO）の研究に至るまで、幅広い領域を概観します。
そして、既存研究がどこまで到達し、そして何が未解決の課題として残されているのかを明らかにしています。特に、マルチエージェント環境における 「システムとしての失敗」 を体系的に理解することの重要性と、本研究がそのギャップをどのように埋めようとしているのかを明確に位置づけようとしています。

2.1 シングルエージェント研究の潮流とその限界

近年、大規模言語モデル（LLM）を活用した自律型エージェントは、目覚ましい発展を遂げています。
例えば、ReAct フレームワークに見られるような、思考（Reasoning）と行動（Acting）を交互に繰り返す手法や、Chain-of-Thought (CoT) プロンプティングに代表される段階的な推論プロセスは、単一のエージェントが複雑なタスクをより効果的に遂行するための基盤技術として確立されつつあります。これらの研究は、LLMが持つ推論能力や言語生成能力を最大限に引き出すことに焦点を当ててきました。

しかしながら、これらのエージェントが単体で動作する際には、依然として克服すべき課題が存在します。その代表例が、LLM特有の幻覚（Hallucination）、すなわち事実に基づかない情報を生成してしまう問題や、計算間違い、あるいは論理的な破綻です。これら単一エージェントにおける失敗モードや、生成される文章の品質を評価するための手法については、既に多くの研究が蓄積されています。

ただし、重要な点として、これらの研究で扱われている問題は、あくまで 「単一LLMエージェント」の内部的な挙動や性能に起因するものが中心です。複数のエージェントが協調して動作する マルチエージェントシステム（Multi-Agent System, MAS） においては、個々のエージェントの能力だけでなく、エージェント間の相互作用に起因する、より複雑で新たな失敗モードが出現する可能性があります。既存のシングルエージェント研究は、このようなマルチエージェント特有の課題に対して、必ずしも十分な光を当てているとは言えません。

2.2 マルチエージェントシステムの登場と新たな課題

シングルエージェントの限界を超える試みとして、複数のエージェントがそれぞれの専門性を活かし、協調してタスクに取り組むマルチエージェントシステムの研究が活発化しています。例えば、ChatDev、MetaGPT、AG2 (AutoGen)、HyperAgentといったプロジェクトは、特にソフトウェア開発のような複雑なタスクにおいて、タスクの分割、役割分担、そしてエージェント間のコミュニケーションを通じて、より高度な問題解決を目指しています。これらのシステムは、複数の「仮想的な専門家」がチームを組んでプロジェクトを進める様子を模倣しており、大きな可能性を秘めていると言えるでしょう。

しかし、これらの先進的な試みにおいても、一つの大きな課題が残されています。それは、システムが実際にどのように動作し、どのようなプロセスを経て最終的な成果物に至るのか、その詳細な動作ログ（Trace）をどのように評価し、潜在的な失敗要因を体系的に洗い出すか？ という点に関するまとまった知見が不足していることです。

既存研究の中には、個別の課題に対する解決策を提示するものも存在します。例えば、Agent Workflow Memory のような研究は、単一エージェントが非常に長いコンテキスト（対話履歴やタスク情報）を効率的に処理するためのメモリ管理機構に焦点を当てています。
また、StateFlow や DSPy のようなフレームワークは、エージェント内部の状態遷移や、タスク間の制御フローをより洗練させることで、単一エージェントのタスク遂行能力の堅牢性を高めようとしています。

これらの研究は確かに重要ですが、著者らが指摘するように、多くは「特定の問題領域（メモリ拡張、タスク分割、状態管理など）に対する部分的なソリューション開発」に偏る傾向があります。その結果として、複数のエージェントが相互作用するシステム全体として、どのような根本的な課題が存在し、どのような失敗が起こりうるのかという、より包括的な視点からの分析は、未だ十分に進んでいないのが現状です。
すなわち、 マルチエージェントシステムならではの協調やコミュニケーションに起因する失敗パターン については、体系的な検証例が依然として少ないのです。

2.3 マルチエージェントシステムの設計原則：複雑性との戦い

マルチエージェントシステムを効果的に構築・運用するためには、単に強力なLLMを用いるだけでは不十分であり、システム全体の 設計原則（Design Principles） が極めて重要になります。この点に関して、いくつかの興味深い指摘がなされています。

例えば、Anthropic 社のブログ記事などでは、エージェントシステムの構成が過度に複雑化すると、予期せぬ問題が発生しやすく、システム全体が破綻するリスクが高まる、という経験則が示唆されています。この考えに基づき、モジュール化されたシンプルな設計、すなわち、各エージェントの役割や責務が明確で、相互のインターフェースが整理されている構成が推奨されています。

同様に、Kapoor ら (2024) の研究においても、タスク達成のために多層的で複雑なフレームワークを構築した場合、管理やデバッグにかかるオーバーヘッドが増大し、実運用において問題が生じやすいことが報告されています。

これらの知見は、設計段階における意図せぬ複雑化が、マルチエージェントシステムの信頼性を損なう大きなリスク要因であることを示唆しています。

では、どのようにしてエージェント間の連携を設計すればよいのでしょうか？マルチエージェントシステムを成功に導くためには、個々のAIモデルの能力向上だけでなく、以下のような 組織論的なアプローチ が重要であると、いくつかの研究で提言されています。

役割分担の明確化:
各エージェントが担当するタスク領域、アクセス可能な情報、そして意思決定における権限の範囲を厳密に定義することが求められます。これにより、責任の所在が曖昧になったり、エージェント間で不要な干渉が発生したりするのを防ぎます。
コミュニケーションプロトコルの定義:
エージェント間の情報交換を、自由形式の自然言語だけに頼ると、意図の誤解や情報の欠落といった曖昧さが生じる可能性があります。これを避けるために、特定のタスクや情報交換の場面においては、構造化されたデータフォーマットや、事前に定義されたメッセージングプロトコルを用いることで、齟齬のないスムーズな情報共有を実現することが考えられます。
検証工程の導入:
システムが最終的な結論や成果物を生成する際に、単一のエージェントの判断に依存するのではなく、複数のエージェントによるクロスチェックや、検証を専門とするVerifier エージェントを導入するなど、多角的な視点での検証プロセスを組み込むことが有効です。

しかしながらこれらのアイデアは、現時点では部分的かつ概念的な提案に留まっていることが多い 、と本論文の著者らは指摘しています。すなわち、これらの設計原則が実際にどのような種類の失敗を防ぐのに有効なのか、あるいは、どのような失敗が依然として発生しやすいのかについて、具体的な失敗事例に基づいた網羅的な分析や定量的な評価は、まだ十分に行われていないのが実情です。

2.4 LLMシステムにおける失敗の分類：シングルからマルチへ

LLMシステムが抱える潜在的な問題点を理解し、対策を講じるためには、発生しうる 失敗モード（Failure Modes） を体系的に分類し、整理する タクソノミー（Taxonomy） の構築が不可欠です。

近年、LLMに固有の失敗、特に 幻覚（Hallucination） 、 論理的な矛盾 、 バイアスや公平性（Fairness） の問題などについて、その発生メカニズムや影響を分析し、分類しようとする研究が盛んに行われています。これらの研究は、LLMの信頼性や安全性を向上させる上で重要な基盤となっています。

しかし、これらの既存の失敗分類研究の多くは、基本的に 「シングルエージェント」の文脈 、すなわち 一回の推論（Inference）や、単一エージェントとユーザー（またはプロンプト）との間のインタラクションにおける応答 を分析対象としています。

マルチエージェントシステムに目を向けると、状況はさらに複雑になります。著者らは、少数ながらもマルチエージェント環境における失敗要因に部分的に言及した研究が存在することも認めています。例えば、Bansal ら (2024) の研究では、人間とAIエージェントが協働するシステムにおける課題が列挙されており、特に人間とエージェント間の 信頼（Trust）の構築 や、 インタラクションの複雑性 が重要な論点として指摘されています。

それでもなお、多くの研究はシングルエージェントにおける問題点の延長線上で議論される傾向があり、 「複数のエージェントが継続的な対話を通じて協力しながらタスクを進める過程で、具体的にどのような相互作用に起因する問題が発生するのか」 という核心的な問いに対する深掘りは、依然として十分とは言えません。例えば、エージェント間で情報が正しく伝達されない、あるエージェントの誤った判断が他のエージェントに波及してしまう、といった マルチエージェント特有のダイナミクスに起因する失敗 については、体系的な分析が不足しているのです。

2.5 高信頼組織（HRO）理論からの洞察：人間の知恵をAIシステムへ

ここで、全く異なる分野の研究、すなわち 高信頼組織（High-Reliability Organization, HRO） の理論に目を向けてみましょう。HRO理論は、原子力発電所、航空管制、空母のフライトデッキ運用といった、わずかなミスが致命的な結果を招きかねない極めて高度なリスク環境において、驚くほど高い信頼性を維持し、重大事故を回避している組織の研究から発展しました。Charles Perrow の古典的研究『Normal Accidents』(1984) や、Karl Weick、Kathleen Roberts らによる一連の研究は、これらの組織がどのようにして「失敗から学び、失敗を未然に防ぐ」能力を培ってきたのかを明らかにしようとしてきました。

HROの研究者たちは、高い信頼性を支える組織文化や構造として、以下のような特徴を挙げています。

失敗へのこだわり（Preoccupation with Failure）: 小さな兆候や逸脱を見逃さず、常に最悪の事態を想定する文化。
単純化への抵抗（Reluctance to Simplify）: 現実の複雑さを安易に単純化せず、多様な視点や解釈を許容する姿勢。
オペレーションへの感度（Sensitivity to Operations）: 現場の状況やリアルタイムの情報に常に注意を払い、状況認識を共有する能力。
レジリエンスへのコミットメント（Commitment to Resilience）: 予期せぬ事態が発生しても、柔軟に対応し、機能を維持・回復できる能力。
専門知識への敬意（Deference to Expertise）: 階層や役職に関わらず、その状況において最も専門知識を持つ人物（現場担当者）の意見や判断を尊重する文化。

なぜ、この人間社会の組織論が、マルチエージェントLLMシステムの研究と関係があるのでしょうか？ 本論文の著者らは、HRO理論が長年取り組んできた 「複雑なシステムにおける組織的な失敗メカニズム」 と、 複数のLLMエージェントが協働するMASにおける失敗メカニズム との間に、驚くほど強い類似性 が存在すると指摘しています。

例えば、MASにおいて観察される失敗モードの一つである「役割仕様の不遵守（Disobey role specification）」は、HROが重要視する 「明確な役割分担と指揮命令系統の欠如」 が引き起こす問題と本質的に同じです。同様に、「他エージェントの入力無視（Ignored other agent's input）」や「情報隠蔽（Information withholding）」といった失敗は、HROの観点から見れば 「効果的な情報共有とコミュニケーションの欠如」 に相当し、組織全体の機能不全を招く重大なリスク要因となります。

さらに具体的に、本論文では、HROを特徴づけるいくつかの原則が、MASにおける失敗によって直接的に侵害されているケースを挙げています。

階層的分化（Hierarchical Differentiation）: HROでは、役割と責任が明確に定義され、通常は階層構造に従って運用されますが、緊急時や特定の状況下では、階層を超えたコミュニケーションや意思決定が許容されます。MASにおいても、エージェントの役割が厳密に区別され、越権行為を防ぐ仕組みが必要です。しかし、実際には、ある役割を担うエージェントが、自身の権限を超えて他のエージェントの領域に踏み込み、不適切な意思決定を行う失敗（Disobey role specification）が見られます。
専門知識への敬意（Deference to Expertise）: HROでは、形式的な権限構造よりも、その状況における実質的な専門知識が優先されます。最も知識のある担当者の判断が尊重されるべきです。MASにおける失敗例として、ソフトウェア開発のタスクにおいて、コード生成を担当する専門エージェントに意見を求めるべき場面で、プロジェクトマネージャー役のエージェントが独自に判断を下してしまい、結果的にバグや不具合を見逃してしまう、といったケース（Fail to ask for clarification, Ignored other agent’s input に関連）が考えられます。

これらの比較から導き出される重要な示唆は、マルチエージェントLLMシステムの信頼性を向上させるためには、 単に個々のLLMの性能（例えば、幻覚の抑制や推論能力の向上）を追求するだけでは不十分である、ということです。むしろ、HRO理論が提示するような、高信頼な組織を設計・運用するための原則（明確な役割分担、効果的なコミュニケーションプロトコル、冗長性やクロスチェックによる検証、専門性の尊重など）を、マルチエージェントシステムの設計思想に取り入れることが、システム全体の失敗を大幅に削減するための鍵となる可能性がある、と本論文は強く主張しています。

2.6 本研究の位置づけ：ギャップを埋める試み

これまでの議論を総括すると、関連研究の現状は以下のようにまとめることができます。

シングルエージェント中心の視点: 既存研究の多くは、単一LLMエージェントの能力向上や、その内部的な失敗モード（幻覚など）の分析に注力してきました。
マルチエージェント特有の課題への理解不足: マルチエージェントシステムに関する研究は進展しているものの、複数のエージェントが相互作用する際に生じる協調やコミュニケーション上の失敗、すなわち 「システムとしての失敗」 については、まだ十分に解明されていません。特に、これらの失敗を体系的に分類し、理解するための枠組み（タクソノミー）が確立されていませんでした。
設計原則の具体化の遅れ: マルチエージェントシステムの設計において、役割分担やコミュニケーションプロトコル、検証プロセスの重要性は認識されつつありますが、具体的な失敗事例に基づいた定量的・定性的な検討は不足しており、 実践的な設計指針はまだ確立されていません。
HRO理論からの示唆の活用不足: 人間組織における高信頼性の研究（HRO理論）は、マルチエージェントシステムの設計に有益な洞察を提供する可能性がありますが、この知見をLLMエージェントシステムに具体的に応用し、その有効性を検証する試みは、まだ始まったばかりです。

こうした背景を踏まえ、本論文は、これまで未踏であった領域に踏み込みます。著者らは、 「マルチエージェントシステムにおいて、具体的にどのような失敗モードが、どのような頻度で、どのような状況下で発生するのか」 を体系的に把握することの重要性を強調しています。そして、その知見に基づいて、より効果的な設計原則や評価手法を議論することが可能になると主張します。

そのために本研究では、実際のマルチエージェントシステムの 大規模な動作ログ（Trace） を収集し、 グラウンデッド・セオリー・アプローチ（Grounded Theory Approach, GTA） という質的研究手法を用いて、ボトムアップ的に失敗パターンを抽出・分類しました。

この分析に基づき、本論文は、マルチエージェントシステムに特有の失敗を包括的に整理した 初のタクソノミー（MASFT: Multi-Agent System Failure Taxonomy） を提示しています。

この点が、本研究の独自性であり、先行研究に対する明確な貢献（差分）となります。すなわち、既存研究がシングルエージェントの問題や部分的なソリューションに焦点を当てていたのに対し、本研究は マルチエージェント特有のシステムレベルの失敗を大規模データに基づいて体系的に解明し、今後の研究開発に向けた具体的な知見を提供すること を目指しているのです。
そして、HRO理論からの洞察も取り入れつつ、マルチエージェントLLMを単なる技術要素の集合体としてではなく、 信頼性を確保すべき「複雑な組織」 として捉え直す視点を提示しています。

次章以降では、この独自のアプローチによって構築された失敗タクソノミーの詳細と、そこから得られる具体的な知見について、さらに詳しく解説していきます。

第3章研究手法：マルチエージェントの失敗を体系的に解き明かす

前章では、マルチエージェントLLMシステムにおける失敗モードの研究が、既存のシングルエージェント研究や設計原則の議論だけでは不十分であり、より体系的なアプローチが必要であることを論じました。本章では、その体系的な理解をどのように実現したのか、すなわち本研究で採用された具体的な研究手法（Study Methodology）について詳述します。

マルチエージェントシステムの失敗は多様であり、事前にすべてのパターンを想定することは困難です。したがって、本研究ではトップダウン的な仮説検証ではなく、実際のデータからボトムアップ的に知見を導き出す 質的研究（Qualitative Research）のアプローチ を採用しました。具体的には、社会科学分野などで用いられるGrounded Theory アプローチに準拠し、実際のマルチエージェントシステムの動作ログを丹念に分析することで、失敗モードの分類体系（タクソノミー）を構築しました。

この章では、データ収集から始まり、コーディング、合意形成、タクソノミーの確定、そしてLLMを用いた自動分類の試みに至るまで、一連の研究プロセスをステップバイステップで解説していきます。このプロセスを通じて、どのようにして信頼性の高い失敗モード分類が実現されたのか、その方法論的な基盤を明らかにします。

3.1 データ収集：多様な現実世界のログを集める

研究の出発点は、分析対象となる生のデータを収集することです。マルチエージェントシステムの失敗モードを網羅的に捉えるためには、特定のシステムやタスクに偏ることなく、 多様な状況下での動作ログ を確保することが極めて重要となります。

3.1.1 マルチエージェントシステム（MAS）フレームワークの選定

この目的のために、本研究ではまず、現在利用可能な代表的なマルチエージェントシステム（MAS）フレームワークの中から、異なる設計思想や想定される適用ドメインを持つものを意図的に複数選定しました。論文では主に以下の5つのフレームワークが分析対象として挙げられています。

ChatDev: ソフトウェア開発プロセス（要件定義、設計、コーディング、テスト、ドキュメンテーション等）を、それぞれ専門の役割を持つエージェント群が協調してシミュレートするフレームワーク。
MetaGPT: 標準作業手順（SOPs: Standard Operating Procedures）に基づいて役割（例: プロダクトマネージャー、エンジニア、QAエンジニア）が明確に定義され、構造化されたチーム開発を行うことを目指すフレームワーク。
HyperAgent: 中央のプランナーエージェントがタスクを分解し、複数の子エージェント（エキスパート）に割り当てる階層的なワークフロー構造を持つフレームワーク。
AppWorld: スマートフォンアプリの操作など、様々な外部アプリケーションとの連携を、それぞれ専用のエージェントが担当するシステム。
AG2 (AutoGen): Microsoftが開発した、柔軟なエージェント設計と多様な対話パターンをサポートする汎用的なフレームワーク。特定のタスク（例: 数学問題解決）に合わせてエージェントの構成や役割をカスタマイズ可能。

ここで重要なのは、フレームワークの選定にあたり Theoretical Sampling（理論的サンプリング） という考え方が用いられている点です。これは、単にランダムにサンプルを集めるのではなく、「研究対象（この場合は失敗モード）に関する理論を構築・洗練するために、最も有益な情報を提供してくれる可能性のある事例（フレームワークやタスク）を意図的に選び出す」というサンプリング戦略です。
多様な設計思想（階層型 vs. フラット型、SOPベース vs. 自由対話ベースなど）や適用ドメイン（ソフトウェア開発、数学、アプリ操作など）を持つフレームワークを選ぶことで、特定の状況に限定されない、より一般化可能な失敗パターンを発見することを目指しています。

3.1.2 タスク設定と実行ログの収集

次に、選定された各MASフレームワークに対して、それぞれの設計意図や想定されるユースケースに即した具体的なタスクを与え、システムを実行させました。そして、その過程で生成されるエージェント間の対話ログ（実行トレース）を収集しました。

具体例としては、以下のようなタスクが設定されました。

ChatDevに対しては、「特定の機能を持つシンプルなWebアプリケーションを実装せよ」といったソフトウェア開発タスク。
AG2を数学問題解決用に構成したMathChatに対しては、「GSM8K」や「GSM-Plus」といったベンチマークに含まれる算数・数学の文章問題。
HyperAgentやAppWorldに対しても、それぞれのフレームワークがターゲットとする典型的なタスク（例: 複雑な情報検索と要約、複数アプリを連携させた操作）が与えられました。

各タスクの実行において、複数のエージェントがメッセージを交換し、情報を共有し、意思決定を行いながら、目標達成（あるいは失敗）に至るまでの全プロセスが詳細なログとして記録されます。一つのタスク実行ログは、短いもので数ターン、長いものでは数十ターン以上のエージェント間メッセージを含むことがあります。

最終的に、これらのプロセスを通じて合計150を超える実行トレースが収集されました。これは、分析対象となる質的データとして非常に大規模なものであり、多様な状況下でのマルチエージェントシステムの挙動を捉えるための強固な基盤となります。

3.2 オープン・コーディング：データから失敗パターンを発掘する

収集された膨大なログデータから、意味のある失敗パターンを体系的に抽出するために、本研究では Grounded Theory アプローチにおける中核的な手法であるOpen Coding（オープン・コーディング）が用いられました。

3.2.1 Grounded Theoryにおけるコーディングの考え方

Grounded Theoryの最大の特徴は、事前に固定されたカテゴリや仮説を持たずにデータ分析を開始する 点にあります。研究者は、収集したデータ（この場合は対話ログ）を繰り返し読み込み、データの中に現れる現象や概念に対して、データに根差した（Grounded）ラベル（コード）を付与していきます。つまり、トップダウンではなく、ボトムアップ的にデータから理論や分類体系を生成していくアプローチです。

3.2.2 ログの読み込みと初期コードの生成プロセス

具体的には、複数の訓練された研究者（アノテータ）が、収集された150以上の対話ログを一つ一つ詳細に読み込みます。そして、エージェント間のやり取りの中で、**「タスクの目標達成を妨げている、あるいは非効率にしている」と考えられる箇所（＝失敗の兆候や明らかなエラー）**を発見するたびに、その現象を的確に表現する短い記述的なラベル（コード）を付与していきます。

例えば、アノテータはログを読み進める中で、以下のような状況に遭遇するかもしれません。

「ユーザーが要求した仕様（例: 特定のUI要素の色）が、最終的なコードに反映されていない」→ Disobey Task Specification （タスク仕様の不遵守）
「コードレビュー担当のエージェントが、先行する開発エージェントからの重要な指摘（例: 潜在的なバグ）を無視して承認している」→ Ignore Other Agent's Input （他エージェントの入力無視）
「生成されたコードに対して、テストが実施されていない、あるいは非常に不十分なままタスクが完了とされている」→ No or Incomplete Verification （検証の欠如または不完全性）

このオープン・コーディングの段階では、厳密な定義や分類はまだ意識しません。アノテータは、データから浮かび上がってくる様々な失敗の側面を、できるだけ忠実に捉えようと試みます。そのため、初期段階では、類似した失敗に対してアノテータごとに微妙に異なる名前のコードが付与されたり、非常に細かい粒度のコードや、逆にかなり抽象的なコードが混在したりすることが一般的です。重要なのは、まずデータに内在する多様な失敗の様相を幅広く捉えることです。

3.3 反復的合意形成：コードの洗練と信頼性の確保

オープン・コーディングによって生成された多数の初期コードは、いわば未加工の原石のようなものです。これらを整理し、一貫性のある信頼性の高い失敗モード分類体系へと磨き上げていくために、本研究では 反復的な合意形成（Iterative Consensus-Building） のプロセスが採用されました。このプロセスは、主に二つの重要な活動から構成されます。

3.3.1 コードの比較と洗練：`Constant Comparison`

Grounded Theoryにおいて中心的な役割を果たすのが、Constant Comparison（絶え間なき比較）と呼ばれる手法です。これは、オープン・コーディングで生成されたコード同士を継続的に比較検討するプロセスを指します。

アノテータたちは、各自が付与したコードを持ち寄り、互いに比較します。

「このコード'Lack of Communication'と、別のログで見つけたコード'Information Not Shared'は、本質的に同じ現象を指しているのではないか？」
「'Coding Error'というコードは少し曖昧すぎる。'Syntax Error'、'Logical Error in Code'、'Dependency Issue'のように、もう少し具体的に細分化すべきではないか？」
「'Agent Hallucination'というコードは、シングルエージェントの問題であり、マルチエージェント特有の失敗とは少し性質が異なるかもしれない。どのように位置づけるべきか？」

このように、コードの意味、範囲、粒度について議論を重ね、コードの定義を明確化し、重複するコードを統合し、曖昧なコードを分割・具体化していく作業を繰り返します。この比較と議論を通じて、徐々に失敗モードの概念が洗練され、より構造化されていきます。

3.3.2 アノテータ間信頼性の評価：`Inter-Annotator Agreement (IAA)`

コードの定義が洗練されてきたら、次にその定義がアノテータ間で一貫して理解され、適用されているかを確認する必要があります。そのために用いられるのが、Inter-Annotator Agreement (IAA)（アノテータ間信頼性、または評定者間信頼性）の定量的評価です。

具体的には、複数のアノテータが、同じ対話ログの同じ箇所に対して、独立して失敗モードのコードを付与します。その後、各アノテータが付与したコードがどの程度一致しているかを、統計的な指標を用いて測定します。代表的な指標としてはCohen's Kappa（コーエンのカッパ係数）が用いられます。Cohen's Kappaは、偶然の一致を除外した上での一致度を0から1の間の値で示し、一般的に 0.6 以上で 「実質的（Substantial）」な合意 、0.8 以上で 「ほぼ完璧（Almost Perfect）」な合意 があると解釈されます。

初期の段階では、コードの定義がまだ曖昧であったり、解釈の余地が大きかったりするため、IAAの値は低い傾向にあります。もしIAAが低い値を示した場合、それは コードの定義や適用基準に問題がある ことを示唆しています。そこで、アノテータたちは再び議論の場に戻り、なぜ意見が分かれたのか、定義のどの部分が曖昧だったのかを特定し、コードの定義やアノテーションガイドラインをさらに修正・明確化します。

3.3.3 反復による精度の向上

この 「コード定義の洗練 → 独立アノテーション → IAA測定 → 定義の見直し」というサイクルを反復的に繰り返す ことが、Iterative Consensus-Buildingプロセスの核心です。この反復を通じて、失敗モードの定義は徐々に客観的で明確なものとなり、アノテータ間で高いレベルの一貫性（例えば、Cohen's Kappaが 0.8 を超えるなど）をもってコードを付与できるようになります。十分な合意度が得られた時点で、その失敗モードの定義は確立されたものと見なされます。

3.4 タクソノミーの確定：失敗モードの体系化

反復的な合意形成プロセスを経て、信頼性の高い形で定義され、区別されるようになった個々の失敗モード（コード）群。次のステップは、これらを 意味のある形で整理し、構造化された分類体系（タクソノミー） としてまとめ上げることです。

3.4.1 コードからカテゴリへ：構造化のプロセス

この段階では、確立された個々の失敗モード（コード）を、内容の類似性、発生するプロセスの段階（例: 初期設計段階、エージェント間対話段階、最終検証段階）、あるいは失敗がシステムに与える影響の種類といった基準に基づいて、より上位の カテゴリ（Category） へとグルーピングしていきます。このプロセスは、Axial Coding（軸足コーディング）やSelective Coding（選択コーディング）と呼ばれるGrounded Theoryの後の段階の考え方に近いものです。

本研究においては、この整理・統合プロセスを経て、最終的にすべての失敗モードが、以下の 3つの主要な失敗カテゴリ（Failure Category, FC） に分類されました。

FC1: Specification and System Design Failures
（仕様設定およびシステム設計における失敗）
: タスクの初期理解、計画立案、役割分担など、システム全体の設計やタスク定義に関連する失敗群。
FC2: Inter-Agent Misalignment
（エージェント間の不整合）
: 複数のエージェントが相互作用する過程で発生するコミュニケーション上の問題や、役割・知識の齟齬に起因する失敗群。
FC3: Task Verification and Termination
（タスク検証および終了における失敗）
: 生成された成果物の品質検証や、タスクの完了判断に関連する失敗群。

さらに、これらの3つの大カテゴリの下に、前段階で確立された**合計14個の具体的な失敗モード（Failure Mode, FM）**が紐付けられる形で、階層的なタクソノミーが構築されました（例: FM1.1: Ambiguous Task Specification, FM2.1: Disobey Role Specification など）。

3.4.2 最終的な分類体系：`MASFT`の完成

このようにして完成したのが、本論文が提示する中核的な成果物である MASFT (Multi-Agent System Failure Taxonomy) です。このタクソノミーは、マルチエージェントLLMシステムにおいて発生しうる主要な失敗を、構造化され、相互排他的かつ網羅的に（mutually exclusive and collectively exhaustive, MECE に近い形で）整理したものです。

重要な点として、論文中では、定義された 各失敗モード（14種類） に対して、実際の対話ログから抽出された具体的な失敗事例 が付随して示されています。これにより、読者は抽象的な定義だけでなく、「この失敗モードは、具体的にどのような状況で、どのような形で現れるのか」を直感的に理解することができます。これは、このタクソノミーを他の研究者や開発者が実際に活用する上で、非常に有用な情報となります。

3.5 自動分類の試み：`LLM-as-a-Judge`の活用

Grounded Theoryに基づく人手による詳細なログ分析は、質の高い知見を得るためには非常に有効ですが、一方で膨大な時間と労力を要するという側面もあります。特に、将来的にさらに多くのマルチエージェントシステムのログを分析・評価する必要が出てきた場合、スケーラビリティ が課題となります。

この課題に対処するため、本研究では興味深い試みが行われました。それは、構築されたMASFTタクソノミーを利用して、LLM（大規模言語モデル）自身に、対話ログ中の失敗モードを自動的に分類させる ことです。論文ではこのアプローチを LLM-as-a-Judge と呼んでいます。

3.5.1 背景と狙い

LLM-as-a-Judgeの基本的なアイデアは、 人間が行ってきた失敗モードの判定プロセスをLLMに模倣させること にあります。もしLLMが人間と同程度の精度で失敗モードを分類できれば、将来的なログ分析の効率を大幅に向上させることが可能になります。その狙いは、開発中のシステムのデバッグ支援や、運用中のシステムの継続的なモニタリングなどを、より迅速かつ大規模に行えるようにすることにあります。

3.5.2 実装方法：プロンプトエンジニアリングとFew-Shot学習

LLM-as-a-Judgeを実現するための具体的な手法は、プロンプトエンジニアリングに基づいています。大まかな流れは以下の通りです。

タクソノミーの提示（システムプロンプト）: まず、LLMに対して、本研究で構築されたMASFTの全体像、すなわち3つの大カテゴリと14個の失敗モード、そしてそれぞれの詳細な定義をシステムプロンプトとして提供します。これにより、LLMはどのような基準で分類を行えばよいかを理解します。
具体例の提示（Few-Shot Learning）: 次に、LLMに対して、実際の対話ログの一部と、それに対応する 正解の失敗モードラベル（人間アノテータが付与したもの） をいくつか具体例（Few-Shot examples）として提示します。「入力ログがこのような内容の場合、この失敗モードに分類される」という実例を示すことで、LLMはより具体的な分類タスクの要領を学習します。
判定の実行: 準備が整ったら、分類したい新しい対話ログのセグメントをLLMに入力として与え、「このログセグメントにMASFTのどの失敗モードが該当するか、最も適切なものを一つ（または複数）選んでください」といった指示を与えます。
結果の取得: LLMは、与えられた情報（タクソノミー定義、Few-Shot例、入力ログ）に基づいて推論を行い、該当すると判断した失敗モードのラベルを出力します。

3.5.3 評価：人間アノテータとの一致度

このLLM-as-a-Judgeアプローチの有効性を検証するために、LLMが出力した失敗モードのラベルと、 人間の専門家アノテータが付与した「正解」ラベル（ゴールドスタンダード） とを比較し、その一致度が評価されました。評価指標としては、ここでもCohen's Kappaが用いられました。

その結果、論文では Cohen's Kappaスコアがおおむね0.77 という、非常に高い値が得られたと報告されています。これは、 「実質的（Substantial）」な合意レベル に達しており、人間同士のアノテーションにおける合意度に迫る精度です。

この結果は、LLMが、適切に設計されたプロンプトとタクソノミーを与えられれば、複雑なマルチエージェントシステムの対話ログにおける失敗モードを、ある程度の正確さをもって自動的に判定できる可能性を示唆しています。これは、将来的なMASの評価やデバッグを効率化する上で、非常に有望な方向性と言えるでしょう。

3.6 まとめ：本研究の手法がもたらす価値

本章で詳述した研究手法は、マルチエージェントLLMシステムにおける失敗という、複雑で捉えどころのない現象を体系的に理解するための、堅牢かつ段階的なアプローチを提供します。その主要なステップを再確認しましょう。

データ収集: Theoretical Samplingに基づき、多様なMASフレームワークとタスクから大規模な実行ログを収集。
オープン・コーディング: Grounded Theoryに従い、データからボトムアップ的に初期の失敗コードを発掘。
反復的合意形成: Constant ComparisonとIAA測定を繰り返し、コード定義の洗練とアノテータ間の一貫性を確保。
タクソノミーの確定: 確立されたコードを構造化し、3カテゴリ・14失敗モードから成る包括的な分類体系MASFTを構築。
LLM-as-a-Judge: MASFTを用いてLLMに自動分類を行わせる手法を開発・評価する。結果、人間アノテータと高い一致度（Kappa=0.77）を確認。

この一連のプロセスを通じて、従来は断片的、あるいは逸話的にしか語られなかったマルチエージェントシステム特有の失敗要因について、データに基づいた体系的かつ信頼性の高い理解が可能になりました。さらに、LLM-as-a-Judgeの成功は、今後のMAS開発における大規模なログ分析や継続的な品質評価を効率化・自動化するための道筋を示しており、本研究手法の大きな実践的価値となっています。

次章では、この研究手法によって明らかにされたMASFTタクソノミーの具体的な内容、すなわち14の失敗モードについて、さらに詳しく見ていくことにします。

第4章結果と考察：マルチエージェントシステムの失敗モード詳解

前章では、マルチエージェントLLMシステム（MAS）における失敗モードを体系的に特定し、分類するための研究手法として、Grounded Theoryに基づいた質的分析プロセスを詳述しました。本章では、その厳密なプロセスを経て得られた具体的な結果（Study Findings）、すなわちマルチエージェントシステム失敗分類体系 MASFT (Multi-Agent System Failure Taxonomy) の詳細と、そこから導き出される *考察 *について深く掘り下げていきます。

論文の著者は、収集された150を超える実行トレースの分析から、MASが陥りやすい失敗パターンを抽出し、最終的に 3つの主要な失敗カテゴリ（Failure Category, FC） と、それに属する 合計14個の具体的な失敗モード（Failure Mode, FM） を同定しました。

本章では、これらのカテゴリとモードを一つ一つ紹介し、実際の対話ログから得られた具体例を交えながら、それぞれの失敗がどのような性質を持ち、システム全体にどのような影響を与えるのかを解説します。さらに、これらの失敗モードの分布や相互関係、そして高信頼組織（HRO）理論との関連性についても考察し、MASの信頼性向上に向けた重要な示唆を提示します。

4.1 MASFT：失敗モード分類体系の全体像

本研究によって構築されたMASFTは、マルチエージェントシステムが経験する可能性のある失敗を、その発生原因や性質に基づいて構造化したものです。このタクソノミーは、以下の3つの大別されたカテゴリ（FC）から構成されています。

FC1: Specification and System Design Failures（仕様設定およびシステム設計における失敗）
: システムの初期設定、タスク定義、役割分担といった、いわば「設計図」の段階に起因する問題群。
FC2: Inter-Agent Misalignment（エージェント間の不整合）
: システム運用中のエージェント間のコミュニケーション、情報共有、協調プロセスにおける齟齬や断絶に起因する問題群。
FC3: Task Verification and Termination（タスク検証および終了における失敗）
: タスクの最終段階における成果物の品質チェックや、タスク完了の判断プロセスにおける問題群。

以降のセクションでは、これらの各カテゴリに属する具体的な失敗モードについて、その定義と典型的な現れ方を詳しく見ていきます。

4.2 FC1: 設計と仕様の落とし穴 - Specification and System Design Failures

このカテゴリに分類される失敗は、マルチエージェントシステムがタスクに取り組む出発点、すなわち初期設定や設計段階に根差しています。タスクの指示が曖昧であったり、エージェントの役割分担が不適切であったり、あるいはシステム自体の基本的な能力（例: 記憶力）に限界がある場合に、これらの失敗が顕在化します。

以下に、FC1に属する代表的な失敗モードをいくつか紹介します。

FM1.1: Disobey Task Specification（タスク仕様の不遵守）

これは、ユーザーが与えた要件、制約、あるいは明示的な指示を、エージェント（またはシステム全体）が無視したり、誤解したり、あるいは単に実行できなかったりするケースです。例えば、「生成するコードはPython 3.9を使用すること」という制約を守らずに古いバージョンで書いてしまう、あるいは「ユーザーインターフェースは青色を基調とすること」という要求が最終成果物に反映されない、といった状況がこれに該当します。これは、システムのタスク理解能力の限界や、指示の追跡能力の欠如に起因することが多いです。
FM1.2: Disobey Role Specification（役割仕様の不遵守）

マルチエージェントシステムでは、各エージェントに特定の役割（例: Planner, Coder, Reviewer）が割り当てられることが一般的です。この失敗モードは、あるエージェントが自身に割り当てられた役割や責任範囲を逸脱し、他のエージェントの担当領域に踏み込んだり、あるいは自身の役割を放棄したりする状況を指します。例えば、Coderエージェントが勝手に設計を変更してしまう、あるいはReviewerエージェントがコードレビューを行わずに承認してしまう、といったケースです。これは、役割定義の曖昧さ、エージェントの自律性の過剰な発揮、あるいは役割間の連携不足によって引き起こされ、システム全体の協調プロセスに混乱をもたらします。
FM1.3: Loss of conversation history（会話履歴の喪失）

長時間にわたる対話や複雑なタスク遂行において、エージェントが過去の会話の文脈や重要な情報を忘れてしまう失敗です。これは、LLMの持つコンテキストウィンドウの制限や、システムにおける長期記憶管理メカニズムの不備に起因することがあります。結果として、以前に決定された事項が無視されたり、同じ質問が繰り返されたりするなど、非効率なやり取りや矛盾した行動につながります。
FM1.4: Unaware of termination conditions（終了条件の不認識）

エージェント（またはシステム全体）が、タスクがいつ完了したとみなすべきか、あるいはどのような条件で終了すべきかを正しく認識できていない状態です。これにより、タスクが未完了にもかかわらず終了してしまったり（後述のPremature terminationと関連）、逆に不必要に処理を続けてしまったりする可能性があります。

これらのFC1に属する失敗は、しばしば後続のFC2やFC3の失敗を引き起こす根本原因となり得るため、システム設計の初期段階でいかに明確な仕様と役割定義、そして堅牢な基盤（記憶管理など）を構築するかが重要であることを示唆しています。

4.3 FC2: エージェント間のすれ違い - Inter-Agent Misalignment

このカテゴリは、システムが稼働し、複数のエージェントが実際に相互作用を始めた段階で発生する問題に焦点を当てています。エージェント間のコミュニケーションがうまくいかなかったり、互いの意図や知識が共有されなかったり、あるいは協調プロセスが破綻したりする場合に、これらの失敗が観察されます。人間社会のチームワークにおける「連携ミス」や「意思疎通の不足」に相当する問題群と言えるでしょう。

以下に、FC2の代表的な失敗モードを挙げます。

FM2.1: Fail to ask for clarification（明確化要求の失敗）

あるエージェントが、他のエージェントから曖昧な指示、不完全な情報、あるいは矛盾したメッセージを受け取ったにもかかわらず、追加の質問や確認を行わずにタスクを進めてしまう失敗です。例えば、必要なパラメータが不足しているAPIコールを指示された際に、「どの値を使えばよいですか？」と尋ねることなく、適当な値で実行してしまうようなケースです。これは、誤った前提に基づいて作業が進む原因となり、後工程での手戻りや、最終的な失敗につながるリスクを高めます。
FM2.2: Ignored other agent's input（他エージェントの入力無視）

あるエージェントが、他のエージェントから提供された情報、提案、あるいは警告を、意図的か否かにかかわらず無視してしまう失敗です。ReviewerエージェントがCoderエージェントのコードに含まれる明らかなバグを指摘したにもかかわらず、Coderがそれを修正せずに次のステップに進んでしまう、といった状況が考えられます。これは、チームとしての集合知が活かされず、個々のエージェントの誤りが是正されないまま放置される原因となります。
FM2.3: Information withholding（情報隠蔽）

: タスク遂行に必要な情報を持っているエージェントが、それを他の必要としているエージェントに**適時・適切に共有しない（あるいは、しようとしない）**失敗です。これは、コミュニケーションプロトコルの不備、あるいはエージェントが情報の重要性を認識できていない場合に発生し得ます。結果として、他のエージェントが必要な情報なしに作業を進めることになり、非効率やエラーを引き起こします。
FM2.4: Task derailment（タスクの脱線）

エージェント間の対話やタスク遂行プロセスが、本来の目標や主要なパスから逸脱し、無関係な話題や非生産的なループに陥ってしまう失敗です。例えば、エラーの解決策について議論しているうちに、全く別の技術的な話題に深入りしてしまい、元の問題を放置してしまうようなケースです。これにより、時間とリソースが無駄に消費され、タスクの完了が遅延したり、達成できなくなったりします。
FM2.5: Reasoning-action mismatch（推論と行動の不一致）

エージェントが内部的な推論（思考プロセス）では正しい結論や次に行うべき行動を導き出しているにもかかわらず、実際の出力（発言や行動）がその推論と一致しない失敗です。例えば、内部ログでは「ファイルXを削除すべき」と判断しているのに、実際にはファイルYを削除するコマンドを実行してしまう、といったケースです。これは、エージェントの内部状態と外部へのインターフェース間の不整合や、LLMの生成プロセスの不安定性に起因する可能性があります。

FC2の失敗モードは、マルチエージェントシステムの「相互作用」の側面に光を当てており、個々のエージェントの能力だけでなく、それらを繋ぐコミュニケーションと協調のメカニズムがいかに重要であるかを強調しています。

4.4 FC3: 検証と終了の壁 - Task Verification and Termination

この最後のカテゴリは、タスク遂行の最終段階、すなわち成果物の品質保証とタスクの完了判断に関連する失敗を扱います。たとえ途中までのプロセスが順調に進んだとしても、この最終段階で適切な検証が行われなかったり、終了判断を誤ったりすると、システム全体の目標達成は危うくなります。

以下に、FC3の主要な失敗モードを示します。

FM3.1: Premature termination（時期尚早な終了）

タスクがまだ完了していない、あるいは要求された品質基準を満たしていないにもかかわらず、システムが 「タスク完了」と誤って判断し、処理を打ち切ってしまう 失敗です。例えば、ソフトウェア開発タスクにおいて、単体テストは通ったものの結合テストや機能テストが不十分な段階で「実装完了」と報告してしまうケースです。これにより、不完全または欠陥のある成果物がユーザーに提供されるリスクが生じます。
FM3.2: No or incomplete verification（検証の欠如または不完全性）

生成された成果物（コード、文章、計画など）に対して、必要な検証プロセスが全く行われない、あるいは行われたとしても形式的で不十分である失敗です。例えば、生成されたコードに対して、コンパイルが通ることだけを確認し、実際のロジックの正しさや要求仕様との整合性をチェックしないまま承認してしまうようなケースです。これは、エラーや欠陥が見逃される直接的な原因となります。
FM3.3: Incorrect verification（不正確な検証）

検証プロセス自体は実施されているものの、その検証ロジックや基準が間違っているために、存在するはずの問題を見逃してしまったり（偽陰性）、逆に問題がないものを誤って問題ありと判断してしまったり（偽陽性）する失敗です。例えば、テストケース自体にバグが含まれていて、本来検出されるべきエラーが検出されない、あるいはテストの合格基準が緩すぎて品質の低い成果物でも合格してしまう、といった状況です。

FC3の失敗モードは、マルチエージェントシステムにおける 品質保証（Quality Assurance, QA） の重要性を示唆しています。特に、複数のエージェントが分担して作業を進める場合、最終的な成果物を統合し、その全体的な品質を誰がどのように保証するのか、というプロセス設計が不可欠となります。

4.5 失敗モードの分布と具体例：システム横断的な課題

MASFTによって14の失敗モードが定義された後、研究チームは収集した150以上の実行トレースに対してこれらのモードを適用し、どの失敗モードが、どのMASフレームワークで、どの程度の頻度で発生しているかを分析しました。

その結果、いくつかの興味深い知見が得られました。

失敗の普遍性

特定の失敗モードが特定のフレームワークだけに極端に集中するというよりは、多くの失敗モードが、程度の差こそあれ、分析対象となった複数のフレームワーク（ChatDev, MetaGPT, AG2など）で共通して観察されました。これは、これらの失敗が個々の実装の問題だけでなく、マルチエージェントシステムというアーキテクチャ自体に内在する普遍的な課題である可能性を示唆しています。

カテゴリ間のバランス

失敗を3つの大カテゴリ（FC1, FC2, FC3）で集計すると、特定のカテゴリだけが突出して多いわけではなく、設計段階（FC1）、エージェント間連携（FC2）、最終検証（FC3）のいずれにおいても、かなりの割合で失敗が発生していることが明らかになりました。システムによって若干の偏り（例えば、あるシステムではFC1が多いが、別のシステムではFC2が多いなど）は見られるものの、全体としては、MASのライフサイクル全体にわたって失敗のリスクが分散していると言えます。

具体的な失敗シナリオ

論文中では、これらの抽象的な失敗モードが実際の対話ログでどのように現れるかを示す具体例が豊富に提示されています。例えば、

あるエージェントがAPIキーを必要としているのに、他のエージェントが必要な情報を渡さず（Information withholding）、結果としてAPI呼び出しが延々と失敗し続けるループに陥る。
コード生成エージェントとレビューエージェントの間で、バグ修正に関する指示と応答が噛み合わず（Inter-Agent Misalignment）、最終的にバグが修正されないままタスクが終了してしまう（Premature termination / No or incomplete verification）。
ユーザーの初期要求が曖昧だったため（潜在的なAmbiguous Task Specification）、エージェントが勝手な解釈で実装を進め、最終的にユーザーの意図と全く異なるものが出来上がる（Disobey Task Specification）。

これらの分析結果は、マルチエージェントシステムの信頼性を向上させるためには、特定の側面（例えば、LLMの基本性能向上）だけを改善するのではなく、システム設計、エージェント間コミュニケーション、そして検証プロセスという、システム全体にわたる多角的なアプローチが必要であることを強く示唆しています。

4.6 考察：失敗の連鎖とVerifier（検証者）の限界

さらに、研究チームは失敗モード間の関係性や、特定の役割（特に検証担当エージェント、Verifier）の重要性についても考察を加えています。

失敗カテゴリ間の相関:

失敗カテゴリ（FC1, FC2, FC3）間の相関関係を分析したところ（論文中ではヒートマップで示されています）、全体として非常に強い相関は見られませんでした。

これは、「設計段階で失敗（FC1）すると、必ず検証段階でも失敗（FC3）する」といった単純な因果関係や連鎖が常に成り立つわけではないことを意味します。失敗は、システムの様々な側面で独立して発生しうる、あるいは複雑な相互作用の結果として生じると考えられます。ただし、個別の失敗モードレベルで見れば、例えばコミュニケーションの齟齬（FC2）がタスク仕様の誤解（FC1）を引き起こしたり、それが最終的な検証不備（FC3）につながったりするような、特定のシナリオにおける連鎖は存在しうることが示唆されています。

Verifierの役割と限界

マルチエージェントシステム、特にソフトウェア開発を模倣するシステムでは、生成された成果物をチェックする「検証者（Verifier）」あるいは「レビューア（Reviewer）」の役割がしばしば導入されます。一見すると、「最終的な検証ステップ（FC3）を強化すれば、上流工程（FC1, FC2）での失敗はすべてキャッチできるのではないか？」と考えがちです。しかし、著者らはこの 「Verifier万能論」 に対して警鐘を鳴らしています。

根本原因の見逃し

たとえVerifierが存在しても、そもそもタスクの仕様が曖昧であったり、重要な情報がエージェント間で共有されていなかったりする場合、Verifierはその欠陥に気づくことすらできない可能性があります。検証は、あくまで「与えられた仕様に対して成果物が正しいか」をチェックするものであり、仕様自体の妥当性や完全性を保証するものではありません。

Verifier自身の能力限界

Verifier役のエージェント自身も、他のエージェントと同様にLLMに基づいている場合が多く、その能力には限界があります。Verifierが不十分なテストケースしか生成できなかったり、複雑なロジックの誤りを見抜けなかったり、あるいはそれ自身が幻覚を起こしたりする可能性も否定できません。
したがって、「検証フェーズで失敗が検出された（例: No or incomplete verification）」としても、その根本原因は検証プロセス自体にあるのではなく、より上流の設計やコミュニケーションの問題（FC1, FC2）に潜んでいる場合が多い、と著者らは結論付けています。Verifierは重要な役割を果たしますが、システム全体の信頼性を保証するための銀の弾丸ではないのです。

4.7 考察：高信頼組織（HRO）理論との響き合い

最後に、本研究の考察は、マルチエージェントLLMシステムで見られる失敗パターンと、人間社会における 高信頼組織（High-Reliability Organization, HRO）の研究で議論されてきた失敗メカニズムとの間に見られる顕著な類似性 に言及しています。

前章でも触れたように、HRO理論は、極めて高い信頼性が要求される複雑なシステム（原子力発電所、航空管制など）を運用する人間組織が、どのようにして重大事故を回避しているかを研究する分野です。そこでは、コミュニケーションの断絶、役割の曖昧さや逸脱、状況認識の共有失敗、小さな異常の軽視などが、組織的な失敗につながる主要な要因として繰り返し指摘されてきました。

本研究で同定されたMASFTの失敗モード、特に**FC2（エージェント間の不整合）**に分類されるもの（例: Fail to ask for clarification, Information withholding, Ignored other agent's input）や、FC1の一部（例: Disobey Role Specification）は、驚くほどHRO理論で議論される人間組織の失敗パターンと共通しています。

この類似性が示唆することは極めて重要です。それは、マルチエージェントLLMシステムの信頼性を向上させるためには、単に個々のLLMエージェントの知能や能力を高めるだけでは不十分であり、むしろ人間組織におけるチームワークやリスク管理、コミュニケーション戦略といった「組織論的」な知見を取り入れたシステム設計や運用プロトコルが不可欠になる、ということです。エージェントの数を増やし、より複雑なタスクに挑戦させようとすればするほど、このような「組織としての」課題がより顕著になる可能性が高いと考えられます。

4.8 まとめ：Study Findingsが示す道筋

本章で詳述した「Study Findings」は、マルチエージェントLLMシステムが直面する失敗の現実を、体系的かつ具体的に描き出しました。その主要なポイントを以下に要約します。

失敗の体系化: MASの失敗は、設計・仕様（FC1）、エージェント間連携（FC2）、検証・終了（FC3）という3つの主要カテゴリと14の具体的モード（MASFT）に分類できる。
失敗の普遍性: これらの失敗モードは、特定のMASフレームワークに限定されず、広く共通して見られる課題である。
多面的なリスク: 失敗はシステムのライフサイクル全体（設計、実行、検証）にわたって発生しうるため、単一の対策（例: Verifier強化）だけでは不十分である。
組織論的課題: 観察された失敗の多くは、人間組織におけるコミュニケーションや役割分担の問題と類似しており、HRO理論などの知見がシステム設計に応用できる可能性を示唆している。

これらの結果と考察は、マルチエージェントLLMシステムの開発者や研究者に対して、単なるバグ修正やLLMの性能向上という視点を超え、システム全体をいかに信頼性の高い「組織」として設計し、運用していくかという、より根本的な問いを投げかけています。MASFTは、そのための具体的な問題点を特定し、改善策を検討するための重要な羅針盤となるでしょう。

第5章解決策に向けて：より信頼性の高いマルチエージェントLLMシステムへ

これまでの章で、著者はマルチエージェントLLMシステム（MAS）が陥りやすい多様な失敗モードを体系的に明らかにし、その分類体系MASFTを提示しました。失敗を理解することは、改善への第一歩です。本章では、その知見に基づき、これらの失敗をいかにして克服し、より堅牢で信頼性の高いMASを構築していくか、その具体的な解決策と将来的な方向性について議論します。

論文の著者らは、特定された失敗モードに対処するためのアプローチを大きく二つに分類しています。一つは、比較的容易に導入可能で即効性のある Tactical Approaches（戦術的アプローチ） 、もう一つは、システム全体の設計やアーキテクチャに踏み込む、より根本的で大掛かりな Structural Strategies（構造的戦略） です。本章では、これらのアプローチを詳細に解説し、それぞれの有効性と限界、そして将来の研究開発に向けた展望を探ります。

5.1 戦術的アプローチ：応急処置としての改善策

戦術的アプローチは、既存のMASフレームワークに対して、比較的少ない労力で適用可能な改善策を指します。これらは主に、プロンプトの工夫やエージェントの構成変更によって、特定の失敗モードの発生頻度を低減させることを目指します。

5.1.1 プロンプトエンジニアリングの洗練

LLMエージェントの挙動を制御する上で、プロンプトは極めて重要な役割を果たします。したがって、プロンプト設計を改善することは、多くの失敗モードに対する直接的な対策となり得ます。

役割とタスク仕様の明確化: エージェントに与えるシステムプロンプトや役割プロンプトにおいて、そのエージェントが担うべき役割（例: 「あなたはコード生成を担当するPythonプログラマです」）、守るべき制約（例: 「生成するコードはPEP 8に準拠してください」）、そしてタスクの終了条件（例: 「指定された全ての機能が実装され、テストがパスしたらタスク完了です」）を、可能な限り厳密かつ具体的に記述します。これにより、Disobey Task SpecificationやDisobey Role Specificationといった失敗のリスクを低減させることが期待できます。
暗黙的ルールの明示化: エージェント間の円滑なコミュニケーションや協調のために望ましい行動（例: 「不明な点があれば必ず質問すること」「他のエージェントからの指摘には必ず応答すること」「エラーが発生した場合は詳細な情報を報告すること」）を、暗黙の了解に頼るのではなく、明示的にプロンプトに組み込みます。これは、Fail to ask for clarificationやIgnored other agent's inputといったコミュニケーション上の問題を抑制する助けとなります。

5.1.2 エージェント構造（トポロジー）の調整

エージェントの構成や連携方法を工夫することでも、失敗を減らすことが可能です。

クロス検証（Cross-Verification）の導入: 単一のエージェントによる検証（Self-Verification）には限界があるため、例えば二つのエージェントが交互に成果物をレビューし合う、あるいは検証を専門とする独立したエージェントを設けるといった構成を採用します。これにより、一方のエージェントが見逃したエラーを他方が検出する機会が生まれ、No or incomplete verificationやIncorrect verificationのリスクを低減できます。
役割分担の最適化: エージェントの数が多すぎたり、逆に一つのエージェントに過度に多くの責任を負わせたりすると、システム全体の調整が困難になり、かえって混乱を招く可能性があります。したがって、タスクの性質に応じて適切な粒度で役割を定義し、モジュール性を保ちつつも、過度な複雑化を避けることが推奨されます。シンプルさは、しばしば信頼性の鍵となります。

5.1.3 自己検証（`Self-Verification`）の促進

エージェント自身に、自身の出力や判断を再検討させることも有効な場合があります。

自己反省プロンプト: タスクの完了直前や、重要な判断を下す際に、「生成した内容に矛盾や誤りはないか、もう一度確認してください」「前提条件は満たされていますか？」といった自己検証を促す指示をプロンプトに含めることで、エージェントが自身の誤りに気づく機会を与えることができます。

5.2 戦術的アプローチの有効性と限界

これらの戦術的アプローチは、実装が比較的容易であり、一定の効果を発揮することが期待できます。実際に、論文中で報告されているケーススタディ（AG2を用いた数学問題解決、ChatDevを用いたソフトウェア生成）では、プロンプトの改善やエージェント構成の微調整、検証ロールの追加といった戦術的な修正を施すことで、いくつかの失敗モードの発生率が実際に低下したことが示されています。

しかしながら、著者らは、これらの戦術的アプローチだけでは、マルチエージェントシステムの失敗を根本的に解決するには不十分である、とも結論付けています。

例えば、どれだけプロンプトで役割を明確に指示しても、LLMの性質上、エージェントがその指示から逸脱してしまう可能性（Disobey Role Specification）を完全にゼロにすることは困難です。同様に、プロンプトで「情報を共有せよ」と指示しても、エージェントが状況に応じて何を、いつ、どのように共有すべきかを適切に判断できない場合（Information withholdingなど）、コミュニケーション不全は依然として発生し得ます。

自己検証も、エージェント自身の能力に依存するため、複雑なエラーや自身の「盲点」となっている問題を見抜けるとは限りません。クロス検証も、検証エージェント自身の能力限界や、検証プロセス自体の不備があれば、やはり失敗を見逃す可能性があります。

すなわち、戦術的アプローチは、いわば「対症療法」や「応急処置」としては有効ですが、病気の根本原因を取り除く「根治療法」にはなり得ない場合が多いのです。より深く、より複雑なシステムレベルの問題に対処するためには、次節で述べる構造的な戦略が必要となります。

5.3 構造的戦略：システム設計からの抜本改革

構造的戦略は、プロンプトやエージェント構成の微調整にとどまらず、マルチエージェントシステムの基盤となるアーキテクチャ、通信メカニズム、検証プロセス、学習能力といった、より根本的な要素に踏み込んだ改善を目指します。これらは実装に時間と労力を要する可能性がありますが、システムの信頼性を飛躍的に向上させるポテンシャルを秘めています。

5.3.1 強力な検証（`Comprehensive Verification`）メカニズムの組み込み

単なる形式的なチェックや自己検証を超えた、多角的かつ厳密な検証プロセスをシステムに組み込むことが重要です。

専門化された検証エージェント: 特定のドメインやタスクに特化した高度な検証能力を持つエージェントを導入します。例えば、ソフトウェア開発タスクであれば、ユニットテスト、統合テスト、静的解析などを自動的に実行し、結果を評価するエージェントを組み込みます。数学問題であれば、シンボリック計算エンジンを用いて解の正しさを形式的に検証するエージェントなどが考えられます。
多層的な検証プロセス: 検証を単一のステップで行うのではなく、複数の段階（例: コンパイルチェック → 単体テスト → 結合テスト → 要求仕様との整合性チェック）で、それぞれ異なる観点からチェックを行う多層的なプロセスを設計します。
ドメイン特化の検証手法: 対象となるタスク領域に応じて、最適な検証手法を採用します。コードのバグ検出、生成された文章のファクトチェック、データの整合性検証、物理シミュレーション結果の妥当性評価など、ドメイン固有の知識やツールを活用した検証が求められます。

5.3.2 標準化されたコミュニケーションプロトコルの導入

エージェント間の自由形式な自然言語による対話は、柔軟性が高い反面、曖昧さや誤解を生むリスクも伴います。これを補完するために、より構造化され、形式化されたコミュニケーションプロトコルを導入することが有効です。

構造化データの活用: エージェント間の情報交換、特に指示や報告など、明確性が求められる場面において、JSON形式や特定のXMLスキーマ、あるいはタグ付けされたフォーマットなど、事前に定義された構造を持つデータ形式を用いることを検討します。これにより、情報の欠落や解釈の揺れを防ぎます。
必須項目とチェックリスト: コミュニケーションにおいて、 必ず含めるべき情報項目（例: タスクID、送信元エージェントID、メッセージタイプ） や、 遵守すべきルール（例: エラー発生時には特定のエラーコードを返す、確認応答を必ず返す） をプロトコルとして定義し、徹底させます。これは、人間組織における標準作業手順（SOP）の導入に似ています。

5.3.3 不確実性の明示的な管理

LLMは、しばしば自信満々に誤った情報を生成することがあります（幻覚）。エージェントが自身の出力や判断に対する 不確実性（Uncertainty） を推定し、それを明示的に扱う仕組みを導入することは、信頼性向上に大きく貢献します。

自信度スコアの活用: エージェントが生成した回答や提案に対して、どの程度の自信を持っているかを数値（例: 0から1のスコア）で表現させます。この自信度スコアが低い場合には、自動的に再検討を促したり、他のエージェントに意見を求めたり（Fail to ask for clarificationの逆）、あるいは人間の介入を要求したりするようなワークフローを設計できます。
動的な意思決定閾値: タスクの重要度や状況に応じて、許容される不確実性のレベル（閾値）を動的に調整します。例えば、クリティカルな判断が求められる場面では、非常に高い自信度スコアを持つエージェントの意見のみを採用する、といったポリシーを設定できます。

5.3.4 継続的な学習能力の付与

システムが運用を通じて経験した成功や失敗から学習し、自身の振る舞いを継続的に改善していく能力を付与することは、長期的な信頼性向上に不可欠です。

マルチエージェント強化学習（MARL）: MAPPOやSHAPPOといったマルチエージェント強化学習（Multi-Agent Reinforcement Learning, MARL）のアルゴリズムを用いて、エージェント群全体としての協調行動（最適な役割分担、効率的な情報交換、効果的な検証戦略など）を報酬最大化を通じて学習させるアプローチです。これにより、人間が明示的にルールを設計せずとも、システムが自律的に最適な運用方法を発見できる可能性があります。
失敗事例からの学習: 本研究で特定されたような失敗モード（MASFT）の発生事例を「ネガティブサンプル」として収集・記録し、これをファインチューニングや強化学習のペナルティとして利用することで、同様の失敗の再発を抑制する学習メカニズムを構築します。

5.3.5 メモリと状態管理の強化

特に長期的なタスクや多数のエージェントが関与する場合、Loss of conversation historyのような問題を防ぐためには、高度なメモリ管理と状態追跡の仕組みが必要です。

OS的なアプローチ: MemGPTのように、エージェントの対話履歴や内部状態を仮想的なメモリ空間で管理し、必要に応じて情報をページング（ロード/アンロード）することで、LLMのコンテキストウィンドウ制限を克服しようとするアプローチです。
ログの構造化と再生可能性: エージェント間の対話ログを単なるテキストとして保存するだけでなく、イベントシーケンスや状態遷移として構造化し、後から特定の時点の状態を再現したり、要約したり、分析したりすることを容易にする仕組みを構築します。

5.4 戦術 vs. 構造：二つのアプローチの比較と統合の必要性

ここまで見てきたように、マルチエージェントシステムの失敗に対処するには、 Tactical Approach（戦術的アプローチ） と Structural Strategy（構造的戦略） という、性質の異なる二種類のアプローチが存在します。

戦術的アプローチは、即効性があり、導入コストも比較的低いという利点があります。プロンプトの改善や簡単な構成変更は、多くのプロジェクトですぐに試すことができるでしょう。しかし、その効果は限定的であり、根本的な問題解決には至らないケースが多いです。
構造的戦略は、システムの基盤に手を入れるため、より根本的で持続的な改善をもたらす可能性があります。強力な検証メカニズムや標準化されたプロトコル、学習能力の導入は、システムの信頼性を大きく向上させるポテンシャルを秘めています。しかし、その実装には高度な技術と多くの開発コストを要し、既存システムへの後付けが難しい場合もあります。

論文の著者らは、戦術的な修正だけでは限界があることを強調 しています。例えば、プロンプトを工夫するだけでは、エージェント間の複雑なコミュニケーション不全や、LLM固有の幻覚といった問題を根絶することは難しいでしょう。

最終的には、高信頼組織（HRO）理論が示唆するように、システム全体の設計思想、すなわちエージェント間の明確な役割と責任分担、階層構造、効果的な情報伝達経路、多重化された検証プロセス、そして失敗から学習する文化（あるいはメカニズム）といった、組織的・全体的なアプローチが不可欠になる、と結論づけられています。信頼性の高いMASを構築するためには、戦術的な改善努力と並行して、これらの構造的な戦略を着実に導入していく必要があるのです。

5.5 今後の展望：未踏のフロンティアへ

マルチエージェントLLMシステムは、依然として発展途上の技術であり、その信頼性向上には多くの未解決課題が存在します。著者らは、今後の研究開発における重要な方向性として、以下のようなテーマを挙げています。

汎用的な検証フレームワークの開発: 特定のタスクだけでなく、様々なドメインやMASアーキテクチャに適用可能な、再利用性の高い検証エージェントや検証プロセスのフレームワークを設計・開発すること。
HRO理論の具体的な応用: HRO理論で提唱されている原則（例: Deference to Expertise, Reluctance to Simplify, Sensitivity to Operations）を、具体的なMASの設計パターンや運用プロトコルとして実装し、その有効性を定量的に評価すること。
自己適応・継続学習システムの実現: システムが長期的な運用を通じて自身の失敗を自動的に検知・記録し、それに基づいて継続的に学習・適応していく、真に自律的な改善メカニズムを構築すること。
人間とエージェントの協調: 人間がMASのループに入り、エージェントの監視、指示、介入を行うハイブリッドなシステムにおいて、効果的なインタラクションデザインと信頼関係構築の方法を探求すること。

これらの課題は、学術界と産業界双方にとって、挑戦的でありながらも非常に重要な研究テーマであり、今後の技術革新が期待される領域です。

5.6 結論：信頼性への多層的アプローチ

本章では、マルチエージェントLLMシステムにおける失敗モードを克服し、より信頼性の高いシステムを構築するための具体的な道筋を探りました。議論された内容は、大きく分けて戦術的アプローチと構造的戦略の二つに分類されます。

プロンプトエンジニアリングの改善やエージェント構成の微調整といった戦術的アプローチは、即効性があり導入も比較的容易ですが、その効果には限界があります。一方で、強力な検証メカニズムの組み込み、標準化されたコミュニケーションプロトコル、不確実性管理、継続的な学習能力の付与といった構造的戦略は、より根本的な改善をもたらす可能性を秘めていますが、実装には相応の努力が必要です。

ケーススタディの結果やHRO理論との比較からも示唆されるように、真に信頼性の高いマルチエージェントLLMシステムを実現するためには、これら両方のアプローチを組み合わせ、システム全体を一つの「組織」として捉え、その設計と運用を根本から見直していくことが不可欠です。この挑戦的な課題に取り組むことが、今後のマルチエージェントシステム研究開発における中心的なテーマの一つとなるでしょう。

第6章ケーススタディ：改善策の有効性を実世界で検証する

前章では、マルチエージェントLLMシステム（MAS）の信頼性を向上させるための様々なアプローチを、 Tactical Approaches（戦術的アプローチ） と Structural Strategies（構造的戦略） という二つの観点から議論しました。理論的な提案や可能性を探ることは重要ですが、それらが実際のシステムにおいてどの程度の効果を発揮するのかを実証的に評価することもまた不可欠です。

本章では、論文中で報告されている具体的なケーススタディ（Case Studies）に焦点を当てます。著者らは、代表的な二つのMASフレームワーク、すなわち AG2 (AutoGen) と ChatDev を取り上げ、前章で提案された改善策、特に 戦術的アプローチ を適用し、その効果を定量的に測定しました。これらの実証実験を通じて、提案された改善策の有効性とその限界を具体的に明らかにしていきます。

6.1 ケーススタディ1：`AG2`を用いた数学問題解決（MathChat）

最初のケーススタディは、Microsoftが開発した柔軟性の高いエージェントフレームワーク AG2 (AutoGen) を対象としています。AG2は、開発者が様々な役割を持つエージェントを定義し、それらを組み合わせて多様なタスクを実行させることができる点が特徴です。

6.1.1 実験の舞台設定：MathChatシナリオ

本研究では、AG2の公式サンプルとしても提供されている MathChat というシナリオに着目しました。MathChatは、数学の文章問題を解くことを目的としたエージェント構成であり、典型的には以下のような役割分担で動作します。

Studentエージェント: 問題文を理解し、解法の方針を自然言語で立案する。
Assistantエージェント: Studentの方針に基づき、具体的な計算を行うためのPythonコードを生成・実行し、最終的な答えを導き出す。

実験タスクとしては、算数・数学の文章問題データセットである GSM-Plus （GSM8Kを拡張したもの）からランダムに抽出された200問が使用されました。

6.1.2 試みられた改善策：プロンプトとトポロジーの変更

このMathChatシナリオに対して、著者らは以下の3つの構成を比較評価しました。

Baseline: 既存のMathChat構成をそのまま使用。これが比較の基準となります。
Improved Prompt（プロンプト改良）: ベースラインの構成は維持しつつ、エージェントに与えるシステムプロンプトに**「最終的な答えを出す前に、計算過程や論理に誤りがないか検証ステップを踏むこと」**といった指示を追加する、比較的手軽な戦術的修正を施しました。
New Topology（新トポロジー）: エージェントの構成自体を変更し、より専門化された3者分業体制を導入しました。
- Problem Solver: 問題を分析し、解法を考案する。
- Coder: Problem Solverの指示に従ってPythonコードを記述・実行する。
- Verifier: Problem Solverの論理とCoderの計算結果を照合し、最終的な答えの妥当性を確認・決定する。

6.1.3 実験結果と洞察：モデル性能と構成変更の影響

実験の結果、いくつかの重要な知見が得られました。

プロンプト改良の効果: 最も性能の高い基盤モデルである**GPT-4**を使用した場合、Improved Prompt構成はBaseline構成と比較して、問題解決の正答率が明確に向上しました（論文中では約+5パーセントポイントの改善）。これは、簡単な検証ステップをプロンプトで促すだけでも、一定の効果があることを示唆しています。
トポロジー変更の限定的な効果: 一方で、より手の込んだNew Topology構成は、Baselineに対してある程度の改善は見られたものの、期待されたほど劇的な性能向上には至りませんでした。著者らは、この理由として、エージェント数を増やしたことによるコミュニケーションオーバーヘッドの増大（エージェント間の情報伝達コストや誤解のリスク）や、導入した**Verifierエージェントが必ずしも全てのエラーを検出しきれなかった**可能性などを指摘しています。役割分担を細かくすることが常に最良の結果をもたらすとは限らない、という教訓が得られます。
基盤モデルへの依存性: 実験では、GPT-4とその派生モデルであるGPT-4o（論文執筆時点ではGPT-4よりやや性能が劣るとされる）を用いた比較も行われました。その結果、プロンプト改良などの改善策の効果は、使用する基盤モデルの性能に依存する傾向が見られました。高性能なGPT-4では改善が顕著に現れる一方で、GPT-4oでは改善幅が小さくなる、あるいは効果が見られないケースもありました。これは、戦術的修正が有効に機能するかどうかは、エージェント自身の基本的な能力にも左右されることを示唆しています。

このAG2のケーススタディは、比較的シンプルな戦術的修正（プロンプト改良）が有効な場合もある一方で、エージェント構成の変更は必ずしも性能向上に直結せず、むしろ新たな課題を生む可能性もあること、そして改善策の効果は基盤となるLLMの性能に大きく依存することを浮き彫りにしました。

6.2 ケーススタディ2：`ChatDev`を用いたソフトウェア自動生成

二つ目のケーススタディは、清華大学の研究チームによって開発された ChatDev フレームワークを対象としています。ChatDevは、ソフトウェア開発企業における様々な役割（例: CEO、最高製品責任者(CPO)、最高技術責任者(CTO)、プログラマ、レビュアー、テスターなど）をLLMエージェントに割り当て、それらが あたかも仮想的な開発チームのように対話しながら ソフトウェアを設計、実装、テストしていくプロセスをシミュレートします。

しかしながら、第4章で述べた先行分析（Study Findings）において、ChatDevはしばしば Disobey Task Specification （ユーザーの要求仕様を満たさない）や No or incomplete verification （不十分なテスト）といった失敗を犯し、結果として完成度の低い、あるいは要求と異なるプログラムを出力してしまう傾向があることが明らかになっていました。

6.2.1 実験の舞台設定：プログラミングベンチマーク

このChatDevの課題を克服するため、著者らは以下の二つのベンチマークを用いて改善実験を行いました。

ProgramDevベンチマーク: 著者らが独自に作成した32個の比較的小規模なプログラミングタスクセット。具体例としては、「ターミナル上で動作するシンプルなチェスゲーム」「BMI（体格指数）を計算するコマンドラインツール」などが含まれます。これらのタスクは、単なるコード生成だけでなく、ある程度の仕様理解や対話を通じた協調が求められます。
HumanEvalベンチマーク: OpenAIによって開発された、Pythonの関数実装能力を評価するための標準的なベンチマーク。与えられたdocstring（関数の説明と入出力例）に基づいて関数を実装し、付属の単体テストが全てパスするかどうかで評価されます。

6.2.2 試みられた改善策：役割プロンプトとワークフローの改良

ChatDevに対して、以下の二種類の戦術的な改善策が適用されました。

Role-Specific Prompt Refinement（役割別プロンプトの厳密化）: ChatDev内の各役割（CEO, Programmer, Testerなど）に与えられるシステムプロンプトの内容をより詳細かつ厳密にしました。例えば、「Programmerは実装のみに専念し、設計に関する最終決定権はCTOが持つ」「Testerは単にコードが実行できるかだけでなく、具体的なテストシナリオに基づいて機能要件を満たしているかを検証すべし」といった指示を強化し、役割の逸脱や責任の曖昧さを減らすことを目指しました。
Topology Redesign（トポロジー再設計）: 元々のChatDevのワークフローは、設計→実装→テスト→文書化といったフェーズを比較的直線的に進む構成でした。これを改良し、特に実装（コーディング）と検証（レビュー、テスト）のフェーズ間で反復的なループ構造を導入しました。これにより、一度テストで問題が発見された場合に、実装フェーズに戻ってコードを修正し、再度テストにかける、というイテレーティブな開発プロセスをより忠実に模倣できるようにしました。

6.2.3 実験結果と洞察：タスク特性による効果の違い

これらの改善策を適用した結果、以下の点が明らかになりました。

ProgramDevにおける顕著な改善: 比較的複雑な要求を含むProgramDevベンチマークにおいては、改善策の効果は顕著でした。ベースライン構成でのタスク達成率（要求仕様を完全に満たすコードが生成された割合）が約25%だったのに対し、改善後の構成では約40%まで向上しました。これは、役割分担の明確化や反復的な検証ループの導入が、より複雑な協調作業においては有効であることを示唆しています。
HumanEvalにおける限定的な改善: 一方、HumanEvalベンチマークにおいては、ベースラインの達成率が元々89.6%と非常に高かったこともあり、改善策を施しても達成率は90～91%程度と、ごくわずかな向上にとどまりました。著者らはこの理由として、HumanEvalのタスクが比較的シンプルで自己完結した関数実装問題であり、そもそもマルチエージェントによる協調作業のメリットが発揮されにくい性質を持っているためではないかと考察しています。実際、単一のLLMを用いたChain-of-Thoughtプロンプティングでも高いスコアが得られることが知られています。
残存する課題: ProgramDevで達成率が向上したとはいえ、依然として60%近くのタスクでは失敗していることも事実です。ログを分析すると、改善後も仕様の抜け漏れやテストの不十分さといった問題は完全には解消されておらず、これらの戦術的修正だけでは限界があることが確認されました。

このChatDevのケーススタディは、適用するタスクの性質によって改善策の効果が大きく異なる こと、そして役割分担の明確化や検証プロセスの強化といった戦術的アプローチが一定の効果を示すものの、依然として多くの失敗が残存 することを示しました。

6.3 ケーススタディからの教訓：戦術的修正の限界

これら二つのケーススタディ（AG2とChatDev）を通じて、一貫して見えてきた重要な結論は、「ある程度の戦術的修正（プロンプトの改善、役割定義の見直し、簡単な検証ステップの追加など）は、短期的かつ限定的ながらパフォーマンス向上に寄与する可能性がある。しかし、それだけではマルチエージェントシステムが抱える深刻な失敗モードを根絶するには不十分である」ということです。

AG2(MathChat)の例では、検証ステップの追加や分業体制の導入が、必ずしも最適な結果をもたらさず、新たなコミュニケーションコストを生む可能性が示されました。
ChatDevの例では、役割の明確化や反復的な検証ループによって成功率は向上したものの、依然として多くのタスクで失敗しており、より根本的な対策の必要性が浮き彫りになりました。

これらの結果は、前章で議論された戦術的アプローチの限界を実証的に裏付けるものと言えます。

6.4 今後の方向性への示唆：バランスの重要性

これらのケーススタディは、今後のマルチエージェントシステム研究開発に向けて、いくつかの重要な示唆を与えています。

基盤モデル性能の影響: 使用するLLMの基本性能が高いほど、戦術的な改善策の効果も現れやすい傾向があります。逆に言えば、性能の低いモデルを用いている場合、小手先の修正だけでは効果が限定的になる可能性があります。システムのポテンシャルを最大限に引き出すためには、高性能な基盤モデルの選択と、それに合わせたチューニングが重要です。
構造的アプローチの必要性: ケーススタディで示された限界を踏まえれば、やはりより抜本的な構造的戦略（強力な検証フレームワーク、標準化されたコミュニケーションプロトコル、強化学習による協調動作の最適化、HRO理論に基づいた組織設計など）の導入が、真に信頼性の高いMASを実現するためには不可欠であると言えます。
タスク特性とシステム設計のバランス: マルチエージェント化による恩恵（タスク分割、並列処理、専門知識の活用など）は、タスクの性質や複雑さ、そしてシステムの設計によって大きく左右されます。HumanEvalの例のように、タスクが単純すぎるとMAS化のメリットが得られない場合もあります。したがって、「とりあえずマルチエージェントにすれば良い」というわけではなく、解決したい課題の特性をよく分析し、それに最適なシステムアーキテクチャ（シングルエージェントが良いのか、どのような役割分担のマルチエージェントが良いのか）を慎重に選択・設計する必要があります。

6.5 結論：実証が示す信頼性への道

本章で紹介した二つのケーススタディは、マルチエージェントLLMシステムの改善に向けた具体的な取り組みとその結果を提示しました。AG2を用いた数学問題解決とChatDevを用いたソフトウェア生成の実験は、プロンプトの改良や役割定義の見直しといった戦術的アプローチが一定の効果を示す場合があることを実証しました。

しかし同時に、これらの戦術的修正だけではシステムの根本的な問題を解決するには限界があることも明確になりました。依然として多くの失敗が残存し、タスクの性質や使用する基盤モデルによって効果が大きく変動することも示されました。

これらの実証結果は、マルチエージェントシステムの信頼性を真に向上させるためには、状況に応じた戦術的な改善努力と、より大局的かつ根本的な構造改革（構造的戦略）の両方を視野に入れた、多層的なアプローチが必要であることを強く裏付けています。今後の研究開発においては、これらの実証的な知見を踏まえ、より効果的で信頼性の高いシステム設計を目指していくことが求められます。

第7章結論：マルチエージェントシステムの未来を拓くために

論文を通じて、著者はマルチエージェントLLMシステム（MAS）の複雑な世界を探求し、特にその信頼性を脅かす「失敗」のメカニズムに焦点を当ててきました。出発点となったのは、「複数のLLMエージェントを連携させれば、より高度なタスクが遂行できるはず」という期待とは裏腹に、しばしば予期せぬ問題が発生し、その原因が必ずしも明確ではなかったという課題認識でした。

本章では、これまでの議論全体を総括し、本研究が達成した主要な成果、そこから導き出される結論、そしてマルチエージェントシステムのさらなる発展に向けた今後の展望を提示します。

7.1 本研究の中核的貢献：`MASFT`の確立

本研究における最大の貢献は、マルチエージェントLLMシステムにおける失敗モードを体系的に調査し、その結果として　MASFT (Multi-Agent System Failure Taxonomy)　を提案した点にあります。

我々は、5つ以上の代表的なMASフレームワークから収集した150を超える実行トレース（対話ログ）を、Grounded Theoryに基づく厳密な質的手法を用いて分析しました。
その結果、単一LLMの既知の問題（例: 幻覚）や、従来のマルチエージェント研究で扱われてきた課題とは異なる、複数の汎用LLMが自然言語で協調する際に特有の失敗パターンを多数発見しました。
これらの失敗パターンを整理・統合し、最終的に3つの主要カテゴリ（FC1: 設計・仕様、FC2: エージェント間不整合、FC3: 検証・終了）と、それに属する14の具体的な失敗モードから成るMASFTを構築しました。

このMASFTは、マルチエージェントLLM固有の失敗を初めて包括的かつ体系的に可視化した分類体系であり、今後のMASの研究開発において、失敗を議論し、評価し、対策を講じるための共通言語および評価基盤となることが期待されます。これにより、開発者や研究者は、単なる直感や個別事例の分析を超え、システム横断的に失敗モードを理解し、比較検討することが可能になります。

7.2 自動評価への道：`LLM-as-a-Judge`の可能性

失敗モードを特定するだけでなく、その分析プロセス自体の効率化も重要な課題です。本研究では、人手によるアノテーション作業の負担を軽減し、スケーラビリティを向上させる試みとして、 LLM自身に失敗モードの分類を行わせるLLM-as-a-Judge という手法を開発・評価しました。

実験の結果、LLM-as-a-Judgeは、人間アノテータによる評価と 高い一致度（Cohen's Kappa ≈ 0.77） を示すことが確認されました。
これは、適切に設計されたプロンプトとMASFTのような明確な分類体系があれば、LLMがある程度の信頼性をもって失敗モードの自動判定を行える可能性を示唆しています。

この成果は、将来的に大量のMASログを効率的に分析・評価する上で極めて重要です。例えば、開発中のシステムの継続的なモニタリング、運用中のシステムにおける異常検知、あるいは大規模なベンチマーク評価などを、より迅速かつ低コストで実施できる道を開く可能性があります。定性的な理解から、より大規模な定量的分析へと移行するための重要な一歩と言えるでしょう。

7.3 改善への道筋：戦術と構造のバランス

MASFTによって失敗モードが明らかになったことを受け、我々は第5章および第6章でその改善策を探求しました。その議論とケーススタディを通じて得られた重要な結論は、**Tactical Approaches（戦術的アプローチ）とStructural Strategies（構造的戦略）**の両方が必要であるということです。

戦術的アプローチ（プロンプトの改善、役割定義の厳密化、簡単な検証ステップの追加など）は、比較的容易に導入でき、一部の失敗モードに対しては明確な改善効果を示します。
しかし、ケーススタディが示したように、これらの戦術的修正だけでは、コミュニケーション不全や仕様逸脱といった根深い問題を完全に解決するには限界があります。
したがって、真に信頼性の高いMASを実現するためには、より抜本的な構造的戦略（強力な検証フレームワークの組み込み、標準化されたコミュニケーションプロトコル、不確実性管理、継続的な学習能力の付与、HRO理論に学ぶ組織設計など）が不可欠となります。

今後のMAS開発においては、短期的な改善をもたらす戦術的アプローチと、長期的な信頼性向上を目指す構造的戦略を、状況に応じてバランス良く組み合わせていくことが求められます。

7.4 未来への羅針盤：今後の研究課題

本研究は、マルチエージェントLLMシステムの失敗に関する理解を大きく前進させましたが、同時に多くの新たな研究課題も浮き彫りにしました。今後の研究開発が注力すべき重要な方向性として、以下のようなテーマが挙げられます。

汎用的な検証エージェントとフレームワーク: 特定のタスクやドメインに依存せず、様々なMASの出力や内部プロセスを効果的に検証できる、再利用可能で汎用的な検証コンポーネントをどのように設計・構築するか。
学習による協調動作の最適化: 強化学習（RL）や模倣学習、あるいは失敗事例からの継続学習といった手法を用いて、エージェント群が自律的に最適なコミュニケーション戦略や役割分担、エラー対処方法などを学習していくメカニズムの開発。
HRO理論の具体的な応用: 高信頼組織（HRO）で培われてきたリスク管理、コミュニケーション、意思決定に関する原則を、どのようにMASのアーキテクチャや運用プロトコルに具体的に落とし込み、その有効性を検証するか。
コミュニケーションプロトコルの標準化と進化: 自然言語の柔軟性を維持しつつ、曖昧さを排除し、より効率的で信頼性の高い情報交換を実現するための、形式化されたコミュニケーションプロトコルやインターフェースの設計。これには、ツール利用や外部API連携の標準化も含まれます。

これらの課題に取り組むことは、MASの能力をさらに引き出し、より複雑でミッションクリティカルな応用への道を開く上で不可欠です。

7.5 総括：本研究が切り拓いた地平

本研究は、マルチエージェントLLMシステムの領域において、以下の3つの主要な意義を持つと考えられます。

第一に、MAS固有の失敗モードを大規模な実証データに基づいて初めて体系的に解明し、共通の理解基盤となるMASFTを提示しました。 これにより、MASの信頼性に関する議論が、より具体的かつ建設的に進められるようになります。
第二に、LLM-as-a-Judgeという自動評価手法の可能性を示し、今後の大規模なログ分析やデバッグ、継続的モニタリングの効率化に貢献する道筋をつけました。これは、研究から実用化への移行を加速させる上で重要な要素です。
第三に、「複数のLLMをいかに組織化するか」という、従来のLLM研究とは異なる新たな視点を提示し、高信頼組織（HRO）理論のような他分野の知見との接続点を示しました。これは、LLM研究が、単なる技術開発だけでなく、より広範なシステム工学や組織科学との学際的な連携を深めていく必要性を示唆しています。

7.6 まとめ

結論として、本研究は、マルチエージェントLLMシステム（MAS）の失敗が、単に構成要素である個々のLLMの能力不足に起因するだけでなく、それらを知的に連携させるシステム設計、エージェント間のコミュニケーション、そして最終的な検証プロセスといった、多岐にわたる要因によって引き起こされることを明らかにしました。

我々が提案した失敗分類体系MASFTや、議論した改善策、そして示した今後の研究方向性が、このエキサイティングな分野における将来の研究開発、そしてより信頼性が高く有用なマルチエージェントシステムの実現に向けた一助となることを願っています。

マルチエージェントLLMの未来は、単に 「より賢い個」 を追求するだけでは切り拓けません。むしろ、 「複数の知能をいかに効果的に組織化し、協調させ、その集合体としての信頼性をいかに担保するか」 という、より高度なシステム設計と組織論的な挑戦にこそ、その鍵が隠されていると言えるでしょう。この視点を持ち続けることが、これからのMAS研究開発において、ますます重要になっていくはずです。

References

Anne et al. (2024)Anne, T., Syrkis, N., Elhosni, M., Turati, F., Legendre, F., Jaquier, A., and Risi, S.Harnessing language for coordination: A framework and benchmark for llm-driven multi-agent control.arXiv preprint arXiv:2412.11761, 2024.　https://arxiv.org/abs/2412.11761
Anthropic (2024a)Anthropic, Dec 2024a.URL https://www.anthropic.com/research/building-effective-agents.
Anthropic (2024b)Anthropic.Building effective agents, 2024b.URL https://www.anthropic.com/research/building-effective-agents.
Bansal et al. (2024)Bansal, G., Wortman Vaughan, J., Amershi, S., Horvitz, E., Fourney, A., Mozannar, H., Dibia, V., and Weld, D. S.
Challenges in human-agent communication.Technical Report MSR-TR-2024-53, Microsoft, December 2024.URL https://www.microsoft.com/en-us/research/publication/human-agent-interaction-challenges/
Bettini et al. (2024)Bettini, M., Prorok, A., and Moens, V.
Benchmark: Benchmarking multi-agent reinforcement learning.Journal of Machine Learning Research, 25(217):1–10, 2024. https://arxiv.org/abs/2312.01472
Chakraborty & Purkayastha (2023)Chakraborty, B. and Purkayastha, D.
Servicenow: From startup to world’s most innovative company.IUP Journal of Entrepreneurship Development, 20(1), 2023. https://www.icmrindia.org/casestudies/catalogue/Leadership and Entrepreneurship/LDEN155.htm
Chan et al. (2023)Chan, C.-M., Chen, W., Su, Y., Yu, J., Xue, W., Zhang, S., Fu, J., and Liu, Z.
Chateval: Towards better llm-based evaluators through multi-agent debate.arXiv preprint arXiv:2308.07201, 2023. https://arxiv.org/abs/2308.07201
Chen et al. (2024a)Chen, L., Davis, J. Q., Hanin, B., Bailis, P., Stoica, I., Zaharia, M., and Zou, J.
Are more llm calls all you need? towards scaling laws of compound inference systems.arXiv preprint arXiv:2403.02419, 2024a. https://arxiv.org/abs/2403.02419
Chen et al. (2024b)Chen, W., Yuan, J., Qian, C., Yang, C., Liu, Z., and Sun, M.
Optima: Optimizing effectiveness and efficiency for llm-based multi-agent system.arXiv preprint arXiv:2410.08115, 2024b. https://arxiv.org/abs/2410.08115
Cheng et al. (2024)Cheng, Y., Zhang, C., Zhang, Z., Meng, X., Hong, S., Li, W., Wang, Z., Wang, Z., Yin, F., Zhao, J., et al.
Exploring large language model based intelligent agents: Definitions, methods, and prospects.arXiv preprint arXiv:2401.03428, 2024. https://arxiv.org/abs/2401.03428
Cobbe et al. (2021)Cobbe, K., Kosaraju, V., Bavarian, M., Chen, M., Jun, H., Kaiser, L., Plappert, M., Tworek, J., Hilton, J., Nakano, R., et al.
Training verifiers to solve math word problems.arXiv preprint arXiv:2110.14168, 2021. https://arxiv.org/abs/2110.14168
Draucker et al. (2007)Draucker, C. B., Martsolf, D. S., Ross, R., and Rusk, T. B.
Theoretical sampling and category development in grounded theory.Qualitative health research, 17(8):1137–1148, 2007.
Du et al. (2023)Du, Y., Li, S., Torralba, A., Tenenbaum, J. B., and Mordatch, I.
Improving factuality and reasoning in language models through multiagent debate, 2023.URL https://arxiv.org/abs/2305.14325.
Glaser & Strauss (1967)Glaser, B. G. and Strauss, A. L.
The Discovery of Grounded Theory: Strategies for Qualitative Research.Aldine Publishing Company, 1967.
Gottweis et al. (2025)Gottweis, J., Weng, W.-H., Daryin, A., Tu, T., Palepu, A., Sirkovic, P., Myaskovsky, A., Weissenberger, F., Rong, K., Tanno, R., Saab, K., Popovici, D., Blum, J., Zhang, F., Chou, K., Hassidim, A., Gokturk, B., Vahdat, A., Kohli, P., Matias, Y., Carroll, A., Kulkarni, K., Tomasev, N., Guan, Y., Dhillon, V., Vaishnav, E. D., Lee, B., Costa, T. R. D., Penadés, J. R., Peltz, G., Xu, Y., Pawlosky, A., Karthikesalingam, A., and Natarajan, V.
Towards an ai co-scientist, 2025.URL https://arxiv.org/abs/2502.18864.
Guo et al. (2024a)Guo, T., Chen, X., Wang, Y., Chang, R., Pei, S., Chawla, N. V., Wiest, O., and Zhang, X.
Large language model based multi-agents: A survey of progress and challenges.arXiv preprint arXiv:2402.01680, 2024a. https://arxiv.org/abs/2402.01680
Guo et al. (2024b)Guo, X., Shi, D., Yu, J., and Fan, W.
Heterogeneous multi-agent reinforcement learning for zero-shot scalable collaboration.arXiv preprint arXiv:2404.03869, 2024b. https://arxiv.org/abs/2404.03869
Haji et al. (2024)Haji, F., Bethany, M., Tabar, M., Chiang, J., Rios, A., and Najafirad, P.
Improving llm reasoning with multi-agent tree-of-thought validator agent.arXiv preprint arXiv:2409.11527, 2024. https://arxiv.org/abs/2409.11527
He et al. (2024a)He, J., Rungta, M., Koleczek, D., Sekhon, A., Wang, F. X., and Hasan, S.
Does prompt formatting have any impact on llm performance?arXiv preprint arXiv:2411.10541, 2024a. https://arxiv.org/abs/2411.10541
He et al. (2024b)He, J., Treude, C., and Lo, D.
Llm-based multi-agent systems for software engineering: Vision and the road ahead, 2024b.URL https://arxiv.org/abs/2404.04834.
Hong et al. (2023)Hong, S., Zheng, X., Chen, J., Cheng, Y., Wang, J., Zhang, C., Wang, Z., Yau, S. K. S., Lin, Z., Zhou, L., et al.
Metagpt: Meta programming for multi-agent collaborative framework.arXiv preprint arXiv:2308.00352, 2023. https://arxiv.org/abs/2308.00352
Horvitz (1999)Horvitz, E.
Uncertainty, action, and interaction: In pursuit of mixed-initiative computing.IEEE Intelligent Systems, 14(5):17–20, 1999. http://erichorvitz.com/ftp/mixedin.pdf
Jain et al. (2024)Jain, K., Synnaeve, G., and Rozière, B.
Testgeneval: A real world unit test generation and test completion benchmark.arXiv preprint arXiv:2410.00752, 2024. https://arxiv.org/abs/2410.00752
Jiang & Lu (2018)Jiang, J. and Lu, Z.
Learning attentional communication for multi-agent cooperation.Advances in neural information processing systems, 31, 2018. https://arxiv.org/abs/1805.07733
Jimenez et al. (2024)Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., and Narasimhan, K. R.
SWE-bench: Can language models resolve real-world github issues?In The Twelfth International Conference on Learning Representations, 2024.
URL https://openreview.net/forum?id=VTF8yNQM66.
https://arxiv.org/abs/2310.06770
Kapanipathi et al. (2020)Kapanipathi, P., Abdelaziz, I., Ravishankar, S., Roukos, S., Gray, A., Astudillo, R., Chang, M., Cornelio, C., Dana, S., Fokoue, A., et al.
Question answering over knowledge bases by leveraging semantic parsing and neuro-symbolic reasoning.arXiv preprint arXiv:2012.01707, 2020. https://www.academia.edu/68569473/Question_Answering_over_Knowledge_Bases_by_Leveraging_Semantic_Parsing_and_Neuro_Symbolic_Reasoning
https://arxiv.org/abs/2012.01707
Kapoor et al. (2024)Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N., and Narayanan, A.
Ai agents that matter, 2024.URL https://arxiv.org/abs/2407.01502.
Khandkar (2009)Khandkar, S. H.
Open coding.University of Calgary, 23(2009):2009, 2009.
Khattab et al. (2023)Khattab, O., Singhvi, A., Maheshwari, P., Zhang, Z., Santhanam, K., Vardhamanan, S., Haq, S., Sharma, A., Joshi, T. T., Moazam, H., Miller, H., Zaharia, M., and Potts, C.
Dspy: Compiling declarative language model calls into self-improving pipelines, 2023.URL https://arxiv.org/abs/2310.03714.
Lalitha et al. (2018)Lalitha, A., Javidi, T., and Sarwate, A. D.
Social learning and distributed hypothesis testing.IEEE Transactions on Information Theory, 64(9):6161–6179, 2018. https://arxiv.org/abs/1410.4307
LangChain (2024)
LangChain.Langgraph, 2024.URL https://www.langchain.com/langgraph.
Li et al. (2023)Li, G., Hammoud, H., Itani, H., Khizbullin, D., and Ghanem, B.
Camel: Communicative agents for” mind” exploration of large language model society.Advances in Neural Information Processing Systems, 36:51991–52008, 2023. https://arxiv.org/abs/2303.17760
Li et al. (2024a)Li, Q., Cui, L., Zhao, X., Kong, L., and Bi, W.
Gsm-plus: A comprehensive benchmark for evaluating the robustness of llms as mathematical problem solvers.arXiv preprint arXiv:2402.19255, 2024a. https://arxiv.org/abs/2402.19255
Li et al. (2024b)Li, X., Wang, S., Zeng, S., Wu, Y., and Yang, Y.
A survey on llm-based multi-agent systems: workflow, infrastructure, and challenges.Vicinagearth, 1(1):9, 2024b. https://arxiv.org/abs/2412.17481v2
Li et al. (2024c)Li, Z., Zang, Q., Ma, D., Guo, J., Zheng, T., Liu, M., Niu, X., Wang, Y., Yang, J., Liu, J., et al.
Autokaggle: A multi-agent framework for autonomous data science competitions.arXiv preprint arXiv:2410.20424, 2024c. https://arxiv.org/abs/2410.20424
Liang et al. (2025)Liang, X., Xiang, J., Yu, Z., Zhang, J., and Hong, S.
Openmanus: An open-source framework for building general ai agents.https://github.com/mannaandpoem/OpenManus, 2025.
Liu et al. (2023)Liu, Y., Yao, Y., Ton, J.-F., Zhang, X., Cheng, R. G. H., Klochkov, Y., Taufiq, M. F., and Li, H.
Trustworthy llms: A survey and guideline for evaluating large language models’ alignment.arXiv preprint arXiv:2308.05374, 2023. https://arxiv.org/abs/2308.05374
Long et al. (2024)Long, Q., Li, Z., Gong, R., Wu, Y. N., Terzopoulos, D., and Gao, X.
Teamcraft: A benchmark for multi-modal multi-agent systems in minecraft.arXiv preprint arXiv:2412.05255, 2024. https://arxiv.org/abs/2412.05255
Mandi et al. (2023)Mandi, Z., Jain, S., and Song, S.
Roco: Dialectic multi-robot collaboration with large language models, 2023.URL https://arxiv.org/abs/2307.04738.
McHugh (2012)McHugh, M. L.
Interrater reliability: the kappa statistic.Biochemia medica, 22(3):276–282, 2012. https://pubmed.ncbi.nlm.nih.gov/23092060/
Niu et al. (2021)Niu, Y., Paleja, R. R., and Gombolay, M. C.
Multi-agent graph-attention communication and teaming.In AAMAS, volume 21, pp. 20th, 2021. https://www.ifaamas.org/Proceedings/aamas2021/pdfs/p964.pdf
Packer et al. (2023)Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., and Gonzalez, J. E.Memgpt: Towards llms as operating systems.arXiv preprint arXiv:2310.08560, 2023.
Packer et al. (2024)Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., and Gonzalez, J. E.Memgpt: Towards llms as operating systems, 2024.URL https://arxiv.org/abs/2310.08560.
Park et al. (2023a)Park, J. S., O’Brien, J., Cai, C. J., Morris, M. R., Liang, P., and Bernstein, M. S.
Generative agents: Interactive simulacra of human behavior.In Proceedings of the 36th annual acm symposium on user interface software and technology, pp. 1–22, 2023a.
Park et al. (2023b)Park, J. S., O’Brien, J. C., Cai, C. J., Morris, M. R., Liang, P., and Bernstein, M. S.
Generative agents: Interactive simulacra of human behavior, 2023b.URL https://arxiv.org/abs/2304.03442.
Patil et al. (2023)Patil, S. G., Zhang, T., Wang, X., and Gonzalez, J. E.
Gorilla: Large language model connected with massive apis, 2023.URL https://arxiv.org/abs/2305.15334.
Peng et al. (2023)Peng, B., Galley, M., He, P., Cheng, H., Xie, Y., Hu, Y., Huang, Q., Liden, L., Yu, Z., Chen, W., et al.
Check your facts and try again: Improving large language models with external knowledge and automated feedback.arXiv preprint arXiv:2302.12813, 2023. https://arxiv.org/abs/2302.12813
Peng et al. (2024)Peng, J.-L., Cheng, S., Diau, E., Shih, Y.-Y., Chen, P.-H., Lin, Y.-T., and Chen, Y.-N.
A survey of useful llm evaluation.arXiv preprint arXiv:2406.00936, 2024. https://arxiv.org/abs/2406.00936
Perrow (1984)Perrow, C.Normal Accidents: Living with High-Risk Technologies.Princeton University Press, Princeton, NJ, 1984.ISBN 978-0691004129.
Phan et al. (2024)Phan, H. N., Nguyen, T. N., Nguyen, P. X., and Bui, N. D.
Hyperagent: Generalist software engineering agents to solve coding tasks at scale.arXiv preprint arXiv:2409.16299, 2024. https://arxiv.org/abs/2409.16299
Qian et al. (2023)Qian, C., Liu, W., Liu, H., Chen, N., Dang, Y., Li, J., Yang, C., Chen, W., Su, Y., Cong, X., Xu, J., Li, D., Liu, Z., and Sun, M.
Chatdev: Communicative agents for software development.arXiv preprint arXiv:2307.07924, 2023.URL https://arxiv.org/abs/2307.07924.
Qian et al. (2024)Qian, C., Liu, W., Liu, H., Chen, N., Dang, Y., Li, J., Yang, C., Chen, W., Su, Y., Cong, X., et al.
Chatdev: Communicative agents for software development.In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 15174–15186, 2024. https://aclanthology.org/2024.acl-long.810/
Roberts & Rousseau (1989)Roberts, K. and Rousseau, D.
Research in nearly failure-free, high-reliability organizations: having the bubble.IEEE Transactions on Engineering Management, 36(2):132–139, 1989.doi: 10.1109/17.18830. https://ieeexplore.ieee.org/document/18830
Roberts (1989)Roberts, K. H.
New challenges in organizational research: High reliability organizations.Organization & Environment, 3(2):111–125, 1989.doi: 10.1177/108602668900300202. https://journals.sagepub.com/doi/10.1177/108602668900300202
Rochlin (1996)Rochlin, G. I.
Reliable organizations: Present research and future directions.Journal of contingencies and crisis management., 4(2), 1996.ISSN 0966-0879. https://onlinelibrary.wiley.com/doi/10.1111/j.1468-5973.1996.tb00077.x
Singh et al. (2018)Singh, A., Jain, T., and Sukhbaatar, S.
Learning when to communicate at scale in multiagent cooperative and competitive tasks.arXiv preprint arXiv:1812.09755, 2018. https://arxiv.org/abs/1812.09755
Stoica et al. (2024a)Stoica, I., Zaharia, M., Gonzalez, J., Goldberg, K., Sen, K., Zhang, H., Angelopoulos, A., Patil, S. G., Chen, L., Chiang, W.-L., and Davis, J. Q.
Specifications: The missing link to making the development of llm systems an engineering discipline, 2024a.URL https://arxiv.org/abs/2412.05299.
Stoica et al. (2024b)Stoica, I., Zaharia, M., Gonzalez, J., Goldberg, K., Zhang, H., Angelopoulos, A., Patil, S. G., Chen, L., Chiang, W.-L., and Davis, J. Q.
Specifications: The missing link to making the development of llm systems an engineering discipline.arXiv preprint arXiv:2412.05299, 2024b.
Stroebl et al. (2024)Stroebl, B., Kapoor, S., and Narayanan, A.
Inference scaling f laws: The limits of llm resampling with imperfect verifiers.arXiv preprint arXiv:2411.17501, 2024. https://arxiv.org/abs/2411.17501
Swanson et al. (2024)Swanson, K., Wu, W., Bulaong, N. L., Pak, J. E., and Zou, J.
The virtual lab: Ai agents design new sars-cov-2 nanobodies with experimental validation.bioRxiv, 2024.doi: 10.1101/2024.11.11.623004.URL https://www.biorxiv.org/content/early/2024/11/12/2024.11.11.623004.
Talebirad & Nadiri (2023)Talebirad, Y. and Nadiri, A.
Multi-agent collaboration: Harnessing the power of intelligent llm agents.arXiv preprint arXiv:2306.03314, 2023. https://arxiv.org/abs/2306.03314
Tolstoy (1878)Tolstoy, L.Anna Karenina.The Russian Messenger, 1878.
Trivedi et al. (2024)Trivedi, H., Khot, T., Hartmann, M., Manku, R., Dong, V., Li, E., Gupta, S., Sabharwal, A., and Balasubramanian, N.
Appworld: A controllable world of apps and people for benchmarking interactive coding agents.arXiv preprint arXiv:2407.18901, 2024. https://arxiv.org/abs/2407.18901
Wang et al. (2024a)Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., Zhao, W. X., Wei, Z., and Wen, J.
A survey on large language model based autonomous agents.Frontiers of Computer Science, 18(6), March 2024a.ISSN 2095-2236.doi: 10.1007/s11704-024-40231-1.URL http://dx.doi.org/10.1007/s11704-024-40231-1.
Wang et al. (2024b)Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., et al.
A survey on large language model based autonomous agents.Frontiers of Computer Science, 18(6):186345, 2024b. https://arxiv.org/abs/2308.11432
Wang et al. (2024c)Wang, W., Zhang, D., Feng, T., Wang, B., and Tang, J.
Battleagentbench: A benchmark for evaluating cooperation and competition capabilities of language models in multi-agent systems.arXiv preprint arXiv:2408.15971, 2024c. https://arxiv.org/abs/2408.15971
Wang et al. (2024d)Wang, X., Li, B., Song, Y., Xu, F. F., Tang, X., Zhuge, M., Pan, J., Song, Y., Li, B., Singh, J., Tran, H. H., Li, F., Ma, R., Zheng, M., Qian, B., Shao, Y., Muennighoff, N., Zhang, Y., Hui, B., Lin, J., Brennan, R., Peng, H., Ji, H., and Neubig, G.
Openhands: An open platform for ai software developers as generalist agents, 2024d.URL https://arxiv.org/abs/2407.16741.
Wang et al. (2024e)Wang, Z. Z., Mao, J., Fried, D., and Neubig, G.
Agent workflow memory, 2024e.URL https://arxiv.org/abs/2409.07429.
Weng et al. (2023)Weng, Y., Zhu, M., Xia, F., Li, B., He, S., Liu, S., Sun, B., Liu, K., and Zhao, J.
Large language models are better reasoners with self-verification.In The 2023 Conference on Empirical Methods in Natural Language Processing, 2023. https://arxiv.org/abs/2212.09561
Wu et al. (2023)Wu, Q., Bansal, G., Zhang, J., Wu, Y., Zhang, S., Zhu, E., Li, B., Jiang, L., Zhang, X., and Wang, C.
Autogen: Enabling next-gen llm applications via multi-agent conversation framework.arXiv preprint arXiv:2308.08155, 2023. https://arxiv.org/abs/2308.08155
Wu et al. (2024a)Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., Zhang, S., Liu, J., et al.
Autogen: Enabling next-gen llm applications via multi-agent conversations.In First Conference on Language Modeling, 2024a.
Wu et al. (2024b)Wu, Y., Yue, T., Zhang, S., Wang, C., and Wu, Q.
Stateflow: Enhancing llm task-solving through state-driven workflows, 2024b.URL https://arxiv.org/abs/2403.11322.
Xi et al. (2023)Xi, Z., Chen, W., Guo, X., He, W., Ding, Y., Hong, B., Zhang, M., Wang, J., Jin, S., Zhou, E., et al.
The rise and potential of large language model based agents: A survey.arXiv preprint arXiv:2309.07864, 2023. https://arxiv.org/abs/2309.07864
Xia et al. (2024)Xia, C. S., Deng, Y., Dunn, S., and Zhang, L.
Agentless: Demystifying llm-based software engineering agents, 2024.URL https://arxiv.org/abs/2407.01489.
Xu et al. (2023)Xu, Z., Shi, S., Hu, B., Yu, J., Li, D., Zhang, M., and Wu, Y.
Towards reasoning in large language models via multi-agent peer review collaboration.arXiv preprint arXiv:2311.08152, 2023. https://arxiv.org/abs/2311.08152
Yao et al. (2024a)Yao, S., Yu, D., Zhao, J., Shafran, I., Griffiths, T., Cao, Y., and Narasimhan, K.
Tree of thoughts: Deliberate problem solving with large language models.Advances in Neural Information Processing Systems, 36, 2024a. https://arxiv.org/abs/2305.10601
Yao et al. (2024b)Yao, Y., Duan, J., Xu, K., Cai, Y., Sun, Z., and Zhang, Y.
A survey on large language model (llm) security and privacy: The good, the bad, and the ugly.High-Confidence Computing, pp. 100211, 2024b. https://arxiv.org/abs/2312.02003
Yu et al. (2022)Yu, C., Velu, A., Vinitsky, E., Gao, J., Wang, Y., Bayen, A., and Wu, Y.
The surprising effectiveness of ppo in cooperative multi-agent games.Advances in Neural Information Processing Systems, 35:24611–24624, 2022. https://arxiv.org/abs/2103.01955
Zhang et al. (2024)Zhang, H., Du, W., Shan, J., Zhou, Q., Du, Y., Tenenbaum, J. B., Shu, T., and Gan, C.
Building cooperative embodied agents modularly with large language models, 2024.URL https://arxiv.org/abs/2307.02485.
Zheng et al. (2023)Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Li, D., Xing, E. P., Zhang, H., Gonzalez, J. E., and Stoica, I.
Judging llm-as-a-judge with mt-bench and chatbot arena, 2023.URL https://arxiv.org/abs/2306.05685.

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up