Cloudflare Kitesurfとは？AIエージェント専用ブラウザの仕組み・Chromiumとの違い・使い方と料金【2026年8月最新】

Cloudflare Kitesurf（カイトサーフ）とは、Cloudflareが2026年8月6日に発表した、AIエージェントのために設計されたステートレスなヘッドレスブラウザです。 Chromiumをまったく使わずRust／WebAssemblyでゼロから作り直されており、Chromium比でCPU約3.1〜3.8倍・メモリ約4.7〜7.0倍の省リソースを実現しています（公式ベンチマーク値、2026年8月時点）。

現時点ではベータ提供で、Cloudflareの「Browser Run（旧Browser Rendering）」のブラウザバックエンドの1つとして、既存のAPIに browser=kitesurf を付けるだけで利用できます。ベータ期間中の利用は無料です。

ただし最も誤解されやすい点として、Kitesurfは「速いブラウザ」ではありません。 実時間（ページ処理が終わるまでの時間）はChromiumより1.7〜1.8倍遅く、勝っているのはあくまでCPUとメモリの消費量です。選ぶ基準は「速さ」ではなく「軽さ・同時実行しやすさ・スケーラビリティ」になります。

この記事でわかること:

Kitesurfの正体と、Cloudflareがゼロから作り直した理由
Chromiumを使わない内部構造（Rust／WASM／V8 isolate／4コンポーネント）
公式ベンチマークの正しい読み解き方（省リソースだが実時間は遅い）
Browser Run（旧Browser Rendering）での具体的な使い方3ルート＋プレイグラウンド
料金体系とコストの考え方、ベータ時点で未確定な部分
Kitesurfでできないこと、Chromiumとの使い分け判断表
セキュリティ設計と、まだ対策が公表されていない領域

対象読者は、AIエージェントやクローラーのバックエンドとしてクラウドブラウザの採用を検討している開発者・技術選定担当者、そしてCloudflareのAIエージェント関連プロダクトの全体像を把握したい方です。

用語の前提：「Browser Rendering」は現在「Browser Run」

Cloudflareは2026年4月15日に「Browser Rendering」を「Browser Run」へ改称しました。 公式ドキュメントのURLも developers.cloudflare.com/browser-run/ に移行済みです。

Kitesurfは単体サービスではなく、このBrowser Runの中で選べるブラウザバックエンドの1つとして提供されます。日本語の情報や過去記事では旧称の「Browser Rendering」表記が多く残っているため、情報を探すときは両方の名称で検索すると見つかりやすくなります。

旧称	現行名	変更日
Browser Rendering	Browser Run	2026年4月15日

Cloudflare Kitesurfとは何か（基本情報）

Cloudflare KitesurfのキービジュアルとBrowser Runのイメージ

出典: Cloudflare 公式ブログ「Kitesurf」

Kitesurfは、Cloudflare Workers上で動作する、AIエージェント専用に設計されたヘッドレスブラウザです。「ヘッドレス」とは画面表示（GUI）を持たず、プログラムから操作するブラウザを指します。

項目	内容（2026年8月時点）
名称	Kitesurf（カイトサーフ）
提供元	Cloudflare
発表日	2026年8月6日
位置づけ	Browser Run（旧Browser Rendering）のブラウザバックエンドの1つ
提供状況	ベータ。ベータ期間中は無料（アカウント単位の利用制限あり）
実装	Rust → WebAssembly（wasm-bindgen経由）、V8 isolate上で実行
Chromium依存	なし（Chromiumのコードを一切使わない独自実装）
開発期間	約12週間（公式言及）
主な用途	HTML抽出、スクリーンショット、PDF生成、DOM検査、JS実行
動作確認	公開プレイグラウンド `https://kitesurf.cloudflare.app/`（Chrome DevTools統合）
今後	オープンソース化を表明（時期は未定）

