目次
Google A2UI Teamは2026年10月27日、生成UIの推論形式を差し替えられる仕組みと、新しいA2UI Expressを発表しました。A2UIを使うエージェント開発者は、モデルに冗長なツリーを直接書かせる代わりに、短い行指向の形式を生成させ、Agent で標準のA2UIメッセージへコンパイルできます。既存のコンポーネントカタログやフロントエンドのレンダラーを維持したまま、生成時間と出力トークンを見直せる更新です。
公式発表は、A2UI ExpressがDirect JSONと比べて同種のUIを最大3分の1のトークンで表し、レイテンシーを最大3分の1にできるとしています。ただし、これはGoogleの評価結果であり、どの画面やモデルでも同じ比率になる保証ではありません。本稿では、WebアプリへA2UIを組み込む担当者向けに、移行対象の見分け方、設定例、比較試験、失敗時の切り分けを整理します。ここで示す手順は公式資料を確認した導入案であり、本サイトによる性能実測ではありません。
スポンサーリンク
変わるのはモデルの出力形式で、画面側の契約は維持できる
A2UIでは、クライアントが使えるボタン、入力欄、カードなどをカタログとして宣言します。エージェントはその範囲でUIを記述し、レンダラーが実際の画面へ変換します。モデルが任意のHTMLやJavaScriptを送り付ける方式ではなく、クライアントが用意した部品と機能を組み合わせる構成です。
従来のDirect JSONでは、モデルが標準の転送メッセージに近いJSONを直接生成します。A2UI Expressでは、モデルはPythonに似た短い記法でコンポーネント、データ結合、イベントを記述します。Agent SDKはカタログのJSON Schemaから、モデルへ渡す説明と、出力をA2UIメッセージへ変換するコンパイラーを用意します。カタログにない部品や属性は表現できないため、推論形式を替えてもUIの契約を別に作り直す必要はありません。
この分離が今回の固有の価値です。モデルの出力を短くしたいときに、通信形式やReact、Angular、Flutterなどの画面実装まで同時に変更せずに済みます。反対に、すでにDirect JSONの生成時間が十分短く、逐次表示が重要なサービスでは、形式を替える効果より移行確認の負担が大きい場合があります。
Direct JSON・Express・定型画面を用途で分ける
| 方式 | 向く画面 | 先に確認する点 |
|---|---|---|
| Direct JSON | 標準メッセージを逐次処理し、生成途中から表示したい画面 | JSONの長さ、構文失敗、ストリーミングの体感 |
| A2UI Express | カタログ内で構成が変わるフォーム、カード、結果画面 | 完全な応答を待つ時間、コンパイル失敗、モデル別の構文精度 |
| 定型レイアウト＋決定モデル | 候補画面が決まり、選択だけを高速化したい場面 | 定型から外れる要求の戻し先、対応できる状態の範囲 |
公式発表は、決まったレイアウトから選べる画面では、Jevのような決定モデルを使う方法も紹介しています。これはA2UI Expressへの単純な置換とは別の構成です。注文状況、検索結果、確認フォームの形が固定できるなら、モデルに全コンポーネントを毎回書かせない方が速く安定する可能性があります。例外の多いUIではExpressへ戻し、未知の用途には独自の推論形式とコンパイラーを用意する、という段階を作れます。
スポンサーリンク
移行前にカタログとレンダラーの基準を固定する
速度比較の前に、現在のカタログID、プロトコル版、レンダラー、サンプル入力を固定してください。A2UIのカタログはJSON Schemaで、利用できるコンポーネント、関数、テーマを定義します。成熟したフロントエンドでは既存のデザインシステムを反映した独自カタログ、新規アプリではBasic Catalogから始める方法が公式資料で案内されています。
Expressはカタログのプロパティ順を使う位置引数を持ちます。カタログの項目順や必須・任意の定義を同時に変えると、形式変更による差とカタログ変更による差を分離できません。まず同じカタログ、同じモデル、同じ入力でDirect JSONとExpressを比較し、その後にカタログの整理へ進む方が原因を追いやすくなります。
Python Agent SDKでExpressを選ぶ最小構成
公式発表時点では、Pythonのa2ui-agent-sdk 0.9.0、TypeScriptの@a2ui/agent、Dartのa2ui_agentでA2UI Expressが案内されています。Pythonではカタログを読み込み、ジェネレーターへExpressFormatFactory()を渡します。
from a2ui.processor import A2uiGenerator, CatalogConfig
from a2ui.inference_formats import ExpressFormatFactory
catalog = CatalogConfig.from_path("catalog.json")
generator = A2uiGenerator(
[catalog],
examples=few_shot_examples,
inference_format_factory=ExpressFormatFactory(),
)
processor = generator.create_processor(renderer_capabilities)
system_prompt = f"{instructions}\n\n{processor.prompt_snippet}"
parts = processor.parse_response(model_reply)この例で、少数例は従来どおりA2UI JSONとして一度用意できます。SDKが選択した形式向けの指示を生成し、モデルの応答を検証済みのA2UIメッセージへ変換します。モデルが書くExpressを、そのままブラウザーで実行するコードとして扱う構成ではありません。
公式ブログはExpress利用時にthinkingを無効にする手順を示しています。利用するモデルやSDKが同じ設定を受け付けるかを確認し、既存の推論設定を機械的に流用しないでください。TypeScriptではジェネレーターの第3引数へnew ExpressFormatFactory()を渡すと説明されています。パッケージ名だけで互換性を判断せず、と実際に導入した版を記録します。
スポンサーリンク
短い出力でも表示開始が早いとは限らない
導入時に最も見落としやすいのがストリーミングです。10月27日の公式ブログは、PythonとTypeScriptのSDKについて、Direct JSONはチャンク単位でストリームできる一方、Expressは完全な応答を受け取ってからコンパイルすると説明しています。出力トークンが減って総時間が短くなっても、最初のカードが表示される時刻はDirect JSONより遅くなる可能性があります。
Express仕様には行指向で逐次解析できる設計が記載されていますが、仕様上の能力と、利用するSDK版の実装は分けて確認してください。本番判断では、要求送信から最初の表示までの時間と、画面全体が確定するまでの時間を別々に測ります。ローディング表示を含む体感を、総トークン数だけから推測しないことが必要です。
比較用の画面と合格条件を先に作る
比較対象には、単純な確認カードだけでなく、実際に失敗しやすい画面を含めます。例えば、任意項目を一つ飛ばすフォーム、データモデルへ値を結合する結果一覧、承認と拒否のイベントを持つカード、既存surfaceを更新する画面です。各入力について期待するコンポーネント、必須属性、イベント名、データの出所を記録します。
最低限、生成した出力トークン、最初の表示までの時間、全体確定までの時間、コンパイル成功率、カタログ検証の合格率、再試行回数、最終画面の一致を比較します。公式の「最大3倍」という数字は候補選定の材料にはなりますが、自社のカタログが深いか、モデルがExpressを安定して書けるか、応答を一括で待つかによって結果は変わります。
既存の評価データを使う場合は、形式変更前と同じ入力を流し、画面の見た目だけでなくイベントとデータ結合を検査します。評価セットの作り方は、関連記事「AIの改善を勘で判断しないために｜評価データと回帰テストの始め方」で詳しく整理しています。
失敗はモデル・コンパイラー・レンダラーに分けて調べる
画面が出ないときは、モデルの生出力、コンパイル結果、レンダラーへ渡した標準メッセージを別々に残します。Expressの開始・終了タグがない、変数名が不正、必須の引数が欠ける場合はモデル出力または指示の問題です。コンパイラーが標準メッセージを生成したのに表示されないなら、プロトコル版、カタログID、レンダラーの対応を確認します。
位置引数の意味がずれる場合は、カタログのプロパティ順と、モデルへ渡したカタログ説明を照合します。任意項目を飛ばす_、データ結合の$/path、サーバーイベントのEvent(...)も確認点です。人が読める見た目に直すだけでは、コンパイル後のイベント名や値の結合先が正しいとは限りません。
再試行は無制限に行わず、同じ入力で一定回数失敗したらDirect JSONへ戻すか、定型画面を表示する経路を用意します。UI生成の失敗を、注文確定やデータ保存の再実行へ直結させないでください。構造化された出力と外部処理を分ける考え方は「構造化出力とツール呼び出しはどう違う？AIをWeb機能へ組み込む設計」も参考になります。
小さな割合から切り替え、形式ごとの記録を残す
本番では、推論形式、SDK版、カタログ版、モデル、生成時間、コンパイル結果を一つの記録へ結び付けます。Direct JSONとExpressを機能フラグで切り替えられる状態にし、社内利用や少数のセッションから開始します。エラー率だけでなく、表示開始の遅れ、再試行、利用者が画面を閉じた割合も確認します。
A2UIの資料ではv0.9.1がCurrent、v1.0がCandidateとして示され、Express仕様にはSDK間の対応差も記載されています。例えば複数カタログのv1.0動作はPythonとTypeScriptで実装される一方、DartのExpressコンパイラーはまだv1.0に対応していないとされています。プロトコルとSDKを同時に更新すると切り分けが難しくなるため、どちらか一方ずつ進めます。
スポンサーリンク
採用判断は「生成UIが遅い」という実測から始める
A2UI Expressは、カタログに沿った動的な画面を毎回モデルが組み立て、JSONの長さや構文失敗が待ち時間と費用を押し上げている場合に試す価値があります。既存レンダラーを維持できるため、推論形式だけを比較する小さな検証を作りやすい点も利点です。
一方、画面の種類が数個に決まるなら定型レイアウト、文章や分類だけで足りるなら通常の構造化出力の方が単純です。A2UIを使っていないアプリが、Expressの速度だけを目的にプロトコル全体を導入する必要はありません。まず遅延の内訳を取り、モデルの出力が支配的か、ネットワーク、データ取得、レンダリングが支配的かを確認してください。
移行の完了条件は、トークンが減ったことだけではありません。同じ入力で必要な部品とイベントを再現でき、最初の表示と全体確定の時間が用途に合い、失敗時に旧形式へ戻せることです。A2UI Expressを「短いJSON」と捉えるのではなく、モデル向けの表現とクライアント向けの契約を分離する選択肢として評価すると、採否を具体的に決められます。
