マルチエージェントシステム（マルチエージェントシステム）
マルチエージェントシステムとは、複数の自律的なAIエージェントが協調・競争しながらタスクを遂行するアーキテクチャで、単一LLMでは困難な複雑な問題を分業と対話によって解決する仕組みである。
複数のAIエージェントが役割を分担し、互いに通信しながら協調的にタスクを遂行するアーキテクチャがマルチエージェントシステム（MAS: Multi-Agent System）である。2025-2026年のLLMアプリケーション開発では、単一プロンプトによる逐次処理の限界を超えるために、専門化されたエージェントを組み合わせるMASアプローチが主流になりつつある。
概要
マルチエージェントシステムは、1990年代の分散AI研究に起源を持つが、GPT-4やClaude 3.5以降の高性能LLMの登場により、実用的なソフトウェアアーキテクチャとして再注目されている。各エージェントは独立したシステムプロンプト・ツールセット・メモリを持ち、オーケストレーター（監督エージェント）が全体の進行を管理する。2026年時点で、AutoGen 0.4・CrewAI 0.80・LangGraph 0.2・MetaGPT 0.8・OpenAI Swarm（実験版）など主要フレームワークが乱立しており、GitHub Star数はAutoGenが68,000超、CrewAIが45,000超を記録している。
エージェント間の通信パターンは大きく3種類に分類される。直列パイプライン（Agent A → B → C と逐次処理）、並列ファンアウト（複数エージェントが同時実行し結果を集約）、対話型ディベート（エージェント同士が議論して結論を導出）である。タスクの性質に応じてこれらを組み合わせることで、コーディング・リサーチ・データ分析など多岐にわたる業務を自動化できる。
主な特徴・アーキテクチャパターン
- 役割分業: 各エージェントに「リサーチャー」「コーダー」「レビュアー」「テスター」など専門役割を割り当て、人間のチーム構成を模倣する
- ツール統合: 各エージェントが独自のツール（Web検索・コード実行・DB問い合わせ・ファイル操作）を持ち、必要に応じて呼び出す
- 共有メモリ: Redis・SQLite・ベクトルDBなどを介して、エージェント間で知識や中間成果物を共有する
- オーケストレーション: 監督エージェントまたはグラフベースのワークフローが、タスクの分配・進捗管理・エラーハンドリングを担当する
- 自己修正ループ: 出力の品質チェックを行うエージェントがフィードバックを返し、生成エージェントが修正するイテレーションが可能
- スケーラビリティ: エージェント数を動的に増減でき、負荷に応じてモデルサイズ（GPT-4o → GPT-4o-mini）を切り替えるコスト最適化が可能
- 障害耐性: 一つのエージェントが失敗しても、タイムアウト検知とリトライにより全体のタスクを継続できる
- トレーサビリティ: 各エージェントの入出力・ツール呼び出し・判断根拠をログに記録し、デバッグや監査に活用する
主要フレームワーク比較
| フレームワーク | 開発元 | GitHub Stars | 特徴 | モデル対応 | ライセンス |
|---|---|---|---|---|---|
| AutoGen 0.4 | Microsoft | 68,000+ | 会話型エージェント、GroupChat | OpenAI/Azure/Anthropic/ローカル | MIT |
| CrewAI 0.80 | CrewAI Inc. | 45,000+ | 役割ベース設計、Process定義 | OpenAI/Anthropic/Ollama | MIT |
| LangGraph 0.2 | LangChain | 38,000+ | グラフベースワークフロー、状態管理 | 全LiteLLM対応 | MIT |
| MetaGPT 0.8 | DeepWisdom | 48,000+ | SOP準拠、ソフトウェア開発特化 | OpenAI/Anthropic | MIT |
| OpenAI Swarm | OpenAI | 25,000+ | 軽量ハンドオフ、実験的 | OpenAI専用 | MIT |
実装パターンと具体例
パターン1: リサーチ → 執筆 → レビュー パイプライン
リサーチャーエージェントがWeb検索でソースを収集し、ライターエージェントが記事を生成、レビューエージェントがファクトチェックと品質評価を行い、不合格なら修正ループに戻す。CrewAIのsequentialプロセスで実装可能。
パターン2: コード生成 → テスト → デバッグ ループ
プランナーエージェントが設計を作成、コーダーエージェントが実装、テスターエージェントが単体テストを実行し、失敗したテストの情報をデバッガーエージェントにフィードバック。AutoGenのGroupChatパターンで実現。
パターン3: 多視点ディベート
同一の質問に対して、楽観的視点・悲観的視点・中立視点の3エージェントが独立に回答を生成し、ジャッジエージェントが最終結論を合成。幻覚リスク低減と回答精度向上に有効。
設計上の注意点
- トークンコスト管理: エージェント数 × 対話ターン数でAPIコストが急増するため、GPT-4o-miniやClaude 3.5 Haikuなど軽量モデルを下位エージェントに割り当てる。上位の判断エージェントのみGPT-4oやClaude Opusを使用する
- 無限ループ防止: エージェント間の対話にmax_turns制限（通常5-10ターン）を設定し、収束しない場合はフォールバック処理を行う
- コンテキストウィンドウ: 対話履歴が膨大になるため、要約エージェントを挟むか、直近N件のみ保持するスライディングウィンドウ方式を採用する
- セキュリティ: コード実行エージェントにはサンドボックス（Docker・E2B）を必ず使用し、ファイルシステムアクセスを制限する
関連用語との違い
| 用語 | 定義 | MASとの関係 |
|---|---|---|
| RAG | 外部知識を検索して回答を補強 | MAS内の1エージェントがRAGを使う構成が一般的 |
| エージェントフレームワーク | 単一エージェントの構築基盤 | MASは複数エージェントの協調に焦点 |
| ワークフローエンジン | 定義済みの処理フローを実行 | MASはLLMが動的にフローを変更可能 |
| Function Calling | LLMが外部関数を呼び出す機能 | MASの各エージェントがFunction Callingを利用する |
よくある質問（FAQ）
Q1: マルチエージェントシステムはどんなタスクに向いているか？ A: 単一プロンプトでは品質が不安定な複雑タスク（長文レポート作成・コードベース全体のリファクタリング・多角的リサーチ）に向く。単純なQ&Aや要約など単一LLM呼び出しで十分なタスクにはオーバーヘッドが大きい。
Q2: エージェント数が多いほど精度は上がるか？ A: 一般に3-5エージェントが費用対効果のスイートスポット。エージェント数増加によるコスト増と通信オーバーヘッドが精度改善を上回る閾値がある。Microsoft Researchの実験では、5エージェント以上でHumanEvalスコアの改善幅が1%未満に収束した。
Q3: ローカルLLMでマルチエージェントは実用的か？ A: Qwen3-8BやGemma4-12Bクラスのモデルをviaで複数起動し、LiteLLMで統合すれば可能。ただし推論速度がボトルネックになるため、Apple Silicon M4 Ultra（128GB）やRTX 5090（32GB VRAM）クラスのハードウェアが実用ライン。
Q4: CrewAIとAutoGenの使い分けは？ A: CrewAIは役割ベースで直感的な設計が可能で、定型的なワークフロー向き。AutoGenは会話ベースで柔軟性が高く、動的にエージェント構成を変更したい場合に適する。LangGraphはグラフベースで最も制御が細かいが学習コストが高い。
まとめ
- マルチエージェントシステムは複数の専門AIエージェントが協調してタスクを遂行するアーキテクチャ
- 2026年時点でAutoGen・CrewAI・LangGraph・MetaGPTが主要フレームワーク
- 直列パイプライン・並列ファンアウト・対話型ディベートの3パターンを組み合わせて設計する
- コスト管理（モデル使い分け）・無限ループ防止・セキュリティ（サンドボックス）が設計の要所
- 3-5エージェントが費用対効果の最適解で、過度な分業は逆効果になりうる