LASSIC Media らしくメディア
生成AIのマルチエージェント連携・実装を外注
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- 生成AIのマルチエージェントは、1つの業務を複数の専門エージェントに分担させ、オーケストレーターが進行を管理する仕組みです。
- Anthropicは研究タスクの評価で、リード役エージェントと複数の専門エージェントを組み合わせた構成が単一エージェントを上回ったと報告しています*1。
- 代表的な構成にはスーパーバイザー型と対等協調型があり、失敗時の制御や人の確認をどう組み込むかで設計の難度が変わります。
目次
生成AIのマルチエージェントとは、複数の専門エージェントが協調して働く仕組み
生成AIのマルチエージェントとは、1つの大きなタスクを複数の専門AIエージェントに分担させる仕組みです。オーケストレーター(進行を管理する役割のエージェントまたは制御ロジック)が各エージェントの出力を統合し、1つの答えに仕上げます*1。単一のAIエージェントが1つの対話や1つのツール群で完結する構成であるのに対し、マルチエージェントは役割ごとに独立したエージェントを組み合わせる点が異なります。
Anthropicは自社の研究支援システムについて、主要エージェントがクエリを分析して戦略を立てると説明しています*1。そのうえで複数の下位エージェントを生成し、異なる観点を並行して調べさせる構成です*1。各下位エージェントには明確な目標・出力形式・ツール利用の指針を渡す必要があり、この境界があいまいだと作業の重複や漏れが生じると述べています*1。
この設計は、複数の視点を並行して調べる調査・分析業務や、専門領域が明確に分かれる業務との相性が良好です。一方、1つのエージェントとツール群で完結する定型業務にまで適用すると、通信や統合の手間がかえって増える場合があります。
スーパーバイザー型と対等協調型——代表的な2つのマルチエージェント構成
マルチエージェントの構成は、スーパーバイザー型と対等協調型(ネットワーク型・スウォーム型)の2つに大別できます*6。どちらを選ぶかによって、開発と運用の難度が変わってきます。
スーパーバイザー型は、中央のエージェントがユーザーの要求を受け取り、適切な専門エージェントへ処理を振り分ける方式です*2*6。Amazon Bedrock Agentsのマルチエージェント連携機能では、スーパーバイザーエージェントが複数のコラボレーターエージェントと連携できます*2。公式ガイドでは、既存ローン対応・新規ローン対応・一般的な質問対応のように役割を分けた例が示されています*2。
対等協調型は、エージェント同士が中央の管理役を介さず直接連携し合う方式です。LangGraphでは、中央集権的なSupervisorパターンに対し、エージェントが互いに直接ハンドオフし合うSwarmパターンも用意されています*6。
状態管理の仕組みはSupervisor構成と共通しています*6。さらに複数のスーパーバイザーを階層化し、研究チーム用・執筆チーム用のように専門スーパーバイザーを分けたうえで、上位のスーパーバイザーが束ねる構成も紹介されています*6。
両者の違いを整理すると次の通りです。
| 項目 | スーパーバイザー型 | 対等協調型 |
|---|---|---|
| 通信経路 | 中央のエージェントを常に経由*2 | エージェント同士が直接ハンドオフ*6 |
| 適した業務 | 担当領域が明確に切り分けられる業務*2 | 前工程の結果次第で担当が変わる業務*6 |
| 進行の管理 | 単一の視点で進行を管理しやすい*2 | 各エージェントの自律性が高い分、全体の把握が複雑になりやすい*6 |
| 実装例 | Amazon Bedrock Agentsのスーパーバイザー構成*2 | LangGraphのSwarmパターン*6 |
プランナー・実行・レビュー——役割分担とエージェント間通信の仕組み
マルチエージェント内の役割分担は、プランナー(計画立案)・実行役・レビュー役のように機能で分けるのが基本形です。Google Agent Development Kit(ADK。マルチエージェントアプリを構築するGoogleのフレームワーク)では、生成エージェントと評価エージェントを直列につなぐ構成が使えます*5。レビュー役が基準を満たすまで結果を洗練させる反復改善のパターンも紹介されています*5。
エージェント間の通信は、共有状態への書き込みと、ハンドオフ(処理を次のエージェントへ引き渡す仕組み)の2つが軸になります。LangGraphのSupervisorパターンでは、ハンドオフをツール呼び出しとして実装します*6。会話履歴のどこまでを次のエージェントに渡すかも選べる設計です*6。
ツール実行についても、各エージェントが担当範囲のツールだけを持つ設計が基本です。ADKのシーケンシャルパイプラインでは、検証・処理・レポート作成のように固定順で処理をつなぎ、前段の出力を次段の入力にする直列処理が示されています*5。並列に処理したいタスクについては、複数の処理を同時に走らせて結果を集約するパターンも用意されています*5。
専門エージェントが社内文書やデータベースを参照する場面では、検索拡張生成の仕組みをツールの1つとして組み込む設計も選択肢になります。ツールの範囲をエージェントごとに絞ることで、意図しない操作の広がりを抑えられます。
失敗時の制御とヒューマンインザループ——止める設計と人の確認ポイント
マルチエージェントは、途中の1エージェントが失敗しても全体を止めずに続行できる設計にしておく必要があります。Anthropicは、エージェントの失敗を検知した際にシステム全体を再起動するのではなく、それまでの状態から再開できる仕組みを実装したと説明しています*1。加えて観測性を高め、どこで失敗したかを追跡できるようにしています*1。
人の確認を挟む設計(ヒューマンインザループ)にも複数の形があります。Microsoft AutoGenでは、人間からの入力を常に求める・完了条件を満たしたときだけ求める・求めないの3段階から選べる設計が示されています*7。即時の承認や却下のような短い判断はチームの実行中に差し込み、それ以外は実行完了後にまとめてフィードバックを反映する非同期の形が適していると説明されています*7。
ADKのワークフローパターンにも、承認前に人の確認を必須にするヒューマンインザループの型が用意されています*5。どの処理で人の判断を必須にするかを、設計の初期段階で決めておく必要があります。
単一エージェントとの違い——導入を判断する境界線
単一のAIエージェントは、1つの対話スレッドの中で計画・実行・回答をまとめて担当します。ツールの範囲が絞られ、応答までの経路が単純な業務では、単一エージェントの構成で足りる場面があります。
マルチエージェントへの切り替えを検討する目安は2つあります。専門知識の異なる複数の観点を同時に調べたい場合と、1回のやり取りで完結しない複数ステップの処理を並行させたい場合です。
Anthropicは、リード役のClaude Opus 4と複数のClaude Sonnet 4のサブエージェントを組み合わせた研究支援システムを評価しています*1。この評価では、同構成が単一のClaude Opus 4を上回ったと報告されています*1。これはAnthropic自身の研究タスクの評価によるものであり、すべての業務領域に当てはまる結果ではありません。
単一エージェントの設計・開発については別稿で解説しています。本稿は、複数エージェントをどう連携させるかという協調設計に焦点をあてます。
内製と外注の分かれ目——フレームワークの変化速度と必要スキル
マルチエージェントの実装を内製するかどうかの分かれ目は、採用するフレームワークの選定と、その変化への追随に要する工数です。Microsoft AutoGenは現在メンテナンスモードに位置づけられています*4。新規の機能追加は行われず、後継のMicrosoft Agent Frameworkへの移行が案内されています*4。
Agent FrameworkはAutoGenとSemantic Kernelの機能を統合したフレームワークです。両フレームワークの直系の後継だとMicrosoftは説明しています*4。
Amazon Web Servicesも同様の転換点にあります。マルチエージェント連携機能を含む既存のAmazon Bedrock Agentsは、新規顧客の受け付けを2026年7月30日に終了します*2。後継となるAmazon Bedrock AgentCoreへの移行が案内されています*3。
AgentCoreはLangGraphやCrewAIなど複数のオープンソースフレームワークと組み合わせて使える基盤として位置づけられています*3。
この作業を内製で担うには、採用したフレームワークの仕様変更を継続して追い、移行が必要になった際に既存の役割分担・通信設計を作り直せる体制が要ります。1名の担当者が通常業務と並行して対応する場合、フレームワークの転換点を見落とすおそれがあります。
外注時に確認すべき5つの要件
外部パートナーへ委託する場合は、次の点を契約前に確認しておくと、後工程での手戻りを抑えやすくなります。
- どのオーケストレーション方式(スーパーバイザー型・対等協調型)を採用し、選定理由を説明できるか*6
- 採用フレームワークが現在も更新され続けているか、後継フレームワークへの移行計画があるか*4*3
- エージェントが失敗した場合に、どこまで自動で再開し、どこから人の確認を挟むか*1*7
- 各エージェントに割り当てるツールの範囲と、想定外の操作を防ぐ仕組みがあるか
- エージェント間の通信・実行状況を追跡できる観測の仕組みがあるか*1
これらを個別に確認するだけでなく、委託先が過去にどの業務でマルチエージェントを構築した経験を持つかも合わせて確認すると、要件の理解度を判断しやすくなります。
まとめ:マルチエージェント導入で押さえる3つの判断軸
本稿では生成AIのマルチエージェントについて、単一エージェントとの違いから代表的な構成、外注時に確認すべき要件までを整理しました。要点は3つに集約できます。第一に、マルチエージェントはオーケストレーターが役割分担と統合を担う仕組みで、専門領域が明確に分かれる業務や複数の観点を並行して調べる業務との相性が良好です*1。第二に、代表的な構成にはスーパーバイザー型と対等協調型があり、失敗時の制御や人の確認をどう組み込むかで設計の難度が変わります*2*6。第三に、採用するフレームワークは現在も転換が進んでおり、内製と外注のどちらであっても継続した追随が欠かせません*3*4。
よくある質問
単一のAIエージェントとマルチエージェントは何が違いますか。
単一のAIエージェントは1つの対話の中で計画・実行・回答をまとめて担当します。マルチエージェントは、オーケストレーターが複数の専門エージェントに役割を分担させ、その出力を統合する点が異なります*1。専門領域が明確に分かれる業務や、複数の観点を並行して調べたい業務ほど、後者の構成が向いています。
マルチエージェントを導入すると開発・運用の負荷は増えますか。
エージェントの数が増えるほど、役割分担・通信経路・ツールの範囲を設計する工数は増える傾向があります。特に対等協調型では、各エージェントの自律性が高まる分、全体の動きを把握する設計が複雑になりやすい点に注意が必要です*6。導入前に、単一エージェントで足りる業務かどうかを見極めておくことが大切です。
スーパーバイザー型と対等協調型はどちらを選べばよいですか。
担当領域が明確に切り分けられる場合はスーパーバイザー型、前工程の結果によって担当が変わる場面が多い場合は対等協調型が候補になります*2*6。どちらも上位のスーパーバイザーを重ねる階層構成へ発展させられるため、小さな構成から始めて拡張する進め方が実務的です。
エージェントが失敗した場合、どこまで人が確認すればよいですか。
即時の承認や却下のような短い判断はその場で人に確認し、それ以外は実行が完了した後にまとめて確認する非同期の形が実務的だと説明されています*7。どの処理を人の確認が必須の工程にするかは、業務の重みに応じて事前に決めておく必要があります。
外注先を選ぶ際、フレームワークの選定はどこまで確認すべきですか。
採用中のフレームワークが現在も更新され続けているか、後継フレームワークへの移行計画を持っているかを確認しておくとよいでしょう*4*3。長期的な運用でも設計の作り直しを抑えやすくなります。フレームワークの転換に対応できる体制を持つ委託先かどうかを見ておくことが大切です。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:Anthropic「How we built our multi-agent research system」Anthropic Engineering Blog(2025年6月13日)(https://www.anthropic.com/engineering/multi-agent-research-system)
- *2 出典:AWS「Use multi-agent collaboration with Amazon Bedrock Agents」AWS Bedrock User Guide(https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html)
- *3 出典:AWS「What is Amazon Bedrock AgentCore?」AWS Bedrock AgentCore Developer Guide(https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)
- *4 出典:Microsoft「Microsoft Agent Framework Overview」Microsoft Learn(2026年2月9日公開・2026年6月11日更新)(https://learn.microsoft.com/en-us/agent-framework/overview/agent-framework-overview)
- *5 出典:Google「Workflow patterns」Agent Development Kit (ADK) Documentation(https://adk.dev/workflows/patterns/)
- *6 出典:LangChain AI「langgraph-supervisor-py」GitHubリポジトリREADME(https://github.com/langchain-ai/langgraph-supervisor-py)
- *7 出典:Microsoft「Human-in-the-Loop」AutoGen AgentChat User Guide(https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/tutorial/human-in-the-loop.html)