WebMCPとは？AIがサイトを操作する仕組みと対応状況

WebMCP は、サイトでできる操作を AI に伝える仕組みです。 「商品を探す」「カートに入れる」などの使い方を、サイト側から案内できます。 人の代わりに操作する AI を「AI エージェント」と呼びます。AI が画面からボタンの意味を推測する負担を減らすための仕組みで、操作の成功を保証するものではありません [1]。

自社サイトも対応したほうがよいのか迷ったら、まず使っているサービスと、任せたい操作を確認します。Shopify の対象ストアのように基盤側が対応する場合もあれば、自社で機能を追加する場合もあります。2026 年 9 月 4 日版は W3C のコミュニティグループによる草案です。

W3C の正式な標準ではなく、正式な標準化の手順にも入っていないと明記されています [1][4]。

ブラウザや各社サービスの対応も、同じ意味の「対応済み」ではありません。試験に登録すれば使える場合、特定のアプリだけで使える場合、今後の予定として発表された場合があります。2026 年 7 月以降の更新を含め、9 月時点の状況を整理します。導入の判断では、表の名前だけでなく、対象と条件を確認してください。

1. WebMCPで変わるサイトの操作

サイト側が操作の名前と必要な入力を伝えれば、AI が使い方を探しやすくなります。 たとえば、検索欄を画面から探す代わりに、商品を検索する機能と入力条件を受け取れます。

Chrome の案内は、画面のボタンや入力欄の目的を、サイト側から伝える方法として説明しています [6]。

公式の説明（要約）: サイト側から、ボタンや入力欄の目的を伝えられます。[6]

「商品を検索する機能です」「検索語を入力してください」といった案内があれば、AI は操作を選ぶ材料を得られます。ただし、説明を誤解したり、条件に合わない入力をしたりする可能性は残ります。サイト側では、受け取った入力と操作権限を確認します。

メニュー表にたとえるなら、料理の名前だけでなく、注文に必要な条件も書くイメージです。実際の WebMCP では、操作の説明と入力の形式をツールとして登録します。仕様の案内では、既存のプログラムや入力フォームを使う方法が示されています [2]。

公式の説明（要約）: 既存のプログラムや入力フォームを、説明付きのツールとして公開できます。[2]

「ツール」は、AI が呼び出せる一つの機能を指します。商品検索なら検索条件を受け取り、結果を返します。新しい画面を必ず作るという意味ではありません。人が普段使う画面や、すでにある処理を生かしながら、AI に使い方を伝えます。

登録方法は 2 つあります。JavaScript という画面の処理用の言語で機能を登録する方法と、HTML の入力フォームに説明を付ける方法です。技術資料では前者を「命令的 API」、後者を「宣言的 API」と呼びます。以下では正式名も残しますが、サイト運営者は「プログラムで登録」「フォームに説明を追加」と考えれば、違いを追えます。

2. 操作をAIに伝える二つの方法

2026 年 9 月の草案では、機能の登録に document.modelContext を使います。 登録、一覧の取得、実行の 3 つが中心です [1]。次の表は開発担当者への確認用です。自分でコードを書かない場合も、古い資料と名前が違うことを確認できます。

メソッド / 属性	役割
registerTool(tool, options)	ツールを登録する。name (英数字と _ - .、1〜128 文字)、description、inputSchema (JSON Schema)、execute (Promise を返す関数)、annotations を渡す
getTools(options)	登録済みツールの一覧を取得する
executeTool(tool, input, options)	ツールを実行する
toolchange イベント	ツールの登録・解除を通知する
annotations	readOnlyHint (読み取り専用) / untrustedContentHint (信頼できない内容を含む) / consequentialHint (取り消せない結果を伴う) の 3 つ

以前は navigator.modelContext という名前でした。変更を提案した PR #184 は 2026 年 5 月 27 日に取り込まれ、ページを表す document の下へ移りました [3]。機能はウィンドウ全体ではなく、開いているページに属するという考え方です。

Chrome の 2026 年 9 月 1 日更新の案内も、document 版を使っています [7]。

2026 年春の解説や、未対応環境を補うプログラムである polyfill には、古い名前が残る場合があります。初期提案の provideContext や clearContext も、現行の登録方法とは違います。登録を解除する際は、registerTool に渡す AbortSignal を使います。

