ブラウザを開いて、AIエージェントに「最も静音なノイズキャンセリングイヤホンを探して、明日届くように手配しておいて」と頼む。エージェントは複数のECサイトを回り、レビューを比較し、カートに入れて配送指定をした上で、決済画面で「ここから先は確認をお願いします」と返してくる。

このとき、ブラウザの向こう側で何が起きているのか。エージェントはピクセルを目で見ているのか、HTMLを解釈しているのか、それともサイト側が用意した「エージェント向けの入口」を使っているのか。

AIエージェント時代のWebがどう変わっていくのかは、私自身ずっと気になっていたテーマだった。最近腰を据えて調べてみたところ、思っていた以上に議論と実装が進んでいた。今回の記事では、私が学んだ範囲で、いまWebのアーキテクチャへの変更を促しつつある二つの標準技術──WebMCPとNLWeb──を、コードスニペットを含めて紹介していく。先に言っておくが、まためちゃ長くなった。こんな長いのは読めないという人のためのtl;drも用意した。

tl;dr

AIエージェントが新しい「Webのクライアント」として登場し、モバイル普及時と同じ構造の再設計が起きている
現状のスクレイピングやComputer Useは脆く、サイト側から明示的なインターフェースを提供する流れに移りつつある
その中心が WebMCP（操作のためのツール契約）と NLWeb（自然言語で問い合わせる窓口）の二つ
設計指標は UX から AX（Agent Experience）へ拡張される。これがAI時代のレスポンシブ設計だ

モバイルが起こしたことが、いま再び起きている

15年前、Webは「人間がデスクトップPCで見るもの」だった。ところがiPhoneが普及し、Webにアクセスする「クライアント」の前提が崩れた。同じURLに、画面幅375pxの端末と1920pxの端末が、ランドスケープとポートレートが、タッチ操作とマウス操作が、低帯域回線と光回線が、同時に来るようになった。

このとき開発者の選択肢は二つあった。一つは、デバイス別にサイトを分離するアプローチ。m.example.com をモバイル用に切り出すような設計だ。短期的には合理的だが、二重メンテナンスのコストが膨らみ、URLの分裂はSEOにも不利だった。もう一つが「Responsive Web Design」だ。同じHTMLが、メディアクエリと流動的なグリッドによって、クライアントに応じて姿を変える。一つのコードベース、一つのURLで、複数のクライアントに応える。Webは結局、後者を選んだ。

そしていま、Webは三度目の同じ問題に直面している。クライアントが、また増えた。

ChatGPT、Claude、Gemini、そしてブラウザに組み込まれつつあるエージェント機能。これらは「ブラウザを通さない閲覧者」ではなく、「ブラウザの中で人間に代わって操作する閲覧者」として登場しつつある。問題の構造はモバイルのときと同じだ。同じWebサービスに、異なる前提のクライアントが同時に来る。違いは、今回のクライアントが画面幅ではなく、視覚を持たない、自然言語で意図を持っている、自律的に複数ステップを踏む、という性質を持つことだ。

これは「AI時代のレスポンシブ設計」と呼んでよいと私は考えている。媒体の軸が画面サイズだったところに、エージェントという軸が加わった、というだけのことだ。そして、軸が増えれば、設計指針も書き換わる。

現状のエージェントは「招かざる客」である

「同じHTMLでよいなら、エージェントもそのまま使えるはずだ」と思うかもしれない。実際、現在のエージェントの多くはそうしている。手段は主に三つある。

DOMスクレイピングは、ページのHTMLを解析して「購入ボタン」らしき要素を探してクリックする。スクリーンショット解析（Computer Use系）は、画面を画像として認識し、人間と同じように視覚的に操作する。ヘッドレスブラウザ操作は、PlaywrightやSeleniumなどでサーバ側からブラウザを動かす。

これらが共通して抱える問題は、「サイトが意図して提供したインターフェース」を使っていないという点にある。購入ボタンのCSSクラス名が変わっただけで動作が壊れる。膨大なDOMやスクリーンショットをLLMに食わせるためトークン消費が肥大する。決済のような重要な操作で、エージェントが間違った要素をクリックする。レンダリング待ちの数秒が、複数ステップ重なれば数十秒に膨らむ。加えて、display:none で隠された要素や視覚的に見えないテキストもエージェントは読み込めるため、ユーザーが認識していない悪質なコンテンツに誘導されるなど、攻撃面の広さも問題になる。私はこの構造的な不適合について、しばらく前に@ITの連載でも書いた。AIブラウザの台頭は、現在のWebが人間の視覚認識のために設計されている、というそもそもの前提に正面からぶつかる。

