A2UI 1.0、AIが作る画面がAIを待たずに動けるようになった

AIに旅行の予約や買い物を頼んだら、文章の返事の代わりに、日付を選ぶカレンダーや「予約する」ボタンが付いた画面が返ってきた。そんな場面に心当たりがあるなら、その画面を支える規格に動きがあった。Googleが2026年11月11日(米国時間)、AIエージェント向けの対話的な画面を作るオープンプロトコル「A2UI」の最初の安定版、1.0を発表した。目玉は、画面のボタンを押すたびにAIが考え直していた仕組みに、AIを経由しない新しい経路が加わったことだ。

この画面は誰が、どうやって描いているのか。1.0で何が変わり、自分が使っているAIでも見られるようになるのか。順番に見ていく。

AIの返事が「画面」になる仕組み

答えは、AIではなく手元のアプリ自身が描いている、になる。公式サイトの説明はこうだ。「エージェントは何を表示するかを記述し、それぞれのアプリが自分のネイティブ部品で画面を描く」。つまりAIは画面そのものを送ってくるのではなく、「カードを1枚、中に『注文番号7731』という文字と『再注文』というボタンを置く」といった組み立て方の指示をデータとして送る。受け取ったアプリ側は、あらかじめ用意してある自分のボタンやカードの部品(これを「カタログ」と呼ぶ)を使って、その指示どおりに画面を描く。

HTMLやJavaScriptのコードそのものは送られてこない。画面の部品はアプリ側が事前に登録したものに限られるので、AIが勝手に見た目の違うボタンを作ったり、危険なコードを仕込んだりする余地がない。これが「生成的UI」と呼ばれる仕組みで、A2UIはこの組み立て方を各社共通のルールにするためのプロトコルになる。

では、そのカードの「再注文」ボタンを押すと、何が起きるのか。

操作のたびにAIへ戻る仕組み

答えを知るには、画面ができるまでの手順を見る必要がある。A2UIのプロトコル仕様書によると、画面が1枚描き上がるまでにAIエージェント側は次の順でメッセージを送る。

1. createSurfaceで画面の土台(サーフェス)を作る
2. updateComponentsでボタンやカードを配置する
3. updateDataModelで中身のデータを入れる

この画面でユーザーがボタンを押すと、アプリ側(レンダラー)はactionというメッセージをエージェントへ送り返す。エージェントはそれを受けて、次にどんな画面を見せるかをまた考え、新しいupdateComponentsやupdateDataModelを送ってくる。つまり0.9までは、画面の中で起きる操作のほとんどが、いったんAIエージェントまで戻ってから次の指示をもらう一方通行の経路だった。

この経路だと、画面の小さな値を1つ更新したいだけでも、AIにもう一度「考えて」もらう必要がある。ここに1.0で手が入った。

AIを経由しない新しい経路

空席確認がその場で終わる

発表ブログは1.0の目玉をこう書いている。「Version 1.0 adds bidirectional function calls, so a flight or reservation picker can check availability on the spot(双方向の関数呼び出しが加わり、航空券や予約の選択画面はその場で空席を確認できるようになる)」。

具体的には、航空券の予約画面で出発日を変えたとする。0.9までの経路なら、その操作をactionとしてAIエージェントに送り、エージェントが新しい空席状況を調べて画面をまるごと描き直す。1.0で新設されたのは、画面の部品がcallAgentFunctionという別のメッセージで、エージェント側に用意された「空席を調べる」という普通の関数を直接呼び出す経路だ。関数の実行結果はagentFunctionResponseで画面に戻り、該当する部分だけが更新される。

これは、エージェントからアプリへ関数を呼ぶ経路(callRendererFunction、0.9のcallFunctionを置き換えたもの)の逆方向にあたる。自分はここで一度止まった。生成的UIは「AIが考えて、画面を描いて、操作されたらまたAIに戻る」循環が前提だと思っていたからだ。画面の部品自身がエージェント側のプログラムに直接問い合わせられるなら、AIへ戻らずに値だけを取りにいける。

