WebMCPはサイトが道具を差し出す仕組み｜草案と決めること

AIが人の代わりにサイトを操作する機能は、すでに実装の段階に入っています。その操作はこれまで、画面に並んだボタンや入力欄をエージェントが見て、意味を推測しながらクリックしていく形で行われてきました。Chromeの公式ドキュメントはこのやり方をアクチュエーションと呼び、エージェントがサイトを相手にしているかのように手動のマウス操作と文字入力を模すことだと説明しています。リンクを1つ押すだけの作業から、購入を終えるような複雑な作業まで、人の操作をまねて進めるという意味です。

この前提を裏返す提案が WebMCP です。Chrome for Developers のドキュメントは一文でこう書いています。「WebMCP is a proposed web standard to help you build and expose structured tools for AI agents」。サイト側が構造化された道具を組み立ててエージェントへ差し出すための、提案中のWeb標準だという位置づけです。

この記事では、W3Cのコミュニティグループが公開している仕様草案と、Chromeの公式ドキュメントに書かれている範囲だけで3つを整理します。何が変わるのか。自社のサイトで対応するとしたら、どこに何を書くのか。そして、差し出す前に決めておかないと危ないのはどこか。確認日は2026年11月5日です。仕様は草案で、ブラウザ側も試験提供の段階にあります。導入を判断する前に、現在の記載を確認してください。

「推測して操作される」から「宣言して呼ばれる」へ

ドキュメントが挙げている利点は、精度の話です。該当箇所を引きます。「Instead of an agent reviewing the element, such as a button or a field, to understand its purpose, the website declares the element’s purpose, so it’s used as intended. This is more reliable than actuation, which may have numerous steps and leaves each step open to interpretation by the agent」。エージェントが要素を見て目的を読み取るのではなく、サイトがその要素の目的を宣言するので、意図どおりに使われる。手順が多く各段に解釈の余地が残るアクチュエーションより信頼できる、という説明です。

サイトを運営する側から見ると、変わるのは立場です。エージェントの自動操作は、これまで「来るもの」でした。ブラウザ側が利用者の指示で画面を操作しに来る流れについては、Gemini in Chromeが米国Androidへ全面展開。自動ブラウズ時代のWeb集客で扱いました。WebMCPは、そこに受け身ではない選択肢を1つ作る提案です。ただし差し出すこと自体が新しい判断を生みます。何を出すか、誰に出すかを決めるのは、サイト側になります。

仕様はどの段階にあるか

仕様草案は、W3C の Web Machine Learning Community Group が Draft Community Group Report として公開しています。参照した版の日付は2026年11月2日です。要旨は短く、WebMCPのAPIはWebアプリケーションがJavaScriptによる道具をAIエージェントへ提供できるようにするものだと書かれています。

段階の読み方で大事なのは、同じ文書に置かれた断り書きです。この文書はW3Cの標準ではなく、標準化トラックにも乗っていないと明記されています。つまり、仕様の形はまだ動きます。編集者として並んでいるのは Microsoft の Brandon Walderman と Samuel Dallstream、Google の Khushal Sagar と Dominic Farolino で、ブラウザを作っている2社の技術者が共同で書いている段階だと読み取れます。

ブラウザ側の提供状況は、Chromeのドキュメントに書かれています。試験提供としてのオリジントライアルが案内されており、記載は「Join the WebMCP origin trial from Chrome 149」です。手元での検証については、chrome://flags/#enable-webmcp-testing を開く手順が案内されています。このドキュメント自体は2026年5月18日に公開され、2026年10月7日に更新されています。

呼び出す側についても1行あります。「Chrome Extensions can query and execute WebMCP tools with content scripts」。拡張機能がコンテンツスクリプトからツールを問い合わせて実行できる、という記載です。差し出した道具を使うのは、ブラウザに組み込まれた機能だけとは限りません。

宣言型：既存のフォームに属性を足す

実装の入口は2つあります。JavaScriptで登録する命令型と、HTMLのフォーム要素に注釈を足す宣言型です。Web担当者に関係が深いのは後者です。既存のフォームを作り直さず、属性を書き足す形になっているためです。

属性	書く場所	ドキュメントの説明
toolname	<form>	「Clearly name the tool, based on its purpose」
tooldescription	<form>	「Describe what action the tool takes and its purpose」
toolparamdescription	個々の入力要素	「Map elements to a property description within the JSON Schema」
toolautosubmit	<form>	エージェントがツールを呼んだときに、自動で送信する