動かない場合は、参考記事の公開日だけでなく、対象の仕様と実際の実行環境を合わせて確認します。

プログラムで登録する方法は草案に手順がある

JavaScript で document.modelContext.registerTool({...}) を呼び、操作の説明と処理を登録する方法です。草案に動作の手順が書かれています。Chrome の案内には、公開先を制限する exposedTo と、登録を解除するための signal もあります [7]。

オリジンは、接続方式、ドメイン、ポート番号を組み合わせたサイトの区切りです。公開先の指定は、信頼する相手に機能を渡すために使います。

フォームに説明を付ける方法は草案に未完成の部分がある

フォームを使う方法では、<form> に toolname、tooldescription、toolparamdescription、toolautosubmit などの説明を付けます。ただし、草案のこの節は未完成を示す TODO で、詳しい動きは別の説明資料へ案内されています [1][2]。 プログラムで登録する方式と、同じ完成度だと考えないでください。

Chrome の説明では、AI がフォームの機能を使うと、ブラウザが入力欄を埋めます。フォームは人にも見えたままです。toolautosubmit は自動送信を指定するもので、送信時には SubmitEvent の agentInvoked で AI による操作かを示します [7]。

入力補助と送信は別の行為です。予約や注文などでは、どの時点で人の確認を必要とするかを設計します。

ChatGPT のデスクトップアプリは、2026 年 9 月時点ではフォームへの説明追加方式に未対応で、JavaScript の registerTool を使います [15]。フォームに属性を付けただけでは、ChatGPT で使えるとは限りません。

対応を依頼する際は、どの AI とブラウザで試すかを先に伝えてください。

3. サイト側に必要な安全対策

機能の説明に「安全」と書くだけでは、安全な動作にはなりません。 草案は、説明と実際の処理が一致する保証はないとしています。AI を不適切な操作へ誘導する指示を、説明文や結果に混ぜる攻撃も扱っています [1]。このような誘導をプロンプトインジェクションと呼び、草案では 3 類型に分けています。

仕様が指摘するのは、機能の名前や説明を、そのまま実際の動作の証明として信用できないという点です。

公式の説明（要約）: ツールの説明と実際の処理が一致する保証はありません。[1]

たとえば「商品情報を見る」という名前の処理が、実際にはカートを変更する可能性もあります。公開する側は、説明と処理が一致するように作り、利用する側も必要な確認を行います。「読み取り専用」の目印だけで、変更処理が禁止されるわけではありません。

代表的な問題を、次の表に整理します [1]。英語名は技術資料との照合用です。右側の説明を読み、どこで確認が必要かを開発担当者と相談できます。

リスク	内容
Tool Poisoning (メタデータ攻撃)	ツールの説明文に、エージェントを誘導する指示を仕込む
Output Injection	ツールの出力に、次の行動を操作する指示を混ぜる
Tool Implementation as Attack Targets	ツールの実装そのものを攻撃の踏み台にする
Misrepresentation of Intent	「読み取り専用」と宣言して書き込みを行う、など意図の偽装
Privacy Leakage Through Over-Parameterization	必要以上の入力パラメータで個人情報を引き出す
Violation of Same-Origin Boundaries	別のサイトの情報や機能へ、本来許可されない形でアクセスする

Chrome の案内も、AI の判断だけに安全性を任せることを勧めていません [7]。

公式の説明（要約）: AI の判断だけで、安全な動作を保証することはできません。[7]

AI の回答や判断には揺れがあります。利用者がログインしているか、操作する権限があるか、入力が正しいかは、通常の機能と同じようにサイト側で確認します。説明文を工夫することと、不正な操作を実際に止めることを分けて考えます。

OpenAI の案内も、既存のログイン確認、権限確認、入力の検査を使い、未対応のブラウザでも通常の画面を使えるようにすることを求めています [15]。たとえば、ほかの利用者の注文を変更できないことは、AI 向けの機能でも変わりません。AI だから特別に確認を省くのではなく、同じ操作ルールを通します。

4. Chrome・Edgeなどの対応状況

Chrome と Edge は試験提供中で、すべてのブラウザで使える状態ではありません。 一定の条件で新機能を試す仕組みを「オリジントライアル」と呼びます。対応するアプリや実験的な実装もあるため、試験提供と通常提供を分けて確認します。

