マルチエージェント設計のA2AとMCP：中堅企業が両方必要になる条件

このガイドは、2つ目のエージェントが最初のエージェントと通信する必要があるかどうか（システムとの通信だけでなく）を判断しなければならないCTOやエンジニアリングリード、および追加プロトコルが監査コストに見合うかを検討しているITガバナンスオーナーを対象としています。MCPサーバーガイドでは、このページが前提とするエージェント対ツール層を設計しています。エージェントAIアーキテクチャガイドでは、1つのエージェント自身のループ内に人間のチェックポイントを配置しています。このページはその両方の上位層、つまり2つ目のエージェントが登場した際に何が変わるかを扱います。

このガイドの内容

• MCPとA2Aは同じ問題を解決するのか？
• 2層パターン
• 中堅企業はA2Aがまだ必要か？
• 実践事例：マルチエージェント設計としての受注から入金まで
• 2つ目のエージェントが呼び出し元になると何が変わるか
• マルチエージェント設計におけるAIの位置づけ
• 存在する納品実績と存在しないもの
• 代替案：複数のエージェントを調整する他の方法
• このガイドの限界
• よくある質問
• 次のステップ

MCPとA2Aは同じ問題を解決するのか？

いいえ。MCP（Model Context Protocol）は、エージェントが業務に必要なツール・データ・システム（注文状況の照会、CRMの更新、ドキュメント検索など）に接続します。A2A（Agent2Agent）は、エージェントから別のエージェントへ接続します。エージェントが2つ目のエージェントの機能を検出し、タスクを送信し、その完了を追跡できるようにするプロトコルであり、エージェントとデータソース間ではなく、2つの推論システム間のプロトコルです。エージェントが1つで5つのツールを持つ企業にはMCPのみで十分であり、その設計では別のエージェントへの検出も委任も発生しません。

2層パターン

両プロトコルを使用するほとんどの企業は、A2Aを上位層に配置して、どの専任エージェントがジョブのどの部分を担当するかを調整し、各エージェントの下にMCPを配置して、その部分が必要とするシステムに接続します。どちらかの層を取り除くと、別の部分が機能しなくなります。A2Aなしでは、エージェントは構造化された方法でタスクを引き渡せなくなります。MCPなしでは、委任されたタスクを受け取ったエージェントはそれに対してガバナンスされた形で行動する手段がなくなります。

中堅企業はA2Aがまだ必要か？

エージェントが1つで複数のツールを持つ中堅企業のほとんどは、まだA2Aを必要としません。シングルエージェント設計では、2つ目の推論システムへ作業を委任するものが何もないため、スコープとガバナンスが整ったMCPだけがシンプルな答えです。問いは「エージェントが何個のツールを使うか」ではなく、「タスクが完了するまでに、異なるチームが構築・所有する別々のエージェントをいくつ経由するか」です。

有用なテスト：すべてのツール呼び出しを、それを承認した1つのエージェントと1人の担当者にさかのぼれるか？シングルエージェント設計では、1つのエージェントがタスク全体を保持しているため、答えは常に「はい」です。タスクがリクエストを分類するトリアージエージェントとそれに対応する請求エージェントの2つに分かれた瞬間、追跡もエージェントをまたいでタスクを追う必要があります。そうしなければ、承認されたアクションが「実際にどのエージェントが要求したか」というコンテキストを失います。A2Aが価値を持つのはその時点です。2つ目のツールが追加されたときではなく、2つ目のエージェントが加わったときです。

実践事例：マルチエージェント設計としての受注から入金まで

受注から入金までのガイドでは、受注から入金まで（受注受付、与信審査、請求書発行、回収フォローアップ）のサブステップを、エージェントが適する箇所と人間が判断する箇所に対応づけています。各サブステップに1つのエージェントを構築する場合（プロセス全体を担う大きな1つのエージェントではなく）、まさにこの条件に該当します。回収エージェントが争議中の請求書を請求エージェントへ引き渡す必要があるか、受付エージェントが与信審査エージェントの回答を先に必要とするかのような状況です。各エージェントは引き続き自身のシステムへの独自のMCP接続を必要とし、A2Aによってエージェントが互いを検出し、引き渡しの監査に十分なコンテキストを付けてタスクを受け渡せるようになります。