よくある誤解として「Chromiumの軽量版」と受け取られることがありますが、そうではありません。レンダリングエンジンからCSSパーサ、JavaScriptエンジンまで、既存のブラウザとは別系統のRust製コンポーネントで構成されています。

設計思想：人間のためのブラウザとの決別

Cloudflareの説明を要約すると、既存のブラウザは「人間が画面を見て操作する」ことに最適化されています。タブ、テーマ、拡張機能、ピクセル単位の正確な描画、60fpsのなめらかなスクロール——これらはすべて人間のための機能です。

一方でAIエージェントが気にするのは、トークン数、コンテキストウィンドウ、スケーラビリティ、処理性能、そしてコストです。エージェントは画面を「見る」わけではなく、構造化されたコンテンツを取り出して処理します。

Kitesurfは、この前提の違いから逆算して「エージェントが実際に使う機能」だけを残し、それ以外を最初から作らないという選択をしたブラウザです。人間の利用体験を良くする方向に進化しているAIブラウザとは、まったく逆方向の設計思想だと考えると理解しやすくなります。

なぜ「AIエージェント専用ブラウザ」が必要になったのか

背景には、AIの使われ方が「質問に答えるチャットボット」から「タスクを最後まで実行するエージェント」へ移行しつつある、という変化があります。

エージェントがWeb上でタスクを完遂するには、Webページを読み、フォームを操作し、結果を確認する必要があります。従来これは、サーバー上でChromiumをヘッドレス起動して実現されてきました。ただしChromiumは1インスタンスあたりのメモリ消費が大きく、数十〜数百のエージェントを同時に走らせようとするとインフラコストが急激に膨らむという構造的な問題を抱えています。

マルチエージェント構成でタスクを並列分割する設計が一般化するほど、この「1ブラウザあたりのコスト」がボトルネックになります。Kitesurfは、そこを1インスタンスあたり数十MiBまで削ることで、同じ予算でより多くのエージェントを動かせるようにするアプローチです。

また、KitesurfはCloudflareの単発プロダクトではなく、「AIエージェントがWebを使うことを前提としたインフラ整備」の一環として読むと位置づけが見えてきます。Cloudflareは同時に、サイト側がエージェントに対応できているかを診断するAgent Readiness Scoreや、クローラー課金の仕組みなども展開しています。「エージェントをブロックする側」と「エージェントにブラウザを与える側」の両方を握る構図になっている点は、技術選定の際に頭に入れておく価値があります。

Chromiumより軽量な仕組み：内部アーキテクチャ

KitesurfのPageScript isolate内部構成図（Bootstrap・Script runner・JSエンジン・DOM・SandboxOutbound）

出典: Cloudflare 公式ブログ「Kitesurf」

Kitesurfの省リソース性は、「Rustで書いた処理をWebAssembly化し、V8 isolate上で直接動かす」という構造から来ています。従来のようにコンテナやVM上でブラウザプロセスを丸ごと立ち上げるのではなく、Workersの実行単位そのものの中でブラウザ機能を動かします。

採用されている主要コンポーネント

役割	採用技術	補足
レンダリング	Blitz	モジュラーなRust製レンダリングエンジン
CSSパース	Stylo	Firefox由来のRust製CSSエンジン
JavaScript実行	Boa JS	Rust製ECMAScriptエンジン（`eval()` 対応用）
テキスト整形・フォント選択	Parley	テキストシェーピング

技術的なルーツとして、CloudflareはObscuraというRust製OSSヘッドレスエンジンにインスパイアされたことを明かしており、最初の実証実装はObscuraのWorkers移植だったとしています。

4つのコンポーネント構成

Kitesurfは以下の4つに機能を分割し、Workers標準のRPCで相互通信します。