ブラウザ / ベンダー	状況	一次ソース
Chrome	Google I/O 2026 (5 月 19 日) で発表。 オリジントライアルは Chrome 149 開始、blink-dev の Intent では 149〜156 。DevTools の Application パネルに WebMCP デバッグ (Chrome 149)。ローカル検証用フラグ chrome://flags/#enable-webmcp-testing	[5][6][8]
Gemini in Chrome	I/O の発表文は「 will soon support WebMCP APIs」。2026 年 9 月 7 日時点で「対応済み」の一次発表は見つからず	[5]
Edge	Edge 150 (2026 年 7 月 2 日) でオリジントライアル 。期限は 2026 年 11 月 17 日。「ネイティブ対応」の一次ソースは無し	[9]
Brave	Leo AI チャットで実験的に対応 (仕様の implementation-status より)	[2]
Mozilla (Firefox)	standards-positions で neutral (中立) 。「サイトが自動操作用の専用レーンを宣言する API」と評価しつつ、実装予定は無し	[10]
WebKit (Safari)	standards-positions で oppose (反対) 。2026 年 6 月 3 日に正式表明	[11]

Safari の基盤を作る WebKit は、別の改善方法を重視しています [11]。

公式の説明（要約）: ページの構造や操作の意味を共通の仕組みで伝え、人や読み上げ機能、AI に役立てるべきだ、という立場です。[11]

WebKit の考え方は、AI 専用の説明を増やす前に、ボタンや入力欄の意味を、通常のページの作り方で正しく伝えようというものです。HTML や ARIA は、画面の構造や役割を伝える仕組みです。人、読み上げ機能、AI が共通して使いやすくなる改善を求めています。

サイト運営者にとっては、未対応の Safari や Firefox でも、普段の操作ができることが大切です。iPhone を使う顧客がいるなら、AI 向けの機能を追加した後も、通常の商品検索やフォーム送信を確認します。「iPhone のすべてのブラウザやアプリが同じ実装」と広く決め付けず、実際に対象とする環境で判断してください。

Google は、WebMCP は議論が続いており、今後変わる可能性があると案内しています [7]。導入する場合は、作成費用だけでなく、仕様変更への対応も考えます。小さい機能から試し、どの版を参考に作ったかを残しておくと、変更箇所を追いやすくなります。

5. ChatGPT・Cloudflare・Shopifyの対応

2026 年 8 月には、ChatGPT、Cloudflare、Shopify がそれぞれ対応を発表しました。 AI を使うアプリ、サイトを配信するサービス、通販サイトの基盤では、担当する役割が違います。どこが対応したかを分けて見ると、自社で追加する作業を判断できます。

日付	誰が	何をしたか	一次ソース
2026-08-05 (発効 8-21)	Shopify	全 Liquid ストアフロント + Hydrogen (developer preview) で WebMCP ツールを公開 。Liquid ストア側の追加設定・インストールは不要。ツールは search_catalog / get_product / get_cart / update_cart / proceed_to_checkout など 10 種	[18][19]
2026-08-06	Cloudflare	ダッシュボードのスイッチ 1 つで WebMCP を有効化 する developer preview。HTMLRewriter で各 HTML レスポンスに bridge script 1 行を注入し、ブラウザ内で document.modelContext.registerTool() を呼ぶ。オリジンの変更は不要	[17]
2026-08-07	Cloudflare	自社の Radar (トラフィック統計サービス) を WebMCP 対応。URL スキャンやドメイン検索をエージェントから実行可能に	[17]
2026-08-25	OpenAI	ChatGPT デスクトップアプリ内蔵ブラウザの「Site tools」が WebMCP を実装 。「Site tools are ChatGPT's implementation of the proposed WebMCP standard」。GPT-5.6 Sol / Terra が必要、Enterprise / Edu 不可、iframe 内不可、宣言的 form 未対応	[14][15]
2026-08-25〜09-04	OpenAI + Chrome / Cloudflare / Shopify / Vercel / Render / Netlify	WebMCP Challenge (10 日間のハッカソン、$35,000 の現金賞、受賞発表は 9 月 23 日)	[16]
2026-09-08〜09	W3C / GS1	チューリッヒで「E-Commerce for Humans and AI Agents」ワークショップ。Shopify が WebMCP のセッションを担当	[20]