atmarkit.itmedia.co.jp

これは「視覚的推測」と呼べる構図だ。人間向けに作られた視覚レイヤーを、機械が眺めて推測している。これはレスポンシブ以前の m.example.com 時代に近い構図だ。クライアント側がサイト側の前提を勝手に推測して、ずれたら壊れる。ここに、サイト側が「機械向けの明示的なインターフェース」を出すべきだ、という発想が生まれる。

念のため言い添えれば、これら既存手法に価値がないわけではない。Webの大半はWebMCP/NLWebに対応していないし、これからも長期間そうあり続ける。エージェントが現実のWebを相手にする以上、スクレイピングやComputer Useは当面なくならない。後述するWebMCPとNLWebは、これらをいきなり置き換えるものではなく、「サイト側が能動的に協力できる場合に、より確実な経路を増やす」ための選択肢である。

そもそもWebは人間のための文書システムとして始まった。それが検索エンジンの登場以降、クローラーという「機械の利用者」を抱えるようになり、SEO、Schema.org、JSON-LD、Microdata、microformats、RDFaといった構造化データの規格、さらにオープンデータの流れが、Webを少しずつ機械にも読みやすくしてきた。アクセシビリティの世界では、ARIAを中心とした取り組みが、支援技術という別種の機械にUIの意味を伝える試みを続けてきた。これから紹介するWebMCPとNLWebは、こうした過去のセマンティックWebやアクセシビリティの蓄積を否定するものではない。むしろその積み重ねの上に、「アクションを呼び出せる契約」と「自然言語で問い合わせる窓口」という新しい層を足す試みとして読むのがふさわしい。

WebMCP──ブラウザの中の「ツール契約」

WebMCPは、GoogleとMicrosoftがW3CのWeb Machine Learning Community Groupで策定を進めているブラウザAPIだ。Chrome 146から早期プレビューとして実験できる（chrome://flags/#enable-webmcp-testing）。

中核は navigator.modelContext というブラウザネイティブのインターフェースである。サイト側がJavaScriptで「このページでできること」をツールとして登録すると、ブラウザがそれをエージェントに公開する。もっとも基本的な例を見る。

window.navigator.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new todo item to the list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text of the todo item" }
    },
    required: ["text"]
  },
  execute: ({ text }, agent) => {
    // Add todo item and update UI.
    return { content: [{ type: "text", text: `Added: ${text}` }] };
  },
});

ここで起きていることは、構造的にはRESTful APIや関数呼び出しと同じだ。name と description で何ができるかを宣言し、inputSchema でパラメータをJSON Schemaとして規定し、execute で実装する。

違いは、これがブラウザのページ内で動作することにある。サイトのJavaScript変数、ログイン中のセッション、現在開いているページの状態すべてに、ツールはそのままアクセスできる。Anthropic発の本来のMCPがバックエンドサーバとして独立しOAuth等で認証を別途要求するのとは対照的に、WebMCPは「ユーザーがいま開いているタブのコンテキスト」をそのまま継承する。両者は競合ではなく補完だ。たとえば航空会社のサイトなら、予約エンジンのコア機能（在庫検索や決済処理）はバックエンドのMCPサーバで提供し、いま開いている画面の座席選択や機内食の指定はWebMCPで担う、というように層を分けて使い分ける。

決済のような重要な操作を考えると、その意味がよくわかる。同じ提案ドキュメントの例だ。

window.navigator.modelContext.registerTool({
  name: "buyProduct",
  description: "Use this tool to purchase a product given its unique product_id.",
  inputSchema: {
    type: "object",
    properties: {
      product_id: {
        description: "The unique identifier for the product to be purchased.",
        type: "string",
      }
    },
    required: ["product_id"]
  },
  execute: async ({ product_id }, agent) => {
    const confirmed = await agent.requestUserInteraction(async () => {
      return new Promise((resolve) => {
        const ok = confirm(`Buy product ${product_id}?\nClick OK to confirm.`);
        resolve(ok);
      });
    });

    if (!confirmed) {
      throw new Error("Purchase cancelled by user.");
    }

    executePurchase(product_id);
    return `Product ${product_id} purchased.`;
  },
});

