2026.10.05

マルチエージェントAIとは？仕組みと得意な業務・導入時の注意点

AIエージェントを調べていると、複数のエージェントに役割を分けて連携させるマルチエージェントの構成図に行き当たります。調査役、執筆役、確認役が矢印でつながった図は分かりやすく、1つのエージェントより賢く動きそうに見えるものです。

ところが、エージェントを増やせば成果が上がるわけではありません。担当を分けた分だけ受け渡しの手間とトークンの消費が増え、失敗が起きる箇所も増えます。仕事によっては、1つのエージェントで組んだほうが速く、安く、確実に終わります。

ここでは、マルチエージェントAIの定義、向く仕事と向かない仕事の見分け方、設計で決める3項目（役割分担と受け渡し・権限と人の承認・評価とコスト）を解説します。内容は2026年10月時点の情報にもとづいています。AIエージェントの企画や開発方針を決める事業部門・情報システム部門の担当者の方に向けた内容です。

分けて組むべきかどうかの見極めは、malnaのAIエージェント構築支援で対象業務の整理から相談いただけます。

マルチエージェントAIとは、役割を分けた複数のAIエージェントが1つの仕事を進める構成です

マルチエージェントAIとは、指示・道具・権限の異なる複数のAIエージェントを連携させ、1つの仕事を分担して進める構成のことです。判断と作業を1つのエージェントが抱える単一エージェントと違い、仕事の分け方と担当どうしのつなぎ方が設計の中心になります。

単一エージェントとの違いは、判断と文脈を分けるかどうか

単一エージェントでは、1つのモデルが1つの指示文に従い、道具（ツール）を選びながら作業を繰り返します。読んだ情報はすべて同じ文脈（コンテキスト）にたまり、判断も1か所で下されます。

マルチエージェントになると、文脈が担当ごとに分かれます。代表的なのは、指揮役が仕事を分解して担当に渡し、担当が自分の範囲だけを処理して結果を返す形です。担当ごとにモデルや道具、触れてよいデータを変えることもできます。

観点	単一エージェント	マルチエージェント
判断する場所	1か所	指揮役と各担当に分散
文脈（コンテキスト）	1つにたまる	担当ごとに分かれる
道具と権限	1つのエージェントにまとめて渡す	担当ごとに絞って渡せる
処理の進め方	基本は1つずつ順番に	並行して進められる
動作の追いやすさ	1本の記録を追えばよい	担当ごとと全体の両方を追う

エージェントを内部構造や自律度で分類する整理と、5つの連携パターンの詳細は、次の記事で扱っています。ここから先は、分けるかどうかの判断と、分けたあとの設計に話を絞ります。

関連記事：AIエージェントの種類とは？仕組みや自律性の違いと選び方

主要な開発基盤での呼び方

マルチエージェントの組み方は、開発基盤によって呼び名が少しずつ異なります。ただ、指揮役が担当を呼び出す形と、担当どうしが仕事を引き継ぐ形の2つが軸になっている点はどこも同じです。

提供元	公式の説明
OpenAI（Agents SDK）	指揮役が専門のエージェントを道具として呼び出す「agents as tools」と、担当に処理を引き継いで残りを任せる「handoffs」の2つを中心に説明している
Anthropic	自社の調査機能の構成として、指揮役が計画を立てて複数のサブエージェントを並行して動かすオーケストレーター・ワーカー型を公開している
Microsoft（Azure Architecture Center）	シーケンシャル、コンカレント、グループチャット、ハンドオフ、マゼンティックの5つのオーケストレーションパターンを整理している
Google（ADK）	親エージェントの下に sub_agents を置き、順番に動かす SequentialAgent や同時に動かす ParallelAgent、振り分け役のコーディネーターなどのパターンを示している

OpenAIのAgents SDKのドキュメントは、組み方をさらに「LLMに計画させる方法」と「コードで流れを決める方法」に分けています。後者のほうが、速度・費用・性能の面で動きを予測しやすいという説明です。

参考：Workflow patterns（Agent Development Kit）

エージェント間の通信規格A2Aと、MCPとの関係

別々の会社や基盤で作られたエージェントどうしをつなぐ規格に、A2A（Agent2Agent）プロトコルがあります。公式サイトではAIエージェント間の通信と協業のためのオープン標準と説明されており、運営はLinux Foundationのもとで行われています。

