AI Agentプロトコル解説：MCP、A2A、ACP、AG…

まず結論

MCP、A2A、ACP、AG-UIは互いの直接的な代替ではありません。Agentシステムの異なる通信境界を標準化するためのものです。

プロトコル	主な問題	典型的な境界
MCP	AIアプリがツール、データ、prompt、コンテキストへ接続する方法	Agent/ホストアプリからツール/リソースサーバー
A2A	あるAgentが別のAgentへタスクを委譲する方法	Agent間のタスク協調
ACP	Agentを相互運用可能なサービスとして公開する方法	Agentサービス相互運用
AG-UI	Agentが状態やアクションをUIへストリームする方法	AgentバックエンドからフロントエンドUI

本番システムで重要なのは「どのプロトコルが勝つか」ではなく、「どの境界を標準化したいか」です。

なぜAgentにプロトコルが必要なのか

初期のAgentシステムでは、ツール呼び出し、UIイベント、マルチAgent委譲を1つのアプリにハードコードしがちです。試作では動きますが、ツール、チーム、ベンダー、UIが増えると壊れやすくなります。

プロトコルは責務を分離します。

ツールやデータソースをAgentから独立して公開できる。
Agentが内部実装を隠したままタスクを委譲できる。
フロントエンドが進捗、ツール呼び出し、中間状態を一貫して表示できる。
セキュリティチームが明確な境界で権限と監査を設計できる。

MCP：ツールとコンテキスト統合

MCP、Model Context Protocolは、AIアプリケーションが外部ツールやコンテキストへ接続するためのプロトコルです。クライアント/サーバーモデルで、ホストアプリがツールを発見・呼び出し、リソースを読み取り、promptテンプレートを利用できます。

MCPが向く場面：

AIアプリがデータベース、ファイルシステム、API、リポジトリ、業務システムを使う。
ツールサーバーを複数のAgentクライアントで再利用したい。
リソースやpromptを標準的に公開したい。
ツールschemaと権限を明確にしたい。

MCPが最も強いのは「Agentがツールを呼ぶ」境界です。マルチAgent全体の編成やUI表示方法を定義するものではありません。

AIアプリ / Agentホスト
  -> MCP client
  -> MCP server
  -> データベース、ファイルシステム、API、内部ツール

A2A：Agent間のタスク協調

A2A、Agent-to-Agentは、Agent同士がどのように協力するかに焦点を当てます。Agentが能力を公開し、別のAgentやオーケストレーターからタスクを受け取る考え方です。

A2Aが向く場面：

複数の専門Agentが協力する。
計画Agentが専門Agentへ作業を委譲する。
Agentが別チームや別サービスに所有されている。
長時間タスクで状態、成果物、進捗更新が必要。

A2Aは「Agentが別のAgentへタスクを委譲する」境界に強いです。MCPを置き換えるものではなく、A2A Agentの内部でMCPを使ってツールを呼ぶこともあります。

オーケストレーターAgent
  -> A2Aタスク要求
  -> 専門Agent
  -> 状態更新と成果物

ACP：相互運用可能なAgentサービス

ACPは、Agent Communication Protocolとして語られることが多く、Agentを発見可能で相互運用可能なサービスとして扱う発想です。実装やエコシステムは異なる場合がありますが、Agentの能力を予測可能な形で公開するという目的は共通しています。

ACP風の方式が向く場面：

Agentをネットワークサービスのように呼びたい。
能力発見が重要。
異なるランタイムやベンダーをまたいで相互運用したい。
プロセス内ライブラリではなくサービス境界が必要。

ACPとA2Aは概念的に重なることがあります。実際には、メッセージ形式、認証、タスクライフサイクル、ストリーミング、SDK成熟度、ガバナンスを具体的に評価してください。

AG-UI：AgentからUIへのイベント

AG-UIはフロントエンド境界に焦点を当てます。Agentバックエンドがメッセージ、ツール呼び出し、状態変化、進捗、UI関連イベントをクライアントへストリームする方法を標準化します。

AG-UIが向く場面：