Shopify は、8 月 21 日から対象の Liquid ストアで機能を提供すると案内しています [18]。Liquid は Shopify の標準的なストア画面を作る仕組みです。Hydrogen で作るストアは開発者向けの試験提供であり、同じ条件の自動対応とまとめないようにします。

公式の説明（要約）: AI は商品検索やカート操作、購入手続きへの移動を行えます。[18]

公開される機能には、商品の検索、カートの確認や変更、購入手続きへの移動などがあります。ストア運営者が専用アプリを一つずつ入れる方式とは異なります。ただし、対応していることと、自社の商品選びで AI が実際に使うことは別です。

操作が誰のカートに反映されるかも重要です。Shopify は、買い物客が開いている状態の中で動くと説明しています [18]。

公式の説明（要約）: 操作は買い物客が開いている状態で行われ、通常のストアの処理を使います。[18]

ここでいうセッションは、利用者がサイトを開いて操作している一続きの状態です。AI が別の見えないカートを作るという説明ではありません。通常のストアの操作を通じて、利用者のカートを扱います。購入手続きへ進むことと、支払いを完了することも分けて考えます。

同じ画面の状態で処理が動いても、すべてのツールの実行が、クリックとして記録されるとは限りません。結果として画面やカートが変わった記録と、どのツールを呼んだかの記録は別です。計測の確認では、この違いを残します。

Cloudflare は、配信するページに小さなプログラムへの参照を加える方式を説明しています [17]。サイトの元のコードを直接変えずに試せる点が特徴です。

公式の説明（要約）: 有効にすると、配信する HTML に bridge script を読み込む参照を加えます。[17]

管理画面で有効にすると、HTMLRewriter というページを書き換える仕組みで、各 HTML に 1 行を追加します。その行から読み込む bridge script が、ページと WebMCP をつなぎます。難しい名前は、配信するページに処理を足すための部品名と考えてください。

プレビューには 2 つのツールパックがあり、どちらもブラウザ内で動くと説明されています [17]。配信サービスが対応したからといって、自社のすべての業務操作が自動で適切なツールになるとは限りません。公開される機能の一覧と、入力、結果を確認します。独自のフォームや画面の作り方によって、追加の検証が必要になる場合があります。

6. Lighthouseでの検査項目

Lighthouse には、AI がページを使う際の状態を調べる項目があります。 Lighthouse は、ページの速度や使いやすさなどを確認するツールです。2026 年 5 月からの Agentic Browsing という分類には、WebMCP に関する 3 つの確認項目があります。

監査	見ているもの	位置づけ
Registered WebMCP tools	ページで登録されている WebMCP ツールの一覧 (命令的・宣言的の両方)	informational (情報表示)
Forms missing declarative WebMCP	toolname と tooldescription が無い form の列挙	informational。「現時点では警告にならない」と明記
WebMCP schema validity	ツールが受け取る入力形式の記述が適切か	—

Lighthouse v13.2.0（2026 年 5 月 1 日）で分類と 3 項目が追加され、v13.3.0（5 月 7 日）で初期設定に入り、v13.4.1（7 月 20 日）で document.modelContext と PageSpeed Insights API に対応しました [13]。

同じ分類には、llms.txt の有無や、AI が扱う際のページの使いやすさ、表示の安定性も含まれます。古い版で調べると、確認項目が違う場合があります。

Google は、これらは実験的な項目で、提案段階の仕様に基づくと案内しています [12]。通常の速度評価のような 0〜100 の点数ではなく、該当項目の比率で表示され、通常の Performance スコアには影響しません。診断に表示されることと、検索で上位になる条件は別です。

診断で未対応と表示されたら、すぐ全部実装する必要はありません。情報を表示するだけの項目もあります。自社で必要な操作に関係するか、対象の AI で使えるかを確認します。診断項目に入ったから、将来必須になると予測して契約や改修を決めないでください。

7. MCPとWebMCPの違い

MCP は AI とサービスをつなぐ仕組み、WebMCP は開いているページの操作を AI に渡す仕組みです。 名前は似ていますが、導入する場所が違います。Google は、両者を組み合わせて考えられると説明しています [7]。社内のデータを検索したいのか、通販サイトのカートを操作したいのかで、相談する内容が変わります。

