AIエージェントに「このページの価格表を取ってきて」と頼むと、その裏では今もフル装備のChromeが1つ丸ごと起動している。人間のためのタブ、拡張機能、テーマ、60fpsの描画、ピクセル単位で正確なCSS。エージェントが本当に欲しいのはページ内のテキストか1枚のスクリーンショットだけなのに、毎回その重量級ブラウザを立ち上げている。この無駄を正面から削りにいったのが、Cloudflareが公開したKitesurfというブラウザだ。
Kitesurfが面白いのは、ヘッドレスChromeを軽く使うための工夫ではなく、エージェント専用にブラウザエンジンそのものを別実装した点にある。仕組みも使い方も一次情報が公開されているので、順番に見ていく。
出典はCloudflareの公式ブログとドキュメント、それに独立系メディアInfoQの取材記事の3つを突き合わせた。
🪁 エージェントに要らないものを全部そぎ落とす
Cloudflareの主張はシンプルだ。
Browser engines like Chromium were built for humans, not agents, and they come with overhead that AI models simply do not need.
（Chromiumのようなブラウザエンジンは人間向けに作られていて、AIモデルには不要なオーバーヘッドを抱えている）
なので、Kitesurfはタブも拡張機能も同期機能も持たない。CSSの解釈が完璧でなくても、描画がピクセル単位で正確でなくても構わないと割り切っている。代わりに最適化するのは、トークン数、コンテキストウィンドウ、スケーラビリティ、コスト。エージェントが読み取る構造化されたテキストと、必要なら1枚の画像さえ出せればいい、という設計思想だ(公式ブログ)。
例えるなら、一晩泊まって机の上のメモ1枚を読むだけの客に、家具付きの一軒家を貸すのをやめて、必要な机とメモだけを置いた個室を毎回作って渡す、という発想に近い。ここが既存の「ヘッドレスChromiumをどう安く回すか」という発想との決定的な差分になる。
V8アイソレート上に、使い捨てのブラウザを1枚ずつ畳む
技術的な中身に入ると、KitesurfはChromiumのプロセスを起動しない。Cloudflare WorkersのV8アイソレート、つまり1リクエストごとに隔離される軽量な実行環境の上で動く。1ページが1つのWorkerに対応し、処理が終われば消える。ここで言うアイソレートとは、OSプロセスより桁違いに軽い分離単位のことだ。
構成は大きく3つに分かれている。CDP(Chrome DevTools Protocol、ブラウザを外部から操作する共通プロトコル)とセッション状態を捌く「Engine」、DOMとJavaScriptを担う「PageScript」、そして描画を担う「PageRenderer」。パース処理にはChromiumのエンジンではなく、Rust製のBlitzというレンダリングエンジンと、Firefox由来のCSSエンジンStyloが使われている。画像やPDFへのラスタライズはblitz-paint、フォントの字組みはParleyが担当する。InfoQも同じ構成を「Rustベースのコンポーネント群」として報じており、独立取材でも裏が取れている(InfoQ)。
要は、Chromeの巨大なコードベースを丸ごと動かす代わりに、ブラウザに必要な部品をRustの既製エンジンから組み直し、Cloudflareのエッジに載せている。標準への準拠度も無視していないと強調していて、Cloudflareによれば約21万件超のWeb Platform Tests(ブラウザの仕様準拠を測る公式テスト群)に合格しているという。
数字で見ると、速さではなく安さを買っている
肝心の効果を、Cloudflareが出した計測値で並べるとこうなる。ウォームプール状態、14 URLの中央値での比較だ。
| 処理 | 指標 | Kitesurf | Chromium比 |
|---|---|---|---|
| スクリーンショット | CPU時間 | 380ms | 約3.1倍少ない |
| HTML抽出 | CPU時間 | 229ms | 約3.8倍少ない |
| スクリーンショット | メモリ | 57.8 MiB | 約4.7倍少ない |
| HTML抽出 | メモリ | 39.4 MiB | 約7.0倍少ない |
ここで見落としてはいけないのが、実時間(wall time)は逆に約1.7倍遅いという点だ。コールドな状態からのラスタライズにコストがかかるためで、Cloudflare自身も認めている。つまりKitesurfが買っているのは1ページあたりのレスポンス速度ではなく、CPUとメモリの消費量、言い換えれば同じ計算資源で捌けるページ数とコストだ。
この割り切りは、実務の感覚に照らすと理にかなっている。エージェントが数千ページを巡回して抽出・撮影するようなバッチ的ワークロードでは、1ページの応答が0.数秒遅いことより、1台のサーバで何ページ回せるか、月末の請求がいくらかの方が効く。ヘッドレスChromeを大量に並べたことがある人なら、あのメモリの膨れ方を思い出すはずで、そこを7倍削れるなら遅さは受け入れやすい。逆に、対話中のエージェントが1ページを即座に見せる用途では、この遅さが気になる場面もあるだろう。
🔌 browser=kitesurf を足すだけで既存コードから使える
導入のハードルが低いのも実務的にありがたい。KitesurfはCloudflareのBrowser Runというサービス上で動き、既存のエンドポイントに browser=kitesurf というパラメータを付けるだけで、デフォルトのChromiumから切り替わる。CDPとMCPに対応しているので、PuppeteerでもPlaywrightでもchrome-remote-interfaceでも、そのまま繋がる。
まずはコードを書かずに試したいなら、公式のプレイグラウンドで任意のURLを入れてDOM・コンソール・ネットワークを覗ける。
REST APIで1枚撮るだけなら、ドキュメントのサンプルはこうなっている。
curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
-H 'Authorization: Bearer <API_TOKEN>' \
-H 'Content-Type: application/json' \
-d '{"url": "https://example.com"}' \
--output "screenshot.png"
PuppeteerやPlaywrightから繋ぐなら、CDPのWebSocketエンドポイントに同じパラメータを付ける。
wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf
MCPクライアント(例えばchrome-devtools-mcp)から使う場合の設定例も公開されている。
{
"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>\"}"
],
"enabled": true
}
}
}
上のコマンドとエンドポイントはすべてBrowser Runのドキュメントに載っているものだ。ベータ期間中は無料で、アカウントごとの上限が設けられている。既存のスクリプトを書き換えずにパラメータ1個で切り替えられる設計は、乗り換えコストと同時に「合わなければ剥がすコスト」も低いということで、試すハードルとしてはかなり低い。
⚠️ できないこと、そして少し引っかかる点
万能ではない。現時点で動画の再生、WebGLの描画、実際のTLSフィンガープリントを使ったbotチャレンジの通過、10分続くような認証済みセッションは扱えない(公式ブログ)。ログイン後の画面を長時間操作し続けるRPA的な用途や、動画・3Dが絡むページは今のところ範囲外だ。この線引きは、逆に「Kitesurfは短命・使い捨ての抽出と撮影に振り切った道具だ」という性格をはっきりさせている。
セッションが毎回まっさらから始まる設計は、セキュリティ面ではむしろ利点になる。Cloudflareは「すべてのページ読み込みは信頼できない入力であり、すべてのセッションは新規から始まる」という姿勢で、プロンプトインジェクションやツールの安全性を意識した隔離を売りにしている。untrustedなWebをエージェントに巡回させる以上、この使い捨て前提は理にかなっている。
一方で、無条件に礼賛できない点もある。InfoQによれば、RedditやHacker Newsでは利害の衝突を指摘する声が出ている。Cloudflareは本来ボットやスクレイピングを防ぐ側の会社なのに、今度はスクレイピングを楽にする道具を出している、という指摘だ。加えて、Kitesurfのコードが非公開である点、そして流用元のBlitzに改善を還元(upstream)していない点にも疑問が向けられている。ここは私も同感で、CDP互換のおかげで剥がすのは簡単とはいえ、心臓部が閉じていてCloudflareのエンドポイントに縛られる構造は、インフラとして深く依存する前に一度立ち止まる理由になる。
とはいえ、ブラウザを「人間が見るもの」から「エージェントがタスク単位で使い捨てる実行基盤」へと定義し直し、課金もCPU・メモリ単位で最適化するという方向性そのものは、この先いくつも追随が出てくるはずだ。今すぐ本番投入しないとしても、手元のスクレイピングやスクリーンショットのバッチに browser=kitesurf を一度足して、自分のワークロードで実時間と資源消費のトレードオフを測っておく価値は十分にある。
※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。