画面は見えるのに、意味が届かない——AIエージェント向けUIを考える論文
人には見えるのに、AIエージェントには操作の意味が届かない——そんなウェブ画面をどう直すか。論文「Affora」の実験から、人間とエージェントが同じUIを使うための設計を考えます。
人には見えるのに、AIエージェントには操作の意味が届かない——そんなウェブ画面をどう直すか。論文「Affora」の実験から、人間とエージェントが同じUIを使うための設計を考えます。
📑 目次
ボタンを置いた。ラベルも付けた。見た目も整っている。
それなのに、AIエージェントは押せない。
こういう場面、これから増えそうです。人間には「ここを押せば保存」とすぐわかるのに、エージェントが受け取る画面の情報には、ボタンの名前も、選べる項目も、押したあとの状態も残っていない。画面が見えることと、操作の意味が読めることは、同じじゃないんですよね。
ふむふむ。この違和感を、UIの設計問題として正面から調べた論文が出ています。今日は、2026年9月16日にarXivへ投稿された「Affora: A Design System for Agent-Friendly Interfaces」を、サクッと覗いてみます。
UIには「塗る層」と「宣言する層」がある
Afforaを書いたのは、サンフランシスコの独立研究者、ジン・ガオさんです。論文の中心にある考え方は、とてもシンプルでした。
UIには、二つの層がある。
- 塗る層:色、文字、形、余白、配置、動き。人が画面から受け取る見た目
- 宣言する層:どれが操作できるか、名前は何か、何を選べるか、いま何が起きているか。機械が読み取れる構造
人間は、見た目と経験から「これはボタン」「この表示は保存完了」と補えます。でもエージェントは、DOMやアクセシビリティツリー、画像など、与えられた観測経路から操作対象を探します。見た目の雰囲気が、機械側の表現にそのまま届くとは限りません。
チカちゃん的には、レストランのメニューに似ていると思いました。人間なら写真を見て「これは辛そう」と想像できます。でも、料理名も値段も注文方法も書かれていなければ、注文を任された人は困ります。おしゃれな盛り付けと、注文に必要な情報は、別の仕事なんです。
まず、部品を変えると成功率が変わった
Afforaの最初の実験では、60種類の操作部品を、素のHTMLと8つのUIコンポーネントライブラリで実装して、同じタスクをエージェントに任せました。
結果は、見た目が同じような部品でも、実装によって成功率が変わりました。素の意味的なHTMLは91%。一方、8つのライブラリは68.3〜86.7%の範囲です。これは「ライブラリは悪い」という話ではありません。人間向けに便利な抽象化が、画面を描画したあとも、機械に必要な名前・状態・選択肢を保っているとは限らない、という話です。
さらに、壊れた部品を段階的に直す実験もありました。意味的な構造だけを直すと成功率は43%から67%へ。そこに、エージェントが必要とする選択肢と状態を明示すると90%まで上がりました。
ここ、面白いところです。
「ボタンに名前を付ける」だけでは足りない。押せること、いま選ばれていること、押した結果が何だったか——操作の前後まで残って、はじめて画面が仕事を伝えられる。UIは静止画ではなく、小さな状態機械として読まれているんですね。
見た目は、かなり自由に変えられる
では、デザインの自由は奪われるのでしょうか。
ちょっと待ってください。Afforaの二つめの実験は、むしろ逆の方向を示しました。意味のある構造を固定したまま、5つの部品を16種類のテーマ、6種類のレイアウトで見せ方だけ変えたんです。
DOMを読む観測では、完了率は99.5%。画像を読む観測でも92%で、標準的な見た目の94%と大きく離れませんでした。視覚的な手がかりを弱めたり強めたりする追加実験でも、完了率は98.7〜99.8%の範囲で、手がかりを強くすれば一直線によくなる、という結果にはなりませんでした。
ただし、ここは数字だけを持ち帰らないほうがよさそうです。画像を読むエージェントには、操作対象を列挙して示す仕組みも使われていました。画面の生画像だけを見て、どこを押すか自力で探すエージェントに、そのまま一般化はできません。
それでも、示唆はあります。
意味の層を壊さなければ、見た目の層はかなり遊べる。
これは、デザイナーにとってうれしい話です。エージェント対応という言葉から、すべての画面を無機質な表にしなければいけない未来を想像しなくてもよさそうです。色も、余白も、形も、世界観も残せる。その下に、操作の意味をちゃんと置いておく。
人間向けの「定石」は、そのまま移らない
三つめの実験では、人間向けのインタラクション設計でよく知られた7つの原則を、エージェント向けに試しました。3つのモデルと2種類の観測経路で、タスクの成功率や操作コストを比べています。
見えてきたのは、原則がそのまま正解になるわけではない、ということでした。
- 失敗したときに、次の対処を明示する設計は役に立つ
- 追加の確認画面は、試したタスクでは操作コストを増やした
- フォームを何段階にも分けても、成功率の改善は確認できず、操作コストが増えた
- 無効になった理由の説明は、実験をまたいで一貫した効果を示さなかった
これは「確認画面はいらない」という結論ではありません。送金や削除のように、人間の安全確認が重要な場面はあります。論文自身も、ここで測ったのは観測されたタスク行動であって、人間の認知負荷や安全上の価値ではない、と慎重に書いています。
人間にとっての確認は、「本当にこれでいい?」と立ち止まる装置です。エージェントにとっては、すでに同じ状態を読んでいるのに、もう一度同じ場所を通るだけになる場合もある。読者が変われば、同じ設計の意味も変わるんですね。
Afforaが提案する、五つの設計ルール
論文が実験からまとめた方向性は、次のようなものです。
- 操作・選択肢・状態・結果を、明示的かつ持続的に置く
- 人に見える構造と、機械が読める構造をそろえる
- ホバーや展開の前に、計画に必要な情報を見つけられるようにする
- 部品、画面、ページをまたいでも、意味の対応関係を保つ
- 意味を保つかぎり、色・文字・形・配置は柔軟にする
追加の評価では、Afforaを適用した画面が、基準の画面よりタスク完了率を上げたケースもありました。作者が作ったリリース作業の画面では、成功した組み合わせに限ると、操作数が約21〜40%、全体のトークン使用量が約24〜41%減っています。
ただし、ここも安全柵を置いておきましょう。各条件の成功した組み合わせは1〜2件ほどで、論文自身が「このワークフローでの予備的な証拠」と位置づけています。どんなサイトでも同じ割合で軽くなる、という話ではありません。
チカちゃん的には——AI対応は、画面を二つに割ることじゃない
AIエージェント向けの設計と聞くと、人間用の画面に加えて、機械だけが使う別の操作口を用意する発想になりがちです。APIやコマンド、専用ツールは、とても効率的なことがあります。Afforaも、それらを否定していません。
でも、この論文が拾っているのは、別の価値です。
機械が操作できることと、人間が何が起きたか確かめられることを、同じ画面の上で両立できないか。
「保存しました」という一瞬の通知だけでなく、何が保存され、何が未完了で、どこから戻れるのかを残す。これはエージェントのためだけでなく、速く動くソフトウェアを人間が監督するためにも大切そうです。論文では人間の利用実験まではしていないので、ここは設計上の含意として受け取るのがよさそうですが。
なるほどねえ。エージェントにやさしいUIとは、機械に人間のふりをさせるための化粧ではなく、画面の意味を隠さないUIなのかもしれません。
ただ、反対側の見方もあります。いま見えている画面に情報を足し続けると、人間にはかえって騒がしくなることがある。すべてを常時表示すればよいわけではありません。Afforaの実験も、ウェブの管理画面や通販画面、小さめから中くらいのモデル、比較的短いタスクが中心です。人間の使いやすさ、信頼感、長い仕事の流れまで確かめたわけではありません。
だから、チカちゃんの持ち帰りは「AIのために画面を作り替えよう」ではなく、もう少し小さく。
このボタンは、機械が名前を読めるか。選べるものは、操作前からわかるか。押したあとの状態は、あとから確かめられるか。
この三つを見直すだけでも、UIは少し静かに、でも強くなる気がします。
あなたが最近触った画面には、人には見えているのに、意味がどこにも残っていない操作がありませんでしたか。もしエージェントに渡すなら、まず何を「宣言」してあげたいでしょう。
答えを急がなくても大丈夫です。画面の下にある意味を覗き込むと、まだ見えていなかった設計の冒険が始まるので。
参考URL
Jin Gao, Affora: A Design System for Agent-Friendly Interfaces(arXiv:2609.19125, 2026)→ https://arxiv.org/abs/2609.19125
論文PDF → https://arxiv.org/pdf/2609.19125
本記事は査読前のプレプリントをもとにした紹介です。本文中の数値は、論文に記載された特定のモデル・観測経路・タスク条件での実験結果であり、すべてのUIやAIエージェントにそのまま当てはまる保証はありません。導入や設計判断の前に、原論文と実装条件を確認してください。
思索は冒険です。今日の話も、その入口のひとつでした。
- インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃(サプライチェーン攻撃)が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
- AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。