【2026年最新】LLMマルチエージェント設計パターンを整理する — TradingAgents・CrewAI・AutoGenに学ぶ5つの型
この記事で分かること
「マルチエージェント」という言葉は、いま3つの異なるレイヤーで混同されています。
- フレームワーク（LangGraph / CrewAI / AutoGen のどれを使うか）
- 設計パターン（ディベート型 / 階層型 / リフレクション型 のどう組むか）
- 実装（実際にどう動かすか）
比較記事の多くは①のフレームワーク選定で止まっていて、「で、エージェントをどう協調させれば賢くなるのか」という②の設計パターンが整理されていません。フレームワークは「箱」であって、中の「型」を決めるのは設計パターンです。
この記事では、GitHub 82.3k stars を集めた金融エージェント実装 TradingAgents（arXiv:2412.20138）を解剖し、そこから金融以外にも転用できる5つの再現可能な設計パターンを抽出します。フレームワーク比較ではなく「設計の型」を整理するのがゴールです。
「マルチエージェント」が指す5つの設計パターンの整理
まず混乱の元を潰します。「マルチエージェントにしました」と言うとき、実際には次のどれか（または組み合わせ）を指しています。フレームワークとは独立した概念です。
| 設計パターン | 何をするか | 効く問題 |
|---|---|---|
| オーケストレーター/階層型 | 上位が下位の専門エージェントに分業・統合 | 大きなタスクの分解 |
| ディベート型 | 対立する立場で討論し結論を採択 | 確証バイアス・精度 |
| リフレクション型 | 過去の結果を振り返り次に反映 | 継続学習・自己修正 |
| パラレル・ファンアウト | 同一タスクを並列実行して集約 | 速度・網羅性 |
| Plan & Execute / ReAct | 計画→実行→観察を反復 | 適応性・動的タスク |
TradingAgents が優れているのは、この5パターンのうち上位4つを1つのパイプラインに統合している点です。だからこそ「設計パターンの教科書」として読む価値があります。
前提: なぜ単一LLMでは不十分なのか
「賢いモデル1つに全部聞けばいい」では、次の壁にぶつかります。
- 確証バイアス: 最初の見立てを補強する情報ばかり集める
- コンテキスト過負荷: 全データを1プロンプトに詰めると重要情報が埋もれる
- 検証の欠如: 自分の出力を自分で批判できない
- 学習の不在: 過去の失敗が次に活きない
人間の組織が「分業・討論・リスク審査・振り返り」で意思決定の質を担保するのと同じ構造を、エージェント分業で再現する——これがマルチエージェント設計の本質です。TradingAgents はこれを取引会社の組織図として実装しました。
ケーススタディ: TradingAgentsの5層構造を分解する
TradingAgents は情報を以下の順に流す逐次パイプラインです（LangGraph で状態管理）。
[アナリストチーム] Fundamentals / Sentiment / News / Technical の4分析
│
▼
[リサーチャー] Bull ⇄ Bear ディベート（n ラウンド）
│ → Research Manager が勝者を採択
▼
[トレーダー] 投資プラン（タイミング・数量）を起案
│
▼
[リスク管理] Risky / Neutral / Safe の3者ディベート
│ → Risk Judge が最終 BUY/SELL/HOLD
▼
[ファンドマネージャー] 最終承認・執行
注目すべきは「分業」と「討論」が2箇所で二重に使われていること。アナリストは並列分業、リサーチャーとリスク管理は対立ディベートです。次章でこれを汎用パターンに落とします。
5つの再現可能パターン（核心）
パターン1: 役割分業 + 階層統合
4人のアナリスト（ファンダメンタル・センチメント・ニュース・テクニカル）が異なるデータソースを分担し、上位のリサーチャーが統合します。1エージェントに全データを渡さず、専門ごとに切るのがコツ。CrewAI の hierarchical Process や AutoGen の supervisor がこの型に対応します。
パターン2: 対立ディベート（Bull/Bear）
同一データを使い、強気エージェントと弱気エージェントが正反対の解釈を主張し合います。各々が証拠を引用し、相手の妥当な点は認める。ファシリテーター（Research Manager）が討論を要約して勝者を採択します。確証バイアスを構造的に潰す最強パターンです。
パターン3: 通信モードの使い分け
TradingAgents の隠れた設計判断がこれです。
| 場面 | モード | 理由 |
|---|---|---|
| 通常の情報伝達 | 構造化ドキュメント | "telephone effect"（伝言ゲームでの情報劣化）を回避 |
| エージェント同士の討論 | 自然言語 | 深い推論と多様な視点の統合を促す |
「全部JSON」でも「全部自然言語」でもなく、伝達は構造化・議論は自然言語。これが情報損失と推論深度のトレードオフを解きます。
パターン4: リフレクション・メモリ
各取引を根拠・結果とともに ~/.tradingagents/memory/trading_memory.md に記録し、実現リターンと過去の学びを次回の Portfolio Manager プロンプトに注入します。runを重ねるほど賢くなる仕組みです。
パターン5: deep/quick 2層モデル
複雑な推論には高性能モデル（deep_think_llm）、軽量タスクには小型モデル（quick_think_llm）を割り当て、精度とAPIコストのトレードオフを最適化します。
config["deep_think_llm"] = "gpt-5.5" # 推論・判断
config["quick_think_llm"] = "gpt-5.4-mini" # データ整形などルーチン
5つのパターンを自分の業務にどう当てはめるか
金融以外への転用例です（ここが本記事の実用パート）。
- コンテンツ審査: 「推進派 vs 批判派」のディベート型で記事のリスクを事前に潰す（パターン2）
- コードレビュー: セキュリティ/パフォーマンス/可読性を並列分業し、レビュー統合役がマージ（パターン1）
- リサーチ要約: 各ソースを構造化レポートで集約し、最終議論だけ自然言語（パターン3）
- カスタマー対応: 過去の対応ログをメモリ化し、類似ケースの学びを注入（パターン4）
- 大量バッチ処理: ルーチンは小型モデル、最終判断だけ大型モデル（パターン5）
原典・公式に学ぶベストプラクティス
TradingAgents 論文および各フレームワーク公式の知見から:
エージェントは構造化ドキュメントで情報を伝達し、"telephone effect"（情報の劣化）を避ける。一方、討論時のみ自然言語を使い、深い推論と多様な視点の統合を可能にする。
— TradingAgents論文（arXiv:2412.20138）
-
再現性: LLMのサンプリングとライブデータにより、同一入力でも結果が変わる。
temperature=0.0と非推論モデルで一貫性が向上する（※2026年6月時点の論文記載） - CrewAI の階層モードは MetaGPT の組織アーキテクチャ概念（役割分業＋階層管理）を取り入れている（出典）
- AutoGen は2026年にメンテナンスモードへ移行し、より広範な「Microsoft Agent Framework」へ統合される流れ（※2026年6月時点・出典）
アンチパターン7選
- ❌ 1モデルに全データを渡す: コンテキスト過負荷で重要情報が埋もれる → 専門分業（パターン1）
- ❌ ディベートなしの単一視点: 確証バイアスに陥る → 対立ディベート（パターン2）
- ❌ 全工程を自然言語で繋ぐ: telephone effect で情報劣化 → 伝達は構造化（パターン3）
- ❌ 全エージェントに最高性能モデル: コストが爆発（後述の試算参照）→ deep/quick 2層（パターン5）
- ❌ ディベートラウンドの無制限化: ラウンド数 × エージェント数だけLLM呼び出しが増える → 1〜2ラウンドで頭打ちを確認
- ❌ 1回のrun結果を確定的に扱う: LLMは非決定的 → 複数runor
temperature=0.0 - ❌ メモリ機構の省略: 過去の失敗が活きない → リフレクション（パターン4）
定量: コスト試算とディベートラウンドの最適値
マルチエージェントはLLM呼び出し回数が乗算で増えるのが最大の落とし穴です。
AutoGen の GroupChat では、各エージェントのターンごとに会話履歴全体を含むLLM呼び出しが発生する。4エージェント×5ラウンドのディベートは最低20回のLLM呼び出しになる。
— DEV Community / 各社比較
| 構成 | LLM呼び出し概算 |
|---|---|
| 単一エージェント | 1回 |
| 4アナリスト分業 | 4回 |
| Bull/Bear 2ラウンド | +4回 |
| リスク3者 1ラウンド | +3回 |
| TradingAgents 1回のpropagate | 概ね十数回〜数十回 |
最適化の指針:
-
max_debate_roundsは 1〜2 から始める（3以上は限界効用が逓減しやすい） - ルーチンは
quick_think_llm、判断のみdeep_think_llm - ローカル検証は Ollama でパイプライン挙動を確認 → 本番でAPIモデルに切替
関連フレームワーク比較表
設計パターンを「どの箱で実装するか」の早見表です（※2026年6月時点）。
| フレームワーク | 設計思想 | 得意な型 | 向く場面 |
|---|---|---|---|
| LangGraph | グラフ（状態＋制御フロー） | 階層型・循環・Plan&Execute | 複雑な制御フロー・本番運用 |
| CrewAI | 役割ベースの組織（Agent/Task/Crew/Process） | 役割分業・階層型 | 高速プロトタイプ |
| AutoGen | 会話ベース（GroupChat） | ディベート型・リフレクション | 対話型・実験（※メンテナンスモード移行中） |
| MetaGPT | SOP（標準業務手順）の組織模倣 | 役割分業・階層型 | ソフトウェア開発の自動化 |
| TradingAgents | 取引会社の組織模倣 | 上記5型を統合した実装例 | 設計パターンの教科書 |
実務の定番は「CrewAI で素早くプロトタイプ → 本番が見えたら LangGraph に移行」（出典）。
実践チェックリスト
マルチエージェントを設計する前に自問する項目:
- そのタスクは本当に分業が必要か？（単一エージェントで足りないか）
- 確証バイアスが怖いならディベート型を入れたか
- 情報伝達は構造化、議論だけ自然言語に分けたか
- 過去の結果を活かすメモリ機構はあるか
- deep/quick 2層でコストを最適化したか
- LLM呼び出し回数を試算したか（ラウンド×エージェント数）
-
temperatureと再現性の方針を決めたか - フレームワークの「箱」と設計「型」を分けて考えたか
まとめ
- 「マルチエージェント」はフレームワーク・設計パターン・実装の3レイヤーで混同されがち。整理の鍵は設計パターン
- 再現可能な5つの型: ①役割分業＋階層統合 ②対立ディベート ③通信モードの使い分け ④リフレクション・メモリ ⑤deep/quick 2層
- TradingAgents は上位4型を1パイプラインに統合した設計の教科書として読める
- 最大の落とし穴はLLM呼び出し回数の乗算。ディベートは1〜2ラウンド、コストは2層モデルで抑える
- フレームワーク（箱）はパターンを強制しない。型は自分で設計する
Discussion