「A2AもMCPも、AIエージェントをつなぐ規格らしい」。ここまでは分かっても、何と何をつなぐのかが曖昧なままだと、構成図に両方の名前を置いただけで設計が止まります。似た用語ですが、担当する接続は同じではありません。
先に結論を言うと、MCPはエージェントがデータや道具を使うための接続、A2Aは異なるエージェント同士が仕事を依頼し合うための接続です。競合する二択ではなく、複数の担当エージェントを動かす場面では併用できます。順番に見ていきます。
最初に結論
A2Aは、異なるAIエージェントが能力を公開し、仕事を依頼し、途中経過や成果物を受け渡すためのオープンな連携方式です。MCPが「エージェントとツール・データ」の接続を受け持つのに対し、A2Aは「エージェントとエージェント」の協働を受け持ちます。最初から両方を入れるのではなく、単一エージェントで解けるかを確認し、担当分離が必要になった段階でA2Aを検討するのが現実的です。
この記事のポイント
- ・MCPは道具への接続、A2Aは仕事を担うエージェント同士の連携と覚える
- ・A2AではAgent Cardで能力や接続先を示し、Task単位で依頼と状態を管理する
- ・小さな業務は単一エージェントで始め、権限・責任・システムが分かれるときに分割する
- ・自律性を増やすほど、本人確認、最小権限、承認、監査ログが重要になる
対象：AIエージェントを業務へ導入したい事業責任者、情シス、データ・アプリケーション担当者
1. A2AとMCPは、つなぐ相手が違う
Google CloudはA2Aを、別々のベンダーやフレームワークで作られたエージェントが相互運用するためのプロトコルとして公開しました。一方のMCPは、モデルやエージェントからファイル、データベース、検索、業務APIなどへ共通の形でアクセスするための規格です。
身近な会社に置き換えると、MCPは担当者が使う電話・台帳・計算機の共通差し込み口、A2Aは営業担当から審査担当へ案件を引き継ぐ伝票に近いものです。営業エージェントが顧客DBを読む部分はMCP、審査エージェントへ確認を依頼する部分はA2A、という分担ができます。
| 観点 | A2A | MCP | 通常のAPI |
|---|---|---|---|
| 主な接続 | エージェント同士 | エージェントとツール・データ | 決められたシステム同士 |
| 中心となる情報 | 能力、タスク、状態、成果物 | 利用可能なツール、リソース、プロンプト | エンドポイント、入力、出力 |
| 向く場面 | 担当や組織をまたぐ協働 | 多様な道具を共通方式で利用 | 処理内容が明確な固定連携 |
| 関係 | MCPを使うエージェント同士も接続できる | A2Aと併用できる | 両規格の内部実装でも利用される |
2. Agent CardとTaskで仕事を引き継ぐ
A2Aの入口になるのがAgent Cardです。エージェントの名前だけでなく、何ができるか、どこへ接続するか、どの認証を求めるかを機械が読める形で示します。依頼側はこの情報を見て、仕事を任せられる相手かを判断します。
実際の仕事はTaskとして扱われます。すぐ終わる質問だけでなく、資料作成のように時間がかかる処理でも、受付済み、作業中、追加入力待ち、完了といった状態を共有できます。人が途中で補足したり、最終成果物を受け取ったりする前提を持てる点が、単発のAPI呼び出しとの違いです。
- 発見する：Agent Cardを読み、必要な能力と認証方法を持つ相手を選びます。
- 依頼する：目的、制約、入力資料をTaskとして渡します。
- 状態を追う：作業中や追加入力待ちを確認し、必要なら人が情報を補います。
- 成果物を受け取る：回答だけでなく、作成された文書や構造化データを受け取ります。
3. 営業分析から承認までを例に考える
たとえば営業会議の前に、分析エージェントがDWHから今月の失注率を調べ、営業支援エージェントが失注案件の活動履歴を確認し、資料作成エージェントが会議用の要点をまとめる流れを考えます。各エージェントが自分のデータへ接続する部分ではMCPを利用でき、担当間の依頼と成果物の受け渡しにはA2Aを利用できます。
ただし、名前を三つに分けただけで品質が上がるわけではありません。どの担当が数値を確定するのか、顧客情報をどこまで渡してよいか、資料の公開前に誰が承認するかを決めなければ、誤りの責任が見えにくくなります。人間の組織図と同じで、分業には役割と引き継ぎ条件が必要です。
4. A2Aを使うべき場面、まだ使わない場面
A2Aが有効なのは、複数部門や複数サービスが独立したエージェントを持ち、互いの内部実装を知らずに協働したい場合です。外部企業の旅行エージェントと社内の経費規程エージェントを組み合わせるような、所有者の異なる連携でも意味があります。
反対に、一つのチームが管理する小さなFAQ、決まったSQLの実行、単純な通知であれば、通常のAPIやワークフローで十分です。早すぎるマルチエージェント化は、通信回数、待ち時間、障害点、評価対象を増やします。まず一つの目的を一つのエージェントで完了できるかを試してください。
- 使う候補：別部門・別企業・別製品のエージェントが協働する
- 使う候補：長い仕事の途中状態や成果物を標準的に受け渡したい
- 見送る候補：処理順と入力が固定され、通常のワークフローで再現できる
- 見送る候補：一つの管理者、一つの権限、一つのデータソースで完結する
5. 小さく安全に始めるための確認事項
最初の実証では、読み取り専用の業務を一つ選びます。Agent Cardへ能力だけでなく認証要件を明記し、依頼元、依頼先、使用したデータ、判断結果を同じTask IDで追えるようにします。失敗時の再実行とタイムアウトも、正常系より先に決めておくと運用しやすくなります。
発注、送金、公開、削除のような不可逆操作は、人の承認を越えない設計にします。A2Aは通信の共通形を提供しますが、業務上の正しさや相手エージェントの信頼性まで保証するものではありません。許可された相手か、渡す情報は最小限か、成果物をどう検証するかは導入側の責任です。
- 一業務に絞る：読み取り中心で、正解を人が確認できる依頼を選びます。
- 責任を決める：入力、判断、承認、障害対応の担当を明文化します。
- 権限を絞る：エージェントごとに必要最小限のデータと操作だけを許可します。
- 記録して評価する：Task単位の入出力、待ち時間、失敗、承認差し戻しを確認します。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Agent2Agentプロトコル：エージェントの相互運用性の新時代 — Google Cloud（2025-04-10）（最終確認：2026-08-07）：A2Aの目的、設計原則、MCPとの補完関係を確認
- Agents、ADK、Agent Engine、A2Aの機能強化 — Google Developers Blog（2025-05-20）（最終確認：2026-08-07）
- Google CloudがA2AをLinux Foundationに寄贈 — Google Developers Blog（2025-06-23）（最終確認：2026-08-07）
- A2A Extensions: Empowering custom agent functionality — Google Developers Blog（2025-09-09）（最終確認：2026-08-07）
- A2A発表時の公開トレンド — X Trends（2025-04-09）（最終確認：2026-08-07）：話題化の観測用。仕様の根拠には使用していない
よくある質問
A2AがあればMCPは不要ですか？
不要にはなりません。A2Aはエージェント同士、MCPはエージェントとツールやデータの接続を主に担当します。一つのエージェントがMCPで社内データを読み、その結果をA2Aで別のエージェントへ渡す構成が可能です。
A2Aは普通のAPIと何が違いますか？
APIは決められた処理の入出力を呼ぶのが基本です。A2Aは相手の能力を発見し、長時間のTask状態や追加対話、成果物をやり取りするための共通モデルを持ちます。固定処理ならAPIの方が単純です。
最初から複数のAIエージェントを作るべきですか？
通常は一つから始めます。異なる権限や責任、専門性を分離する必要が確認できてから分割した方が、評価と障害対応が容易です。エージェント数ではなく、業務の完了率と安全性で判断してください。
まとめと次の一歩
A2Aの価値は、エージェントの数を増やすことではなく、権限や責任の異なる担当間で依頼と成果物を追跡できることにあります。単一エージェントで完結するうちは構成を増やさず、分業の理由が説明できる業務だけに使うのが要点です。