Overview
サイトを見るのは、もう人間だけではない。
2026年8月7日、CloudflareがWebMCPのdeveloper previewを発表した。「スイッチ1つで、あらゆるサイトがブラウザAIエージェントから使えるようになる。新しいAPIは不要、サーバー側の改修もゼロ」。この発表を見て、その日のうちにandoor.coを対応させた。かかった作業はトグル1回。検証まで含めて1時間かからなかった。
この記事は、その導入実録。何が起きて、何が変わるのかを、実測ベースで書く。
WebMCPは何をするのか
サイトが「読まれる対象」から「操作できる道具」に変わる。
これまでのWebサイトは、AIにとってただのテキストの塊だった。エージェントがサイトを使おうとすると、画面を無理やり解析してボタンの位置を推測するしかない。遅いし、壊れやすい。
WebMCPは、サイト側が「このサイトでできること」をエージェントに直接教える仕組み。MCP(Model Context Protocol)というAIとツールをつなぐ標準規格を、ブラウザの中に持ち込んだ。
Cloudflareの実装が賢いのは、この仕組みをエッジで完結させたこと。配信時にHTMLへスクリプトを1本注入するだけ。サイト本体のコードには一切触れない。
導入は本当に「スイッチ1つ」だったか
本当だった。ダッシュボードのトグル1回で終わった。
手順はこれだけ。Cloudflareダッシュボードでゾーンを開き、Agent ReadinessのLabsセクションでWebMCPをON。デプロイなし、コード変更なし、DNS変更なし。
ONにした直後、実測で確認した内容:
- 全ページのHTMLに47KBのbridge.jsが自動注入されていた。トップも、英語版も、下層ページも
- コンソールエラー0件。既存のアクセス解析との干渉なし
- CSP(Content Security Policy)は変更不要。同一オリジン配信のため、厳しめの設定でもそのまま通った
- 非対応ブラウザでは静かに何もしない。通常の訪問者への影響はゼロ
「オリジン改修ゼロ」という売り文句は、誇張ではなかった。
ただし、まだ誰も来ない
サイト側の準備はできた。エージェント側が、まだ来ていない。
現時点でブラウザ側のWebMCP APIを持つのは、実験フラグを立てたChromeの最新版だけ。つまり今andoor.coをエージェント対応にしても、実際に「使いに来る」エージェントはほぼいない。
だったら急ぐ意味はないのか。逆だと考えている。
この非対称が重要で、サイト側の対応はコストほぼゼロで先行できる。エージェント側が普及した瞬間、対応済みのサイトと未対応のサイトの間に体験の断層ができる。SEOで起きたことと同じ構図。検索エンジンが来る前にサイトマップを置いた者が先行した。
検索エンジンに読まれるための最適化がSEOなら、次はエージェントに使われるための設計。呼び名はまだ定まっていないが、構造の変化はもう始まっている。
なぜ発表当日に動いたのか
触っていない技術について語る言葉は、全部借り物になるから。
AIと人が一体になって仕組みを発明し、美しいプロダクトを届ける。ANDOORはそう掲げている。この看板の下で「WebMCPというものが出たらしいですよ」と伝聞で語るのは違う。
自分のサイトで有効にして、注入されたスクリプトを読み、CSPとの相性を検証し、非対応ブラウザでの挙動まで実測した。ここまでやって初めて、クライアントに「入れるべきか、待つべきか」を自分の言葉で言える。
developer previewの技術をクライアントの本番に入れることはしない。それは検証と冒険の区別がついていないだけ。まず自分のサイトで試す。壊れてもいいのは自分の城だけ。
We ship. We own. 出荷して、結果を引き受ける。発表当日の1時間は、その実践だった。
まとめ
- WebMCPはサイトをAIエージェントの「道具」にする標準規格。Cloudflareがスイッチ1つで有効化できるpreviewを出した
- andoor.coで実測した限り、導入コストはほぼゼロ。既存サイトへの副作用もゼロ
- エージェント側の普及はこれから。ただしサイト側は今すぐ、無料で先回りできる
- 触ってから語る。順番を守るだけで、言葉の重さが変わる
サイトの向こうに立つのが人間だけだった時代が、終わろうとしている。