コンポーネント	役割
Engine	公開窓口。CDP（Chrome DevTools Protocol）のWebSocket／HTTP RESTを処理し、セッション状態を管理
PageScript	Dynamic Workersを使い、ページごとに専用のisolateを起動。クリーンな `globalThis` とDOMを持ち、JS実行とDOM操作を担当
PageRenderer	計算済みのページオブジェクトからピクセル出力を生成し、JPEG／PNG／PDFを返す
SandboxOutbound	唯一のネットワーク出口。CORS強制・Cookie分離・レスポンスフィルタリングを一元適用

この分割で重要なのは、ページ1枚ごとにisolateが独立している点と、外部通信の出口が1か所に集約されている点です。この2つが、Kitesurfのセキュリティ設計そのものの土台になっています。

公式が掲げる4つの設計原則

Rust優先：エミュレーション層を挟まず、ネイティブRustをWASM化する
例外処理：すべての失敗はグレースフルに劣化させ、セッションをクラッシュさせない
分離：各ページロードを「信頼できないもの」として扱う
ステートレス：使い捨て・並列可能。復旧は「再構築」ではなく「リプレイ」で行う

とくに4つ目の「ステートレス」は、Kitesurfの強みと弱みの両方を生んでいます。使い捨てだからこそ大量に並列実行できる一方で、ログイン状態を長時間保持する用途には向かないという制約になります。

Web標準への準拠度

Kitesurfはゼロから作られたブラウザであるため、「そもそもWebページが正しく表示されるのか」が最大の懸念になります。公式はWeb Platform Tests（WPT、ブラウザのWeb標準準拠を検証する業界標準テスト群）の通過数を公開しています。

出典	記載内容
公式ブログ（2026年8月6日）	215,000件超のWPTにパス。毎週数百件ずつ追加中
公式ドキュメント（Kitesurfページ）	235,000件超のWPTサブテストにパス。DOM 97%／HTML 96%／Selection 99%／SVG 97%／Encoding 99%／CORS 95%／XHR 95%／URL 83%

数値が食い違って見えますが、これは「テスト」と「サブテスト」で母数の単位が異なる可能性が高いためです。どちらか一方を唯一の正解として扱わず、「公式ブログ時点で21.5万件超、ドキュメント上は23.5万サブテスト超、いずれも継続的に増加中」と理解しておくのが安全です。

実際のレンダリング実績として公式が挙げているのは、TodoMVC（全フレームワーク版）、Wikipedia、Hacker News、Cloudflare Blog、Cloudflareダッシュボードの一部です。一般的な情報系サイトは通るが、複雑なWebアプリは要検証というのが現時点の実力感になります。

Chromiumとの性能比較：省リソースだが実時間は遅い

Chrome DevToolsでKitesurfのメモリ使用量（Main・PageRenderer・Engine）を計測した画面

出典: Cloudflare 公式ブログ「Kitesurf」

Kitesurfを評価するうえで最も重要なのが、この比較表です。公式が公開しているベンチマーク（ウォームプール、14URLのコーパス、5回実行の中央値）は次のとおりです。

指標	Kitesurf	Chromium	差
CPU（スクリーンショット）	380 ms	1,173 ms	3.1倍少ない
CPU（HTML抽出）	229 ms	877 ms	3.8倍少ない
メモリ（スクリーンショット）	57.8 MiB	271.0 MiB	4.7倍少ない
メモリ（HTML抽出）	39.4 MiB	273.7 MiB	7.0倍少ない
実時間（スクリーンショット）	1,148 ms	637 ms	1.8倍遅い
実時間（HTML抽出）	820 ms	472 ms	1.7倍遅い

この表の読み解き方

Kitesurfが勝っているのは「消費するリソース量」、Chromiumが勝っているのは「終わるまでの時間」です。

実時間でChromiumが優位なのは、ChromiumのJITコンパイルとラスタライズ最適化が長年積み上げられてきた結果です。Kitesurfは「V8 isolate上でRust製WASMを動かし、その中でさらにBoa JSがJavaScriptを解釈する」という多段構成のため、単発のレイテンシでは不利になります。

したがって導入判断は、次のように整理できます。