観点	MCP (Model Context Protocol)	WebMCP
動く場所	サーバー (バックエンド)	ブラウザ (いま開いているページ)
必要なもの	MCP サーバーを立てる	ページのスクリプトに registerTool を書く (または form に属性)
寿命	接続先のサービスとして提供。実行形態による	タブが開いている間だけ (ephemeral)
認証	サーバー側で実装	ユーザーのログイン状態をそのまま使う
2026 年の動き	7 月 28 日に大改訂 (ステートレス化、認可強化、Tasks の拡張化)	草案の更新が続く (7/21、8/14、8/19、8/26、9/4)

MCP は 7 月 28 日の改訂で、通信の状態を持ち続ける方式から、要求と応答を中心とする方式への変更を説明しています [21]。専門的にはステートレス化と呼びます。認可の強化や Tasks の扱いも含む、MCP 側の変更です。WebMCP の API を同じように変更する話ではありません。

Shopify も、WebMCP の機能と MCP サーバーを別に案内しています [19]。

開発を頼む際は、「MCP に対応したい」だけでなく、AI に何をしてもらうかを伝えます。社内のデータや外部サービスへの接続と、利用者が開いているページでの操作では、設計と確認の対象が違います。WebMCP 用の別サーバーは必須ではありませんが、注文や予約を保存する既存のサーバー処理が不要になるわけではありません。

8. 古い説明を読むときの注意点

古い資料を使う際は、API の名前、試験提供の条件、対応予定と対応済みの違いを確認します。 7 月以前の説明を参考にする場合も含め、特に間違えやすい 3 点を整理します。

1. Chrome 150 での非推奨化と、仕様の変更日を混同しない。 二次記事にはそう書かれていますが、Chrome 150 のリリースノートにも Chrome のドキュメントにも、その記述はありません。事実として確認できるのは「仕様が 5 月 27 日に document へ移動し、Chrome のドキュメントは document 版だけを記載している」ところまでです。
2. Edge の通常提供と試験提供を分ける。 Microsoft の一次ソースで確認できるのは「Edge 150 でオリジントライアル (期限 11 月 17 日)」までです。
3. Gemini in Chrome の対応予定を、対応済みと書かない。 I/O の発表文は「will soon support」で、9 月 7 日時点で対応済みの発表は見つかりません。ChatGPT デスクトップの Site tools のほうが先に対応しました。

ニュースの見出しに「対応」とあっても、本文では試験提供や今後の予定と書かれている場合があります。仕様書、ブラウザの案内、実際に使うアプリの案内をそれぞれ確認します。日付と対象が分かれば、違う条件の説明を混ぜにくくなります。

9. 自社で導入するか考える

まず、自社で AI に任せたい操作と、現在困っている箇所を決めます。 計測できる範囲を確認し、基盤の対応状況と合わせて導入を考えます。判断材料は次の 3 つです。

1 つ目は、利用中の基盤です。Shopify なら Liquid と Hydrogen のどちらか、Cloudflare なら試験提供の条件と公開される機能を確認します。自社実装なら、document.modelContext を使い、対象のブラウザや ChatGPT デスクトップで試します。

Safari などの未対応環境では、通常の画面を使えるように残します。基盤が対応済みでも、運用上の確認がなくなるわけではありません。

2 つ目は、変更に対応できる範囲です。仕様は議論中で、フォーム方式の草案には未完成の部分があります。半年後にも同じコードで動く保証はありません。一方で、必ず書き直しになるとも言えません。試す機能を小さくし、更新確認と修正を誰が担当するかを決めます。

3 つ目は、結果を確認できるかです。WebMCP はブラウザ内で動きますが、直接のツール実行が通常のクリックを発生させるとは限りません。録画で画面の変化を見られる場合でも、ツール名、入力、成功・失敗を知るには追加の記録が必要な場合があります。AI か人かの分類も、取得できる情報に左右されます。 導入前に、何が見え、何が見えないかを確認してください。

作業は、次の順で進められます。記録の件数が少ない場合は、期間だけで結論を出さず、実際に対象の操作を試した回数も確認します。

順番	やること	判断できること
1	計測できる範囲を確認し、人間 / AI エージェント / bot の分類と、記録された訪問数を 1 か月見る	記録できた範囲で対象の訪問があるか
2	AI エージェントのセッションを録画で見て、どこで止まっているか (検索・フォーム・カート) を確認する	画面で止まる場所があるか。原因は追加で確認
3	Lighthouse の Agentic Browsing カテゴリで、toolname の無い form を列挙する	宣言的 API を付けるとしたらどの form か
4	Shopify / Cloudflare は対象と公開ツールを確認。2 週間を目安に、実行記録と画面の変化を比較する	十分な実行があれば、対象の操作が改善したか
5	自前実装するなら document.modelContext.registerTool で 1 ツール (検索など読み取り専用) から。readOnlyHint を付け、既存の認証・入力検証をそのまま通す	仕様変更に追随できる規模か

