WebMCPは、ページがAIエージェントに操作の「道具」を差し出す実験段階の仕組み ── 自社のページに自分で選んでいない道具や差し込みが入っていないか確かめる13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — WebMCPは、ページがAIエージェントに「操作の道具」を差し出す、実験段階の仕組み
   1. 原文が書いていること
   2. まだ、実験段階である
   3. 差し込まれる1行と、外す仕組み
   4. 呼び名と日付が、2本の記事で揃っていない
2. 02 なぜ・背景 — 「ボタンを推測する」エージェントに、使い方を先に渡す
   1. エージェントは、HTMLから「どのボタンが何か」を推測している
   2. 道具があると、2回の呼び出しで済む
   3. 経緯を日付で並べる
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. WebMCPと、MCPの違い
   2. 道具（ツール）と、document.modelContext
   3. 宣言型と命令型の、2つの書き方
   4. パックと、橋渡しの部品
   5. Origin Trialと、実験用のフラグ
4. 04 型別 — 道具がページに出る3つの経路と、それぞれの見つけ方
   1. 🅰 適用範囲 — どんなサイトに当てはまるか
   2. 🅱 この記事が測っていないこと
   3. 🅲 手順 — 3つの経路を、3つの見え方で探す
   4. 3の経路は、「自分のソース」を見ても見つからない
   5. ブラウザが対応していないと、道具は登録されない
   6. 別のサイトの枠（iframe）には、初期値で道具を許さない
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 道具を出さない・自分で書く・提供元の機能に任せる
   1. 入れるか決める前に、見直す3つのこと
7. 07 当サイトで確かめたこと — 公開ページ8本のソースと、読み込むスクリプトを調べた結果
   1. 8ページのソースに、WebMCPの道具は無かった
   2. 読み込んでいるスクリプトの中身にも、登録の書き方は無かった
   3. 当サイトで確かめていないこと
8. 08 このテーマは、ここまで
   1. WebMCPを、7月に整理した記事
   2. 入り口の名前は、7月と、いまの文書で違う
   3. エージェントが「実行する」側へ動く、という話
   4. 自分で選んだつもりのない設定が、効く話
   5. 2026年10月28日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — WebMCPは、ページがAIエージェントに「操作の道具」を差し出す、実験段階の仕組み

2026年10月21日に、Cloudflareが公式ブログで、ECの基盤を提供するCommerce.comと一緒に、店のページをAIエージェントに対応させる取り組みを書いた。題は「How Commerce.com and Cloudflare are getting storefronts ready for AI agents」（訳: Commerce.comとCloudflareは、店のページをAIエージェントに対応させようとしている）で、書いたのはJenny Lea、Max Brosnahan、Matthew Conroyの3人である。この記事は、取り組みの紹介よりも、自分のサイトに、自分で選んでいない「道具」や「差し込み」が入っていないかを、ページのソースで確かめる方法に絞る。

原文が書いていること

原文の内容を、3つに分けて書く。

• WebMCPは、AIエージェントに、ページ上の構造化された「道具」（原文の例はsearch_products）を渡す、Google発のブラウザ標準だと書く。
• Cloudflareは、8月に、WebMCPをCloudflare側（配信の途中）で実装する機能をベータで出した。オンにすると、サイトの持ち主がコードを書かなくても、道具が使える。
• Commerce.comは、10万に近い数のドメインをCloudflareで動かしていて、全店で一度にオンにできるかを尋ねた。

まだ、実験段階である

WebMCPを、原文は、早期のプレビューにある実験的な標準だと書く。使える場所は、次のように並んでいる。

"Because WebMCP is still an experimental proposed browser standard in early preview, it’s currently available behind experimental Chrome flags (chrome://flags/#enable-webmcp-testing), in Chrome Origin Trials, in some agentic browsers, and across developer environments like Cloudflare Kitesurf."

（訳: WebMCPは、まだ、早期のプレビューにある、提案中の実験的なブラウザ標準である。そのため、いまは、Chromeの実験用フラグの裏、ChromeのOrigin Trial、一部のエージェント型ブラウザ、Cloudflare Kitesurfのような開発環境で使える。）

Chromeの開発者向け文書も、同じ向きで書く。

"WebMCP is under active discussion and subject to change in the future."

（訳: WebMCPは、活発に議論されていて、今後、変わることがある。）

仕様の草稿のページは、2026年10月27日の日付の「Draft Community Group Report」（訳: コミュニティグループの報告の草稿）で、位置づけを次のように書く。

