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

フロントエンドエンジニアがこれまで向き合ってきた相手は、人間でした。しかしAIの登場によって、この前提が変わりつつあります。

AIはWebの出力者になりました。ストリーミングで流れるチャットUIが注目を集め、インタラクティブなUIを返せるMCP Appsも登場しています。
同時にAIはWebの消費者にもなりました。AIが効率的に情報を取得できるよう、HTMLの代わりにマークダウンでコンテンツを配信する動きや、AIがWebアプリをツールとして利用するWebMCPの策定も進んでいます。さらにAIが生成したことを示すai-disclosure属性の提案・仕様の議論が進んでいます。

このようにWebフロントエンドは「AIとの接点」として日々進化しています。本セッションではこれらの変化を整理し、AI時代においてもWebが情報をやり取りする手段として重要な役割を果たしていることをお伝えします。

Transcript

1. 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
2. 自己紹介 azukiazusa ▸ Frontend Engineer ▸ https://azukiazusa.dev ▸ 週に 1 回、Web 開発と AI の記事 を書いています ▸ FE（フロントエンド | ファイアー エムブレム）が好き ▸
3. あなたのフロントエンドの "相手" は誰ですか？ 従来のフロントエンドの仕事は、人間とシステムの間のインターフェースを作る ことだった ▸ ところが 2023 年以降、AI が Web のコンテンツを読んで、生成して、操作するよ うになった ▸ つまり Web の相手に AI が加わった ▸
4. 2つの AI PRODUCER 出力者の AI CONSUMER 消費者の AI チャットで応答を生成する ▸ ユーザーが理解・操作しやすいよ うな UI を返す ▸ コンテンツを生成する ▸ 正確な応答を生成するために、 Web の情報にアクセスする ▸ ユーザーのタスクを完了するため に、Web アプリを操作する ▸
5. P A R T 1 AI は Web の 「出力者」になった
6. チャット型 UI の台頭 AI の普及により、チャット型の UI を設計 する機会が増えた → これまでの「リクエストを送って完成 したレスポンスを受け取る」UI から「途 中経過をリアルタイムに描画し続ける」 UI へ ストリーミング処理が日常になった ▸ 待機状態の UX ▸ 入力フォームの設計（IME の確定で送 信しない、など） ▸
7. ストリーミング UI は何を変えたか 途中経過をどう見せるかの体験設計が必要になった ▸ 応答をそのまま出力すると機械的に見えるので、バッファリングしたり、表 示のアニメーションをつけたりする工夫が必要 ▸ マークダウンを素朴にパースすると、不完全な構文で表示が崩れる恐れがあ る ▸ 自動スクロールの挙動（ユーザーが過去のメッセージを読んでいるときは自 動スクロールを止める、など） ▸ アクセシビリティ上の観点（ストリーミングで逐次追加されるメッセージを スクリーンリーダーにどう伝えるか） ▸
8. Generative UI という潮流 AI が会話の中でテキストではなくUIを返す設計 ▸ チャット応答が「読むもの」から「操作するもの」へ ▸ 実装は一つではない — MCP Apps / A2UI など複数の規格が並行 ▸ まずは Anthropic が提案した MCP Apps から見ていく ▸
9. MCP Apps の登場 MCP Apps は、AI がテキストだけでな くインタラクティブな UI 会話の中で 返せるようにする仕組み ▸ 右の例では、ホテルの一覧がチャッ トの中にカード形式で表示されてい て、そのまま予約の操作もできる ▸ ポイントは、UI が入口ではなく、必 要な瞬間に差し込まれる部品になっ たことと、チャット画面でそのまま 操作できる体験が提供されること ▸
10. なぜテキストだけでは足りないのか チャットは説明には強いが、比較や選択や確認には向かない場面がある ▸ 単にデータを眺めるよりも、グラフで推移を眺めたほうがわかりやすいこと は一目瞭然 ▸ テキストのチャットは一方向の情報伝達であった ▸ MCP Apps ではユーザーのクリックや入力などの操作を受け付ける双方向の インターフェースが提供される ▸ 会話から離れずに操作する体験が求められている ▸ コンテキストを保ったまま操作できる UI を差し込めるのが MCP Apps の強み ▸
11. 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 */ ],
12. MCP Apps のコード例 ツール定義の _meta.ui.resourceUri からそのリソースを参照する server.tool( "show_dashboard", { description: "売上データをダッシュボードで表示する", _meta: { ui: { resourceUri: "ui://dashboard", }, }, }, async (params) => { // ツールのレスポンスは UI に渡されるので、UI 上でデータを表示できる return { data: await fetchSalesData(params) }; }, );
13. 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(...) で商品を購入するツールを呼び出す例 ▸
14. 設計思想の変化 UI は入口ではなく、必要な瞬間に差し込まれる部品になる ▸ チャットの中でデザインを統一しつつ、破綻しないような UI を提供する必要 がある ▸ 既存のデザインシステムもこの文脈でどう活かせるかを考える必要がある ▸ 人間の判断が必要な瞬間にはテキストではなく UI が必要 ▸ AI に UI を作らせたいが、その UI を安全に表示・操作するにはどう設計すべき か？ ▸ MCP Apps は HTML を iframe に埋め込むサンドボックスアプローチでこの問 題に答えている ▸
15. ホストごとに異なるテーマへの対応 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 は含めない ▸
16. Agent が UI を返す方法は MCP Apps だけではない MCP Apps は HTML を iframe に埋め込む アプローチ → ホスト側のサンドボックス前提で表現力を確保する 一方で、「宣言的な JSON を返す」 という別解もある AI は HTML ではなく、コンポーネント spec の JSON を生成する ▸ ホスト側がそれを ネイティブ部品 として描画する ▸
17. レイヤーが異なる 2 つの代表例 A2UI (Google) — プロトコル。何を、どんな JSON で送るかの仕様 ▸ json-render (Vercel Labs) — フレームワーク。schema-agnostic なので A2UI 形 式にも適用可能 ▸
18. A2UI — Google Agent と UI の間の通信プロトコル AI が返す JSON の メッセージ形式と意味論 を定義する ▸ 描画側の実装は問わない — React / Angular / Flutter / ネイティブで同じ JSON が 動く ▸ LLM が インクリメンタルに生成しやすい フラットな構造 ▸ 完成 JSON を待たずにストリーミングで部分描画できる ▸
19. 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" } } ] } }
20. json-render — Vercel Labs (フレームワーク) JSON 形式の記述から、React / Vue / Svelte など様々な環境の UI を描画するフレ ームワーク ▸ LLM が JSON を出力するだけでアプリの UI を生成できるようにするのが狙い ▸ 開発者が コンポーネントカタログ (Zod スキーマ) を定義して AI を制約する ▸
21. json-render の 4 つのステップ 開発者が カタログ (Zod スキーマ) を定義 ▸ カタログにマッピングするコンポーネントを実装 ▸ AI が カタログ準拠の JSON をストリーミング生成 ▸ JSON を元に React コンポーネントとして描画 ▸
22. 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: {}, });
23. json-render のコード例 カタログにマッピングするコンポーネントを実装 import { defineRegistry, Renderer } from "@json-render/react"; const { registry } = defineRegistry(catalog, { components: { Card: ({ props, children }) => ( <div className="card"> <h3>{props.title}</h3> {children} </div> ), Metric: ({ props }) => ( <div className="metric"> <span>{props.label}</span> <span>{props.value}</span> </div> ), },
24. 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 はカタログに完全に拘束される ▸
25. json-render のコード例 AI が生成する JSON を <Renderer /> で描画する <Renderer registry={registry} spec={spec} />
26. よく見られる言説 UI は AI が全部作ってくれるから、フロントエンドエンジニアは もういらない。バックエンドエンジニアを目指そう。
27. AI が登場したことで考えるべきことが増えている ストリーミング UI のユーザー体験設計/MCP Apps の UI 設計など ▸ AI は技術的に UI を生成できるが、体験設計は依然として人間が担う領域 ▸ 人間と AI のブラウザの操作の仕方は大きく異なる ▸ フロントエンドはユーザー体験を形作る役割がある ▸
28. P A R T 2 AI は Web の 「消費者」にもなった
29. クローラと AI エージェントの違い Web には以前からクローラという「人間以外の消費者」がいた しかし AI エージェントは振る舞いが違う クローラ AI エージェント 目的 インデックス作成 タスク遂行 行動 読み取り 読み取り + 操作 理解 構造的（DOM をパースしてコン テンツを抽出） 意味的（レンダリングされた内容を理解し て判断） コンテンツの冗長性が 与える影響 小さい 大きい（コンテキストウィンドウを圧迫す ると性能が落ちる）
30. AI が Web を読むための工夫が必要に エージェント フレンドリーなウェブサイトを構築する | web.dev AI はスクリーンショットや DOM、アクセシビリティツリーを利用してコンテンツ の意味構造を理解する ▸ セマンティック HTML の重要性 ▸ これは今までと変わらない ▸ コンテキストウィンドウを圧迫しない → 単に情報が欲しいだけであれば、装飾の ための構造はノイズになる ▸
31. コンテキスト効率の良い配信が重視される AI にとっては、複雑な装飾付き HTML より Markdown のほうが読みやすい 場面 が多い ▸ Web サイトが Markdown 版を返す動きが出てきた ▸ Cloudflare も Markdown for agents を公開し、エージェント向けの配信を提案し ている ▸ Accept: text/markdown ヘッダを送ると、AI にとってコンテキスト効率の良 い Markdown 版が返る ▸
32. llms.txt という慣習 Web サイトが AI 向けに「読むべき場所」を案内する Markdown ファイル サイトのルートに /llms.txt (目次) と /llms-full.txt (全文) を置く ▸ 採用が進む開発者向けドキュメント ▸ Anthropic / Vercel / Cloudflare / Stripe / Cursor / Supabase ▸
33. AI がコンテンツを効率よく理解するための工夫は早期から行わ れていたが、操作のためのインターフェースはまだ発展途上
34. WebMCP の提案
35. WebMCP は Web アプリをツール化する WebMCP は、Web アプリがブラウザ上で AI から呼び出せるツール を公開する仕 組み ▸ AI はスクリーンショット解析やコードによる DOM 操作ではなく、意味を持った 関数 を通じて操作できる ▸ 余分なコンテキストを与えず、AI にとって必要な情報だけを渡すことができ る ▸ 前提は human-in-the-loop ▸ AI が完全に自律的に動くのではなく、人間と協業することを前提とした設計 ▸
36. 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 アプリが「タスクを追加する」ツールを提供するコード例 ▸
37. 宣言的にツール化できる <form toolname="add-todo-item" tooldescription="Add a new todo item to the list" > <input name="text" required /> <button type="submit">Add Todo</button> </form> WebMCP ではフォームに属性を付けるだけでツール登録できる提案もある ▸ AI ツールを呼び出すとフォームに自動で値が入力される ▸ Submit ボタンを押すのは人間が担う ▸
38. 実行例
39. 従来の MCP ツールや API と何が違うのか 単に AI にツールを使わせるだけなら MCP ツールでいい ▸ それでも WebMCP が必要なのは、人間と AI が同じインターフェース上で協業す るから ▸ 使いなれたダッシュボードを眺めながら、AI に必要な操作だけを任せたり、 データを要約してもらうという流れが自然にできる ▸ 既に多くの企業が Web を通じてサービスを提供しており、既存の資産を再利用で きるというメリットも大きい ▸ ブラウザに既にあるセッション Cookie / SSO の恩恵をそのまま利用できる ▸
40. AI 向け対応とアクセシビリティは地続き → 新しいスキルが必要なのではなく、アクセシビリティという Web の基本が生きて くる WebMCP の仕様書でも「much of the challenges faced by assistive technologies also apply to AI agents」と明記されている ▸ Web を視覚情報なしにどう理解し、操作するかという点で、AI エージェントとス クリーンリーダーは本質的に同じ問題を解いている ▸ 「支援技術のためのインターフェース」を考えるスキルセットが、そのまま「AI のためのインターフェース」に転用できる ▸
41. AI が生成する時代の説明責任 AI が生成したコンテンツは、誤情報や偏見を含む可能性がある ▸ AI はコンテンツを大量に生成できるため、よく検証されていない情報が大量に投 稿されるという問題も出てきた ▸ Web コンテンツの制作者として、AI の関与を明示することが求められている ▸
42. ai-disclosure 属性の提案 <article> <section ai-disclosure="none"> <p>本誌の独自調査では...</p> </section> <aside ai-disclosure="ai-generated" ai-model="gpt-4o"> <h3>AI要約</h3> <p>レポートの結論は...</p> </aside> </article> AI の関与度を HTML で宣言 ▸ 例えばニュースサイトでは、人間が書いた調査報道と AI 生成のサマリーが混在す る可能性がある ▸ ai-disclosure 属性を使ってどの部分が AI 生成なのかを明示することができる ▸
43. C O N C L U S I O N 「The Web is for everyone」の再解釈
44. everyone に AI が含まれた "The Web is for everyone" — Tim Berners-Lee スクリーンリーダーに情報を伝えたり、身体に障害がある人が操作できるようにする のと同じように、AI にも情報を届けたり、発信する基盤を作ることが求められるよう になった → アクセシビリティと同じ考え方 すべての人が自由かつ平等にアクセスし、利用できる開かれた基盤であるべきだ という考え方 ▸ この理念は変わっていない 「everyone」の範囲が拡張された ▸
45. 人間と AI、どちらの体験を優先するか AIエージェント時代のWeb〜いま、第二のレスポンシブ設計が始まっている - Nothing ventured, nothing gained. AI に最適化すると、人間にとって使いにくい UI になることがある ▸ 人間に最適化すると、AI にとって冗長になる (装飾 HTML、画像に埋め込まれたテ キスト) ▸ モバイルデバイスが登場したとき、m.example.com を作り分離する動きがあった が、運用コストの高さや SEO への悪影響などから、レスポンシブデザインが主流 になった ▸ 同じような観点で、AI 向けのレスポンシブな設計が求められるだろう ▸
46. 新しい技術は協業のために作られている これまで紹介した規格はどれも、AI にすべてを任せる仕組みではない 人間と AI が同じ場所で働くことを前提に設計されている MCP Apps/A2UI / json-render — テキストで足りない瞬間に、人間が判断・操作 するための UI を会話に差し込む ▸ WebMCP — Web という既存のインターフェースを人間と AI で共有し、AI は必要 な操作だけをツールとして呼び出す ▸
47. 我々の役割は変わらない すべての人（と AI）にWeb というインターフェースを介して 体験を設計することがフロントエンドエンジニアの役割である AI と人間が協業できるように Web が進化しているだけ ▸
48. まとめ AI は Web の 出力者 になり、UI は入口から補助へ変わりつつある ▸ AI は Web の 消費者 にもなり、Web アプリは人間向け UI と AI 向けツールの両方 の顔を持つようになった ▸ それでもフロントエンドエンジニアの役割は変わらない。ユーザー体験を形作る ことが重要で、AI と人間の両方を考慮した設計が求められるようになった ▸
49. 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/ ▸
50. T H A N K Y O U ご清聴ありがとうございました azukiazusa.dev