CloudflareがChromiumを捨てた — エージェント専用ブラウザ「Kitesurf」がメモリを1/5にした構成

はじめに

エージェントに Web を見せる、という要件を実装したことがある人なら、最初にぶつかる壁を知っているはずだ。Puppeteer なり Playwright なりを立ち上げ、その裏でヘッドレス Chromium が起動する。1セッションあたり数百 MB のメモリを食い、起動に数秒かかり、同時実行数はすぐ頭打ちになる。やりたいことは「このページの本文を取ってきて」だけなのに、GPU 合成もタブ管理も拡張機能ランタイムも一式ついてくる。

2026年8月6日、Cloudflare がこの前提そのものを外した Kitesurf を公開した。Chromium を使わない。V8 isolate 上で動く自前のブラウザエンジンを、Rust 製 OSS の寄せ集めで12週間で組み上げたという。Chromium 比で CPU 3.1〜3.8倍、メモリ 4.7〜7倍の削減を謳っている。

この記事では、Kitesurf が何をどう組み合わせて「ブラウザ」を名乗っているのか、その数字がどこから出ているのか、そして何と引き換えなのかを、構成レベルで読んでいく。

何が公開されたか

Kitesurf は Cloudflare の Browser Run（旧 Browser Rendering）経由で、無料ベータとして提供開始されている。アカウントごとの利用上限つきだ。使い方は3通り用意されている。

CDP（Chrome DevTools Protocol）互換。Puppeteer / Playwright / chrome-remote-interface からそのまま繋がる。既存の自動化コードを書き換えずに接続先だけ差し替えられる、というのが売りだ。
Quick Actions。スクリーンショットと HTML 抽出だけなら REST を1発叩けば済む。
```
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"}'
```
注目すべきはクエリパラメータの browser=kitesurf だ。既存の Chromium バックエンドと同一 API 上でエンジンを切り替える設計になっている。移行コストの置き方としてかなり素直だ。
公開プレイグラウンド。kitesurf.cloudflare.app で DevTools つきの検査ができる。

適合性の指標として、Cloudflare は Web Platform Tests を 215,000件以上パスしていると公表している（CSS / DOM / HTML / selection / SVG / XHR / Streams で強いカバレッジ）。TodoMVC、Wikipedia、Hacker News、Cloudflare 自身のブログとダッシュボードの大部分が正しく描画されるという。将来的な OSS 化も予告されている。

中身は何でできているのか — Rust製OSSの分業

Kitesurf の面白さは、独自実装がほとんどない点にある。既存の Rust 製コンポーネントを役割ごとに貼り合わせている。

レイヤー	使っているもの	出自
HTML パース / レンダリング	Blitz	Dioxus Labs
CSS 処理	Stylo	Firefox の CSS エンジン
テキスト整形・グリフ選択	Parley	Linebender
`eval()` の実行	Boa JS	Rust 製 ECMAScript エンジン

Firefox の CSS エンジンである Stylo が Cloudflare のエッジで動いている、という絵面だけでも十分に奇妙で面白い。Stylo は元々 Servo 由来で Firefox に取り込まれた並列 CSS スタイル計算エンジンであり、単体クレートとして切り出されているおかげでこういう再利用ができる。

そして Blitz は「radically modular な HTML/CSS レンダリングエンジン」を名乗るプロジェクトで、WebRTC・WebSocket・localStorage といったものを最初から任意機能として外している。ブラウザの全部入りを目指していない。ただし Blitz 自身はpre-alpha であり、JavaScript バインディングを持たない。ここが構成上の勘所になる。

JavaScript はどこで動くのか — V8とBoaの二段構え

Blitz に JS がないなら、ページのスクリプトは誰が実行するのか。答えは Cloudflare Workers 自身の V8 isolate だ。

Kitesurf は Engine / PageScript / PageRenderer の3コンポーネントで構成される。ページのスクリプトは PageScript ワーカーの中で、まっさらな globalThis と DOM を与えられた状態で走る。つまり Workers というランタイムがすでに持っている V8 をそのままページ実行環境として流用している。「ブラウザを Workers に載せた」のではなく、「Workers の isolate モデルの上に、足りていなかった DOM とレンダラを後付けした」と読むのが正確だ。ここが Chromium をコンテナに詰めて動かす従来型との決定的な差になる。

