AI ブラウザKitesurfは無料?料金と利用上限を徹底解説
CloudflareのAI ブラウザKitesurfはベータ期間中なら無料です。ただしWorkers Freeは1日10分、同時3セッション、新規セッションは20秒に1回まで。Browser Runの料金、無料枠で1日10タスクを回す条件、Chromiumとの使い分けを公開情報から整理します。

AI ブラウザのKitesurfは無料で使えるのでしょうか。ベータ期間中は無料です。ただしWorkers Freeで実用できる枠は、アカウントごとにブラウザ時間が1日10分、同時に使えるBrowser Sessionsが3件、新規セッションの開始は20秒に1件までです。範囲を絞ったパイロットには十分でも、エージェント基盤全体を無料で運用できる証明にはなりません。
AI ブラウザKitesurfは無料で使える?
Kitesurfは、ベータ提供中なら無料で利用できます。Cloudflareは2026年9月28日のアップデートでそう明記しています。ただし、アカウント単位のBrowser Run上限がある点も見落とせません。
Kitesurfは、CloudflareがAIエージェント向けに開発したステートレスなブラウザエンジンです。Workers上で動作し、人間向けブラウザの機能を減らす代わりに、エージェント用途に絞った軽量なランタイムを実現しています。現時点でKitesurfエンジン自体に個別料金はありませんが、その外側ではBrowser Runの使用量が引き続き計測されます。

現在のBrowser Runの上限とBrowser Runの料金を並べると、押さえるべき境界は次の4つです。
つまり「無料」という説明は、製品価格への答えにはなっても、必要予算の全体像までは示しません。ベータ期間中にCloudflareがKitesurfへ請求する料金は分かりますが、ワークフローがアカウント上限内に収まるか、Workers Paidが必要か、エージェントのモデル利用料がいくらになるかまでは分かりません。
本ガイドの料金と上限は、2026年9月29日時点のCloudflare公開ページで確認しました。今回のレビューでは認証済みのBrowser Runジョブを実行できなかったため、ダッシュボード上の請求額、処理時間、ツール呼び出し成功率を推測で補ってはいません。
2026年9月28日のアップデートで何が変わったのか
9月のアップデートによって、Kitesurfはより幅広いパイロットで検討できる存在になりました。エージェント開発者がすでに使っているインターフェースと、エンジンが接続されたためです。8月の初回リリースで登場したのはブラウザ本体でしたが、今回は実用に必要な周辺機能が加わりました。
第1に、KitesurfはWebMCPに対応しました。WebMCPは、Webサイトが構造化された入力を持つ名前付きツールを公開するブラウザAPIです。エージェントは画面上のピクセルからボタンを推測する代わりに、サイトのsearchFlights()のような関数を呼び出せます。CloudflareのWebMCPドキュメントによれば、KitesurfはChrome DevTools Protocol(通常はCDPと略されます)を介して、これらのツールを一覧表示し実行できます。
第2に、KitesurfがBrowser Run APIを全面的に利用できるようになりました。CDP、Playwright、Puppeteer、MCPのいずれからでもKitesurfを選択できます。スクリーンショット、HTML、PDFなど一般的な出力を1リクエストで取得するCloudflareのQuick Actionsでも、Workerからenv.BROWSER.quickAction()を呼ぶ際にKitesurfを指定できます。
第3に、Kitty graphics protocolに対応するターミナルならレンダラーを実行でき、Kittyが使えない環境ではプレーンなANSIテキストモードに切り替わります。別のデスクトップブラウザを開かず、エージェント用ブラウザの視点でページを確認するのに便利です。ただし、これは検証を助ける機能であり、新しい本番向け料金プランではありません。
Cloudflareは9月のアップデートで、KitesurfがWeb Platform Testのサブテスト730,000件以上に合格し、リリース時から500,000件以上増えたとも報告しています。互換性が大きく向上したことを示す数字です。ただし、任意の顧客ポータルが正しくレンダリングされる保証ではありません。だからこそ、パイロットでは対象サイトを限定する必要があります。
Kitesurfベータ版の上限:1日10タスクは収まる?
1日10タスクを収めるには、タスク全体で使うブラウザ時間の平均を60秒以下にする必要があります。Workers Freeの枠は10分、つまり600秒です。これを10タスクで割ると、1タスクあたりの上限は60秒になります。
使う式はdaily task ceiling = floor(600 / measured browser seconds per task)です。アプリケーションログの経過時間で代用してはいけません。Cloudflareの料金ドキュメントによれば、Quick ActionsではレスポンスヘッダーX-Browser-Ms-Usedにブラウザ時間が返されます。実運用を予定しているタスクと対象サイトで、この値を記録してください。