1リクエストのレスポンス速度が最優先（ユーザー操作に同期して結果を返す用途）→ Chromiumが有利
同時に大量のページを処理し、インフラコストを抑えたい（バッチクロール、エージェントの並列実行）→ Kitesurfが有利

「Kitesurf＝高速」という理解で導入すると、期待と実測が食い違います。選ぶ理由は速さではなく、軽さと同時実行のしやすさです。

Browser Run（旧Browser Rendering）での使い方

CDPクライアントからKitesurfのEngine・PageScript・PageRendererへ処理が流れるシーケンス図

出典: Cloudflare 公式ブログ「Kitesurf」

既にBrowser Runを使っている場合、Kitesurfへの切り替えはリクエストに browser=kitesurf を追加するだけです。 これが導入面での最大の利点で、既存コードの大幅な書き換えは不要です。

利用ルートは、公式が示すもので大きく4つあります。

1. Quick Actions（REST API）

ワンショットでスクリーンショットやHTML取得を行う最も簡単な方法です。

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"}'

screenshot の部分を差し替えることで、HTML取得やPDF生成など他のQuick Actionも同様に呼び出せます。

2. CDPエンドポイント（Puppeteer / Playwright / chrome-remote-interface）

既存の自動操作コードを流用したい場合は、CDP（Chrome DevTools Protocol）のWebSocketエンドポイントに接続します。

wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf

ここで注意すべきは、KitesurfのCDPプロトコルカバレッジは現時点で部分的という点です。Chromium前提で書かれたPuppeteer／Playwrightのスクリプトが、すべてそのまま動く保証はありません。カバレッジ拡大は公式ロードマップに入っていますが、既存スクリプトの移行時は個別の動作検証が必要です。

3. MCPクライアント経由

chrome-devtools-mcp などのCDPを話すMCPクライアントに、KitesurfのWebSocketエンドポイントとAuthorizationヘッダを設定することで、AIエージェントから直接ブラウザ操作をさせられます。公式はOpenCodeでの設定例に言及しています。

MCP（Model Context Protocol）自体の仕組みや、どのクライアントが対応しているかはMCPとは？仕組み・できること・対応ツールで整理しています。Claude Codeから使う場合の設定手順はClaude CodeのMCP連携ガイドも参考になります。

4. 公開プレイグラウンド（コード不要）

https://kitesurf.cloudflare.app/ で、コードを書かずにKitesurfの挙動を確認できます。Chrome DevToolsが統合されており、DOMツリーやネットワークの様子をそのまま見られます。

公式もこのプレイグラウンドを、「本番導入前に、対象サイトが正しくレンダリングされるかを確かめる場所」として推奨しています。ゼロから作られたブラウザである以上、自分が処理したいサイトが実際に描画できるかを事前に確認するステップは省略しない方が安全です。

料金とコストの考え方

Kitesurf自体はベータ期間中無料です。ただし土台となるBrowser Runには従量課金があり、ベータ終了後の課金体系は現時点で未発表です。

Kitesurfの料金（2026年8月時点）

項目	内容
ベータ期間中	無料
制限	アカウント単位の利用制限あり（具体的な数値は公式未公表）
一般提供（GA）後	未発表。Browser Runの料金ページにKitesurf固有の記載は現時点でなし

「無料だから将来もタダで使える」と前提を置いた設計は避けるべきです。少なくとも、土台であるBrowser Runの料金体系に沿った課金になる可能性は考慮しておくのが現実的です。

土台となるBrowser Runの料金

プラン	ブラウザ利用時間	同時実行ブラウザ数
Workers Free	1日10分まで	3ブラウザ
Workers Paid	月10時間まで無料、超過分は $0.09／ブラウザ時間	10ブラウザ（月平均）まで無料、超過分は $2.00／追加1ブラウザ

課金の考え方には、見落としやすい独特のルールがあります。

