Kitesurfとは｜CloudflareのAIエージェント専用ブラウザをV8 isolateの仕組みから解説

Cloudflareが2026年8月6日、Kitesurfを発表した。AIエージェント専用に設計された新しいWebブラウザで、Chromiumを使わず、Cloudflare WorkersのV8 isolate上で丸ごと動く。Hacker Newsでは216ポイント・62コメントを集めている（スレッド、2026年8月10日時点）。

まず、下の画像を見てほしい。これはKitesurfが実際にレンダリングしたHacker Newsのスクリーンショットだ。筆者がCloudflareアカウントもAPIトークンも使わず、curl一発で取得したものである。

エージェント設計全体の中でブラウザをどのレイヤーに置くかという話は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で整理している。本記事はそのうち「ブラウザ本体」の層だけを扱う。

Kitesurfとは——V8 isolate上で動くAIエージェント専用ブラウザ

Kitesurfは、Cloudflareのヘッドレスブラウザ自動化API「Browser Run」の新しいバックエンドとして提供される、エージェント向けに割り切ったブラウザだ。公式ブログの著者はCelso Martinho、Ruskin Constant、Rui Figueira、Luís Duarteの4名。プロジェクトの最初のコミットは2026年5月で、発表時点で12週間しか経っていない。

「自分たちでブラウザを作るべきか」という議論はCloudflare社内で何年も繰り返されては棚上げされてきた、とブログは書いている。今回それが動いたのは、2つの条件が同時に揃ったからだ。ひとつはWorkers側の成熟——WebAssembly対応、Dynamic Workers、SQLiteベースのDurable Objects、Worker間RPC、Node.js互換性の向上、各種上限の引き上げ。もうひとつはAIエージェントの側の需要である。

ブログの問題提起は率直だ。

browser engines like Chromium were built for humans, not agents

Chromiumは人間のために作られていて、エージェントには不要なオーバーヘッドを抱えている。メモリとCPUを食いすぎるので、エージェント1体ごとに1インスタンスを与えるのは費用的に非現実的になる。結果として、Webの大部分が「高価で高性能なモデル」にしかアクセスできなくなる——というのがCloudflareの見立てである。

そこで、エージェントにとって重要でないものを大胆に捨てた。Cloudflareが挙げる「AIが気にしないもの」は、タブ、テーマ、拡張機能、デバイス間同期、滑らかな60fpsスクロール、ピクセル単位の正確なCSSレンダリング。逆に「AIが気にするもの」は、トークン数、コンテキストウィンドウ、スケーラビリティ、性能、コストだ。

この位置づけを最初に押さえておくと混乱しない。そしてAIエージェント向けブラウザというジャンル自体は、既に混み合っている。Obscura：Rust製ヘッドレスブラウザがChrome比6倍高速・メモリ85%削減でAI自動化を変えるは自分のマシンでChromeなしにCDPを話すローカル実行型で、camofox-browser完全解説：C++偽装でAIエージェントの検出を回避するREST APIブラウザは逆に「検出されないこと」に全振りしている。Kitesurfはそのどちらでもない。リモートで動くブラウザエンジンをCDP越しに貸すタイプで、しかも後述のとおりbot検知の回避は明確に守備範囲外だと宣言している。

なお、Cloudflare自身がKitesurfの着想元として明示しているのが、まさにそのObscuraだ。ブログ本文からh4ckf0r0day/obscuraへリンクが張られており、「no Chrome, no Node.js, no dependencies」というObscuraの謳い文句を引用したうえで、「AIエージェントの助けを借りてWorkersへの移植を試みた。最初はうまくいかなかったが、明確な計画と成功の定義を与えたら動いた」と書いている。当サイトが2026年4月にObscuraを取り上げた時点でスター数は約2,400だったが、2026年8月10日時点では20,919まで伸びている。

なぜフルChromiumではないのか——「人間用の機能」の代償

Chromiumを使わないという判断は、単に「軽くしたい」以上の意味を持つ。Cloudflareが設計段階で決めた方針は4つある。

1. テストを大量に用意する。プロトタイプから実用ブラウザへ持っていく作業にAIエージェントを使うと決めた以上、品質の歯止めが要る。そこで採用したのがWeb Platform Tests（WPT）だ。W3C標準への準拠度を測る膨大なテスト群で、AIエージェントに与える「明確なゴールポスト」として機能する。ただしWPTは標準準拠を測るだけで、実在のWebサイトを正しく描画・操作できるかは測れない。そのギャップを埋めるため、実サイトに対して多段のPuppeteerテストをChromiumとKitesurfの両方で走らせ、アサーションだけでなく各ステップのレンダリング結果まで比較する視覚回帰テストを組んでいる。