注目すべきは agent.requestUserInteraction() だ。重要なアクションを実行する前に、エージェント側のフローを一旦止めて、ブラウザ上のユーザーに承認を求めることができる。エージェントは自律的だが、ブラウザはユーザーのものであり、サイトはユーザーに対して責任を持つ。WebMCPの設計はこの境界を尊重している。仕様がHuman-in-the-loopを明示的に組み込んでいるのは、エージェントを単独で動作させるのではなく、重要な判断を要所でユーザーに戻す設計を前提にしているからだ。

ここに Human-in-the-loop が組み込まれているのには理由がある。エージェントに自律実行を許す瞬間、Webは新しい攻撃面を抱える。悪意のあるサイトがツール定義の description に隠し命令を仕込んでエージェントを誤誘導する Prompt Injection、第三者がツール自体を汚染する Tool Poisoning、そして見えないテキストでエージェントだけに別のメッセージを送り込む手口──これらはすべて、決済や個人情報送信のような「慎重さを要求する操作」を狙うものだ。だからこそ、重要アクションの直前にユーザー承認を挟む requestUserInteraction() は、便利機能ではなく安全装置として設計されている。

宣言型API（Declarative API）も提案されている。既存のHTMLフォームに属性を追加するだけで、エージェントから呼び出せるツールになる。

<form toolname="search-cars"
      tooldescription="Perform a car make/model search">
  <input type="text" name="make"
         toolparamdescription="The vehicle's make (e.g., BMW, Ford)" required>
  <input type="text" name="model"
         toolparamdescription="The vehicle's model (e.g., 330i, F-150)" required>
  <button type="submit">Search</button>
</form>

これは命令型APIで registerTool({ name: "search-cars", ... }) と書いたのと等価なツール定義になる。toolautosubmit 属性をつけない限り、エージェントがフォームを埋めても、最終的なsubmitはユーザーが目視確認する。HTMLのセマンティクスをそのまま「機械可読な契約」へ持ち上げる、という発想だ。

WebMCPの本質は、サイトが「どんな操作を許可するか」を自分で決められる、という点にある。スクレイピングは「クライアントが推測する」関係だが、WebMCPは「サーバーが提示する」関係だ。レスポンシブ設計でメディアクエリが提供側からの宣言だったのと、同じ構図である。

NLWeb──「対話する情報」のレイヤー

WebMCPはアクションを担う。だが、エージェント時代のWebに必要なのはアクションだけではない。

「この製品の保証期間は」「過去三ヶ月で評価が高かった商品は」「このサイトの返品ポリシーを要約して」──これらは「クリック」ではなく「問い合わせる」操作だ。サイト側にとっては、コンテンツを構造化して提供すれば応えられるが、現在のWebでは検索結果ページや個別記事ページに散らばっており、エージェントには取り出しにくい。

NLWebはこの層を担う、Microsoftが主導するオープンプロトコルである。提唱者のR.V. Guha氏は、Schema.orgとRSSの提唱者として知られる。

仕組みはシンプルだ。サイト側は、自身のコンテンツ（Schema.orgで構造化されたデータ、RSSフィード、商品データなど）をベクトルデータベースに登録し、/ask という単一のエンドポイントを公開する。NLWebの公式ドキュメントによれば、APIの形は次のようになる。

GET /ask?query=最近のAIエージェントを扱った回&site=Today-Explained&mode=summarize

主要なリクエストパラメータは次のとおり。

query: 自然言語クエリ（必須）
site: 対象サイトのスコープ
prev: 過去のクエリ（会話文脈の保持に使う、カンマ区切り）
mode: list（既定、関連項目を返す）、summarize（要約付き）、generate（RAG的に生成）
streaming: ストリーミングするか（既定true）

レスポンスはSchema.orgの語彙で返ってくる。NLWebの公式チュートリアルでは、Voxの「Today, Explained」ポッドキャストのRSSをそのままロードして検索可能にする例が示されている。それを念頭に置いた応答イメージは次のような形になる。

{
  "query_id": "abc123",
  "results": [
    {
      "url": "https://feeds.megaphone.fm/.../episode-xyz",
      "name": "What AI agents actually do",
      "site": "Today-Explained",
      "score": 0.92,
      "description": "AIエージェントの実態と社会的影響について議論した回。",
      "schema_object": {
        "@type": "PodcastEpisode",
        "name": "What AI agents actually do",
        "datePublished": "2026-03-18",
        "duration": "PT27M",
        "associatedMedia": {
          "@type": "MediaObject",
          "contentUrl": "https://feeds.megaphone.fm/.../episode-xyz.mp3"
        }
      }
    }
  ]
}

