A2UI プロトコル入門 ── MCP・A2A を補完しユーザー体験を変える生成 UI の仕組み

本記事では、Google が策定を進める A2UI (Agent-to-User Interface Protocol) の位置付けと仕組みを整理します。

A2UI が登場した背景、MCP・A2A との補完関係、v0.9 時点のプロトコル構造と採用状況、そして実際に検討する際に確認しておくべき成熟度上の注意点を順に取り上げます。

ユーザーとエージェントの対話面を担うレイヤーとして A2UI を捉えることで、マルチエージェント設計においてユーザー体験をどう変えられるかを判断しましょう。

A2UI の立ち位置 ── MCP・A2A を補完しユーザー体験を形作るレイヤー

マルチエージェントシステムは、「ツールを呼び出す」「別のエージェントに委任する」「ユーザーに何をどう見せるか」という異なる役割を、それぞれ別のプロトコルが分担することで成り立ちます。

Google は 2026 年 3 月に公開した Developer Guide で、3 つのプロトコルが互いに補完しあう関係にあることを整理しています。

MCP (Model Context Protocol) はツールとデータへの接続を担います。A2A (Agent-to-Agent Protocol) はエージェント同士の通信を担います。そして A2UI は、エージェントが生成した UI をユーザーに届けるレイヤーを担います。

A2UI の公式定義は「agents to generate or populate rich user interfaces」(エージェントがリッチな UI を生成・埋め込む) とされています。

Apache 2.0 ライセンスで公開されており、リポジトリは github.com/google/A2UI で参照できます (2026 年 5 月時点で 14,500 以上のスターを獲得)。

MCP と A2A が先行して広まっていた中で、A2UI は 2026 年に入ってから本格的に姿を現しました。ツール接続とエージェント間通信の仕組みはすでに確立されていましたが、エージェントが生成した UI をユーザーに自然な形で届ける仕組みは欠けていました。

A2UI はこの欠けたピースを補い、エージェントが提供できるユーザー体験そのものを変えるレイヤーとして位置付けられます。テキスト対話だけでは扱いにくい操作 (フォーム入力・選択・確認) を、ホストアプリのネイティブ UI として届けられるようになります。

なお MCP には UI 関連機能 (MCP Apps) も存在しますが、A2UI とは設計アプローチが異なります (詳細は次節)。

テキストの壁と信頼境界 ── A2UI が解こうとした 2 つの問題

A2UI が生まれた背景には、既存のアプローチが抱える 2 つの課題があります。

1 つ目は「テキストの壁」です。

公式ブログでは、レストランの予約を例に挙げています。自然言語だけでやりとりすると、日時・人数・席の希望・アレルギー対応などを確認するために 7 往復前後の会話が必要になります。一方、予約フォームを 1 枚表示すれば 1 回の操作で完結します。構造化された UI は、テキストチャットでは補えない情報収集の効率をもたらします。

2 つ目は信頼境界の問題です。リモートエージェントはセキュリティ上の理由から、ユーザーのブラウザ DOM に直接アクセスできません。

これまでの典型的な回避策は、HTML や JavaScript を iframe に埋め込んで送る方法でした。しかし公式は「heavy, visually disjointed」と評しており、重くなりがちで表示が浮き立つという問題がありました。

この 2 つを解くために導き出された設計原則が、「We needed a way to transmit UI that is safe like data, but expressive like code.」という一文です。

We needed a way to transmit UI that is safe like data, but expressive like code.

出典: Google Developers Blog — Introducing A2UI

「データのように安全で、コードのように表現力がある」という方向性は、A2UI の設計全体を貫くコンセプトです。

なお、MCP の機能として存在する MCP Apps と A2UI は異なります。MCP Apps はサーバーが事前に構築した HTML を ui:// URI でリソースとして返す「リソース取得モデル」です。

これに対して A2UI は、コンポーネントの宣言をホスト側に送り、ホスト側のネイティブコンポーネントでレンダリングする「ネイティブファーストアプローチ」をとっています。公式はこの違いを “A2UI takes a ‘native-first approach’ that is distinct from the resource-fetching model of MCP Apps.” と明示しています。

「コードを送らない」という設計選択 ── 3 つの原則

A2UI の設計は意図的に「実行可能なコードを送らない」という選択によって成り立っています。この選択が、セキュリティ・LLM との親和性・フレームワーク非依存という 3 つの原則を同時に実現しています。

原則 1: セキュリティファースト

エージェントが送れるのは宣言的なデータ形式のみです。クライアント (ホストアプリ) はあらかじめ承認済みの「カタログ」を保持しており、エージェントはカタログに登録されたコンポーネントしか呼び出せません。

エージェントが任意のコードを実行する経路は存在しません。

v0.9 時点の Basic Catalog には 18 個のコンポーネントが定義されています (公式記載)。

カテゴリ別に整理すると、レイアウト系 (Row / Column / List)、表示系 (Text / Image / Icon / Divider / Video / AudioPlayer)、インタラクティブ系 (Button / TextField / CheckBox / Slider / DateTimeInput / ChoicePicker)、コンテナ系 (Card / Modal / Tabs) という構成です。

原則 2: LLM フレンドリーな構造とプログレッシブレンダリング