2. 可能な限りRustを使う。Emscriptenのようなエミュレーション層を挟むとバイナリが肥大化して遅くなるため、ネイティブRustをwasm-bindgenで直接WebAssemblyへコンパイルする方針を取った。

3. 例外は必ず握る。ここは設計思想がはっきり出ている箇所で、ブログは一行のルールとして書いている。

any failure degrades to a blank frame or a missing element, never a dead session

どんな失敗も、空のフレームか欠けた要素に劣化するだけで、セッションを殺すことはない。敵対的な入力を含む「信頼できないWeb全体」を相手にする以上、落ちないことが最優先だという判断だ。

4. 可能な限りステートレスにする。状態を持たないコンポーネントは使い捨てにでき、並列に走らせられる。詰まったら殺して作り直せばいい。バースト的に負荷が来る自動化用途にはこの性質が効く。

そしてもう一点、分離。手元のPCのブラウザは「信頼できるサイトを見る」前提で多少のリソース共有を許容できるが、エージェントはタスクが要求するまま任意のオリジンの任意のコードへ向かう。そのためKitesurfは「すべてのページ読み込みは信頼できない入力であり、すべてのセッションは新規に始まる」という前提で作られている。

Workersのセキュリティモデルはもともと分離を前提に設計されているが、ブログはそれだけでは足りないと釘を刺している。プラットフォームが与えてくれるのはisolate間の境界だけで、「どのコンポーネントが何に触ってよいか」をアプリケーション層で決め、ページをまたいで何も漏れないようにするのは自分たちの仕事だ、と。エージェント実行環境の分離をどの粒度で取るかという設計判断は各社で割れており、CubeSandbox解説：60ms起動MicroVMでAIエージェントを安全実行するTencentの設計思想はMicroVMという一段重い境界を選んでいる。Kitesurfはより軽いV8 isolateを選び、その代わりネットワーク出口を1コンポーネントに絞ることで補っている。

内部構造：4つのWorkerが1つのブラウザを構成する

Kitesurfは単一のプログラムではなく、役割の違う複数のWorkerの集合体だ。

Engine は唯一の公開コンポーネントで、CDPのWebSocketとHTTP REST APIを処理し、セッション状態を保持する。名前に反して、Kitesurfの中では最も単純な部品だとブログは書いている。CDPを採用した理由はクライアント互換性で、Puppeteer・Playwright・chrome-remote-interface、そして本物のChrome DevToolsフロントエンドがそのまま繋がる。

PageScript はDynamic Workersの威力が最も出ている部分だ。ページごと、あるいはOOPIF（アウトオブプロセスiframe）ごとに、長寿命のisolateを立ち上げる。isolateの中にはクリーンなglobalThisとDOM documentオブジェクトがあり、そこへHTML解析結果を流し込む。HTMLとCSSの解析にはBlitz（モジュラーな描画エンジン）とStylo（Firefoxの高性能CSSパーサ）を使う。どちらもRust製だ。<script>タグや.wasmファイルを見つけると、同じisolate内でそのJavaScript／WebAssemblyを実行する。

ここで問題になるのがevalである。Workersはセキュリティ上の理由でネイティブのevalを今も許していない。別のisolateを立ててもglobalThisにアクセスできないので解決にならない。Cloudflareの答えは、Rust製のECMAScriptエンジンBoaをWorkers上で動かすことだった。ブログは「ランタイムの上でランタイムを動かしているわけで、最適とは言えないし、実際最適ではない」と正直に認めつつ、コード中にたまに現れるevalを捌くには十分に機能していると書く。Workersにネイティブevalが入ったら移行する予定だという。

PageRenderer は計算済みのページオブジェクト（シーン）から実際のピクセルを生成する。Blitzの別モジュールであるblitz-paintが中心で、文字をグリフに整形しフォントを選び行分割する処理にはParleyを使う。ラスタライズ結果をJPEG/PNG/PDFとしてEngineへ返す。

