AIエージェントについて調べていると、MCP、A2A、UCP、AP2、A2UI、AG-UIなど、似たような略語が次々に出てきます。
「結局どれを使えばいいの？」
「全部覚えないとダメなの？」
「同じような規格が乱立しているだけじゃないの？」
このように感じる人も多いでしょう。
結論からお伝えすると、AIエージェントのプロトコルは、どれが一番優れているかで選ぶものではありません。
大切なのは、AIエージェントが何に困っているのかを見ることです。
Google Developers Blogの「Developer’s Guide to AI Agent Protocols」では、AIエージェント関連のプロトコルを、レストランの仕入れ業務を行うAIエージェントの例で整理しています。
この記事では、その内容をもとに、初級者の方にもわかりやすく、
-
MCP
-
A2A
-
UCP
-
AP2
-
A2UI
-
AG-UI
の役割や使い分けを紹介します。
AIエージェント開発で「どのプロトコルを、どこで使えばいいのか」と悩んでいる方は、ぜひ参考にしてみてください。
AIプロトコルが増えすぎて混乱する理由
AIエージェントの世界では、ここ最近さまざまなプロトコルが登場しています。
MCP、A2A、UCP、AP2、A2UI、AG-UI……。
名前だけを見ると、かなりややこしく感じますよね。
ただ、これらはすべて同じ役割を持っているわけではありません。
それぞれが、AIエージェント開発で発生する別々の問題を解決するために用意されています。
Googleの記事でも、次のような趣旨の説明があります。
“Six protocols, each solving a different problem, all working through a single agent.”
つまり、6つのプロトコルはそれぞれ違う問題を解決しながら、1つのAIエージェントの中で連携するということです。
ここを理解すると、一気に整理しやすくなります。
AIプロトコルは、「どれが最強か」を比べるものではありません。
エージェントが今どこで詰まっているのかを見て、必要なものを選ぶための道具です。
AIエージェント開発でプロトコルが必要になる場面
なぜ普通のLLMだけでは足りないのか
LLMは、文章を作ったり、質問に答えたりするのが得意です。
ただし、実務で使えるAIエージェントにするには、それだけでは足りません。
たとえば、レストランのキッチン管理エージェントを考えてみましょう。
このエージェントに、
「サーモンの在庫を確認して、少なければ仕入れ先に注文して、支払いまで進めて」
と依頼したとします。
この場合、AIが文章で「在庫を確認しましょう」と返すだけでは意味がありません。
実際には、次のような処理が必要になります。
-
在庫データベースを確認する
-
仕入れ先の価格を調べる
-
品質情報を確認する
-
注文処理を行う
-
支払い承認を取る
-
結果を画面に表示する
-
進捗をリアルタイムで見せる
つまり、AIエージェントは「考える」だけでなく、外部システムにつながり、他のエージェントと連携し、実際の業務を進める存在になります。
そのときに必要になるのが、各種プロトコルです。
プロトコルは役割ごとに分かれている
Googleの記事で紹介されている6つのプロトコルは、それぞれ担当する領域が違います。
ざっくり整理すると、以下のようになります。
-
MCP：データや外部ツールにつなぐ
-
A2A：エージェント同士をつなぐ
-
UCP：購入や注文の流れを扱う
-
AP2：支払いの承認や証跡を扱う
-
A2UI：画面UIを組み立てる
-
AG-UI：進捗や応答をリアルタイムに届ける
このように、役割が分かれています。
ですので、MCPとA2Aを比べて「どっちが良いか」と考える必要はありません。
社内データにつなぎたいならMCP。
別のAIエージェントと連携したいならA2A。
このように、目的から逆算して選ぶのが一番わかりやすいです。
MCP：エージェントを社内データや外部ツールにつなぐ
MCPは何を解決するのか
MCPは、Model Context Protocolの略です。
初級者向けに言うと、AIエージェントがデータベースや業務ツール、外部APIなどに接続するための共通ルールです。
たとえば、キッチン管理エージェントが次のような操作をするとします。
-
在庫データベースを確認する
-
Notionにあるレシピを読む
-
Mailgunを使って仕入れ先にメールを送る
-
社内システムから商品情報を取得する
このような処理を、毎回バラバラの方法で実装するのは大変です。
APIごとに接続方法が違えば、そのたびにカスタム連携コードを書かなければいけません。
そこで役立つのがMCPです。
MCPは、AIエージェントに外部ツールを使わせるための接続口だと考えるとわかりやすいでしょう。
MCPはどこで使うべきか
MCPは、AIエージェントに「自社の情報」や「既存ツール」を使わせたいときに検討するプロトコルです。
たとえば、次のようなケースです。
-
社内データベースを検索させたい
-
Google DriveやNotionの情報を参照させたい
-
Slackの会話を確認させたい
-
CRMや在庫管理システムと連携させたい
-
メール送信やチケット作成をさせたい
AIエージェントに外部データを見せたり、業務ツールを操作させたりしたいなら、まずMCPを考えましょう。
逆に、単にチャットで質問に答えるだけならMCPは不要です。
エージェントが現実のデータやツールに触れ始めたとき、MCPの出番になります。
初級者向けの判断基準
MCPを使うかどうかは、次のように判断するとわかりやすいです。
AIに何かを「調べに行かせたい」「操作させたい」ならMCPです。
たとえば、
-
在庫を確認してほしい
-
顧客情報を見てほしい
-
社内資料から答えを探してほしい
-
メールを送ってほしい
-
タスクを作成してほしい
このような要望があるなら、MCPが候補になります。
初級者の方は、MCPを「AIに道具を持たせるための仕組み」と覚えておくと良いでしょう。
A2A：エージェント同士を連携させる
A2Aは何を解決するのか
A2Aは、Agent2Agent Protocolの略です。
これは、AIエージェント同士が、お互いを見つけ、能力を理解し、メッセージをやり取りするためのプロトコルです。
Googleの記事では、各A2Aエージェントが「Agent Card」を公開する仕組みが紹介されています。
Agent Cardには、エージェントの名前や能力、接続先などが記述されます。
これにより、あるエージェントが別の専門エージェントを見つけて、必要な仕事を依頼できるようになります。
つまりA2Aは、AIエージェント同士の紹介状や名刺のような役割を持っていると言えます。
A2Aはどこで使うべきか
A2Aは、1つのAIエージェントだけでは完結しない業務で使います。
たとえば、レストランの仕入れ業務を考えてみましょう。
キッチン管理エージェントは、在庫の確認はできるかもしれません。
しかし、次のような情報までは自分で持っていない可能性があります。
-
今日の卸売価格
-
食材の品質グレード
-
配送可能時間
-
仕入れ先ごとの条件
-
代替商品の候補
この場合、価格確認エージェント、品質評価エージェント、配送確認エージェントなどに問い合わせる必要があります。
このように、専門分野ごとのエージェントを組み合わせたい場合にA2Aが役立ちます。
MCPとの違い
MCPとA2Aは、混同されやすいポイントです。
ただ、違いはかなりシンプルです。
MCPは、エージェントとツール・データをつなぐもの。
A2Aは、エージェントとエージェントをつなぐもの。
この違いを押さえるだけで、かなり整理しやすくなります。
たとえば、社内データベースやAPIにつなぐならMCPです。
一方で、別のAIエージェントに仕事を依頼するならA2Aです。
初級者向けの判断基準
A2Aを使うべきか迷ったら、次のように考えてください。
「別の専門AIにお願いしたい仕事があるか」
あるならA2Aの出番です。
たとえば、
-
価格調査専門のAIに聞きたい
-
法務チェック専門のAIに確認したい
-
在庫管理AIと配送管理AIをつなぎたい
-
複数のAIに役割分担させたい
このようなケースでは、A2Aが役立ちます。
AIエージェントが1人で全部やるのではなく、チームで仕事をする段階になったらA2Aと考えるとわかりやすいです。
UCP：買い物や注文の流れを標準化する
UCPは何を解決するのか
UCPは、Universal Commerce Protocolの略です。
これは、商品検索、カート、チェックアウト、注文といった商取引の流れを標準化するためのプロトコルです。
Googleの記事では、複数の卸売業者から食材を仕入れる場面が例として紹介されています。
仕入れ先ごとにAPIや注文フローが違うと、開発者はそれぞれに合わせて処理を書かなければいけません。
ある業者ではカートを作成してから注文する。
別の業者では見積もりを取得してから発注する。
さらに別の業者では独自のチェックアウト手順がある。
このように、購入や注文の流れがバラバラだと、開発はかなり複雑になります。
UCPは、この買い物や注文の流れを共通の型で扱えるようにするものです。
初級者向けに言えば、UCPはAIが買い物や注文をするときの共通レジのようなものです。
UCPはどこで使うべきか
UCPは、AIエージェントに「購入」「予約」「注文」「チェックアウト」のような商取引をさせたいときに使います。
たとえば、次のようなケースです。
-
AIが商品を探して注文する
-
複数のECサイトや販売業者を比較する
-
仕入れ業務を自動化する
-
カート作成やチェックアウトをAIに任せる
-
注文フローを共通化したい
単に情報を取得するだけなら、MCPで足りる場合もあります。
しかし、そこから一歩進んで、AIが購入や注文の流れに入るならUCPが候補になります。
A2AやMCPとの関係
UCPは、MCPやA2Aと競合するものではありません。
むしろ、組み合わせて使うことがあります。
たとえば、仕入れ先の情報を見つけるためにA2Aを使い、実際の注文処理にUCPを使うことができます。
また、システムとの接続部分にMCPを使いながら、商取引の流れだけUCPで標準化することも考えられます。
つまり、UCPは商取引という特定の業務領域に強いプロトコルです。
初級者向けの判断基準
UCPを使うかどうかは、次のように判断しましょう。
AIに注文や購入まで任せたいならUCPです。
たとえば、
-
商品を選ばせるだけでなく注文まで進めたい
-
カートやチェックアウトの流れを扱いたい
-
複数の販売業者を横断して仕入れたい
-
ECや予約の処理をAIに組み込みたい
このような場合は、UCPを検討する価値があります。
AP2：AIによる支払いに承認と証跡を加える
AP2は何を解決するのか
AP2は、Agent Payments Protocolの略です。
これは、AIエージェントが支払いを行うときに、承認や証跡を管理するためのプロトコルです。
AIが注文や購入を行う場合、必ず問題になるのが「支払い」です。
たとえば、AIが勝手に高額な注文をしてしまったら困りますよね。
そのため、次のような情報を明確にする必要があります。
-
誰が支払いを承認したのか
-
どの条件で支払いが許可されたのか
-
何に対して支払ったのか
-
いくら支払ったのか
-
支払いの証跡が残っているのか
AP2は、こうした支払いまわりの信頼性を担保するためのものです。
Googleの記事では、UCPが「何を注文するか」「誰から注文するか」を扱うのに対し、AP2は「誰がその支払いを承認したのか」「どのような監査証跡が残るのか」を扱うと説明されています。
AP2はどこで使うべきか
AP2は、AIエージェントにお金を扱わせる場合に重要になります。
たとえば、次のようなケースです。
-
AIが自動で仕入れを行う
-
一定金額以下なら自動承認したい
-
高額注文は人間の承認を必須にしたい
-
どの支払いが、どの意図に基づいて行われたか記録したい
-
監査やコンプライアンスに対応したい
AIエージェントが注文まで行うだけなら、UCPが中心になります。
しかし、支払いの承認・制限・記録まで考えるならAP2が必要です。
UCPとの違い
UCPとAP2も、混同されやすいポイントです。
違いは次の通りです。
UCPは、注文や購入の流れを扱います。
AP2は、支払いの承認と証跡を扱います。
この2つは、セットで使われることも多いでしょう。
イメージとしては、
-
UCPで注文する
-
AP2で支払いの正当性を担保する
という流れです。
注文と支払いは近い領域ですが、役割は別です。
ここを分けて考えると、かなり理解しやすくなります。
初級者向けの判断基準
AP2を使うかどうかは、次の質問で判断できます。
AIにお金を動かさせるのか？
答えが「はい」なら、AP2を検討する必要があります。
特に、会社や事業でAIエージェントを使う場合、支払いの承認や証跡はとても重要です。
「AIがやりました」だけでは済まない場面もあります。
お金が絡むなら、AP2。
このくらいシンプルに覚えておくと良いでしょう。
A2UI：エージェントが画面UIを組み立てる
A2UIは何を解決するのか
A2UIは、Agent-to-User Interface Protocolの略です。
これは、AIエージェントがユーザーに見せる画面を、宣言的なJSON形式で構成するためのプロトコルです。
少し難しく聞こえるかもしれません。
初級者向けに言うと、A2UIはAIが画面の設計図を作るためのルールです。
AIエージェントの出力は、テキストだけとは限りません。
たとえば、次のような画面を出したいことがあります。
-
在庫ダッシュボード
-
注文フォーム
-
仕入れ先の比較画面
-
確認用のカード表示
-
チェックリスト形式の画面
こうした画面を毎回フロントエンド側で個別に作るのは大変です。
そこでA2UIを使うことで、エージェントが必要に応じて画面構造を組み立てられるようになります。
A2UIはどこで使うべきか
A2UIは、AIエージェントの出力を単なるテキストではなく、画面として見せたいときに使います。
たとえば、次のようなケースです。
-
在庫一覧をチェックリストで表示したい
-
注文内容をフォームで確認させたい
-
仕入れ先をカード形式で比較したい
-
ダッシュボードを自動生成したい
-
ユーザーがクリックや入力で操作できる画面を出したい
チャットだけで完結するなら、A2UIは必須ではありません。
しかし、AIエージェントが業務画面の中で動くようになると、テキストだけでは不十分になります。
ユーザーが見て、選んで、確認して、操作する画面が必要になるならA2UIの出番です。
AG-UIとの違い
A2UIとAG-UIは、どちらもUIまわりのプロトコルです。
ただし、役割は違います。
A2UIは、何を画面に表示するかを扱います。
AG-UIは、エージェントの動きや応答をリアルタイムに届けることを扱います。
つまり、
-
画面の部品やレイアウトならA2UI
-
進捗やイベントのリアルタイム表示ならAG-UI
という違いです。
初級者向けの判断基準
A2UIを使うかどうかは、次のように考えるとわかりやすいです。
AIに画面を作らせたいならA2UIです。
たとえば、
-
AIにフォームを出させたい
-
比較カードを表示させたい
-
操作できる画面を自動生成したい
-
ダッシュボードを柔軟に表示したい
このような場合は、A2UIを検討しましょう。
AG-UI：エージェントの応答をリアルタイムに表示する
AG-UIは何を解決するのか
AG-UIは、Agent-User Interaction Protocolの略です。
これは、AIエージェントとユーザーインターフェースの間で、途中経過や応答をリアルタイムにやり取りするためのプロトコルです。
通常のREST APIでは、リクエストを送ってレスポンスを受け取れば終わりです。
しかし、AIエージェントはそう単純ではありません。
処理の途中で、次のようなことが起こります。
-
ツールを呼び出す
-
少しずつ文章を生成する
-
外部データを確認する
-
ユーザーの承認を待つ
-
処理状況を更新する
-
結果を段階的に表示する
このような複雑なイベントを、フロントエンド側で扱いやすくするためにAG-UIが使われます。
Googleの記事では、AG-UIがこうした複雑なイベントを標準化されたSSEストリームとして扱い、フロントエンド側が特定のエージェントフレームワークに依存しなくて済むようにするものとして説明されています。
AG-UIはどこで使うべきか
AG-UIは、AIエージェントの処理状況をユーザーにリアルタイムで見せたい場合に使います。
たとえば、次のようなケースです。
-
「在庫を確認中」と表示したい
-
「価格を取得中」と進捗を出したい
-
「注文を作成中」と知らせたい
-
ツール呼び出しの開始・終了を画面に出したい
-
文章生成をストリーミング表示したい
-
ユーザーの確認待ちをUI上で扱いたい
AIエージェントは、処理に時間がかかることがあります。
その間、画面が止まったように見えると、ユーザーは不安になります。
そこでAG-UIを使うことで、今AIが何をしているのかをリアルタイムに伝えられるようになります。
初級者向けの判断基準
AG-UIを使うかどうかは、次のように判断しましょう。
AIの動きをリアルタイムに見せたいならAG-UIです。
たとえば、
-
途中経過を表示したい
-
ストリーミングで文章を出したい
-
ツール実行状況を見せたい
-
ユーザー承認を画面上で扱いたい
-
フロントエンドとエージェントを安定して接続したい
このような場合、AG-UIが役立ちます。
初級者向けに言えば、AG-UIはAIエージェントの動きを画面にリアルタイム中継するためのルールです。
6つのプロトコルをどう使い分ければよいか
まずは名前ではなく課題から考える
AIプロトコルを理解するコツは、名前から覚えようとしないことです。
MCP、A2A、UCP、AP2、A2UI、AG-UI……。
この略語をいきなり全部暗記しようとすると、かなり混乱します。
まず見るべきなのは、自分のAIエージェントが何に困っているのかです。
たとえば、次のように考えると整理しやすくなります。
-
データやツールにつなぎたい → MCP
-
他のエージェントと連携したい → A2A
-
注文や購入を扱いたい → UCP
-
支払いの承認や証跡が必要 → AP2
-
画面UIをエージェントに組み立てさせたい → A2UI
-
リアルタイムな進捗やイベントを流したい → AG-UI
このように、目的で分けるとかなりシンプルです。
最初から全部使う必要はない
初級者が一番気をつけたいのは、最初から6つすべてを使おうとしないことです。
Googleの記事でも、最初からすべてを導入する必要はないという考え方が示されています。
多くのAIエージェントは、まずMCPでデータアクセスから始まります。
その後、要件が増えるにつれて、A2A、UCP、AP2、A2UI、AG-UIを追加していく流れになります。
たとえば、最初は社内データを読むだけならMCPで十分かもしれません。
その後、他の専門エージェントと連携したくなればA2Aを追加します。
注文や購入まで進めたいならUCP。
支払い管理が必要ならAP2。
画面を柔軟に出したいならA2UI。
進捗をリアルタイムに見せたいならAG-UI。
このように、必要になった段階で追加していけば問題ありません。
プロトコルは全部入りセットではなく、必要なものを選ぶ部品です。
レストラン仕入れエージェントで見る全体像
Googleの記事の例をもとにすると、6つのプロトコルは次のように連携します。
まず、キッチン管理エージェントがMCPを使って在庫データベースを確認します。
そこで、サーモンの在庫が少ないとわかります。
次に、A2Aを使って、価格エージェントや品質エージェントに問い合わせます。
どの仕入れ先が安いのか。
品質は問題ないのか。
配送は間に合うのか。
こうした情報を、専門エージェントから集めます。
注文する必要があれば、UCPで仕入れ先にチェックアウトリクエストを送ります。
支払いが発生するため、AP2で承認条件や支払い証跡を管理します。
その結果をユーザーに見せるために、A2UIでダッシュボードや確認画面を構成します。
そして、処理の進行状況や応答をAG-UIでリアルタイムにフロントエンドへ届けます。
この流れを見ると、それぞれのプロトコルがバラバラに存在しているわけではないことがわかります。
AIエージェントの業務フローの中で、それぞれ担当箇所が分かれているのです。
AIプロトコルの使い分け早見表
ここまでの内容を、初級者向けに整理します。
| 困っていること | 使うプロトコル | 役割 |
|---|---|---|
| 外部データやツールにつなぎたい | MCP | AIに道具を持たせる |
| 別のAIエージェントに仕事を頼みたい | A2A | エージェント同士をつなぐ |
| 注文や購入の流れを扱いたい | UCP | 商取引の流れを標準化する |
| 支払いの承認や証跡を残したい | AP2 | お金まわりの信頼性を担保する |
| AIに画面UIを作らせたい | A2UI | 画面の設計図を作る |
| 進捗や応答をリアルタイムに見せたい | AG-UI | AIの動きを中継する |
まずは、この表だけ押さえておけば大丈夫です。
細かい仕様を覚える前に、どのプロトコルがどの悩みに対応するのかを理解しておきましょう。
初級者が最初に覚えるべき順番
初級者が学ぶなら、最初はMCPから入るのがおすすめです。
なぜなら、多くのAIエージェントは、最初に「外部データやツールにつなぐ」必要が出てくるからです。
社内資料を読む。
データベースを確認する。
NotionやSlackの情報を見る。
メールを送る。
チケットを作成する。
こうした処理は、AIエージェント開発の入り口になりやすいです。
そのため、まずはMCPを理解しましょう。
その後、必要に応じて以下の順番で見ていくと整理しやすいです。
-
MCP：外部データやツールにつなぐ
-
A2A：他のAIエージェントと連携する
-
UCP：注文や購入を扱う
-
AP2：支払いの承認や証跡を扱う
-
A2UI：画面UIを構成する
-
AG-UI：リアルタイムに進捗を表示する
もちろん、すべてを一気に覚える必要はありません。
今の自分に必要なものから順番に理解していけば十分です。
よくある質問
Q1. 初心者はまずどのプロトコルから学べばいいですか？
まずはMCPから学ぶのがおすすめです。
多くのAIエージェントは、最初に外部データやツールとつながる必要が出てきます。
社内データベース、Notion、メール、業務システムなどと連携する場面が多いため、MCPは最初の学習対象として実用性が高いです。
Q2. MCPとA2Aの違いは何ですか？
MCPは、AIエージェントとツール・データをつなぐためのプロトコルです。
一方、A2Aは、AIエージェント同士をつなぐためのプロトコルです。
データベースやAPIにアクセスするならMCP。
別の専門エージェントに仕事を依頼するならA2A。
このように考えるとわかりやすいです。
Q3. UCPとAP2は必ずセットで使う必要がありますか？
必ずセットで使う必要はありません。
ただし、AIエージェントが注文だけでなく支払いまで行う場合は、UCPとAP2を組み合わせる考え方が自然です。
UCPは注文やチェックアウトの流れを扱います。
AP2は支払いの承認や証跡を扱います。
Q4. A2UIとAG-UIはどちらも画面まわりのプロトコルですか？
どちらもユーザーインターフェースに関係しますが、役割は違います。
A2UIは、エージェントがどのような画面部品やレイアウトを表示するかを扱います。
AG-UIは、エージェントの処理状況、ツール呼び出し、文章生成などをリアルタイムにフロントエンドへ届けるためのものです。
Q5. 6つのプロトコルをすべて導入しないとAIエージェントは作れませんか？
すべて導入する必要はありません。
最初はMCPだけでも十分なケースがあります。
要件が増えて、他のエージェント連携が必要になればA2A。
商取引が必要になればUCP。
支払い管理が必要になればAP2。
リッチなUIが必要になればA2UI。
リアルタイム表示が必要になればAG-UI。
このように、必要に応じて追加していけば問題ありません。
AIエージェントのプロトコルの使い分けについてまとめ
AIエージェント関連のプロトコルは、名前だけを見るとかなり複雑に感じます。
しかし、実際にはそれぞれが異なる課題を解決するために用意されています。
改めて整理すると、次の通りです。
-
MCPは、エージェントをツールやデータにつなぐためのもの
-
A2Aは、エージェント同士を連携させるためのもの
-
UCPは、注文や購入といった商取引を標準化するためのもの
-
AP2は、支払いに承認と監査証跡を加えるためのもの
-
A2UIは、エージェントが画面UIを構成するためのもの
-
AG-UIは、エージェントの動きや応答をリアルタイムに届けるためのもの
初級者が最初に意識すべきことは、「どのプロトコルが流行っているか」ではありません。
自分のAIエージェントが、今どこで困っているのかです。
外部データにアクセスできないならMCP。
他の専門エージェントと連携したいならA2A。
注文処理が必要ならUCP。
支払い承認が必要ならAP2。
画面を柔軟に出したいならA2UI。
リアルタイム表示が必要ならAG-UI。
この順番で考えれば、乱立して見えるAIプロトコルも、かなり実務的に整理できます。
最初から全部覚える必要はありません。
まずは、「AIに何をさせたいのか」から逆算して、必要なプロトコルを選ぶことが大切です。
参考リンク
Google Developers Blog：Developer’s Guide to AI Agent Protocols
