社内のAIシステムを設計していると、「MCPとA2Aは何が違うのか、自社にはどちらが必要か」という問いに直面します。どちらも「AIエージェントと外の世界を繋ぐプロトコル」に見えますが、解決するレイヤーが根本的に異なります。誤解したまま設計を進めると不要な複雑性を抱えるか、必要な機能を実装し損ねます。
MCPとA2Aはなぜ2つ存在するのか
MCPはエージェントとツールの垂直統合、A2Aはエージェント間委譲の水平連携を担うプロトコルです。解決するレイヤーが異なり、2つは競合せず補完関係にあります。
AIエージェントが「外の世界」と接続する経路には2つの方向があります。ひとつは「エージェントがツールやデータを使う」という縦方向の接続、もうひとつは「エージェントが別のエージェントに仕事を頼む」という横方向の接続です。
MCP（Model Context Protocol） はAnthropicが2024年11月に発表し、現在はLinux Foundation傘下のAgentic AI Foundationが管理するオープン仕様です。縦方向の接続——エージェントとファイル・データベース・外部APIの統合——を標準化します。
A2A（Agent-to-Agent Protocol） はGoogleが2025年4月に発表し、同年6月にLinux Foundationへ移管したオープン仕様です。横方向の接続——複数エージェント間でのタスク委譲と進捗共有——を標準化します。2026年にv1.0がリリースされ、Microsoft・AWS・Salesforceを含む150以上の組織が本番採用しています。
よく使われる比喩は「MCPはエージェントが手を使う方法、A2Aは2人のエージェントが握手する方法」です。2プロトコルを組み合わせることで初めて本格的なマルチエージェントシステムが成立します。
MCP——エージェントとツールを繋ぐ垂直統合
MCPはJSON-RPC 2.0ベースで、1エージェントが外部ツール・データにアクセスする標準プロトコルです。Tools・Resources・Promptsの3プリミティブで操作の種類を区別します。
MCPはMCPサーバーとMCPクライアント（AIアプリ）の2者間通信として成立します。Claude DesktopやVS Codeのようなアプリが「MCPホスト」として複数のMCPサーバーに同時接続し、各サーバーが特定のデータやツールへのアクセスを提供します。
MCPが定義する3つのプリミティブは「誰が起動を制御するか」で区別されます。
| プリミティブ | 制御主体 | 主な用途 |
|---|---|---|
| Tools | LLMが自律判断 | 外部API呼び出し・DB書き込み・副作用ある操作 |
| Resources | アプリが制御 | 社内文書・スキーマ・静的データの読み取り |
| Prompts | ユーザーが選択 | 繰り返し定型業務のテンプレート |
3プリミティブの詳しい使い分けは「MCPプリミティブをどう選ぶか」を参照してください。
MCPのトランスポートには2種類あります。ローカルで動作するサーバーにはstdio（標準入出力）を使い、リモートのサーバーにはStreamable HTTP（HTTP POST＋Server-Sent Events）を使います。後者の場合はBearerトークンやAPIキーで認証します。
SMBでのMCPの典型ユースケース: カレンダー・メール・社内DBへの読み書き、見積書の自動生成、在庫システムへの発注登録。単一エージェントが複数の業務システムを操作するシナリオはすべてMCPの領域です。
A2A——エージェント間を繋ぐ水平連携
A2Aは2026年v1.0時点で150以上の組織に採用された、エージェント間タスク委譲の標準プロトコルです。各エージェントはAgent Cardで能力を公開し、オーケストレーターが動的にタスクを割り当てます。
A2Aは「複数の専門エージェントを協調させる」ために設計されています。例えば、顧客問い合わせを受けたオーケストレーターエージェントが、「契約確認エージェント」と「在庫照会エージェント」にA2Aでタスクを委譲し、結果を統合して回答するといった構成が典型です。
Agent Card はRFC 8615のwell-known URI規約に従い/.well-known/agent.jsonに配置されるJSON文書で、エージェントの名称・スキル・認証要件・エンドポイントを記述します。他のエージェントがドメイン情報だけで機能を発見・接続できます。A2A v1.0では暗号署名付きSigned Agent Cardsが導入され、カード偽造攻撃への耐性が強化されています。
タスクライフサイクルはsubmitted → working → completed/failedの状態機械で管理されます。長時間の非同期処理が最初から設計に組み込まれており、サブタスクの並列実行や途中での入力要求にも対応します。
SMBでA2Aが必要になる典型例: 社内に「調査エージェント」「文書作成エージェント」「承認確認エージェント」が存在し、それらを動的に連携させる場合。単一エージェントでの自動化フェーズを超えて、役割別のエージェントチームを組む段階で初めて必要になります。
中小企業のプロトコル選択フロー
「外部ツール接続」ならMCP、「エージェント間委譲」ならA2Aが担当です。単一エージェント構成ではMCPのみで十分です。
選択の軸は「自社のエージェント構成」で決まります。
| シナリオ | 選択 |
|---|---|
| 1エージェントが社内DBや外部APIを操作する | MCPのみ |
| 1エージェントが複数MCPサーバーに同時接続する | MCPのみ |
| 専門エージェント間でタスクを動的に委譲する | MCP＋A2A |
| 異なるベンダーのエージェントを連携させる | A2A（各エージェントはMCPも使用） |
多くの中小企業は最初「MCPのみ」フェーズで自動化を進め、エージェントの役割が増えてきた段階でA2Aを追加するステップが現実的です。
MCPとA2Aを組み合わせた構成例: オーケストレーターがA2Aで専門エージェントへタスクを委譲し、各専門エージェントはMCPで自分のツール（DB・API・ファイル）にアクセスする。2プロトコルが担うレイヤーが異なるため、干渉せずに共存できます。
MCPサーバーの実装方法については「MCPサーバーを実装する」を、エンタープライズ向けのA2A認証・委譲設計の詳細は「A2AプロトコルとMCPの使い分け」を参照してください。
エージェントプロトコルの選定や設計のご相談は Kuuの運用管理サービス（AI Ops） からお問い合わせください。
参考
- MCP Architecture Overview（公式ドキュメント）
- A2A Protocol: How Google's Agent-to-Agent Standard Grew to 150+ Organizations | Stellagent
- MCP vs A2A Protocol（Atlan）
まとめ
MCPは「エージェントとツール・データの垂直統合」、A2Aは「エージェント間の水平連携」という役割の違いが明確です。単一エージェントで業務自動化を始める中小企業はMCPから実装し、専門エージェントを組み合わせる段階でA2Aを追加するのが現実的な道筋です。2プロトコルはどちらが優れているかではなく、解決したい問題のレイヤーで選ぶものです。
エージェントプロトコルの設計や運用体制の整備については、Kuuの運用管理サービス（AI Ops）にお気軽にご相談ください。