一緒に語られることの多いMCP（Model Context Protocol）は、エージェントと道具をつなぐ規格です。A2Aの公式サイトは、MCPがエージェントと道具の通信を、A2Aがエージェントどうしの通信を受け持ち、両者は補い合う関係だと位置づけています。A2Aでつながるエージェントは、内部の記憶や道具、独自の処理を相手に見せずにやり取りできるとも説明されています。

社内で完結するマルチエージェントであれば、A2Aは必須ではありません。社外のエージェントや、別の基盤で作られたエージェントと連携させる段階で検討する規格です。

参考：A2A Protocol（Linux Foundation）

公式の解説は、そろって「まず単一エージェントから」を勧めています

マルチエージェントは、単一エージェントでは確実にこなせない仕事が見えてから採用する構成です。OpenAI、Anthropic、Microsoftの公式の解説は、いずれも要件を満たす中で最も単純な構成から始め、必要になった分だけ複雑さを足すよう勧めています。

Microsoftは複雑さを3段階に分けています

Microsoftの「AIエージェントオーケストレーションパターン」は、マルチエージェントを採用する前に、その場面で本当に必要かを評価するよう求めています。段階が1つ上がるごとに調整の手間と待ち時間と費用が増えるので、要件を確実に満たせる最も低い段階を選ぶ、という考え方です。

段階	中身	向く場面
直接のモデル呼び出し	よく作り込んだプロンプトで1回呼び出す。エージェントの仕組みも道具も持たない	分類や要約のように1回で終わる処理
道具を持つ単一エージェント	1つのエージェントが道具やデータを選び、呼び出しを繰り返して結果を詰める	1つの領域の中で、問い合わせに応じて道具を使い分ける仕事
マルチエージェント	専門の担当を複数置き、指揮役などが分担・文脈の共有・結果の集約を管理する	部門や領域をまたぐ問題、担当ごとに別のセキュリティ境界が要る場面、並行して専門化すると効く仕事

同じページは、道具を持つ単一エージェントを、企業の用途の多くで既定にしてよい選択肢と位置づけています。マルチエージェントは調整の手間や待ち時間、失敗の種類を増やします。プロンプトの複雑さ、道具の多さ、セキュリティ要件のいずれかが理由で単一エージェントでは確実に処理できないとき、はじめてその複雑さに見合う理由が生まれる、という書き方です。

OpenAIは単一エージェントの能力を先に引き出すよう勧めています

OpenAIの「A practical guide to building agents」は、一般的な推奨として、まず単一エージェントの能力を引き出し切ることを挙げています。エージェントを増やすと概念は切り分けやすくなるものの、複雑さと負荷も増えるので、道具を持つ単一エージェントで足りる場面が多いという説明です。

分割を考える目安は2つ示されています。1つ目は、プロンプトの条件分岐が増えすぎて、指示文の雛形を広げにくくなった場合です。2つ目は道具の過多で、問題は数よりも道具どうしの似通い方にあるとしています。明確に区別された道具を15個より多く扱えている例がある一方、重なり合う道具が10個に満たなくても苦戦する例があるという記述です。道具の名前や説明を分かりやすく直しても改善しないときに、はじめてエージェントを分ける順序になっています。

Anthropicは最も単純な解決策から探すよう勧めています

Anthropicの「Building effective agents」は、できるだけ単純な解決策を探し、必要なときにだけ複雑さを増やすよう勧めています。同じ記事は、あらかじめ決めたコードの流れでLLMと道具を動かすものを「ワークフロー」、LLMが自分で進め方を決めるものを「エージェント」と呼び分けています。

複数のLLMを組み合わせる形として紹介されているのは、中心のLLMが仕事を分解して作業役に配るオーケストレーター・ワーカー型と、あるLLMの結果を別のLLMが評価して改善させる評価者・最適化者型などです。マルチエージェントの前に、こうした決まった流れで足りないかを見ておきます。

参考：Building effective agents（Anthropic）

マルチエージェントが向く仕事

マルチエージェントが向くのは、仕事を独立した部分に分けられ、分けることで速さ・扱える量・安全性のどれかがはっきり良くなる仕事です。公式の解説が挙げる条件を業務の言葉に直すと、次の4つに整理できます。

