フロントエンドの相手が変わった - AIが加わったWebの新しいインターフェース設計

Embed

Start on current slide

Slide 1

Slide 1 text

F R O N T E N D C O N F E R E N C E N A G O Y A 2 0 2 6 フロントエンドの相手が変わった AIが加わったWebの新しいインターフェース設計人間と AI が協業する UI へ azukiazusa

Slide 2

Slide 2 text

自己紹介 azukiazusa ▸ Frontend Engineer ▸ https://azukiazusa.dev ▸ 週に 1 回、Web 開発と AI の記事を書いています ▸ FE（フロントエンド | ファイアーエムブレム）が好き ▸

Slide 3

Slide 3 text

あなたのフロントエンドの "相手" は誰ですか？従来のフロントエンドの仕事は、人間とシステムの間のインターフェースを作ることだった ▸ ところが 2023 年以降、AI が Web のコンテンツを読んで、生成して、操作するようになった ▸ つまり Web の相手に AI が加わった ▸

Slide 4

Slide 4 text

2つの AI PRODUCER 出力者の AI CONSUMER 消費者の AI チャットで応答を生成する ▸ ユーザーが理解・操作しやすいような UI を返す ▸ コンテンツを生成する ▸ 正確な応答を生成するために、 Web の情報にアクセスする ▸ ユーザーのタスクを完了するために、Web アプリを操作する ▸

Slide 5

Slide 5 text

P A R T 1 AI は Web の「出力者」になった

Slide 6

Slide 6 text

チャット型 UI の台頭 AI の普及により、チャット型の UI を設計する機会が増えた → これまでの「リクエストを送って完成したレスポンスを受け取る」UI から「途中経過をリアルタイムに描画し続ける」 UI へストリーミング処理が日常になった ▸ 待機状態の UX ▸ 入力フォームの設計（IME の確定で送信しない、など） ▸

Slide 7

Slide 7 text

ストリーミング UI は何を変えたか途中経過をどう見せるかの体験設計が必要になった ▸ 応答をそのまま出力すると機械的に見えるので、バッファリングしたり、表示のアニメーションをつけたりする工夫が必要 ▸ マークダウンを素朴にパースすると、不完全な構文で表示が崩れる恐れがある ▸ 自動スクロールの挙動（ユーザーが過去のメッセージを読んでいるときは自動スクロールを止める、など） ▸ アクセシビリティ上の観点（ストリーミングで逐次追加されるメッセージをスクリーンリーダーにどう伝えるか） ▸

Slide 8

Slide 8 text

Generative UI という潮流 AI が会話の中でテキストではなくUIを返す設計 ▸ チャット応答が「読むもの」から「操作するもの」へ ▸ 実装は一つではない — MCP Apps / A2UI など複数の規格が並行 ▸ まずは Anthropic が提案した MCP Apps から見ていく ▸

Slide 9

Slide 9 text

MCP Apps の登場 MCP Apps は、AI がテキストだけでなくインタラクティブな UI 会話の中で返せるようにする仕組み ▸ 右の例では、ホテルの一覧がチャットの中にカード形式で表示されていて、そのまま予約の操作もできる ▸ ポイントは、UI が入口ではなく、必要な瞬間に差し込まれる部品になったことと、チャット画面でそのまま操作できる体験が提供されること ▸

Slide 10

Slide 10 text

なぜテキストだけでは足りないのかチャットは説明には強いが、比較や選択や確認には向かない場面がある ▸ 単にデータを眺めるよりも、グラフで推移を眺めたほうがわかりやすいことは一目瞭然 ▸ テキストのチャットは一方向の情報伝達であった ▸ MCP Apps ではユーザーのクリックや入力などの操作を受け付ける双方向のインターフェースが提供される ▸ 会話から離れずに操作する体験が求められている ▸ コンテキストを保ったまま操作できる UI を差し込めるのが MCP Apps の強み ▸

Slide 11

Slide 11 text

MCP Apps のコード例まず ui:// から始まる URI でリソースを登録する registerAppResource( server, "ui://dashboard", "Sales Dashboard", { mimeType: RESOURCE_MIME_TYPE, _meta: { ui: { csp: { resourceDomains: ["https://cdn.example.com"], connectDomains: ["https://api.example.com"], }, }, }, }, async () => ({ contents: [ /* built HTML */ ],

Slide 12

Slide 12 text