注目したいのは、schema_object がSchema.orgのアイテムとしてそのまま返ってくる点だ。エージェント側はこれを構造化データとして直接消費できる。リッチスニペットがGoogleの検索結果のために存在したのと同じ役割を、NLWebはエージェントのために果たそうとしている。

NLWebはMCPとも互換だ。同じNLWebサーバには /mcp エンドポイントもあり、list_tools、call_tool などのMCPメソッドに応える。つまり、Anthropic MCPのクライアント（Claude DesktopやCursorなど）から、サイトのコンテンツを直接問い合わせることができる。

NLWebの位置づけはWebMCPと相補的だ。WebMCPが「このサイトでどんな操作ができるか」を担うなら、NLWebは「このサイトに何の情報があり、どう問いかけられるか」を担う。前者がフロントエンドのDOM/JSロジックの上に乗り、後者がバックエンドのデータの上に乗る。両者を貫く共通言語が、Anthropic発のMCPというプロトコルである。

両者の違いを整理すると次のようになる。

観点	WebMCP	NLWeb
主な役割	アクションの実行	情報の検索・対話（RAG）
動作レイヤー	ブラウザ内（フロントエンド）	サーバサイド／セマンティック層
インターフェース	`navigator.modelContext.registerTool()`	`/ask`、`/mcp` の HTTP エンドポイント
データソース	ライブDOM、ページ内のJavaScript状態	Schema.org、RSS、商品データ等のベクトルDB
認証・セッション	ブラウザの現セッションをそのまま継承	サーバ側で別途構成（OAuth等）
推進主体	Google、Microsoft（W3C WMLCG）	Microsoft（R.V. Guha氏）
ユースケース例	「カートに入れる」「予約する」	「返品ポリシーを要約して」「条件に合う商品は」
ステータス	Chrome 146で早期プレビュー、草案段階	OSSとして公開、商用導入が進行中

実用シナリオでは両者が組み合わさる。たとえばECサイトでユーザーが「予算3万円以内で評価が高いノイズキャンセリングイヤホンを買って」と頼んだ場合、エージェントはまずNLWebの /ask で候補を絞り込み、次にWebMCPの buyProduct ツールを呼んで購入処理に入る、という流れになる。「対話で探し、契約で実行する」二段構えである。

なお、エージェント間の協調を扱う A2A（Agent2Agent）や、画面操作そのものをモデル化する Computer Use のような隣接プロトコルも、並行して提案が進んでいる。ただし「Webサイト側からエージェント対応する」という文脈で、いますぐ取り組める候補が、ここで取り上げたWebMCPとNLWebの二つだ。

乱暴にまとめてしまえば、WebMCPは「ボタンを押すための標準化されたツール」で、NLWebは「サイトに質問するための標準化された窓口」である。今はとりあえずこれだけ覚えておけば良いだろう。

UXからAX（Agent Experience）へ

ここでいうAX（Agent Experience）は、ひとまず「エージェントがそのサイトをどれだけ理解しやすく、操作しやすいか」という体験のことだと緩く捉えてほしい。UX（User Experience）の対になる概念で、業界でもまだ定義が固まりきっていない用語である。

これら二つの技術が指している方向は、Webサイトの設計指標が「UX」だけでなく「AX」へと拡張される、ということだ。

レスポンシブ設計の登場以降、サイトは「PCでもモバイルでも快適に閲覧できるか」という問いに答える必要があった。PageSpeed Insightsはモバイル評価を持ち、GoogleはMobile First Indexingを導入した。今後数年で、同じ種類の問いがエージェントについても立てられる。

このサイトのアクションは、エージェントから明示的なAPIとして見えるか（WebMCP）
このサイトの情報は、エージェントから自然言語で問い合わせられるか（NLWeb）
重要なアクションには、ユーザー承認のフックが組み込まれているか
ツール定義はUIの変更に追従して保守されているか

GoogleがWebMCPに対応したサイトをAI Overviewsで優先的に提示する可能性は指摘されているし、Microsoft Edgeのネイティブ実装についても2026年中盤を見据えているという報道がある。具体的な時期はずれる可能性があるが、検索順位の指標が「人間の閲覧体験」から「エージェントの実行容易性」へと拡大していく方向自体は、もはや動かないだろう。

