WebMCPとは｜自社サイトをAIが使える道具にする

「予約の変更」「見積もりの依頼」「在庫の確認」——自分が返信しないと何も進まない問い合わせが毎日届き、そこが事業の上限になっている。

結論から言うと、この構造を崩す選択肢が2026年8月に1つ増えました。WebMCP——サイト側が「AIエージェント用の操作口」を用意しておく仕組みで、Cloudflareが2026年8月6日に開発者プレビューを公開しています。エージェントに画面を推測させるのではなく、こちらが「これは使っていい道具です」と定義して差し出す発想です。

株式会社Fyveは、AIに業務を任せる仕組みを自分たちで組んで運用しています。私はこれまで、公式APIが無いサービスをブラウザの通信を観測して自動化する——つまり「推測する側」を散々やってきました。この記事では、その経験から見て何が本当に変わるのか、そして開発者プレビュー段階の今、何をやって何をやらないべきかを整理します。

WebMCPとは何か——エージェントに「推測させる」のをやめる仕組み

WebMCPは、Webサイトがブラウザ上で動くAIエージェントに対して「使える操作の一覧」を公開するためのブラウザ標準です。Cloudflareの発表文の言い方を借りれば、サイトが道具の集合を提示することで「エージェントは、人間向けに作られたページを手探りで進む必要がなくなる」。

ここが肝心なところなので、少し噛み砕きます。

これまで：エージェントは「画面を見て当てる」しかなかった

AIエージェントに何かのサイトで作業させるとき、エージェントがやっていることは本質的に推測です。ページのHTMLを読み、ボタンのラベルを読み、「たぶんこれが送信ボタンだろう」と当たりをつけて押す。人間が目でやっていることを、機械が文字列から再現しているだけです。

この方式には構造的な弱点が3つあります。

• 当たらないことがある：同じ「確定」という文字が3箇所にあれば、どれが正解かは文脈依存になる
• 黙って壊れる：サイト側がデザインを少し変えただけで動かなくなる。しかもエラーではなく「間違ったボタンを押す」形で壊れる
• サイト側に打ち手がない：運営者にできるのは実質「弾く」だけ。使わせ方をコントロールする手段がない

これから：サイトが「道具」に名前を付けて渡す

WebMCPが変えるのはこの前提です。サイト側が「予約を変更する」「在庫を照会する」といった操作に名前と入出力を定義して公開し、エージェントはその定義された道具を呼び出す。画面のどこを押すかを当てる工程が、まるごと不要になります。

名前のとおり、これはMCP（Model Context Protocol）の考え方をブラウザに持ち込んだものです。MCPそのものについては別記事で解説しています。

Claude CodeMCPとは？仕組みと実務での活用法をわかりやすく解説

MCPが「AIと外部サービスをつなぐ共通規格」だとすれば、WebMCPは「AIと、いま開いているそのWebページをつなぐ共通規格」です。つなぎ先がサーバーではなくブラウザの中である、という違いだと考えると早いです。

発表内容の事実整理

⚠️ ここで強調しておきたいのは、「開発者プレビュー」かつ「標準自体もプレビュー」という二重の前提です。今日から本番の予約受付を全部任せられる、という話ではありません。仕様の細部は変わり得ます。

私がこの発表に反応した理由——「推測する側」を実際にやってきたから

正直に書くと、私はまだWebMCPを自分の本番サイトには入れていません。開発者プレビューで、対応ブラウザも実験段階だからです。それでもこの発表を重く見ているのは、私が長いこと「推測する側」に立っていたからです。

公式APIが提供されていないサービスを自動化したいとき、私が取ってきた手段はブラウザの裏で流れている通信を観測して、内部で使われているAPIを割り出すという方法でした。この手順自体は別記事にまとめています。

Claude Code公式APIが無いサイトを自動化する方法｜裏のAPIを観測

この方法は確かに動きます。ただ、やってみるとよく分かるのは「推測は当たらない。観測しないと分からない」ということと、それでもなお相手の都合で壊れるということです。相手が仕様を変えた瞬間、こちらの自動化は静かに死にます。連絡は来ません。

そして重要なのは、これは自動化する側の問題ではなく、双方にとっての損だという点です。サイト運営者からすれば、自分のサイトが意図しない使われ方をしているのに、それを整える手段がない。使う側からすれば、いつ壊れるか分からないものに業務を乗せている。誰も得をしていません。

