エージェントを「試す」段階では見えない問題が、「本番の量で回す」段階でいちばん最初に効いてきます。その一つが、意外にもブラウザです。エージェントに社外サイトを調べさせ、SaaSの画面を操作させ、結果をスクリーンショットで確認する——こうしたWeb操作を数百・数千のエージェントが同時に走らせると、裏で動いているブラウザ（多くはChromium）のコストが無視できない規模になります。
2026年8月、Cloudflareがこの問題に正面から答える製品を公開しました。エージェント専用に設計されたブラウザ「Kitesurf」です（Cloudflare公式ブログ、TechCrunch）。単なる新製品の話ではありません。「エージェントにとってブラウザとは何か」を問い直す動きであり、日本企業がエージェントを本番運用へ乗せるときの実行基盤・コスト・統制の設計に直結します。
Kitesurfとは——「見せない」ことに振り切ったブラウザ
Kitesurfは、CloudflareのサーバーレスプラットフォームWorkers上で、V8アイソレート（軽量な分離実行環境）として動く、ステートレスなヘッドレスブラウザエンジンです。特徴は、できることを大胆に削ったことにあります。
- できること: ページを開く／スクリーンショットを撮る／HTML・DOMを抽出する
- できないこと: タブ表示、ピクセル完全なアニメーション描画、拡張機能の実行
人間が「見る」ための機能を捨て、エージェントが「読む・操作する」ために必要な部分だけを残した、という設計思想です。互換性の指標として、Web Platform Testsを23万5,000件以上通過（DOMサブテスト97%、HTMLサブテスト96%）しており、Web標準の実装としても実用水準にあります。エンジンは既存技術の組み合わせで、レンダリングにBlitz、CSSパーサにFirefox由来のStylo、JS実行にRust製のBoaを採用しています。
現在は開発者向けの「Browser Run」でベータ提供（無償）され、将来のオープンソース化も表明されています。
なぜ専用ブラウザなのか——Chromiumは「人間向け」に重すぎる
Chromiumは優秀なブラウザですが、1人の人間が快適に使うために作られています。エージェントの使い方はまるで違います。
負荷が極端に波打つ（いま1セッション、次の瞬間に1,000セッション）。そのたびに、1インスタンスあたり数百MiBのメモリを食うChromiumを温めておくのは、規模が大きいほど割に合わない。
Cloudflareが示した数字を整理すると、削減効果は明確です。
| 指標 | Kitesurf | Chromium（ヘッドレス） |
|---|---|---|
| CPU使用量 | 約3.1〜3.8倍少ない | 基準 |
| メモリ使用量 | 約4.7〜7.0倍少ない | 基準 |
| 1ページロードのコスト（大規模時の試算） | 約 $0.00089 | 約 $0.0031（ウォーム状態） |
| 実行速度（実時間） | やや遅い | 約1.7〜1.8倍速い |
つまり Kitesurf は**「速さ」ではなく「1セッションあたりのコストとスケール適性」で勝つ**設計です。ステートレスであることが要で、セッションを保持しない＝どのインスタンスでも処理でき、バースト負荷にサーバーレスで追従できる。エージェントを"艦隊（fleet）"で運用する企業にとって、これはFinOps（コスト統制）の論点そのものです。
判断軸はシンプルです。低レイテンシで1件を速く返したいインタラクティブ用途はChromium系が有利。大量のページを継続的に処理するリサーチ・監視・データ収集系のエージェントは、コストとスケールでKitesurf型が効く。用途で使い分ける前提に立つのが実務的です。
移行コストは低い——CDP互換とMCP接続
Kitesurfが現実的なのは、既存のツールチェーンにそのまま差し込める点です。Chrome DevTools Protocol（CDP）互換のエンドポイントを公開しており、Puppeteer・Playwright、そしてMCPクライアントから接続できます。すでにPlaywrightでブラウザ自動化を組んでいるチームや、MCP経由でツールを束ねているエージェント基盤であれば、実行先を差し替える発想で試せます。「専用ランタイムに乗り換える＝作り直し」ではない、というのが普及の鍵になります。
エンタープライズの論点——安くなっても『危険なツール』であることは変わらない
ここで強調したいのは、実行が軽く・安くなることと、安全になることは別問題だという点です。ブラウザはエージェントにとって最も強力で、最も危険なツールです。エージェントが外部ページを読み込む以上、そのページに埋め込まれた指示（プロンプトインジェクション）に誘導されるリスクは残ります。ヘッドレスで使い捨て・ステートレスな実行は、人間のログイン済みブラウザをエージェントに操作させる方式（関連記事）に比べれば被害範囲（blast radius）を絞りやすい一方で、「どこに接続してよいか」「取得した内容を信じてよいか」「その操作を承認するか」を判断する層は依然として必要です。
- エグレス制御: エージェントブラウザが到達できる宛先を許可リストで絞る
- 承認ゲート: 取得だけは自由でも、書き込み・送信・決済など副作用のある操作は人間の承認を挟む
- 監査: どのエージェントが、いつ、どのURLに、何をしたかを追跡可能にする
実行基盤が速く安くなるほど、エージェントは「もっと多くのサイトに、もっと頻繁に」到達します。統制を設計しないまま量を増やせば、リスクも同じ倍率で増える、という当たり前の帰結です。
homulaの観点——実行基盤は選べる。統制は設計するもの
homulaは特定の実行ランタイムに肩入れしません。用途に応じてKitesurf型のサーバーレス・ブラウザも、従来のChromiumも、MCP接続のツールも選べばよい——重要なのは、どの実行面を使っても効く「制御層」を先に設計しておくことです。
homulaのプラットフォームAgensは、200以上のツールと構築ゼロで接続します。ブラウザは、そこに並ぶ数多いツールの一つに過ぎません。だからこそ、接続の数が増えるほど統制が要になります。Agens Controlは、承認フロー・DLP・RBAC・5年分の監査ログを提供し、「エージェントが到達してよい先」「副作用のある操作の承認」「誰が何をしたかの記録」を、ツールや実行基盤の違いを越えて一枚の層でかけられるように設計されています。
導入の順序も実務的に考えるべきです。まずは影響の小さいリサーチ・監視系のエージェントで、コスト効率の良い実行基盤を試し、承認と監査の型を固める。そこで効く統制を確認してから、副作用の大きい業務へ広げる——この順番なら、コスト最適化とガバナンスを同時に前へ進められます。業務の棚卸しからプロトタイプ、ROI試算までを3〜5日で回すAIエージェント・ブートキャンプは、この最初の一歩を短くするための入口です。
まとめ
Cloudflare Kitesurfは、「エージェントは人間と同じブラウザを使わなくてよい」という発想を製品に落とし込みました。ピクセルを描く代わりにDOMを返し、セッションを保持する代わりにステートレスで走り、Chromiumより3〜7倍軽く動く。エージェントを本番の量で回す企業にとって、Web操作は"設定"ではなく実行基盤とコストの設計問題になった——これが今回の本質です。
ただし、安くなったツールは、統制がなければ安いままリスクを量産します。実行基盤は用途で選び、その上に効く承認・監査・権限の層を自分で設計する。ここが、エージェントを"艦隊"で動かす時代の分かれ目です。
エージェントの実行基盤選定と、その上にかける統制設計は、切り離さずに一度に描くのが近道です。homulaが、御社の業務に合った"選べる実行基盤 × 効く統制"の設計をご一緒します。