WebMCPとは?
WebMCPとは、Webページが自分の機能を「AIエージェントが呼び出せるツール」として宣言するためのブラウザ標準のこと。画面を見て操作を推測させるのではなく、サイト側が用意した処理をエージェントに名前で直接呼ばせます。
実務での使い方
AIエージェントのWeb操作は、これまで画面のスクリーンショットを読み取り「次にどこを押すべきか」を推測するやり方が主流でした。WebMCPはこの構造を逆にします。サイト側が「このページではこの処理ができる」と機能を宣言し、エージェントはその処理を名前で呼び出します。座標のクリックではなく関数の呼び出しになるため、レイアウトを変えても表示言語が違っても壊れません。サイト運営者から見れば、AIエージェントという新しい来訪者に向けて自サイトの入口を用意する作業にあたります。
ページ側のAPIは document.modelContext で、登録するツールは「名前・自然言語の説明・入力のJSON Schema・実行する関数」の4点セットです。この形式はMCP(Model Context Protocol)のツール定義を踏襲しているため、エージェントから見ればMCPサーバーと同じ作法で扱えます。仕様はW3CのWeb Machine Learning Community GroupでGoogleとMicrosoftのエンジニアが編集を進めており、コミュニティグループのドラフト段階です。W3Cの標準化トラックには乗っておらず、APIの形は版によって変わります。
ブラウザ実装はChromeが先行しています。2026年5月19日のGoogle I/Oで、Chrome 149からのOrigin Trial(本番サイトで試験運用できる仕組み)が公表されました。あわせて、古い名前だった navigator.modelContext はChrome 150で非推奨になっています。2026年8月時点では試験段階の技術で、全ブラウザで動く前提には立てません。
MCPとWebMCPは何が違う?
違いは「ツールを実行する場所」です。MCPは独立したサーバーを立て、AIがそのサーバー越しに社内システムやSaaSを操作します。WebMCPでは、いま開いているWebページ自身がツールの提供者になります。サーバーを用意する必要がなく、JavaScriptを書いてデプロイするだけで公開できます。
実務で効いてくるのは、ログイン状態をブラウザがすでに持っている点です。MCPサーバーを立てる場合はアクセストークンや権限設計を別途用意する必要がありますが、WebMCPでは訪問者がその画面でできることが、そのままエージェントにできることの上限になります。逆に言えば、公開するツールの選び方を誤ると、訪問者本人の権限で意図しない操作が走る余地が生まれます。
ツール定義の形式は共通。違うのは実行場所と権限の出どころ。
自社サイトでは何から始める?
入口は2つあります。1つはCDNのスイッチで、Cloudflareは2026年8月6日にWebMCP対応を開発者プレビューとして公開しました。オリジンのコード変更もデプロイも不要で、配信されるHTMLにエッジ側がブリッジスクリプトを挿入します。まず対応の受け皿を作りたい段階に向いています。
もう1つは自力実装で、ページ内で document.modelContext.registerTool() を呼び、自サイト固有の機能をツールとして登録します。サイト内検索・在庫照会・料金試算のように「このサイトにしかない処理」をエージェントへ開放できるのはこちらだけです。CDNのスイッチが提供するのは汎用のツールパックであり、自社の中核機能は自分で書かなければ公開されません。
公開してよい操作・避けるべき操作は?
読み取り専用の操作から始めるのが原則です。検索・照会・試算のように状態を変えないツールであれば、エージェントにできることは訪問者が画面から行えることの範囲を超えません。仕様には、状態を変えないことを宣言する readOnlyHint や、公開先を限定する exposedTo が用意されています。
避けるべきなのは、投稿・購入・送信・設定変更のように副作用のある操作です。エージェントは自然言語の指示から実行内容を組み立てるため、指示の解釈がずれたときに取り返しがつきません。認証済みの操作や決済につながる操作は、確認の仕組みが仕様と実装の両面で固まるまで公開を見送るのが安全です。自社サイトがエージェントからどう見えているかは、下の関連ツールに置いたエージェント対応度チェックで確認できます。