ではなぜ Boa JS が別途必要なのか。Workers はセキュリティ上ネイティブの eval() をサポートしていないからだ。動的コード生成を含むページを踏むと V8 側では実行できない。そこで Rust 製の Boa をインタプリタとして持ち込み、eval() 呼び出しだけをそちらに逃がしている。プラットフォームの制約を、別エンジンを1つ足すことで埋めた形だ。なお実行対象は JS だけではなく、見つかった <script> タグと .wasm ファイルを同一 isolate 内で走らせる、と明記されている。

コンポーネント間は Worker-to-Worker RPC で繋がっており、Engine がステートレスな PageRenderer を呼ぶ。レンダリングに失敗した isolate は自動で再起動される。設計思想として徹底しているのは degradation の扱いで、例外が起きても空フレームや要素欠落として劣化するだけで、セッションは決して落とさない。各ページロードを untrusted として扱い、各コンポーネントには必要最小限のアクセス権しか与えない、という分離前提も明記されている。

PageRenderer は計算済みのページオブジェクトを JPEG / PNG / PDF のイメージバッファに変換する。スクリーンショットと PDF 生成という、エージェント用途で最も需要のある2つがここに落ちている。

ベンチマークの読み方 — 何と引き換えなのか

Cloudflare が公開した数字は 14 URL のコーパス、5回実行の中央値だ。

指標	Kitesurf	Chromium（ウォーム）
CPU: スクリーンショット	380 ms	1,173 ms
CPU: HTML 抽出	229 ms	877 ms
メモリ: スクリーンショット	57.8 MiB	271.0 MiB
メモリ: HTML 抽出	39.4 MiB	273.7 MiB

CPU で 3.1〜3.8倍、メモリで 4.7〜7倍の削減。一方で wall time は Kitesurf のほうが 1.7〜1.8倍遅い。ここを見落とすと評価を誤る。

つまりこれは「速くなりました」という話ではない。レイテンシを犠牲にして、密度を買っている。1リクエストの完了は遅くなるが、同じハードウェアに載る同時セッション数が数倍になる。エージェントのブラウジングは「1本の応答を人間が待つ」のではなく「数百本を並列に走らせて結果を集める」形をとることが多いので、支配的なのはスループットとコストのほうだ、という賭けである。

コストの文脈も押さえておくと理解しやすい。既存の Chromium ベースの Browser Run は、Workers 有料プランで月10時間・同時ブラウザ月平均10台までが無料枠に含まれ、それを超えた分に $0.09 / ブラウザ時間、Workers Bindings 経由なら追加の同時ブラウザ1台あたり $2.00 が課金される。実行時間だけでなく同時実行数そのものが課金軸になっているので、1セッションあたりのメモリを 1/5 にできるなら、それはそのまま単価に効く。無料ベータ中の Kitesurf に価格は出ていないが、この構造を見れば何を狙って作られたエンジンかは明らかだろう。

なお 215,000件の WPT パスは立派な数字だが、Chromium の適合性と同列には置けない。Cloudflare 自身が「毎週数百件ずつ追加でパスさせている」と書いており、現在進行形の途上にあることを認めている。

エンジニアへの影響 — 使える場所と、まだ使えない場所

Cloudflare は現時点で使えないものを4つ、明記している。

動画再生
WebGL レンダリング
ボットチャレンジ対応のための TLS フィンガープリント交渉
永続状態を要する10分単位の認証セッション

この4つに加えて、リストとは別に設計思想としてはっきり書かれているのがピクセル完全性の放棄だ。「CSS のパースが多少ずれていても、レンダリングがピクセルパーフェクトでなくても、エージェントは困らない」——これは制約ではなく意図的なトレードオフとして提示されている。裏を返せば、描画の見た目そのものが成果物になる用途（ビジュアルリグレッションテストなど）は最初から対象外ということでもある。

