A2UI入門 — GoogleのUIプロトコルを動かしてみた

A2UI入門 — GoogleのUIプロトコルを動かしてみた

2026.02.16

こんにちは!製造ビジネステクノロジー部の石井です。

いまのチャットAIはテキストだけで何でもこなそうとしますが、正直、フォームで入力したほうが早い場面やテーブルで一覧したほうが分かりやすい場面は山ほどありますよね。
エージェントが状況に応じてリッチなUIを動的に生成できたら — それを実現するのが、Googleがオープンソースで公開した**A2UI(Agent-to-User Interface)**というプロトコルです。

今回はこのA2UIを実際に触ってみたので、このプロトコルがどんな未来を開きそうか、一緒に考えてみましょう。技術的な中身の解説は後編(近日公開)で詳しく書いています。

A2UIとは何か

A2UI(Agent-to-User Interface)は、AIエージェントがUIを安全に生成するための宣言型UIプロトコルです。2025年12月にGoogleがApache 2.0ライセンスで公開しました。

公式サイト: https://a2ui.org

基本的な仕組み

エージェントが生成するのはJSONデータです。HTMLでもJavaScriptでもなく、実行可能なコードは一切含みません。

クライアント側には事前に承認されたUIコンポーネントのカタログ(Card、Button、TextField、Tableなど)があり、エージェントはそのカタログの中からコンポーネントを組み合わせてUIを構築します。エージェントが「このボタンを置いて、ここにテキストフィールドを配置して...」と構造を宣言すると、クライアントがそれをネイティブなUIとしてレンダリングする仕組みです。

余談: エージェントプロトコルエコシステムの中での位置づけ

A2UIは単独で存在するプロトコルではなく、エージェント間通信のエコシステムの一部として設計されています。

それぞれの役割を整理します。

  • AG-UI (CopilotKit) … フロントエンド↔エージェント間のランタイム接続を提供するプロトコル。上の図でいうフロントエンド↔エージェント間の双方向通信の仕組み全体にあたる。今回のA2UIサンプルではAG-UIは使われておらず、同じ層をA2Aが担っている
  • A2UI (Google) … エージェントからフロントエンドへのレスポンスに含まれるUIの設計図。JSONフォーマットで「どんな画面を出すか」を記述する。トランスポート非依存で、AG-UIに限らずA2AやSSE/WebSocketなど任意の通信手段で運べる
  • MCP (Anthropic) … エージェントの「手足」。外部ツールやデータソースとの接続を担う
  • A2A (Google) … エージェント同士の「会話」。タスクの委譲や協調を担う

AG-UIとA2UIは名前が似ていて混同しやすいですが、レイヤーが違います。AG-UIがフロントエンド↔エージェント間のランタイム接続(通信の仕組み全体)を指すのに対し、A2UIはその通信で運ばれるUIペイロードのフォーマットです。

実際に動かしてみた

セットアップ

