Kitesurf が WebMCP に対応。エージェントがクリックを模倣せず、サイトの関数を直接呼べるようになった

要約

Cloudflare が2026年9月28日、Kitesurf の更新を公開しました。Kitesurf は2026年8月6日にベータ公開された、Workers 上で完全に動作するエージェント専用ブラウザです。

今回の中心は WebMCP 対応です。 これが何を変えるかというと、エージェントがクリックを模倣する必要がなくなります。

従来のブラウザ自動化はこうでした。ページを読み込み、DOM を解析し、目的のボタンやフォームを特定し、座標を出し、クリックし、遷移を待ち、結果の DOM を読む。この一連の操作列が、すべて「人間の操作を機械が真似る」形で組まれています。 途中でレイアウトが変われば壊れ、要素の特定に失敗すれば止まります。

WebMCP では、サイト側が関数を公開します。 公式が挙げている例は searchFlights() です。エージェントはこの関数を直接呼びます。 公式の説明は「より速く、より確実」。画面を経由せずに、サイトの機能そのものへ到達します。

Web 標準のカバー範囲も大きく広がりました。 CSS Layout、CSS Object Model、Custom Elements、URL ベースのモジュール解決、JSON モジュール、import maps、iframe の挙動改善に対応。Web Platform Tests の通過サブテスト数が約230,000件から730,000件超へ増えています。 8月のベータ公開時点が「215,000件以上」だったので、1か月半で3倍以上です。エージェント専用に絞って作ったエンジンが、実用に耐える互換性へ急速に寄ってきている、という状況です。

性能は DOM 操作・タイマー・フォント読み込みを最適化してエージェントループ内のレイテンシを削減しつつ、壁時計時間と CPU 使用量は「ローンチ時のベンチマークとおおむね同水準」に保たれています。互換性を3倍にしながら、速度とコストを維持したという主張です。

面白いのはターミナル描画の追加です。 Kitty graphics protocol または ANSI テキストモードで、ページをターミナル上に描画できます。 目的は「エージェントが Web ページをどう見ているかを開発者が目視する」こと。エージェントの認識を人間がデバッグするための機能で、Homebrew で入れられます。

アクセス手段は3つ。 刷新された kitesurf.dev プレイグラウンド、Browser Run API、ターミナル。Browser Run API の全面対応により CDP / Playwright / Puppeteer / MCP から利用でき、Quick Actions にも対応します。料金はベータ期間中は無料で、アカウント単位の上限があります。

なお同日の changelog では、WebMCP が Kitesurf セッションへ拡大したこと、そして標準の document.modelContext へ移行したことが告知されています。 Lab セッションの実験 API navigator.modelContextTesting は廃止されました。使っていた場合は移行が必要です。

何が変わったか

• WebMCP 対応。エージェントがサイトの公開関数（例: searchFlights()）を直接呼び出せる
• Web Platform Tests の通過サブテスト数が約230,000件から730,000件超へ（8月ベータ時は215,000件以上）
• CSS Layout / CSS Object Model / Custom Elements / URL ベースのモジュール解決 / JSON モジュール / import maps / iframe 挙動に対応
• DOM 操作・タイマー・フォント読み込みを最適化。壁時計時間と CPU 使用量はローンチ時ベンチマークとおおむね同水準を維持
• ターミナル描画（Kitty graphics protocol / ANSI テキストモード）。Homebrew で導入
• Browser Run API の全面対応。CDP / Playwright / Puppeteer / MCP から利用可能、Quick Actions 対応
• アクセスは kitesurf.dev プレイグラウンド / Browser Run API / ターミナルの3経路
• ベータ期間中は無料、アカウント単位の上限あり
• changelog 側で navigator.modelContextTesting が廃止され、標準の document.modelContext へ移行

業務インパクト（一般企業向け）

社内の RPA・Web 自動化を持っている組織にとって、方向性が示された更新です。 現在の自動化は、ほぼすべてが「画面操作の模倣」で組まれています。そして、そのすべてが画面変更で壊れます。 業務システムの UI が更新されるたびにスクリプトを直す、という保守コストを抱えている組織は多いはずです。

WebMCP は、この構造そのものを変える提案です。 サイト側が関数を公開し、エージェントがそれを呼ぶ。画面が変わっても関数の契約が変われば済む——API と同じ考え方を、Web ページの上に持ち込んでいます。

ただし、これは「サイト側が対応していれば」の話です。 ここが実務上の分かれ目で、WebMCP は自社が使う側であると同時に、自社が提供する側にもなります。

自社サイトを持っている組織には、新しい判断が発生します。 「自社サイトの機能を、エージェントに関数として公開するか」 です。公開すれば、AI エージェント経由の予約・検索・問い合わせが確実に動くようになります。公開しなければ、エージェントは従来どおり画面を推測して操作し、失敗もします。これは SEO とは別軸の設計課題です。 検索エンジンに見つけてもらう話ではなく、エージェントに正しく使ってもらう話です。

セキュリティ面では、公開する関数の粒度が論点になります。 検索は公開してよいとして、予約確定は? 決済は? 「エージェントに直接呼ばせてよい操作」と「人間の確認を挟むべき操作」の線引きを、関数の設計時点で決める必要があります。画面経由なら確認ダイアログで止められたものが、関数呼び出しでは止まりません。

検証の観点では、ターミナル描画が実用的です。 「エージェントがページをどう見ているか」が見えると、自動化が失敗したときの原因切り分けが速くなります。 「クリックできていない」のか「そもそも要素が見えていない」のかを、推測でなく目視で判断できます。

導入判断としては、ベータである点を踏まえてください。 無料かつアカウント単位の上限つき。本番の基幹業務に入れる段階ではなく、既存の自動化資産を Kitesurf で動かしてみて互換性を測る段階です。エンジンが Chromium ではないため、既存資産がそのまま動く保証はありません。

副業・個人活用視点

スクレイピングや自動化を受託しているなら、コスト構造が変わる可能性があります。 Kitesurf は Workers 上で動くため、大量並列の実行が現実的です。 そしてベータ期間中は無料。「Chromium を何十個も立てる」前提で見積もっていた案件は、前提から組み直せます。

壊れにくさのほうが、実は効きます。 受託で自動化を納品すると、「先方のサイトが変わって動かなくなりました」という保守依頼が定期的に発生します。 これは収入でもありますが、割に合わない仕事でもあります。WebMCP 対応サイトが増えれば、この種の保守は減ります。 減る前提で、保守契約の内容を見直す時期が来るかもしれません。

逆に、新しい仕事も出ます。 「自社サイトを WebMCP 対応させたい」という需要です。エージェント経由の流入を取りたい事業者は、遠くない将来これを考え始めます。SEO 対策の隣に「エージェント対応」という項目が並ぶという見立ては、それほど飛躍していません。いま触っておくと、需要が立ち上がったときに提案できる側に回れます。

個人の実験用途としては、ターミナル描画が単純に面白い使い方です。 自分が作ったサイトをエージェントの目で見る。「人間には読めるが、エージェントには構造が分からない」ページが、自分のサイトに何枚あるか。これは無料で確認できます。アクセシビリティの話と重なる部分が大きいので、その観点の改善にもそのまま使えます。

注意点を2つ。 エンジンが Chromium ではないので、既存の Puppeteer / Playwright スクリプトがそのまま動く保証はありません。 切り替え前に実測してください。もう1つ、ベータ期間中無料ということは、課金開始後の価格が未定ということです。コスト前提で顧客に提案する場合は、そこを明示しておくのが安全です。