「Kitesurf」解説｜AIエージェント専用ブラウザはE2Eにも使えるのか

Cloudflareが2026年8月6日、Kitesurf を発表しました。Chromiumを動かすのではなく、Workers の上でブラウザそのものを新しく実装したという尖った構想のプロダクトです。

▲ 発表元: Kitesurf: an agent-first browser built on Cloudflare Workers（Cloudflare公式ブログ・著者 Celso Martinho）

発表を読んで最初に浮かぶ疑問は、たいてい用途の切り分けです。APIを提供していないWebアプリをエージェントに操作させるためのものか、E2Eテスト基盤か、それともローカルのヘッドレスブラウザの置き換えか。 この記事では、まず結論としての向き不向きを示し、そのうえで「何が発表されたか」「なぜ作ったか」「仕組み」「性能」「使い方」「成熟度と料金」を整理します。

結論：用途の切り分け

さらに、公式が明確に「まだ向いていない」と挙げた条件が4つあります。動画再生・WebGL描画・実TLSフィンガープリントを要するbotチャレンジの通過・状態を保持する10分級の認証済みセッションです。これらはBrowser Runの既定であるChromiumを使う、という棲み分けが示されています。

つまり「ログインが必要な業務SaaSを長時間操作し続ける」タイプの自動化は現状Chromium側であり、Kitesurfが得意なのは短命・大量・使い捨ての作業です。

何が発表されたか：Workers上に実装された新しいブラウザ

Kitesurfは「Workersの上で完全に動作する新しいブラウザ」で、Cloudflareのブラウザ実行サービス Browser Run の選択肢として追加されました。Chromiumが引き続き既定で、Kitesurfは browser=kitesurf を付けたときに使われる代替エンジンという位置づけです。

重要なのは、Chromiumをコンテナで動かす従来型の延長ではなく、HTMLパース・CSS計算・JS実行・ラスタライズまでを自前実装してWebAssemblyに載せたという点です。ブラウザを軽量化したのではなく、必要な機能だけを持つブラウザを作り直した、という理解が近いです。

なぜ作ったか：Chromiumは人間向けで、エージェントには過剰

Cloudflareの主張は明快です。既存ブラウザは「エージェントではなく人間のために作られた」。結果として、AIモデルが必要としないメモリとCPUを大量に消費し、エージェント1体ごとにインスタンスを立てる運用ではコストが見合わなくなります。

公式ブログの表現では、AIが気にするのは次のものです。

AIはタブ・テーマ・ブラウザ拡張機能を気にしない。気にするのはトークン数、コンテキストウィンドウ、スケーラビリティ、性能、そしてコストだ。

言い換えると、人間向けブラウザの価値の多く（ピクセル完全な描画、滑らかな動画再生、拡張機能エコシステム）は、エージェント用途では支払っているのに使われていないコストです。Kitesurfはそこを削り、DOM構造・テキスト・スクリーンショットという「モデルが実際に読む出力」に資源を集中させています。

仕組み：3コンポーネントをWorkersのRPCで繋ぐ

内部はWorkers間のRPCで連携する3層構成です。

Engineが renderFrame() をPageRenderer側のWorkerに対して呼び、戻り値としてPNGを受け取る——といった具合に、ブラウザの内部構造がそのままWorkers間のRPC境界になっています。JSの eval() 対応には、Rust製のECMAScriptエンジン Boa JS を暫定的に使っているという記述もあります。

ネットワーク面では SandboxOutbound という専用Workerが外向き通信を仲介し、CORS処理とCookieの隔離（ページごとに独立したCookie jar）を担います。

設計原則として挙げられているのは4つです。

• 隔離：ページの読み込みは常に「信頼できない入力」として扱い、各コンポーネントには必要最小限のリソースしか渡さない
• ステートレス：コンポーネントは使い捨て前提。並列実行とコスト効率のために状態を持たない
• Rustファースト：性能が要る部分はRustで書きwasm-bindgen経由でWebAssemblyへ。エミュレーション層を挟まない
• 例外処理：どこが失敗しても劣化して動き続ける。「セッションが死ぬことはない」

エージェント運用の観点では、ステートレスであること自体が機能です。1リクエストごとに真っさらな隔離環境が立つので、並列で数百セッション回しても相互汚染がなく、後片付けも要りません。その代償が「認証済みセッションを長く維持できない」という制約であり、先の向き不向きはここから直接来ています。

性能：CPUとメモリで勝ち、レイテンシで負ける

14 URLのテストコーパスでのChromium（ウォーム状態）との比較です。

読み方は明快です。1件あたりの応答時間は負けるが、1件あたりの単価は3〜7倍安い。 遅さの理由はJIT（実行時最適化）の有無とコールドスタートで、Chromium側はウォーム状態の数字であることに注意が必要です。

この特性は用途を選びます。ユーザーを待たせる同期処理には不利ですが、「エージェントが1万ページを非同期に巡回する」ようなバースト型・並列型のワークロードでは、メモリとCPUの単価がそのままスループットの上限を決めるため有利になります。

使い方：既存ツールがそのまま繋がる

CDP互換を維持しているため、Puppeteer・Playwright・chrome-remote-interface が無改造で動くとされています。切り替えは接続先に browser=kitesurf を付けるだけです。

ワンショット処理向けの Quick Actions API はHTTP一発で完結します。

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://example.com"}' \
  --output "screenshot.png"

MCPクライアント（エージェントにツールを渡す標準プロトコル）から使う場合は、chrome-devtools-mcp のWebSocket接続先をKitesurfに向けます。

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ]
    }
  }
}

この設定を見ると、冒頭の「ローカルのヘッドレスブラウザとしても使えるか」への答えがはっきりします。ローカルで動くのはMCPサーバのプロセスだけで、ブラウザ本体はCloudflareのネットワーク上です。手元のマシンのメモリを節約したい、という文脈では合致しますが、オフラインやローカルネットワーク内のURLを開く用途には使えません。

動作確認用の公開プレイグラウンドも用意され、Chrome DevToolsが統合された状態で試せます。

成熟度：Web Platform Tests 21万件超、ただし「初期段階」

互換性の指標として、Web Platform Tests（ブラウザ標準の適合テスト群）を 約215,000件以上パスし、DOM・CSS・HTML・selection・SVG・XHRの領域で高いカバレッジを持つと報告されています。実サイトでは TodoMVC（vanilla・React・Vue・Angular・Preact）、Wikipedia、Hacker News、Cloudflareブログ、Cloudflareダッシュボードの多くが正しく描画できるとのことです。

一方で公式自身が「Kitesurfは初期段階にある」と明言しています。E2Eテスト用途を検討する場合、この点が判断の分かれ目です。「Chromiumで動くか」を検証したいテストを別エンジンで回すと、テストの目的そのものが崩れます。 Kitesurfで妥当なのは、ログイン後の画面遷移が壊れていないかといったDOM水準のスモークテストや、レポートPDF・スクリーンショットの定期生成といった「描画の厳密さより回数とコストが効く」領域です。

料金と今後：ベータ中は無料、OSS化を表明

• 現在：Browser Run経由でベータ提供、アカウント単位の上限付きで無料
• 将来：「準備ができたらKitesurfをオープンソース化する」と表明。実現すればローカル実行の道も開ける
• Chromiumを置き換えるものではなく、Browser Runの選択肢として併存する

実務への示唆

1. コスト構造が変わるのは「並列度」の側面。 エージェントにブラウザを持たせる構成で最初に詰まるのは、たいてい同時実行数です。1セッション40〜60 MiB級であれば、これまでコンテナ数で頭打ちになっていた並列巡回・並列スクレイピングの上限が上がります。単価が3〜7倍違うのは、月末の請求書ではなく「同時に何体動かせるか」に現れます。

2. 既存コードの評価コストは低い。 CDP互換で接続先パラメータだけの切り替えなので、手元のPuppeteer/Playwrightスクリプトをbrowser=kitesurfで走らせて、出力が壊れないかを比べるだけで適合判定ができます。ベータの無料期間中に自社の対象サイトで通るかを確かめておくのが安全です。

3. 判定は「対象サイト依存」。 向き不向きの実質的な境界は、機能一覧ではなく操作したいサイトがどれだけJS・WebGL・bot対策に依存しているかです。SPAのダッシュボードや文書系サイトなら通る可能性が高く、bot対策の強いポータルや動画を含む画面は現状Chromium側、という切り分けになります。

まとめ

• Kitesurfは、Chromiumを軽量化したものではなく、Workers上に新規実装されたエージェント向けブラウザ。Browser Runの選択肢としてbrowser=kitesurfで使える（既定はChromium）。
• 構成はEngine（CDP窓口）／PageScript（DOM・JS実行）／PageRenderer（描画）の3層で、Workers間RPCとRust+WebAssemblyで組まれている。
• Chromium比でCPU 3.1〜3.8倍・メモリ4.7〜7.0倍少ない一方、実時間は1.7〜1.8倍遅い。単価とスループットで勝ち、レイテンシで負ける。
• 本命用途はAPI非提供アプリに対するエージェント操作と、スクショ・PDF・HTML抽出のワンショット自動化。
• E2Eは限定的（別レンダリングエンジンのためビジュアル検証には使えない）、ローカルヘッドレス代替は現状不可（リモート実行のみ）。
• 動画・WebGL・botチャレンジ突破・長時間の認証済みセッションは非対応で、そこはChromiumを使う。
• ベータ中はアカウント上限付きで無料。将来のOSS化を表明。

「エージェントに手足としてブラウザを持たせる」構成が当たり前になるほど、ブラウザ1体あたりの原価が設計を縛ります。Kitesurfはその原価を一桁近く動かす提案であり、対象サイトが対応範囲に収まるかどうかで評価が決まります。まずはベータ無料期間に、実際に操作したいURLで通るかを試すのが現実的な一手です。

参考資料

• Kitesurf: an agent-first browser built on Cloudflare Workers（Cloudflare公式ブログ・2026年8月6日）
• Kitesurf 公開プレイグラウンド
• Agents Week 2026 Updates and Announcements（Cloudflare）