AI エージェント時代の UI に、ずっと違和感を持っていた
こんにちは。 Legalscape でエンジニアをしている kazukitash です。
最近、AI エージェントが担うタスクの幅が広がってきています。担えるタスクは検索、要約、調査、下書きなど多岐に渡り、私たちが取り組んでいる Legal Research 領域の業務でも「AI に聞く」こと自体は特別な行為ではなくなりつつあります。
一方でずっと気になっていることがあります。それは、 人間と AI エージェントの協調が前提となりつつあるのに、UI がその変化に追いついていない という感覚です。
多くの AI プロダクトでは、いまだに
- 質問を投げる
- テキストの回答が返ってくる
という一問一答型の体験が主流です。もちろん便利です。ただ、この体験にはどこかで限界を感じ始めています。
一問一答型 UI では、物足りない
法務の調査や検討は、単に「答え」を知ることがゴールではないと聞いています。
- どんな要件に分解できるのか
- どの要件が争点になりそうか
- それぞれに、どんな根拠があるのか
- どの前提が足りていないのか
こうした 思考の途中経過そのもの が重要で、それがそのまま成果物になることも少なくありません。
ところが、従来の一問一答型 UI では、
- 要件分解は文章中に埋もれ
- 根拠は段落の一部として消費され
- どこが確定で、どこが仮なのかも曖昧なまま
最終的に「答え」だけが提示されてしまいます。
「この結論は、どの前提に依存しているんだっけ？」
「この要件は、どこからきた話だっけ？」
後から振り返ろうとすると、また初めから読み直す必要があります。
AI と「一緒に考える」体験が、まだ UI になっていない
ここで感じるのは、AI の能力不足というよりも UI の役割不足です。
AI はすでに、
- 論点を洗い出し
- 要件を分解し
- 不足している情報に気づき
- 仮の結論を条件付きで示す
ところまでできるようになってきています。それなのに UI は、それらを 全てテキストに押し込めて返す ことしかできていません。
本来やりたいのは、
- 人と AI が一緒にコンテキストを作り上げ
- その過程自体が構造化され
- 途中で人が介入し、判断を差し込めて
- 最後に「成果物」として残る
こんな体験のはずです。 AI エージェントが活躍する時代だからこそ、AI と人が一緒に考えることができる UI が必要なのではないか。 そんな違和感がずっとありました。
いま欲しいのは「綺麗な画面」より「状況の構造」
では、「AI と一緒に考え、途中で人が介入でき、成果物として残る UI」はどうやって実現すれば良いでしょうか？ 初めに思いつくのは今ある UI の延長線で、フォームやタブ、モーダルを増やしたり、ステップ UI を導入したりすることかもしれません。ただ、これでは問題にぶつかります。
AI エージェントは途中で計画を変えます。前提が崩れたら、問いの立て方自体を変えます。その度に UI の構造を変え、
- どの画面を出すのか
- どの入力を求めるのか
- どこで止めるのか
を 人が事前に全て設計する のは現実的ではありません。
自律性ではなく介入設計が必要だった
2025 年 5 月、Microsoft Research のチームが発表したブログ記事 「Magentic-UI, an experimental human-centered web agent」 は、この問題に対する 1 つの答えを示しています。
Magentic-UI は、AI の自律性を最大化して賢いエージェントを作る話というより、 人が途中で介入できる形で AI エージェントを賢く動かすには何が必要か を UI とインタラクション設計のレイヤーで議論しています。実際、ブログでは低コストに人の関与をするための仕組みとして co-planning ・ co-tasking ・ action-guards などを明示的に整理しています。
Magentic-UI は、 UI 設計に焦点を当てる という視点を提示しました。この流れが大事だと思うのは、ここで問題設定が切り替わっているからです。
従来：「エージェントをどこまで自律化できるか」を考える
Magentic-UI：「人がどこで止め、どこで直し、どこで承認するか」を設計対象にする
つまり、 AI エージェントの自律性を前提としつつ、人が介入できるポイントを設計することも重要 だということです。
AI エージェントは UI を画面として送る必要があるのか？
では、具体的にどうやって「人が介入できる UI」を実現すれば良いのでしょうか？
すぐに思いつくのは、AI に画面をその場で作らせることです。生成 AI が登場した当初からこの考え方はありました。「生成 AI による新しい UI/UX ~ Generative “UI” の世界観を感じよう ~ | AWS」 確かに表現力は高いし、状況にも追従できます。でも業務で使うとなると、当然不安が出てきます。
- その UI は安全か？
- そのボタンは押していいのか？
- 重要な判断が勝手に確定していないか？
- あとから監査・説明できるか？
UI が「コード」になると、統制と検証が難しくなる。ここは法務ドメインだと特にシビアです。
ここで一度、問いを置き直します。「人が介入できる UI」とは何でしょうか？
人が本当に欲しいのは、綺麗に整形された画面ではなくて、
- 今どこを検討しているのか
- 何が未確定で、何が確定なのか
- どこで人の判断が必要なのか
という 状況の構造 です。
それをたまたま「画面」という形で見ているだけで、必要なのはむしろそれに「内在しているデータ構造」のほうかもしれない。
この発想に近い回答として出てきたと感じているのが A2UI（Agent-to-UI） です。
A2UI：エージェントが送るのは「実行可能な UI」ではなく「宣言的なデータ」
A2UI is a declarative data format, not executable code.
Introducing A2UI: An open project for agent-driven interfaces - Google Developers Blog
A2UI は、エージェントが UI を送るときに 実行可能な UI コードではなく、宣言的なデータ を送るためのプロトコルです。
A2UI のコア思想
A2UI のコア思想は、だいたい次の 3 つに集約できます。
- (1) Security first：生成 UI は「コード」ではなく「データ」
- (2) LLM-friendly：ストリーミング前提で「作りやすい形」
- (3) Framework-agnostic：UI 構造と実装を分離する
(1) Security first：UI を「コード」ではなく「責任境界」として扱う
A2UI は UI を 検証可能なデータ として扱います。
- エージェントが使える UI 部品は、クライアントが定義した 許可リスト（Catalog） に限定
- 実際に描画・操作可能にするかどうかの最終判断は 常にクライアント側（Renderer）
つまり A2UI は、 「AI が UI を作る」のではなく、「AI が UI の構造を宣言する」 という責任分離を明示的に設計に組み込んでいます。
(2) LLM-friendly：ストリーミング前提で「作りやすい形」
A2UI は LLM が逐次生成すること を前提に設計されています。
- UI は一括生成ではなく、段階的に組み立てられる
- 途中で構造を変えたり、一部だけ更新できる
- 人の介入を受けて、その結果を即座に反映できる
この設計によって、「途中で考えが変わる AI」と「途中で止めたい人」 が同じ UI を共有しながら思考を進められるようになります。
(3) Framework-agnostic：UI 構造と実装を分離する
A2UI でエージェントが送るのは、あくまで 抽象的な UI 構造 です。それを React で描くか、Flutter で描くか、SwiftUI で描くかはクライアント次第です。
この分離によって A2UI は、
- 特定フレームワークに縛られず
- UI の責任をエージェントに渡しすぎず
- 同じ構造を複数環境で再利用できる
という性質を持つことになります。
A2UI の仕様概要
上記の思想を実現するために、A2UI では UI を JSON オブジェクトのストリーム として server → client に送ります。
メッセージは大きく次の 4 種類に分かれています。
- createSurface：新しい UI の表示領域（Surface）を作り、描画を開始する
- updateComponents：UI の構造（Component ツリー）を追加・更新する
- updateDataModel：UI に流し込む状態（値・前提・選択結果など）を差分更新する
- deleteSurface：その Surface を破棄する
重要なのは、構造（Component）と状態（Data Model）が分離されている 点です。これにより、
- 見た目は保ったまま、前提や値だけを更新できる
- 計画変更に合わせて UI 構造を差し替えられる
- 人の介入結果が UI に即座に反映される
といった、「一緒に考える」体験を支える振る舞いが可能になります。
チャットのように情報が流れて消えるのではなく、 UI が構造として残り続けることで、コンテキストそのものが作業スペース になるのです。
UI は「操作面」から「責任の境界」へ
Magentic-UI の考え方と A2UI の設計を組み合わせると、 AI エージェント時代の UI は、ボタンや画面の集合ではなく 人と AI の責任境界を表現するもの として捉え直すことができました。これは Microsoft Design の UX design for agents でも強調されている以下の考え方を補完するものだと言えます。
Transparency, control, and consistency are foundational elements of all agents
- 透過性：AI が「何をしているか」が、UI から分かる
- 制御：止められる、選べる、責任を持てる
- 一貫性：どの画面でも、同じ UI パターンで判断できる
AI エージェントが当たり前になるにつれて、人に任せる部分と AI に任せる部分、UI の設計は難しくなっていくと思います。
その境界を、コードではなく 体験として設計する。A2UI は、その一つの方法になると考えています。
Legalscape でも、まさにこの問いに向き合いながら、AI エージェントと UI の設計を進めています。
- どんな体験がよかったか
- どこで不安を感じたか
- どんな介入点が欲しかったか
そうした声を拾い上げ、AI エージェント時代の UI を、これから作っていきたいです。
Legalscape では、この記事で紹介したような最新の技術動向を継続的に追いかけ、実際のプロダクトに取り入れる試みを続けています。そういった試行錯誤を楽しめるエンジニアと一緒に働きたいと考えています。もしこの記事を読んで、最先端の技術を追いかけながらプロダクトを作ることに興味を持っていただけたなら、ぜひ Legalscape で一緒に挑戦してみませんか。
