WebMCPとは？自社サイトがAIエージェントの窓口になる——W3Cドラフトが用意した3つの「させない」設定と、公開前に決める線引き

WebMCPとは、自社のWebサイトに置いたJavaScript（Webページを動かすためのプログラミング言語）で、AIエージェントに実行させてよい機能を「ツール」として宣言できるようにする仕組みです。W3C（Webの技術標準を策定する国際組織）傘下のWeb Machine Learning Community Groupが、2026年7月28日付でドラフト（草案）文書として公開しました。まだ標準ではなく、標準化の道筋にすら乗っていない段階です。

WebMCPとは何か——「AIに優しいサイト」ではなく「AIに使わせる道具を宣言する」仕組み

WebMCPは、ぼんやりと「AIが読みやすいサイト」を作るための工夫ではありません。ドラフトの定義を訳すと、「Webサイトの機能を、自然言語（人間が普段使う言葉）による説明と構造化されたスキーマ（データの型や形式を決めた設計図）を持つJavaScriptの関数として、エージェント・ブラウザのエージェント・支援技術から呼び出せる形で公開する新しいインターフェース」です。何を公開するかをサイト側が1つずつ手で宣言する仕組みだ、という点がまず押さえるべき前提になります。

この定義でもう1つ見落とされがちなのが、支援技術（スクリーンリーダーなど、視覚や操作に障害のある利用者を補助するソフトウェア）が呼び出し主体として名指しされていることです。WebMCPはAIエージェント専用の仕組みとして語られがちですが、ドラフト本文はAIエージェントと支援技術を並べて書いています。ツールをどう宣言するかは、AIへの窓口だけでなく、アクセシビリティの窓口も同時に設計することになります。

ドラフトはツールを呼ぶ側を3つに分けて定義しています。agentは利用者の目標を理解し代わりに行動する自律的なアシスタント、browser's agentはブラウザ自身が提供するエージェント、そしてAI platformの例としてOpenAIのChatGPT・AnthropicのClaude・GoogleのGeminiが名指しされています。「AI」とひとくくりにせず、誰がツールを呼ぶ可能性があるかを分けて考える必要がある、というのがドラフトの立て付けです。

AnthropicのMCPとは何が違うのか——動く場所が「サーバー」から「ブラウザ」へ

WebMCPという名前から連想するのは、Anthropicが2024年11月に公開したMCP（Model Context Protocol）です。両者の関係について、ドラフト本文は次のように明記しています。「Web pages that use WebMCP can be thought of as Model Context Protocol [MCP] servers that implement tools in client-side script instead of on the backend」（WebMCPを使うWebページは、バックエンドではなくクライアント側スクリプト——訪問者のブラウザ内で動くプログラム——でツールを実装したMCPサーバーだと考えられる）。これは筆者の推測ではなく、仕様本文が言っていることです。

つまりMCPは「AIと社内の道具」を、サーバー側でつなぐ規格でした。WebMCPは同じ発想を、サイト訪問者のブラウザ側に持ち込んだものだと整理できます。誰が窓口を出すか、どこで動くかを比較すると次のようになります。

MCPそのものの仕組みや、2026年7月28日版で何が変わったかは前回の記事「MCPとは、AIに社内の道具を使わせる共通規格」で扱っています。この記事ではWebMCPに絞って、「サイト側が何を開放し、何を開放しないか」を掘り下げます。

自社サイトでAIに何をさせるかの整理から相談したい方はこちら（FDE型AI導入支援・無料相談）

今どの段階か——「W3C標準ではない」と文書自身が書いている

ドラフト文書は冒頭近くで、自らの立場をはっきり書いています。「It is not a W3C Standard nor is it on the W3C Standards Track」（W3Cの標準ではなく、標準化トラックにも乗っていない）。発行元はWeb Machine Learning Community Groupという1つの検討グループで、種別は「Draft Community Group Report（草案段階のコミュニティグループ報告書）」です。標準に向けた審査を経た文書ではありません。