SandboxOutbound はネットワークの単一出口だ。外部からアセット（画像・フォント・CSS・JS・Wasm）を取ってくるのはブラウザにとって最も危険な操作のひとつなので、これをDynamic Workersで強制的に1コンポーネントに閉じ込めている。CORSの強制、ブラウザらしいヘッダの注入、レスポンスのフィルタ、ページごとのCookie隔離をここで行い、ポリシーに反するものは403で落とす。

コンポーネント間の呼び出しにはWorkers組み込みのRPCを使う。EngineがPageRendererのrenderFrame()を1回呼べばPNGが返ってくる。レンダラは（使い捨てのキャッシュ以外に）ページ状態を持たないので、RPCが失敗したり詰まったりしたらEngineは安全に殺して立て直せる。

使い方：APIキー不要のplaygroundと、Browser Run経由の2経路

Kitesurfを触る経路は2つある。この2つは制限も用途もまったく違うので、混同しないでほしい。

経路1：公式playground（アカウント不要・動作確認用）

kitesurf.cloudflare.app が公開playgroundだ。ブラウザで開けばURLを入力して描画結果を見られるうえ、UIにChrome DevToolsが注入されているので、展開後のDOM要素の検査、コンソールメッセージの確認、ネットワーク活動の観察ができる。Memoryパネルは各isolateのWebAssemblyフットプリントをフレーム単位で報告するよう実装されており、そのページがどれだけリソースを食っているかを直接見られる。

そしてplaygroundは、HTTPエンドポイントとしても認証なしで叩ける。筆者が2026年8月10日に確認した挙動は以下のとおり。

# スクリーンショット（1920x1080のPNGが返る）
curl -s "https://kitesurf.cloudflare.app/screenshot?url=https%3A%2F%2Fnews.ycombinator.com%2F" -o hn.png

# レンダリング後のHTML（JS実行後のDOM）
curl -s "https://kitesurf.cloudflare.app/html?url=https%3A%2F%2Fexample.com%2F"

# PDF化
curl -s "https://kitesurf.cloudflare.app/pdf?url=https%3A%2F%2Fnews.ycombinator.com%2F" -o hn.pdf

# CDPターゲット一覧（WebSocketのURLがここに出る）
curl -s "https://kitesurf.cloudflare.app/json"

playgroundページに明記されている制限は「1回のページ遷移あたりCPU時間20秒・実時間60秒」。予算を超えるとページは停止され、DevToolsが理由を教えてくれる。またURLスキームはhttps:のみで、http:・data:・javascript:・file:は拒否される。

なお、Browser Runには/markdown・/snapshot・/content・/links・/scrapeといったトークン削減に効きそうなQuick Actionが用意されているが、playgroundでは提供されていない（筆者が叩いたところ/markdown・/snapshot・/content・/links・/scrapeはいずれも404、/jsonのみ200）。これらをKitesurfで試すにはBrowser Run経由が必要になる。

経路2：Browser Run（実運用向け）

既存のBrowser Runエンドポイントにbrowser=kitesurfを付けるだけで切り替わる。ベータ期間中は無料で、アカウント単位の制限がかかる。

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"

MCPクライアントから使う場合は、chrome-devtools-mcpのWebSocketエンドポイントをKitesurf側に向ける。Cloudflareが公式ブログで示しているopencode向けの設定はこうだ。