WebMCPが解こうとしているのは、まさにこの「双方にとって損な状態」です。運営者が「この操作なら使っていい」と明示できれば、使う側は壊れにくい道具を得て、運営者は使われ方の主導権を得る。私が実際に困ってきた場所に、正面から刺さっています。

Cloudflareの実装は具体的に何をやっているのか

ダッシュボードのスイッチ1つ。originは触らない

Cloudflareの実装で一番驚いたのは、導入手順の軽さです。公式ブログには「これで設定は全部です。デプロイするものは何もないし、originで変更するものも何もありません」と書かれています。

やることは、Cloudflareのダッシュボードで対象ドメインの「Agent Readiness」からWebMCPをオンにし、公開する道具のセットを選ぶだけ。アプリケーション側のコードは1行も変えません。

仕組みとしては、Cloudflareがエッジ側でHTMLを書き換え、ページに小さな橋渡し用のスクリプトを差し込んでいます。これがブラウザ内のエージェントに対して道具を登録する役割を持ちます。技術メディアのInfoQも同様の解説をしており、同一オリジンの制約はそのまま維持されると触れています。

最初から入っている2つの道具セット

プレビュー時点で用意されている道具セットは2つです。

• Content Credentials：ページ内の画像に埋め込まれた来歴情報（C2PAメタデータ）をエージェントが読めるようにする。「この画像はどこから来たのか」を機械が確認できる
• Site MCP Server：すでに自社でMCPサーバーを持っている場合、そこで定義した道具をブラウザ内のエージェントへ橋渡しする

実務的に効いてくるのは明らかに後者です。すでにMCPサーバーを持っている事業者にとっては、追加の実装ではなく「既存の道具の配布経路が1本増える」話になります。私自身、X検索用のMCPサーバーを自分で書いて無人ジョブから使わせていますが、あの手のものを「ページを開いた人のAIにも使わせる」という発想は今までありませんでした。

導入前に押さえておくべき制約

この表を見て「まだ早い」と判断するのは、まったく正しい読み方です。今この段階でやる価値があるのは、実装ではなく設計のほうだと私は考えています。次のセクションがその話です。

robots.txtでの「AI対策」とは何が違うのか

ここは混同されやすいので、はっきり分けておきます。これまでのAI対策とWebMCPは、そもそも相手にしている対象が違います。

つまりこの2つは排他ではありません。「コンテンツの無断収集はこれまでどおり制御しつつ、決められた操作だけは道具として開放する」という組み合わせが普通に成立します。

むしろ実務的には、この2つを分けて考えられるかどうかが分かれ目になります。「AIに関わりたくないから全部塞ぐ」と決めてしまうと、収集への対策と操作の開放という本来は別々に判断できる2つを、まとめて捨てることになります。

1人・小規模事業でどう使うか——3ステップ

ここからが本題です。ツールが揃うのを待つ必要がない部分——つまり今日から手を動かせる部分を切り出します。

STEP 1：任せたい操作を書き出す

最初にやるのは技術的な作業ではありません。「自分が返さないと止まる問い合わせ」を紙に並べることです。

• 予約日時の変更・キャンセル
• 見積もりの概算依頼
• 在庫・空き状況の照会
• 営業時間・アクセス・対応エリアの確認
• 過去の注文履歴の照会

この時点では、機械に任せられるかどうかは考えなくて構いません。「自分の時間を実際に奪っているもの」を順番に並べるのが目的です。

STEP 2：1つずつ「道具」の形にする

ここが一番時間がかかり、そして一番価値がある工程です。並べた操作の1つを取って、次の3点を決めます。

• 名前：何をする道具か（例：予約日時を変更する）
• 受け取る情報：動かすために何が必要か（例：予約番号、希望日時）
• 返すもの：結果として何を返すか（例：変更後の予約内容、または空きが無い旨と代替候補）

この作業をやると、多くの場合自分の業務の曖昧さが露出します。「当日キャンセルは電話のみ」「常連さんは特例で融通している」——そういう例外が、道具の定義を書こうとした瞬間に全部出てきます。

私はこれを「工程を刻む作業」と呼んでいます。AIに任せられる形に整理するとは、結局自分の仕事を、他人に説明できる粒度まで分解することです。この作業自体は、WebMCPが正式版になろうがならなかろうが無駄になりません。

STEP 3：相手にはURLを渡すだけ

道具が定義できていれば、あとは配るだけです。ここが従来と決定的に違うところで、相手に渡すのはURL1本になります。マニュアルも、アカウント発行も、初期設定の説明も要りません。相手は自分のAIにそのページを開かせればいい。