独立した方向を並行して調べる仕事

1つの問いに対し、互いに依存しない方向を同時に調べる仕事では、マルチエージェントが力を発揮しやすくなります。Anthropicは自社の調査機能で、幅広い問いを複数のサブエージェントに割り振って同時に調べさせる構成を公開しています。

同社の社内の調査タスクの評価では、Claude Opus 4を指揮役、Claude Sonnet 4をサブエージェントにした構成が、Claude Opus 4単独の場合を90.2%上回ったと報告されています。業務でいえば、競合各社の公開情報の収集や、複数の製品カテゴリにまたがる市場調査のように、調べる範囲を切り分けられる仕事が当てはまります。

1つの文脈に収まらない量の情報を扱う仕事

資料が多く、1つのエージェントの文脈に入りきらない仕事も候補です。担当がそれぞれ別の文脈で資料を読み、要点だけを返せば、指揮役の文脈は結論の整理に使えます。

Anthropicも、マルチエージェントが特に向く条件として、並行化しやすいこと、1つの文脈の容量を超える情報を扱うこと、複雑な道具を数多く使うことの3つを挙げています。

担当ごとに権限の境界を分けたい仕事

扱うデータの機密度が担当によって違う場合も、エージェントを分ける理由になります。Microsoftは、担当ごとに別々のセキュリティ境界が要る場面を、マルチエージェントで対応できる場面の1つに数えています。

たとえば、社外の公開情報を集める担当には社内データへの接続を渡さず、社内の顧客データを扱う担当にはインターネットへの接続を渡さないという分け方です。すべての権限を1つのエージェントに持たせるより、誤った操作が起きたときの影響を狭く抑えられます。

作る役と確かめる役を分けたい仕事

下書きを作る担当と、決めた基準で確かめる担当を分ける構成も、よく使われる形です。Microsoftはこれを作成者とチェッカーのループとして説明しており、チェッカーが不足を見つけると具体的な指摘を添えて作成者に差し戻します。

この形では、チェッカーが毎回同じ基準で合否を出せるよう、明確な受け入れ基準が欠かせません。修正の往復が終わらなくなるのを防ぐ反復回数の上限と、上限に達したときに人の確認へ回すといった扱いも先に決めておきます。

マルチエージェントが向かない仕事

マルチエージェントが向かないのは、担当どうしが同じ前提を細かく共有しないと進まない仕事と、増える費用に見合う価値がない仕事です。公式の解説は、向く条件と同じくらい、向かない条件もはっきり書いています。

全員が同じ前提を共有しないと進まない仕事

Anthropicは、すべてのエージェントが同じ文脈を共有する必要がある領域や、エージェント間の依存が多い領域は、現時点ではマルチエージェントに向かないとしています。例として挙げているのは、ほとんどのコーディング作業です。

業務に置き換えると、1つの契約書を全体の整合をとりながら直す作業や、前の判断を受けて次の判断が細かく変わる作業が近いでしょう。担当を分けると前提を説明し直す手間がかさみ、担当ごとの解釈のずれが結果に残ります。

費用に見合う価値がない仕事

マルチエージェントは単一エージェントよりトークンを多く使います。Anthropicの公開記事によると、同社のデータでは、エージェントはチャットでのやり取りの約4倍、マルチエージェントは約15倍のトークンを使っていました。

同じ記事は、経済的に成り立たせるには、増えた性能の分を支払えるだけ価値の高い仕事であることが条件だとしています。1件あたりの価値が小さく件数の多い社内の定型問い合わせに、調査向けの重い構成をそのまま持ち込むと、費用が先に膨らみます。

単一エージェントの手直しで解決できる問題

単一エージェントの精度が出ない原因が、分割の必要性ではなく、指示文や道具の説明の分かりにくさにある場合もあります。OpenAIのガイドが、道具の名前・引数・説明を明確にしても改善しないときに分割を考える順序を示しているのは、この見極めのためです。

Microsoftも、意味のある専門化をもたらさないエージェントを足すことや、単純な構成で足りるのに複雑なパターンを選ぶことを、避けるべき誤りとして挙げています。

設計で決めること1：役割分担と受け渡し

マルチエージェントの設計で最初に決めるのは、どこで担当を分け、担当どうしで何を受け渡すかです。役割の切り方と受け渡しの中身が曖昧なままだと、作業が重なったり、必要な情報が誰の手にも渡らなかったりします。