MCP Apps のコード例ツール定義の _meta.ui.resourceUri からそのリソースを参照する server.tool( "show_dashboard", { description: "売上データをダッシュボードで表示する", _meta: { ui: { resourceUri: "ui://dashboard", }, }, }, async (params) => { // ツールのレスポンスは UI に渡されるので、UI 上でデータを表示できる return { data: await fetchSalesData(params) }; }, );

Slide 13

Slide 13 text

MCP Apps でインタラクションを実行する import { App } from "@modelcontextprotocol/ext-apps"; const app = new App(); button.addEventListener("click", async () => { const response = await app.callServerTool({ name: "purchase-product", arguments: { productId: "sku_123", quantity: 1, }, }); const message = response.content?.find((c) => c.type === "text")?.text; if (message) status.textContent = message; }); App はユーザー操作を受けて再度ツールを呼び出せる ▸ app.callServerTool(...) で商品を購入するツールを呼び出す例 ▸

Slide 14

Slide 14 text

設計思想の変化 UI は入口ではなく、必要な瞬間に差し込まれる部品になる ▸ チャットの中でデザインを統一しつつ、破綻しないような UI を提供する必要がある ▸ 既存のデザインシステムもこの文脈でどう活かせるかを考える必要がある ▸ 人間の判断が必要な瞬間にはテキストではなく UI が必要 ▸ AI に UI を作らせたいが、その UI を安全に表示・操作するにはどう設計すべきか？ ▸ MCP Apps は HTML を iframe に埋め込むサンドボックスアプローチでこの問題に答えている ▸

Slide 15

Slide 15 text

ホストごとに異なるテーマへの対応 MCP Apps は標準化された CSS カスタムプロパティを用意している /* 仕様が定める CSS 変数をそのまま使う */ .card { background: var(--color-background-primary); color: var(--color-text-primary); border: 1px solid var(--color-border-primary); font-family: var(--font-sans); } ホストが light / dark / ブランドごとの値を注入する ▸ App 側は変数を参照するだけで、ChatGPT でも Claude でも「その場に馴染む」 UI になる ▸ 仕様は意図的に色・タイポグラフィ・境界線に限定し、spacing は含めない ▸

Slide 16

Slide 16 text

Agent が UI を返す方法は MCP Apps だけではない MCP Apps は HTML を iframe に埋め込むアプローチ → ホスト側のサンドボックス前提で表現力を確保する一方で、「宣言的な JSON を返す」という別解もある AI は HTML ではなく、コンポーネント spec の JSON を生成する ▸ ホスト側がそれをネイティブ部品として描画する ▸

Slide 17

Slide 17 text

レイヤーが異なる 2 つの代表例 A2UI (Google) — プロトコル。何を、どんな JSON で送るかの仕様 ▸ json-render (Vercel Labs) — フレームワーク。schema-agnostic なので A2UI 形式にも適用可能 ▸

Slide 18

Slide 18 text

A2UI — Google Agent と UI の間の通信プロトコル AI が返す JSON のメッセージ形式と意味論を定義する ▸ 描画側の実装は問わない — React / Angular / Flutter / ネイティブで同じ JSON が動く ▸ LLM がインクリメンタルに生成しやすいフラットな構造 ▸ 完成 JSON を待たずにストリーミングで部分描画できる ▸

Slide 19

Slide 19 text

A2UI のメッセージ例 (v0.9 draft) Agent はフラットな JSON で UI を記述する { "version": "v0.9", "createSurface": { "surfaceId": "reservation", "catalogId": "basic" } } { "version": "v0.9", "updateComponents": { "surfaceId": "reservation", "components": [ { "id": "root", "component": "Column", "children": ["header", "submit"] }, { "id": "header", "component": "Text", "text": "Book Your Table" }, { "id": "submit", "component": "Button", "label": "Reserve", "action": { "name": "submit_reservation" } } ] } }

Slide 20

Slide 20 text

json-render — Vercel Labs (フレームワーク) JSON 形式の記述から、React / Vue / Svelte など様々な環境の UI を描画するフレームワーク ▸ LLM が JSON を出力するだけでアプリの UI を生成できるようにするのが狙い ▸ 開発者がコンポーネントカタログ (Zod スキーマ) を定義して AI を制約する ▸

Slide 21

Slide 21 text

json-render の 4 つのステップ開発者がカタログ (Zod スキーマ) を定義 ▸ カタログにマッピングするコンポーネントを実装 ▸ AI がカタログ準拠の JSON をストリーミング生成 ▸ JSON を元に React コンポーネントとして描画 ▸

Slide 22

Slide 22 text

json-render のコード例カタログを Zod で定義する export const catalog = defineCatalog(schema, { components: { Card: { props: z.object({ title: z.string() }), slots: ["default"] }, Metric: { props: z.object({ label: z.string(), value: z.string() }) }, }, actions: {}, });

Slide 23

Slide 23 text

json-render のコード例カタログにマッピングするコンポーネントを実装 import { defineRegistry, Renderer } from "@json-render/react"; const { registry } = defineRegistry(catalog, { components: { Card: ({ props, children }) => (

{props.title}

{children}

), Metric: ({ props }) => (

{props.label} {props.value}

), },

Slide 24

Slide 24 text

json-render のコード例 { "root": "card-1", "elements": { "card-1": { "type": "Card", "props": { "title": "Revenue" }, "children": ["m1"] }, "m1": { "type": "Metric", "props": { "label": "Total", "value": "$48,200" } } } } カタログと仕様を AI のシステムプロンプトとして与えるて JSON を生成させる ▸ AI が生成する JSON はカタログに完全に拘束される ▸

Slide 25

Slide 25 text

json-render のコード例 AI が生成する JSON をで描画する

Slide 26

Slide 26 text

よく見られる言説 UI は AI が全部作ってくれるから、フロントエンドエンジニアはもういらない。バックエンドエンジニアを目指そう。

Slide 27

Slide 27 text

AI が登場したことで考えるべきことが増えているストリーミング UI のユーザー体験設計/MCP Apps の UI 設計など ▸ AI は技術的に UI を生成できるが、体験設計は依然として人間が担う領域 ▸ 人間と AI のブラウザの操作の仕方は大きく異なる ▸ フロントエンドはユーザー体験を形作る役割がある ▸

Slide 28

Slide 28 text

P A R T 2 AI は Web の「消費者」にもなった

Slide 29

Slide 29 text

クローラと AI エージェントの違い Web には以前からクローラという「人間以外の消費者」がいたしかし AI エージェントは振る舞いが違うクローラ AI エージェント目的インデックス作成タスク遂行行動読み取り読み取り + 操作理解構造的（DOM をパースしてコンテンツを抽出）意味的（レンダリングされた内容を理解して判断）コンテンツの冗長性が与える影響小さい大きい（コンテキストウィンドウを圧迫すると性能が落ちる）

Slide 30

Slide 30 text

AI が Web を読むための工夫が必要にエージェントフレンドリーなウェブサイトを構築する | web.dev AI はスクリーンショットや DOM、アクセシビリティツリーを利用してコンテンツの意味構造を理解する ▸ セマンティック HTML の重要性 ▸ これは今までと変わらない ▸ コンテキストウィンドウを圧迫しない → 単に情報が欲しいだけであれば、装飾のための構造はノイズになる ▸

Slide 31

Slide 31 text

コンテキスト効率の良い配信が重視される AI にとっては、複雑な装飾付き HTML より Markdown のほうが読みやすい場面が多い ▸ Web サイトが Markdown 版を返す動きが出てきた ▸ Cloudflare も Markdown for agents を公開し、エージェント向けの配信を提案している ▸ Accept: text/markdown ヘッダを送ると、AI にとってコンテキスト効率の良い Markdown 版が返る ▸

Slide 32

Slide 32 text

llms.txt という慣習 Web サイトが AI 向けに「読むべき場所」を案内する Markdown ファイルサイトのルートに /llms.txt (目次) と /llms-full.txt (全文) を置く ▸ 採用が進む開発者向けドキュメント ▸ Anthropic / Vercel / Cloudflare / Stripe / Cursor / Supabase ▸

Slide 33

Slide 33 text

AI がコンテンツを効率よく理解するための工夫は早期から行われていたが、操作のためのインターフェースはまだ発展途上

Slide 34

Slide 34 text

WebMCP の提案

Slide 35

Slide 35 text

WebMCP は Web アプリをツール化する WebMCP は、Web アプリがブラウザ上で AI から呼び出せるツールを公開する仕組み ▸ AI はスクリーンショット解析やコードによる DOM 操作ではなく、意味を持った関数を通じて操作できる ▸ 余分なコンテキストを与えず、AI にとって必要な情報だけを渡すことができる ▸ 前提は human-in-the-loop ▸ AI が完全に自律的に動くのではなく、人間と協業することを前提とした設計 ▸

Slide 36

Slide 36 text

WebMCP のコード例 window.navigator.modelContext.registerTool({ name: "add-todo", title: "Add todo", description: "Add a new todo item to the list", inputSchema: { type: "object", properties: { text: { type: "string" } } }, execute: async ({ text }) => { // addTask は JavaScript 関数で、UI 上のタスク追加と同じロジックが走ると想定 addTask(text); return { content: [{ type: "text", text: `Added todo: ${text}` }] }; }, }); window.navigator.modelContext.registerTool でツールを提供する ▸ 例えば、Todo アプリが「タスクを追加する」ツールを提供するコード例 ▸

Slide 37

Slide 37 text

宣言的にツール化できる Add Todo WebMCP ではフォームに属性を付けるだけでツール登録できる提案もある ▸ AI ツールを呼び出すとフォームに自動で値が入力される ▸ Submit ボタンを押すのは人間が担う ▸

Slide 38

Slide 38 text

実行例

Slide 39

Slide 39 text

従来の MCP ツールや API と何が違うのか単に AI にツールを使わせるだけなら MCP ツールでいい ▸ それでも WebMCP が必要なのは、人間と AI が同じインターフェース上で協業するから ▸ 使いなれたダッシュボードを眺めながら、AI に必要な操作だけを任せたり、データを要約してもらうという流れが自然にできる ▸ 既に多くの企業が Web を通じてサービスを提供しており、既存の資産を再利用できるというメリットも大きい ▸ ブラウザに既にあるセッション Cookie / SSO の恩恵をそのまま利用できる ▸

Slide 40

Slide 40 text

AI 向け対応とアクセシビリティは地続き → 新しいスキルが必要なのではなく、アクセシビリティという Web の基本が生きてくる WebMCP の仕様書でも「much of the challenges faced by assistive technologies also apply to AI agents」と明記されている ▸ Web を視覚情報なしにどう理解し、操作するかという点で、AI エージェントとスクリーンリーダーは本質的に同じ問題を解いている ▸ 「支援技術のためのインターフェース」を考えるスキルセットが、そのまま「AI のためのインターフェース」に転用できる ▸

Slide 41

Slide 41 text

AI が生成する時代の説明責任 AI が生成したコンテンツは、誤情報や偏見を含む可能性がある ▸ AI はコンテンツを大量に生成できるため、よく検証されていない情報が大量に投稿されるという問題も出てきた ▸ Web コンテンツの制作者として、AI の関与を明示することが求められている ▸

Slide 42

Slide 42 text

ai-disclosure 属性の提案

本誌の独自調査では...

AI要約

レポートの結論は...

AI の関与度を HTML で宣言 ▸ 例えばニュースサイトでは、人間が書いた調査報道と AI 生成のサマリーが混在する可能性がある ▸ ai-disclosure 属性を使ってどの部分が AI 生成なのかを明示することができる ▸

Slide 43

Slide 43 text

C O N C L U S I O N 「The Web is for everyone」の再解釈

Slide 44

Slide 44 text

everyone に AI が含まれた "The Web is for everyone" — Tim Berners-Lee スクリーンリーダーに情報を伝えたり、身体に障害がある人が操作できるようにするのと同じように、AI にも情報を届けたり、発信する基盤を作ることが求められるようになった → アクセシビリティと同じ考え方すべての人が自由かつ平等にアクセスし、利用できる開かれた基盤であるべきだという考え方 ▸ この理念は変わっていない「everyone」の範囲が拡張された ▸

Slide 45

Slide 45 text

人間と AI、どちらの体験を優先するか AIエージェント時代のWeb〜いま、第二のレスポンシブ設計が始まっている - Nothing ventured, nothing gained. AI に最適化すると、人間にとって使いにくい UI になることがある ▸ 人間に最適化すると、AI にとって冗長になる (装飾 HTML、画像に埋め込まれたテキスト) ▸ モバイルデバイスが登場したとき、m.example.com を作り分離する動きがあったが、運用コストの高さや SEO への悪影響などから、レスポンシブデザインが主流になった ▸ 同じような観点で、AI 向けのレスポンシブな設計が求められるだろう ▸

Slide 46

Slide 46 text

新しい技術は協業のために作られているこれまで紹介した規格はどれも、AI にすべてを任せる仕組みではない人間と AI が同じ場所で働くことを前提に設計されている MCP Apps/A2UI / json-render — テキストで足りない瞬間に、人間が判断・操作するための UI を会話に差し込む ▸ WebMCP — Web という既存のインターフェースを人間と AI で共有し、AI は必要な操作だけをツールとして呼び出す ▸

Slide 47

Slide 47 text

我々の役割は変わらないすべての人（と AI）にWeb というインターフェースを介して体験を設計することがフロントエンドエンジニアの役割である AI と人間が協業できるように Web が進化しているだけ ▸

Slide 48

Slide 48 text

まとめ AI は Web の出力者になり、UI は入口から補助へ変わりつつある ▸ AI は Web の消費者にもなり、Web アプリは人間向け UI と AI 向けツールの両方の顔を持つようになった ▸ それでもフロントエンドエンジニアの役割は変わらない。ユーザー体験を形作ることが重要で、AI と人間の両方を考慮した設計が求められるようになった ▸

Slide 49

Slide 49 text

References MCP Apps: https://github.com/modelcontextprotocol/ext- apps/blob/main/specification/2026-01-26/apps.mdx ▸ MCP Apps: Extending servers with interactive user interfaces: https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/ ▸ AI Content Disclosure: https://github.com/dweekly/ai-content-disclosure ▸ Markdown for agents: https://blog.cloudflare.com/ja-jp/markdown-for-agents/ ▸ WebMCP: https://github.com/webmachinelearning/webmcp ▸ json-render: https://json-render.dev/ ▸ A2UI: https://a2ui.org/ ▸

Slide 50

Slide 50 text

T H A N K Y O U ご清聴ありがとうございました azukiazusa.dev