AIエージェントにブラウザ作業を任せると、画面の見た目が少し変わっただけで止まったり、意図しないボタンを選んだりすることがあります。
これは、従来のブラウザ自動化が、人間向けに作られた画面を読み取り、「次に何を押すか」を推測しているためです。画面を操作できることと、安定して同じ仕事を任せられることは別です。
その前提を変えようとしているのが、WebMCPです。
WebMCPは「画面を読む」代わりに「操作を渡す」考え方
WebMCPでは、Webサイト側がAIエージェントに使わせてよい操作を、ツールとして公開します。
例えば、サイト上に次のような操作があるとします。
・商品を検索する
・予約可能な日時を確認する
・ログイン済みの利用者の注文履歴を表示する
・下書き状態の内容を取得する
従来のエージェントは、画面から検索欄やボタンを探し、順番を推測して操作します。WebMCPの考え方では、サイトが「検索する」「予約可能日時を確認する」のような操作を明示します。エージェントは、許可された操作の一覧から選べるようになります。
ここで重要なのは、AIが急に万能になるという話ではないことです。サイト側が、何をさせてよいかを先に定義することで、画面の見た目への依存を減らす仕組みです。
Cloudflareは2026年8月にDeveloper Previewを発表した
Cloudflareは2026年8月6日、WebMCPのDeveloper Previewを発表しました。Cloudflareの説明では、サイト本体のコードを変更せず、ページに小さなbridgeを追加することで、ブラウザ内のAIエージェントが利用するツールを登録できるとしています。
Cloudflareは、WebMCPをChrome 146で実験的に提供されるブラウザ標準として紹介しています。また、Cloudflare側のPreviewでは、画像の来歴情報を読むContent Credentials packと、サイト側のMCPサーバーのツールをブラウザへ公開するSite MCP Server packを例として示しています。
ただし、これはDeveloper Previewです。対応するブラウザやAIエージェント、Cloudflareの利用条件、サイト側の構成を確認せずに、すぐ本番運用へ入れるものではありません。
まず分けるべきは「見る」「下書きする」「確定する」操作
WebMCPを検討するとき、最初に考えるべきは実装方法ではなく、操作の危険度です。
比較的検討しやすいのは、検索、閲覧、在庫や予約枠の照会、公開情報の要約、下書きの生成といった、結果を利用者が確認してから次へ進められる操作です。
一方で、次のような操作は同じ扱いにしないほうが安全です。
・メール、チャット、SNSの送信
・注文、予約、決済の確定
・公開済みページや顧客情報の更新
・権限の付与や削除
・外部サービスとの連携設定の変更
「操作できる」ことを理由に、確定操作まで公開する必要はありません。閲覧、候補提示、下書き、最終確定を別の段階に分けると、導入後の責任範囲を整理しやすくなります。
認証済みの画面を扱うなら、権限はさらに細かく分ける
Cloudflareが紹介するSite MCP Server packは、ページと同じオリジンで、利用者の既存セッションを使ってMCPサーバーのエンドポイントへ接続する構成です。
これは、ログイン後の利用者に必要な操作を届けられる可能性がある一方で、公開する操作の範囲を慎重に決める必要があることも意味します。
例えば、注文履歴の表示は許可しても、配送先の変更は許可しない。予約候補の提示は許可しても、予約の確定は利用者の明示的な確認後にする。このように、利用者の情報に触れる操作ほど細かく分ける設計が必要です。
AIエージェントに渡す権限を、サイトへログインした人が持つ権限と同じにする必要はありません。必要最小限の操作だけを渡すことが、設計の出発点になります。
WebMCPに向くのは、操作の意味を言葉で説明できるサイト
導入を検討しやすいのは、操作の目的と結果をはっきり説明できるサイトです。
・検索結果を返す
・指定条件の空き枠を返す
・利用者本人の履歴を表示する
・入力内容を検証して下書きを保存する
反対に、画面の状態や担当者の判断に強く依存する仕事、例外が多い承認、金額や契約条件を最終決定する処理は、Preview段階で急いで委ねる対象ではありません。
WebMCPは、複雑な業務を丸ごとAIへ渡すための近道ではありません。サイトが提供してよい行為を、利用者にも開発者にも説明できる形にするための設計材料です。