"It is not a W3C Standard nor is it on the W3C Standards Track."

（訳: これは、W3Cの標準ではなく、W3Cの標準化の道筋にも載っていない。）

つまり、WebMCPは、まだ標準として決まった仕組みではない。誰が提案したかについて、Cloudflareの記事は、Googleから出たブラウザ標準だと書き、仕様の草稿の編集者の欄には、MicrosoftとGoogleの人が並ぶ。提案の経緯は、開いた文書では確かめられなかった。

差し込まれる1行と、外す仕組み

8月の記事（2026年8月6日・書いたのはWill Rowe）は、オンにしたときに起きることを、こう書く。

"Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin."

（訳: オンにすると、ブラウザのエージェントが、コードなしで、配信元には何も変えずに、サイトを使い始められる。）

仕組みは、配信するHTMLに、scriptタグを1行足し、そこから「橋渡しの部品」（原文でbridge）を読み込む形である。原文のタグは、src="/.webmcp/bridge.js"で読み込み先を指し、data-packsで有効にする道具のまとまりを、data-mcp-urlでサイトのMCPの窓口を指す。

10月の記事は、外す仕組みを書く。Commerce.comは、主なゾーンでWebMCPをオンにしたうえで、店のメタデータを調べる設定ルールを足す。店の持ち主が、Commerce.comの管理画面で「オプトアウト」（訳: 対象から外す）のスイッチを切り替えると、その店では、WebMCPが自動で外れる。

"Because Cloudflare evaluates these rules at the edge before serving the page, an opted-out store gets zero extra latency, no remote lookups, and no injected scripts."

（訳: Cloudflareは、ページを返す前に、配信の途中でこれらのルールを評価する。そのため、外れた店では、余計な待ち時間も、遠くへの問い合わせも、差し込まれるスクリプトも無い。）

呼び名と日付が、2本の記事で揃っていない

同じ機能を、8月6日の記事は「developer preview」（訳: 開発者向けのプレビュー）と呼び、10月21日の記事は「In August, we launched edge implementation of WebMCP in beta」（訳: 8月に、WebMCPを配信の途中で実装する機能を、ベータで出した）と書く。どちらも、発表の月は8月で、同じ機能を指しているように読める。ただし、呼び名が揃っていない理由は、原文に書かれていない。

02 なぜ・背景 — 「ボタンを推測する」エージェントに、使い方を先に渡す

エージェントは、HTMLから「どのボタンが何か」を推測している

原文は、WebMCPが要る理由を、いまのエージェントの動き方から書き始める。

"Most agents that shop for someone today work from a site’s HTML — they look at the page, guess which button does what, click, and try again when they get it wrong."

（訳: いま、誰かの代わりに買い物をするエージェントの多くは、サイトのHTMLを手がかりに動く。ページを見て、どのボタンが何をするかを推測し、押し、間違えたらやり直す。）

原文は、この動き方は遅く、テーマを変えただけで壊れることがあると書く。

道具があると、2回の呼び出しで済む

原文の例は、「防水のトレイルランニングシューズを、140ドル以下で、サイズ10で探して、カートに入れて」と頼む場面である。道具が無いと、エージェントは、人の操作をまねして、Cookieの案内に止められたり、選択肢を読み違えたり、人と自動を見分ける確認に引っかかったりする。道具があると、エージェントは、search_productsとadd_to_cartの2回の呼び出しで済む。カートは、利用者の今のブラウザで、その店のドメインの上で更新される。決済は、利用者が自分で押す、と原文は書く。

道具を出すと、エージェントが「推測する余地」が減る。その分、サイトの持ち主が決めた動きを、エージェントが実行する。これが、便利さと、確かめる必要の、両方の出どころである。

経緯を日付で並べる

開いた文書の日付を、古い順に並べた。

筆者の読みでは、Chromeの早期プレビューの募集（2月10日）から、CDNの機能、プラットフォームの一括の有効化まで、8か月ほどで進んだ。ただし、仕様の草稿は、標準としては決まっていない。進んだのは、使う側の仕組みが先に広がっていることで、仕様そのものが固まったことではない。

03 用語 — 出てくる言葉を、先にそろえる

WebMCPと、MCPの違い

名前が似ているMCP（Model Context Protocol）は、AIエージェントと、外のシステムをつなぐ、別の標準である。Chromeの文書は、2つの関係をこう書く。

"WebMCP is not an extension or a replacement of MCP."

（訳: WebMCPは、MCPの拡張でも、置き換えでもない。）

