8月6日、Cloudflareが「Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers」と題した記事を公開した。AIエージェント専用に設計され、Cloudflare Workers上のV8 isolateで完全動作するブラウザ「Kitesurf」の技術的アーキテクチャについて詳しく紹介されている。
「ブラウザを自作すべきか？」に、今回初めて「Yes」と答えた
Cloudflare社内では、ブラウザ自作の議論が何年も周期的に浮上しては棚上げされてきた。技術的難度と解決できる問題のバランスが取れなかったからだ。しかし今回、状況が変わった。
AIエージェントがWebにアクセスする場面は急増している。CloudflareはChromiumベースのヘッドレスブラウザAPIとして「Browser Run」（旧称: Browser Rendering API）を提供してきたが、AI需要の急拡大とともにその限界が顕在化した。問題の核心はリソース効率だ。Chromiumはメモリとコンピューティングを大量消費するため、エージェントごとに専用インスタンスを用意するとコストが現実的でなくなる。結果として、高性能なAIモデルだけがWebを活用でき、多くのエージェントアプリケーションが閉め出される状況が生まれていた。
12週間前、Cloudflareは問いを立て直した。「AIに本当に必要なものだけを持つブラウザを作ればいい」という答えが出た。
- AIはタブ、テーマ、ブラウザ拡張機能、デバイス間同期を必要としない。必要なのはトークン数、コンテキストウィンドウ、スケーラビリティ、コストだ
- 視覚的な完全性（60fpsスクロール、ピクセルパーフェクトなレンダリング）は不要。構造化されたマシン可読コンテンツが重要
- 脅威モデルが異なる。プロンプトインジェクションやツールの安全性が優先事項となる
開発の出発点となったのはRust製ヘッドレスエンジンobscura（「Chromなし、Node.jsなし、依存なし」を掲げるAI自動化向けエンジン）だ。AIエージェントの助けを借りてWorkersへの移植を試みたところ、「エージェントに明確な計画と成功の定義を与える」ことで動作するプロトタイプが完成した。こうして誕生したのがKitesurf——Cloudflare Workers上で完全動作するエージェント専用ブラウザである。現在Browser Runでベータ版が無料提供されている。
既存ユーザーへの影響：Puppeteer・Playwrightはそのまま動く
Kitesurfを導入するにあたって、まず開発者が気になるのは「既存のコードが動くか」だろう。
KitesurfはChrome DevTools Protocol（CDP）のWebSocketとHTTP REST APIを実装しているため、既存のPuppeteer、Playwright、chrome-remote-interfaceがそのまま動作する。Browser Runの既存ユーザーは特別な変更なしにKitesurfを利用できる。アーキテクチャを根本から作り直しながら、互換レイヤーを維持している点は実用面での大きな強みだ。
アーキテクチャの核心：V8 isolateで動くブラウザの中身
Kitesurfが技術的に面白いのは、その構成要素にある。主要コンポーネントはEngine、PageScript、PageRendererの3つだ。
PageScript：Dynamic Workersなしには存在しなかった
最も注目すべきコンポーネントがPageScriptだ。ページごと、またはout-of-process iframe（OOPIF）ごとに、**Dynamic Workers**（実行時に動的に生成・起動できるCloudflare Workersの仕組み）を使ってPageScript isolateを起動する。各isolateはクリーンなglobalThisとDOMドキュメントオブジェクトを持つ。
HTMLとCSSのパースには、Blitz（DioxusLabsが開発するモジュール型Rustレンダリングエンジン）とFirefoxのCSSエンジン由来の高性能パーサーStyloを使用。どちらもRust製で、WebAssemblyにコンパイルしてWorkers上で実行される。
evalの扱いが一つの難所だった。Workersはセキュリティ上の理由からネイティブのevalをサポートしていない。別のisolateでevalを処理しようとしても、そのisolateは元のglobalThisにアクセスできない。解決策として採用したのが**Boa JS**——Rustで実装されたECMAScriptエンジンをWorkers上でさらに動かすという、「ランタイムの上でランタイムを動かす」構成だ。パフォーマンスコストを伴うアプローチであることは記事中でも認めているが、実際のエージェント処理で遭遇するevalの頻度と内容には十分機能しているとしている。将来Workersがネイティブeval対応した際には移行予定とのことだ。
PageRenderer：RPCで繋がるステートレスなレンダラー
PageRendererはページオブジェクトから実際のピクセルを生成するコンポーネントだ。EngineからWorker間RPCでrenderFrame()を呼び出し、PNGを返す。
engine.renderFrame() → [RPC] → PageRenderer → PNG
PageRendererはページの状態を持たない（使い捨てキャッシュのみ）。そのためEngineはRPCが失敗・スタックした際にいつでもkill→再起動できる。各レンダーリクエストが完全に自己完結している設計だ。文字のレンダリングにはBlitzのサブモジュールblitz-paintとParleyを使用し、グリフへの変換とテキストの折り返しを処理する。
ネットワークアクセスの封じ込め
外部ネットワークへのアクセスはSandboxOutboundという単一のWorkerのみが担う。他のコンポーネントは直接ネットワークに触れられない——これはDynamic Workersによって強制される。CORSの適用、ブラウザ的なヘッダーの注入、レスポンスフィルタリング、ページごとのCookie分離がここで行われ、ポリシーに違反したリクエストには403を返す。
テスト戦略：AIエージェントを使い倒す
Kitesurfの開発でAIを活用したのは実装だけではない。テスト戦略にも組み込まれている。
Web Platform Tests（WPT）——ブラウザの相互運用性を検証するための業界標準テストスイートで、Chrome・Firefox・Safariなど主要ブラウザエンジンも継続的にスコアを競っているベンチマーク——をAIエージェントへの明確なゴールポストとして活用。人間はアーキテクチャレビューに集中し、エージェントに機能実装とテスト通過を繰り返させる体制を取った。現時点でKitesurfは215,000以上のWPTテストをパスしており、この数は増加中だ。「全機能網羅」ではなくAIユースケースに絞った実装でこの数字を達成している点が特徴的だ。
WPTだけでは実世界のWebサイトへの対応を測れないため、実際のWebサイトに対してPuppeteerを使ったマルチステップの統合テストと視覚回帰テストも実施している。ChromiumとKitesurfの両方で同じテストを走らせ、DOMアサーションだけでなく各ステップのレンダリング出力も比較する構成だ。
詳細はIntroducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workersを参照していただきたい。