copilotやassistant UIを作る。
フロントエンドがツール呼び出し、中間ステップ、進捗を表示する。
ユーザーがUI上で操作を承認する。
Agent状態をReact、VueなどのUIフレームワークと同期する。

AG-UIは「AgentバックエンドがUIと通信する」境界に強いです。Agent内部のワークフローやツールホスティングを定義するものではありません。

Agentバックエンド
  -> イベントストリーム
  -> フロントエンドUI
  -> ユーザー承認 / 入力
  -> バックエンドが再開

組み合わせ方

これらのプロトコルは補完関係になることが多いです。

ユーザーインターフェース
  <-> AG-UIイベント
Agentアプリ / オーケストレーター
  <-> A2AまたはACPでAgent協調
専門Agent
  <-> MCPでツール、リソース、promptを利用
業務システム

サポート自動化では、AG-UIで進捗と確認を表示し、A2Aで返金レビューを財務Agentへ委譲し、MCPで注文、決済、チケットツールを呼ぶ構成が考えられます。

開発アシスタントでは、AG-UIでエディタUIイベントを扱い、MCPでリポジトリ、ターミナル、Issue、ドキュメントツールを接続し、外部専門Agentへ委譲する場合だけA2AやACPを使います。

比較表

観点	MCP	A2A	ACP	AG-UI
主な境界	Agentからツール/コンテキスト	AgentからAgent	Agentサービス相互運用	AgentからUI
主な対象	Tool、Resource、Prompt	Task、Message、Artifact	Capability、Agent、Message	Event、State、Tool action
向いている用途	ツール統合	委譲と協調	サービス契約	対話型フロントエンド
アプリロジックを置換するか	しない	しない	しない	しない
組み合わせ可能か	可能	可能	可能	可能
主なリスク	ツール権限が広すぎる	委譲が無制限になる	実装が分化・未成熟	UI状態や秘密情報の漏えい

選び方

AIアプリをツールやデータに接続することが主問題ならMCP。

Agentが別Agentへタスクを委譲し、状態や成果物が重要ならA2A。

Agentをサービスとして公開し、能力発見と相互運用が中心ならACP風の方式。

対話型Agent UIを作り、進捗、承認、中間ステップを表示したいならAG-UI。

よくある失敗

プロトコルをフレームワークだと思う

プロトコルは通信境界を定義します。オーケストレーション、評価、セキュリティ、デプロイ、プロダクト設計を置き換えるものではありません。

単純なツール呼び出しにマルチAgentプロトコルを使う

データベース検索やAPI呼び出しだけなら、MCP型のツール統合で十分な場合があります。

強すぎるツールを公開する

ツールサーバーは狭い操作を公開すべきです。十分に制御された環境でない限り、任意SQLや任意shell実行を公開しないでください。

Agent出力を検証しない

Agent間通信でも検証は必要です。成果物は直接信頼せず、schemaや業務ルールで確認します。

UIイベントを権限として扱う

フロントエンドの承認イベントは操作シグナルであり、セキュリティ制御そのものではありません。権限はバックエンドで強制します。

本番チェックリスト

領域	確認すること
認証	誰がエンドポイントを呼べるか
認可	どのツール、Agent、タスク、UI操作が許可されるか
監査	誰が何を要求し、何が起きたか再現できるか
タイムアウト	Agentやツールが止まった場合どうするか
予算	モデル呼び出し、ツール呼び出し、タスク深度を制限できるか
検証	入力と出力をschemaで確認しているか
可観測性	UI、Agent、ツール、タスク境界のtraceがつながるか
バージョン管理	schema変更でクライアントを壊さないか

まとめ

MCP、A2A、ACP、AG-UIは境界プロトコルとして理解すると分かりやすくなります。MCPはツールとコンテキスト、A2AはAgent間タスク協調、ACP風の方式はAgentサービス相互運用、AG-UIは対話型フロントエンドイベントを標準化します。成熟したAgentシステムでは複数を組み合わせることもありますが、それぞれは境界をより明確で安全にできる場所にだけ導入すべきです。