存在する納品実績と存在しないもの

Netbaseは、マルチエージェント設計の各エージェントが独自のガバナンスされたアクセスを必要とするようなシステムを構築し、このページが前提とするシングルエージェントのコントロールループとツール公開層を設計してきました。

• 米国クライアント向けマルチテナントクラウドERP（クライアント非公開）。2020年以降、SaaSとして提供するクラウドERPのオフショア開発と管理パートナー。フェーズ1はCRM、ナレッジベース、作業・プロジェクト管理、API連携をカバーし、専任エージェントのMCP接続がラップするようなシステムです。
• ERPおよびCRMコンサルタンシー（クライアント非公開）。Odooのコンサルティングとカスタマイズ、カタログ・在庫・注文・顧客データをAPIで同期するECサイト対ERPインテグレーション、VtigerからERPへのアップグレード。いずれも個々のエージェントのMCPツールが呼び出す、定義された範囲のあるアクションであり、生のデータベース接続ではありません。
• その他の納品済みAI（匿名）：検索拡張型ナレッジアシスタント、ドキュメントAI、ここでは非公開のクライアント向けMLOpsパイプライン（F072）。

存在しないもの。A2Aプロトコルによるマルチエージェントシステムやプロダクションでのエージェント間委任、A2AとMCPの組み合わせによる計測済み結果を説明する公開済みのNetbaseの実績はありません。上記の判断ルール・2層パターン・シーケンスステップは、NetbaseのERP/CRMインテグレーションおよびシングルエージェント納品実績（F070、F072、F076、F077）と引用プロトコルソースに基づいており、測定済みのマルチエージェントまたはA2Aプロジェクトに基づくものではありません。マルチエージェントまたはA2Aの導入に関して、期間・コスト・精度・採用率などの数値は一切主張しません。

代替案：複数のエージェントを調整する他の方法

A2Aをまだ追加しない場合。複数のツールを持つシングルエージェントで、2つ目の推論システムへ作業を引き渡す必要がない場合、委任プロトコルは不要です。追加しても調整する対象がなく、複雑さが増すだけです。2つ目の専任エージェントが存在するか確実に計画された段階でA2Aを追加してください。

Netbaseのカスタム開発では、クライアントが自社向けに作成されたIPを所有し、ほとんどのプロジェクトはディスカバリー後に合意された請負契約で進みます。エージェント対ツール層はシステムおよびAPI連携とERPおよびCRM開発に位置し、エージェント向け設計はAI連携に、エージェントAI自動化とエンタープライズAIエージェントプラットフォームを通じて、プロフェッショナルサービスなどの業界向けに提供されます。

このガイドの限界

• 両プロトコルはまだ新しく、頻繁に改訂されます。いずれかのアーキテクチャにコミットする前に、最新の仕様を確認してください。
• 判断ルールと2層パターンは設計の出発点であり、特定のマルチエージェントシステムが安全であるか正しくスコープされていることを保証するものではありません。
• マルチエージェントまたはA2Aの導入に関して、期間・コスト・精度・採用率などの数値は一切主張しません。
• A2Aを追加しても、このクラスターの他のガイドが扱うシングルエージェントの制御（承認・トレース・キルスイッチ）が不要になるわけではありません。置き換えではなく、上位層として追加されます。

次のステップ

設計に実際に何台のエージェントが必要か、各エージェントがどのシステムにアクセスする必要があるかをお知らせください。委任層・ツール接続・それをまたぐ承認トレールのスコープを定めるためにソリューションレビューをご予約します。エージェントAI自動化サービスをご覧いただくか、Netbase JSCのインサイトを閲覧することもできます。

関連サービスとソリューション