マルチエージェントシステム：AI agentが連携して働く仕組み
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
マルチエージェントシステムとは、より狭い役割に絞った2つ以上のAI agentが、1つのagentにすべてを任せる代わりに、仕事の一部を分担し、互いにコンテキストを受け渡す仕組みです。オーケストレーター、または定義されたハンドオフの連鎖が、次にどのagentが動くかを決め、前のagentが得た情報を引き継ぎ、結果を1つの成果にまとめます。企業がマルチエージェントシステムを選ぶのは、仕事の中にツールやルール、コンテキストの異なる明確なフェーズがある場合です。agentの数が多いほど高度に聞こえる、という理由ではありません。
シングルagentとマルチagent：境界線はどこにあるか
複数のagentが必要に見えるタスクの多くは、実際にはツールを増やした1つのagentで足ります。Web検索、CRMの参照、メール送信ができる単一のagentは、モデルがそのすべてを1つの共有コンテキストで推論できるため、意外なほど多様なケースを自力で処理できます。
OpenAIのAI agent構築実践ガイドはこの点を明確にしています。まず単一のagentから始めてツールを少しずつ追加し、そのagentの指示、ツール、意思決定ロジックが複雑になりすぎて確実にテスト・保守できなくなって初めて、複数のagentに分けるべきだというものです。ガイド自身の説明では、単一のagentでもツールを段階的に追加すれば、複雑さを抑えたまま長く対応でき、別々のagentをオーケストレーションせざるを得なくなる前に多くのことができるとされています。
この線引きをさらに掘り下げた分類はAI agentの種類で扱っており、シングルagent設計とマルチagent設計の位置づけも説明しています。個々のagentが単独で動くときも、大きなシステムの一部として動くときも、実行するループはAI agentの仕組みで説明したものと同じです。
複数agentを連携させる2つの方法
仕事に本当に複数のagentが必要になったら、それらをつなぐ一般的な方法は2つあります。
| パターン | 仕組み | 適した場面 |
|---|---|---|
| オーケストレーター・ワーカー | 中心となるagentが仕事をサブタスクに分解し、ツールを呼ぶのと同じ要領で専門agentを呼び出し、結果を統合する | 調整役が明確で、ワーカー同士が直接やり取りする必要がない仕事 |
| ピアハンドオフ | 1つのagentが自分の担当を終えると、中心となる調整役を置かずに、定義された連鎖の次のagentへ直接タスクを渡す | 自然に段階が直線的に並ぶ仕事 |
OpenAIは、オーケストレーター・ワーカー型をagents-as-toolsとして説明しています。どの専門agentを呼ぶかを決め、出力をまとめ上げるマネージャーagentです。AnthropicのBuilding Effective Agentsガイドは、本番導入の事例をもとに、同じオーケストレーター・ワーカー型を、実際のagentシステムの大半をカバーする少数のパターンの1つとして紹介しています。ルーティングやプロンプトチェーンといった、それだけで十分なことも多いより単純なパターンも併せて挙げられています。ピアハンドオフは中心となる調整役を完全に省きます。各agentは自分の担当範囲で何をすべきかを理解していて、終わったら構造化された結果を次へ渡します。ハブというよりリレーに近い形です。
実例：リードのスコアリングから商談予約まで
ここでは、3つの専門agentで構成したピアハンドオフの連鎖を紹介します。それぞれが同じ仕事の1つのフェーズを担当します。
- AI Lead Scoring Agent は、新しいインバウンドのリードを読み込み、ICPの基準と行動シグナルに照らして確認し、その根拠とともに適合度スコアを出力します。
- AI Lead Routing Agent は、そのスコアを受け取り、テリトリー、製品ライン、案件規模のルールに基づいて、適切なキューや担当者にリードを割り当てます。
- AI Follow-Up Agent は、ルーティングされたリードを引き継ぎ、アウトリーチのケイデンスを実行します。スコアリングのコンテキストを使うので、最初のメッセージが汎用的なテンプレートのようにならず、このリードがなぜ重要なのかを反映したものになります。
各ハンドオフでは、長い自由記述のテキストではなく、構造化されたレコードを次へ渡します。スコア、その根拠、ルーティングの判断です。これが連鎖を機能させる要です。もしLead Scoring Agentが構造化されていない段落を出力し、Routing Agentが特定のフィールドを期待していたら、ハンドオフは気づかれないまま失敗するか、Routing Agentが推測するしかなくなります。AI SDR Agentのブループリントは、インバウンドではなくアウトバウンドで似た形を示しています。リサーチ、シーケンス設計、CRMへの記録が、3つの別々のagentではなく、より広い1つの役割の中で行われます。フェーズが単純で1つのagentの守備範囲に収まるなら、これも妥当な選択肢です。
もう1つの例：チケットのトリアージからエスカレーションまで
サポート業務でも、3つではなく2つのagentで同じパターンが見られます。AI Support Triage Agentは、届いたすべてのチケットを読み込んで分類し、単純なケースは自分で解決するか、重大度が高いものやSLAに関わるものにフラグを立てます。フラグが立ったチケットはAI Escalation Manager Agentに引き継がれます。このagentはSLAのカウントダウンを追跡し、適切な人間のチームにルーティングし、期限が迫る間、関係者全員に状況を共有し続けます。
2つのagentが、内部の仕組みの詳細をすべて共有する必要はありません。Triage AgentはSLAポリシーがどう設定されているかを知る必要はなく、Escalation Managerはチケットがどう分類されるかを知る必要はありません。互いに合意しておくべきなのは、何を渡すかだけです。チケット、その分類、緊急度です。これは機能するマルチagent境界すべてに共通する設計原則です。AI agentがツールを使う仕組みが単一agentのツールスキーマについて説明している原則と同じものを、agentと関数の間ではなく、agent同士の間という一段上の階層に適用したものです。
オーケストレーションが難しい理由
仕事を複数のagentに分けると決めるのは簡単な判断です。本当の作業は、連携を確実に動かすことです。どのagentをいつ動かすかの順序づけ、1つのagentの失敗で連鎖全体を止めない処理、想定した経路に収まらないエッジケースのルーティングなどが含まれます。この連携の層には名前があり、順次、並列、条件分岐、ハイブリッドといったオーケストレーションのパターンも含めて、AIオーケストレーションとはで詳しく解説しています。
この層への関心は急速に高まっています。Gartnerは、2024年第1四半期から2025年第2四半期にかけて、マルチエージェントシステムに関する顧客からの問い合わせが1,445%急増したと報告しています。この数字が実際に測っているものを理解しておく必要があります。これはアナリストへの問い合わせ件数であり、関心と評価の高まりを示すシグナルです。そうした問い合わせの大半が実際の本番システムになったことの証拠ではありません。「関心を持つ」ことと「確実に運用する」ことの間にあるギャップこそが、オーケストレーション設計の領域です。
複数のagentから、役割レベルの1つのagentへ
マルチエージェントシステムと、多くの機能を持つ単一のagentは、必ずしも別物ではありません。マルチエージェントシステムは、役割レベルの単一agentの中身を開いたときの姿である場合もあります。ある機能全体を「担当する」AI Sales OperatorやAI Support Agentは、1つの巨大なモデルがすべてをこなしているのではなく、複数のパターンが連携して動いていることがよくあります。
パターンを積み重ねてAI agentを構築するでは、パターン間のつなぎ目で現れる具体的な失敗モードを含めて詳しく解説しています。これは、マルチエージェントシステムで別々のagentの間に現れる接合部のリスクと同じです。データ形式の不一致、積み重なるレイテンシ、誰にも気づかれないまま下流に流れていくエラーなどです。
マルチエージェントシステムが破綻する場所
agentを増やせば、連携が必要な接点も増えます。そして、問題が起きるのは連携の接点です。
レイテンシが積み重なります。 連鎖にagentが1つ増えるたびに、そのagentの処理時間が加わります。各ステップに数秒かかる5つのagentの連鎖では、ツールを増やした単一のagentよりも、ユーザーがはるかに長く待つことになりかねません。
ハンドオフは気づかれないまま失敗します。 Agent Aの出力形式が、Agent Bの期待するものから少しでもずれると、Agent Bは必ずしもエラーを出すとは限りません。不完全な入力や誤読した入力のまま処理を進め、自信満々に誤った結果を出すことがあります。
エラーはagentの境界を越えて伝播します。 連鎖の最初のagentによる誤った分類は、下流のすべてのagentが最適化の基準とする入力になります。人間が気づく頃には、1つではなく複数のagentが誤った情報に基づいて動いています。Autonomous Agentパターンは、単一agentのループ内で起きる同じ累積リスクを扱っています。マルチエージェントシステムも同一のリスクを抱えますが、それがループの反復ではなくagentの境界をまたいで広がる点が異なります。
ガバナンスが見えにくくなります。 個々のagentはそれぞれ単独では適切に統制されていても、ハンドオフの部分に抜け穴が残ることがあります。あるagentから次のagentへ移るデータを誰が承認したのか、組み合わさったシステムが誤りを犯したとき誰が責任を負うのか、といった点です。Gartnerは、agentic AIプロジェクトの40%超が2027年末までに中止されると予測しており、その理由としてコストの増大、不明確なビジネス価値、不十分なリスク管理を挙げています。マルチagentのプロジェクトは、統制すべき対象が多い分、単一agentのプロジェクトよりもこうしたリスクを多く抱えます。
マルチagentにするか、ツールを増やした単一agentにするか
| シグナル | マルチagent向き | シングルagent向き |
|---|---|---|
| フェーズごとの専門性 | 各フェーズで異なるルール、トーン、判断が必要 | 仕事全体が同じコンテキストとルールを共有している |
| 並列作業 | フェーズが独立して動き、後で統合できる | 作業が本質的に順次的で単純 |
| ハンドオフの明確さ | 作業を次へ渡す、きれいで構造化された接点がある | 仕事を分けると、雑然とした非構造化のコンテキストを渡すことになる |
| チームのオーナーシップ | フェーズごとに担当チームが異なり、別々の可視性を求めている | すでに1つのチームがワークフロー全体を担当している |
| 保守の複雑さ | 単一agent版が複雑になりすぎて、確実にテストできなくなった | 連携コストの増加に見合う段階にまだ達していない |
正直なところ、基本は次のとおりです。まず、ツールの範囲を適切に絞った単一のagentを試してください。複数のagentに移るのは、そうすべき根拠が出てきたときです。マルチagentのアーキテクチャがスライドの上で洗練されて見えるから、という理由ではありません。
Key Facts
- マルチエージェントシステムは、専門化したagentに仕事を分け、構造化されたコンテキストを引き継がせます。連携は中心となるオーケストレーターか、定義されたピアハンドオフの連鎖で行います。
- OpenAI自身のガイダンスは、まず単一のagentから始め、1つのagentの守備範囲が複雑になりすぎて保守できなくなってから複数のagentに分けることを推奨しています。
- Gartnerは、マルチエージェントシステムに関する問い合わせが1,445%急増したと記録しています。これは需要のシグナルであり、その規模で導入が成功した証拠ではありません。
- 最もよくある障害ポイントは、agent間のハンドオフにあります。データ形式の不一致、積み重なるレイテンシ、下流に気づかれず伝播するエラーです。
- Gartnerは、コスト、不明確な価値、弱いリスク管理を理由に、agentic AIプロジェクトの40%超が2027年までに中止されると予測しています。連鎖にagentを加えるたびに、このリスクは大きくなります。
マルチエージェントシステムに関するよくある質問
マルチエージェントシステムとは何ですか。
マルチエージェントシステムとは、より狭い役割を持つ2つ以上のAI agentが、仕事の別々の部分を担当し、互いにコンテキストを引き継ぐ仕組みです。連携は、専門agentに仕事を割り振る中心的なオーケストレーターを通じて行うか、各agentが構造化された結果を次へ渡す、定義されたピアハンドオフの連鎖で行います。
ツールを増やした1つのagentではなく、マルチエージェントシステムを使うべきなのはどんなときですか。
仕事に、ルール、ツール、コンテキストの異なる明確なフェーズがあり、作業を次へ渡すきれいで構造化された接点がある場合に、複数のagentを使います。適切にツールを絞った1つのagentでバリエーションに対応できるなら、通常はそのほうが、agentに分けるより構築、テスト、統制が簡単です。
オーケストレーター・ワーカーパターンとピアハンドオフの違いは何ですか。
オーケストレーター・ワーカーパターンでは、中心となるagentが仕事をサブタスクに分解し、ツールを呼ぶのと同じ要領で専門agentを呼び出して、結果を統合します。ピアハンドオフには中心となる調整役がありません。1つのagentが自分の担当を終えると、定義された連鎖の次のagentにタスクを直接渡します。
マルチエージェントシステムが失敗する原因は何ですか。
ほとんどの失敗は、個々のagentの内部ではなく、agent間のハンドオフで起こります。よくある原因は、あるagentが出力するものと次のagentが期待するものとのデータ形式の不一致、agentが増えるごとに積み重なるレイテンシ、そして初期のagentによる誤った出力を、下流のagentが誤りに気づかないまま使ってしまうことです。
マルチエージェントシステムは、単一の自律型agentとどう違いますか。
単一の自律型agentは1つのループを実行し、そのループの中で複数のツールを使って目標を追いかけます。マルチエージェントシステムは、仕事を複数の別々のagentに分け、それぞれが自分のループと守備範囲で動き、オーケストレーターまたはハンドオフの連鎖で連携します。個々のagentのリスク(ループのステップをまたいで累積するエラーなど)は、マルチエージェントシステムの各agentにも引き続き当てはまり、さらにagent間の接合部のリスクが加わります。
マルチエージェントシステムは、単一のagentより運用コストが高くなりますか。
一般的には、計算リソースの面でも連携のオーバーヘッドの面でも高くなります。agentが増えるごとに処理ステップが加わり、レイテンシとコストが増えます。だからこそ、適切に守備範囲を絞った単一のagentから始め、1つのagentでは仕事を十分にこなせない明確な理由が出てから増やす、というのが標準的なアドバイスです。
次に読むもの
マルチエージェントシステムは、このライブラリの別の記事で扱っている2つの要素から作られます。ツールをうまく呼び出すagent(AI agentがツールを使う仕組み)と、次に何をすべきかを明確に推論するagent(AI agentの推論の仕組み)です。最初のマルチエージェントプロジェクトの範囲を決める準備ができたら、AI agentの作り方でその進め方を確認してください。上で紹介したようなトリアージからエスカレーションまでの連鎖を検討している場合は、サポートツールの比較記事とAIカスタマーサービスツールのおすすめガイドが出発点として役立ちます。