Chromeの文書の説明では、MCPは裏側（バックエンド）の機能向け、WebMCPは表側（ブラウザで見えるページ）の機能向けである。Cloudflareの10月の記事も、Commerce.comが両方を並べて使っていると書く。

道具（ツール）と、document.modelContext

道具は、名前、説明文、入力の形、実行する処理の4つを持つ、1つの機能である。ページのJavaScriptは、document.modelContextという入り口に、registerToolで道具を登録する。Cloudflareの2本の記事は、この入り口をdocument.modelContextと書く。当サイトが7月に書いたブログは、別の名前で書いていたので、08章で触れる。

宣言型と命令型の、2つの書き方

Chromeの文書は、道具を作る方法を2つ挙げる。命令型は、JavaScriptで登録する。宣言型は、HTMLのフォームに、toolnameとtooldescriptionの属性を足す。宣言型について、文書は、次のように書く。

"If you remove either the toolname or tooldescription HTML attribute, the tool is unregistered."

（訳: toolnameかtooldescriptionのどちらかのHTML属性を外すと、その道具は登録が外れる。）

パックと、橋渡しの部品

Origin Trialと、実験用のフラグ

Origin Trialは、ブラウザの新しい機能を、サイトごとに期間を限って試す仕組みである。WebMCPのOrigin Trialは、Chrome 149からだと、Chromeの文書が書く。

04 型別 — 道具がページに出る3つの経路と、それぞれの見つけ方

🅰 適用範囲 — どんなサイトに当てはまるか

道具を登録できるのは、ページのJavaScriptか、HTMLのフォームを書ける人である。ところが、Cloudflareの8月の記事は、オンにすると各HTMLの返事に1行を足すと書く。道具を使う画面（購入・予約・申込・問い合わせ）が無いサイトでも、設定がオンなら、足される。一方、Cloudflareを通っていないサイトでは、この経路は当てはまらない。通っているのに、設定をした覚えが無い場合は、確かめる価値がある。

🅱 この記事が測っていないこと

• WebMCPの道具が、エージェントに実際にどのくらい呼ばれているか（Chromeの開発者ツールに、呼び出しの記録の欄はあるが、この記事では、道具を持つサイトの記録を見ていない）
• Chrome以外のブラウザの対応の状況（開いた文書は、Chromeの話が中心で、ほかのブラウザの対応は確かめていない）
• 道具を出したサイトで、集客や売上がどう変わったか（原文に、数字は無い）

🅲 手順 — 3つの経路を、3つの見え方で探す

道具がページに出る経路を、筆者は3つに分けた。分け方は、出典に書かれたものではなく、確かめる場所を決めるための整理である。

3の経路は、「自分のソース」を見ても見つからない

3の経路は、配信の途中でHTMLに足される。だから、手元のテンプレートやCMSの編集画面を見ても、見つからない。見つけるには、実際に配信されたHTMLを取る。Cloudflareの8月の記事は、確かめ方を1行で書く。

curl -s https://your-site.example | grep webmcp

これは、サイトのHTMLを取り、「webmcp」を含む行だけを出すコマンドである。Cloudflareの記事は、オンにしたときに、足された行が見える、と書く。出ないときは、足されていない可能性が高い。ただし、取ったHTMLが目当てのページだったかは、先に題名で確かめる。遮断の画面や、別のページを取っていると、「無い」と読み違える（当サイトの外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけたの考え方である）。

ブラウザが対応していないと、道具は登録されない

差し込まれた橋渡しの部品は、ブラウザがWebMCPに対応していないと、何もせずに終わる。Cloudflareの10月の記事は、次のように書く。

"If a store's MCP server is offline or a customer's browser doesn't support WebMCP, the script exits. The storefront loads normally and human shoppers aren't affected."

（訳: 店のMCPサーバーが止まっているときや、客のブラウザがWebMCPに対応していないときは、スクリプトは終了する。店のページは普通に読み込まれ、人の買い物客には影響が出ない。）

だから、人が普通のブラウザで見ても、何も変わらない。道具が入っていても、画面の見た目から分からない。ソースを見るか、WebMCPに対応した状態のブラウザで開発者ツールを開くか、どちらかが要る。Chromeの文書は、DevToolsのApplicationパネルの中に「WebMCP」のペインがあり、「Available Tools」（訳: 使える道具）の欄に、そのタブで見つかった道具の名前と説明文が並ぶ、と書く。宣言型と命令型を、種類で絞る欄もある。

別のサイトの枠（iframe）には、初期値で道具を許さない

