AI・テクノロジー

WebMCPとCloudflare OSで作るAIエージェント向けWeb

Cloudflareが2026年8月のAgents Weekで、サイトをAIエージェントから直接呼べるWebMCPと、オープンソースのAIワークスペースCloudflare OSを発表。エージェント専用ブラウザKitesurfやステートレス化したMCP新仕様まで、全体像と今日から試せる手順を整理します。

claude

• 7 min read
Share

WebMCPとCloudflare OSで作るAIエージェント向けWeb

2026年8月2日から7日にかけて、Cloudflareが2度目となる Agents Week を開催し、AIエージェントがWebを「使う」ための部品を一気に公開しました。目玉は2つです。ダッシュボードのトグル1つで既存サイトをAIエージェントから直接操作できるようにする WebMCP、そして社内業務をエージェントに開くオープンソースのAIワークスペース Cloudflare OS。さらにエージェント専用ブラウザ Kitesurf と、ステートレス化したMCPの新仕様も揃いました。これらが何を解決しようとしているのか、そして実際にどう触れるのかを整理します。

背景：Webはもともとエージェント向けに作られていない

現在のAIエージェントがWebサイトを操作する方法は、驚くほど原始的です。スクリーンショットを撮り、画像を解析し、ボタンらしき座標をクリックする。この「screenshot-analyze-click ループ」は遅く、壊れやすく、そして高くつきます。

Cloudflareは8月6日の記事で、エージェントを「CSSをレンダリングせず広告もクリックしないが、向こう側には支払い能力のある人間がいる訪問者」と表現しました。人間が一度も見ないHTMLタグを生成することは計算資源の無駄であるだけでなく、エージェントのコンテキストウィンドウを汚染する行為でもある——その答えとして示されたのが、Webを readable（読める）・discoverable（見つかる）・callable（呼べる）・payable（払える）の4軸で作り直す構想でした。

WebMCP：サイトを「読ませる」から「呼ばせる」へ

WebMCPは、Webサイトが構造化されたツールをページ内に登録し、ブラウザ内で動くAIエージェントがそれを発見して直接実行できるようにする仕組みです。座標クリックの代わりに、searchFlights() のような型付き関数を引数付きで呼ぶ。これが核心です。

土台はブラウザ標準の document.modelContext で、Chrome 146 に実験的に搭載されています。ツール定義には MCP標準の Tool と CallToolResult の型がそのまま使われるため、既存のMCP対応エージェントは追加実装なしで動きます。ブラウザが単なる「もう一つのMCPランタイム」になる、という位置づけです。

Cloudflareの実装で特徴的なのは、オリジンのコードを一切変更しない点です。エッジのHTMLRewriterが次の1行を注入します。

<script type="module"
        src="/.webmcp/bridge.js"
        data-packs="c2pa,mcp-server-client"
        data-mcp-url="/mcp"></script>

developer preview には2つのツールパックが同梱されています。c2pa はページ内の画像のContent Credentials（来歴情報）を走査するもので、現時点では署名検証まではしません（signatureVerified: false）。mcp-server-client は自前のMCPサーバーが公開するツールを同一オリジンのfetchでプロキシするもので、訪問者のセッションCookieがそのまま使われるため、ログイン済みユーザーの権限でエージェントが動きます。

重要なのは、すべてのツールが訪問者のブラウザ内で実行される点です。サイト側は公開するツールをトグルで制御でき、エージェントは登録されたツールの外側では動けません。人間が主導権を保ったまま、サイト運営者はトラフィックを失わない——Cloudflareが強調しているのはここです。

Kitesurf：エージェント側のブラウザを作り直す

同じ8月6日に発表された Kitesurf は、逆側からのアプローチです。Cloudflare Workers の V8 isolate 上で動く、エージェント専用のブラウザ。タブも拡張機能もありません。HTMLパースには Blitz、CSSには Firefox由来の Stylo を使い、いずれもRustからWebAssemblyにコンパイルされています。

