Michael Johnsonページを読む、あるいはスクリーンショットを撮るだけなら、すべてのAIエージェントが完全なChromiumを起動する必要はあるのでしょうか。2026年11月12日、Cloudflareはこのような自動化タスク向けの実験的ブラウザーエンジン、Kitesurfのソースコードを公開しました。ローカルで実行するか、自分のCloudflareアカウントにデプロイできます。主なトレードオフは、CPUとメモリーの消費を抑える代わりに、処理時間が長く、サイトとの互換性が限られることです。
ブラウザー自動化の開発者にとって、これは有用な選択肢です。使い慣れたChrome DevTools Protocol（CDP）インターフェースを維持しながら、エンジンを調査・改変できます。ただし、必要なページで動作を確かめてからシナリオをKitesurfに移行するべきです。Cloudflareが公開した比較では、テストタスクの完了速度はChromiumのほうが速く、Kitesurfは現在、ウェブの重要な機能の一部に対応していません。
11月12日に変わったこと
Kitesurfは2026年10月6日、ベータ版として提供されていたBrowser Runのコンポーネントとして初めて紹介されました。当時、Cloudflareはアーキテクチャーと自社テストの結果を説明していましたが、11月12日にApache 2.0ライセンスでコードを公開しました。これにより、エンジンを調査し、ローカルでビルドし、自分のアカウントのインフラにデプロイできるようになりました。実装へのアクセスは広がりますが、それだけで実験的なブラウザーがChromiumの代替になるわけではありません。
プロジェクトには、実行方法が2つあります。ローカル開発にはNode.js 22以降、pnpm 9.15.4、Bazeliskが必要です。プロジェクトの手順では、リポジトリーをクローンして依存関係をインストールし、pnpm run devでビルドを実行します。CloudflareへのデプロイにはWorkers有料プランが必要です。エンジンはページを分離するためにDynamic Workersを使用します。セルフホストする場合は、別途認証を設定する必要があります。Kitesurfには認証機能が組み込まれていないため、Workerの公開アドレスを第三者が利用すると、あなたのアカウントの計算資源や外向きリクエストを使われるおそれがあります。
Chromiumなしでブラウザーを動かす仕組み
通常のヘッドレスブラウザーは、ウェブサイトやユーザーインターフェース向けに設計された大規模なエンジンを起動します。Kitesurfは、自動化に必要な機能を複数のWorkersコンポーネントで構成します。1つはCDP接続を受け付けてセッション状態を保持し、別の分離プロセスがページを処理し、さらに別のコンポーネントが描画を担当します。開発者ツールとの連携にはCDPをサポートしているため、Puppeteerなどの互換クライアントを接続できます。
HTMLとCSSはRust製コンポーネントで処理され、ページのJavaScriptは分離されたWorkers環境で実行され、別のレンダラーが画像を生成します。Cloudflareの説明によると、ネットワークリクエストは専用コンポーネントを経由します。このコンポーネントがサイトのリソースを読み込み、ネットワークポリシーを適用し、ページごとにCookieを分けて保存します。エージェントは信頼できるとは限らないコードを含む任意のサイトを開くため、分離はブラウザー設計の一部です。
このアーキテクチャーは、「タスクを実行し、ページを処理し、終了する」という負荷のパターンに適しています。レンダラーが応答しなくなった場合、停止して作り直せます。ページ状態はレンダラーに保存されないためです。この方法は、自動化が集中する状況では、常時稼働する重いプロセスより扱いやすい可能性があります。ただし、これはプロジェクトの設計上の狙いであり、あらゆるユーザー環境で具体的な節約が保証されるわけではありません。
コストを抑えられる理由
Cloudflareが以前公開した比較では、14個のURLを使ったBrowser Runの実行5回分の中央値を用いています。スクリーンショットの作成時、Kitesurfのメモリー使用量は57.8 MiBで、ウォームプールのChromiumは271 MiBでした。HTML抽出ではKitesurfが39.4 MiB、Chromiumが273.7 MiBでした。これらの数値は、同社の特定の構成とページ群を対象としたものです。あらゆるサイトに当てはまる普遍的な倍率ではなく、特定の負荷を測定した結果として捉えるのが適切です。
同じタスクで、処理時間はChromiumのほうが短く、スクリーンショットの作成は637ミリ秒に対してKitesurfが1,148ミリ秒、HTML抽出は472ミリ秒に対してKitesurfが820ミリ秒でした。つまり、Kitesurfの優位性は主にリソース消費にあり、応答速度ではありません。短時間で大量のページを収集する場合は、メモリーのコストが数秒の遅延より重要かもしれません。一方、素早い応答が必要な対話型エージェントでは、速度差の影響が上回る可能性があります。Cloudflareは測定方法と結果を公開しています。
KitesurfとChromiumの使い分け
Kitesurfは、互換性のあるサイトでHTMLを取得し、DOMを構築し、スナップショットを撮影したりPDFを生成したりする単発タスクに適しています。CDP互換性により、既存の自動化スタックで代替手段を試せます。また、ソースコードを通じて動作やデプロイ要件を調査できます。小規模な実験ならローカルビルドから始められます。Cloudflare上で運用する場合は、有料プランが必要なことを考慮し、インスタンスを認証で保護してください。
動画やWebGLを使うサイト、長期間の認証済みセッション、ボット対策への安定した対応、ページの正確な表示が求められる場合、CloudflareのドキュメントはChromiumベースの標準的なBrowser Runブラウザーを推奨しています。Kitesurfは現時点で、動画再生、WebGL、状態を保持する長時間セッションに対応していません。標準への対応とレンダリング品質は、引き続き改善されています。
標準への準拠と実際の互換性には、有用な違いがあります。Web Platform Testsはウェブ標準の個々の要件を検証しますが、特定の複雑なサイトが読み込めるか、エージェントがそこで一連の操作を正しく実行できるかまではわかりません。実用上は、必要なページとシナリオを実際に動かし、Chromiumと結果を比較することが重要です。合格したテストの総数だけから互換性を推測すべきではありません。
チームが取るべき実践的な判断
Kitesurfは、ブラウザータスクを実行するための特化型オプションとして検討してください。まず実際に使うページをいくつか選び、抽出データやスクリーンショットの正確さ、実行時間、リソース消費の3点を測定します。次に、認証、ネットワーク制限、セッションの挙動を個別に確認してください。タスクが短く、サイトに互換性があり、遅延よりもメモリーとCPUが重要なら、Kitesurfを試験導入する価値があります。正確な描画、豊富なウェブ機能、または状態の継続が重要なら、Chromiumを出発点とするほうが適切です。
ソースコードの公開によって、軽量な特化型エンジンと完全なブラウザーのどちらを選ぶかという構図自体が変わったわけではありません。変わったのは、前者を自分で検証し、デプロイできるようになったことです。これにより各チームは、ベンダーの比較表だけに頼らず、自社のページとインフラで評価しやすくなりました。
