Google A2UIとは？AIが「画面を描く」時代の仕組みをデザイナー目線でわかりやすく解説

こんにちは、プロンプト画伯です。

元デザイナーからAI画像職人になって、毎日プロンプトを試行錯誤しています。

「センスじゃない、言語化だ」をモットーに、使えるプロンプトと失敗例を晒しています。

今日はちょっと方向が違う話をします。

Google A2UIという新しいプロトコルの話です。

最初に見たとき、「これ、画像生成AIで散々やってきた『言語化でモノを作る』体験が、画面そのものに飛び火するやつじゃん」と震えました。

デザイナーとして、そして画像生成AIの住人として、A2UIは完全に自分ごとなので、今回はじっくり解説してみました。

画像生成AIの次はA2UIが「画面」を描くエージェントの話

プロンプト一本で絵を出力する。

この数年、私たちがやってきたことです。

Midjourneyでコンセプトアート、Stable Diffusionでリアル画像、DALL-Eでバリエーション出し。

「言語化すれば、モノが出てくる」という体験に、もう身体が慣れきってるんですよね。

ここで想像してみてください。

プロンプトを投げたら、絵じゃなくて「動くUI」が出てきたら、どうしますか。

しかも、フォームもボタンもスライダーも、全部その場で生成される。

「え、そんなことできるの？」って感じですよね。

2025年12月にGoogleが初公開し、2026年4月にv0.9アップデートで再び注目を集めている「A2UI（Agent-to-UI）」プロトコルは、まさにその世界を作ろうとしています。

ネタ元はこれです。

投稿主の Atai Barkai さんは CopilotKit のCEOで、A2UIのローンチパートナー側の一人です。

「エージェントが画面そのものを書き始める時代が来た」と興奮気味に紹介していて、読んでて私もテンションが上がりました。

この記事では、A2UIとは何なのか、何がすごいのか、そしてデザイナーやクリエイターの仕事にどう効いてくるのかを、専門用語を噛み砕きながら解説していきます。

でも、そもそもなんでこんな仕組みが必要になったのか。先に「困り事」から入った方が、A2UIのすごさが伝わるんです。

そもそもAIエージェントのUI自動生成で何が困っていたか

テキストだけのチャットには限界があった

ChatGPTにしろClaudeにしろ、今までのAIとの対話は基本「文字」でした。

質問して、文章で返ってくる。

これはこれで便利なんですが、「予約日を選びたい」「商品を3つの中から選びたい」みたいな、ちょっとインタラクティブな作業になると途端に不便です。

チャットの中で「何月何日ですか？」と聞かれて、カレンダーのない世界で日付を打ち込む感覚です。

本当にしんどいんですよね。

HTMLやJSを直接書かせるのは危険すぎた

じゃあエージェントにHTMLやJavaScriptを直接吐かせればいいじゃん、という発想もありました。

実際、一部のAIツールはそうしています。

でもこれ、セキュリティ的に本当に怖い話なんです。

エージェントが生成したコードに、悪意のあるスクリプトが混ざっていたら？

ユーザーの入力を盗むコードが仕込まれていたら？

これを「UIインジェクション攻撃」と呼びます。

AIにHTMLを自由に書かせるということは、Webの世界で一番やってはいけないことを許すことに近い。

つまり、「動くUIが欲しい」けど「エージェントにコードは書かせたくない」という矛盾を、どう解くかが課題だったわけです。

この「矛盾」を鮮やかに解決したのが、次に紹介するA2UIなんです。

Google A2UIとは何か：JSONでUIを記述するプロトコル

A2UIは「コード」ではなく「設計図（JSON）」を送る仕組み

A2UIの一番の発明は、ここです。

エージェントはHTMLやJSを書きません。

代わりに、「どんなUIを表示してほしいか」をJSON形式で宣言します。

JSONというのは、簡単に言えば「構造化されたメモ」みたいなものです。

「タイトルはこれ」「ボタンを3つ配置」「色はこの赤」みたいな情報を、機械が読める形で書いたもの。

これをエージェントがクライアント（ユーザーの画面側）に送ると、クライアント側が用意しているネイティブのUIパーツを使って実際の画面を組み立てます。

この「設計図を渡して、組み立ては現場に任せる」スタイルが、A2UIの核です。

つまり、エージェントはあくまで「何を出してほしいか」を指示するだけで、コードには一切触れない。

危険な橋を渡らずに、インタラクティブなUIが実現できる、これがA2UIの本質的なすごさです。

絵のプロンプトと同じ「宣言的」という考え方

ここでピンと来てほしいのが、画像生成AIのプロンプトです。

Midjourneyに「a cyberpunk city at night, neon lights, rain」と投げるとき、私たちは手順じゃなくて「何が欲しいか」を書いてますよね。

描き方そのものは指定していない。

A2UIも同じ発想です。

「どう描くか」じゃなくて「何を描くか」だけを書く。

これを宣言的UI記述と呼びます。

プロンプト文化を通ってきた人なら、この感覚は一瞬で掴めるはずです。

v0.8安定版とv0.9ドラフトが進行中

