AIエージェントが人間の代わりにウェブサイトを操作する場面が増えています。そうなると、サイト側が「ここではこういうことができます」と機械に向けて明示する仕組みが必要になります。その提案として登場したのが WebMCP（Web Model Context Protocol） です。

W3C の Web Machine Learning Community Group で検討されている提案で、仕様の編集者には Google と Microsoft のメンバーが名を連ねています。ただし現時点では Draft Community Group Report の段階であり、W3C勧告に向けた正式な標準化過程には乗っていません。

本稿では、WebMCPが何を解こうとしているのか、仕様として何が決まっていて何がまだ決まっていないのか、そして実務としていま何に着手すべきかを整理します。

WebMCPとは何か

ひとことで言えば、ウェブサイトがAIエージェントに、使える道具（ツール）を構造化して公開する仕組みです。提案元の説明では「AIエージェント相互作用のUSB-C」とも表現されています。

重要なのは、これが人間向けの画面をなくす提案ではないという点です。デザインもUXもそのままに、機械向けの入り口を別に用意する。公開する操作の範囲を決めるのはページの作者であり、サイトの全機能が自動的に道具になるわけではありません。

なぜこの提案が必要とされたか

現在のAIエージェントが、サイト上でボタンを1つ押すために何をしているか。Google Chromeチームのカンファレンスセッションでは、次のような処理の連鎖が示されました。

1. DOM全体をパースする（ページで何が起きているか理解するため）
2. アクセシビリティツリーを読む（HTMLの構造を理解するため）
3. スクリーンショットを撮って分析する（前の2つで見えなかった要素を拾うため）
4. クリックすべき要素の座標を測る
5. クリックする

これは典型例として挙げられたもので、全エージェントが必ずこの5段階を踏むわけではありません。DOMだけを読むもの、スクリーンショット中心のものなど、実装によって手がかりの使い方は異なります。ただ、人間の目のために作られたUIを機械が解釈し直しているという構図は共通しています。

登壇者はこのプロセスを「非常に長く、脆く（brittle）なりうる。どれだけのトークンを使ったか推測すらしたくない」と表現しました。さらに、すべての処理を終えた後に「広告がページ上部にロードされてコンテンツが下に押しやられ、結局正しい場所をクリックできなかった」可能性まで残ります。

脆さの所在は明確です。操作の意味を画面から推測する部分に集まります。具体的には次の3つで壊れます。

WebMCPは、この「画面から操作の意味を推測する」部分を減らしにいく提案です。

ただし正確に書いておくと、推測がゼロになるわけではありません。エージェントは公開されたツールの名前と説明文を読み、どれを呼ぶべきかを判断し、引数を組み立てる必要があります。ページ全体の内容を理解する場面ではDOMも読みます。減らせるのは「どのボタンが目当ての操作なのかを画面から探り当てる」部分であって、判断そのものが消えるわけではありません。

SEOから続く原理原則は、変わっていない

AI検索への最適化には、GEO（Generative Engine Optimization）、LLMO、AEO、AIO と複数の呼び方があります。これらに標準化された定義はなく、実務上は大きく重なっています。対象とする回答システムや測定指標が提唱者によって異なる程度の差で、AIO に至っては「AI Optimization」と「AI Overviews」の両方の意味で使われており特に紛らわしい用語です。本稿では「AI検索最適化」と総称します。

呼び方はともかく、SEOとAI検索最適化の原理原則は、抽象度を上げれば変わっていないというのが当社の見方です。原則は2つに整理できます。

原則1：機械が情報を取得できる基盤を整える

クロールの対象が、分かりやすく、迅速に、間違いなく判別できること。robots.txt、サイトマップ、セマンティックなHTML、構造化データ、表示速度。技術要素の名前は変わっても、「機械が迷わず正確に読めるようにする」という要件は一貫しています。

WebMCPはこの延長線上にあります。DOMを読ませて推測させるのではなく、「このサイトでできること」を最初からツールのリストとして渡す。操作の意味を画面から探り当てる範囲を減らし、構造化された宣言によって判断しやすくする発想です。

原則2：機械が求める情報が、そこに実際にあること

基盤を整えた次は、中身の問題になります。

AIが引用しやすい情報の傾向として、事実密度が高いこと（具体的な数値・統計・調査結果があること）、出典が明示されていること、その段落だけで意味が通ること、といった整理がよく紹介されます。ただしこの種の法則は領域やAI製品によって効き方が異なります。Google自身は、AI向けの特別な文章形式や機械的な「チャンク化」は必要ないとし、独自の視点や一次的な価値のあるコンテンツを重視すると説明しています。

また、AI検索には「クエリファンアウト」と呼ばれる仕組みがあります。1つの質問に対して、AIが裏側で複数の関連クエリを並行実行するものです。Googleは、AI Overviews と AI Mode が質問によっては複数の関連検索を並行実行すると説明していますが、常に実行するわけではなく、クエリ数も公表されていません。

