MCP・A2A・AG-UI——これらは競合している規格ではありません。

2026年、AIエージェント開発の現場でこの3つの略語が頻繁に登場するようになりました。「どれを選ぶのか」「全部使うのか」という疑問は多いですが、答えはシンプルです。それぞれが異なるレイヤーの問題を解決する補完的な規格であり、本番システムでは3つを組み合わせて使います。

この記事でわかること：

  • MCP・A2A・AG-UIそれぞれの役割と担うレイヤー
  • 3つのプロトコルが連携する実際の処理フロー
  • 設計時にどのプロトコルを選ぶかの判断基準

https://www.copilotkit.ai/blog/the-state-of-agentic-ui-comparing-ag-ui-mcp-ui-and-a2ui-protocols

3つのプロトコルの全体像

TCP・HTTP・HTMLがそれぞれ異なるレイヤーを担ってWebを成立させているように、MCP・A2A・AG-UIも担う範囲が明確に分かれています。

プロトコル 開発元 担うレイヤー
MCP Anthropic エージェント ↔ ツール・データ
A2A Google / Linux Foundation エージェント ↔ エージェント
AG-UI CopilotKit エージェント ↔ ユーザーインターフェース

この3つが組み合わさることで、ツール呼び出し・エージェント協調・UI通信というAIエージェントの3つの課題を解決できます。

MCP — ツールアクセスの標準化

MCP（Model Context Protocol）はAnthropicが策定したプロトコルで、エージェントが外部ツールやデータを利用する方法を統一します。登場以前は、データベースへのアクセスやAPIの呼び出しはすべて独自実装が必要でした。

MCPはJSON-RPC 2.0ベースのクライアント・サーバーモデルを採用しています。MCPサーバーが公開するのは主に3つです。モデルが呼び出せる関数である「ツール」、参照できる読み取り専用データの「リソース」、再利用可能なテンプレートの「プロンプト」です。

AWSはBedrock AgentCore RuntimeでS3・DynamoDB・CloudWatchなど主要サービスのMCPサーバーをオープンソース提供しています。

MCPが適しているのは「エージェントが外部システムを操作する必要があるとき」です。エージェント同士の連携はMCPの担当外であり、それはA2Aが解決します。

A2A — エージェント同士の協調

A2A（Agent-to-Agent Protocol）はGoogleが主導し、Linux Foundationに移管されたオープン規格です。異なるフレームワークで作られたエージェントが、互いの内部実装を知らずに協調する仕組みを定義しています。

最大の特徴は「不透明性」です。エージェントは自分のツールや内部ロジックを公開せず、できること（スキル）だけを外部に宣言します。LangGraphで作ったエージェントとCrewAIで作ったエージェントが、実装の違いを気にせず連携できます。

エージェントは /.well-known/agent.json に「エージェントカード」を公開し、名前・スキル・入出力形式・認証方式を宣言します。タスクはsubmitted → working → completedのライフサイクルで管理され、長時間処理はServer-Sent Eventsでストリーミング更新できます。

A2Aが向いているのは、異なるチームや企業が作ったエージェントを組み合わせるケースです。ツール呼び出しのみであればMCPで十分で、A2Aは不要です。

AG-UI — エージェントとUIのリアルタイム通信

AG-UI（Agent-to-UI Protocol）はCopilotKitが開発したオープン規格で、エージェントバックエンドとユーザー向けフロントエンドをリアルタイムでつなぎます。

MCPとA2Aがバックエンドのロジックをカバーするのに対し、AG-UIはユーザーが実際に操作する画面との通信を標準化します。課題はシンプルで「エージェントが処理している間、ユーザーはローディングスピナーしか見えない」という問題です。

AG-UIは約16種類のイベントタイプを定義しています。処理の開始・終了を通知するライフサイクルイベント、テキストをトークン単位で流すテキストメッセージイベント、実行中ツールをユーザーに見せるツールイベント、UI状態を差分更新するステートデルタ、重要な操作前にユーザーの承認を求めるインタラプトなどです。

2026年3月にはAWS Bedrock AgentCore RuntimeがAG-UIサポートを追加しています。LangGraph・CrewAI・PydanticAI・Mastraなど主要フレームワークとの統合も用意されています。バックグラウンドのバッチ処理などユーザーとのやり取りが不要なケースでは、AG-UIは過剰になります。

3つのプロトコルが連携する処理フロー

実際の本番環境では、3つのプロトコルは次のように連携します。

ユーザーが質問を送ると、AG-UIがフロントエンドからスーパーバイザーエージェントへリクエストを転送し、リアルタイムの進捗を返します。スーパーバイザーはMCPでデータベースやAPIを直接呼び出します。複雑なサブタスクはA2Aで専門エージェントに委譲され、結果がA2A → スーパーバイザー → AG-UI → ユーザーの順で返ります。

各プロトコルの担当範囲が明確に分かれているため、競合は起きません（参考）。

設計時の判断基準

新しいエージェントシステムを設計するときは、次の3つの問いで判断できます。

「エージェントが外部ツールやデータにアクセスするか」——YesならMCPです。

「複数のエージェントが協調するか」——YesならA2Aです。特に異なるチームや企業が作ったエージェントを連携させる場合に効果的です。

「エージェントがリアルタイムでユーザーに情報を届けるか」——YesならAG-UIです。ツールの実行状況の表示、ユーザーの承認待ち、フォームやダッシュボードの更新を扱います。

AWS Bedrock AgentCore Runtimeは3つすべてをネイティブにサポートしており、同一インフラ上にデプロイできます。MCP・A2A・AG-UIをそれぞれの担当レイヤーで分けて設計することが、保守性の高いAIエージェントシステムへの近道です。