Quick Actions：ブラウザ利用時間のみが課金対象
Browser Sessions（Puppeteer／Playwright／CDP）：ブラウザ時間＋同時実行ブラウザ数の両方が課金対象
ブラウザ時間の算定：日次で秒単位に積み上げ、請求サイクル末に月次合計。時間単位に四捨五入（1,800秒以上は切り上げ）
同時実行ブラウザ数の算定：「日次のピーク値」を毎日記録し、それを1か月分平均した値で課金
ブラウザ時間はBrowser Runのすべての利用方法で共有される
タイムアウトエラーで失敗したAPIコールは課金されない

とくに同時実行ブラウザ数が「日次ピークの月平均」である点は重要です。月に1日だけ大量並列を走らせても、平均で均されるため請求インパクトが小さい一方、毎日一定のピークを出す常時稼働型のワークロードでは効いてきます。

主な利用上限（2026年8月時点）

項目	Free	Paid
1日のブラウザ時間	10分	無制限（従量課金）
アカウント同時ブラウザ数	3	120（増枠申請可）
新規ブラウザ生成レート	20秒に1回	1秒に1回
ブラウザタイムアウト	60秒（最大10分まで延長可）	同左
リクエストレート（Quick Actions）	10秒に1回	秒間10回
`/crawl` ジョブ	1日5件	—
1クロールの最大ページ数	100ページ	—

セッションに固定の最大寿命はなく、アクティビティが続く限り継続します。無操作時は既定1分で終了し、keep_alive オプションで最大10分まで延長できます。

実時間の遅さがコストに与える影響（注意点）

ここは公式が言及していない、実務上の論点です。

Browser Runの課金軸のひとつはブラウザ「時間」です。一方でKitesurfは実時間がChromium比で1.7〜1.8倍長い。つまり、GA後にKitesurfが同じ従量課金体系に乗った場合、同じページ数を処理するとブラウザ時間の請求はむしろ増える可能性があると考えられます。

例えばHTML抽出を単純積算すると、1万ページの処理にかかる時間はChromiumが約4,720秒、Kitesurfが約8,200秒です（公式ベンチマークの中央値をそのまま掛けた概算であり、実際のセッション時間とは一致しません）。

とはいえ、Kitesurfの省リソース性が無意味になるわけではありません。効いてくるのは次のような場面です。

アカウントの同時実行ブラウザ数の上限内で、より多くの処理を安定して回せる
将来オープンソース化された際、自社インフラでセルフホストするときのサーバーコストが桁違いに小さくなる
Cloudflare側の提供コストが下がることで、GA後の単価が抑えられる可能性がある（あくまで推測）

現時点では「ベータ無料のうちに検証し、GA時の課金体系が出てから本番判断する」のが最も損の少ない進め方です。

Kitesurfでできないこと（2026年8月時点）

Kitesurfはまだベータであり、公式が明示している未対応項目があります。 ここを把握せずに本番投入すると確実に詰まります。

できないこと	影響する用途
動画再生	動画コンテンツを含むページの処理
WebGLのレンダリング	3D表示・地図・ゲーム系サイト
TLSフィンガープリントによるボットチャレンジの突破	本格的なボット対策が入ったサイトの取得
永続的な認証セッションの維持	ログイン後の画面を長時間操作する処理
ピクセルパーフェクトな描画	ビジュアルリグレッションテスト、印刷品質のPDF
実時間がChromium比1.7〜1.8倍遅い	レイテンシ重視の同期処理
CDPプロトコルカバレッジが部分的	既存Puppeteer／Playwrightスクリプトの完全な流用

海外の技術系フォーラムでは、このうち「認証セッションを保持できない点」が最大の実用上の弱点として指摘されています。「本物のログインの内側や、本格的なボット対策の壁の向こうには、依然としてChromiumが必要」という評価です。

なお、レンダリング忠実度の向上とCDPカバレッジの拡大は、いずれも公式ロードマップに明記されています。現時点の制約が恒久的なものとは限りません。

