Agentに「旅行の候補を比較して」のような依頼をすると、文章だけでなく、比較カードや絞り込みフォームで返してほしくなる場面があります。
Microsoft Agent FrameworkのPython版1.15.0では、AG-UIアダプターにA2UI（Agent-to-UI）のサポートが加わりました。
これは、エージェントがフロントエンドに表示するUIの構成を返せるようにする仕組みです。
ただし、A2UIは「エージェントに自由な画面を作らせる」ための機能ではありません。
AG-UIとの役割を分け、画面の変更範囲を制御して使うと、対話を壊さずにリッチな入力・表示を足せます。
先に結論
- AG-UI は、エージェントのバックエンドとユーザー向けアプリをつなぐイベントプロトコルである
- A2UI は、その通信の中で「どのコンポーネントをどう表示するか」を表す生成UIの仕様である
- UIの骨格が固定なら、A2UIでコンポーネント構成まで生成させず、固定スキーマとデータだけを扱う方が安全である
- 画面構成も依頼内容ごとに変える必要がある場合に、カタログで許可したコンポーネントだけをA2UIで動的に組み立てる
両者は競合する選択肢ではありません。
AG-UIで会話や実行状態を届け、その上で必要なときだけA2UIを使います。
AG-UIとA2UIの違い
AG-UIは、エージェントとフロントエンドを接続するためのイベントベースのプロトコルです。
メッセージ、ツール呼び出し、実行状態、ユーザー操作などを双方向に扱います。
一方のA2UIは、エージェントがUIサーフェス（表示領域）にコンポーネントとデータを渡すための仕様です。
レンダラーがあらかじめ知っているコンポーネントのカタログを前提にするため、任意のHTMLやJavaScriptをエージェントに生成させる設計とは異なります。
| 観点 | AG-UI | A2UI |
|---|---|---|
| 主な役割 | エージェントとアプリの通信 | 表示するUIの構成とデータの表現 |
| 扱うもの | 状態、メッセージ、ツール、ユーザー操作 | UIサーフェス、コンポーネント、データ |
| 単独で解決すること | エージェント実行をアプリへ接続する | 画面を安全な部品の組み合わせで動的に描画する |
| 関係 | A2UIを運ぶ経路になれる | AG-UI上のUI表現として利用できる |
たとえば、注文状況を自然文で返すだけならAG-UIだけで足ります。
配送先の選択、日時の入力、注文内容の確認まで一連の操作として出したいなら、AG-UIで状態をやり取りしながらA2UIでフォームやカードを表示する、という分担です。
1.15.0で追加されたこと
2026年8月21日に公開されたPython版1.15.0では、agent-framework-ag-uiにA2UIのオプションサポートが追加されました。
追加の対象はAG-UIアダプターであり、A2UIを使わないアプリの基本依存関係を増やさない形になっています。
インストール時にA2UIの追加依存を指定します。
pip install "agent-framework-ag-ui[a2ui]>=1.15.0,<2"
リリースノートと実装では、次のような利用を想定しています。
- UIコンポーネントの構成を、クライアントが渡すカタログに基づいて動的に生成する
- バックエンドで決めたコンポーネント構成に、エージェントが取得したデータだけを流し込む
-
render_a2uiの引数をストリーミングし、サーフェスが組み上がる途中経過をクライアントへ届ける - 生成したUIを検証し、失敗時には再試行または失敗を表す結果へ戻す
後半の二つは、UIを生成する場合に特に重要です。
テキストの生成失敗は再生成で済むことがありますが、壊れたフォームを画面に出すと、ユーザーは何を入力できるのか判断できません。
実装は「動的」と「固定」から選ぶ
動的スキーマ: 依頼に合わせて画面の構成も変える
比較表、候補カード、入力フォームのどれが必要かを、依頼内容に応じてエージェントに選ばせたい場合です。
フロントエンドは、表示を許可するコンポーネントとそのプロパティをカタログとして持ちます。
エージェントはその範囲内でA2UIの操作を生成します。
この方式が向くのは、画面の種類を事前に絞り切れない対話型の支援です。
たとえば、社内ナレッジ検索で「候補の比較」「申請フォーム」「設定値の確認」を同じ会話から始めるケースです。
固定スキーマ: 画面の骨格はアプリが持つ
請求確認、権限申請、注文確定のように、レイアウトや入力項目をプロダクト側で固定したい場合です。
この場合はバックエンドがあらかじめ用意したA2UIの操作をツールから返し、エージェントには取得結果などのデータだけを扱わせます。
この設計なら、エージェントの出力が変わっても「確認ボタンが消えた」「必須項目が別の部品に置き換わった」といった変化を防げます。
初めてA2UIを導入するなら、こちらから始めるのが扱いやすいでしょう。
AG-UIエンドポイントへの設定は、次のように渡せます。
これは設定の要点だけを抜き出した断片です。
from agent_framework.ag_ui import add_agent_framework_fastapi_endpoint
add_agent_framework_fastapi_endpoint(
app=app,
agent=agent,
path="/assistant",
a2ui_config={
"default_catalog_id": "support-ui-v1",
"guidelines": {
"composition_guide": "Use a form only when user input is required.",
},
},
)
a2ui_configには、カタログ、既定のサーフェス、生成時のガイドライン、検証失敗時の回復方法などを渡せます。
設定値の詳細は、利用するAgent Frameworkのバージョンに対応したAPIリファレンスとサンプルを確認してください。
固定スキーマは「見た目を固定する」だけではありません。
金額、権限、同意、外部への送信に関わる操作では、入力検証と認可をサーバー側で必ず行います。A2UIで画面を表示できることは、その操作を許可する根拠にはなりません。
採用判断の目安
| 状況 | 選択 |
|---|---|
| 会話、進捗、ツール実行結果をアプリへ表示したい | まずAG-UI |
| 既存画面に、決まったカードやフォームを追加したい | 固定スキーマのA2UI、または既存UIで実装 |
| 依頼ごとに必要なカード・表・フォームが変わる | カタログを限定した動的スキーマのA2UI |
| 厳密な画面遷移、アクセシビリティ審査、ピクセル単位のデザインが必要 | 通常のフロントエンド実装を主にする |
| 購入・権限変更・個人情報の送信を含む | 固定UIとサーバー側の認可・検証を中心にする |
特に「画面を生成できるなら、既存のフロントエンドを置き換えられる」と考えるのは早計です。
A2UIは、許可済みの部品を使って対話の途中にUIを差し込むための仕組みとして捉えると、境界が明確になります。
導入時に決めておきたいこと
コンポーネントカタログをAPI契約として扱う
カタログは、エージェントが利用できるUI部品の境界です。
部品名、必須プロパティ、イベント名を変更すると、プロンプト、エージェント、レンダラーのいずれかが追随できなくなることがあります。
support-ui-v1のようにバージョンを持たせ、互換性のない変更は新しいカタログで出すと移行を管理しやすくなります。
失敗時の表示を先に作る
生成結果の検証に失敗したとき、何を再試行し、何回で打ち切り、ユーザーにどう伝えるかを決めます。
UIが作れない場合にテキスト回答へ戻すのか、再実行ボタンを出すのかは、機能ごとに異なります。
正常系だけを見ていると、ストリーミング途中の切断やカタログ更新時に操作不能な画面を作りやすくなります。
ユーザー操作は常に再検証する
レンダラーから返るイベントは、サーバーにとって信頼済み入力ではありません。
UIで選択肢を絞っていても、IDの存在確認、権限、現在の状態、二重実行の防止をサーバー側で検証します。
これはA2UI固有の制約ではなく、エージェント経由で業務操作を行うときの基本です。
まとめ
Agent Framework 1.15.0のA2UIサポートは、AG-UIで接続したエージェント体験に、構造化されたUIを加える選択肢です。
最初から画面全体を生成対象にする必要はありません。
まずAG-UIで会話と状態の流れを整え、価値の高い一場面だけを固定スキーマのA2UIで置き換える。その後、本当に画面構成まで可変にする必要がある部分へ動的スキーマを広げると、運用しやすくなります。