制限されるのは時間だけではありません。上限ページによれば、Freeアカウントで同時に実行できるBrowser Sessionsは3件、新規セッションの開始は20秒に1件、Quick Actionsは10秒に1リクエストです。非アクティブ時のデフォルトタイムアウトは60秒です。対応するセッション連携ではkeep_aliveを延長できますが、CloudflareのWebMCPページでは、KitesurfのChrome DevTools MCP設定はkeep_aliveを受け付けないと説明されています。
同じ上限ページには、Freeでの/crawlに関する別の境界も記載されています。クロールジョブは1日5件まで、1クロールは100ページまでです。1つの質問から複数のクロールを走らせるリサーチエージェントでは、ブラウザ時間10分を使い切る前にジョブ数の上限へ達する可能性があります。
セッションを確実に閉じる運用も、処理できる量を左右します。Cloudflareは、開いたままのセッションがタイムアウトするまでブラウザ時間を消費し続けると注意しています。明示的に閉じればNormalClosure、アイドルタイムアウトならBrowserIdleが記録されます。browser.close()をfinallyブロックに置き、コードが後始末したはずだと決めつけず、終了理由まで確認してください。
判断基準は明快です。実測中央値が60秒以下で、レート制限による待ち行列も発生しないなら、10タスクのパイロットは枠内に収まります。収まらない場合は、非効率なループを有料で拡大する前に、対象ページやタスクの範囲を狭めるべきです。
Cloudflare Kitesurfの料金を分ける3つの境界
Kitesurf、Workersアカウント、Browser Runの使用量、推論モデルはそれぞれ別のサービスなので、料金は1つの数字では表せません。すべてを「無料エージェント」の1項目にまとめると、どこから請求が増えるのか見えなくなります。