順番 1 と 2 では、既存の計測で分かる範囲を確認します。順番 4 で変化が見えなかった場合も、ツールが使われたか、記録できていたかを先に調べます。試行がない状態では、効果の有無を比べられません。必要な操作が確認できてから、自社実装を追加するか判断します。

10. AgentSignalで操作を確認する

AgentSignal では、記録できた訪問の分類と、画面上の操作を確認できます。 人間・AI エージェント・bot の 3 種類の分類は、取得できた情報に基づくものです。すべての AI を見分けたり、WebMCP のツール呼び出しをすべて録画したりする保証はありません。

画面に現れた変化と、サイト側で保存した実行記録を合わせると、検索やカートで止まった箇所を調べやすくなります。

無料の AIO チェック の結果だけで、WebMCP の登録ツールやすべての実行結果を確認できるとは考えないでください。対応度を確認する項目と、実際の操作を試す作業は分けます。計測タグの設置は 計測タグを設置する、ページを読むプログラムと操作する AI の違いは AI クローラーの種類と設定 で説明しています。 まず、既存の記録で確認できることから始めます。

11. 商品検索を使った導入例

最初に試すなら、情報を探すだけの操作から始めると確認しやすくなります。 商品の検索や在庫の確認なら、注文を確定する操作と分けて試せます。どのツールにも同じ確認で十分という意味ではありません。変更を伴う機能を増やす際は、別に検証します。

たとえば、利用者が AI に「指定の条件に合う商品を探して」と頼む場面を考えます。通常の画面操作なら、AI は検索欄や絞り込み条件を探します。WebMCP の商品検索ツールがあれば、AI は説明と入力条件を読み、その機能を呼び出せます。結果に商品名や条件が返れば、利用者へ候補を示す材料になります。

ここで確認するのは、ツールを登録できたかだけではありません。指定した条件が正しく伝わったか、結果が実際の商品情報と合うか、該当商品がない場合に分かる返答をするかも見ます。使える機能の一覧に名前が出ても、検索結果が誤っていれば利用者の目的は達成できません。

11-1. 成功の条件を決める

試す前に、同じ作業を人が行った場合の結果を確認します。AI が返した候補が正しいかを比べるためです。価格、在庫、対象地域などが変わる商品なら、確認した時点の情報も残します。古い画面の記録と現在の結果を比べて、AI の間違いと決めないようにします。

検索の成功は、正しい候補を返すことです。カート追加の成功は、正しい商品と数量が、対象の利用者のカートに反映されることです。購入手続きへの移動と、注文の確定も別々に確認します。まとめて「買い物できた」と報告すると、どこまで試したか分からなくなります。

操作	確認したい結果	別に確認すること
商品検索	指定条件に合う候補が出る	該当商品がない場合の説明
商品詳細の確認	現在の価格や条件と一致する	古い結果を使っていないか
カートの確認	利用者の現在の内容が分かる	ほかの利用者の情報を見られないか
カートの変更	指定商品と数量が反映される	重複実行や在庫不足の扱い
購入手続きへ進む	正しい手続き画面へ移る	支払い完了とは区別する

11-2. 入力の間違いも試す

正常な入力だけでは、利用者が困る場面を見落とします。空の検索語、存在しない商品、利用できない条件なども確認します。結果がない場合に、理由を伝えず成功と返すと、AI が別の操作を進めてしまう可能性があります。

入力の説明は、必要なものだけにします。商品の検索に個人情報が必要ないなら、余分な入力を求めません。ツールの説明を詳しくすることと、受け取る情報を増やすことは別です。通常の検索画面でも不要な情報を、AI 向けだからという理由で集めないようにします。

11-3. 未対応の環境も確認する

WebMCP に未対応のブラウザでは、通常の検索やフォームが使えることを確認します。追加のプログラムが動かなくても、ページ全体が使えなくならない作りにします。既存の利用者にとって、AI 向けの対応が不具合の原因にならないことが大切です。

