--- title: "マルチエージェントとは？仕組み・構成パターンと採用判断を研究データで解説【2026年10月】" url: "https://www.issoh.co.jp/tech/details/13604/" published: 2026-07-13 updated: 2026-10-12 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # マルチエージェントとは？仕組み・構成パターンと採用判断を研究データで解説【2026年10月】 マルチエージェントとは、役割を分けた複数のAIエージェントが情報を受け渡しながら、1つの目標に向けて作業を分担する仕組みです。調査担当・分析担当・執筆担当のように責務を切り分け、それぞれの出力をつないで最終的な成果にまとめます。 この記事では、LLM以前からある研究分野としてのマルチエージェントシステム（MAS）との関係を押さえたうえで、役割・通信・統合という設計要素を標準ライブラリだけの短いコードで示します。後半では代表的な構成パターン、MCPとA2Aの役割分担、2026年10月9日時点の主要フレームワークの版、そしてAnthropicとGoogle Researchが公表した数値から「どの業務で効き、どの業務で逆に精度が落ちるか」を整理します。 ## まとめ：マルチエージェントの要点（2026年10月時点） - マルチエージェントは、複数のエージェントに役割を分け、通信と結果の統合で1つの成果へまとめる構成です。設計の中心は個々のエージェントの賢さより、何を渡し、誰が書き込み、いつ終えるかの取り決めにあります。 - 言葉自体はLLM以前から、分散人工知能の研究分野で使われてきました。LLMを使う現在のマルチエージェントは、その考え方を言語モデルで実装したものです。 - 効果は業務の形で決まります。Google Researchの評価では、並列に分けられる金融分析で単体比80.9%改善した一方、逐次的な計画タスクではすべての複数構成が39〜70%悪化しました。 - 費用は構成と使用モデルによって変わります。Anthropicの調査用システムは単体のClaude Opus 4を90.2%上回りましたが、トークン消費は通常のチャットの約15倍でした。 - 新規に組むなら、OpenAI Agents SDK・LangGraph・CrewAI・Microsoft Agent Framework・Google ADKが現役の選択肢です。AutoGenはメンテナンスモードで新機能は追加されません。 - 逐次的な推論が中心の業務は、まずシングルエージェントを基準に比較検証してください。1つのプロンプトとツール数本で要件を満たす処理は、単体構成を維持します。 ## マルチエージェントの定義と2つの系譜 「マルチエージェント」で検索すると、生成AIの解説と、ロボット制御や交通シミュレーションの論文が混ざって出てきます。同じ言葉が2つの文脈で使われているためです。 ### LLMベースのマルチエージェント：役割を分けた複数のLLMの協働 本記事では、主にLLMベースのマルチエージェントを扱います。1体ずつのエージェントは、LLMがツールを呼び出しながら目標達成まで判断を繰り返すループです（1体の内側の動きは[エージェントループとは？止まる条件とSDK別の反復上限を実測で解説【2026年10月】](/tech/details/13602/)で扱っています）。マルチエージェントは、このループを複数並べ、それぞれに異なるシステムプロンプト・ツール・権限を与えて連携させます。 Anthropicが2025年6月13日に公開した調査用システムが代表例です。リード役のエージェント（Claude Opus 4）が質問を分解し、複数のサブエージェント（Claude Sonnet 4）に並列で検索させ、結果を集約します。Anthropicはこの構成をorchestrator-worker patternと呼んでいます。 ### 古典的なマルチエージェントシステム（MAS）：分散人工知能の研究領域 マルチエージェントシステムは、LLMの登場以前から研究されてきた分野です。教科書『An Introduction to MultiAgent Systems』（Michael Wooldridge、第2版2009年）は、MASを「計算を担う構成要素が自律的に振る舞う分散システム」を理解し構築するための枠組みと位置づけています。同書の説明では、エージェント同士の関係はアリの群れのように協調的な場合も、自由市場のように利己的な場合もあります。 この系譜では、エージェント間でやり取りするメッセージの形式まで標準化されました。FIPA（Foundation for Intelligent Physical Agents）が2002年に標準とした通信言語FIPA ACLは、依頼（request）・通知（inform）・提案（propose）といった発話行為の種類とその意味、メッセージの構成を定めています。強化学習で複数の主体を同時に学習させるマルチエージェント強化学習や、制御工学の分散制御も同じ流れにあります。 LLMベースとの違いは、エージェントの中身と協調の前提です。LLM以前のMASにも、人が判断規則を設計する方式と、強化学習などで方策を獲得する方式があり、利害が対立する主体同士の交渉も研究対象に含みます。LLMベースは判断をLLMに任せ、ほとんどの場合は全員が同じ目標に向かう協調型として組みます。ロボットの群制御や交通流の論文を探している場合は、LLMの記事ではなく分散人工知能の文献に当たってください。 ### シングルエージェント・AIエージェントとの関係 AIエージェントは、自律的に判断して行動する個々の主体を指す言葉です（全体像は[AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説](/column/details/12917/)）。1体で全工程を受け持つ構成をシングルエージェント、複数体に責務を分ける構成をマルチエージェントと呼び分けます。両者のコスト比較や、マルチエージェントで起きる14種類の失敗モードは[シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】](/tech/details/4261/)で詳しく比べています。 ## マルチエージェントを形づくる設計要素：役割・通信・統合 どのフレームワークを使っても、決めることは同じです。誰に何をさせるか、エージェント間で何を受け渡すか、ばらばらの出力をどう1つにまとめて止めるか。次にどのエージェントを動かすかという制御（オーケストレーション）もありますが、こちらは[マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】](/tech/details/13600/)で扱います。 ### 役割と権限：エージェント別のツールと書き込み先の制限 役割を分ける目的は、1体あたりのプロンプトとツール一覧を短くすることです。LangChainの公式ドキュメントは、マルチエージェントが特に役立つ場面として「1体のエージェントにツールが多すぎて選択を誤るとき」「長い専門知識を要するタスクが混ざるとき」を挙げています。役割を決めたら、その役割が使えるツールと、書き込んでよいデータの範囲も同時に決めます。調査担当に送信系のツールを持たせない、レビュー担当には最終成果物を書き換えさせない、といった制限です。 ### エージェント間の通信：メッセージの受け渡しと共有状態 情報の渡し方は2通りあります。前のエージェントの出力を次のエージェントへメッセージとして渡す方式と、全員が読み書きする共有状態（黒板）を置く方式です。OpenAI Agents SDKのハンドオフは会話履歴ごと次のエージェントへ渡す前者、LangGraphのstateは後者にあたります。 どちらでも問題になるのは渡す量です。前段の会話をすべて後段へ流すと、後段ほど入力トークンが増え、関係のない情報に引きずられた判断も起きます。各エージェントが読むべき項目を決め、それ以外は渡さない設計にしておくと、費用と誤りの両方を抑えられます。 ### 結果の統合と終了条件：最終書き込み担当と停止基準の設定 並列に動いた複数の出力は、どこかで1つの回答にまとめる必要があります。Anthropicの調査用システムでは、リード役が集約し、引用の付与は専用のCitationAgentが担います。統合役を決めずに各エージェントが同じ成果物を書き換える構成にすると、後から書いた側の内容で前の結論が消え、誰の判断が残ったのか追えなくなります。最終成果物に書き込めるエージェントは1体に限り、他のエージェントは材料を渡す側に回すのが安全です。あわせて、何を満たしたら終えるか（検証担当の合格、反復回数の上限）もこの段階で決めます。 ## 共有状態で3体をつなぐ最小コード例 上の3要素を、Python標準ライブラリだけで書くと次のようになります。各エージェントはLLMを呼ぶ代わりに挙動だけを模したスタブです。共有状態の各項目に書き込める担当を1体ずつ決め、権限外の書き込みは例外で止めます。 ``` from dataclasses import dataclass # 共有状態（黒板）。誰がどのキーに書けるかを持ち、権限外の書き込みは拒否する class Board: def __init__(self, owners): self.data, self.owners, self.log = {}, owners, [] def read(self, agent, keys): view = {k: self.data[k] for k in keys if k in self.data} self.log.append(f"{agent} read {list(view)} ({sum(len(v) for v in view.values())}字)") return view def write(self, agent, key, value): if self.owners.get(key) != agent: raise PermissionError(f"{agent} は {key} に書き込めない") self.data[key] = value self.log.append(f"{agent} write {key}") @dataclass class Agent: name: str reads: list writes: str work: callable # 実際はLLM呼び出し。ここでは挙動だけ模したスタブ def step(self, board): board.write(self.name, self.writes, self.work(board.read(self.name, self.reads))) researcher = Agent("researcher", ["question"], "facts", lambda v: "出典A: 市場規模は前年比12%増。出典B: 上位3社で6割。" * 3) analyst = Agent("analyst", ["facts"], "findings", lambda v: "寡占が進み新規参入の余地は小さい") writer = Agent("writer", ["question", "findings"], "answer", lambda v: f"結論: {v['findings']}") board = Board(owners={"question": "user", "facts": "researcher", "findings": "analyst", "answer": "writer"}) board.write("user", "question", "この市場に参入すべきか") for agent in (researcher, analyst, writer): agent.step(board) print(board.data["answer"]) print("\n".join(board.log)) try: board.write("analyst", "answer", "上書き") except PermissionError as e: print("拒否:", e) ``` Python 3.9.6で実行した出力は次のとおりです。 ``` 結論: 寡占が進み新規参入の余地は小さい user write question researcher read ['question'] (11字) researcher write facts analyst read ['facts'] (93字) analyst write findings writer read ['question', 'findings'] (27字) writer write answer 拒否: analyst は answer に書き込めない ``` 見るべき点は2つです。1つ目は、執筆担当が読んだのは質問と分析結果の27字だけで、調査担当が集めた93字の生データは渡っていないことです。会話履歴をそのまま流す方式なら、執筆担当は全量を受け取ります。2つ目は最後の行で、分析担当が最終回答を書き換えようとすると拒否されます。実際のフレームワークでは、渡す項目をstateのスキーマなどで制御し、書き込み権限はツールや保存先でも検証します。この例の名前照合は、認証済みの実行主体に基づくアクセス制御を代替するものではありません。LangGraphで同じ構造を組む手順は[LangGraphでAIエージェントを実装する手順：状態管理から承認フローまで](/tech/details/17447/)、担当をどの粒度で分けるかは[タスク分解とは？AIエージェントの分解粒度・3手法・妥当性検証を実装目線で解説](/tech/details/16330/)が参考になります。 ## マルチエージェントの代表的な構成パターンと向く業務 構成パターンの呼び名はフレームワークごとに違いますが、指揮をどこに置くかで整理すると下表のようになります。[LangChainの公式ドキュメント（v1系）](https://docs.langchain.com/oss/python/langchain/multi-agent)はSubagents・Handoffs・Skills・Router・Custom workflowの5つを挙げ、組み合わせてよいと明記しています。 | 構成 | 指揮の置き方 | 向く業務 | LangChainでの名称 | | -------------- | --------------- | ----------- | --------------- | | 中央集権（サブエージェント） | メインが担当をツールとして呼ぶ | 調査・分析の分担 | Subagents | | 振り分け | 入口で分類して担当へ送る | 問い合わせの一次受付 | Router | | ハンドオフ | 会話の主導権ごと担当へ移す | 窓口の取り次ぎ | Handoffs | | カスタムワークフロー | 順序・分岐・反復をコードで制御 | 定型の多段処理 | Custom workflow | | 分散（ピア型） | 司令塔を置かない | シミュレーション・討論 | なし | LangChainの5つのうちSkillsは、1体のエージェントが必要なときだけ専門のプロンプトや知識を読み込む方式で、実体はシングルエージェントです。複数体に分ける前に、1体のまま文脈を切り替える選択肢があることを示しています。 実務で最初に選ぶなら中央集権型です。後で触れるGoogle Researchの評価でも、中央の調整役を持つ構成は誤りの伝播を抑える結果になっています。担当が会話の途中で入れ替わる窓口業務だけはハンドオフが自然です。各パターンの制御の仕方は[マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】](/tech/details/13600/)、Anthropicが公式に示した5つの協調パターンは[Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】](/tech/details/12108/)で解説しています。 ## エージェント同士をつなぐ標準プロトコル：MCPとA2A 1つのアプリの中で複数のエージェントを動かすだけなら、フレームワークの機能で足ります。組織やベンダーをまたいでエージェントをつなぐ場面では、2つのプロトコルが使われます。 - **MCP（Model Context Protocol）**：エージェントと外部のツール・データをつなぐ規格です。Anthropicが2025年12月9日にLinux Foundation傘下のAgentic AI Foundationへ寄贈しました。2026年10月9日時点の最新仕様は2026年7月28日公開の `2026-07-28` 版（[MCP公式ブログの告知](https://blog.modelcontextprotocol.io/posts/2026-07-28/)）で、プロトコルの中核がステートレスなリクエスト／レスポンス型に変わりました。 - **A2A（Agent2Agent）**：エージェント同士がタスクを依頼し、結果を受け取るための規格です。Googleが作成し、2025年6月23日にLinux Foundationのプロジェクトになりました。最新リリースはv1.0.1（[GitHubでの公開](https://github.com/a2aproject/A2A/releases)は2026年5月28日）です。 住み分けは、MCPが「エージェントから道具へ」、A2Aが「エージェントからエージェントへ」です。社内の調査エージェントが取引先の在庫確認エージェントに依頼するような場面ではA2A、そのエージェントが自社の在庫DBを読むときはMCPを使います。A2Aの仕組みと実装は[A2A（Agent2Agent）プロトコルとは？v1.0の仕組み・MCPとの違い・実装手順](/tech/details/6732/)、MCPでのツール接続は[AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】](/tech/details/15365/)にまとめています。 ## 主要フレームワークの現在地（2026年10月9日時点） マルチエージェントを組める主なフレームワークと、PyPIで確認した最新版は次のとおりです。リリース頻度や保守方針は製品ごとに異なるため、採用時には公式の変更履歴を確認してください。 | フレームワーク | PyPIの最新版 | 公開日 | 連携の組み立て方 | | ------------------------- | ----------------------- | ---------- | ------------- | | OpenAI Agents SDK | openai-agents 0.23.1 | 2026-10-02 | ハンドオフとツール化 | | LangGraph | langgraph 1.2.14 | 2026-10-06 | 状態遷移のグラフ | | CrewAI | crewai 1.15.26 | 2026-10-08 | 役割とタスクの割り当て | | Microsoft Agent Framework | agent-framework 1.21.0 | 2026-10-08 | 5種のオーケストレーション | | Google ADK | google-adk 2.11.0 | 2026-10-02 | 親子エージェントとA2A | | AutoGen | autogen-agentchat 0.7.5 | 2025-09-30 | メンテナンスモード | [AutoGenの公式README](https://github.com/microsoft/autogen)では、新機能や機能強化を追加しない、コミュニティ管理のメンテナンスモードと案内されています。新規の利用者にはMicrosoft Agent Frameworkを勧めています。AutoGenで組んだ既存の仕組みをどう扱うかは[AutoGenとは？Microsoftのマルチエージェント基盤の現在地とv0.4以降の選び方【2026年版】](/tech/details/5020/)、移行先の詳細は[Microsoft Agent Framework 1.0とは｜Semantic KernelとAutoGenを統合した.NET/Python共通エージェントSDK](/tech/details/11675/)で扱っています。 選び方の目安は、ハンドオフ中心の窓口業務ならOpenAI Agents SDK（使い方はOpenAI Agents SDKの使い方｜handoff・as\_tool・ガードレールをv0.22で実装【2026年9月】）、分岐や承認を厳密に制御したいならLangGraph、役割分担を少ない記述で試したいならCrewAI（[CrewAIとは？Agent・Task・Crewの仕組みからAutoGen・LangGraphとの違い・採用判断まで実装者向けに解説【2026年版】](/tech/details/13598/)）です。8種を同じ課題で動かした比較は[AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】](/tech/details/15367/)にあります。 ## マルチエージェントが効く業務・効かない業務：研究データから見る判断基準 マルチエージェントは「複雑な業務ほど有利」と説明されがちですが、公表された評価を見ると、効くかどうかを決めるのは複雑さより業務の形です。 ### 並列化できる調査・分析での性能改善：AnthropicとGoogleの評価 Anthropicの社内評価では、調査用のマルチエージェント構成が単体のClaude Opus 4を90.2%上回りました（出典：[Anthropic「How we built our multi-agent research system」](https://www.anthropic.com/engineering/multi-agent-research-system)）。Google Researchが2026年1月28日に公開した評価（180構成を比較・出典：[Google Research「Towards a science of scaling agent systems」](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)）でも、売上・コスト・市場比較を別々のエージェントが同時に分析できる金融タスクで、中央集権型が単体比80.9%改善しています。どちらも、互いに独立した調べ物を同時に進められる業務です。 ### 逐次的な計画タスクでの性能低下とトークン消費の増加 同じGoogle Researchの評価で、前の手の結果を踏まえて次の手を決める計画タスク（PlanCraft）では、試したすべてのマルチエージェント構成が単体より39〜70%悪化しました。エージェント間の通信に処理を割かれ、肝心の推論が細切れになったためと説明されています。誤りの広がり方にも差があり、互いに連絡せず並列に動く独立型は誤りを最大17.2倍に増幅しました。中央集権型ではこれが4.4倍に収まっています。論文（[arXiv:2512.08296](https://arxiv.org/abs/2512.08296)）の改訂版は評価を260構成・6種類のベンチマークへ広げ、単体比の変化幅を+80.8%から-70.0%としています。 費用面では、Anthropicの測定でエージェント1体が通常のチャットの約4倍、マルチエージェントは約15倍のトークンを使いました。同社は、BrowseCompでの分析で性能のばらつきの80%がトークン使用量だけで説明できたとも書いています。この分析はトークン使用量と評価性能の関連を示していますが、90.2%の改善のうち何割がトークン増によるものかを直接示すものではありません。 ### 採用を見送る場面と、小さく始める進め方 次のどれかに当てはまる業務では、マルチエージェントを採用しないでください。 - 手順の前後関係が強く、単体構成との比較検証で分割による品質低下が確認された業務。GoogleのPlanCraftでの結果は、そのリスクを示す評価例です。 - 単体構成との比較検証で、1件あたりの費用や応答時間が許容上限を超える業務。Anthropicの約15倍という値は同社の測定例であり、自社業務の費用対効果は別途測定します。 - 1つのプロンプトとツール数本で片づく処理。LangChainのドキュメントも、適切なツールとプロンプトを持つ1体で同等の結果が得られることが多いと書いています。 採用するなら、成果を測りやすい1業務に絞り、中央集権型で2〜3体の構成から始めます。最初に単体構成で同じ業務を回して精度と費用を記録しておくと、分割した効果をトークン増と比べて判断できます。並列で調べる範囲が広い業務のうち、どこをエージェントに分け、どこをコードで固定するかの切り分けに迷う場合は、[AIエンジン開発の支援](/service/ai/recommend/)で業務の棚卸しから相談できます。 ## よくある質問 ### マルチエージェントとは何ですか？ 役割を分けた複数のAIエージェントが、情報を受け渡しながら1つの目標に向けて作業を分担する仕組みです。調査・分析・執筆のように責務を切り分ける構成が代表例で、結果の統合方法は中央集約やエージェント間の合意など、設計によって異なります。 ### マルチエージェントシステム（MAS）とLLMのマルチエージェントは同じものですか？ 考え方は同じですが、指す範囲が違います。MASはLLM以前からある分散人工知能の研究分野で、ロボットの群制御や利害が対立する主体の交渉も含みます。LLMのマルチエージェントは、判断をLLMに任せた協調型のMASと捉えると整理できます。 ### マルチエージェントのメリットとデメリットは何ですか？ メリットは、独立した調べ物を並列に進められることと、1体あたりのプロンプトとツールを絞れることです。デメリットは費用で、Anthropicの調査用システムの測定ではチャットの約15倍のトークンを使いました。逐次的な推論が中心の業務では精度が下がった評価もあります。 ### AIエージェントとマルチエージェントの違いは何ですか？ AIエージェントは自律的に判断して行動する1体の主体を指し、マルチエージェントはそれを複数組み合わせた構成を指します。1体で全工程を受け持つ構成はシングルエージェントと呼ばれます。 ### マルチエージェントの代表的なフレームワークは何ですか？ 2026年10月時点では、OpenAI Agents SDK・LangGraph・CrewAI・Microsoft Agent Framework・Google ADKが現役です。AutoGenはメンテナンスモードに入っているため、新規の構築では選ばないでください。 ## 関連記事 - [シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】](/tech/details/4261/) - [マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】](/tech/details/13600/) - [Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】](/tech/details/12108/) - [AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】](/tech/details/15367/) - [A2A（Agent2Agent）プロトコルとは？v1.0の仕組み・MCPとの違い・実装手順](/tech/details/6732/) --- 出典: [マルチエージェントとは？仕組み・構成パターンと採用判断を研究データで解説【2026年10月】]()（株式会社一創）