含意ははっきりしています。関連するサブトピックで情報を持っていれば、引用候補になる機会が増える。だから特定のキーワードで1位を取ることだけでなく、関連する情報の「面」を持っていることが効いてきます。

もっとも、「順位より面が重要になった」と単純化はできません。Googleは、ファンアウトの候補ごとに大量のページを量産する行為を推奨しておらず、検索順位の土台となる従来型のSEOと有用なコンテンツを引き続き重視すると明言しています。従来のSEOの上に、カバー範囲の広さが加わったと捉えるのが妥当でしょう。

そして、その面のなかで最も価値が高いのが一次データです。自社にしかない実績数値、自社でしか取れない調査結果、自社の現場からしか出てこない具体例。独自性が高い情報ほど、検索する人に提供する価値が高まり、結果としてAIにも選ばれます。

これはSEOで言われ続けてきたことと変わりません。基盤を整え、独自の一次情報を置く。技術の名前が変わっただけで、原理原則は動いていません。

仕様の中身

サイト側は document.modelContext.registerTool でツールを登録します。ツールのフィールドは、仕様上の必須が3つ、任意が3つです。

Chromeの実装例では inputSchema を含めた形が基本形として示されているため、実務上は4つ書くことが多くなります。ただし仕様上の必須は name / description / execute の3つです。

登録するツールは固定ではなく、ログイン前後で変えたり、画面に応じて動的に増減させたりできます。ECサイトのデモでは「複数商品を比較する」「カートの内容を取得する」「絞り込み条件を取得する」といった読み取り系と、「カートに入れる」「注文を確定する」といった書き込み系のツールが並んでいました。

なお、WebMCPは「ウェブページをデータベース化する仕様」ではなく、MCPのプロトコルをブラウザ内にそのまま実装するものでもありません。MCPに着想を得たブラウザ側のツール公開APIであり、ブラウザがそれをエージェントにどう渡すかは仕様で固定されていません。

確定していること、まだ決まっていないこと

ここが本稿で最も重要な部分です。WebMCPは実験段階にあり、要約が独り歩きしやすい状況にあります。

標準としてのステータス

Draft Community Group Report であり、Standards Track には乗っていません。ChromeとMicrosoft Edgeがオリジントライアル（公開試験）を実施している段階です。提案元自身が「このAPIは非常に実験的。今日見せたコードは来週には違うかもしれない」と述べています。

呼び出し経路の設計には、まだ幅がある

ページ内でツールを列挙する getTools() は仕様に規定されています。一方で、ブラウザ外のエージェントにツールをどう見せ、どう呼ばせるかは実装依存の部分が残ります。宣言型API（HTMLフォームに属性を足すだけで動く方式）も、命令型APIほど固まっていません。

主要AI製品が呼べるかは公式に確認できない

Claude、ChatGPT、Gemini、Perplexity が標準のWebMCPを呼べると公式に確認できる資料は、現時点で見当たりません。「ブラウザを操作できる製品だから呼べるはず」とは言えず、逆に「資料がないから未対応」とも断定できません。

ベンダー実装と標準は別物

ここは特に混同されやすい点です。Cloudflareが「管理画面のスイッチひとつで既存サイトにWebMCPインターフェースを持たせる」機能をデベロッパープレビューとして公開しています。HTMLRewriter で bridge.js を配信時のHTMLに注入し、選んだツールパックを登録する仕組みで、用意されているパックは2つです。

• Content Credentials — ページ内画像のC2PAマニフェストを読み取ってエージェントに渡す。ただし暗号学的な署名検証は行わず、結果には signatureVerified: false が付く。「来歴情報が読める」だけで、真正性が検証されたわけではない
• Site MCP Server — サイト自身のMCPサーバーのツールをブラウザ内エージェントへ中継する。既存のMCPエンドポイント（既定では同一オリジンの /mcp）があることが前提で、未設置なら別途実装が必要

「オリジン側の改修は不要」と説明されますが、これが掛かるのはスクリプト注入とブリッジの部分までです。Site MCP Server を使うなら、結局サイト側にMCPサーバーの実装が要ります。

また、Cloudflare独自なのは「WebMCPツールをエッジで自動注入して提供する」レイヤーであって、注入されたブリッジがブラウザにツールを登録する際にはWebMCP提案のAPIを使っています。標準と非互換な独自APIではありません。それでも、このサービス自体が「WebMCP標準」なのではない、という区別は残ります。

サイト側では今すぐ有効化して試せますが、実際に使われるには呼び出す側の対応が必要で、そこはまだ実験段階です。標準の提案、ベンダーの実装、試すための環境。この3つは分けて理解する必要があります。

セキュリティは未決の論点が残る

WebMCPは新しいブラウザ権限を付与しません。実行に使われるのは、いま訪問している人のオリジンとログインセッションの範囲内です。Permissions Policy の tools を使えば、このAPI自体を使わせない制御もできます。