開発担当者への確認では、対象ブラウザと版を一覧にします。試験機能を有効にした環境で成功した結果を、すべての利用者に公開済みと表現しないでください。試験の期限や条件がある場合は、その情報も作業記録へ残します。

12. 制作担当者への依頼と確認

「WebMCP 対応をお願いします」だけでなく、試す操作と対象環境を伝えます。 機能名だけで頼むと、フォームに説明を追加して完了とする提案と、アプリ上での実行まで確認する提案が混ざります。最初に受け取りたい結果を決めておきます。

自社サイトの商品検索を、対象の AI から使えるか小さく検証したいです。現在使っている基盤で、すでに公開されている WebMCP ツールがないか確認してください。追加する場合は、検索だけを対象にし、注文や支払いは含めません。参考にした仕様の日付、対象のブラウザとアプリ、登録した機能、試した入力と結果を記録してください。未対応の環境で通常の検索が使えることも確認をお願いします。

この依頼では、実装に加えて動作の確認も求めています。自社で用意するのは、試したい検索条件と、正しい結果の判断基準です。商品の条件が複雑なら、担当者が回答を確認できる例を用意します。開発担当者だけに商品の正しさを判断させないようにします。

12-1. 受け取る記録

記録には、ツール名、入力条件、実行した日時、成功・失敗、画面やデータに起きた変化を残します。利用者の個人情報や機密情報を、そのまま診断用の記録へ保存する必要はありません。必要な情報だけを残す方法を担当者と決めます。

録画は、画面で何が起きたかを見るのに役立ちます。一方、画面に変化がない検索や、直接処理を呼び出す操作は、それだけでは分からない場合があります。録画と実行記録を結び付けられるかを確認し、見えない操作を「起きていない」と判断しないでください。

12-2. 仕様変更への対応

検証が終わったら、仕様やサービスの更新を誰が確認するかを決めます。草案の変更、試験提供の終了、対象アプリの対応変更によって、再確認が必要になる場合があります。参考にした URL と日付を残しておけば、どの説明を基に作ったかを後から追えます。

保守を外部へ頼むなら、どの程度の変更が契約に含まれるかを聞きます。機能名の変更と、操作方法全体の変更では作業量が違います。すべてを予測する必要はありませんが、変更を見つけた際の連絡先と、対応を決める担当は決めておけます。

12-3. 対応を広げるか判断する

検証で役立った操作があれば、次に広げる対象を選びます。単にツールの数を増やすより、利用者が実際に困る作業を優先します。検索は使えたがカートで止まったなら、その原因が入力条件、権限、画面の分かりにくさのどれかを調べます。

WebMCP を追加せず、通常のフォームの見出しやエラー表示を直すほうが適切な場合もあります。AI 専用の機能を増やすことを前提にせず、人が使っても分かりやすい状態を保ちます。検証した結果と、次の作業の理由がつながっていれば、対応範囲を増やす場合も、いったん保守だけを続ける場合も判断しやすくなります。

まとめ

WebMCP は、サイトでできる操作を AI に案内する仕組みです。 まだ草案のため、対象の環境で小さく試し、通常の画面と操作の確認も続けます。

• WebMCP は、サイトの機能 (JavaScript の関数・HTML の form) を AI エージェント向けの「ツール」として宣言する仕組み。W3C コミュニティグループの草案で、標準ではなく標準トラックにも乗っていない (2026 年 9 月 4 日版)
• 現行 API は document.modelContext (registerTool / getTools / executeTool)。5 月 27 日に navigator から移動した。provideContext や navigator.modelContext を書いた古い記事は現行仕様と違う
• プログラムで登録する方式は草案に手順があり、フォーム方式は仕様上 TODO。ChatGPT は宣言的 form に未対応
• Chrome 149〜156、Edge 150 はオリジントライアル。アプリ側の対応条件も別に確認する。Mozilla は中立、WebKit は反対。Gemini in Chrome は「まもなく」
• 実装は先行: Shopify 全 Liquid ストア (8/21 発効)、Cloudflare スイッチ 1 つ (8/6)、ChatGPT デスクトップ Site tools (8/25)、WebMCP Challenge (受賞発表 9/23)。Lighthouse に Agentic Browsing 監査
• 試す操作、対象環境、記録方法を決める。ブラウザ内での実行でも、すべてがクリックや録画に残るとは限らない