ただし、WebMCPの普及を疑問視する声もある。論点は大きく二つに整理できる。

一つ目は、保守コストの問題だ。WebMCPに対応すると、サイトはUIとツール定義の二つを並行してメンテナンスすることになる。検索フォームのUIを変更したらツール定義も追従して更新しないと、エージェントが古い仕様で動いてしまう。これは「UIとツール定義のドリフト」と呼ばれる典型的な問題で、サイト側に継続的な負担を強いる。

二つ目は、過去の類似規格の普及が芳しくなかったという歴史的事実だ。Schema.org、microformats、RDFaなど、サイトに追加のメタデータを埋め込ませる規格は20年以上にわたり提案されてきたが、いずれも「直接的なビジネスメリットが見えにくい」という理由で必ずしも圧倒的に支持されたという状況にはならなかった。WebMCPも同じ轍を踏むのではないか、というのが懐疑派の主張である。

これに対する反論ももちろんある。短期的には、webmcp-react や webmcp-next のようなフレームワーク統合、そしてHTMLフォームに toolname 属性を足すだけで済む宣言型APIによって、対応コストを下げる動きがある。長期的には、検索エンジンやAIアシスタントが「WebMCP対応サイトを優先表示する」というインセンティブを与える可能性がある。Schema.orgが普及したのは、Googleがリッチスニペットの条件にしたからだ。WebMCPがビジネスメリットと結びつくか否かが、普及の分水嶺になる。

開発者がいまから始められること

仕様はまだ草案段階だが、いまからできることもある。レスポンシブ設計のときも、メディアクエリの仕様が安定する前から、先進的なサイトは導入を始めていた。

最低限のアクションは三つある。

第一に、自分のサイトの「主要な操作」を棚卸しする。検索、カート、予約、ログイン、設定変更──これらの中で、エージェントにツールとして提供する価値があるものはどれか。WebMCPのツールは粒度が大きすぎても小さすぎても使いにくい。「ユーザーがこのサイトに来てよく行う代表的なジョブ」を3〜5個挙げて、それをツールに翻訳する作業が出発点になる。

第二に、Schema.orgでの構造化データを再点検する。NLWebはSchema.orgやRSSをそのままベクトル化して使う仕組みなので、すでに構造化データが整っているサイトは、立ち上げまでの距離が近い。流れだけ書けば、LLMプロバイダ・埋め込みモデル・ベクトルDBを設定ファイルで指定し、既存のRSSやSchema.orgデータをロードしてサーバを起動する、という三ステップで /ask が動き出す。具体的なコマンドは公式リポジトリの「Hello World」ガイドが詳しいので、そちらを参照するとよい。逆に構造化データが弱いサイトは、エージェント時代の検索結果から消える可能性が高い。

第三に、UI操作と「意図」の分離を始める。WebMCPの命令型APIは、ページのJavaScript関数を再利用するのが前提だ。クリックハンドラの中にビジネスロジックが書き込まれているようなコードは、エージェント対応のためにリファクタリングが必要になる。addTodo(text) のような純粋な関数として切り出されていれば、それをそのまま execute に渡せる。これは設計品質としても望ましい方向で、エージェント対応はその副次的な動機付けになる。

Webは何度目かの「クライアント拡張」を経験している

Webの歴史は、新しいクライアントを受け入れる歴史でもあった。1990年代後半、Webにブラウザの種類が増えた（Netscape、IE、Opera）。CSSとJavaScriptの仕様が乱立し、開発者は分岐コードに苦しんだ。標準化が進むまで10年かかった。2010年前後、モバイルが来た。レスポンシブ設計、ビューポートメタタグ、タッチイベント、Service Worker。標準が安定するまでに、また数年かかった。

そしていま、エージェントという「視覚を持たない、意図を持つクライアント」が来ている。WebMCPがブラウザ内のアクションを、NLWebがバックエンドの対話を担う。両者を支えるのはMCPという共通プロトコルである。

レスポンシブ設計を最初に学んだとき、私たちは「画面幅」というたった一つの軸が、いかにWebの設計全体を再考させるかを目撃した。エージェントという軸は、それよりもさらに大きな再考を求めるかもしれない。「人間が見るためのWeb」と「エージェントが操作するためのWeb」は別物ではなく、同じ一つのコードベースから両方を成立させる方法を、私たちはこれから設計していく。

それが、AI時代のレスポンシブ設計だ。