# マルチエージェント協調 ## 定義 マルチエージェント協調(multi-agent coordination)は、複数のLLMエージェントがそれぞれの専門能力を組み合わせて単一エージェントでは解決が難しい問題を解くアーキテクチャ・手法群の総称である。主な設計次元は「通信トポロジー（チェーン・ツリー・グラフ）」「役割分担（プランナー・実装者・検証者など）」「知識伝達機構（コンテキスト共有・要約・議論）」の3軸からなる。(Source: [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]] §3・§5) 既存手法は大きく2類型に分かれる。(1) **手設計スキャフォールド**（MoA・Mixture-of-Agents等）: 固定された通信パターンを事前に設計し、各ラウンドでエージェントを並列・直列に呼び出す。(2) **学習型ルーター**（MASRouter・RouterDC・Smoothie等）: 埋め込み空間上で問題をエージェントや人手設計トポロジーにルーティングする分類器を学習する。 2026年のConductor（Nielsen et al., ICLR 2026）は第3の類型として、強化学習で訓練したメタエージェントが自然言語で任意の協調戦略を生成する**エンドツーエンドRL型**を提案した。Conductorは7B LLMとして訓練され、よりはるかに大型のworker LLMを指揮することで全フロンティアモデルを超えるSOTA性能を達成した。(Source: 同上 §3・§4) ## 横断的知見 - **オーケストレーターを「単一モデルインターフェース」として公開すると集合知がスケーリング軸になる**: Sakana Fugu（[[@2026__Sakana AI__Sakana Fugu Technical Report]]）はワーカープールを内部に隠蔽し、ユーザーには単一モデル呼び出しとして見せる。Conductor が「オーケストレーターを研究パラダイムとして示した」段階から、「本番 API として公開できる」段階へ移行したことを示す。GPQA-Diamond 95.5%・SWE-bench Pro 73.7%・HLE 50.0% という成績は、ワーカープールに含まれない Mythos Preview・Fable 5 モデルクラスをも超えた。(Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §4.1, Table 1) - **intra-workflow agent isolation はオーケストレーション崩壊を防ぐ必須設計**: マルチエージェント関数呼び出し環境では最初のエージェントの軌跡が後続エージェントを支配し、独立した貢献が失われる「オーケストレーション崩壊」が発生する。Fugu-Ultra は各エージェントが自身の関数呼び出し履歴しか観測しない分離設計（アクセスリストでのみ情報共有）でこれを防ぐ。一方でワークフロー間の完全分離は過去コンテキストを失わせるため、ワークフロー「内」の分離とワークフロー「間」の共有メモリを組み合わせる。(Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §3.2.2) - **ドメイン適応性は自動的に創発し、事前知識なしに専門家の直観と一致する**: Fugu/Fugu-Ultra はドメインごとのモデル配分として「Terminal Bench→GPT-5.5 優先(86%)」「GPQA-Diamond→Gemini-3.1-Pro 優先(56%)」「HLE 数学→GPT 優先、化学・生物→Gemini 優先」を学習した。これは「GPTが数学に強い」「Geminiがニッチ科学知識に強い」というドメイン知識と一致しており、RL 訓練を通じて外部の知識なしに自発的に獲得された。(Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §4.2, Figure 5) - **固定集約モデルのボトルネックを「動的集約者」で突破できる**: Mixture-of-Agents等の固定スキャフォールドは常に同じモデルが最終合成を担うため、そのモデルの専門外タスクで頭打ちになる。Fugu-Ultra はタスクによって集約役を変更する（数学問題ならGPTが集約、ニッチ科学知識ならGeminiが集約）。この適応が Conductor 単独より実用的な性能向上をもたらす鍵となっている。(Source: [[@2026__Sakana AI__Sakana Fugu Technical Report]] §4.4) - **自然言語を媒介にすることで協調戦略の表現力が質的に変わる**: 学習型ルーター（MASRouter等）は事前定義されたトポロジー候補集合の中から選択するだけだが、Conductorは自然言語で「プランナーを2ステップ挟む」「前エージェントの推論を全エージェントに見せる」「反論して洗練させる」等の任意の戦略を記述できる。この表現力の差がConductor vs MASRouterで約20ポイント、Conductor vs MoAで約10ポイントの性能差として現れる。(Source: [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]] Figure 4・Figure 5) - **マルチエージェント協調は「呼び出し数当たりの性能」という新しい効率軸で評価すべきである**: 従来手法の比較は主に絶対性能で行われてきたが、Conductor（平均3呼び出し）がMoA（8呼び出し）を15ポイント上回る事実は、同じ計算コストで圧倒的な性能差があることを示す。RL型コーディネーターが自律的に「必要最小限のワークフロー」を学習した結果として、効率と性能の正相関が生まれた点が注目に値する。(Source: 同上 Figure 5) - **エージェント選択と指示内容（プロンプトエンジニアリング）はともに重要な協調スキルだが、後者がより大型モデルを要する**: 3B Conductorと7B Conductorは訓練後に同じエージェント分布（Gemini 2.5 Pro・GPT-5・Claude Sonnet 4を優先）に収束するが、7Bは3Bよりも性能が明確に高い。この差はより細かく焦点化されたサブタスク指示（プロンプトエンジニアリング）の質によるものと分析されており、モデルスケールアップが協調戦略の言語表現力に直接変換される軸が存在することを示す。(Source: 同上 §4.5・Figure 7) - **ドメイン特化マルチエージェントは「役割分担設計 > モデル規模」という優先順位で協調利得を生む**: mABC(Zhang+ EMNLP Findings 2024)は AIOps/MSA ドメインに特化した 7 専門エージェントが固定スキャフォールド(Agent Chain + Agent Workflow)上で協調する手設計スキャフォールド型の実装例である。アブレーション(Table 7)で「マルチエージェント除去 > Agent Workflow 除去 > 投票除去」の順で性能が低下し、**役割分担がもっとも重要なコンポーネント**であることが定量化された。特に Llama-3-8B ベースの mABC が ReAct(GPT-4-Turbo 単一エージェント)を上回った事実(RA 43.5 vs 38.5)は、Conductor の「RL でコーディネーターを訓練しなくてもドメイン特化役割分担だけで規模差を埋められる」という観察と並行して位置づけられる。ただし Conductor がタスク横断的な汎用協調を学習するのに対し、mABC は MSA RCA に閉じた固定スキャフォールドであり、転移性は低い。(Source: [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] §3.5, Table 4, Table 7) - **産業オンコール自動化でも「木探索プランナー + 専門エージェント役割分担」が ReAct 単一エージェントを上回り、コンテキスト長が壁になる**: OncallX(Fu+ ASE 2025)は OCEAgent（中央木探索プランナー）が KernelAgent・CompileAgent・FirmwareAgent 等の専門エージェントを動的に呼び分け、リフレクション機構でバックトラックする設計で、GPT-3.5 ベース Pass Rate 78.26% を達成し ReAct(71.01%)を +7.25pt 上回った。アブレーションでマルチエージェント&木プランナー除去が −13.04pt と最大の性能低下を示し、「役割分担設計 > モデル能力」という傾向が AIOps ドメインに加えてオンコールドメインでも再現された。一方で多ターン通信の積み重ねによるコンテキスト長増大が LLM の文脈保持を劣化させる問題（§VI-A）は未解決であり、この制約がマルチエージェント協調のスケーリング限界として繰り返し現れる。(Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] §V-B, Table I, Table III, §VI-A) - **分散型多数決(blockchain-inspired voting)はエージェント間の誤り修正機構として機能するが、精度への貢献は役割分担より小さい**: mABC の投票では各エージェントが他エージェントの回答に賛否を表明し、否決された場合は元エージェントが再回答する。貢献指数(wc)と専門指数(we)の積でウェイト調整することで、活動量と正解率の両方を報酬シグナルとして使う仕組み。アブレーションでは w/o Voting が最も小さな精度低下(RA -9.6 vs -16.0 for w/o Multi-Agent、Train-Ticket)にとどまる一方、人間評価の解決策有用性スコア(R-Useful)では最も高い評価を獲得した。この結果は「投票が精度測定上のメトリクスよりも解決策の品質・信頼性に寄与する」という非対称な効果を示す。(Source: 同上 §2.4, Table 6, Table 7) - **スティグマジック（間接的な足跡ベース）協調は、ネゴシエーション型・自然言語推論型の協調と比べて、本番運用でのエージェント品質異質性への耐性を定量的に実証した最初の産業事例である**: Comfey([[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]])は自らを Contract Net/ネゴシエーション型（Triangle (ASE '25) 等、$O(N^2)$ 通信コスト・高度な共通言語を要求）や MetaGPT・ChatDev のような自然言語推論による "Reasoning Routing" と対比し、Global Routing Table を Blackboard/Stigmergy 型の共有メモリとして扱う "Statistical Routing" を採用する。LLM 呼び出しをローカルなエンリッチメント・要約のみに予約することで、ルーティングの都度 LLM 推論するコストを回避しつつ、Azure 本番 15 チーム・22 か月間の運用で 91.5% の精度を維持した。アブレーションでは Global Routing Table の除去（ナイーブなランダム隣接ネゴシエーションへの置換）が精度を 40% 低下させ、**間接的な履歴ベース協調が直接ネゴシエーションより頑健である**ことを実運用データで裏付けた点は、Conductor(RL 型オーケストレーター)・mABC(固定スキャフォールド + 投票)とは異なる第 3 の協調様式（スティグマジック）の実証例として位置づけられる。(Source: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] §3.1, §4.6, §5) - **トレースグラフのトポロジそのものを協調構造として使う「グラフ同型な役割分担」は、mABC・OncallX の機能軸役割分担・Comfey の履歴軸ルーティングとは異なる第4の協調様式を提示する**: [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]](RCLAgent)は、各トレーススパンに専任エージェントを割り当て、エージェント間の親子関係をトレースグラフの親子関係とそのまま一致させる(Global Evidence Graph はトレースグラフと同型)。mABC(機能で分業: Alert Receiver・Dependency Explorer 等)・OncallX(木探索プランナーが動的に呼び分け)・Comfey(統計的ルーティングテーブル)がいずれも協調構造をタスク側から独立に設計するのに対し、RCLAgent は**対象データの構造自体を協調トポロジとして流用する**点が異なる。固定容量 K の Agents Pool による同時実行数の制御(式8)は、Comfey が実運用でスケールを扱う際の設計思想(統計的ルーティングによる低コスト協調)と通じるものの、RCLAgent は事前に定義したグラフ構造に沿うため、探索的なルーティング判断そのものが不要という点でさらに単純である。アブレーション(Global Evidence Graph 除去で平均 MRR 69.73%→56.90%)は、この構造的協調でも「協調機構の設計そのものが精度を大きく左右する」という OncallX・Comfey と同型のパターンを再確認した。(Source: [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] §IV-B, Table IV) - **「役割分担設計 > モデル能力」という OncallX の知見は、「ルーティング機構の設計 > 個別エージェントの推論能力」という Comfey の知見と整合する**: OncallX のアブレーション（マルチエージェント&木プランナー除去で Pass Rate −13.04pt）と Comfey のアブレーション（Global Routing Table 除去で精度 −40%）は、いずれも「協調機構そのもの」が個々のエージェントの LLM 推論能力より性能に大きく寄与することを示す。ただし OncallX は木探索プランナー（中央集権的な動的協調）、Comfey は Global Routing Table（分散的な履歴ベース協調）と、協調機構の設計思想は対照的であり、「エージェント間の協調をどう構造化するか」という問いに対する 2 つの異なる解が、同じ「協調機構の寄与が大きい」という結論に至っている。(Source: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] §4.6, [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] Table III) ## 未解決の問い - **Fugu のドメイン適応はワーカープール構成変化に対してロバストか**: 現在は Gemini-3.1-Pro・Opus-4.8・GPT-5.5 の3モデル固定。新モデル追加・廃止時に SFT ラベルだけ追加すれば再学習なしで対応できると主張するが、その性能変化の実験は報告されていない。 - **Fugu-Ultra の intra-workflow isolation はエージェント数スケーリングで壊れないか**: 5ステップ以上のワークフローで分離コストが増大するか、情報欠落が増えるかは未評価。最大ステップ数 5 という制約は設計選択なのか性能的限界なのか不明。 - **オーケストレーション崩壊の発生条件はどこにあるか**: Fugu-Ultra が定性的に報告する崩壊現象を定量化した実験が存在しない。タスクタイプ・ワーカー数・ワークフロー深さのどの軸が崩壊しやすいかは未整理。 - Conductorが学習する協調戦略は、workerモデルのセット（プロバイダー・サイズ・専門化）に対してどこまで転移するか。訓練時に含まれないモデルを追加・削除した場合の性能劣化の境界条件は未報告。 - 再帰的トポロジーにおける最適な再帰深さ・コスト上限はどう決定するか。論文は2×までを評価したが、それ以上の再帰でどの程度の収益逓減が生じるか不明。 - 協調戦略の創発はタスクドメイン（数学・コード・科学）によって質的に異なるか。Conductorが数学では「プランナー+実装者+検証者」の順を、コードでは別の構造を学ぶといった分析が付録の例示にとどまっており、定量的な戦略分類は未実施。 - マルチエージェント協調を対象としたRLの探索問題（報酬がスパース・遅延）は、強力なworkerがあることで緩和されると本論文は主張するが、workerが弱い場合（例：Gemma 7Bのみのプール）でRLが収束するかどうかは未検証。 - **固定スキャフォールド型(mABC)と RL 型(Conductor)の境界条件**: mABC はドメイン知識を手作業で役割分担に埋め込む固定設計で、訓練不要だが転移性が低い。Conductor は転移性を RL で獲得するが、RL の訓練コストが発生する。「訓練データが手に入らないが正確な役割分担を事前定義できるドメイン(AIOps など)では固定スキャフォールドで十分か、それとも RL 型が必要か」の判断軸は未整理。(Source: [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] §7, [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]] §5) - **スティグマジック協調（Comfey）と中央プランナー型協調（OncallX の OCEAgent、mABC の Agent Workflow）は、どの条件下でどちらが優れるか**: Comfey は「拒否したエージェントの意思決定に依存しない」堅牢性をスティグマジックルーティングの利点として挙げるが、OncallX・mABC は中央プランナー/固定ワークフローによる明示的な統制で協調を実現する。両者の優劣を同一タスク・同一データセットで比較した研究は存在しない。エージェント数が数百規模までスケールした場合に中央プランナー型が実運用上どこまで耐えるかも未検証。 - **Comfey のスティグマジックルーティングは、Conductor のような RL 型自然言語オーケストレーションと統合可能か**: Comfey の Global Routing Table は統計的な頻度マップに基づく単純な仕組みであり、Conductor のように協調戦略を自然言語で柔軟に表現する余地はない。ルーティングの精度・監査可能性を保ちつつ、より表現力の高い協調戦略を学習させることは可能か。 ## 関連 - ソース: [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]] / [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] / [[@2026__Sakana AI__Sakana Fugu Technical Report]] / [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] / [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] / [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] - 概念: [[テスト時計算スケーリング]] / [[強化学習スケーリング]] / [[LLM推論]] / [[LLM評価]] / [[LLMによる根本原因分析]] / [[オンコール自動化]] / [[インシデントトリアージ]] - エンティティ: [[Sakana AI]] / [[Stefan Nielsen]] / [[Edoardo Cetin]] / [[Yujin Tang]] / [[Wei Zhang (Beihang)]] / [[Hongcheng Guo]] / [[Ruowei Fu]] / [[OncallX]] / [[Comfey]] / [[RCLAgent]] ## 出典 - [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]]（§3 手法定義・§4 実験・§4.5 分析・§5 関連研究） - [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]]（§2.3 エージェント設計・§2.4 blockchain 投票・§3.5 主要結果・§4.3 アブレーション・Table 7） - [[@2026__Sakana AI__Sakana Fugu Technical Report]]（§3 Fugu/Fugu-Ultra 手法・§4 ベンチマーク・§4.2 ドメイン適応・§4.4 最適戦略） - [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]]（§IV-C 木探索設計・§V-B RQ1 実験・Table I・Table III アブレーション・§VI-A 限界） - [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]]（§3.1 設計判断・§3.6 Global Routing Table・§4.6 アブレーション・§5 関連研究との位置づけ） - [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]]（§IV Multi-Agent RoT・Agents Pool 設計・§IV-B アブレーション Table IV）