なぜ自前でブラウザを作るのか：Chromium は人向けに作られている

「自前ブラウザを作るべきか」という問いは、Cloudflare 社内で数年にわたり数ヶ月おきに持ち上がっては、そのたびに見送られてきました。技術的な難しさと「どのような独自の課題を解決できるのか」という点の両方で、バランスが取れなかったからです。

今回答えが「作る」に変わったのは、両方の条件が同時に熟したからです。プラットフォーム側が成熟した：Workers 上で WebAssembly を動かすことが安定し、Dynamic WorkersCloudflare Workers の機能の 1 つ。コードの実行中に、動的に新しい隔離環境を作って別のコードを実行でき、その環境がアクセスできる範囲も制限できる。、SQLite ベースの Durable Objects、Worker 間の直接呼び出しが出揃い、以前は難しかった複雑なアプリケーションが作れるようになりました。需要側も迫ってきた：Browser Run（Cloudflare のヘッドレスブラウザ自動化プロダクト）は AI の台頭とともに急成長。エージェントが多くの仕事をする上で、ブラウザなしではどうにもならない場面が増えています。

ここが行き詰まりの本質でした。従来のブラウザはすべて人間のために設計されています。美しい UI、タブ、豊富な拡張機能、滑らかな 60fps スクロール。これらのせいでブラウザはメモリと CPU を異常に消費し、「エージェントごとに 1 インスタンスを割り当てるのはコスト的に不可能になってしまいます。その結果、ウェブ上の大部分は最も高価で最も賢いモデルにしか開かれておらず、それ以外のエージェントアプリケーションは締め出されているというのが現状です。

しかし AI エージェントには、そうした派手な機能は必要ありません。チームは人間とエージェント、それぞれが重視するものを並べて比較しました。この部分が、この記事全体の思想的基盤になります。

もう 1 つ見落とされがちな点があります。脅威モデルが異なる、ということです。人間がブラウザを開くとき、訪問するのは自分が知っているサイトです。一方 AI がブラウザを開くときは、タスクに指示された場所ならどこへでも行きます。プロンプトインジェクションやツールのセキュリティといった新しい問題は、このシナリオでは最優先の課題になります。

そして 12 週間前、チームは再びあの古い問いを立てました。今回は全会一致で「作る」でした。人間にしか必要ないビジュアルと機能をすべて捨て、AI が本当に使うコア機能だけを残す。

中核的な強み：コストとリソースの大幅削減、完全ステートレス、高い互換性

その1：とにかく安くて軽い（中核的価値）

標準の Chromium と比べた場合、これが最もストレートな計算です。比較相手は「熱いプール」（常時起動して待機中）の Chromium。すでにウォームアップ済みで、いつでも仕事を受けられる状態のものです。

生の数字はこちらです：

小さな欠点 / トレードオフ：ページ描画のウォールタイムは Chromium より 1.7〜1.8 倍遅くなっています。公式の説明は「そのページをすでに見たことのある JIT（実行時コンパイラ）は、コールドスタートのソフトウェアレンダラーより常に速い。差は主にラスタライズと JPEG/PNG エンコード部分で、まだ最適化を続けている」というものです。少しの待ち時間と引き換えに 3〜7 倍のリソースを節約できるのは、AI 自動化タスクにとっては非常にお得です。

データ・説明ともに Kitesurf 発表ブログより

その2：完全ステートレスで、高度に隔離

全体は Workers 上で動作し、すべてのページ読み込みを信頼できない入力として扱い、すべてのセッションは毎回ゼロから始まります。3 つのコンポーネントのうち、状態を持つのはエンジンだけ。残りはすべてステートレスです。復元すべき状態がないため、クラッシュからの回復は「新しいものを作ってリクエストをやり直す」のと同じことになります。

メリットは現実的です。特定のページがクラッシュしてもシステム全体には波及しません。固まったレンダラーは直接殺してやり直せます。1000 個同時に開いていても、常時生かしておく必要はありません。

その3：互換性が非常に高い。パラメータを変えるだけ

標準の CDPChrome DevTools Protocol。Chrome のデベロッパーツールとブラウザの間で通信するためのプロトコル。Puppeteer や Playwright などの自動化ツールは、これを使ってブラウザを遠隔操作している。（Chrome DevTools Protocol）を話します。つまり、既存の Puppeteer、Playwright、chrome-remote-interface、さらには MCP や CDP を話す AI フレームワークも、URL パラメータを 1 つ変更するだけでシームレスに乗り換えられます。コードは 1 行もいじる必要がありません。

仕様適合性については、すでに WPTWeb Platform Tests。ブラウザがウェブ標準をどの程度実装しているかをチェックする、公開された大規模なテストスイート。（Web Platform Tests）の 215,000 件以上のテストに合格しています。毎週さらに数百件ずつ増えています。