ただし、「権限が増えない」ことと「安全である」ことは別です。ツールの実装がバックエンドの認可チェックや通常のUIでの入力検証を迂回していれば、ログインセッションを使って本来意図しない操作が実行されうる。各ツールは、通常のフォーム経由と同じ認可と検証を必ず再適用する必要があります。Permissions Policy は「APIを使えるか」を制御するもので、個々の業務操作の正当性を保証する仕組みではありません。

そして仕様自身が、最も重要な限界を明記しています。

ツール名や説明文、入力形式、戻り値を使ってエージェントの判断を誘導できてしまいます。プロンプトインジェクションのWeb版と言えるものです。標準化されるのは受け渡しの方法であって、中身を確かめるのは使う側の仕事のまま残ります。

いま着手すべきこと

ここで、提案元であるGoogle Chromeチームのセッションにあった前置きが効いてきます。

具体的には次の4点が挙げられています。

1. セマンティックHTMLを改善する
2. 堅牢なアクセシビリティ標準にフォーカスする
3. ページパフォーマンスを改善する（Core Web Vitals）
4. サイト全体で良いUXフローを整える

そして「これらが揃っていれば、すでにエージェント対応サイトへの道の半分まで来ている。それらが揃って初めて、WebMCPについて考え始めることが意味を持つ」と続きます。

新しい技術を導入する前に、まず基礎を整える。今のサイトの基礎を整えることが、AI対応そのものであるという点は、投資判断において重要です。アクセシビリティ改善の効果を説明する新しい根拠にもなります。

エージェントの流入をどう扱うか

運用面では、エージェント経由のアクセスをどう位置づけるかという論点があります。

従来のボット管理も「一律に弾く」ものではありませんでした。Googlebot のように運営主体を検証できるクローラーは許可対象にでき、実際の運用は検証状態・挙動・用途に応じてポリシーを分けています。AIアクセスについても、検索用・エージェント用・学習用といった目的別の分類が進んでいます。

したがって論点は、AIエージェントをその分類のどこに置くかです。一律に許可するのではなく、運営主体の検証、アクセス目的、利用者単位の認可に応じてポリシーを設計する。既存の認証・認可、入力検証、レート制限は維持した上で、正規と判断したアクセスには構造化された操作手段を用意する、という順序になります。WebMCPを導入すればアクセスの正当性が保証される、という話ではありません。

計測の前提も変わりつつある

Chromeの実験的な宣言型APIとそのExplainerには、フォームの送信イベントがエージェント起因かどうかを示す SubmitEvent.agentInvoked が提案されています。ただし現行のW3C Community Group Report では宣言型APIの節がまだTODOで、これも規定されていません。「誰が入力したか」を一般に判別できるわけでもありません。

それでも、こうした識別手段が検討されていること自体が、アクセス解析の前提が変わりつつあることを示しています。

数字で見る現在地

公表されている調査から、出典と標本の性質を含めて整理します。

数値を読む際の注意点を2つ添えます。

McKinseyの44%は米国消費者全体ではなく、AI検索利用者の中での割合です。またAhrefsの調査では「AI Overviewが表示されたキーワードのうち32.3%がYMYLに分類される」という別指標があり、YMYLキーワードにおける表示率（34.3%）と混同されやすくなっています。

3つ目の「未着手が約20%」についても、裏返して「8割が着手済み」と読むことはできません。この種の調査の「着手」には情報収集や検討段階が含まれうるため、実際に施策を運用している割合はこの数字からは分かりません。読み取れるのは「関心そのものは相応に広がっている」ということまでで、着手の早さが業績や競争優位に結びつくかどうかは、この調査だけでは判断できません。

なお、WebMCPの効果について「処理時間が8割カットされる」といった数値が流通していますが、出典が確認できません。提案元のGoogleも「大幅に向上させる」としか述べておらず、定量値を出していません。この種の数字は使わず、「画面から操作を探り当てる工程が減るので、速く確実になりやすい」という定性的な説明に留めるべきです。

まとめ

標準化の行方はまだ未知数です。複数社が参加するコミュニティグループでの提案とはいえ、2026年8月時点で公表されている実装とオリジントライアルは Chromium系ブラウザが中心であり、クロスブラウザ標準として普及するかは確定していません。

それでもこの動きを注視すべき理由は、「機械が求める情報と操作に、迷わずアクセスできる状態」という要件を、自社サイトに対して明示的に突きつけてくるからです。

どのツールを公開すべきかを設計することは、「自社サイトで、外から見て価値のある操作と情報は何か」を棚卸しすることに等しく、inputSchema を定義することは自社のデータ構造を言語化することに等しい。description を書くことは、その機能の存在意義を一文で説明できるかを問われることに等しい。

その過程で、本来持つべきなのに持っていなかったコンテンツやデータが浮かび上がります。それを埋めれば、人間の訪問者にとってもAIにとっても価値が上がる。この循環が回り始めることが、望ましい姿だと考えています。

技術の名前は今後も変わり続けます。機械が正確に読める基盤を整え、そこにしかない一次情報を置く。この原理原則を握っていれば、次に何が来ても慌てずに済みます。WebMCPは、その原則を「情報」だけでなく「操作」の領域にまで広げた提案です。