エージェントが画面を描き直すとき、利用者は何を確認したのか

2026年10月29日、Googleは、アプリの部品からエージェント生成型の画面を組み立てるA2UIとCopilotKitのチュートリアルを公開した。そこで考えたいのは、変化し続ける画面に対して、利用者の確認がどの版の実行を認めるのかという問題だ。Googleのチュートリアル。

以下はOpen Market Notesによる設計上の分析であり、脆弱性を発見したという報告ではない。対象は、提案を読む時点と操作する時点の間にある時間だ。生成型UIなら、利用者は追加のプロンプトを書かずに選択肢を比較できる。ただし、エージェントが提案も修正するなら、人が検討した条件と、最終的に実施する処理の関係をアプリが維持する必要がある。

同じボタンの意味が変わるとき

顧客サポート用の画面を仮定しよう。担当者は、交換品を顧客の従来の住所へ発送する提案を確認している。在庫情報を読んでいる間に、別の会話で届け先が更新され、エージェントが発送カードを描き直した。担当者は、すでに押そうとしていたボタンを押す。

各項目はすべて有効で、担当者も発送権限を持っているかもしれない。それでも、旧住所を承認したのか、新住所を見て受け入れたのかは別途判断する必要がある。最新のフォーム状態をその答えにすれば、システムが人の意図を解釈したことになる。画面を無期限に固定する方法にも問題がある。すでに実行できない案を、担当者が安心して承認するかもしれないからだ。

A2UIのアクション文書では、イベントのコンテキストに固定値や現在のデータモデルから取得する値を使える。これはイベントのデータを用意する仕組みであり、利用者が何を理解したかはアプリ側の課題として残る。アクション文書。

この違いは検収にも関係する。バックエンドに届く住所が画面と一致すると証明しても、クリック直前の変更を見落とす可能性がある。難しいのは、システム各層の同期が完全でも、人の理解が追いついていない場合だ。

値自体が変わらなくても、表示方法の問題は残る。同じ仮定で、作業用カードには住所の省略形だけが表示され、確認用カードには完全な届け先が表示されるとしよう。確認前には対象を区別できる詳細を見せる必要がある。同じ場所に複数の人がいるなら受取人も重要だ。変更項目を強調しても、ラベルから業務上の意味が分からなければ役に立たない。内部IDは処理を正しく結び付けても、人の判断材料にはならない場合がある。逆に内部項目をすべて表示すれば、重要な数項目が埋もれる。確認画面では判断に必要な情報を意識的に選び、残りも参照できるようにしたい。この選択は製品側が担うべきであり、コンパクトな配置を求めるエージェントの裁量だけに任せるべきではない。

確認対象の案に業務上の識別子を持たせる

本稿が提案するのは、動作を続ける画面と、確認対象の案を分ける設計だ。エージェントは引き続き検索し、提案できる。一方、実際の結果を伴う確認段階に入ったら、アプリは識別子、改訂版、明示した業務条件を持つ案を作る。確認操作は、入れ替わり得るリスト内の位置やボタンの文言ではなく、その案を指すようにする。

続いて、正式な業務サービスが実行可能性を確認する。この例なら、届け先、商品、配送の約束は判断の条件に含まれる。カードの色や説明文の並びは通常含まれない。重要条件が変わった場合は差分を示し、新たな判断を求める。その際、影響を受けていない入力は残し、フォーム全体を消さない方がよい。理由のない「再試行してください」より、何が変わったかを説明する方が役に立つ。

A2UIの仕様は、双方向バインディングがクライアント内で行われ、入力の送信はアクションを契機とすると説明している。表示項目と永続化された業務記録は、アプリ設計で別々に考慮する必要がある。プロトコル文書。

既存技術にも使える要素がある。HTTPのIf-Match事前条件は、エンティティタグの一致を更新の条件にできる。RFC 9110。ここで条件付き更新を使うというのは本稿の設計上の推論であり、チュートリアルがその機能を実装済みという意味ではない。タグが守るのは、それが表すリソースだけだ。住所と在庫が別サービスにあるなら、画面の版を確認するだけでは両方の有効性を保証できない。業務サービスには、一貫した検証・確定の境界、または期限を明確にした資源の予約処理が必要になる。

どの変更なら利用者を止めるべきか

再確認にも負担がある。更新のたびに中断させると、担当者が通知を読み飛ばすようになるかもしれない。中断が少なすぎれば「確認済み」の意味が薄れる。製品チームは結果に責任を持つ人とともに、その仕事の言葉で重要な変更を定義する必要がある。

交換品の発送なら、新しい届け先への配送が速くても、再確認が必要かもしれない。一つの面で改善しても、別の面での同意が得られたことにはならない。反対に、実際の指示が同一なら、内部説明の誤字修正で再承認を求める必要はない場合もある。これらは本稿が示す製品方針の選択肢であり、UIプロトコルに組み込まれた普遍的な規則ではない。

並行する作業も読み取れるようにしたい。例えば、新しく届いた未確認の提案と、いま検討している案を区別する。別の担当者が元の案件を変更したら、最初の担当者には確定前に具体的な衝突を示す。「更新中」という表示だけでは、ボタンを押せるまま操作の意味が変わる場合の保護は弱い。

描画だけでなく判断過程を検収する

受け入れテストでは、閲覧中、キーボード操作中、送信中に重要条件を意図的に変えてみる。メッセージの遅延、提案の並べ替え、別の担当者による同時編集も対象にする。正解が常に処理の停止とは限らない。判断条件が変わっていなければ、不要な繰り返しを求めず進められるべきだ。

役立つ記録は、確認した案、利用者の操作、結果としての業務処理を結び付ける。適切な保存方針に従い、その関係を再構成できる情報を残す。画面全体の画像や会話全文が必ず必要だと決めつける必要はない。クリック記録だけでも、APIの成功応答だけでも、利用者が受け入れた条件は十分には分からない。

引用した文書からは、この不一致が本番環境でどれほど起きるかも、特定の実装に問題があるかも判断できない。読み取れるのは、いま検討すべき設計上の問いだ。エージェントが人の判断する画面を組み立てるようになるほど、いつ画面を変更してよいか、どの変更で元の判断が無効になるか、最終処理を実際に確認された条件へどう結び付けるかを、チームが明確にする必要がある。