業種別：最初に出す道具は何にするか

「1つ選べ」と言われると意外と迷うので、考え方の例を挙げます。共通するのは①頻度が高い ②答えが一意に決まる ③間違えても取り消せるの3条件です。

• 飲食店：空席状況の照会。予約の確定より先に「今夜19時に4名入れるか」だけを返す道具にする
• クリニック・治療院：診療時間と休診日の照会。次に初診の受付可否。予約変更は最後
• 工務店・リフォーム：対応エリアの判定。「この住所は対応範囲内か」は答えが一意で、外れていれば早く分かるほど双方の得になる
• 士業・コンサル：相談メニューと料金体系の照会。個別案件の判断は絶対に道具にしない

逆に最初に出してはいけないものもはっきりしています。金額の確定、キャンセル料の判断、値引きの可否、断りの連絡。これらは間違えたときに信用で払うことになるので、手順が決まっているように見えても人が持ち続けるべき領域です。

社内にも同じことが起きる——「手順書をPDFで配る」のをやめる

この発想が効くのは、実は社外向けの問い合わせだけではありません。今回の発表を追いかけていて、現場でこう当てている人を見かけました——社内共有用の手順を道具として作り、社員にはURLを渡すだけにするという使い方です。

これは考えてみると、かなり大きな転換です。これまで社内の業務手順を共有する方法は、突き詰めると「文書を作って、読ませて、覚えさせる」の一択でした。手順書のPDF、マニュアルのスプレッドシート、動画。どれも受け取った人間が読んで理解して実行することを前提にしています。

だから手順書は必ず陳腐化します。更新しても読み直してもらえない。新人が入るたびに同じ説明をする。誰かが自己流でやり始めても気づけない。

道具として渡す形にすると、この前提が変わります。手順が「読ませるもの」から「呼び出せば実行されるもの」になる。更新すれば、次に呼び出した全員に自動的に反映されます。

もっとも、これも万能ではありません。判断が要る仕事は道具にできないからです。値引きしていいかどうか、この例外を認めるかどうか、この案件を断るかどうか——こういうものは定義できません。だからこそ、STEP 2の分解で「判断が要るもの」と「手順が決まっているもの」を仕分ける作業が効いてきます。

守る側から、差し出す側へ

ここ数年、Webサイト運営者にとってAIの話題はほぼ「守る」文脈でした。学習データとして収集されないようにする、クローラーを制御する、コンテンツを勝手に使われないようにする。robots.txtやアクセス制御の議論が中心だったはずです。

私はそれ自体を否定しません。実際、守るべきものはあります。ただ、「守る」以外の選択肢が事実上存在しなかったのがこれまでの状況で、そこが今回変わりました。

誤解されがちなので明記しておくと、差し出す側に回ることは主導権を手放すことではありません。Cloudflareの発表でも「人間が主導権を持ち、コンテンツの作り手はトラフィックを維持する」という設計思想が明示されています。訪問者がサイトに来る流れも、運営側のコントロールも、元のサイトに残ったままです。

そして差し出す道具は自分で選べます。「営業時間の照会だけ出して、それ以外は出さない」でいい。全部か、ゼロかではないということが、ブロック一択だった頃との一番の違いです。

そのうえで、私の判定を書きます。読まれないように守るフェーズは、そろそろ終わりに向かっています。これから差が付くのは、自分の側から道具として差し出した側です。理由は単純で、エージェントを使う人間が増えるほど「エージェントから使いやすい事業者」が選ばれるからです。人間が電話とFAXしか受け付けない店を避けるようになったのと、同じことが起きます。

今日やるなら何をするか

プレビュー段階での現実的な動き方を、優先順に並べます。

1. 業務の棚卸しを先にやる（今日できる・最優先）

前述のSTEP 1とSTEP 2です。これは技術の成熟を待つ必要がまったくありません。しかも棚卸しの結果は、WebMCPが普及してもしなくても、AI活用の全施策の土台になります。ここを飛ばして機能だけ追いかけると、たいてい「入れたけど何を任せるか決まっていない」で止まります。

2. 渡す範囲を先に決める（実装より先）

AIに何かを任せるとき、私が必ず先にやるのは「越えたら止める線」を引くことです。何ができるかを広げる前に、何をさせないかを決める。この順番を逆にすると、事故が起きてから慌てて制限をかけることになります。

AI業務効率化AIにメール・予定を任せる境界の作り方