ここで効いてくるのが、属性を省略したときの動きです。ドキュメントは、toolparamdescription がない場合について「the browser uses the content within the associated <label> and skips descendants that are labelable」と書いています。ラベルの文字が、そのままエージェントへの説明として使われるということです。「氏名」とだけ書かれた画面と、「ご担当者さまのお名前」と書かれた画面では、渡る情報が違います。フォームの文言を具体的にする作業は、人に対する分かりやすさの改善と同じ方向を向きます。入力画面側の改善の進め方はCVR改善の方法｜数値の見方と改善の順番を解説に整理しています。

送信のふるまいは2通りです。ドキュメントは「The user must manually click Submit to complete the task」と書き、自動で送信させたい場合に toolautosubmit を足すと案内しています。つまり既定では、最後の送信は人の操作に残ります。ここを自動へ寄せるかどうかは、サイト側が選ぶ設計の分かれ目です。

どんな作業が想定されているかは、ユースケース集を見ると具体的です。並んでいるのは、買い物リストの商品を近くの店で価格比較する依頼（記載の例は「Find me the best prices for the products on my shopping list at two or three local stores」）、保証請求の開始、ケータリングの問い合わせ、物件や宿泊先の絞り込み、工数の入力です。問い合わせフォームと検索の絞り込みが中心だと分かります。多くのサイトが既に持っている画面です。

命令型：JavaScriptでツールを登録する

もう一方の入口は document.modelContext.registerTool() です。渡すのは、道具の名前、説明、入力の形（JSON Schema）、そして実際の処理を行う関数です。登録を取り消す手段も用意されており、AbortSignal を任意の引数として渡しておくと、あとで解除できると書かれています。処理の側も、途中で中断された場合に備えて AbortSignal を受け取れます。

設計の指針は、別のページに具体的に書かれています。「Each tool should consist of a single function」。1つの道具は1つの機能にする、という原則です。数については「While there isn’t a maximum number of tools allowed, each tool takes up part of the context window and adds to the time for completion」とあり、上限はないが、道具の数が増えるほど文脈の枠を使い、完了までの時間も伸びると説明されています。並べられるから並べる、という足し方は勧められていません。

入力の扱いにも明確な指示があります。「Declare specific types for parameters, such as string, number, or enum」「Validate strictly in code, loosely in schema」「Accept raw user input. Avoid asking the agent to perform math or transform the input strings」。型は具体的に宣言し、検査はコード側で厳しく、スキーマ側は緩く。そして、計算や文字列の変換をエージェントにやらせず、利用者の入力をそのまま受け取る。エラーの返し方についても「Add descriptive errors to your function code to allow the model to self-correct and retry」と書かれており、説明のあるエラーを返して直させる形が想定されています。

名前と説明の書き方の指針もあります。「When writing tool names, distinguish execution from initiation, and use verbs that describe exactly what happens」。実行と開始を区別し、実際に起きることを表す動詞を使う、という指示です。道具の名前と説明は、呼ぶかどうかの判断材料になります。曖昧に書くと、呼ばれないか、意図しない場面で呼ばれます。

差し出した道具は、誰にでも見えるわけではない

ここが、仕様を読んで安心できる部分です。公開範囲は既定で閉じています。仕様草案は、このAPIを tools という名前の権限で制御する機能として定義し、既定の許可範囲を自分自身のオリジンだけとしています。

他のオリジンへ出す場合の仕組みも、片側だけでは成立しません。草案は双方の明示的な指定を求めています。出す側は登録のときに exposedTo で相手のオリジンを指定し、求める側は getTools() の fromOrigins でそのオリジンを指定する。両方がそろって初めて見える形です。知らないうちに道具の一覧を拾われることを防ぐための設計だと説明されています。

そのうえで、安全設計のドキュメントは判断の基準を1行で示しています。「Only expose your tools to origins that you trust」。読み取りだけの道具についても、利用者のデータが見える場合は、そのデータを直接共有してもよい相手にだけ出すように、と書かれています。読み取り専用だから安全、ではありません。広告プラットフォーム側が公開したMCPサーバーが読み取り専用かつ二段階の承認だった事例は広告データにAIエージェントの正面入口。SnapとGoogleの公式MCPサーバーで扱いました。接続する側と差し出す側で、決める順番は同じです。

安全側は「注釈」と「前提の置き方」で決める

安全設計のドキュメントは、言い切りから始まります。「It’s impossible to guarantee safety inside of a large language model (LLM)」。大規模言語モデルの内側で安全を保証することはできない、という前提です。続けて、間接プロンプトインジェクション（攻撃者が悪意ある指示を混ぜ込むこと）を主要な懸念として挙げ、最新のモデルを使うエージェント的な仕組みに対して再現可能な攻撃が報告されており、Web上での攻撃の広がりも増していると書いています。

その前提で用意されているのが、道具に付ける注釈です。