KitesurfとChromiumの使い分け判断表

Browser Runでは、KitesurfとChromiumバックエンドを用途ごとに使い分けられます。パラメータ1つで切り替えられるため、「全部どちらかに寄せる」のではなく、処理の性質ごとに振り分けるのが現実的な運用です。

やりたいこと	推奨バックエンド	理由
大量ページのHTML抽出・要約	Kitesurf	メモリ最大7.0倍削減。同時実行数を稼げる
サムネイル・OGP画像の大量生成	Kitesurf	CPU3.1倍削減。厳密な見た目の忠実性が不要
検索エンジン的なバッチクロール	Kitesurf	リソース効率が総コストを左右する
エージェントに大量のページを読ませる	Kitesurf	並列数を確保しやすい
ログイン後の画面を継続操作	Chromium	永続的な認証セッション非対応
ボット対策の強いサイトへのアクセス	Chromium	TLSフィンガープリント非対応
動画・WebGLを含むページ	Chromium	いずれも未対応
ビジュアルリグレッションテスト	Chromium	ピクセルパーフェクトな描画ではない
レイテンシ最優先の単発処理	Chromium	実時間が1.7〜1.8倍遅い
既存Puppeteerスクリプトの完全流用	Chromium	CDPカバレッジがまだ部分的

判断の順序としては、次の3ステップで考えると迷いにくくなります。

その処理はログイン内側／ボット対策の内側か？ → YESならChromium一択
見た目の正確さや動画・WebGLが必要か？ → YESならChromium
上記に当てはまらず、処理件数が多いか？ → YESならKitesurfを検証する価値が高い

セキュリティ設計と、まだ埋まっていない部分

Kitesurfの外部通信経路図：信頼できないページからWorkers isolate境界とネットワークプロキシを経てインターネットへ出る構造

出典: Cloudflare 公式ブログ「Kitesurf」

Kitesurfの分離設計は明確な強みですが、エージェントブラウザ特有のリスクについては「脅威モデルに挙げているが、具体的な防御策は未公表」という状態です。ここは正確に線引きして理解しておく必要があります。

良く設計されている部分

ページ単位の分離：各ページを独立したisolateで実行し、あるページの情報が別ページに漏れない構造。エージェントが1つのページで悪意あるコンテンツに触れても、他のページを汚染できない
ゼロトラスト前提：各ページロードを「信頼できないもの」として扱う
ネットワーク出口の集約：SandboxOutboundが唯一の出口となり、CORS強制・Cookie分離・レスポンスフィルタリングを一元管理
ステートレス設計：セッション間に残留状態を持たない

複数のエージェントタスクを同一アカウントで並列に走らせる際、タスク間のデータ漏洩リスクを構造で抑え込んでいるのは、既存のヘッドレスChromium運用と比べて明確な進歩です。

まだ埋まっていない部分

Cloudflareはプロンプトインジェクションとツール安全性をKitesurfの脅威モデルの最優先事項と位置づけていますが、発表時点で具体的な防御メカニズムは説明されていません。

エージェントブラウザは構造上、以下のリスクを負います。

Webページ内に仕込まれた隠しプロンプトによるインジェクション
モデルの挙動を操作しようとする悪意あるJavaScript
エージェントのタスク間で起こりうるクロスサイトのデータ漏洩

とくにKitesurfは取得した生テキストをそのままモデルへ渡す設計であるため、「ページの中に書かれた指示をモデルが指示だと解釈してしまう」典型的なリスクは残ります。「Cloudflare製だから安全」という判断は成り立ちません。 取得コンテンツをモデルに渡す前段でのサニタイズや、エージェントに与える権限の最小化といった対策は、利用側で設計する必要があります。この領域の全体像はAIエージェントのセキュリティ対策で整理しています。

運用上の注意：常にボットとして識別される

