マルチエージェントシステムは、現代のAIの文脈において、複数の異なるAIエージェントインスタンスが互いに相互作用するアーキテクチャであり、典型的には協力、分業、または互いの作業の検証を通じて、単一のエージェント単独では効果的に処理できないタスクを達成する。各エージェントは通常、大規模言語モデル上に構築され、多くの場合、独自のシステムプロンプトを通じて明確な役割、ペルソナ、またはツールセットが与えられ、エージェント同士はメッセージの受け渡し、共有ワークスペース、または共通の状態への読み書きによって通信する。
マルチエージェントシステムの概念は大規模言語モデルよりはるかに古く、分散人工知能や強化学習研究において、独立したエージェントが共有環境内で協力または競争する方法を研究する長い歴史がある。LLM固有のこのアイデアのバージョンは、2023年から2025年にかけてのより広範なエージェントの波から直接発展した。個々のエージェントがツール使用を用いて多段階タスクを完了するのに十分信頼できるようになるにつれ、研究者や開発者は、ソフトウェア開発、研究、討論など、自然な役割分担を持つタスクを処理するために、複数のエージェントを組み合わせ始めた。
一般的なパターン
マルチエージェントフレームワークには、いくつかの組織パターンが繰り返し見られる。オーケストレーター・ワーカーパターンでは、1つのエージェントがタスクをサブタスクに分割し、専門化されたワーカーエージェントにそれらを割り当て、その後結果を統合する。この構造は、複数のサブトピックを並行して調査するなど、自然に分解できるタスクに適している。討論または批評パターンでは、2つ以上のエージェントが回答を提案するか、最終回答が生成される前に互いの推論を批評し、単一のモデルでは単独で見つけられないエラーを表面化することを目的とする。パイプラインパターンでは、エージェントが固定された順序で配置され、各エージェントがより大きなプロセスの1つの段階を処理する。例えば、草稿作成エージェントに続いて編集エージェントと事実確認エージェントが続く。一部のシステムでは、エージェント同士が直接メッセージを渡すのではなく、複数のエージェントが非同期的に読み書きする共有ブラックボードまたはドキュメントも使用される。
利点と根拠
支持者は、それぞれがより狭い役割と対応してより単純なプロンプトを持つ専門化されたエージェント間で複雑なタスクを分割することで、1つのエージェントに複雑なタスク全体を一度に保持させるよりも、特に単一のコンテキストウィンドウを超えるタスクや、結果が選択される前に独立した相関の低い試行が有益なタスクにおいて、より信頼性の高い結果を生み出せると主張する。特にマルチエージェントの討論と批評の設定は、幻覚と推論エラーを減らす方法として研究されており、新しいコンテキストから別のエージェントの出力をレビューするエージェントは、元のエージェントが自分の作業をレビューするよりも間違いを見つける可能性が高いという前提に基づいている。
制限と批判
マルチエージェントシステムは、独自のコストと障害モードを導入する。複数のエージェントを実行すると、各エージェントが通常独自のコンテキストを維持し、基盤となるモデルを何度も呼び出す可能性があるため、単一のエージェントと比較してトークン使用量とレイテンシが増加する。調整の失敗も一般的であり、エージェントが互いにすれ違い、作業を重複させ、互いを待って行き詰まり、またはハンドオフ全体でエラーが累積するにつれて元のタスクから逸脱する可能性があり、これは単一エージェントについて議論された信頼性の懸念と密接に関連するリスクである。一部の実務者は、複数のエージェントを必要とすると宣伝される多くのタスクは、適切なプロンプトエンジニアリングと適切なツールへのアクセスを備えた単一の十分に能力のあるエージェントで同等に、かつより安価に処理できると主張し、マルチエージェントアーキテクチャを厳密に優れたデフォルトではなく、真の工学的トレードオフにしている。2025年現在、マルチエージェントフレームワークはツール開発の活発な領域であり、エージェントが通信すべき方法について単一の支配的な標準はないが、モデルコンテキストプロトコルとツールおよびコンテキストインターフェースを標準化する関連取り組みは、一部のプロジェクトによってエージェント間通信にも拡張されている。