Cloudflareは2026年8月6日、AIエージェント向けブラウザエンジン「Kitesurf」をBrowser Runでベータ公開した。Chromeの画面を人間向けに作り替えた製品ではない。Chromiumを搭載せず、Cloudflare WorkersのV8 isolateとWebAssembly上でブラウザの機能を組み直した。狙いは、短時間のページ取得や画面生成を大量に走らせる際のCPUとメモリを減らすことにある。
ブラウザを使うAIエージェントは、タブやテーマ、拡張機能を必要としないことが多い。一方、従来のBrowser Runはheadless Chromeを起動するため、エージェントごとに用意する計算資源が並列数を制約する。Kitesurfは見た目の完全な再現や幅広い互換性を譲り、機械がページを読み、操作し、結果を返す処理へ資源を振り向けた。その代償も、公式ベンチマークにははっきり表れている。
CPUとメモリを減らし、待ち時間は増える
Cloudflareは14件のURLを使い、Browser RunのQuick Actionsを5回実行した中央値を公開した。比較相手は起動済みのChromiumである。スクリーンショットではKitesurfのCPU時間が380ミリ秒、Chromiumが1,173ミリ秒だった。HTML抽出でも229ミリ秒対877ミリ秒となり、KitesurfのCPU時間はChromiumの26〜32%だった。
| 処理 | Kitesurf | Chromium |
|---|---|---|
| スクリーンショットのCPU時間 | 380ms | 1,173ms |
| HTML抽出のCPU時間 | 229ms | 877ms |
| スクリーンショットのメモリ | 57.8MiB | 271.0MiB |
| HTML抽出のメモリ | 39.4MiB | 273.7MiB |
| スクリーンショットの経過時間 | 1,148ms | 637ms |
| HTML抽出の経過時間 | 820ms | 472ms |
表が示す取引条件は明快だ。Kitesurfのメモリ使用量はChromiumの14〜21%に縮むが、結果を受け取るまでの時間は1.7〜1.8倍に延びる。Cloudflareは、起動済みChromiumのJITに対し、Kitesurfの冷えたソフトウェアレンダラーが不利になるためだと説明する。ページを一つでも速く開く用途より、多数の独立した処理を限られた資源で回す用途に向く。
ただし、これはCloudflare自身が選んだ14件のURLによる測定である。サイトの複雑さ、キャッシュ状態、操作の長さが変われば差も動く。ベータ期間中のKitesurfは無料なので、この資源差が利用料金へどう反映されるかもまだ決まっていない。
Workersでブラウザを三つに分ける
Kitesurfは、セッションを管理するEngine、ページ内の文書とスクリプトを扱うPageScript、画面を画像へ変換するPageRendererを中心に構成する。外部から接続するEngineだけがセッション状態を保持し、ほかの部品は可能な限り状態を持たない。処理が停止すれば該当isolateを捨てて起動し直せるため、短い仕事が集中する負荷に合わせて数を増減しやすい。
ページごとにPageScriptのisolateを起動し、HTMLとJavaScriptを別のページから切り離す。HTMLとCSSの解析にはRust製のBlitzとFirefox由来のStyloを採用した。Workersがnative evalを許可していないため、evalが必要なJavaScriptはRust製ECMAScriptエンジンのBoa JSで実行する。さらにPageRendererを分け、EngineからWorker間RPCで描画を依頼する。描画側が固まっても、ページの状態を抱えたEngineまで巻き込まずに済む。
ネットワーク接続もSandboxOutbound workerへ集約した。ほかの部品はインターネットへ直接接続できず、SandboxOutboundがCORSを適用し、レスポンスを検査して、ページごとのcookie jarを保つ。任意のサイトを訪れるエージェントでは、読み込むページを最初から信頼しない設計が必要になるためだ。
この分離は、不正なページが触れられる資源と障害の範囲を狭める。ただし、CloudflareはKitesurfがプロンプトインジェクションを防ぐとは説明していない。ブラウザ内部の分離と、ページ上の命令をAIが信用してしまう問題は別に検証する必要がある。
既存のCDP接続からエンジンを選ぶ
2026年4月にBrowser Renderingから改称したBrowser Runは、Cloudflareのネットワーク上でheadless Chromeを動かし、PuppeteerやPlaywright、Chrome DevTools Protocol（CDP）から操作するサービスだった。Kitesurfはこの操作面を作り直していない。既存のCDP endpointやQuick Actionsへbrowser=kitesurfを加えると、実行エンジンだけを切り替えられる。
この互換層により、開発者はエージェントの制御コードを全面的に書き換えず、処理ごとにChromiumとKitesurfを選べる。MCPとCDPに対応するエージェントからも接続可能だ。短いHTML抽出やスクリーンショットはKitesurfへ流し、状態を維持する長時間の認証セッションや高い表示互換性が必要な仕事はChromiumへ残す運用が現実的である。
KitesurfはBrowser Run内でベータ提供され、現在は無料だがアカウント単位の上限がある。無料という条件より、同じAPIの背後で軽量エンジンを選択できる点の方が長く効く。Cloudflareにとっても、エージェントの同時実行数を増やす際に、Chromiumインスタンスの確保だけに依存しない経路ができた。
適合試験を通っても、実サイトは別問題
8月7日更新の公式文書によると、KitesurfはWeb Platform Tests（WPT）の235,000超のサブテストを通過している。DOMは97%、HTMLは96%、XHRは95%をカバーする一方、URLは83%にとどまる。WPTはWeb標準への適合を測る試験であり、個々の実サイトが正しく表示され、最後まで操作できることを保証しない。
現時点では動画とWebGLに対応せず、実際のTLSフィンガープリントを使うbot challengeの処理もできない。状態を保った長時間の認証セッションにも不向きで、該当する仕事にはBrowser Run既定のChromiumが推奨される。CDPの実装も一部に限られ、画面とPDFの再現度は開発途上だ。
Cloudflareは準備が整い次第Kitesurfをオープンソース化し、顧客自身のアカウントへ配備できるようにする方針を示した。ただし、公開日や正式提供の時期、ベータ後の料金は明らかにしていない。採用を決める材料はWPTの総数より、自社の対象サイトで完了率と経過時間をChromiumと比較し、軽くなった資源が失敗時の再試行を含めても得になるかどうかである。