A2UIリポジトリにはいくつかのサンプルが同梱されています(https://github.com/google/A2UI/tree/main/samples)。まずはLitレンダラー(Web Components)でRestaurant Finderデモを動かしてみました。

まずリポジトリをクローンします。

git clone https://github.com/google/A2UI.git

デモの実行にはGemini APIキー(無料)が必要です。以下の手順で取得できます。

  1. Google AI Studio にアクセス

  2. Googleアカウントでログイン

  3. 左下メニューの「Get API key」をクリック
    CleanShot 2026-02-14 at 09.34.11@2x

  4. 「Create API key」で新しいキーを作成
    CleanShot 2026-02-14 at 09.35.55@2x

5.キーの名前、プロンプトを選択して作成
CleanShot 2026-02-14 at 09.36.46@2x

取得したAPIキーを環境変数に設定します。

export GEMINI_API_KEY="your-api-key"

※キーはここからコピーできます。
CleanShot 2026-02-14 at 10.08.07@2x

Litクライアントのサンプルディレクトリに移動して、依存関係をインストールしたらデモを起動します。

cd A2UI/samples/client/lit
pnpm install
pnpm run demo:all

demo:allを実行すると、Python製のエージェントサーバーとLit製のWebクライアントが同時に起動します。(フロント、API同時起動するので落ち着くまで待ちます)

CleanShot 2026-02-01 at 00.17.59@2x

触ってみた印象

チャット内にデフォルトで入力されている「Top 5 Chinese restaurants in New York.」をそのまま使用して送信すると、エージェントがレストランの検索結果をカード形式のUIとして動的に生成してくれます。

CleanShot 2026-02-14 at 09.43.59@2x

※なお、このデモはモックデータのためニューヨークの中華レストランのみ対応しています。
試しに、「Find me a good Italian restaurant」 と入力したら、TOPに戻されました

レストランを選んで「Book Now」ボタンを押下すると、今度は日時や人数を入力できるフォームUIが生成されます。

CleanShot 2026-02-14 at 09.45.51@2x

テキストのやり取りで一つずつ聞かれるのではなく、一画面でまとめて入力できるのは明らかに効率的です。
自分はタイピングが遅いほうなので、チャットベースではなくGUIでポチポチ選ぶだけで済むのは地味にありがたかったりします。

良かった点:

  • あらかじめUIを作り込んでいなくても、それっぽいUIが動的に出てくる
  • 事前に作り込んだ画面と言われても違和感がないくらい、見た目に一体感がある
  • レストランの情報と「Book Now」ボタンがセットで返ってくるので、次のアクションにそのまま進める。テキストだけだと、情報を見た後に「〇〇を予約して」とまたテキストを打つことになる

実際に使うなら気をつけたい点:

  • サンプルではエージェントのレスポンスが返り切るまでUIが表示されなかった。AG-UIなどストリーミング対応のトランスポートと組み合わせた場合にどうなるかは未検証
  • フォームのバリデーション制御(必須チェックやボタンの無効化など)は、サンプルのv0.8では未対応だがv0.9ドラフトで追加されている。とはいえ実際に使う際には、想定外の入力に対するエラーハンドリングやユーザーへのフィードバックはちゃんと設計しておきたい

A2UIが変える未来

ここからはA2UIが広く普及した場合に実現しうる未来について考えてみます。

テキストチャットからの解放

いまのチャットAIを使っていて、こんな場面に遭遇したことはありませんか?

  • 5つの選択肢から一つ選ぶだけなのに、テキストで「2番でお願いします」と打っている
  • 日時を指定するのに「2026年2月15日の14時から」と手入力している(カレンダーUIがあれば1クリックなのに)
  • 表形式のデータを延々とテキストで読まされている
  • 画像やチャートで見たほうが一瞬で理解できる情報を、長文で説明されている

これはチャットAIのインターフェースが「テキスト入力 → テキスト出力」に縛られているために起きる問題です。
A2UIがあれば、エージェントは状況に応じてDateTimeInputコンポーネントでカレンダーを出したり、MultipleChoiceで選択肢を出したり、テーブルやチャートでデータを可視化したりできます。

「何でもテキストで頑張る」時代から、「場面に応じた最適なUIをエージェントが選ぶ」時代への転換です。

システム連携UIの即席生成

いま、あるシステムのデータを別のシステムで表示したいとき、連携用の画面開発が必要です。API設計、データマッピング、UI実装、テスト...。システムの数が増えるほど、連携パターンはN×Nで爆発的に増えていきます。

もし各システムがA2UIに対応したエージェントを標準装備していたら、話は変わります。

連携用の画面を事前に開発する必要がなくなり、必要なときに必要なUIが即席で生成される世界です。A2UIが宣言的でセキュリティが担保されたフォーマットだからこそ、信頼境界を越えたUIの受け渡しが安全に成立します。

マルチエージェント協調の世界

複数のエージェントが協調してUIを提供する未来も見えてきます。

たとえば旅行の計画。航空会社のエージェントがフライト選択UI、ホテルのエージェントが宿泊予約UI、レンタカーのエージェントが車種選択UIをそれぞれA2UIで提供し、旅行サイトのオーケストレーターがこれらを一つの画面に統合する。各社が自社のUIをA2UIフォーマットで公開するだけで、統合は自動的に行われます。

実はA2UIリポジトリにはすでにマルチエージェント構成のサンプルが含まれていて、この仕組みがサンプルレベルで動作しています。
裏側の動きについては後編(近日公開)で除いてみましょう。

今後の注目ポイント

A2UIはまだ初期段階ですが、だからこそ今後の動きが楽しみなプロトコルです。
個人的に気になっているポイントをいくつか挙げておきます。

仕様の進化: 現在v0.8(安定版)とv0.9(ドラフト)の段階です。v0.9ではバリデーション機能の強化やスキーマのモジュール化が進んでいます。ロードマップによると、2026年Q1にReactレンダラー、Q2にSwiftUI/Jetpack Composeレンダラー、Q4にv1.0安定版のリリースが予定されています。React対応が来たらフロントエンド界隈でもぐっと注目度が上がりそうです。

実データとの統合: 現状のサンプルはモックデータなので、実際のAPIやデータベースと繋いだときにどうなるかは気になるところです。MCP等のツール連携と組み合わせて、リアルなデータでUIを生成するパターンを試してみたいですね。

まとめ

実際に触ってみて、「画面を事前に作らなくてもUIが出てくる」という体験は素直に新鮮でした。まだサンプルレベルではありますが、宣言的なJSONだけでここまでの見た目と操作感が実現できるのは想像以上です。

まだv0.8の段階で、ストリーミング表示やバリデーションなど改善の余地はあります。ただ、v0.9ドラフトではこのあたりも着実に進化していて、2026年Q1にはReactレンダラー、Q4にはv1.0安定版のリリースも予定されています。

テキストチャットベースのやり取りから、エージェントが場面に応じたUIを選んでくれるようになり、さらにはマルチエージェントで複数のサービスのUIが一つの画面に統合される未来まで見えてくると、これはかなりワクワクします。

サンプルはgit cloneしてすぐ動かせるので、気になった方はぜひ触ってみてください。
裏側でどういった挙動を行ってるかは、別ブログ(近日公開)で取り上げたいと思います。

A2UIリポジトリ: https://github.com/google/A2UI (Apache 2.0)

この記事をシェアする

FacebookHatena blogX

関連記事