--- title: "Cloudflare Kitesurfとは：Wasmブラウザの実測値と切替手順・使えない場面を解説" url: "https://www.issoh.co.jp/tech/details/16913/" published: 2026-08-24 updated: 2026-10-10 categories: ["ブラウザ"] publisher: "株式会社一創" --- # Cloudflare Kitesurfとは：Wasmブラウザの実測値と切替手順・使えない場面を解説 Cloudflareは2026年8月6日、AIエージェント向けのヘッドレスブラウザ「Kitesurf」をBrowser Runのベータ機能として公開しました。Chromiumの派生ではなくRustで書き起こしたブラウザエンジンをWebAssemblyへコンパイルし、Workersのアイソレート上で直接動かすという構成です。読みどころは速さではありません。CPUとメモリは3〜7分の1に落ちるのに、1ページあたりの実時間はChromiumより1.7〜1.8倍かかるという、方向の違う二つの数字をどう扱うかが判断の芯になります。この記事では、エンジンの部品構成、公表された実測値の読み方、既存のPuppeteerやPlaywrightのコードからの切り替え手順、そして未対応4項目から逆算した採用と見送りの線引きを整理します。実行基盤そのものの仕組みは[Cloudflare Workersのエッジ実行モデルを解説した記事](https://www.issoh.co.jp/tech/details/6539/)で扱っているため、ここで扱うのはその上で動くブラウザエンジンだけです。 ## まとめ｜Kitesurfが下げるコストと、引き換えに諦める機能の範囲 Kitesurfは、人間が使うブラウザから機能を削った軽量版ではなく、閲覧者が言語モデルであるという前提で作り直したエンジンです。タブ、拡張機能、テーマ、ピクセル単位の描画忠実度、滑らかなスクロールはいずれも実装されていません。残したのはページ取得、スクリーンショット、HTMLとDOMの抽出という、エージェントが実際に叩く経路だけです。 公表された実測は非対称でした。14件のURLを対象にした計測（5回の中央値）で、スクリーンショット時のCPU時間はKitesurfが380ミリ秒に対しChromiumが1,173ミリ秒、HTML抽出では229ミリ秒に対し877ミリ秒。メモリはスクリーンショットで57.8MiB対271.0MiB、HTML抽出では39.4MiB対273.7MiBまで開きます。ところが実時間はスクリーンショットで1,148ミリ秒対637ミリ秒、HTML抽出で820ミリ秒対472ミリ秒と、Kitesurf側が遅い。請求に効くのはCPU時間とメモリなので、1リクエストの応答が遅くなることを許容できるバッチ的な処理ほど得が出ます。 切り替えの敷居は低く、Browser RunのCDPエンドポイントやQuick Actionのクエリ文字列に`browser=kitesurf`を足すだけで、Puppeteer・Playwright・chrome-remote-interface・MCPクライアントがそのまま接続できます。判断が要るのは切り替え方ではなく適用範囲のほうです。動画再生、WebGLの描画、TLSフィンガープリントを伴うボットチャレンジの通過、永続的な認証セッションの4つは2026年8月時点で未対応と明記されており、この4つに触れる処理はChromium側へ残す前提で設計します。 ## Kitesurfの構造｜Rust部品の組み合わせをWasm化してアイソレートで動かす まず押さえるべきは、Kitesurfが既存エンジンの移植ではないという点です。Cloudflareは実績のあるRust製部品を組み合わせ、それをWebAssemblyへ落としてWorkersのアイソレート上で動かす道を選びました。 ### 部品構成｜Blitz・Stylo・Parley・Boaがそれぞれ担う層 レンダリングの土台にはBlitzというモジュール型のレンダリングエンジンを据え、HTMLの解析と、`blitz-paint`によるラスタライズを任せています。CSSの解析はFirefoxで使われている高性能なCSSエンジンStyloが担当し、文字の字形選択・整形・行分割はParleyが引き受けます。JavaScriptの実行はアイソレートのV8が主役ですが、Workers上では使えない`eval()`相当の処理があるため、Rust製のECMAScriptエンジンであるBoaを併用して穴を埋める構成です。 この分業は実装者にとって読みやすい情報を含みます。CSSとテキスト整形は成熟したRust実装をそのまま使っているため、レイアウト計算の精度は初物のわりに素性が良い。一方でラスタライズ、つまり最終的な画素の生成は自前のモジュールで、Cloudflare自身がスクリーンショットとPDFの描画忠実度を改善項目としてロードマップへ挙げています。文字を読み取る用途と、見た目を人に見せる用途では、現時点の成熟度が違うという読み方になります。 ### Emscriptenを避けた判断｜エミュレーション層を挟まないWasm化 C/C++のコード資産をWebAssemblyへ持ち込む定番はEmscriptenですが、Cloudflareはこれを採りませんでした。理由は明快で、Emscriptenが持ち込む多層のモック依存とC/C++エミュレーション層が、生成バイナリを肥大化させ実行を鈍らせるためです。Kitesurfが減らそうとしているオーバーヘッドを、変換の過程で再び足してしまう。そこで可能な限りネイティブなRustで書き、`wasm-bindgen`で直接WebAssemblyへコンパイルする方針が採られました。 この設計判断は自社でWasmを扱うときの参照点にもなります。既存資産の移植と、目的に合わせた書き起こしのどちらを選ぶかは、起動時間とメモリ上限のどちらが制約になっているかで決まる。Wasm化そのものの手順は[RustのコードをWebAssemblyへ変換する実装手順の記事](https://www.issoh.co.jp/tech/details/15290/)で扱っています。 ### アイソレート上で動く意味｜起動単位がコンテナからV8へ変わる 従来のヘッドレスブラウザは、Chromiumのプロセスをコンテナや仮想マシンの中で立ち上げ、そこへCDPで接続する形でした。Kitesurfはブラウザ自体がWorkersのコードとして動くため、起動単位がV8のアイソレートになります。1つのアイソレートが数十MiB規模で済むという先の実測値は、この構造の帰結です。 運用面では、同時に走らせられるセッション数の頭打ちが変わります。メモリ1台分で抱えられる並列数が数倍になるため、深夜に数万ページを回すような一括処理では、実時間が1.8倍かかっても総所要時間は並列度で取り返せる。分散実行の前提そのものは[エッジコンピューティングの仕組みを整理した記事](https://www.issoh.co.jp/column/details/15366/)を参照してください。 ## 実測値の読み方｜遅くなるのに安くなるという構造を判断軸ごとに分解する 3〜7分の1という数字だけを見て導入を決めると、応答時間の悪化で足をすくわれます。公表値を項目別に分けて、どちらの軸で得をするのかを先に決めるべきです。 ### 数値の並べ方｜比較条件をそろえた4指標をそのまま一覧表にする | 指標 | Kitesurf | Chromium | 比 | | ---------------- | -------- | -------- | ------ | | CPU時間（スクリーンショット） | 380ms | 1,173ms | 3.1分の1 | | CPU時間（HTML抽出） | 229ms | 877ms | 3.8分の1 | | メモリ（スクリーンショット） | 57.8MiB | 271.0MiB | 4.7分の1 | | メモリ（HTML抽出） | 39.4MiB | 273.7MiB | 7.0分の1 | | 実時間（スクリーンショット） | 1,148ms | 637ms | 1.8倍 | | 実時間（HTML抽出） | 820ms | 472ms | 1.7倍 | 計測は14件のURLからなるコーパスに対する5回の中央値です。母数が小さいため、自社が実際に巡回する対象で追試したうえで数字を確定させてください。 ### なぜ遅くなるのか｜起動時に温まっていないラスタライズ経路を追う 実時間で負ける主因は、描画経路が冷えた状態から動くことにあります。Chromiumは長年かけて画素生成の経路を詰めており、GPUや専用の効率化された実装に支えられています。Kitesurfのラスタライズは書き起こしたばかりで、同じ絵を作るのに素直な計算を回す。CPU時間が短いのに実時間が長いという一見矛盾した並びは、待ち時間の性質が違うことを示しています。 この差はHTML抽出のほうが小さく出ます。画素を作らない処理では、そもそもラスタライズが走らないためです。抽出用途を主に据えるエージェントほど、実時間の悪化を小さく抑えられます。 ### どちらの軸で判断するか｜請求額に効くCPUとメモリの消費量を見る Browser Runの課金はブラウザが動いた時間に紐づき、その裏側でCPU時間とメモリが効いてきます。同時実行数の上限もメモリで決まる。つまり請求書と処理能力を動かすのは3〜7分の1のほうで、1.7〜1.8倍のほうは体感の応答時間に効きます。Workers側の課金体系の前提は[Cloudflare Workersの料金と無料枠を整理した記事](https://www.issoh.co.jp/tech/details/6760/)で確認できます。 判断の線はこう引けます。ユーザーの操作を待たせる同期処理なら実時間が支配的なのでChromiumを残す。キューに積んで裏で回すクロールや定期監視、エージェントの調査タスクなら、同時実行数を上げられるKitesurfが有利になります。 ## 切り替え手順｜browser=kitesurfで済む範囲と済まない範囲 移行コストの見積もりは二段構えです。接続の切り替えはクエリ文字列1つで終わりますが、コード側が前提にしていた挙動まで自動では移りません。 ### 接続の切り替え｜CDPエンドポイントとQuick Actionへの付与 PuppeteerやPlaywrightからつなぐ場合は、WebSocketのエンドポイントにパラメータを足します。 ``` wss://api.cloudflare.com/client/v4/accounts//browser-run/devtools/browser?browser=kitesurf ``` REST形式のQuick Actionでも同じ考え方です。 ``` curl -X POST 'https://api.cloudflare.com/client/v4/accounts//browser-run/screenshot?browser=kitesurf' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json' \ -d '{"url": "https://example.com"}' \ --output "screenshot.png" ``` chrome-remote-interfaceのような低レベルのCDPクライアント、およびCDPを話すMCPクライアントも同じ経路で接続します。エージェント側の道具接続をMCPで組んでいる場合の設計は[MCPで外部ツールをつなぐ実装手順の記事](https://www.issoh.co.jp/tech/details/15365/)にまとめました。 ### 切り替えでは移らないもの｜CDPの実装範囲とセレクタの前提を確認する KitesurfのChrome DevTools Protocol対応は拡大の途中で、Cloudflare自身が対応範囲の拡張をロードマップへ載せています。Chromium前提で書いたコードのうち、性能計測系やネットワーク傍受系の細かいドメインを叩いている箇所は、動作確認の対象に入れてください。 もう一つの落とし穴が描画依存のセレクタです。要素の座標を取ってクリック位置を決める実装や、スクリーンショットの画素比較でアサーションを書いているテストは、描画忠実度の差でずれます。DOM上のセレクタとテキスト一致で書き直しておけば、この差は吸収できます。クライアント側ライブラリの版差については[Playwright 1.56の新機能を解説した記事](https://www.issoh.co.jp/tech/details/9257/)を参照してください。 ### 検証の置き方｜同一URLで二系統を並走させて出力差分を確認する 移行判断のいちばん確実な進め方は、本番のクロール対象からURLを50件ほど抜き、ChromiumとKitesurfへ同じ入力を流して出力を突き合わせる方式です。抽出したテキストの文字数、取得できたリンク数、失敗率の3つを並べれば、自社の対象サイト群における実用度が数値で出ます。ページによってはJavaScriptの実行結果が揃わない場合があり、その差はコーパスの性質に依存するため、公表値ではなく自前の数字で判断すべき部分になります。 ## 使えない場面｜未対応4項目から逆算する採用条件と業務上の見送り条件 ここが判断の核心です。Cloudflareは「まだKitesurfが適さない条件」を明示しており、その裏返しが適用範囲になります。 ### 動画とWebGL｜画素と時間軸を扱う処理が対象外になる理由を知る 動画の再生とWebGLの描画は未対応です。動画配信サイトの再生挙動を確認する監視、Three.jsやWebGLで描いた地図・3D表示のスクリーンショット取得、Canvas上のグラフを画像として残す用途は、Chromium側に残してください。テキストと静的なレイアウトを読む処理に限れば影響はありません。 ### ボットチャレンジ｜TLSフィンガープリントの交渉ができない制約を知る ボット判定のチャレンジをTLSフィンガープリントの交渉込みで通過する能力は、現時点のKitesurfにありません。保護されたサイトを巡回する構成では、そこで止まります。受ける側のサイトがAIエージェントをどう判定し、署名付きのエージェントだけを通すルールの書き方は[Cloudflare Adaptive Intelligenceとボットスコアのルール設定例](https://www.issoh.co.jp/tech/details/18231/)で扱っています。そもそも巡回対象の規約と法的な整理が先に必要な領域なので、手法選定と併せて[スクレイピングの手法と法務判断を整理した記事](https://www.issoh.co.jp/tech/details/13414/)で前提を確認しておいてください。 ### 永続認証セッション｜ステートレスであることを前提にした設計思想 ログイン状態を保ったまま長時間動かす使い方も対象外です。Kitesurfはタスクの実行中だけ存在するステートレスな設計で、Cloudflare自身が状態を持ち越す用途にはChromiumを使うよう案内しています。会員制サイトの管理画面を操作し続けるRPA的な処理は、そのままChromium側の仕事になります。 ### 線引き｜業務で採用してよい条件と、運用上見送るべき条件を整理する 採用してよいのは、次の3条件がそろう場合です。第一に、取り出したいものがテキストかDOMか粗いスクリーンショットであること。第二に、処理がキュー経由の非同期で、1件あたり数百ミリ秒の増加を許容できること。第三に、巡回対象がボット保護の内側になく、ログイン状態の維持を必要としないこと。この3つを満たすなら、同時実行数を数倍に引き上げられる利得がそのまま効きます。 見送るべきなのは、逆の性質を持つ処理です。ユーザーの画面遷移に同期して実行結果を返す用途、帳票PDFのように画素の正確さが検収条件になる出力、認証を保持した業務システムの自動操作、動画やWebGLを含むページの検証。これらはChromiumで動かし続けるほうが、移行の手間と障害対応の総量が小さくなります。 ## ベータ前提の運用設計｜無料の意味と二系統併存を継続する組み方 提供条件そのものが設計の入力になります。ベータで無料という状態は、費用の見通しと安定性の両方に前提を置きます。 ### 提供条件｜ベータ中は無料、アカウント単位の上限つきで試用する Kitesurfはベータ期間中は無料で使え、アカウントごとの上限の内側で動きます。上限の具体値は公開されていないため、試験導入の段階で自社の実行量が枠に収まるかを実測しておく必要があります。ベータを抜けた後の課金がどうなるかも未確定なので、コスト削減効果を稟議の数字に入れるなら、Browser Run全体の課金軸で概算し、Kitesurf無料分は上振れ要素として扱うのが安全です。 ### 二系統フォールバック｜エンジン選択を設定値としてコードの外へ出す 実装上の推奨はひとつです。接続先のエンジンをコードへ直書きせず、環境変数か設定テーブルの値で切り替えられるようにしておく。`browser=kitesurf`の有無だけの違いなので、エンドポイント文字列を組み立てる関数を1か所に集約すれば済みます。 そのうえで、URLパターンごとにエンジンを割り当てる表を持たせます。ボット保護のあるドメイン、動画を含むドメイン、認証が要るドメインはChromium、それ以外はKitesurf。失敗時に自動でChromiumへ落とすリトライを入れておけば、ベータ期間中の不安定さも吸収できます。エージェント側の骨組みをどう組むかは[AIエージェントフレームワークの比較と選定基準の記事](https://www.issoh.co.jp/tech/details/15367/)が参考になります。 ### 移行判断を外部と進める場合｜検証コーパスの設計段階から相談する 自社の巡回対象がKitesurfで賄えるかどうかは、対象サイト群の性質次第で結論が変わります。検証コーパスの作り方、二系統の振り分け基準、エージェント側の再試行設計までを含めて詰めたい場合は、[AIエージェント開発の相談窓口](https://www.issoh.co.jp/service/ai/agent/)で個別の条件を確認してください。エージェント本体の設計と、ブラウザ層の選定はセットで決めたほうが手戻りが出ません。 ## よくある質問 Kitesurfの導入検討でよく挙がる論点へ、実装の目線で答えます。 ### KitesurfはChromiumより速いのですか？ 1ページあたりの実時間では遅くなります。公表値ではスクリーンショットで1.8倍、HTML抽出で1.7倍の時間がかかりました。速さで選ぶ製品ではなく、CPU時間とメモリを3〜7分の1に抑えて同時実行数を増やすための製品だと理解してください。総所要時間は並列度で取り返す形になります。 ### 既存のPuppeteerのコードはそのまま動きますか？ 接続先のエンドポイントに`browser=kitesurf`を足すだけで接続自体は通ります。ただしCDPの対応範囲は拡大の途中で、描画の忠実度もChromiumとは差があります。座標指定のクリックや画素比較のアサーションを含むコードは、DOMのセレクタとテキスト一致へ書き換えたうえで動作確認してください。 ### ログインが必要なサイトを巡回できますか？ 短時間で完結する範囲なら扱えますが、状態を保持し続ける長時間の認証セッションは未対応です。Cloudflareもそうした用途にはChromiumを使うよう案内しています。会員制サイトの継続操作は、当面Chromium側へ振り分ける設計にしてください。 ### Kitesurfはオープンソースとして公開されていますか？ 2026年8月時点では公開されていません。Cloudflareは準備が整い次第オープンソース化する意向を示していますが、時期は明示されていない状態です。使われている構成部品のうちBlitz・Stylo・Parley・BoaはいずれもRustコミュニティの既存プロジェクトで、こちらは公開されています。 ### 本番投入して問題ない成熟度ですか？ ベータ提供であることを前提に、退避先を用意したうえでなら投入できます。Web Platform Testsは21万5千件以上を通過しており、テキスト抽出の用途では実務に耐える水準です。判断材料としては、自社の対象URL群で二系統を並走させ、抽出結果の一致率と失敗率を測るのが確実になります。 ## 関連記事 - [Cloudflare Workersとは？エッジコンピューティングの基本解説](https://www.issoh.co.jp/tech/details/6539/)：Kitesurfが動く実行基盤そのものの仕組みを扱っています。 - [Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ](https://www.issoh.co.jp/tech/details/6760/)：課金体系と無料枠の考え方を確認できます。 - [スクレイピングとは？クローリング・APIとの違いと実装・法務の判断を解説](https://www.issoh.co.jp/tech/details/13414/)：巡回そのものの手法選定と法務の前提を整理しています。 - [RustでWebAssemblyを実装する手順｜wasm-packでのWASM化と軽量化・配置先の選び方](https://www.issoh.co.jp/tech/details/15290/)：Wasm化の一般的な手順と軽量化の勘所をまとめました。 - [AIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準](https://www.issoh.co.jp/tech/details/15367/)：ブラウザ層の外側にあるエージェント本体の設計を扱っています。 --- 出典: [Cloudflare Kitesurfとは：Wasmブラウザの実測値と切替手順・使えない場面を解説]()（株式会社一創）