Kitesurf：Cloudflare が作った「エージェント専用ブラウザ」がベータ公開

要約

Cloudflare が 2026-08-06、AI エージェント向けに設計したブラウザエンジン「Kitesurf」を Browser Run 上でベータ公開しました。

発想の出発点は、既存のブラウザがすべて人間向けに最適化されているという点です。Chromium はページを美しく描画し、スクロールを滑らかにし、複雑なレイアウトを正確に再現することに膨大なリソースを割いています。しかしエージェントがブラウザを使うとき、効いてくる指標はまったく別です。ページを読んだ結果が何トークンになるか、コンテキストウィンドウに収まるか、数千セッションを同時に立てられるか、1リクエストあたりいくらか。Kitesurf はこちらを優先して作り直されたエンジンです。

構成は Cloudflare Workers 上の3コンポーネントに分かれます。Engine が Chrome DevTools Protocol（CDP）の通信とセッション状態を扱います。PageScript は動的に起動する isolate で、HTML と CSS のパース、JavaScript の実行を担当します。ここは Rust から WebAssembly にコンパイルしたモジュールで実装されています。PageRenderer は Blitz のレンダリング部品を使って、ページオブジェクトを画像に変換します。

性能として公式が挙げているのは、スクリーンショット取得時に Chromium 比で CPU 消費 3.1 倍削減、メモリ 4.7 倍削減という数字です。加えてステートレス設計であるため、エージェント特有のバースト的な負荷 — 突然数百セッションが立ち上がるような使われ方 — に対して水平にスケールできると説明されています。

「独自エンジンだと動かないサイトが出るのでは」という当然の懸念に対しては、Web Platform Tests を 215,000 件以上パスしていると回答しています。ただし全方位の互換ではなく、CSS / DOM / HTML / XHR という「エージェントが実際に使う API」を中心にカバーしたという書き方です。

使い方は3経路が用意されています。既存の Puppeteer / Playwright / chrome-remote-interface のコードに browser=kitesurf パラメータを付けてエンジンを切り替える。スクリーンショットや PDF 生成なら Quick Actions の REST エンドポイントを直接叩く。あるいは公開プレイグラウンド kitesurf.cloudflare.app で、Chrome DevTools を繋いだ状態で挙動を確認する。ベータ期間中は無料で、アカウント単位の上限がかかります。

この発表は同日公開の「Agentic Internet」構想の一部で、4本柱のうち Readable（エージェントが読める形でWebを配信する）に位置づけられています。

何が変わったか

• Browser Run のブラウザエンジンとして、Chromium 以外に Kitesurf を選べるようになった
• 既存の Puppeteer / Playwright / chrome-remote-interface のコードに browser=kitesurf を追加するだけで切り替えられる
• スクリーンショット・PDF 生成を Quick Actions の REST エンドポイントから直接呼べる
• Cloudflare Workers の V8 isolate 上で動作し、ステートレス設計で水平スケールする
• スクリーンショット取得で Chromium 比 CPU 3.1倍削減・メモリ 4.7倍削減（公式計測）
• Web Platform Tests を 215,000 件以上パス（CSS / DOM / HTML / XHR 中心）
• 公開プレイグラウンド kitesurf.cloudflare.app で DevTools 付きの検証ができる
• ベータ期間中は無料（アカウント単位の上限あり）

業務インパクト（一般企業向け）

ブラウザ操作を含む自動化を持っている企業にとって、これは「コスト構造が変わるかもしれない選択肢」として検証する価値があります。

現実の業務でブラウザ自動化が使われる場面は、API が提供されていない社内外システムの操作、取引先ポータルからの定期的なデータ取得、Web アプリケーションのリグレッションテスト、公開情報の定点観測といったあたりです。これらはいずれも「大量に、定期的に、並列で」動かす性質を持ちます。ヘッドレス Chromium はこの用途で動くものの、1セッションあたりのメモリ消費が大きく、並列度を上げるとインフラ費用が線形以上に膨らみます。CPU 3.1 倍・メモリ 4.7 倍という削減幅が自社のワークロードでも再現するなら、同じ予算で並列度を数倍にできる計算になります。

ただし、そのまま乗り換えられる話ではありません。エンジンが Chromium ではない以上、既存の自動化スクリプトが同じように動く保証はありません。特に、複雑な JavaScript フレームワークで作られた業務システム、Canvas や WebGL を使う画面、ブラウザ固有の挙動に依存した処理は、実際に流してみないと分かりません。公式が「エージェントが実際に使う API を中心にカバー」と書いているのは、裏を返せば網羅ではないという意味です。現実的な進め方は、既存のジョブを全部移すのではなく、負荷が高くて構造が単純なものから1本ずつ切り替えて比較することです。プレイグラウンドと browser=kitesurf パラメータの存在は、この段階的な検証をやりやすくしています。

ガバナンス面では、実行環境が Cloudflare のエッジになる点を確認する必要があります。ブラウザ自動化は認証情報を伴うことが多く、社内システムへログインする処理を外部基盤で動かすなら、どこに認証情報が渡り、セッションがどこで終端するかを整理しておくべきです。ステートレス設計は「状態が残らない」という意味で好都合ですが、それを情シスに説明できる形にしておく必要があります。

またベータであることは軽視できません。無料なのはベータ期間中の話で、正式版の価格は示されていません。本番の基幹処理をここに乗せるのは時期尚早で、現時点では「評価と比較データの蓄積」に投資するのが妥当な位置づけです。

副業・個人活用視点

個人でスクレイピングやブラウザ自動化を扱っている人にとって、ここは実務の単価に直結します。

ブラウザ自動化の受託でボトルネックになるのは、たいてい実行環境の維持費です。ヘッドレス Chromium を動かすには相応のメモリを積んだサーバーが要り、それを常時立てておくか、必要なときだけ起動する仕組みを自分で作るかの選択になります。前者はコストが読めるが無駄が多く、後者は起動の遅さと実装コストがつきまといます。Workers 上でステートレスに走る構成なら、この設計自体が要らなくなります。「月額いくらのサーバーを維持します」ではなく「実行した分だけ」で見積もれるようになると、小規模案件の採算が変わります。

ベータで無料という点も、個人には素直に有利です。自分の手持ちの自動化スクリプトを移して、実際に速度とコストがどう変わるかを試すコストがほぼゼロです。ここで得られる比較データ — 「同じ処理が Chromium ではこう、Kitesurf ではこう」という実測 — は、そのまま提案資料になります。この手の数字を持っている個人は多くないので、差別化材料として機能します。

一方で、案件に組み込むときの説明責任は増えます。クライアントに「Chromium ではないブラウザで動かします」と言う以上、動かない可能性とその場合の代替案をセットで提示しなければ、後で揉めます。現実的には、Chromium での実装をベースに持ちつつ、Kitesurf に切り替えられるかを検証して差分を報告する、という進め方が安全です。browser=kitesurf を付けるだけで切り替わる設計は、この二段構えを取りやすくしています。

学習投資としては、Puppeteer / Playwright の知識がそのまま活きる点が重要です。新しい API を覚え直す必要はなく、既存スキルの適用先が増えたという構図です。ブラウザ自動化をこれから学ぶなら、Playwright を軸に据えておけば実行基盤の選択肢が広がる、と考えておけば十分です。