Chromeの文書は、許可の方針（Permissions Policy）について、次のように書く。

"The policy defaults to self, which allows tool registration in top-level and same-origin contexts, and disables it for cross-origin iframes."

（訳: この方針は、初期値がselfで、最上位と同じ生成元の場所では道具の登録を許し、別の生成元のiframeでは許さない。）

つまり、初期値では、別のサイトの部品（埋め込みの予約や決済の枠）が、自分のページの上で道具を登録することは、許されない。許すには、iframeにallow="tools"を足す。自分のページに、別のサイトの枠を埋め込んでいるなら、その枠のallowの指定に、toolsが入っていないかを見る。

05 明日、自社のサイトで確認できることチェックリスト

以下は、担当サイトに、自分で選んでいない道具や差し込みが入っていないかを確かめる13項目である。1〜5番目はソースと配信されたHTMLの検索、6〜7番目はChromeの開発者ツール、8〜9番目は見つけたものの読み方、10〜13番目は提供元への確認と、残す・外すの決め方である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。

• 担当サイトのトップページを開き、右クリックの「ページのソースを表示」で、画面全体を検索して「webmcp」と入力し、ヒットした数を書き留める
• 同じソースで「modelContext」を検索し、ヒットが0件か、あれば何行目かを書き留める
• 同じソースで「toolname」を検索し、フォームの属性として出てくる数を書き留める（引用符の種類で外れないよう、「=」は付けずに探す）
• ログイン、問い合わせ、検索、申込のうち、フォームのあるページを3つ選んで開き、1〜3番目の検索を同じように繰り返す
• ターミナルでcurl -s （自社のアドレス） | grep -i webmcpを1回実行し、行が出るかを見る（Cloudflareの記事の例に、大文字小文字を区別しない-iを足した形）
• WebMCPのフラグ（chrome://flags/#enable-webmcp-testing）をオンにしたChromeで担当サイトを開き、開発者ツールのApplicationタブにある「WebMCP」を選んで、「Available Tools」に並ぶ道具の数を数える
• 道具が並んでいたら、種類の絞り込みで、HTMLで書いた宣言型と、JavaScriptで書いた命令型の数を、それぞれ書き出す
• 見つかった道具の名前と説明文を、すべてメモ帳に書き写し、決済・個人情報・ログインに触れるものに印を付ける
• 見つかったscriptタグの読み込み先を1本ずつ見て、自社のサーバーの中か、他社のアドレスかを、書き分ける
• ホスティング、CDN、ECの管理画面を開き、「WebMCP」や「エージェント向けの機能」という名前の設定がオンかオフかを見る（Cloudflareでは、ダッシュボードの「Agent Readiness」の中の「WebMCP」）
• 制作会社やプラットフォームの提供元に、「自社のページにWebMCPの道具を足す機能があるか、あればいつオンにしたか」を、3行のメールで1通聞く
• 解析ツールで、ページビューが急に増えた日と、サイトの設定を変えた日を、1枚のメモに並べる
• 見つかった道具や差し込みを1つずつ「残す・外す・保留」に分け、担当者の名前と見直す日を書く

06 代替・他の選択肢 — 道具を出さない・自分で書く・提供元の機能に任せる

見つかったときの選び方を、表にした。右の列は、出典が書く内容と、筆者の読みを分けている。

入れるか決める前に、見直す3つのこと

道具を自分で出すと決めたときに、先に見直す点を、出典の記述から3つ挙げる。

• 決済と個人情報に触れる道具か。Chromeの文書は、購入のように、慎重にしたい操作には、利用者に確認の画面を出す仕組みを入れられると書く。また、道具の注釈に、影響の大きい操作を示すconsequentialHintと、状態を変えないreadOnlyHintがある。
• 道具が返す文章に、利用者が書いた文字が混ざらないか。文書は、利用者が書いた内容や外部のデータを返す道具には、untrustedContentHintを付ける、と書く。仕様の草稿も、道具の説明文や返す値に、悪意のある指示が紛れ込む危険を、項目として挙げる。
• 道具の名前と説明文が、短く、はっきりしているか。Chromeの文書は、字数の目安として、道具の説明文500字、引数の説明文150字、名前30字、1回の出力1.5K字を、挙げる。目安は、変わることがあるとも書く。

