Google、A2UI Expressと別系統の決定モデル方式を紹介

Google が十月二十七日に発表した A2UI の更新は、エージェントが画面を組み立てる際に最初に出力する形式を変える。従来はモデルが入れ子になった JSON の転送メッセージを直接書いた。新しい A2UI Express では短い中間形式を生成し、SDK の決定的な処理で標準 A2UI メッセージへ変換する。クライアントは引き続き使用を認める部品のカタログを提示し、描画側も既存の転送形式を受け取る。形式の指示とコンパイラが同じカタログから作られるため、Express がカタログ外の部品を無制限に作れるわけではない。

Google によれば、同種の画面を作る際の生成テキスト単位は直接 JSON と比べて最大で三分の一になり、遅延も最大三倍短縮できるという。原文は Gemini 3.5 Flash を用い、五十一の課題で直接 JSON、Express とほか二つの構文を比較したと説明する。「最大」は条件のよい観測値であり、すべてのモデルと画面に同じ結果を約束しない。SDK が構文を検証しても、表示する値の正しさ、部品の選択、操作が業務上適切かどうかは別の確認が必要だ。モデルが出した最初の文字までの時間だけでは、利用者が使える画面の完成時間は分からない。

Express は記事で挙げられた Python、TypeScript、Dart のエージェント SDK で利用できる。Python と TypeScript では直接 JSON を断片ごとに流せるが、Express はモデルから完全な返答を受け取ったあとでコンパイルする。Python SDK のマクロは、モデルが注文などの識別子だけを示し、アプリケーションの既存データから値を埋める使い方も可能にする。金額や注文状態をモデルに推測させず、信頼できる保管先から取得できる点は設計上重要だ。速度比較では生成、検証、描画、データ取得を分けて測るべきだろう。

記事は、画面の形があらかじめ決まっている場合の別方式も紹介する。Apparite という例では Jev の決定モデルが型付きの配置質問に答え、コードが部品の木を作り、別の小さなモデルが文章を書く。十一の入力を使った一回の例では、部品の木が九十二〜二百九十八ミリ秒で表示され、完成画面は〇・八〜一・七秒で得られた。Google が述べる最大八十倍という速さは、この制約付きの決定方式に関するものだ。事前に定義した九種類の画面と十二種類のブロックを扱う小規模な例であり、A2UI の SDK に決定モデル形式がすでに組み込まれたという意味でもない。Express 自体の性能値と混同してはならない。

形の分かった設定画面なら制約付きの選択が有効かもしれない。一方、認められたカタログの中で柔軟な構成を必要とする画面には Express が適する。独自形式を追加する場合も、その形式の説明と変換器をそろえれば転送と描画は使い続けられる。実際の採用判断では、自社の課題で部品の妥当性、データの正しさ、完成までの時間、失敗時の挙動を一緒に評価したい。モデルの token は暗号資産ではなく生成テキストの計量単位であり、八十倍の数字も A2UI を使う全アプリに当てはまるものではない。