- MCP、A2A、UCP、AP2、A2UI、AG-UI など 6種類のAIエージェント・プロトコルを、1つのレストラン向けサプライチェーン・エージェントのシナリオにまとめ、各プロトコルが解決する課題を実践的なコードとともに段階的に説明するガイド
- Google の Agent Development Kit(ADK) を活用し、空の LLM から始めてプロトコルを1つずつ追加しながら、在庫確認・見積もり・発注・決済・ダッシュボード描画まで完成させる構成
- MCP はツール/データ接続、A2A はエージェント間通信、UCP は商取引の標準化、AP2 は決済認可、A2UI は UI 構成、AG-UI はストリーミング伝送をそれぞれ担当
- 各プロトコルは よく知られた URL ベースのディスカバリー、型付きスキーマ、標準イベントストリーム などの共通パターンを共有し、エコシステムの互換性を確保
- 初日から6つすべてを導入する必要はなく、必要に応じて段階的に追加するアプローチを推奨
MCP(Model Context Protocol) — ツール・データ接続
- エージェントをシステムやデータに接続する際に生じる最初の障壁を解決するプロトコルで、各 API ごとに カスタム統合コードを書く手作業をなくす
- MCP サーバーが自身のツールを advertise すると、エージェントが自動でディスカバリーする仕組みで、数百のサーバーに対して 単一の標準接続パターン を提供
- MCP サーバーはそのシステムを作ったチームが保守するため、エージェント側で 統合コードを書いたり更新したりする必要なく 常に最新のツール定義を取得できる
- ADK では McpToolset を通じて第一級のサポートがあり、例では PostgreSQL データベース照会(MCP Toolbox for Databases)、Notion MCP によるレシピ参照、Mailgun MCP によるサプライヤー向けメール送信を実装
ToolboxToolset で在庫 DB に接続
McpToolset で Notion、Mailgun など外部サービスに接続
- 別途コードを書くことなく
npx コマンドで MCP サーバーを起動し、エージェントにすぐ接続できる簡潔なパターン
A2A(Agent2Agent Protocol) — エージェント間通信
- MCP がデータアクセスを解決したあとに残る 専門性(expertise)の問題 を扱うプロトコルで、異なるチーム・フレームワーク・サーバーで運用されるリモートエージェント間の 標準ディスカバリー・通信方法 を提供
- 各 A2A エージェントは
/.well-known/agent-card.json に Agent Card を公開して名前・能力・エンドポイントを示し、キッチンマネージャー・エージェントがこれを取得して実行時に適切なエージェントへクエリをルーティング
- 新しいリモートエージェントを追加する際は URL を追加するだけ でよく、手動のコード変更や再デプロイは不要
- ADK の
RemoteA2aAgent は1ターンにつき1つのリモートエージェントにルーティングし、複数のリモートエージェントへの同時クエリ が必要な場合は a2a-sdk を直接利用
to_a2a() 関数で すべての ADK エージェントを A2A サービスへ変換 可能
- 価格確認、品質等級、配送ウィンドウなどの生データが API として公開されていなくても、エージェント型インターフェースを通じてアクセス可能
UCP(Universal Commerce Protocol) — 商取引の標準化
- サプライヤーごとに異なる API を持つ 発注プロセスを統合 するプロトコルで、ショッピングのライフサイクルをモジュール型機能として標準化
- 強い型付けのリクエスト/レスポンススキーマ により一貫性を保ち、下位の伝送レイヤーが REST、MCP、A2A、EP(ブラウザベースの埋め込みプロトコル)のいずれでも同じパターンで動作
- A2A と同じ
/.well-known/ucp URL パターンでサプライヤーのカタログをディスカバリー可能
- 独自 SDK は不要 で、既存の HTTP クライアントから標準 REST API にそのまま連携可能
- 例では
CheckoutCreateRequest でサーモン10ポンドとオリーブオイル3本を発注し、PaymentCreateRequest で決済リクエストを構成
- UCP サンプルリポジトリには ADK と A2A を組み合わせた AI ベースのショッピングアシスタント の例が含まれる
AP2(Agent Payments Protocol) — 決済認可・監査証跡
- UCP が注文対象とサプライヤーを扱うなら、AP2 は 誰が購入を承認したかと監査証跡 を担当
- 型付き mandate により意図の否認防止証拠(non-repudiatable proof of intent)を提供し、すべての取引に 設定可能なガードレール を適用
- 全体フロー:
IntentMandate → PaymentMandate(署名済み) → PaymentReceipt
- IntentMandate: 許可加盟店、支出上限、自動承認の可否、返金可能性の要件、有効期限などのガードレールを設定
- PaymentMandate: 特定のカートと金額に紐づく決済委任状で、上限超過時には管理者の明示的承認があるまで未署名のまま維持
- PaymentReceipt: 監査証跡を完結させるレシート
- UCP の拡張(extension)として動作し、チェックアウトフローに 暗号化された認可証明 を追加
- 現在は v0.1 段階で、ADK コアには組み込まれておらず別パッケージとして型を提供
A2UI(Agent-to-User Interface Protocol) — 動的 UI 構成
- エージェントが通常のテキストの代わりに ダッシュボード、注文フォーム、サプライヤー比較表 などを動的に構成できるようにするプロトコル
- 18種類の安全なコンポーネント・プリミティブ(行、列、テキストフィールドなど)から成る固定カタログ上で、宣言的な JSON 形式により新しいレイアウトの組み合わせを表現
- UI 構造とデータを 分離 し、コンポーネントを再送せずデータだけ更新可能
- コンポーネントは ID で相互参照する フラットリスト として送信
- データは別の
dataModelUpdate で送信
- クライアント側レンダラーが JSON を Lit、Flutter、Angular などのネイティブ UI に変換
- 同じエージェントでも同じ18個のプリミティブを用いて、在庫チェックリスト、注文フォーム、サプライヤー比較など まったく異なるインターフェース を生成可能
- ADK Web インターフェース(
adk web)では A2UI コンポーネントをネイティブにレンダリング できるため、開発中に別個のレンダラーを構築する必要がない
- A2UI Widget Builder によりレイアウトをインタラクティブに組み合わせ可能
AG-UI(Agent-User Interaction Protocol) — ストリーミング伝送
- エージェントは従来の REST API と異なり、テキストを段階的にストリーミングし、応答の途中でツールを呼び出し、人の入力を待って一時停止するなど 複雑な相互作用パターン を持つ
- AG-UI は ミドルウェアとして動作 し、フレームワークごとの生イベントを標準化された SSE ストリームへ変換
- フロントエンドは
TEXT_MESSAGE_CONTENT、TOOL_CALL_START などの 型付きイベント だけを受け取ればよく、どのエージェントフレームワークが生成したかを知る必要はない
- ADK はネイティブの
/run_sse エンドポイントを提供するが、パース処理のコードがボイラープレート化し、イベント形式の変更で壊れやすい問題を AG-UI が解決
ag_ui_adk パッケージでラップし、FastAPI アプリにマウント するだけで AG-UI ストリーミングエンドポイントを構成可能
全体の統合動作フロー
- ユーザーが「サーモンの在庫確認、今日の卸売価格・品質等級の確認、在庫不足なら Example Wholesale で10ポンド発注し決済認可まで」を依頼すると、6つのプロトコルが段階的に動作
- 第1段階 — 情報収集: MCP で在庫 DB をクエリ(
check_inventory) → A2A でリモートの価格・品質エージェントにクエリ(ask_agent)
- 第2段階 — 取引完了: UCP でチェックアウト要求(
place_order) → AP2 で設定済みガードレール内の決済 mandate を取得(authorize_payment)
- 第3段階 — 結果表示: A2UI でインタラクティブなウィジェットを構成 → AG-UI でツール呼び出しとテキスト応答をリアルタイムにストリーミング
プロトコル活用のヒント
- 各プロトコルが解決する問題を正確に把握 することで、アーキテクチャをすっきり保てる
- 初日から6つすべてが必要なわけではなく、多くの場合は MCP から開始 し、マルチエージェント通信、商取引、決済、リッチ UI、ストリーミングなど要件の増加に応じて段階的に追加
- プロトコルで構築する前に ADK 統合、公式 SDK、サンプルコード を先に確認し、自前で再実装しないようにすること
- プロトコルはまだ成熟途上だが、よく知られた URL ディスカバリー・型付きスキーマ・標準イベントストリームといったパターンを 早期に採用することで、ツール・サービス・エージェントのエコシステムとの互換性を確保できる
1件のコメント
こうしてまとめてみると、AI関連のプロトコルはものすごく多いですね