コンポーネントはフラットなリスト形式で表現され、各要素に ID が付与されています。隣接リストモデル (各コンポーネントに ID を付与し、親子関係を参照で表現する平坦な配列構造) を採用することで、LLM が出力しやすい構造を保ちながら、差分更新 (特定コンポーネントのみを後から変更) にも対応できます。

プログレッシブレンダリングにより、大きなフォームや複雑な画面でも段階的に描画できます。

原則 3: フレームワーク非依存と移植性

同一の A2UI JSON は、Web / Flutter / React / SwiftUI など複数のレンダリング環境で利用できます。ホスト側が対応するレンダラーを持っていれば、エージェント側は UI の実装詳細を意識する必要がありません。

これら 3 つの原則が組み合わさることで、A2UI は「コードではなく宣言として UI を伝送する」という核心的な設計選択の意味を具体化しています。

プロトコルの輪郭 ── v0.9 の 4 メッセージと JSON Lines

A2UI のメッセージはすべて JSON Lines (JSONL) 形式で記述されます。1 行 1 メッセージのストリーミングに適した形式です。

トランスポートプロトコルは特定のものに依存しません。A2A・AG-UI・MCP・WebSocket・REST のいずれの上でも動作します (AG-UI はフロントエンドとエージェントを接続するプロトコル層で、A2UI が UI ペイロード形式として乗ります)。

v0.9 仕様では 4 種類のメッセージタイプが定義されています。

データバインディングには RFC 6901 の JSON Pointer を使用します。コンポーネントのプロパティに $data 参照を記述することで、データモデルの変化を UI に反映できます。

以下は公式 Quickstart を参考にした構造例です (動作確認済みのものではありません)。

実装時は a2ui.org/quickstart の Getting Started セクションに動かせる最小構成があります。最新の仕様変更はそちらで確認してください。

{
  "type": "createSurface",
  "surfaceId": "booking-form",
  "components": [
    {
      "id": "title",
      "type": "Text",
      "props": { "content": "予約情報を入力してください" }
    },
    {
      "id": "confirm-btn",
      "type": "Button",
      "props": { "label": "予約を確定する" },
      "events": { "onTap": "submitBooking" }
    }
  ]
}

4 つのメッセージを組み合わせることで、エージェントは「Surface を作り → データを更新し → コンポーネントを差し替え → 完了後に破棄する」というライフサイクルを制御できます。

Draft の今、どこまで使えるか ── 採用事例と v0.9 の成熟度

A2UI の現在の採用状況は「一部の Google 製品と外部パートナーが先行実装している段階」です。v0.9 は Draft ステータスで、stable マイルストーンの達成に向けてオープンのイシューが残っており、仕様変更が起こりうる段階です。

Google 内での採用事例としては、Google Opal、Gemini Enterprise (Public Preview 中)、Flutter GenUI SDK、Google ADK (Agent Development Kit) が挙げられます。ただし Gemini Enterprise の Public Preview が対応しているのは v0.8 のみです (公式ドキュメントに明記)。

外部からは AG-UI と CopilotKit が day-zero 互換として対応しています。v0.9 の早期採用パートナーとしては Rebel App Studio と Very Good Ventures が公式ブログで紹介されています。

SDK の対応状況は以下の通りです。

React レンダラーは v0.9 から公式サポートが始まりました。一方、React Native レンダラーはまだリリースされていません。Go・Kotlin の SDK はリリース日が公表されていない状況です。

プロダクション導入を検討する場合、Gemini Enterprise や Google ADK を通じて v0.8 の機能を試すことはできます。

v0.9 仕様をベースに開発を進めるなら、GitHub の A2UI milestone と a2ui.org の仕様ページ を定期的に確認しながら仕様変更を追うのが現実的な進め方です。

まとめ ── 補完しあう 3 プロトコルとユーザー体験のレイヤー

MCP はツールとデータへの接続を担い、A2A はエージェント同士の通信を担います。A2UI はそれらと補完関係にあり、エージェントが生成した UI をユーザーに届けるレイヤーを担います。

A2UI が「実行可能なコードを送らず、宣言的なコンポーネント参照だけを送る」という信頼境界ファーストの設計を選択したことで、エージェントとユーザーの対話はテキスト中心から、ホストアプリのネイティブ UI を介した自然な操作へと拡張されます。これがユーザー体験の側で起きる最も大きな変化です。

マルチエージェント設計で A2UI の導入を検討するなら、まず確認する場所は 3 つです。

• コンポーネントの全体像: A2UI Component Gallery Reference
• 動かして試す: a2ui.org の Quickstart
• Google ADK との統合サンプル: google/A2UI リポジトリの samples ディレクトリ

v0.9 から stable への移行を追うなら、GitHub milestone と a2ui.org の仕様 changelog を起点にしてください。

参考文献

• Developers Guide to AI Agent Protocols (Google Developers Blog, 2026-03-18)
• Introducing A2UI: An Open Project for Agent-Driven Interfaces (Google Developers Blog)
• A2UI v0.9: Generative UI (Google Developers Blog)
• A2UI Specification v0.9 (a2ui.org)
• A2UI Quickstart (a2ui.org)
• A2UI Component Gallery Reference (Google Cloud ドキュメント)
• Register and Manage an A2UI Agent (Google Cloud ドキュメント)
• google/A2UI GitHub リポジトリ

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile