Cloudflare OSの記事を読んだ流れで、同じ週にCloudflareが出していたKitesurf（2026-08-07公開）も読んだ。こちらはCloudflare OS本体とは別プロダクトで、Cloudflare Workers上で動く「AIエージェント専用のブラウザ」。GIGAZINEの解説記事も分かりやすかったので合わせて読んだ。テーマとしては「AIエージェントがブラウザの中で動く」というCloudflare OSと地続きの話で、数字の出し方が具体的で面白かったのでまとめておく。
なぜ既存のヘッドレスChromiumではダメだったのか
エージェントがWebページを見に行くとき、多くの場合ヘッドレスのChromiumが使われている。でもChromiumはあくまで人間向けに作られたブラウザで、タブ・テーマ・拡張機能といった、AIエージェントには要らない機能を全部抱えている。エージェント側が本当に必要としているのはトークン数・コンテキストウィンドウ・スケーラビリティであって、それとは別の脅威モデル（プロンプトインジェクションなど）にも晒される。メモリとCPUを食う専用インスタンスを1エージェントごとに立てるのはコスト的にも厳しく、結果として高性能なモデルにしかブラウザアクセスを与えられない、という制約が生まれていたらしい。Kitesurfはこの「人間向けブラウザをエージェントに間借りさせている」状態そのものを解消しようとしている。
アーキテクチャは3つのコンポーネントに分かれている
- Engine — 唯一の公開インターフェース。Chrome DevTools Protocol（CDP）をWebSocketとREST APIで受け付け、セッション状態を保持する。ここ以外は基本ステートレス
- PageScript — Dynamic Workersを使って、ページ（やOOPIF）ごとに独立したWorkerを立てる。クリーンな
globalThisとDOMを初期化し、HTMLパースとJavaScript/WebAssemblyの実行を担当 - PageRenderer — PageScriptから受け取った「シーン」をラスタライズし、JPEG/PNG/PDFとして返す。フォントや画像はStatic Assetsから取得
外部への通信はSandboxOutbound Workerという別コンポーネントに一元化されていて、CORS適用・ブラウザヘッダの注入・レスポンス監視・クッキーの隔離をここでまとめて行う。ページごとに独立したWorkerを都度生成する構成は、Cloudflare OSでアプリのサーバー処理をDynamic Worker + Durable Object Facetで動かしていたのと同じ設計思想に見える。
ゼロから書かずOSSを組み合わせている
ブラウザエンジンを一から書くのではなく、Rust製のパーツを寄せ集めて作っているのが特徴的だった。
- Blitz — HTMLのパースとレンダリング（Rust製、Wasm対応）
- Stylo — CSS解析。Firefoxでも使われている実装
- Boa JS — ECMAScript実行エンジン
- Parley — テキストの成形・グリフ化
RustからWasm-bindgen経由で直接WebAssemblyにコンパイルすることで、Emscriptenのモック依存レイヤーを挟まずハードウェアに近い性能を出す、という選び方をしている。
ベンチマークの数字がわかりやすい
14URLのコーパスで、ウォームプールのChromiumと比較した中央値が公開されている。
| 指標 | Kitesurf | Chromium | 差 |
|---|---|---|---|
| CPU時間（スクリーンショット） | 380ms | 1,173ms | 約3.1倍削減 |
| CPU時間（HTML抽出） | 229ms | 877ms | 約3.8倍削減 |
| メモリ（スクリーンショット） | 57.8MiB | 271.0MiB | 約4.7倍削減 |
| メモリ（HTML抽出） | 39.4MiB | 273.7MiB | 約7.0倍削減 |
| 壁時計時間（スクリーンショット） | 1,148ms | 637ms | 約1.8倍遅い |
| 壁時計時間（HTML抽出） | 820ms | 472ms | 約1.7倍遅い |
CPUとメモリは大幅に軽い一方、壁時計時間（実際にかかる時間）はChromiumのほうが速いという、正直な数字の出し方をしているのが好印象だった。「立ち止まって速さを競えばChromiumが勝つが、CPU・メモリではKitesurfが圧倒的」という書き方で、メモリ効率がそのままコスト効率に効いてくる設計だと説明している。品質面ではWeb Platform Testsを21万5000件以上通過していて、CSS・DOM・HTML・SVG・XHRといったエージェントが実際に使う領域を重点的に伸ばしているらしい。TodoMVCやWikipedia、Hacker News、Cloudflare自身のダッシュボードでの動作も確認済みとのこと。
使い方とできないこと
Chrome DevTools ProtocolのサブセットでPuppeteer・Playwright・chrome-remote-interfaceといった既存ツールからそのまま使える。Browser Runというプロダクト上で、MCP/CDP接続時やQuick Actionsでbrowser=kitesurfをクエリパラメータに指定すれば切り替わる仕組みで、公開プレイグラウンドも用意されている。ベータ期間中は無料とのこと。
一方でビデオ再生・WebGL・TLSフィンガープリントを使ったボット対策の突破・10分を超える永続セッションには対応していない。短時間で終わるバースト的なタスク向けに割り切った設計で、長時間ログインを維持し続けるような使い方は想定されていない。今後はCDPカバレッジの拡大、スクリーンショット品質の向上、WPT通過率の継続的な引き上げに加えて、顧客が自分のアカウントに独自のKitesurfをデプロイできるOSS化も計画しているそうだ。
Cloudflare OSと並べて見ると
Kitesurf単体の記事にCloudflare OSへの言及はなかったけれど、「エージェントの実行環境をブラウザ・Workerの中に閉じ込めて、必要な分だけ軽く立ち上げる」という発想は共通している。Cloudflare OSがDynamic Worker + Durable Object Facetでアプリの実行環境を分離していたのと同じ発想が、ブラウザという単位でも繰り返されている感じがして、Cloudflareの中で一貫した設計思想があるんだろうなと思って読んだ。
AIはタブ、テーマ、拡張機能を必要としない。
というくだりが、この製品の割り切り方を一番よく表していた。