A2UIは2026年4月時点で、v0.8が安定版、v0.9がドラフトスペックとして公開されています。

Apache 2.0ライセンスの完全オープンソースなので、誰でも使えて、改造もできます。

「オープンソースで無料、しかもGoogleが主導」という組み合わせは、エコシステムが育ちやすい条件が揃っているんですよね。

公式はここです。

ちなみに、これはGoogle主導のプロジェクトで、CopilotKitはローンチパートナーとして初期から密接に協力しています。

CopilotKitはAG-UIという別のプロトコルを作っていて、この2つが絶妙にペアになる設計になっています（これは後で詳しく説明します）。

仕組みの概要がわかったところで、もう少し「中身」を掘り下げてみましょう。

A2UIの仕組みとGenerative UIのフロー

コンポーネントカタログという「承認済みパーツ集」

A2UIを理解する上で、一番重要な概念が「コンポーネントカタログ」です。

これは、クライアント側（Webアプリやモバイルアプリ）が事前に用意しておくUIパーツのリストです。

ボタン、フォーム、カード、チャート、画像プレビュー、みたいな部品たち。

全部、開発者が「これなら表示していいよ」と承認済みのパーツ。

エージェントは、このカタログの中からしかパーツを選べません。

つまり「この店にあるメニューからしか注文できない」状態です。

これがすごく重要で、エージェントが勝手に変な要素を差し込めないから安全が保たれるわけです。

エージェント→JSON→ネイティブ描画の流れ

ざっくりフローはこんな感じです。

1. ユーザーがエージェントに話しかける（例：「来週の予約を取りたい」）
2. エージェントが必要なUIを判断する（例：「カレンダーと時間選択と確認ボタンが必要だな」）
3. エージェントがJSONでUI設計図を作る
4. クライアントがJSONを受け取る
5. コンポーネントカタログのパーツを組み合わせてネイティブに描画する

この流れで、エージェントが勝手にコードを吐くのではなく、あくまで「注文書」を出すだけという関係になります。

ストリーミング描画でLLMと相性が抜群

もう一つ面白いのが、JSONがストリーミングで送られてくる対応をしている点です。

LLMって、文章を一気に生成するんじゃなくて、トークンを順番に吐き出しますよね。

A2UIのJSONも同じで、エージェントが考えながらUIを少しずつ送ってきて、クライアントが受け取り次第どんどんレンダリングしていけます。

「先にタイトルだけ表示されて、あとからボタンが出てくる」みたいな体験になる。

つまり、「全部揃うまで白い画面でぼーっと待つ」時代が終わるんです。

ユーザーが感じる「重さ」が全然変わる、地味にでかい改善なんですよね。

次は「じゃあAG-UIとは何が違うの？」という疑問を解消しましょう。ここで混乱しがちなポイントがあるので、しっかり整理します。

AG-UIとA2UIは何が違うのか：通信とペイロードの役割分担

AG-UIは「どう運ぶか」、A2UIは「何を運ぶか」

ここ、ちょっと混乱するポイントです。

AG-UIとA2UIって名前が似てるんですが、役割が完全に違います。

比喩で言うと、AG-UIは「配達トラック」、A2UIは「荷物の中身」です。

AG-UIはエージェントとフロントエンドの通信プロトコル。

つまり、どういうチャンネルでデータをやり取りするかを決める層です。

A2UIはその通信で流す「UIの中身（ペイロード）」を定義する層。

この2つが組み合わさって初めて、「エージェントがUIを送って、画面が動く」が成立します。

CopilotKitはこの関係を「A2UIとAG-UIはセットで使うもの」と明言しています。

MCP・A2A・AG-UI・A2UIという4層のスタック

2026年現在、AIエージェントまわりのプロトコルは大きく4つあります。

この4つでエージェント時代の「OSレイヤー」みたいな構造ができつつあります。

A2UIはその中で「画面を描く」担当、と覚えておけば充分です。

「なるほど、役割分担か」と腹落ちしたら、次は「自分の仕事にどう効くか」ですよね。ここからが個人的に一番テンションが上がるパートです。

A2UIでデザイナーの仕事はどう変わるか

Figma的なコンポーネント設計がそのまま活きる

デザイナーとして一番嬉しいのは、Figmaで普段やっているコンポーネント設計の考え方が、ほぼそのままA2UIの世界で通用することです。

Figmaで「Button」「Card」「InputField」といったコンポーネントを作って、Variantsで色や状態を切り替える。

A2UIのコンポーネントカタログは、この設計思想とほぼ同じ。

つまり「良いデザインシステムを作れる人」は、そのままA2UIで強いってこと。

デザイナーのアセットが、エージェントの出力品質を直接決める時代が来ます。

これ、すごいことなんですよ。

デザインの仕事が「見た目を作る」から「エージェントが参照するカタログを作る」に変わっていく、そういうシフトが起きつつあります。

ノーコード開発者との相性もいい

ノーコード勢にとってもA2UIは朗報です。

コンポーネントを一度カタログとして定義しておけば、あとはエージェントが組み合わせてくれる。

「プロンプトを投げたらUIが組み上がる」感覚で作業できるようになります。