役割は、専門化に意味がある単位で切る

担当を分けるのは、指示・道具・データ・モデルのいずれかを担当ごとに変える必要があるときです。Microsoftは利点として、担当が特定の領域に集中できるので指示文とコードの複雑さが下がること、テストと修正を担当単位で行えることを挙げています。

同じ道具と同じ指示で動く担当を、名前だけ変えて並べても受け渡しが増えるだけです。役割の候補を書き出したら、担当ごとに何が違うのかを1行で言えるかどうかを確かめます。

指揮役を置くか、担当どうしで引き継ぐか

担当のつなぎ方は、指揮役が担当を呼び出して結果を受け取る形と、担当が次の担当に処理ごと引き継ぐ形に大きく分かれます。OpenAIのガイドは、前者をマネージャー型、後者を分散型と呼んでいます。

観点	指揮役が呼び出す形（マネージャー型）	担当どうしで引き継ぐ形（分散型）
主導権	指揮役が最後まで持つ	引き継いだ担当に移る
利用者とのやり取り	指揮役だけが行う	引き継いだ担当が直接行う
向く仕事	範囲の決まった作業だけを任せ、結果を1つにまとめたい仕事	振り分け自体が仕事の一部で、選んだ担当に残りを任せたい仕事

Agents SDKのドキュメントも、範囲の決まった作業を手伝わせるが主導権は渡さない場合は「agents as tools」、振り分けが流れの一部で選んだ担当に残りを任せたい場合は「handoffs」と使い分けを示しています。問い合わせの一次受付から担当部署へ回す仕事なら引き継ぐ形、複数の調査結果を1つの報告にまとめる仕事なら指揮役が呼び出す形が合わせやすいでしょう。

渡す指示には、目的・出力形式・使う情報源・範囲を書く

指揮役から担当への指示が短すぎると、担当どうしで同じ作業をしたり、必要な部分を誰も調べなかったりします。Anthropicは、サブエージェントへの指示に、目的、出力の形式、使う道具や情報源の指針、仕事の明確な範囲を含める必要があるとしています。

同じ記事には、仕事の重さに応じて担当の数を変えるよう指揮役に指示した例も載っています。単純な事実確認なら1つのエージェントで道具を3〜10回呼び出す程度、比較なら2〜4のサブエージェント、複雑な調査なら10を超えるサブエージェントという目安です。

受け渡す文脈は必要な分だけにする

担当が増えると、それぞれの推論や道具の結果が積み重なり、文脈はみるみる膨らみます。Microsoftは、次の担当が働くのに必要な文脈を見極め、全文を渡す場面と、前の担当の出力を要約して渡せば足りる場面を分けるよう勧めています。

時間のかかる仕事や、利用者とのやり取りが何度も続く仕事では、途中の状態を外部に保存しておくことも勧められています。進み具合と中間結果が残っていれば、中断しても途中から再開できます。保存する情報を必要最小限に絞れば、トークンの負担とプライバシーの危険も抑えられます。

参考：Agent orchestration（OpenAI Agents SDK）

参考：A practical guide to building agents（OpenAI）

設計で決めること2：権限と人の承認

マルチエージェントの安全性は、担当ごとに渡す権限と、人が承認する場所の決め方で大きく変わります。担当が増えるほど、誤った出力や不適切な操作が次の担当へ流れていく経路も増えるため、権限は担当単位で絞り込みます。

担当ごとに必要最小限の権限だけを渡す

Microsoftは、エージェントと指揮役を最小特権の原則に沿って設計すること、エージェント間の通信に認証を入れること、監査の記録を残すことを挙げています。使える道具とデータを担当ごとに絞っておけば、1つの担当が判断を誤っても、影響はその範囲で止まります。

書き込みや送信のように外部へ影響する操作は、それを必要とする担当にだけ持たせます。調査や確認の担当を読み取り専用にしておくと、権限の設計がそのまま役割の説明にもなります。

利用者の閲覧権限を、すべての担当で守らせる

社内データを扱う構成では、利用者が本来見られないデータを、担当経由で見せてしまわない仕組みが要ります。Microsoftは、エージェントは全利用者の要求に応えるため広いアクセス権を持つ一方、その利用者がアクセスできないデータを返してはならず、その制御はパターン内のすべてのエージェントに実装する必要があるとしています。