短いタスクなら、ブラウザの超過料金そのものは現時点では少額です。公表済みのBrowser Run料金では、Workers Paidに含まれる10時間を超えた後でも、60秒のタスク1件は1時間あたり$0.09の計算で$0.0015です。同時実行、Workersのコンピューティング、モデル利用、連携先SaaSの料金はこの金額に含まれません。タスクの長さが均一なら、同じ10時間の枠で1分のブラウザタスクを600件実行できます。
この計算を、ベータ終了後のKitesurf料金の約束と受け取るべきではありません。Cloudflareは、アップデート、Kitesurfドキュメント、Browser Run料金ページ、Workers料金ページのいずれにも、Kitesurf固有のベータ終了後の料金を掲載していません。Workers Paidの最低$5は、Workersアカウントのプラン料金です。将来のKitesurf料金を固定するものではありません。
導入側の予算表では、ブラウザ時間、同時セッション数、Workers、モデル、エージェントが操作する有料システムを別々の行に分けるのが明快です。ブラウザエンジンが無料でも、ワークフロー全体は有料になり得ます。
Kitesurf Browser Runを開発者・運用担当者・導入担当者はどう捉えるべきか
このプラットフォームが向いているのは、範囲を限定したステートレスな処理です。万能なChromium代替ではありません。取るべき対応は役割によって異なります。
開発者:タスクを完了できる最小のインターフェースから始める
必要な出力がスクリーンショット、ページ内容、PDF、構造化データの抽出なら、まずQuick Actionから試すべきです。エンドポイントにbrowser=kitesurfを加え、返されたブラウザ時間を計測し、複数の操作にまたがるナビゲーションや状態保持が必要な場合だけフルセッションへ移行します。
対象サイトが必要な処理をそのまま公開しているなら、WebMCPは魅力的です。壊れやすい画面操作ループを、名前の付いたツールに置き換えられます。ただし、サイト側の実装、権限の境界、結果の妥当性を確認する必要までなくなるわけではありません。
顧客向けセッションを本番運用へ近づける際は、エンジン選択とBrowser Runの制御を組み合わせてください。既存ガイドの許可済みホストと読み取り専用のクライアントレビューでは、ブラウザを選ぶだけでは設定できない接続先の境界を解説しています。
運用担当者:正常時と失敗時を分けて計測する
タスク種別ごとに、ブラウザ使用時間(ミリ秒)、終了理由、リクエスト結果、モデル使用量を記録してください。抽出に成功したケースと、ページがタイムアウトしたケースでは負荷の性質が異なります。まとめて平均を取ると、ブラウザ、サイト、エージェントループのどこを直すべきか見えなくなります。
失敗したジョブは、再実行する前に証拠を保存します。Browser Runの検査ワークフローを使えば、記録済みセッションのコンソール、ネットワーク、最終ページ状態を確認できます。失敗ジョブを再実行前にデバッグするためのガイドでは、すぐ再実行するより証拠を調べた方が有効な場面を説明しています。
導入担当者:互換性を確かめてから処理枠を買う
Freeのカウンターが上限に達したという理由だけでアップグレードすべきではありません。まずKitesurfが対象サイトをレンダリングでき、タスクを正しく完了できるか確認します。そのうえで、ボトルネックが1日のブラウザ時間、リクエストレート、同時実行数、モデルのどれなのかを判断してください。
Cloudflareの現行ドキュメントから、エンジンの使い分けは明確です。互換性のある1回完結型のレンダリングや抽出、負荷が一時的に集中するステートレスなエージェント処理にはKitesurfを選びます。動画、WebGL、実際のTLSフィンガープリントを使うボット対策のハンドシェイク、状態を保持する長時間の認証済みセッションが必要ならChromiumを選びます。

