WebMCPは、Webページが自分の機能を「ツール」としてAIエージェントに公開するためのブラウザAPIです。エージェントはボタンの位置を推測してクリックする代わりに、ページが登録した関数を名前と引数で呼び出します。この記事では、WebMCPの仕組みとMCPとの違い、document.modelContext.registerToolとHTMLフォームを使った実装手順、公開範囲とセキュリティの設計、そして今導入すべきかの判断を、2026年10月23日時点のChrome公式ドキュメントとW3Cの仕様草案に沿って整理しました。
まとめ｜WebMCPとは何か、MCPとの違いと今試すべきかの結論
WebMCPは、ページ側が「この画面でできる操作」をJSON Schema付きの関数として宣言し、ブラウザ内のエージェントに渡す仕組みです。仕様はW3CのWeb Machine Learning Community Groupの草案で、正式なW3C標準ではありません。ChromeはChrome 149から156までのオリジントライアルで提供しており、FirefoxとSafariは態度を示していない段階です。
MCPとは競合しません。MCPはサーバーで常駐して、どこからでもデータと操作を提供します。WebMCPが動く場所はタブの中で、動作するのは利用者がそのページを開いている間だけです。予約・EC・サポート受付のように、フォーム入力で完結する業務を持つサイトは今のうちに検証を始める価値があります。情報を読ませるだけのサイトは、仕様が固まるまで待って問題ありません。
WebMCPの仕組み：ページがAIエージェントへツールを公開するブラウザAPI
まず、WebMCPが何を解決しようとしているのかを、従来のエージェントの動き方と比べて押さえます。
画面操作の推測をやめてページ側が関数を宣言するという発想の転換
ブラウザを操作するAIエージェントは、これまでスクリーンショットやDOMを読み、どのボタンが何をするかを推測して操作してきました。この方式の弱点はComputer Useの仕組み｜スクリーンショットと座標で画面を操作する動作原理で詳しく扱っていますが、デザイン変更やCookieバナー1つで手順が崩れます。
Chrome公式のWebMCP概要は、要素の目的をエージェントに読み解かせるのではなく、Webサイトが要素の目的を宣言する方式だと説明しています。提供されるのは、ツールを登録する発見の仕組み、入力と出力を定義するJSON Schema、現在のページ状態の共有の3点です。ツールはページ上で目に見える形で実行されるため、利用者は作業の進み具合を自分の画面で確かめられます。
W3Cコミュニティグループ草案という位置づけとGoogle・Microsoftの関与
WebMCPの仕様書は、2026年10月20日付の「Draft Community Group Report」です。仕様書自身が「W3C標準ではなく、標準化トラックにも乗っていない」と明記しています。編集者はMicrosoftのBrandon Walderman氏とGoogleのKhushal Sagar氏で、2社のブラウザベンダーが共同で書いている点は押さえておくべき事実です。
APIの入口はdocument.modelContextで、仕様書はDocumentにModelContextを持たせる形で定義しています。初期の解説記事にはnavigator.modelContextで書かれたコードが残っているため、ネットで拾った例をそのまま使うと動かないことがあります。新しく書くコードは、仕様書とChrome公式ドキュメントにそろえてdocument.modelContextを使ってください。
Chromeの対応状況：Chrome 149〜156のオリジントライアルとフラグ
Chrome PlatformのWebMCPのページを2026年10月23日に確認したところ、開発者向け試験はChrome 146から、オリジントライアルはChrome 149から156まで（延長枠は162まで）と登録されていました。FirefoxとSafariの欄は「No signal」です。
| 使い方 | 対象 | 必要な作業 |
|---|---|---|
| ローカル検証 | 自分のChromeだけ | フラグを有効にして再起動 |
| オリジントライアル | 本番サイトの訪問者 | トークンを登録してページに設定 |
| 正式提供 | 未定 | 2026年10月時点で予定なし |
オリジントライアルは期間限定の実験枠です。Chrome 156を過ぎて延長が無ければ機能は止まるため、本番の主要導線をWebMCPだけに頼る設計は避けてください。Chromeに内蔵されたほかのAI系APIの出荷段階はChrome Built-in AIとは？7つのAPIの出荷段階と実装手順にまとめています。
WebMCPとMCPの違い：サーバーで常駐するMCPとタブに紐づくWebMCP
名前が似ているため「WebMCPはMCPを置き換えるのか」という疑問がよく出ます。Chromeチームの答えは明確に「置き換えでも拡張でもない」です。
比較表で見る実行場所・寿命・発見方法・UIとの関係という判断軸
WebMCPとMCPの使い分けの公式解説は、MCPをバックエンド向け、WebMCPをフロントエンド向けと位置づけています。MCPそのものの仕組みはMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格で解説しています。
| 比較項目 | MCP | WebMCP |
|---|---|---|
| 動く場所 | サーバー・常駐プロセス | 利用者のブラウザのタブ |
| 寿命 | 常時 | ページを開いている間だけ |
| 実装の手段 | 各言語のSDK・JSON-RPC | JavaScriptかHTML属性 |
| ツールの発見 | エージェントごとに登録 | 訪問中にページが登録 |
| ログイン状態 | 別途の認証が必要 | タブのセッションを使う |
| resources | あり | 持たない |
実務で効いてくるのは「ログイン状態」の行です。WebMCPのツールは利用者がログイン済みのタブで動くため、カートや会員情報をそのまま扱えます。エージェント側にパスワードやトークンを預ける必要がありません。反対に、タブを閉じればツールは消えるので、夜間バッチのような裏方の処理はMCPの担当です。
併用構成の実例：Commerce.comとCloudflareの約10万ストア
併用の実例として、Cloudflareが2026年10月に公開した事例があります。Cloudflareは8月にWebMCPのエッジ実装をベータ公開し、Commerce.comはそれを使って約10万ドメインのストアでWebMCPを有効にしました。
仕組みは、エッジで小さなスクリプトをページに差し込み、Commerce.comのバックエンドMCPサーバーにあるツール定義を、訪問者のブラウザへそのまま中継するものです。エージェントはsearch_productsとadd_to_cartを呼び出し、決済ボタンは利用者が自分で押します。加盟店ごとにオプトアウトでき、非対応ブラウザではスクリプトが何もせず終了します。ツールのロジックはMCPサーバー1か所に置き、届け方だけをMCPとWebMCPで分ける構成です。CloudflareでMCPサーバーを立てる手順はCloudflareでMCPサーバーを構築・公開する方法にあります。
命令型APIの実装手順：Chromeでのツール登録と実行処理の定義
ここからは、document.modelContext.registerToolでツールを登録し、手元のChromeで動かせる形で実装を示します。コードはImperative APIの公式ドキュメント（2026年10月16日更新）の仕様に合わせています。
Chromeのフラグを有効にして検証環境を用意しツールを1つ登録する
ローカル検証では、Chromeでchrome://flags/#enable-webmcp-testingを開いてEnabledにし、再起動します。そのうえで、予約サイトの空き枠検索をツールとして登録する例が次のコードです。
<script type="module">
// WebMCP 非対応のブラウザでは何もしない（従来の画面はそのまま動く）
if ('modelContext' in document) {
await document.modelContext.registerTool({
name: 'search_slots',
description: '指定した日付の空き枠を検索し、開始時刻と残席数を返す',
inputSchema: {
type: 'object',
properties: {
date: { type: 'string', description: 'YYYY-MM-DD 形式の日付' },
people: { type: 'number', description: '予約する人数' }
},
required: ['date']
},
annotations: { readOnlyHint: true },
execute: async ({ date, people = 1 }, { signal }) => {
const res = await fetch(`/api/slots?date=${date}&people=${people}`, { signal });
const slots = await res.json();
return JSON.stringify(slots.slice(0, 10));
}
});
}
</script>登録に必須なのはname・description・inputSchemaと、実際の処理を書くexecuteです。executeは第2引数でsignalを受け取れるので、fetchへ渡しておくとエージェントや利用者が中断したときに通信も止まります。登録できたかは、DevToolsのApplicationパネルか、Chromeが公開しているModel Context Tool Inspector拡張で確かめられます。
annotationsで読み取り専用と取り消し不能な操作をエージェントへ伝える
annotationsは任意の項目ですが、エージェントが確認ダイアログを出すかどうかの判断材料になるため、実務では必ず付けてください。公式ドキュメントが定める4種類は次のとおりです。
consequentialHint：予約・送金・削除など取り消せない操作。エージェントやブラウザが実行前に利用者の確認を求められるreadOnlyHint：検索や状態の取得など、何も書き換えない操作untrustedContentHint：口コミや外部データなど、出力に信頼できない内容を含むdebugging：テストや開発者ツール向け。Chrome 156から使える
最初に付けるべきはconsequentialHintです。予約確定のツールにこれが無いと、エージェントが利用者に確認せず確定まで進む余地が残ります。どれも既定値はfalseなので、書かなければ「副作用があるかもしれないが重大ではない」扱いになる点に注意してください。
AbortSignalによる登録解除と画面遷移に合わせたツールの入れ替え
SPAでは、画面ごとに使えるツールが変わります。登録時にsignalを渡しておき、画面を離れるときにabort()を呼ぶと登録が外れます。
const controller = new AbortController();
await document.modelContext.registerTool({
name: 'confirm_booking',
description: '選択中の枠で予約を確定する',
inputSchema: { type: 'object', properties: { slotId: { type: 'string' } }, required: ['slotId'] },
annotations: { consequentialHint: true },
execute: async ({ slotId }) => confirmBooking(slotId)
}, { signal: controller.signal });
// 予約画面を離れるときに登録を外す
controller.abort();公式ドキュメントによると、Chrome 153からは実行中の処理を壊さずに登録を外せるようになりました。ReactやVueのようにコンポーネント単位で登録と解除を繰り返す構成でも、途中のツール実行が切れません。Chrome 155からはツールの引数をJSON文字列で渡す形が非推奨になっています。古い例を参考にする場合は、オブジェクトで渡しているかを確認してください。
宣言型APIの実装手順：HTMLフォームにtoolname属性を足してツール化
JavaScriptを書かなくても、既存のフォームに属性を足すだけでツールになります。Declarative APIの公式ドキュメント（2026年9月25日更新）の仕様に沿って説明します。
フォームと入力欄の3属性でツール名・説明・引数の説明を定義する手順
form要素にtoolnameとtooldescriptionを付けると、ブラウザがフォームの入力欄から入力スキーマを組み立てます。どちらかの属性を外すと、ツールの登録も外れる仕組みです。
<form toolname="create_inquiry"
tooldescription="システム開発に関する問い合わせを送信する"
action="/inquiry" method="post">
<label for="company">会社名</label>
<input id="company" name="company" required>
<select name="topic" required
toolparamdescription="相談したい内容。担当部署の振り分けに使う">
<option value="ai">AI・エージェント開発</option>
<option value="web">Webサイト制作</option>
</select>
<button type="submit">送信</button>
</form>toolparamdescriptionを省くと、ブラウザは対応するlabelの文言を、それも無ければaria-descriptionを説明に使います。ラベルがきちんと付いたフォームなら、アクセシビリティの整備がそのままエージェント対応になるわけです。selectの選択肢は、入力スキーマの列挙値として渡されます。
SubmitEventで送信元を判定しエージェントへ処理結果を返す手順
SubmitEventのagentInvokedとrespondWithを使い、送信元の判定と結果の返却を行います。既定では、エージェントが行うのは入力欄を埋めるところまでで、送信ボタンを押すのは利用者です。toolautosubmit属性を付けると、エージェントの呼び出しで送信まで進みます。送信結果をエージェントへ返したいときは、submitイベントで次のように書きます。
document.querySelector('form[toolname="create_inquiry"]')
.addEventListener('submit', (e) => {
if (!e.agentInvoked) return; // 人の送信は従来どおり
e.preventDefault();
const body = new FormData(e.target);
e.respondWith(
fetch('/inquiry', { method: 'POST', body })
.then((r) => (r.ok ? '受付番号を発行しました' : '送信に失敗しました'))
);
});agentInvokedはエージェントが起動した送信のときだけtrueになります。respondWithを使う前にはpreventDefault()が必須です。エージェントの操作中、フォームには:tool-form-active、送信ボタンには:tool-submit-activeという疑似クラスが付き、Chromeの既定では破線の枠が表示されます。
セキュリティと設計の注意点：プロンプトインジェクションと公開範囲の管理
ツールを公開することは、エージェント経由で操作される入口を増やすことでもあります。WebMCPのツールセキュリティの公式ガイドをもとに、設計時に決めておく事項を挙げます。
Permissions PolicyとexposedToによる公開先制御の設定
WebMCPの2つのAPIは、toolsというPermissions Policyで制御されます。既定値はselfで、トップレベルと同一オリジンでは登録でき、別オリジンのiframeでは無効です。埋め込み先で使わせたい場合だけ、iframeにallow="tools"を付けます。
ツールを別オリジンから見えるようにするには、registerToolの第2引数でexposedToに信頼できるオリジンを列挙します。読み取り専用のツールでも利用者の情報を返すことがあるため、データを直接渡してよい相手にしか公開しないのが原則です。注意したいのは、ホスト権限を持つChrome拡張はWebMCPに関係なくページを操作できる点で、ツールの公開範囲を絞っても拡張由来の操作は防げません。
ツール出力に混ざる命令への備えと公式が示す説明・出力の文字数の目安
口コミやユーザー投稿を返すツールは、そこに埋め込まれた命令をエージェントが実行してしまう間接プロンプトインジェクションの経路になります。該当するツールにはuntrustedContentHintを付け、出力は必要な項目に絞ってください。攻撃の型と一般的な対策はプロンプトインジェクションとは？攻撃例・種類と対策をOWASP LLM01とコードで解説で整理しています。
同じガイドは、エージェントのガードレールに引っかからないための文字数の目安も示しています。ツールの説明は500文字、引数の説明は150文字、ツール名と引数名は30文字、1回のツール出力は1,500文字までです。上の空き枠検索の例で結果を10件に切っているのはこのためで、一覧を全件返す設計は避けたほうが安全です。
WebMCPを今導入すべきかの判断：採用する条件と見送るべきサイト
仕様が草案で、対応ブラウザもChromeの実験枠だけという前提で、どこまで投資するかを条件で切り分けます。
先行して実装する価値があるサイト：予約・EC・サポート受付のフォーム
次の3つがそろうサイトは、今から検証を始めてください。1つ目は、予約・注文・問い合わせなど、フォーム送信で完結する業務が売上や受付件数に直結していること。2つ目は、そのフォームにラベルが付き、入力の検証がサーバー側にあること。3つ目は、確定操作をconsequentialHintで守り、最後の確定を人に残す運用に合意できることです。
この条件なら、宣言型APIでフォームに属性を足すだけで始められ、非対応ブラウザへの影響もありません。エージェント経由の購買はUCP（Universal Commerce Protocol）の仕組みとACP・AP2との違いのような決済側の標準とも組み合わさっていくため、ECでは早く動いた側が検証の知見を持てます。
今は導入を見送ってよいケース：静的な情報サイトと状態が複雑な画面
記事や会社案内を読ませるだけのサイトは、WebMCPで公開すべき操作がほとんどありません。ここで工数をかけても回収できないので見送ってかまいません。公式ドキュメントも制限として、複雑な画面では状態管理のためのリファクタリングが要ること、ヘッドレス環境は主な対象ではないこと、エージェントがサイトを訪れるまでツールの存在が分からないことを挙げています。
サーバー側でエージェントに常時データを提供したいなら、先にMCPサーバーの作り方とAIエージェントへの接続手順でMCPを整えるほうが、対応できるエージェントの数で勝ります。自社のサイトや業務システムに、MCPとWebMCPのどちらをどこまで入れるかを決められない場合は、一創のAIエージェント開発で、ツール設計から既存システムとの接続、確認フローの組み込みまで相談を受け付けています。
よくある質問
WebMCPについて、検索でよく見かける疑問に短く答えます。
WebMCPはMCPの代わりになりますか？
なりません。Chromeの公式解説は、WebMCPはMCPの拡張でも置き換えでもないと明言しています。MCPはサーバーで常時動き、デスクトップやクラウドのエージェントからも使える仕組みです。WebMCPはブラウザのタブの中だけで、利用者がページを開いている間に限って動きます。ツールのロジックをMCPサーバーに置き、ブラウザへはWebMCPで届けるという併用が、Commerce.comの事例でも採られている構成です。
WebMCPはどのブラウザで使えますか？
2026年10月23日時点で実装しているのはChromeだけです。Chrome 149から156までのオリジントライアルと、ローカル検証用のフラグで使えます。Chrome PlatformのページではFirefoxとSafariの欄が「No signal」で、対応の予定は示されていません。仕様の編集者にMicrosoftの担当者が入っているものの、Edgeでの提供時期も公表されていません。
WebMCPを入れると既存のサイトが壊れることはありますか？
正しく機能検出していれば壊れません。documentにmodelContextが無いブラウザでは登録処理を飛ばせばよく、宣言型の属性は非対応ブラウザでは単に無視されます。Cloudflareの事例でも、非対応ブラウザやMCPサーバーの停止時にはスクリプトが何もせず終了し、人の買い物には影響しない設計になっています。
WebMCPのツールはエージェントに勝手に実行されませんか？
ツールを呼ぶかどうかはエージェントが決めるため、取り消せない操作にはconsequentialHint: trueを付け、エージェントやブラウザが確認を求められるようにします。宣言型APIではtoolautosubmitを付けなければ、送信ボタンは利用者が押すまで動きません。決済のように最後の確定を人に残す設計なら、誤操作の範囲を入力の下書きまでに抑えられます。
WebMCPとBrowser UseやPlaywright MCPは何が違いますか？
Browser UseやPlaywright MCPは、エージェントの側がページを読み取り、クリックや入力を代行する道具です。サイト側の協力が無くても動きますが、画面が変わると手順が崩れやすくなります。WebMCPはサイト側が操作を関数として用意する仕組みで、対応したページでは推測が要りません。両者の違いと使い分けはBrowser Useとは？使い方・料金・Playwright MCPとの違いでも比べています。
関連記事
- MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説：WebMCPと併用するMCPの基本です
- MCPサーバーの作り方とAIエージェントへの接続手順｜Python SDK 2.3でツール定義・認可を実装：バックエンド側のツール実装の手順です
- CloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータル：Cloudflare上でMCPサーバーを公開する方法です
- Chrome Built-in AIとは？7つのAPIの出荷段階と実装手順【2026年8月】：Chromeに内蔵されたAI系APIの全体像です
- Computer Useの仕組み｜スクリーンショットと座標で画面を操作する動作原理をClaude・OpenAI・Geminiで比較：WebMCPが置き換えようとしている画面操作型の仕組みです