制御を指揮役だけに任せ、担当の側では利用者の権限を見ない作りにすると、どこかの担当から情報が漏れる余地が残ります。

人の承認を挟む位置を決める

人の承認は、担当の出力全体ではなく、特定の操作に絞って挟む方法があります。Microsoftによれば、承認の対象を特定の道具の呼び出しに限れば、影響の小さい操作は自律的に進め、機密性の高い操作だけで承認を求められます。

承認が必須の箇所では処理がそこで止まります。その時点の状態を保存し、承認後に前の担当の作業をやり直さずに再開できるようにしておきます。承認を先へ進める許可として扱うのか、担当に戻して直させる指摘として扱うのかも、あらかじめ決めておくところです。

関連記事：自律型AIエージェントとは？仕組みと業務に導入するための条件

担当の出力は、次に渡す前に確かめる

ある担当の誤った出力は次の担当の入力になり、後ろの工程で大きくなります。Microsoftは、次のエージェントに渡す前に出力を検証し、質の低い応答や形式の崩れた応答には、再試行、確認の依頼、処理の停止のいずれかで対応するよう勧めています。

時間切れと再試行の仕組み、エラーを隠さず後続に伝えること、反復回数の上限も挙げられています。

設計で決めること3：評価とコスト

評価とコストは、動かしたあとに付け足すものではなく、設計の段階で測り方を決めておく項目です。マルチエージェントでは、担当ごとの動きと全体の結果の両方を見ない限り、どこで品質が落ち、どこに費用がかかっているのかが分かりません。

評価は少数の事例から始め、採点基準で判定する

マルチエージェントの出力は毎回同じにならないので、完全一致で正誤を判定する方法は使えません。Microsoftは、統合テストに採点基準（ルーブリック）や言語モデルによる評価を使うよう勧めています。

Anthropicは、大規模な評価を作り込む前に、約20件の問いの小さなサンプルから始めた経験を紹介しています。開発の初期は変更の影響が大きいので、少ない事例でも差が見えるという理由です。採点はLLMに0.0〜1.0の点数と合否を出させる方法で行い、自動評価で見落とす部分を人の評価で補っています。

担当ごとと全体の両方を記録する

担当を分けた構成では、全体の結果を見ただけでは、どの担当で問題が起きたのかを突き止められません。Microsoftは、すべての担当の動作と受け渡しを記録すること、担当ごとの性能とリソース使用量を追って基準値を持つこと、担当単位でテストしやすい入出力にすることを勧めています。

担当ごとのトークン消費が残っていれば、費用の内訳から、どこを軽くすべきかも数字で判断できます。

担当ごとにモデルの大きさを変える

すべての担当に最も高性能なモデルを使う必要はありません。Microsoftは、担当ごとに仕事の複雑さに合ったモデルを割り当てるよう勧めており、分類・抽出・書式の整形を担う担当は、全体の品質を落とさずに小さく安いモデルで済むことが多いとしています。

Anthropicの調査機能も、指揮役とサブエージェントで異なるモデルを組み合わせています。判断の重い指揮役と、範囲の決まった作業をこなす担当とでは、求める性能を分けて考えてよいということです。

費用は、構成の形と往復の回数で見積もる

マルチエージェントの費用は、担当の数に加えて、どうつなぐかでも変わります。Microsoftの説明では、順番に呼び出す構成や引き継ぐ構成は同時に使う資源を抑えられる反面、工程ごとに費用が積み上がります。並行に動かす構成は処理量が増える代わりに、資源の消費が一時的に跳ね上がることがあります。指揮役が計画を練り直し続ける構成は、総費用を最も予測しにくいとされています。

Anthropicは、BrowseCompという評価での分析で、性能のばらつきの80%がトークンの使用量だけで説明できたと報告しています。性能とトークン消費がこれだけ結び付いている以上、試す段階で担当の数と往復の回数を記録し、1件あたりの費用が仕事の価値に見合うかを確かめてから範囲を広げるのが現実的です。

参考：How we built our multi-agent research system（Anthropic）

参考：AIエージェントオーケストレーションパターン（Microsoft Learn）

関連記事：AIエージェントの開発方法！必要な技術と費用・外注時の注意点