Cloudflareは、AIエージェント向けブラウザエンジン「Kitesurf」のソースコードをApache 2.0ライセンスで公開した。Webページを読み込み、JavaScriptを実行して画面を画像にするエンジンで、Chromeのコンテナーを立ち上げずにCloudflare Workers上で動く。ブラウザを外部から操作・検査するChrome DevTools Protocol（CDP）を通じて、Puppeteerなどから接続できる。

同社は8月6日のベータ公開時にオープンソース化を予告し、11月12日の変更履歴で公開を告知、13日のブログで内容を詳しく説明した。従来のBrowser Run管理APIに加え、取得したコードを手元で試し、自分のCloudflareアカウントへ配備する道が開いた。一方、自前で動かすには実行基盤の条件を満たし、外部からの接続を自分で守る必要がある。

AD

利用形態別の比較表

Kitesurfは、人間がタブや画面を操作するブラウザというより、自動化ツールから指示を受けてWebページを処理するためのエンジンだ。Cloudflareが提供するBrowser Run管理APIを使う経路に対し、公開コードを取得すれば、内部の実装を調べたり変更したりできる。変更したコードはローカルで試すほか、自分のWorkersへ配備することも可能になった。

利用形態 実行場所・入口 開始方法 利用時に整える条件
管理API Cloudflareが提供する管理API Browser Run管理APIを使う 提供APIの条件に従う
ローカル開発 手元の開発環境、wrangler dev コードを取得し、依存関係を導入して起動 Bazelisk、Node.js 22以上、pnpm 9.15.4など
自己配備 自分のCloudflare Workersアカウント pnpm run deployで配備 Workers Paidプランと接続を保護する認証設定

注：2026年11月の公開時に示された利用経路と開始条件の比較。公開発表、README、変更履歴に基づく。

管理API、ローカル開発、自分のCloudflareアカウントへの配備では、実行場所と運用者の責任が異なる。自己配備では有料プランと外付け認証の双方が条件となる。Apache 2.0による本体コードの公開と、Workersで動かす際の契約や認証は別々に考える必要がある。

RustとWasmで組み直したブラウザの中身

公開された実装は、接続から描画までを三つの役割に分けている。Engineがセッションとクライアント接続を管理し、PageScriptがページとそのJavaScriptを実行、PageRendererが描画を担当する構成だ。リポジトリのpackagesにはRustのコア、DOMの代替実装、レンダラーやCLIが分かれて置かれている。

ページの処理を追うと、BlitzがHTMLを解析してDOMを構築し、レイアウトや描画を担う。CSSの解析や、複数の指定を組み合わせたスタイルの計算にはStyloを使う設計だ。さらにLinebenderのライブラリが文字組みと2D描画を支え、KrillaがPDF出力を担当する。Rustで書かれた部品をWebAssembly（Wasm）へコンパイルし、WorkersのAPIと組み合わせて動かす。

JavaScriptの実行にも役割分担がある。ページのJavaScriptはPageScript側で扱い、Dynamic Workersで実行できない場合の最後の手段としてJavaScriptエンジンのBoaを使う。Cloudflareは8月の設計説明で、Workersではネイティブのevalを実行できないためBoaを利用すると説明していた。ページ内で動的にコードを評価する処理を扱うための補完経路がある、ということだ。

開発者は各部品のコードを読んで変更できるが、配布物全体のライセンスは一種類にそろっているわけではない。Kitesurf本体はApache 2.0で公開され、依存ライブラリやフォント、データにはそれぞれのライセンスが残る。例えばStyloはMPL-2.0、BlitzはMITまたはApache-2.0で、付属のNOTICEに通知が記載されている。再配布や改変にあたっては、使う部品ごとの条件も確認する必要がある。

AD

自己配備では接続を許す相手も自分で決める

ローカルで試すには、READMEに示されたビルド環境が出発点になる。Bazeliskをbazelとして導入し、Node.js 22以上とpnpm 9.15.4を用意する。macOSではGNU tarも必要だ。リポジトリを取得後、pnpm install --frozen-lockfileで依存関係を導入し、pnpm run devを実行すると、RustとWasmのビルドに続いてwrangler devが起動する。

初回のビルドには時間がかかり、以降はキャッシュが使われる。ローカルでは127.0.0.1:8787で待ち受け、READMEにはPuppeteerから接続してページを開き、スクリーンショットを保存する例が載る。これらは公開手順に基づく説明であり、今回、実際の起動や配備は試していない。

自分のCloudflareアカウントへの配備にはpnpm run deployを使う。Kitesurfはページごとに独立したWorkerを生成するため、Dynamic Workersが必要で、その利用にはWorkers Paidプランが要る。コードが公開されていても、公式に示されたこの配備経路の実行資源には利用条件がある。

そして、配備したエンジンへの接続を誰に許すかは運用者の仕事になる。Cloudflareは変更履歴で「Kitesurfには認証が組み込まれていない」と注意を促した。workers.devのURLは既定で公開され、名前のパターンも推測できる。URLへ接続した相手はDevToolsやCDPを使えるほか、配備者のアカウントから外部へ通信し、CPUやDynamic Workersの有料資源を消費できてしまう。

READMEはCloudflare Accessなどで配備URLを保護するよう案内している。プレビュー用のVersion URLsも公開されるため、保護の対象に含める必要がある。配備してからAccessを設定するまでには公開される時間が生じるが、事前にアカウントの全Workers向けにAccessを有効化しておく方法も示されている。

Accessを有効にすると、今度は自動操作側にも認証が要る。通常のブラウザでログインして得るセッションを持たないCDPクライアントは、そのままでは遮断されるためだ。READMEが示すPuppeteerの方法では、Accessのサービス・トークンを発行してService Authポリシーで許可し、WebSocket接続時にCF-Access-Client-IdとCF-Access-Client-Secretをヘッダーとして渡す。トークンはサインインした利用者と同等の権限を持つため、秘密情報として管理する必要がある。

採用の判断は対象サイトと自動化処理から

CDPを使うことで既存の自動操作ツールから接続する経路はできる。READMEのPuppeteer例では、ローカルのCDPエンドポイントに接続し、newPageでページを作成、gotoで開き、screenshotの後に切断する。ただしKitesurfはCDPエンドポイントを提供するものの、Chrome全体を実装したものではなく、Chrome DevToolsの一部機能には対応していない。Cloudflareは、エンジンが実験段階にあり、活発に開発中だと位置付けている。

したがって、接続できたかどうかに加え、運用したいサイトで一連の処理が完了するかを確かめたい。ページの表示やJavaScriptの動作、操作結果を既存スクリプトで試し、スクリーンショットの再現度も確認することが採用判断につながる。CloudflareはフルブラウザよりCPUとメモリの使用を減らすことを目標に掲げる一方、今回の配布コードについて新たな性能測定や個別ワークロードの運用費は示していない。必要な処理が成立することを確認したうえで、その処理に要する時間と資源を測るのが次の段階だ。

Cloudflareは互換性、信頼性、効率の改善を重点に挙げ、再現できるページや失敗する自動化手順、文書の修正を歓迎している。貢献する場合はissueを作成し、メンテナーのvouchを得てからプルリクエストを開く手順だ。対象サイトで再現できる失敗を開発側へ返せれば、自分の用途に合うかを見極めながら、公開されたエンジンの改善にもつなげられる。