注釈	付ける対象	ドキュメントの説明
readOnlyHint	状態を変えない道具	「Use the readOnlyHint on tools that don’t change state」
consequentialHint	影響の大きい操作	「If executing a tool results in significant actions, such as booking travel or transferring money, set consequentialHint: true」
untrustedContentHint	外部由来の内容を返す道具	「If a tool returns user-generated content (UGC) or externally sourced data, consider adding the untrustedContentHint」

3つめは、口コミやレビュー、投稿された文章を返す道具が対象になります。メディアやECサイトのように他人が書いた文章を抱えているサイトは、ここに該当する道具を作りやすいという点に注意してください。注釈はエージェント側へ伝えるための印で、それ自体が攻撃を止める仕組みではありません。

計測の論点が1つ増える

宣言型のドキュメントには、運用に直接関わる一文があります。送信イベントに agentInvoked という真偽値の属性が加わる、という記載です。その送信がエージェントによって引き起こされたのかどうかを、サイト側で区別できるということになります。

これは実務では小さくない変更です。問い合わせや資料請求の件数を見ているチームは、人が入力したものと、エージェントが代わりに入力したものを混ぜたまま数えることになりかねません。分けて数えるのか、まとめて数えるのかは、仕様が決めてくれません。測る側の方針です。フォーム送信をどう数えるかという手前の設計はGA4のキーイベント設定方法｜コンバージョン計測の手順にまとめています。

なお現状は提案段階で、ブラウザの試験提供に依存します。どの環境でどれだけの割合が該当するのかを示す数値は、参照したドキュメントにはありません。いま決められるのは、記録の持ち方だけです。

先に決めておくこと

順番があります。第一に、出す候補を読み取り側から選ぶことです。在庫や空き状況の照会、条件での絞り込みのように、状態を変えない操作から始めれば、注釈も readOnlyHint で足ります。送信や決済を最初の候補にすると、決めることが一度に増えます。

第二に、送信を人の操作に残すかどうかを決めることです。宣言型は、既定で送信を人に残します。自動送信にすると、確認の段がなくなります。取り消せない処理ほど、ここは残しておくほうが安全です。

第三に、記録の持ち方を先に決めることです。エージェント経由の送信を区別できる属性が入るので、受け取った側の台帳に印を残せるかどうかを確認してください。あとから分けるのは難しく、混ざった期間はそのまま残ります。

第四に、フォームの文言を見直すことです。これは仕様が固まる前にできて、しかも人に対しても効きます。ラベルが具体的であれば、エージェントへ渡る説明も具体的になります。

AIが買い物の側に回る前提で何を整えるかという、より広い流れはAIが買い物をする時代へ。Microsoftが示した3段階の備えで整理しました。

参照したドキュメントに書かれていないこと

推測で埋めないために、探しても見つからなかった項目を残します。

確認したかった項目	記載	どうするか
試験提供が終わる時期	参照したページに記載がありません	採用の前に現在の案内を確認する
対応するブラウザの範囲	Chrome以外の提供状況の記載がありません	他のブラウザの公式情報を個別に確認する
道具を呼べるエージェントの一覧	拡張機能から実行できる記載はありますが、一覧はありません	自社で許す相手を決める前提で考える
普及の規模を示す数値	記載がありません	数値を自社の資料へ書かない
日本語のラベルや説明の扱い	記載を確認できませんでした	実装のときに自分で確かめる

書かれていない項目が多いのは、草案と試験提供の段階では普通のことです。問題になるのは、書かれていないことを社内の資料で埋めてしまうときです。共有するときは、仕様の記載と自分たちの判断を分けて書いてください。

まとめ

WebMCPは、サイトが自分の機能を構造化した道具としてAIエージェントへ差し出すための提案仕様です。仕様草案はW3CのコミュニティグループがDraft Community Group Reportとして公開しており、W3Cの標準ではなく標準化トラックにも乗っていないと明記されています。編集者にはGoogleとMicrosoftの技術者が並び、Chromeは Chrome 149 からのオリジントライアルを案内しています。

実装の入口は2つです。宣言型は既存のフォームに toolname などの属性を足す形で、送信は既定で人の操作に残ります。命令型は document.modelContext.registerTool() で登録し、1つの道具は1つの機能にする、型は具体的に宣言する、といった設計の指針がドキュメントに書かれています。

公開範囲は既定で自分のオリジンだけです。他のオリジンへ出すには出す側と求める側の双方の指定が必要で、安全設計のドキュメントは信頼できる相手にだけ出すよう求めています。モデルの内側で安全を保証することはできないという前提も明記されています。

いま手を動かすなら、出稿や施策の前に、出す候補の選び方、送信を人に残すかどうか、エージェント経由の送信をどう記録するか、そしてフォームの文言の4つです。最後の1つは仕様の行方に関係なく効きます。確認日は2026年11月5日です。