性能の割り切り方が興味深いところです。実時間ではウォームなChromiumプールのほうが約1.7倍速い。しかし公開されたベンチマークでは、スクリーンショット取得でCPU消費が3.1分の1・メモリが4.7分の1、HTML抽出ではCPUが3.8分の1・メモリが7.0分の1になっています。実運用のコストを決めるのは同時実行数とセッションあたりのリソース消費なので、エージェント用途ではこちらが効くという判断です。

Kitesurf は動画再生、WebGL、長時間の認証済みセッションに対応していません。一方で Web Platform Tests は21万5,000件以上をパスしており、エージェントが実際に依存するDOM・CSS・HTML・SVGの領域は厚い。CDP互換なので Puppeteer や Playwright はそのまま接続でき、ベータ期間中は無料です。

Cloudflare OS：社内の業務をエージェントに開く

8月5日に発表された Cloudflare OS は、パブリックWebではなく企業内部に向いた製品です。「社内の全員がアプリを作り、業務を自動化し、内部システムに安全にアクセスできる」オープンソースのAIワークスペースで、ブラウザ上で動きます。

構成は3つの要素からなります。エージェントのセッション・永続状態・コード実行・組織のコンテキストをまとめた Agent Workspace、入口を Cloudflare Access で守りエージェントには権限ゼロから始めさせるセキュリティ層、そして個人用にも共有用にもなるフルスタックアプリのプラットフォーム。基盤は Workers、アプリごとに隔離されたSQLiteを与える Durable Object Facets、アプリ単位の軽量isolateを立てる Dynamic Workers です。

セキュリティ設計で注目したいのが Gatekeepers です。外部システムごとに置かれる仲介Workerで、OAuth処理、粒度の細かいポリシー適用、機微フィールドのマスク、レート制限、観測ログを引き受けます。さらに Observation Logging がエージェントの参照したリソースを全て記録し、共有された出力を経由した意図しない情報流出を防ぎます。推論はすべて AI Gateway を通るため、個人・チーム単位の費用按分と予算制御も効きます。

Cloudflare社内では2026年5月から全部門・数千人規模で稼働しており、その実績を経てのオープンソース公開という順序です。

4軸で整理する：今日から何が試せるか

Cloudflareが掲げる readable（読める）・discoverable（見つかる）・callable（呼べる）・payable（払える）の4軸に発表済みの製品を当てはめると、全体像がつかめます。

  • Readable：Accept: text/markdown を付けるとエッジがHTMLをMarkdownに変換して返す Markdown for Agents（2026年2月、beta）と、Kitesurf。前者は AI Crawl Control からトグルで有効化でき、Pro以上のプランで追加料金なしです。
  • Discoverable：自社データをエージェント向け検索にする AI Search（open beta）と、AIアシスタントからの引用率や言及率を測る AEO Visibility（early access 申請制）。
  • Callable：WebMCP に加え、MCPスキーマからTypeScript APIを生成しエージェントにコードを書かせる Code Mode。Cloudflare API全体を2ツールに畳んだ事例では、コンテキスト消費が117万トークンから約1,000トークンまで削減されました。
  • Payable：HTTPリクエストに支払いを添付する x402、エージェント用の Cloudflare Wallets、任意のリソースに課金する Monetization Gateway、ボットを暗号署名で同定する Web Bot Auth。

実際に手を動かす順序はこうなります。

  1. Agent Readiness で診断する — ダッシュボードの Agent Readiness で自サイトを採点します。robots.txtやサイトマップといった Quick wins から、MCPやOAuth discoveryを含む Advanced integration、x402などの Commerce まで4段階。各項目の「Copy Agent Prompt」ボタンで、修正指示をそのままコーディングエージェントに渡せます。
  2. WebMCP を有効化する — Agent Readiness > Labs から WebMCP をドメイン単位でオンにし、curl -s https://your-site.example | grep webmcp で注入を確認します。
  3. 動作テストする — Browser Run の lab セッション（lab=true、Chrome 146 beta）で確認します。ただし lab は本番非推奨で、@cloudflare/puppeteer と @cloudflare/playwright はまだ lab パラメータに対応していません。