WebMCPの場合、具体的には「どの操作を道具として出すか」がそのまま権限設計になります。照会系（読むだけ）から始めて、更新系（書き込む）は後回しが定石です。間違えても取り返しがつく操作から出す。

3. 検証環境で試す（技術検証をする場合）

実際に触ってみるなら、本番ドメインではなく検証用のサブドメインで試すのが安全です。開発者プレビューであること、対応ブラウザが実験段階であること、この2点から本番投入は時期尚早だと判断しています。

4. 「取り消せるか」を先に確認する

実装より先に決めておくべきことがもう1つあります。エージェントが操作した記録が、あとから追えるかどうかです。

人間が電話で予約を変更したなら、受けた本人が覚えています。エージェント経由だと、そこが抜けます。「誰の依頼で・いつ・何が変わったのか」が残らない仕組みに操作を開放すると、間違いが起きたときに戻せません。

私が無人でジョブを回すときに必ず用意しているのも、結局は同じものです。実行の記録と、おかしくなったときに元に戻せる経路。この2つが無い自動化は、動いているうちは快適でも、壊れた日に全部が止まります。開放する操作を選ぶ基準に「取り消せるか」を1つ足してください。

5. 既存のMCPサーバーがあるなら棚卸しする

すでに社内でMCPサーバーを運用している場合、Site MCP Serverの道具セットは「今ある道具をそのまま配布経路に載せる」という意味を持ちます。この場合だけは、検討の優先度が一段上がります。

よくある質問

Q. 新しくAPIを作る必要はありますか？

Cloudflareの実装を使う場合、新しいAPIの開発もorigin側の改修も不要とされています。ただし「何を道具として出すか」の設計は必要です。技術的な工数より、業務の整理に時間がかかると考えておくのが実態に近いはずです。

Q. サイトが乗っ取られたり、勝手に操作されたりしませんか？

公開する道具は運営者が選べます。出していない操作は、これまでどおりエージェントから触れません。またエージェントは訪問者のブラウザ内で、その訪問者のログイン状態の範囲で動作します。とはいえプレビュー段階のセキュリティ評価が確定しているわけではないので、本番導入の際は最新の公式ドキュメントで確認してください。

Q. Cloudflareを使っていないと導入できませんか？

WebMCP自体はオープンな仕様として標準化が進められているもので、Cloudflare専用の機能ではありません。Cloudflareが提供しているのは「コードを書かずに有効化できる実装場所」です。他の手段で同じ仕様に対応することは、原理的には可能です。

Q. SEOやAI検索への影響はありますか？

現時点で検索順位への影響を示すデータはなく、断定できることはありません。ただ、エージェント経由の流入という導線が今後増えるとすれば、「人間に読ませる最適化」と「エージェントに使わせる最適化」は別物として扱う必要が出てきます。これは今後の観測対象だと考えています。

Q. 中小企業が今すぐ着手すべきですか？

実装は待っていいですが、業務の棚卸しは今すぐやるべきだというのが私の答えです。理由は前述のとおりで、棚卸しの成果はこの技術の成否と無関係に効いてくるからです。何から手を付けるか判断がつかない場合は、専属AI活用顧問サービスのような形で、業務の分解から一緒に進める選択肢もあります。

まとめ

要点を整理します。

• WebMCPは、サイトがAIエージェントに「使える道具」を公開するためのブラウザ標準。エージェントが画面を推測する工程がなくなる
• Cloudflareが2026年8月6日に開発者プレビューを公開。ダッシュボードのスイッチ1つで有効化でき、origin側の改修は不要
• ただし標準・実装ともにプレビュー段階で、対応ブラウザも実験的サポート。本番投入は時期尚早
• 今日やるべきは実装ではなく棚卸し。「自分が返さないと止まる問い合わせ」を並べ、名前・入力・出力の3点で道具の形に分解する
• この分解作業はWebMCPの成否と無関係に価値がある。AIに任せられる形に整理するとは、自分の仕事を他人に説明できる粒度まで刻むことだから
• 渡す範囲は自分で選べる。照会系から始めて、更新系は後回し

私自身、公式APIが無いサービスを推測と観測で自動化してきた側の人間です。だからこそ、あの不毛さが構造的に解消される方向に進んでいることは素直に歓迎しています。守る一択だった状況が終わりつつあるのは、Webサイトを持つ事業者にとって単純に選択肢が増えたということです。

まずは、自分が今週返信した問い合わせを5つ書き出すところから始めてみてください。株式会社Fyveでも、この棚卸しから伴走しています。