Cloudflareが WebMCP の developer preview を出したわね。ダッシュボードでスイッチを入れると、オリジンのコードを触らずにサイトへエージェント向けツールを足せる——そういう売り方よ。
アタシが読んだあとで引っかかったのは、機能の一覧じゃなくて 「それ、いつ・誰に対して有効になるの？」 だった。結論から言うと、WebMCP の熱さはプロトコル名そのものより、MCP ツールの発見の仕方を変える ところにある。今日はその軸で整理するわ。
そもそも WebMCP って何よ
Web は長いあいだ「向こう側に人間がいる」前提で作られてきた。ページを読む、ボタンを押す、フォームを埋める。でも最近の訪問者には AI エージェントが増えてる。そのとき古典的な答えがスクレイピング——HTML を持って帰って、サイトにはトラフィックも文脈もあまり残さない、ってやつ。
WebMCP（Web Model Context Protocol）は、それに対する別案よ。Chrome 側で実験的に載っているブラウザ標準で、ページ上に document.modelContext という面が出る。サイトはここに 型付きのツール を registerTool できる。エージェントは DOM を勘でクリックする代わりに、list_articles や search_products みたいな関数を呼べる。
ポイントは、ツールが そのページのドキュメントに紐づく こと。サーバの隅に常駐する API というより、ブラウジングセッションの中の道具箱に近い。
Cloudflare のプレビューがやってること
実装を全部自分でやるのは「小プロジェクト」よ。ツール設計、配線、標準の追従。Cloudflare はそこをエッジで肩代わりする。
- Dashboard の Agent Readiness → WebMCP をオン
- エッジの HTMLRewriter が
/.webmcp/bridge.jsを差し込む（同一オリジン） - bridge が WebMCP 面を見つけて、選んだ pack を
registerTool - 非対応ブラウザなら何もしない。人間向けページはそのまま
プレビューの pack 例：
- Content Credentials (C2PA) … 画像の provenance をブラウザ内で読む（現状は暗号的な署名検証まではしない、という注意付き）
- Site MCP Server … 同一オリジンの
/mcpをtools/listして、各ツールを WebMCP にプロキシ。訪問者のセッション付きで呼べる
つまりスイッチは メニュー板の掲示と配線。厨房（ビジネスロジック）まで自動生成するわけじゃない。
スイッチオン ≠ 全エージェントが突然使える
ここ、マーケの言い方と実態がズレやすいからはっきり書く。
有効になる条件はだいたいこう：
- 誰かのブラウザがその URL を開く（後述の「来訪」）
- そのブラウザに WebMCP 面がある
- エージェントが tool 一覧を発見して呼ぶ実装を持っている
HTTP で HTML を GET するだけのクローラが、勝手に WebMCP を使い始めるわけじゃない。スイッチは「オプトインのツール公開面を生やす」までよ。
「来訪」って何？
いちばんふわっとしやすいのがここ。アタシの定義はこう：
誰かの自動化されたブラウザが、その URL を document として開いた瞬間。
人が Chrome で開くのと同じ条件。違うのは操作者が人間じゃなくてエージェントなだけ。
具体例：
- チャットで「このページ見て」「予約して」と頼む → エージェントがブラウザを起動して URL を開く
- 「ホテル探して」みたいなタスクで、検索結果から詳細ページへ辿る（各ページを開くたびに、そのオリジンの tool が見える）
- ユーザーがすでに開いているタブに対して、同居しているエージェントが同じ
modelContextを使う
来訪じゃないもの：
- 事前登録したリモート MCP への API 呼び出し（ページを開かない）
- 単なるスクレイプ用の HTTP GET（JS の道具箱としては動かないことが多い）
ページを閉じれば、その場の tool も消える。常時公開のグローバル API というより、セッションに紐づく一時的な道具箱 よ。
リモート MCP との本当の違い
ビジネスロジック（本物の handler）があるなら、WebMCP が無くても世界は回る。普通にリモート MCP を公開すればいい。
でもリモート MCP は、だいたい 利用者が先に設定する 世界よ。コネクタやマーケットプレイス、URL の手入力、OAuth。知らないサーバーには繋がらない。MCP サーバー設定、まあまあ面倒でしょ？
WebMCP がアツいのは、その儀式を飛ばして 「開いたページの tool がそのまま見える」 方向だから。利用者視点では「MCP を設定した」感が薄くて、エージェントがページと話してるだけに見える。
対比を一文でまとめると：
- リモート MCP … 接続の意思表示が先（カタログ型・設定型の発見）
- WebMCP … 訪問が先（ページに載ってる tool をその場で使う）
難しさが消えるんじゃなくて、オンボーディングの場所が設定画面からページに移る。そこが熱い。
ビジネスロジックは誰が実装する？
注文ボタンのメニューを出しても、押されたあとの厨房は別問題よ。
- Cloudflare が用意した汎用 pack（C2PA など）… 向こうの実装で動く
- Site MCP Server pack …
/mcpへのプロキシ。検索や予約の中身はアンタの handler - 独自の業務ツール … 自分で書くか、将来の pack を待つか
だから「スイッチがあればプロダクトがエージェント対応完了」ではない。入口のコストが下がるだけ。すでに堅牢なリモート MCP があって、ブラウザ内の訪問者セッションとつなぎたいわけでもないなら、WebMCP は必須じゃない。あると楽、というレイヤ。
自前で WebMCP 対応するのも、ゼロからプロトコルを発明するほどじゃない。既存の /mcp を tools/list して registerTool でプロキシする小プロジェクト。キツいのは tool 設計と権限と、実験 API の追従よ。
記事の本線と、わざと踏み込まない話
この記事の本線は 発見の仕方（カタログ型 vs 訪問型） と 来訪の意味。Cloudflare のリモートブラウザ製品（Browser Run）は、対応エージェント環境の一例にはなるけど、WebMCP の説明の主役にするとズレる。だからここでは深入りしない。
おわりに
WebMCP を一言で言うなら、「サイトがエージェントに公式の操作メニューを、ページ訪問の文脈で渡す仕組み」。スクレイプの代替としてサイト側が主導権を持ちつつ、利用者にはコネクタ設定の山を見せない——そのトレードオフの提案よ。
アタシのブログ自体を WebMCP 対応するかは、また別の機会にする。まずはこの整理を置いとくわ。次にやるなら list_articles / search_articles / get_article くらいの読み取り専用ツールから、で十分だと思ってる。