大規模展開の前に、代表的なタスク1つ、対象サイト群1つ、ブラウザ時間の実測分布1つ、明示的なフォールバック1つを用意すれば判断できます。フォールバックが頻繁に発生するなら、小さなエンジンを選んでも運用コストの削減にはなりません。
今すぐ動くべき人、待つべき人、影響の少ない人
今すぐ動くべきなのは、公開ページやリスクの低いページを扱うサポート、リサーチ、QAのワークフロー担当者です。ヘルプセンターのスクリーンショット取得、リリースノートの抽出、レンダリング済みコンポーネントの確認、互換サイト上のWebMCP検索ツール呼び出しなどがパイロットに適しています。いずれも短時間で完了し、監査しやすく、既知の結果と比較しやすいタスクです。
待つべきなのは、ログイン状態の保持、動画、WebGL、ボット対策との互換性、あるいは慎重な扱いが必要なWebMCP操作の無人確認に依存するワークフローです。Kitesurfセッションはwrangler browser listに表示されず、ライブビューもありません。そのためCloudflareによれば、人の確認待ちで一時停止するツールをKitesurfのエージェントセッションから完了させることはできず、その操作には手動プレイグラウンドが必要です。
ベータ終了後まで見据えた予算の確約も、今は待つべきです。現在のブラウザは無料ですが、長期契約や利益率を固定した顧客見積もりに使えるベータ終了後のKitesurf料金は公表されていません。
影響がほとんどないのは、安定したChromium Browser Runワークフローがすでにコストと信頼性の目標を満たしている場合です。9月のリリースによって、評価できるバックエンドが1つ増えました。しかし、正常に稼働している本番ブラウザの移行が必須になったわけではありません。
無料ベータ版について過大評価されている点
エージェント全体を「無料」と表現すると、この言葉に意味を詰め込みすぎてしまいます。無料なのはベータ期間中のKitesurfであり、モデル、運用担当者の工数、接続先SaaS、将来の商用料金まで含むわけではありません。
WebMCPによってブラウザ障害がなくなるわけでもありません。Cloudflareは、現在のKitesurf実装に4つの重要な不足があると説明しています。WebMCPツールの権限ポリシーやオリジンフィルタリングがないこと、iframeやポップアップ内のツールがCDP経由で公開されないこと、Kitesurfセッションにライブビューがないこと、人の確認を必要とするツールをエージェント側で確定できないことです。名前付き関数がピクセル単位のクリックより信頼できるのは、ページが適切な関数を公開し、安全に保護している場合に限られます。
ターミナルレンダラーは可視性を高めるには有用ですが、デプロイ戦略ではありません。開発者がKitesurfの見ているページを確認しやすくなるだけで、ブラウザ時間、同時実行数、モデル料金、サイト互換性は変わりません。
性能についても同じ慎重さが必要です。Cloudflareが公開した中央値ベンチマークでは、14 URLのコーパスに対してQuick Actionを5回実行しています。スクリーンショット取得時のKitesurfはCPUを380 ms使用し、ウォームプールのChromiumは1,173 msでした。メモリ使用量もKitesurfが57.8 MiB、Chromiumが271.0 MiBです。一方、実経過時間はKitesurfの方が遅く、1,148 msに対してChromiumは637 msでした。リソース使用量の少なさは大規模運用で価値がありますが、すべてのリクエストが速く完了するという意味ではありません。
最後に、730,000件を超えるサブテストへの合格は、急速な進歩を示す材料ではあっても、Web全体と完全に互換である証拠ではありません。対象サイトごとの互換性マトリクスの方が、全体のテスト件数よりも実務に役立ちます。
月曜日にやること:範囲を絞ったパイロットを1回実行する
次に行うべきなのは、アーキテクチャの移行ではなく、条件を管理したアカウントテストです。本記事では認証済みBrowser Runリクエストを実行していないため、以下は実測済みの独自ベンチマークではなく、再現可能なパイロット手順です。
公開されている機能を確認する
Cloudflare RadarのKitesurfプレイグラウンドを開きます。DevToolsでApplication > WebMCPを開き、CloudflareがRadarで公開していると説明する
navigate-toやset-locationなどのツールを記録してください。これらが存在しても、対象サイトに同等のツールがある証明にはなりません。代表的なタスクを1回実行する
既存のテストアカウントを使い、コンテンツ取得またはスクリーンショット取得を1回実行します。Cloudflareがドキュメントで示しているスクリーンショットの形式は次のとおりです。
Bashcurl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \ -H 'Authorization: Bearer <API_TOKEN>' \ -H 'Content-Type: application/json' \ -d '{"url":"https://example.com"}' \ --output screenshot.pngまず機密性のない対象で試してください。速度を最適化する前に、出力が正しいかを記録します。
すべての費用境界を記録する
Workersプラン、Quick Actionの
X-Browser-Ms-Used、Browser Run使用量、セッション終了理由、モデル使用量を記録します。Browser Sessionは明示的に閉じ、BrowserIdleではなくNormalClosureになったことを確認してください。無料枠で処理できる件数を計算する
600を、成功した1タスクあたりの実測ブラウザ秒数で割り、小数点以下を切り捨てます。1日10タスクを実行するには、実測平均を60秒以下にする必要があります。モデル料金は別の列に分けたうえで、パイロットがFreeに収まるか、タスクをさらに絞るべきか、Workers Paidに移行する価値があるかを判断します。
この1回の実行で、事業として繰り返すタスクについて不足していた根拠がそろいます。互換性、ブラウザ時間、終了時の挙動、モデル料金です。
エージェント基盤に関する次の料金改定や上限変更を、具体的な運用判断として受け取りたい方は、ニュースレターにご登録ください。
- 最終更新
- 2026年9月29日
- カテゴリー
- Build