実装面では、Chrome for Developersのブログ（2026年6月9日公開）が「Chrome 149からWebMCPのオリジントライアルに参加できる」と告知しています。オリジントライアルとは、正式リリース前の機能を限定したサイトで試せる期間限定のプログラムのことです。ブラウザベンダー1社が期間限定で試験提供している段階で、このブログ記事自体に具体的なAPIの呼び出しコード例は載っていません。

仕様の中身も全部が決まっているわけではありません。HTMLに注釈を書くだけでツールを登録できるDeclarative（宣言的）方式が構想されていますが、ドラフト本文はこの方式の実行手順について「登録されたツールについては、まだ定義されていない一連の『内部』ステップになる」と書き、Declarativeの節自体も「This section is entirely a TODO（この節はまるごと未着手）」とだけ記されています。今すぐ動くのは、標準的なJavaScriptでツールを1つずつ登録するImperative（命令的）方式だけです。

まとめると、標準化の手続き上も、ブラウザでの実装上も、仕様の中身自体も、いずれも「まだ実装する段階ではない」という同じ結論を指しています。ここで急ぐ理由はありません。

ドラフトが用意した3つの「させない」設定

ここが本題です。WebMCPのドラフトは、ツールを登録するときに付けられる目印（annotations）を用意しています。中心になるのは次の3つです。

readOnlyHintとuntrustedContentHint——2つとも初期値はfalse

readOnlyHint（読み取り専用の目印）は、そのツールが読み取りだけで済むものか、状態を変更する可能性があるものかをAI側に伝える設定です。untrustedContentHint（信頼できない内容の目印）は、そのツールが返す内容を、無条件に信頼できる情報として扱ってはいけないという目印です。ドラフトを確認すると、この2つの初期値はどちらもfalseです。つまり何も指定しなければ、「読み取り専用ではない」「返す内容は信頼できるものとして扱われうる」という、より強い権限を持つ側の扱いになります。安全な側に倒すには、サイト側が明示的にtrueを指定する必要があります。

exposedTo——見せる相手のオリジンを絞る設定

exposedToは、登録したツールを誰に見せるかを、オリジン（URLのうちプロトコル・ドメイン・ポートの組み合わせで決まる「発行元」の単位）で指定できる設定です。既定では空のリストになっており、この場合は同一オリジンからであればツールが見えます。exposedToで特定のオリジンを指定する場合、そのオリジンが「potentially trustworthy（セキュアだと判断できる状態）」でなければSecurityErrorになります。WebMCP自体の利用にもSecureContext（HTTPS等のセキュアな通信環境）が必須で、見せる相手を絞る仕組みが複数の層で用意されていることになります。

ここから見えてくるWebMCPの性格は、「AIに何でもさせるための規格」ではなく、「サイト側が何をさせるかを1つずつ宣言し、宣言していないことはさせない規格」だということです。2つの目印の初期値がどちらもfalse、見せる相手の初期値も空リストという設計は、機能を足すたびにサイト側が意識して選択することを前提にしています。

ドラフト自身が挙げているリスク4つ

ドラフトにはセキュリティ・プライバシー節があり、対処すべきリスクを自ら列挙しています。夢のような機能として書かれているわけではない、という点が重要です。

プロンプトインジェクションと意図の偽装

プロンプトインジェクション（AIへの指示に見せかけた不正な入力を紛れ込ませる攻撃）について、ドラフトは「Tool descriptions and return values could be treated as trusted context（ツールの説明文や返り値が、信頼できる文脈としてそのまま扱われる可能性がある）」と指摘しています。ツールの説明や実行結果に含まれる文字列を、AIが指示だと誤認する余地があるということです。もう1つのMisrepresentation of Intent（意図の偽装）では、「no guarantee that a WebMCP tool's declared intent matches its actual behavior（WebMCPツールが宣言した意図と、実際の動作が一致する保証はない)」と明記されています。ツールの説明文に「これは読み取り専用です」と書いても、そのとおりに実装されているかは規格の外側、実装者の責任です。