当サイトの無料ツールで補えることもある。ページが読み込むJavaScriptとCSSのファイルを調べて、中身の書き方を確かめるには、🔧 WEBページが読み込むJavaScriptとCSSのファイルを調べて、ソースの中身を確かめるツールが使える。このツールが調べるのは、書き方の問題で、WebMCPの道具を見つける機能ではない。ページ全体の診断なら、🔧 SEO・セキュリティヘッダー・アクセシビリティなどを一括で診断する、WEBサイト総合分析ツールがある。この診断の項目の一覧にも、WebMCPは出てこない。

07 当サイトで確かめたこと — 公開ページ8本のソースと、読み込むスクリプトを調べた結果

2026年10月28日の朝に、当サイトの公開ページ8本の、配信されたHTMLを取って、05章の1〜3番目を当てた。当サイトは、ページの配信にCloudflareの仕組みを使っていない。そのため、Cloudflareの差し込みの経路は当てはまらないが、ほかの経路が無いことも、ここで確かめた。

8ページのソースに、WebMCPの道具は無かった

開いたのは、トップページ、AI Ronのブログの一覧と記事1本、解説記事の一覧と記事1本、無料ツールの一覧とツール1本、お問い合わせの画面である。結果は次のとおりだった。

• 「modelContext」は、0件だった。
• フォームのタグに、toolnameなどの属性が付いたものは、0件だった。
• 「webmcp」は、ブログの一覧に1か所だけあった。記事の分類タグに、WebMCPという名前が付いたリンクである。道具の記述ではない。
• Cloudflareの例の読み込み先（/.webmcp/bridge.js）を直接開くと、404だった。

読み込んでいるスクリプトの中身にも、登録の書き方は無かった

8ページが読み込む外部のスクリプトは、同じものを1本と数えて31本だった。このうち30本の中身を取り、「modelContext」「registerTool」「webmcp」を探したところ、0件だった。ページの中に書いてあるスクリプト62か所も、0件だった。残る1本は、Googleのサインイン用の部品で、自動の取得を断られたので、中身を見ていない。

当サイトで確かめていないこと

• WebMCPに対応した状態のブラウザで、開発者ツールの「WebMCP」のペインを開いたか（開いていない）
• 会員ログインの後の画面や、公開していないページ（見ていない）
• 上の8ページ以外の、公開ページ（全ページは調べていない）
• 条件によって、あとから読み込まれるスクリプトの中身（取得した30本には含まれない可能性がある）

当サイトは、購入や予約の画面を持たない。それでも手順を当てたのは、差し込みも属性も、画面の見た目には出ないからである。

08 このテーマは、ここまで

AIエージェントが、サイトを「読む」から「使う」に動く話は、これまでにも書いてきた。

WebMCPを、7月に整理した記事

検索は「クリックする場所」から「エージェントが代わりに動く場所」になった — WebMCP・UCPとAgentic Commerce時代の実務チェックリストは、WebMCP、UCP、Universal Cartを、2026年7月10日の時点で整理した。この記事は、当時の対応状況を、Chrome 149のOrigin Trial、Firefoxは第3四半期の約束、Safariは第4四半期の予定、と書いた。今回開いた文書は、Chromeの文書とCloudflareの記事が中心で、Firefox、Safariの状況は確かめていない。

入り口の名前は、7月と、いまの文書で違う

7月の記事は、入り口のAPIをnavigator.modelContextと書いた。いまの文書は、Cloudflareの2本も、Chromeの文書も、仕様の草稿も、document.modelContextと書く。仕様はまだ草稿で、名前が変わることがあるので、05章の2番目の検索は、両方に共通するmodelContextで探す形にした。

エージェントが「実行する」側へ動く、という話

エージェント検索が来る — 検索は『答える』から『実行する』へ進化するは、題のとおり、検索が答えるだけでなく、実行する方へ進むという見立てを書いた記事である。Information Agentsが動き始めた — 24時間代理検索の時代、WEBディレクターが今すべきことも、同じ流れの話である。

自分で選んだつもりのない設定が、効く話

Cloudflareの設定が、自分で選んでいなくても効く例は、Cloudflareのデフォルト「AI bots ブロック」があなたのGEOを殺している — robots.txt無関係のインフラ層ブロックと、WEBディレクターが今すぐ確認すべき3つの設定と、Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つに書いた。筆者の読みでは、設定の中身が違っても、「自分で選んでいない記述や設定が、配信の途中で効いていないか」を確かめる形は、今回のWebMCPと同じである。

2026年10月28日 — この記事の確認日

この記事の内容は、2026年10月28日に、Cloudflareのブログ2本、Chromeの文書とブログ8本、WebMCPの仕様の草稿を開いて確かめた時点のものである。仕様や名前が変わったときは、日付つきで追記する。