{
  "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側の制限はKitesurf固有ではなく製品共通で、公式ドキュメントに記載がある。

playgroundの「CPU20秒／実時間60秒」とこの表は別物である点に注意してほしい。前者はplayground固有の予算、後者はBrowser Runというプロダクトの制限だ。

実測：KitesurfはJavaScriptを実行しているのか、CDPに何を名乗るのか

ここからは公式発表ではなく、筆者が2026年8月10日にplayground経由で測った結果である。

エージェント開発者にとって最も重要な問いは「Kitesurfは単なる高機能なfetchなのか、それとも本当にブラウザなのか」だ。SPAを食わせれば一発でわかる。

TodoMVCのReact版に対し、素のcurlとKitesurfの/htmlを並べた。素のcurlが返す<body>はこうだ。

<body><section class="todoapp" id="root"></section><footer class="info">...</footer><script src="./base.js"></script></body>

id="root"が空である。一方Kitesurfの/htmlは、この#rootが埋まった状態のDOMを返し、さらにbase.jsが動的に差し込む解説サイドバー（<aside class="learn">）まで含まれていた。開始タグの数で比べると、素のHTMLが17個に対しKitesurfは70個。JavaScriptは確かに実行されている。

5サイトで測った結果をまとめる。

読み取れることは3つある。

第一に、静的HTMLのサイトではKitesurfを使う意味がほぼない。Hacker Newsは本文の文字数が3,993字で完全に一致し、Wikipediaもほぼ同じ（差はJSで消える要素の分）。これらは素のcurlで足りる。エージェントの実装で「とりあえず全部ブラウザに通す」設計にしていると、この帯域では純粋に無駄なコストを払うことになる。

第二に、SPAでは決定的な差が出る。TodoMVC Vueは84字から356字へ、Reactは86字から160字へ増えた。素のfetchでは空のシェルしか取れないので、そもそも情報がゼロである。

第三に、実時間は「体感で待てる」水準。ただしこの数字は筆者のノートPCから公開インターネット越しにplaygroundを叩いた壁時計時間であり、Cloudflareが公表しているサーバ側ベンチマーク（後述）とは測っているものが違う。両者を突き合わせて優劣を語ることはできない。

なお、SPAの抽出結果は実行タイミングによって揺れる。TodoMVC Reactは別の試行で1,926 Bではなく3,133 Bを返した。非同期に差し込まれる要素がどこまで間に合うかで変わるためで、単発の数値を絶対値として扱うべきではない。

CDPに何を名乗っているか

もうひとつ、playgroundのCDPエンドポイント（wss://kitesurf.cloudflare.app/devtools/browser）にWebSocketで接続し、Browser.getVersionを投げてみた。返ってきたのがこれだ。

{"protocolVersion":"1.3","product":"Chrome/145.0.0.0","revision":"@kitesurf",
 "userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36",
 "jsVersion":"12.0.0"}

「Puppeteerもplaywrightもそのまま動く」という主張の機構がここに見える。KitesurfはCDPプロトコル1.3を名乗り、製品名としてChrome/145.0.0.0を、UAとしてLinux版Chromeの標準的な文字列を返す。バージョンを見て挙動を変えるクライアントに対して、Chromeとして振る舞っているわけだ。正体を明かしているのはrevisionフィールドの@kitesurfだけで、ここだけが本当のことを言っている。

これは実務上の含意もある。接続先サイトから見れば、Cloudflareのアドレス帯から一般的なLinux Chromeを名乗るアクセスが来る。Cloudflare自身が「実TLSフィンガープリントを伴うbotチャレンジのネゴシエーションはできない」と明記しているとおり、UA偽装で検知を回避する類の用途は想定されていない。

Playwright・Puppeteer・browser-useとの違いと使い分け

「Kitesurfに移行すべきか」という問いは、多くの場合そもそも設定が誤っている。KitesurfはPlaywrightの競合ではないからだ。整理するとこうなる。

判断は用途で切れる。

・エージェントを多数並列で走らせ、1回あたりの処理が短い——Kitesurfが最も効く領域。ステートレスかつ使い捨て前提の設計がそのまま利点になる
・スクショ・PDF生成・本文抽出のようなワンショット処理——Cloudflare自身が「Quick Actionsに依存する自動化やアプリケーションにも優れている」と挙げている用途
・対象が静的HTMLのサイトだけ——そもそもブラウザが不要。素のfetchで足りる（前節の実測どおり）
・動画・WebGL・ログイン維持・bot対策サイト——Kitesurfは非対応。Browser Runの既定（Chromium）を使う
・E2Eテストでピクセル単位の忠実性が要る——Kitesurfの守備範囲外。そもそも「ピクセルパーフェクトを捨てる」のが設計方針である

性能：CPUとメモリは減り、実時間は増える

Cloudflareが公表しているベンチマークは、14個のURLからなるコーパスに対しBrowser Runのquick actionを5回実行した中央値を、暖機済みのChromiumプールと比較したものだ。

Cloudflare自身の説明はこうだ。ストップウォッチで勝つのはChromiumで、すでにそのページを見たことのあるJITは、コールドなソフトウェアレンダラに常に勝つ。差の大部分はラスタライズとJPEG/PNGエンコードから来ており、そこは今後最適化していく。一方でKitesurfが勝つのはメモリとCPU——請求額を実際に動かす部分である。メモリが減れば同時セッション数を増やせ、スケールしやすくなり、Cloudflare側のコストも顧客側のコストも下がる、と。

つまりKitesurfの売りは速度ではない。単価だ。ここを取り違えると導入判断を誤る。1リクエストのレイテンシが厳しいユースケースではChromiumのほうが速い。

標準準拠の面では、Kitesurfは215,000以上のWPTテストをパスしており、毎週数百件ずつ増えているという。公式ドキュメントによれば、エージェントにとって重要な領域のカバレッジは高く、DOMが97%、HTMLが96%、Selectionが99%。ストリームのようにエージェント用途では優先度の低い領域も、それなりに対応が進んでいるとしている。

今できないこと、OSS化の見通し、そして構成部品

動かないもの

Cloudflareは制限を明示している。動画再生、WebGLのレンダリング、実TLSフィンガープリントを伴うbotチャレンジのネゴシエーション、状態を保持する10分級の認証セッション——これらが必要ならKitesurfはまだ適切な選択肢ではなく、Chromium製の既定を使えばよい、と。

一方で、実際に描画できるページとして挙げられているのはTodoMVC（vanilla・React・Vue・Angular・Preact）、Wikipedia、Hacker News、Cloudflare Blog、そしてCloudflareダッシュボードの大部分である。

ブログが「最も重要なテスト」として掲げているのが、Doomが動くかどうかだ。筆者もplaygroundでsilentspacemarine.com（CloudflareがWorkers・WebSockets・Durable Objectsで作ったWebAssembly版Doom）を撮ってみた。

前掲のHacker Newsのスクリーンショットとあわせて見ると、レンダリング品質の実像がわかる。レイアウト・配色・文字は十分に読める水準で、エージェントが画面を見て判断する用途には足りる。一方でフォントは元サイト指定のものとは異なるものに代替されており、テーブルの幅もビューポートを完全には埋めていない。「ピクセルパーフェクトではない」という但し書きは誇張ではなく、実際にこの程度の差は出る。エージェントの判断には影響しないが、視覚回帰テストの基準画像には使えない。

OSSではない。ただし部品はすべてOSS

2026年8月10日時点で、Kitesurf本体のソースコードは公開されていない。ブログの最後にこう書かれている。

we’re going to open source Kitesurf once we’re ready — hopefully soon

目標は「顧客が望めば自分のアカウントに自前のKitesurfをデプロイできるようにすること」だという。時期の確約はない。したがって現時点では、KitesurfはCloudflareのマネージドサービスとしてのみ利用可能と理解しておくのが正確だ。

ただし、Kitesurfを構成している要素はいずれも既存のOSSであり、これらは今すぐ単体で試せる。以下は2026年8月10日にGitHub APIで取得した実データである。

※ Stylo だけはGitHub APIのライセンス判定が空になる。リポジトリ直下にLICENSEファイルが無いためで、実体は style/Cargo.toml の [package]（クレート名 stylo、リポジトリのdefault-member）が license = "MPL-2.0" を宣言している。他の3つはリポジトリ単位で判定済みの値。

Kitesurfの独自性は、これらを組み合わせてWorkersのisolateモデルに載せた統合の部分にある。逆に言えば、Rust製ブラウザエンジンをローカルで試したいだけなら、Blitzを直接触るという道は今すぐ開かれている。

今後の予定

Cloudflareが挙げている改善項目は4つ。CDPプロトコルのカバレッジ拡大（現状はサブセット実装で、DOMとネットワーク検査は堅牢とのこと）、スクリーンショットとPDFのレンダリング忠実度の向上（「LLMはテキストより画像のほうがうまく扱えることが多い」ため）、WPTカバレッジのさらなる拡大、そしてCPU・メモリ・実時間の効率改善である。

参照ソース

・Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers — Cloudflare公式ブログ、2026年8月6日。Celso Martinho、Ruskin Constant、Rui Figueira、Luís Duarte。アーキテクチャ・ベンチマーク・制限・OSS化方針の一次ソース
・Kitesurf — Cloudflare Browser Run ドキュメント — browser=kitesurfの指定方法、WPTカバレッジ率（DOM 97%・HTML 96%・Selection 99%）、ベータ／無料の位置づけ
・Browser Run Limits — Free/Paidの同時実行数・レート制限・タイムアウトの公式値
・Kitesurf Playground — 認証不要の公開playground。本記事の実測はすべてここを経由（2026年8月10日実施）
・Kitesurf: Agent-first browser that runs in V8 isolates — Hacker News — 216ポイント・62コメント（2026年8月10日時点）
・h4ckf0r0day/obscura — Cloudflareが公式ブログで着想元として明示しているRust製ヘッドレスブラウザ