つまり、画面を操作したときにAIへ戻る経路(action)と、画面の部品が裏側の関数を直接呼ぶ経路(callAgentFunction)は、1.0から別物として分かれている。

「AIを経由しない」の中身

ここで気になるのは、「AIを経由しない」が具体的に何を省いているかだ。A2UIの仕様書はcallAgentFunctionを「レンダラーがローカルに実装を持たない関数を呼ぶときの経路」と説明するにとどまり、その先でAIモデル自体を呼び出すかどうかは決めていない。実装側の裁量になるということだ。ここは自分の読み方になるが、空席確認のような単純な値の取得にまでAIモデルの応答を待たせる設計にする理由は薄い。だとすれば、callAgentFunctionの多くは、AIモデルを介さない普通のプログラムの呼び出しで完結すると自分は見ている。

自由になった分だけ歯止めも入った

画面の部品がエージェント側の関数を直接呼べるようになると、今度は心配になる。画面が勝手に、ユーザーの意図しない操作をしてしまわないかということだ。ここにも仕様が手当てをしている。

カスタム関数の仕様では、関数ごとに誰が呼べるかをallowedCallersで決める。

• rendererOnly(既定): アプリ側だけが呼べる
• agentOnly: AIエージェントだけが呼べる
• rendererOrAgent: どちらからでも呼べる

さらに、外部のWebページを開くopenUrlのような、実行すると取り返しのつかない操作を伴う関数にはrequiresUserActivation: trueという印が付く。この印が付いた関数は、ユーザーが実際にボタンを押すといった操作をした瞬間でなければ実行できない。AIエージェントがこの関数を呼ぼうとしても、INVALID_FUNCTION_CALLというエラーで弾かれる。

経路が増えて自由度が上がった分だけ、「ユーザーが今まさに押した」という条件を満たさない限り重い操作は動かせない、という歯止めが同時に組み込まれている形になる。

自分が使うAIではもう見られるか

ここまでの変更は、今すぐ全部のAI製品で体験できるわけではない。発表ブログによると、対応は次のように分かれている。

この表から分かるのは、1.0の画面をすでに体験できるのは一部に限られるということだ。

一方で、WebとFlutterのレンダラーはClaudeが使う「MCP Apps」という別の仕組みの内部でも動く。そのため、ClaudeのようなMCP Apps対応のAIアシスタントの会話の中にも、A2UIで組み立てた画面を表示できる。発表ブログでは、データ分析サービスのAlationが、同じフィード(指標カードやグラフ)をA2UIで作り、自社アプリとClaudeの会話の両方に表示している例が挙がっている。

ほかにもAtlassianがJiraの作業項目内で判断を仰ぐカードを公開済みだ。ByteDanceは動画アプリ「Lynx」向けのレンダラーを2026年6月に公開し、0.9対応から1.0対応を進めている段階にある。

A2UIはApache 2.0のオープンソースで、仕様とSDKはGoogleのGitHub(a2ui-project/a2ui)で公開されている。Pythonに加えてTypeScript・Dartのエージェント向けSDKも用意されており、画面を描く側だけでなく、エージェントを作る側もすぐに1.0の仕様に触れられる。

まとめ

Googleのオープンプロトコル「A2UI」が1.0になり、AIエージェントが作る対話的な画面に、AIへ戻らず裏側の関数を直接呼ぶ経路(callAgentFunction)が新設された。航空券の空席確認のように、画面の一部を更新するだけならAIの応答を待たずに済む場面が増える。

同時に、ユーザーが実際に操作した瞬間でなければ実行できない関数の区分(requiresUserActivation)も加わり、自由度と歯止めが一緒に入った格好になる。対応はWeb・Flutter・iOSのレンダラーが先行し、Android版やGemini本体の対応はこれから追いつく段階にある。ClaudeやGeminiの会話の中で操作できる画面に最近触れた人は、その裏側でこの規格が動いている可能性がある。