>
>
公開日
2026年8月6日、Cloudflareは「Kitesurf」という新しいブラウザを発表しました。人間ではなくAIエージェントのために設計され、Cloudflare Workers上のV8アイソレートだけで完全に動作する点が最大の特徴です。社内でAIエージェントにWebブラウジングをさせる機会が増えている今、情シスとしてこの動きをどう捉え、何を確認しておくべきかを整理します。
Kitesurfとは何か
Kitesurfは、Cloudflareが開発したAIエージェント専用のブラウザで、Chromiumのようなブラウザエンジンを使わず、Rust実装のコンポーネントをWebAssemblyとしてCloudflare Workers上で動かす設計になっています。現在はBrowser Run（Cloudflareのヘッドレスブラウザ自動化API）の一部として、ベータ期間中は無料で利用できます。
Cloudflareはこれまでも「Browser Run」でChromiumベースのブラウザ自動化を提供してきましたが、AIエージェントによる利用が急増する中で、人間向けに作られたブラウザの overhead（タブ、拡張機能、同期機能、ピクセル単位の描画精度など）がエージェントには不要であるという課題が明確になりました。Kitesurfは、エージェントが本当に必要とする「トークン数」「コンテキストウィンドウ」「スケーラビリティ」「コスト」を優先し、人間向けの機能を思い切って削ぎ落とした設計です。
なぜCloudflareはAIエージェント専用ブラウザを作ったのか
背景にあるのは、AIエージェントがWebブラウジングを必要とする場面が急増している一方で、Chromiumのようなフルスペックブラウザをエージェントごとに1インスタンス割り当てるのはコストが高すぎるという問題です。メモリと計算リソースを大量に消費するため、高性能なAIモデルしかWebにアクセスできない状況を生み、多くのエージェント活用の場を狭めてしまいます。
Cloudflareは、AIがブラウザを使う際の要件は人間と根本的に異なると位置づけています。エージェントはタブやテーマ、拡張機能を必要としない一方、構造化されたデータの取得しやすさやコスト効率を重視します。また、エージェントが訪れるWebページは常に信頼できない入力として扱う必要があり、プロンプトインジェクションのような新しい脅威モデルへの備えも、人間向けブラウザとは異なる優先度で求められます。この認識のもと、Cloudflareは自社のDeveloper Platformの成熟（Dynamic WorkersやWorker間RPCなど）を背景に、12週間でKitesurfの開発に踏み切りました。
Kitesurfの仕組み：3つのコンポーネント
Kitesurfのアーキテクチャは、役割ごとに完全に分離された3つのコンポーネントで構成されており、この「分離」こそが情シスにとって注目すべき設計思想です。
Engine：
唯一の公開コンポーネントで、Chrome DevTools Protocol（CDP）のWebSocket / HTTP APIを提供し、セッション状態を保持します。Puppeteer、Playwright、chrome-remote-interfaceなど既存クライアントがそのまま使える互換性を持ちます。
PageScript：
Dynamic Workersを使い、ページごとに独立したWorkerを起動してHTML・CSSの解析とJavaScript / WebAssemblyの実行を行います。HTML/CSS解析にはRust製のBlitzとStyloを採用しています。
PageRenderer：
計算済みのページオブジェクトから実際の画像（PNG/JPEG/PDFなど）を生成します。ステートを持たない使い捨て設計のため、Engineは失敗したレンダリング処理をいつでも安全に強制終了・再起動できます。
外部のWeb資産（画像、フォント、CSS、JavaScript、Wasmファイル）を取得できるのは「SandboxOutbound」という単一のコンポーネントに限定され、他のコンポーネントは直接ネットワークにアクセスできません。CORSの強制、レスポンスのフィルタリング、Cookieの分離などをこの一点で統制する構造は、社内でエージェントの通信経路を絞り込みたい情シスの発想と近いものです。
パフォーマンス比較：ChromiumとKitesurf
Cloudflareが公開したベンチマーク（14URLのコーパスに対する5回実行の中央値）では、KitesurfはChromiumに比べてCPUとメモリの消費を大幅に抑えられる一方、処理速度（ウォールタイム）はChromiumがまだ優位という結果が出ています。
指標 | Kitesurf | Chromium（ウォームプール） | Kitesurf比較 |
|---|---|---|---|
CPU：スクリーンショット | 380ms | 1,173ms | 3.1倍少ない |
CPU：HTML抽出 | 229ms | 877ms | 3.8倍少ない |
メモリ：スクリーンショット | 57.8MiB | 271.0MiB | 4.7倍少ない |
メモリ：HTML抽出 | 39.4MiB | 273.7MiB | 7.0倍少ない |
ウォールタイム：スクリーンショット | 1,148ms | 637ms | 1.8倍遅い |
ウォールタイム：HTML抽出 | 820ms | 472ms | 1.7倍遅い |
処理速度でChromiumに劣るのは、ページを見た経験のあるJITコンパイラの優位性によるもので、主にラスタライズとJPEG/PNGエンコード部分が要因とされています。一方でCPU・メモリはコストに直結する指標であり、ここで3〜7倍の差がついていることは、エージェント運用のコストを重視する組織にとって意味のある違いです。
情シスが押さえるべきセキュリティ・統制の観点
Kitesurfが体現している設計思想は、社内でAIエージェントにWebアクセスを許可する際のセキュリティ要件そのものを映し出しており、情シスが自社のエージェント統制方針を見直す材料になります。
Cloudflareは開発にあたり「すべてのページ読み込みは信頼できない入力であり、すべてのセッションは新規に始まる」という前提を採用しました。これは、エージェントが訪れるWebページに悪意のあるコードやプロンプトインジェクションが含まれている可能性を常に想定する設計です。社内でエージェントによるWebブラウジングを許可する場合も、同様に「エージェントが取得した外部コンテンツは無条件に信頼しない」という前提を、プロンプト設計やツール権限の設計に反映させる必要があります。
また、Kitesurfは「ステートレスであるほど良い」という原則で作られており、失敗したセッションは状態を持たないため復旧コストが低い一方、10分を超えるような認証済みセッションの保持や永続的な状態管理にはまだ対応していません。裏を返せば、エージェントに長時間の認証済みセッションを持たせる用途（社内システムへのログイン状態を保ったままの操作など）は、現時点のKitesurfの想定外の使い方であり、既存のChromiumベースの仕組みを使う判断が必要になる場面です。この境界線をどこに引くかは、まさに情シスが権限設計として決めるべき部分です。
導入前に確認すべきチェックポイント
Kitesurfのような「エージェント専用ブラウザ」を業務で使う、あるいは社内のAIエージェント基盤の一部として検討する場合、次のような観点を事前に洗い出しておくと判断がぶれません。
アクセス範囲の統制：エージェントがブラウジングできるドメイン・URLの範囲をどう制限するか。社内システムへのアクセスを許可するかどうかを個別に判断する。
取得コンテンツの扱い：エージェントが取得したWebコンテンツをそのままプロンプトに渡す設計になっていないか、プロンプトインジェクション対策が入っているかを確認する。
ログと監査性：どのエージェントがいつどのURLにアクセスし、何を取得したかを追跡できるログ設計になっているか。
認証状態の扱い：ログインが必要なサービスへのアクセスを前提にする場合、永続セッションを扱えるのか、都度認証が必要になるのかを確認する。
対応範囲の限界：動画再生、WebGL、実TLSフィンガープリントを使うボット判定の回避など、Kitesurfが現時点で対応していない領域を業務要件と照らし合わせる。
料金・提供形態の変化：無料ベータである現状から、将来的に有料化・提供条件の変更が入る可能性を踏まえてロードマップを追う。
これらは、社内で導入するAIエージェントツール全般を評価する際のAIエージェント比較の選定基準とも重なる部分が多く、単体ツールとしてではなく、既存のエージェント統制フレームワークの中に位置づけて検討するのが実務的です。
情シスとしての活用シーン
Kitesurfそのものを直接導入するかどうかとは別に、情シスが押さえておくべきなのは「エージェントにブラウザを持たせる」という選択が社内で広がっていくという流れです。営業支援ツールがWebから企業情報を自動収集する、QA用のエージェントが社内システムの画面をチェックする、リサーチ用のエージェントが競合情報をまとめるといった用途は、すでに多くの現場で使われ始めています。
こうした用途は、MCP（Model Context Protocol）を通じて外部ツールと連携するAIエージェントの利用拡大と地続きの動きです。ブラウザという「Webそのものにアクセスできるツール」がエージェントに組み込まれると、従業員が個別に契約・利用するSaaSツールと同様に、情シスが把握していないアクセス経路（シャドーAI的な状態）が生まれるリスクがあります。エージェントのWebアクセスを許可制にする、アクセス先をログとして残す、といった運用ルールを、既存のSaaS統制の延長として設計しておくことが望まれます。
現時点の制約と使いどころの見極め
Kitesurfは発表から12週間の若いプロダクトであり、Cloudflare自身も「動画再生、WebGLレンダリング、実TLSフィンガープリントを使うボット判定の回避、10分を超える認証済みセッションが必要な用途にはまだ向かない」と明言しています。対応しているのはTodoMVCやWikipedia、Hacker News、Cloudflareブログなど比較的構造がシンプルなページで、複雑なWebアプリケーションへの対応はこれから拡大していく段階です。
情シスとしては、「今すぐ全社のエージェント基盤をKitesurfに置き換える」という判断ではなく、まず自社のエージェント運用でどの程度Webブラウジングへの依存があるのか、どのユースケースであればステートレスな軽量ブラウザで十分なのかを棚卸しすることが先になります。過去に取り上げたOpenAIのAIモデル暴走インシデントのように、エージェントが想定外の権限や経路を使って動いてしまう事例は今後も増えると考えられるため、ブラウザという新しいアクセス経路が増えるたびに、権限設計を見直す運用を定着させておくことが重要です。
よくある質問（FAQ）
Q. Kitesurfは今すぐ使えますか？
A. Browser Runのベータ機能として無料で利用できます。既存のPuppeteerやPlaywrightのクライアントから、エンドポイントにbrowser=kitesurfパラメータを追加するだけで利用できる設計です。
Q. Kitesurfを使うとセキュリティが自動的に強化されますか？
A. いいえ。Kitesurfの設計思想（ステートレス、アイソレーション、信頼できない入力としての扱い）はセキュリティ上有用ですが、社内でエージェントに何を許可するかというアクセス制御・ログ設計は、利用する側の責任です。
Q. Chromiumベースの仕組みを完全に置き換えるものですか？
A. 現時点では置き換えではありません。動画再生やWebGL、長時間の認証済みセッションが必要な用途にはChromiumベースの既存機能（Browser Runの標準機能）を使う想定で、Cloudflare自身もそのように案内しています。
Q. オープンソース化される予定はありますか？
A. Cloudflareは将来的にKitesurfをオープンソース化し、企業が自社アカウント上に独自のインスタンスをデプロイできるようにする方針を示していますが、具体的な時期は明言されていません。
まとめ
Kitesurfは、AIエージェントのWebブラウジングという新しい需要に対して、Cloudflareがコストと安全性の両面から答えを出そうとした試みです。情シスにとって重要なのは、Kitesurfというプロダクト単体の評価だけでなく、「エージェントにブラウザという新しいアクセス経路を持たせる」という変化そのものに、既存のSaaS統制・シャドーAI対策の考え方をどう当てはめるかという視点です。Adminaのシャドーit検知機能やセキュリティ機能で可視化してきた「情シスが把握していないアクセス経路」の問題は、AIエージェントの時代にも形を変えて現れています。新しいツールが登場するたびに、権限・ログ・監査の3点を確認する運用を定着させることが、変化の速いAI領域で情シスが主導権を持ち続けるための土台になります。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