分野別に見ると、より本質が見えてきます。エージェントが実際に使う分野のカバレッジは良好ですが、同じ表には明らかに低い項目も並んでいます：

最後はあの伝統的なテストです。Doom が動きます。公式の言葉は「テストが何万件あっても、Doom が動かないプロジェクトは本当に完成したとは言えない」というものです。

技術アーキテクチャ：3 つのモジュールとネットワーク出口

この図で最も重要なのは「誰が状態を持つか」「誰がステートレスか」「誰がネットワークに触れるか」の 3 点です。

Engine（エンジン）：唯一の外部窓口で、CDP の WebSocket と HTTP インタフェースを受け持ち、各セッションの状態を保持します。名前が最も仰々しいですが、実は 3 つのコンポーネントの中で最もシンプルです。

PageScript（スクリプトとパース）：新しいページやクロスプロセス iframe が開かれるたびに、Dynamic Workers を使ってライフサイクルの長い隔離環境を起動します。そこにはクリーンなグローバルオブジェクトと DOM ドキュメントがあります。HTML と CSS のパースには Blitz（モジュラーレンダリングエンジン）と Stylo（Firefox の高性能 CSS パーサー）の一部を使用。どちらも Rust で書かれています。

ここに、触れておく価値のある詳細があります。ウェブページ内の eval はどうするのか？ Workers はセキュリティ上の理由から、いまだに eval をネイティブにサポートしていません。かといって別の隔離環境を立てて処理しようとすると、ページのグローバルオブジェクトにアクセスできなくなります。彼らの解法は、Boa JS（Rust 製の JavaScript エンジン）を Workers 用にコンパイルして動かすこと。つまり、あるランタイムの上にもう 1 つランタイムを載せる形です。彼ら自身も「見た目はエレガントではないし、実際エレガントでもないが、コード内に時々現れる eval を処理するには十分」と認めています。Workers がネイティブで eval をサポートしたら、Boa は置き換える予定です。

PageRenderer（レンダリング）：PageScript から計算済みのページオブジェクト（彼らは「シーン」と呼ぶ）を受け取り、フォントと画像を取得してラスタライズし、画像バッファを生成。クライアントが要求した JPEG / PNG / PDF 形式で返します。ページの状態は保持しておらず、破棄可能なキャッシュしか持ちません。そのため、今回の呼び出しが失敗したり固まったりした場合、エンジンはこのレンダラーを直接 kill して再起動できます。各レンダリングリクエストは自己完結的で、リトライ可能です。

SandboxOutbound（ネットワーク出口）：信頼できないウェブページをレンダリングするには、必然的にインターネット上の任意のリソースを取得する必要があります。画像、フォント、CSS、JavaScript、Wasm ファイルなどです。これはブラウザが行う最も危険な操作の 1 つです。Kitesurf はこれを単一のコンポーネントに集約し、それ以外の何物もネットワークに触れられないようにしています。これは Dynamic Workers によって強制されます。ここがクロスオリジンポリシーの実行、ブラウザ型リクエストヘッダーの注入、レスポンスのフィルタリングを担当し、cookie はページごとに別々の瓶に入れられ、ポリシーに適合しないものはすべて 403 を返します。

12 週間でどうやって作ったのか

このセクションが、この記事全体で最も持ち帰りやすい部分です。AI に複雑で制御不能になりがちな仕事をさせる方法についてです。

出発点はオープンソースプロジェクト obscura。Rust 製のヘッドレスエンジンで、「Chrome なし、Node.js なし、依存関係なし」を売りにしています。

彼らは AI エージェントに、これを Workers へ移植することを試させました。最初は散々な結果でした。転機は、AI にしっかりした計画と明確な成功定義を与えたこと。エージェントが延々とループし続けられ、行き詰まったら質問に戻ってくることがわかるほど詳細なものでした。すると、動くようになったのです。かろうじて動くそのプロトタイプに衝撃を受けたチームは、本格的に作り込むことにしました。

次に彼らは、自らこの核心的な問いを投げかけます：

プロトタイプから、本番でスケールに耐える完全なブラウザに到達するには、大量の作業と反復が必要です。AI でこのプロセスを加速することが鍵だったのは否定しません。しかし、これほど複雑なプロジェクトで、コードと成果物の品質を保ちつつ、スピードも落とさずに AI を使うにはどうすればいいのか。

答えは「できるだけ多くのテストを用意する」ことです。

Kitesurf 発表ブログ

使われたのは WPT です。WPT は AI エージェントに明確なゴールポストを提供します。どの機能ができて、どの機能ができていないかが、テストすればすぐにわかります。人間がやることは 2 つだけ。エージェントに任せる機能の選定と優先順位付け。そして、アーキテクチャを見て、エージェントの考え方が正しいかを確認することです。