なお8月6日には、MCP自体の新仕様（2026-07-28版）も公開されました。initialize ハンドシェイクと Mcp-Session-Id ヘッダを廃した完全ステートレス設計になり、Workers上では Durable Objects なしでMCPサーバーをデプロイできます。

影響と今後

サイト運営者にとって、これは検索エンジン最適化の次に来る作業がはっきりしたことを意味します。エージェントが顧客の代理として訪れる比率が上がるなら、「エージェントから見えるか、呼べるか、課金できるか」が事業上の可用性そのものになるからです。

一方で、この領域はまだ固まっていません。WebMCPは developer preview、Monetization Gateway は waitlist、Cloudflare Wallets の決済機能は「まもなく」の段階です。同時に発表された Agent Access Model は製品ではなく提案アーキテクチャであり、Cloudflare自身が「複数主体が絡むアクセス制御は未解決の系統的問題」と認めています。

注意深く見ておきたいのは、Cloudflareが繰り返し「オープン」を強調している点です。x402、MCP、Web Bot Auth といった標準の上に構築し、「Cloudflareは選択肢の一つであってスタック全体ではない」と明言しています。とはいえ、エッジで注入し、検証し、課金するという構造自体が強力な位置取りであることは間違いありません。標準がどこまで相互運用可能なまま育つかが、今後の分かれ目になりそうです。

よくある質問

WebMCPを使うのにサイトのコードを書き換える必要はありますか

WebMCP の developer preview の範囲では、サイト側のコード変更は不要です。Cloudflareのエッジが HTMLRewriter でブリッジスクリプトを1行注入するため、ダッシュボードのトグルだけで有効化できます。ただし自前のツールを公開したい場合は、mcp-server-client パックから参照するMCPサーバーを別途用意する必要があります。

WebMCPはCloudflare独自の仕組みですか

いいえ。WebMCP はブラウザ標準の document.modelContext と Model Context Protocol の標準型の上に作られており、既存のMCP対応エージェントがそのまま動きます。Cloudflareが提供しているのは、その標準をオリジン改修なしで既存サイトに載せる橋渡し部分です。

Kitesurf は Chrome の代わりになりますか

用途次第です。Kitesurf は動画再生やWebGL、長時間の認証済みセッションに対応しておらず、実時間の処理速度でも Chromium のほうが約1.7倍速いため、汎用ブラウザの完全な置き換えにはなりません。一方で Kitesurf はCPUとメモリの消費が3〜7分の1に収まるため、大量のページを並列に読ませるエージェント用途ではコスト面で有利です。

Cloudflare OS は無料で使えますか

Cloudflare OS のソフトウェア自体はオープンソースとして公開されており、自前でデプロイできます。ただし動作には Workers、Durable Objects、Access、AI Gateway といったCloudflareのサービスが必要になるため、それらの利用条件は別途確認が必要です。

AIエージェント対応は何から始めればいいですか

Cloudflareダッシュボードの Agent Readiness 診断が出発点として最も費用対効果が高いです。robots.txtやXMLサイトマップ、Markdown配信といった Quick wins は短時間で対応でき、各項目の「Copy Agent Prompt」で修正指示をコーディングエージェントに渡せます。WebMCPや決済まわりは、その土台が整ってからで十分です。

まとめ

2026年8月のAgents Weekで、Cloudflareはエージェンティック・Webの構想を製品として具体化しました。WebMCPはサイトを「呼べる」ものに変え、Kitesurfはエージェント側のブラウザを作り直し、Cloudflare OSは同じ発想を企業の内部業務に持ち込みます。

個々の機能はまだプレビューやベータの段階ですが、readable・discoverable・callable・payable という4軸の整理は、優先順位を決めるうえで実用的な枠組みです。まずは Agent Readiness で現状を測り、WebMCPや決済まわりは仕様の固まり具合を見ながら段階的に取り込む——現時点ではこれが現実的な進め方でしょう。

参考ソース

関連記事