Browser Run共通の仕様として、Browser Runから発したリクエストは、Cloudflareによって常にボットトラフィックとして識別されます。 cf-biso-request-id / cf-biso-devtools ヘッダが自動付与されるため、アクセス先のサーバー側でも識別可能です。

自社サイトのボット対策に自分で引っかかるケースを避けたい場合、Enterpriseプランではbot detection IDを使ったWAFルールで許可リスト化できます。認証が必要なページをレンダリングする手段としては、HTTP Basic認証／Cookieベース／Authorizationヘッダ（Bearerトークン）の3つが公式に案内されています。

他のエージェント向けクラウドブラウザとの位置づけ

Kitesurfが参入するのは、既にプレイヤーが存在する市場です。以下は各社の位置づけの整理です。

サービス	位置づけ	料金感
Cloudflare Kitesurf	Workers上・Chromium非依存・低リソース。エージェント向けに絞った機能セット	ベータ期間中無料（土台のBrowser Runは$0.09／ブラウザ時間〜）
Browserbase	運用成熟度・可観測性・デバッグ機能を重視した定番	無料プランあり／Developer $20/月／Startup $99/月
Steel.dev	オープンソース志向のエージェント特化ブラウザAPI	セッション単位課金
Hyperbrowser	大量実行（ボリューム）重視	公開情報を要確認
Browser Use	OSSフレームワーク（インフラではなく操作レイヤー）	無料（OSS）

※Cloudflare以外の料金は第三者の比較情報を含む参考値です。実際の採用検討時は各社公式で再確認してください。

Kitesurfの差別化点はリソース効率とCloudflareネットワークへの統合であり、逆にデバッグ機能・セッション管理・実績の厚みでは既存プレイヤーが先行しています。「既にCloudflare Workersでシステムを組んでいるか」が、実質的な選択の分かれ目になりやすいところです。

なお、ここで扱っているのはすべてサーバー側で動くエージェント用ブラウザです。人間が画面を見ながら使うPerplexity CometのようなAIブラウザとは、そもそも用途が異なります。

Kitesurfの導入が向くケース・見送った方がよいケース

導入を検討する価値が高いケース

既にCloudflare WorkersやBrowser Runを使っている：browser=kitesurf を足すだけで検証でき、移行コストがほぼゼロ
1日数千〜数万ページ規模のHTML抽出・要約を回している：リソース効率が総コストに直結する
多数のエージェントを並列実行する設計：1ブラウザあたりのフットプリントが小さいほど並列度を上げやすい
スクリーンショットやOGP画像を大量生成している：厳密な見た目の忠実性が不要なら効果が出やすい
将来的にセルフホストしたい：オープンソース化が表明されており、リソース効率の恩恵が最大化する
新しい技術を早期に検証したい：ベータ無料の今が検証コストの最も低いタイミング

現時点では見送りを推奨するケース

ログイン後の操作が処理の中心：永続的な認証セッションに未対応
強いボット対策のあるサイトを対象にしている：TLSフィンガープリントによるチャレンジを突破できない
動画・WebGLを含むページを扱う：いずれも未対応
ビジュアルリグレッションテストや印刷品質のPDFが目的：ピクセルパーフェクトな描画ではない
1リクエストのレイテンシがSLAに直結する：実時間はChromiumより遅い
既存のPuppeteer／Playwright資産をそのまま動かしたい：CDPカバレッジがまだ部分的
本番のSLAを今すぐ確定させたい：ベータであり、GA後の料金・制限が未発表

判断としてはシンプルで、「ベータのうちに自社の対象サイトで検証を回し、本番切り替えはGA後の条件を見てから決める」という二段構えが最も合理的です。

今後の展望

公式が示しているロードマップは以下のとおりです。

CDPプロトコルのカバレッジ拡大（既存ツールとの互換性向上）
スクリーンショット／PDFのレンダリング忠実度向上
WPTテストの継続拡充（プロダクション品質を目指す）
CPU・メモリ・実時間の継続的な最適化
オープンソース化（顧客が自アカウントでセルフホストできるようにする方針。時期は未定）