この線引きは率直に言って、用途の判断材料としてかなり分かりやすい。TLS フィンガープリント非対応という項目は、スクレイピング対策を敷いたサイトを相手にする用途が現状ほぼ無理であることを意味する。CAPTCHA やボット検知の突破は想定されていない。同様に、ログイン状態を保って数分にわたり操作するタイプの自動化——SaaS の管理画面を巡回させるような処理——も、ステートレス設計と正面から衝突する。

逆に噛み合うのは、single-shot な取得系タスクだ。URL を渡してスクリーンショットを撮る、DOM を抽出して LLM に食わせる、PDF を吐く。RAG のクローラ、リンク先のプレビュー生成、エージェントの「この URL を見て」に応える部分。ここは Chromium を起動する必要が最初からなかった領域であり、Kitesurf の想定利用シーンとぴたりと重なる。

導入判断の進め方としては、CDP 互換であることを利用するのが早い。既存の Playwright / Puppeteer コードの接続先を差し替え、あるいは Quick Actions なら browser=kitesurf を付けるだけで、自分の対象サイト群で描画が壊れないかを実測できる。Cloudflare のベンチは 14 URL のコーパスに過ぎず、自社のクロール対象がその分布に収まる保証はどこにもない。壊れるページの割合と、削減できるコストを天秤にかける——判断材料は自分で取るしかない。

もうひとつ、この発表が示しているのはコンポーネント再利用の到達点だ。Stylo（Firefox）、Blitz（pre-alpha）、Parley、Boa。production 品質を名乗っていない部品を含めて組み上げ、12週間でエッジに載せたという事実は、ブラウザエンジンが「10年かけて作るもの」から「組み立てるもの」に変わりつつあることを意味する。Blitz を native アプリの UI レンダラとして検討していた人にとっても、実運用に晒された事例が1つ増えたことになる。

今日のその他のニュース

Oracle が OpenJDK への AI 生成コード投入を禁止（HN 162pt）。Larry Ellison が「Oracle はもう自分でコードを書いていない」と公言する一方での措置で、ねじれとして注目を集めた。OSS プロジェクトにおける AI 生成コードの著作権・ライセンス由来リスクが、大規模プロジェクトの明文ポリシーとして現れ始めている。

GitHub にスタック型プルリクエストが公式登場。gh stack で大きな変更を依存関係のある小さな PR に分割できる。Graphite などサードパーティが担ってきた領域が公式機能になった形で、エージェントが吐く大きな差分をレビュー可能な単位に割るワークフローと相性がいい。

Postgres の分析クエリを300倍速くした話（HN 159pt）。Rust 製の pgrust が Volcano モデルを捨て、1,024行バッチ処理・オペレータ融合・SIMD を積んで、5億件の合計を PostgreSQL 18.4 の約20秒から135ms まで縮めた。ディスク I/O 前提の1980年代の設計を、RAM に載る前提で組み直すという主張だ。

まとめ

Cloudflare が Chromium を使わないエージェント専用ブラウザ Kitesurf を無料ベータで公開した。Browser Run 上で browser=kitesurf により既存 API から切り替えられ、CDP 互換で Puppeteer / Playwright からも繋がる。
中身は Blitz（HTML/レンダリング）+ Stylo（Firefox の CSS エンジン）+ Parley（テキスト）+ Boa（eval() 用）という Rust 製 OSS の分業。ページの JS は Workers の V8 isolate がそのまま実行し、Workers が禁じる native eval() だけを Boa に逃がしている。
Chromium 比で CPU 3.1〜3.8倍・メモリ 4.7〜7倍の削減。ただし wall time は 1.7〜1.8倍遅い。速度ではなく同時実行密度とコストを買う設計だ。
WebGL・動画・TLS フィンガープリント・長時間認証セッションは非対応。刺さるのはスクリーンショット / DOM 抽出 / PDF といった single-shot タスクに限られる。

「エージェント向け」を謳う製品の多くは既存プロダクトへの API 追加に留まるが、Kitesurf はレンダリングエンジンから積み直している点で毛色が違う。人間が見るための描画品質を捨てれば、ブラウザはここまで軽くなる——その実測値が公開された意味は小さくない。OSS 化が実現すれば、エージェント基盤を自前で持つ側にとっての選択肢はさらに広がる。