Cloudflare、AIエージェント向けブラウザーエンジン「Kitesurf」をオープンソース化

Cloudflareは2026年11月13日、AIエージェント向けの実験的なブラウザーエンジンであるKitesurfを、Apache 2.0ライセンスの下でオープンソースとして公開したと発表しました。開発者はコードを調査・変更し、ローカルで実行したり、Cloudflare Workers上に独自のインスタンスをデプロイしたりできます。

公開リポジトリを利用すれば、管理型のBrowser Run APIだけに頼らず、開発者自身のCloudflareアカウントでエンジンを運用・変更できます。Cloudflareは、2026年8月6日にKitesurfを発表した際にこの方針を示しており、さらに2026年9月28日のアップデートでも改めて表明しました。このアップデートでは、WebMCPのサポート、ブラウザーAPIとBrowser Runの対応範囲の拡大、ターミナル描画機能の導入が行われました。

Kitesurfのエージェントに特化した設計の内部

Kitesurfは、Chromeやブラウザーコンテナを使わずに、HTMLとCSSから描画済みのページを生成し、ページ上のJavaScriptを実行してスクリーンショットを作成します。Chrome DevToolsと互換性のある自動化ソフトウェアが使用する制御インターフェース、Chrome DevTools Protocol (CDP)のエンドポイントを公開しており、PuppeteerクライアントやAIエージェントの実行環境から接続できます。

内部では、Engineがブラウザーセッションとクライアント接続を調整し、PageScriptがページとそのJavaScriptを実行し、PageRendererが視覚的な出力を生成します。Cloudflareの開発者向けプラットフォームに、WebAssemblyにコンパイルされたRustコンポーネントを組み合わせています。BlitzはHTMLの解析、DOM、レイアウト、描画を担い、StyloはCSSを処理します。Linebenderのライブラリーはテキストと2Dグラフィックスを扱い、KrillaはPDFを生成します。ページのコードをDynamic Workersで実行できない場合、BoaがWebAssembly内で代替のJavaScriptランタイムを提供します。

Cloudflareによると、設計上の目標は、フル機能のChromiumブラウザーよりもCPUとメモリーの使用量を抑えながら、エージェントが必要とするウェブへのアクセスを提供し、Workersネットワーク全体で需要に応じて規模を拡大できるようにすることです。当初のアーキテクチャでは、すべてのページ読み込みを信頼できない入力として扱い、必要なリソースに応じてコンポーネントを分離します。専用のSandboxOutboundワーカーがすべての外部へのデータ取得を担い、ネットワークポリシーを適用するとともに、ページごとにCookieを分離します。他のコンポーネントがネットワークに直接アクセスすることはできません。

無状態性も、この設計の一部です。Engineはセッション状態を保持する一方、可能な限り他のコンポーネントを破棄可能にすることで、エージェントの活動が急増した際にも、需要に合わせて処理能力を調整できます。PageRendererはページの永続的な状態を保持しないため、描画要求が失敗したり停止したりした後に、EngineがPageRendererを置き換えられます。

セルフホスティングの要件とセキュリティ

ローカルでの開発には、Bazelisk、Node.js 22以降、pnpm 9.15.4が必要です。開発用コマンドを実行すると、WebAssemblyモジュールとページ用・レンダラー用のバンドルがビルドされ、その後、127.0.0.1:8787でローカルエンジンが起動します。初回のビルドではRustのコアとベンダー提供の依存関係をコンパイルしますが、2回目以降のビルドではBazelのキャッシュを再利用します。その後、開発者はChrome DevToolsでページを調査したり、PuppeteerなどのCDPクライアントを接続したりできます。

CloudflareへのデプロイにはWorkers有料プランが必要です。Dynamic Workersが、ページやレンダラーに使用する分離されたワーカーを作成するためです。ローカルでのテスト後、運用者は管理型のBrowser Run APIに代えて、自身のアカウントにエンジンをデプロイできます。

セルフホスティングでは、重要なセキュリティ上の責任も運用者に移ります。エンジン自体には認証機能がなく、workers.devのアドレスは初期設定で公開されています。Cloudflare Accessなどの認証レイヤーを設けなければ、URLを知っている人なら誰でもエンジンを通じてブラウジングし、CDPクライアントを接続し、運用者のCloudflareアカウントを通じてリクエストを発行し、有料のCPU時間やDynamic Workersを消費できます。リポジトリでは、運用者にURLを直ちに保護するよう求めており、公開状態になる時間を避けるため、デプロイ前にアカウント全体でAccessを有効にする方法も説明しています。

実験段階の現状とコントリビューションの手順

Kitesurfは現在も実験段階にあり、活発に開発が進められています。リポジトリでは、完全なChrome実装ではなくCDPエンドポイントとして説明されており、Chrome DevToolsの一部機能はまだサポートされていません。Cloudflareは互換性、信頼性、効率性を優先しています。

8月の公開時、Cloudflareは、Kitesurfは動画、WebGL、実際のTLSフィンガープリントを必要とするボット対策チャレンジのハンドシェイク、または永続的な状態に依存する長時間の認証済みセッションには、まだ適していないと説明しました。こうした制約は、軽量なブラウザーのリソース使用量が魅力的な場合でも、エージェントのワークロードで引き続き重要となる互換性の確認事項を示しています。

コントリビューションの手順は、こうした継続的な開発に合わせて整備されています。Cloudflareは、コントリビューションを検討している人に対し、最小限の再現手順または提案するアプローチを添えてissueを作成し、プルリクエストを送る前にメンテナーから推薦を得るよう求めています。テストを含み、対象範囲が明確な、焦点を絞った変更が望まれますが、再現可能な描画の不具合、自動化ワークフローの失敗、ドキュメントの修正も歓迎されます。

開発者にとってのトレードオフは、ブラウザースタックを直接制御できる一方で、デプロイのセキュリティを自ら確保し、Chromeおよびウェブプラットフォームとの互換性がまだ完全ではないエンジンに対応する必要があることです。