とくにオープンソース化が実現すれば、「AIエージェント向けブラウザ」の実装そのものが共有資産になります。エージェント実行基盤をどう組むかという議論はエージェンティックエンジニアリングやOpenAI Agents SDKの新ハーネスといった周辺領域とも接続しており、Kitesurfはその「Webアクセス層」を担う候補として位置づけられます。

ただし時期は公式にも "hopefully soon" としか示されておらず、具体的なスケジュールは決まっていません。ロードマップ前提の設計判断は避けるのが無難です。

よくある質問（FAQ）

Q. Kitesurfという名前は何を指していますか？
Cloudflareの製品名で、Browser Run上のブラウザバックエンドを識別する名称です。API上も browser=kitesurf という値で指定します。単体で契約する独立サービスではありません。

Q. Workers Freeプランでも使えますか？
公式は「ベータ期間中は無料、アカウント単位の制限あり」とのみ記載しており、Workers FreeプランでKitesurfが利用できるかは明示されていません。制限値の具体的な数値も未公表です。まずは公開プレイグラウンド（kitesurf.cloudflare.app）で挙動を確認するのが確実です。

Q. 日本語サイトのレンダリングは問題ありませんか？
公式は日本語に特化した言及をしていません。テキスト整形にParley、文字エンコーディングのWPT準拠率は99%と示されていますが、日本語の縦書きやWebフォント、複雑なレイアウトについては個別検証が必要です。プレイグラウンドで対象サイトを実際に開いて確認してください。

Q. 既存のPuppeteerコードはそのまま動きますか？
保証されません。KitesurfのCDPプロトコルカバレッジは現時点で部分的で、拡大はロードマップ段階です。移行時は使用しているCDPコマンド単位での動作確認が必要になります。

Q. 「Browser Rendering」という名前はもう使われないのですか？
現行の正式名称は「Browser Run」です（2026年4月15日改称）。旧称のドキュメントURLやサードパーティ記事は残っているため、情報を探す際は両方の名称で検索すると見つかりやすくなります。

Q. 自社サーバーで動かせますか？
現時点ではできません。Cloudflareはオープンソース化とセルフホスト対応の方針を表明していますが、時期は未定です。

Q. Chromiumバックエンドは廃止されますか？
そのような発表はありません。公式ドキュメント自体が「動画・WebGL・ボットチャレンジ・長時間の認証セッションが必要な場合はChromiumベースのBrowser Runを使うように」と案内しており、当面は併存する前提です。

まとめ

Cloudflare Kitesurfは、AIエージェントが本当に使う機能だけに絞って作り直された、Chromium非依存のヘッドレスブラウザです。2026年8月6日にベータ提供が始まり、Browser Run（旧Browser Rendering）に browser=kitesurf を追加するだけで試せます。

判断のポイントを3つに整理すると次のとおりです。

選ぶ理由は「速さ」ではなく「軽さ」 — CPU3.1〜3.8倍・メモリ4.7〜7.0倍の削減が強みで、実時間は1.7〜1.8倍遅い。大量並列処理でこそ効く
ログイン内側・ボット対策・動画/WebGL・見た目の忠実性が必要ならChromium — 用途ごとに使い分ける前提で設計する
ベータのうちに検証、本番判断はGA後 — 料金・制限・CDPカバレッジがいずれも確定していない

Cloudflareが「エージェントをブロックする側」と「エージェントにブラウザを与える側」の両方を持ち始めたことは、Web全体の構造変化としても見逃せない動きです。サイト運営側の視点でこの流れを追うならCloudflare Agent Readiness Scoreを、エージェント向けブラウザ全体の選択肢を比較したい場合はAIブラウザおすすめ比較を合わせて確認してください。

※Kitesurfはベータ提供中で、仕様・料金・制限が変更される可能性が高い段階です。導入前にCloudflare公式ドキュメントで最新情報を確認してください。