しかし WPT は仕様適合性しか測れません。「実際のウェブサイトをレンダリングして操作できるか」は測れないのです。そこで彼らはもう 1 層追加しました。統合テストとビジュアルリグレッションテストです。Puppeteer で実際のウェブサイトに対して複数ステップの操作を実行し、Chromium と Kitesurf を同時に走らせて、アサーションの結果だけでなく、各ステップのレンダリング出力も 1 枚ずつ比較し、あるべきでない差分を洗い出します。

着手前に決めた 4 つのルール

テスト以外にも、最初の本番コードを書く前に 4 つのルールを固定しました。それぞれに「だからどうなる」が続きます。

向いている仕事、向いていない仕事

このセクションは「自分の仕事が乗り換えるべきかどうか」を判断するためのものです。

公式の位置づけは、次のように正確な言葉で表されています。Kitesurf とは「短命で、完全に隔離され、ステートレスなエンジン」であり、1 つのタスクの時間だけ存在するもの。波のように押し寄せる AI 負荷に適しています。

サイト互換性については、現在きちんとレンダリングできるものとして、TodoMVC の各バージョン（ネイティブ、React、Vue、Angular、Preact）、Wikipedia、Hacker News、Cloudflare ブログ、そして Cloudflare ダッシュボードの大部分が挙げられています。特定のサイトが動くかどうかを判断する最も速い方法は、公開 playground に URL を入れて試すことです。

体験方法とオープンソース計画

パブリックベータは無料：現在 Cloudflare の Browser Run プロダクト内で無料テストを公開中です。アカウントごとにクォータ（利用枠）があります。使い方は、API にパラメータを 1 つ追加するだけです：

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://example.com"}' \
  --output "screenshot.png"

オンライン Playground：公式が公開している kitesurf.cloudflare.app にアクセスすれば、任意の URL を入力して Kitesurf のレンダリング結果を直接確認でき、操作も可能です。

ここにしかないものがあります。Chrome DevTools をインターフェースに組み込んだのです。しかも Memory パネルに必要な CDP コマンドを特別に実装したので、各隔離環境（各フレーム含む）の WebAssembly 使用量を見ることができます。

公式が挙げている進行中の 4 つの取り組み：より完全な CDP カバレッジ、スクリーンショットと PDF のレンダリング忠実度（理由は、AI はテキストより画像を見たほうが効果的なことが多いから）、さらなる WPT カバレッジ、そして効率性です。CPU、メモリ、ウォールタイムのベンチマークは常時実行されています。

オープンソース計画：「準備ができたら、できればすぐにでも」Kitesurf をオープンソース化する予定とのこと。目標は、顧客が自分のアカウントに自分の分をデプロイできるようにすることです。

初版は AI エージェントがオープンソースエンジン obscura を移植したもので、最初は動きませんでした。しっかりした計画と、延々とループし続けられるほど明確な成功定義を与えたところ、使えるプロトタイプができました。これほど複雑なプロジェクトを AI に書かせて品質を制御不能にしない方法、それは「自動で採点できる標的」を与えることです。

標的は Web Platform Tests。ブラウザがウェブ標準を正しく実装しているかを検証する公開テストスイートです。AI がコードを変更し、テストを実行し、スコアを受け取り、さらに変更する。人間はどの機能をテストすべきかを選び、アーキテクチャと方針を確認するだけ。テストでは実際のウェブサイトの使い勝手は測れないため、もう 1 層追加しました。Chromium と Kitesurf を同時に実行して同じサイトにアクセスし、レンダリング画面を 1 枚ずつ比較するのです。

以下の数字は Cloudflare の自己測定です。シナリオはスクリーンショットと HTML 抽出。比較相手は「熱いプール」で待機中の Chromium。第三者による再現はまだありません。同じ 2 つの作業で、Kitesurf は CPU とメモリを大幅に節約できる一方、待ち時間は長くなります。

Kitesurf の位置づけは「短命・完全隔離・ステートレスなエンジン」です。1 つのタスクの時間だけ存在し、波のように押し寄せる AI 負荷に適しています。Chromium の下に、もう 1 つの安価な選択肢を加えるイメージです。

現在、Wikipedia、Hacker News、Cloudflare ブログとダッシュボード、TodoMVC の各フレームワーク版を正常にレンダリングできます。特定のサイトが動くかどうかは、kitesurf.cloudflare.app に URL を入れて試すのが最も速い方法です。パブリックベータは無料で、アカウントごとのクォータがあります。オープンソース化も計画されており、顧客が自分のアカウントに自分の分をデプロイできるようになることを目指しています。