BubbleやFramerのような既存ノーコードツールが、A2UI対応を始めたら相当強力です。

「センスじゃない、言語化だ」がUIの世界にも

これ、個人的に一番言いたいポイントです。

画像生成AIで散々言われてきた「プロンプトの言語化スキル」が、UIの世界でも全く同じように効いてきます。

「何を、どんな配置で、どんなトーンで、どんな目的で見せたいか」を言葉で説明できる人は、A2UIでも強いってこと。

絵心じゃない、UIセンスじゃない、言語化力なんですよね。

プロンプト画伯として、ここはかなり嬉しいポジション取りです。

「理屈はわかった、じゃあ実際に触れるの？」という疑問が出てきたと思いますが、答えはYESです。

A2UI 試し方：CopilotKitコマンドで30秒セットアップ

npx一発でサンプルアプリが動く

「仕組みはわかった、で、実際どうやって試すの？」

これ一番気になりますよね。

Atai Barkaiさんの投稿ではコマンド一発のスクリプトが紹介されています。

npx copilotkit@latest create my-app --framework a2ui

ただ、CopilotKit公式ドキュメントでは現時点でテンプレートリポジトリをクローンする手順が案内されているので、もしnpxがうまく動かない場合はこちらを試してください。

git clone https://github.com/CopilotKit/with-a2a-a2ui.git

どちらにせよ、Node.jsが入っていればすぐに試せます。

セットアップで何が起きるのか

テンプレートを使うと、CopilotKitがA2UI対応のサンプルアプリを展開してくれます。

Reactベースのプロジェクトが立ち上がって、エージェントがJSONでUIを送る→画面が生成される、という流れを実際に体験できます。

GitHubリポジトリはここで公開されています。

GitHub - CopilotKit/generative-ui: Generative UI examples for: AG-UI, A2UI/Open-JSON-UI, and MCP Apps.

Generative UI examples for: AG-UI, A2UI/Open-JSON-UI, and MCP Apps. - CopilotKit/generative-ui

github.com

最初に触るなら、このテンプレを眺めるだけでも雰囲気が掴めます。

私も最初セットアップしたとき、「ああ、これ本当に動くんだ」と素直に感動しました。

ドキュメントで文字を読んでいたときとは全然違う実感があって、「エージェントが画面を組み立ててくる」感覚が体に入ってきます。

ドキュメントを読み込むよりも、先に手を動かす方が圧倒的に理解が早いのでおすすめです。

手を動かしながら「この技術、今後どう育っていくんだろう？」と気になりますよね。ロードマップを確認しておきましょう。

A2UI 2026 ロードマップと業界動向

React先行、モバイル対応は2026年後半

a2ui.orgで公開されているロードマップはこんな感じです。

Reactが最優先で開発中で、コミュニティ製のレンダラーはすでに複数動いています。

公式レンダラーが完成すれば、もっと安定した形で試せるようになります。

モバイルアプリ勢（iOS／Android）は Q2以降が本番投入の目安になりそうです。

v1.0がQ4予定ということは、今はちょうど「先行して試しておくと美味しい」タイミングなんですよね。

MCP Apps陣営との競争が激化している

忘れちゃいけないのが、AnthropicとOpenAIが推している「MCP Apps」という別の規格の存在です。

ざっくり言うと、A2UIが「Web中心・ネイティブコンポーネント派」、MCP Appsが「アプリ単位で配布する派」みたいな対立軸になっています。

どっちが勝つかは現時点では読めません。

どちらも長所と短所があるので、両方の動向を追っておくのが吉です。

個人的には、A2UIのオープンソース体制とCopilotKitの実装スピードが心強いと思っています。

A2UI時代、プロンプトの射程はどこまで広がるのか

絵を描くから画面を描くへ

ここまで読んでくれたあなたに、一番伝えたいことです。

A2UIの登場は、「プロンプトで絵を描く」で終わっていた私たちの体験を、「プロンプトで画面を描く」まで拡張してくれます。

画像生成AIで培った言語化スキルが、エージェント UI 自動生成の世界でもそのまま武器になる時代がきました。

デザイナーにとっても、ノーコード勢にとっても、フロントエンド勢にとっても、この流れは無視できないインパクトがあります。

今すぐ試すべき人・様子見でいい人

最後に、タイプ別のおすすめです。

今すぐ試すべき人

• React／Next.jsでWeb制作している人
• ノーコードツールを作ってる／使ってる人
• デザインシステムを日常的に設計している人
• 画像生成AIを使い倒してきた人（言語化の感覚がすでにある）

もう少し様子見でいい人

• 本番プロダクトにすぐ組み込みたい人（v1.0を待つ方が安全）
• モバイルアプリ専業の人（SwiftUI対応はQ2予定）

私自身は、Reactで小さいサンプルを作って、エージェントにUIを吐かせる実験をしているところです。

プロンプト画伯としての言語化スキルが、UIの世界でもちゃんと効くことを確認できて、ちょっと興奮しました。

「センスじゃない、言語化だ」は、これからも射程が広がっていきます。

あなたのプロンプトスキルを、次はUIで試してみてください。