プライバシー漏えい——サイト側が加害者になり得る指摘

3つ目のPrivacy Leakage（プライバシー漏えい）は、他の3つと性格が違います。「Sites can design highly parameterized WebMCP tools to extract sensitive user data（サイトは、高度にパラメータ化されたWebMCPツールを設計することで、利用者の機微な情報を抜き出すことができる）」——これはAIや外部の攻撃者ではなく、サイトを作る側が意図的・非意図的に加害者側になり得るという指摘です。検索条件を細かく絞り込めるツールや、会員情報を条件検索できるツールを何気なく設計すると、悪意がなくても個人情報を引き出しやすい形になってしまう可能性があります。ここは自社がツールを設計するときに、自分たちの手元で気をつけるべき論点です。

4つ目のPrivate Browsing（プライベートブラウジング）については、「may inadvertently leak information across this boundary（この境界を越えて意図せず情報が漏れる可能性がある）」とだけ記載されています。シークレットモードのような通常とは切り離された閲覧状態と、通常の閲覧状態の間で情報が混ざる懸念があると読めますが、具体的な対策はまだ書き込まれていません。

自社サイトで先に決めておく線引き

ここまでの内容を、実装の話ではなく「決めること」の話として並べ直すと、次の4つになります。

1つ目と2つ目はreadOnlyHintに、3つ目はexposedToに対応します。4つ目は規格には書かれていない、自社の運用として決めておくべき項目です。ツールの実行結果を誰も確認しないまま次の行動に使わせるのか、どこかで人の目を挟むのかは、WebMCPが決めることではなく自社が決めることです。

よくある失敗・NGパターン

ドラフトの記述から導ける範囲で、検討段階の会社が陥りやすいパターンを挙げます。

1. ①まだ標準でないものに実装工数を割く。Chrome 149限定のオリジントライアルであり、他のブラウザでの対応は本記事の一次情報からは確認できていません。今の段階でエンジニアの工数を確保するのは時期尚早です。
2. ②readOnlyHintを付けずに登録する。初期値はfalseなので、意識して指定しない限り「読み取り専用ではない」扱いのままツールが公開されてしまいます。
3. ③exposedToを検討せずに公開する。既定は同一オリジンのみですが、将来的に外部と連携するときにオリジンの精査を怠ると、意図しない相手にツールが見える設計になり得ます。
4. ④ツールの説明文をAIが必ず信じると仮定する。Misrepresentation of Intentとして明記されている通り、説明文と実際の動作が一致する保証は規格上ありません。説明を書いて終わりにせず、実装が説明どおりかを自分たちで確認する前提に立つ必要があります。

自社サイトで何を開放し何を開放しないかの設計から相談したい方はこちら（FDE型AI導入支援・無料相談）

よくある質問

まとめ

WebMCPは、自社サイトの機能をAIエージェント（と支援技術）に「ツール」として宣言する仕組みです。仕様本文が自ら「バックエンドではなくクライアント側でツールを実装したMCPサーバー」と説明しているとおり、MCPと同じ発想をブラウザ側に持ち込んだものだと整理できます。用意されている3つの設定——readOnlyHint・untrustedContentHint・exposedTo——はいずれも初期値が制限的な側にあり、規格そのものが「宣言していないことはさせない」方向に設計されています。ドラフトはプロンプトインジェクション・意図の偽装・プライバシー漏えい・プライベートブラウジングという4つのリスクも自ら列挙しており、特にプライバシー漏えいはサイトを作る側が加害者になり得るという指摘です。

そして何より、文書自身が「W3Cの標準ではなく標準化トラックにも乗っていない」と書いています。今の段階で中小企業がやるべきなのは実装ではなく、自社サイトでAIに何をさせたいか、何をさせたくないかを言語化しておくことです。