DocsDigest
Back to listLanguage: JA
OpenAICloudflareMay 13, 2026, 1:00 PM

Browser Run: now running on Cloudflare Containers, it’s faster and more scalable

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

Browser Run: now running on Cloudflare Containers — faster and more scalable

cloudflare-containersdurable-objectsd1queuesworkersheadless-browserbrowser-run

Key Points

  • 120 concurrent browsers (4× increase)
  • Quick Actions over 50% faster
  • State moved from KV to D1+Queues with 100-row batching

Summary

Browser Run has been rebuilt on Cloudflare Containers (Durable Object-enabled) and is live with no customer changes required. Engineers get higher throughput, lower latency, and better reliability: you can spin up 60 browsers/min via the Workers binding and run up to 120 concurrent browsers (4× previous limits). Quick Action response times dropped by more than 50%, and the team can ship fixes and features faster thanks to dedicated container images.

Key Points

  • Migration approach: gradual dual support (Containers + prior Browser Isolation) via a Worker proxy, validate per-plan, then roll out globally without requiring customer redeploys.
  • Capacity & limits: 60 browsers/min acquisition through Workers binding; 120 concurrent sessions; Quick Actions now >50% faster.
  • Latency strategy: use regional pools of pre-warmed DO-backed containers to minimize user→DO and DO→container hops and reduce WebSocket/RTT penalties.
  • State management: moved from Workers KV (eventual consistency) to transactional D1 + Queues to eliminate race conditions when claiming browsers.
  • Batching & throughput: containers write state every 5s into a location queue; consumers batch writes (100 rows, 1s max timeout) to D1 — this enables scaling to ~500k containers per location and yields a P95 batch write of ~0.1ms.
  • Operational fallbacks: region-specific queue backlogs fall back to a designated backup region until queues catch up.
  • Developer impact: faster browser upgrades and new capabilities (WebGL, WebMCP); Browser Run available on all Workers plans; no API or worker changes required.

Practical takeaways for engineers

  • Avoid KV for critical, sub-30s request-path state. Use transactional DBs (D1/SQL) when you need atomic claims.
  • Batch frequent heartbeat/state updates via queues (example consumer: max_batch_size=100, max_batch_timeout=1s).
  • Pre-warm regional pools to constrain cross-region latency for bidirectional or WebSocket-heavy flows.
  • Expect improved throughput and response times out-of-the-box when using Browser Run on Workers.

References: check the Browser Run docs, Quick Actions, /crawl endpoint, and Agents SDK for implementation details.

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

Browser Run：Cloudflare Containers 上で稼働開始 — より高速でスケーラブルに

概要

Browser Run を Cloudflare の Containers 上で再構築したことで、利用上限の拡張、パフォーマンスの向上、信頼性の改善を実現しました。Workers バインディング経由で毎分 60 ブラウザを起動でき、同時実行は最大 120 まで — 従来比 4 倍の上限です。さらに Quick Action の応答時間は 50% 以上短縮されました。利用者側での変更は不要で、これらの改善は本日より有効です。加えて、修正や新機能のリリース速度も向上しています。以下で移行の経緯とデータを紹介します。

まず振り返り：Browser Run とは？

Browser Run は開発者が Cloudflare のグローバルネットワーク上で動作するヘッドレスブラウザをプログラム的に操作・やり取りできるサービスです。主な用途は以下の通りです：

  • Web アプリのエンドツーエンドテスト
  • 疑わしい URL の安全な調査
  • ブラウザを用いた PDF レンダリング
  • スクリーンショット取得やコンテンツ抽出などの Quick Actions

最近では、AI エージェントがウェブと相互作用するための重要な基盤にもなっています。大規模かつ安全に自動ブラウザを責任を持って活用するための主要プラットフォームを目指して開発しています。

旧インフラの限界（“二段ベッド” を超えて）

従来は Browser Isolation（BISO）とインフラを共有していました。見た目は似ていても、BISO の大きなコンテナイメージは起動や開発を遅くし、グローバルな分散配置も最適ではなく、回復力やレイテンシの面で制約がありました。さらに、BISO の典型的な利用は長時間の安定したセッションであるのに対し、Browser Run は短時間で突発的な負荷が多く、スケーリングや可用性におけるボトルネックを生んでいました。

昨年、Durable Object (DO) 対応 Containers のオープンベータが公開され、社内での採用準備が整ったため段階的な移行を開始しました。自社プラットフォーム上でまず自身が Customer Zero として運用することで、外部顧客に先立って課題を検出して対応できる体制を取っています。

移行プロセス：Containers への段階的導入

まずリクエスト経路に Worker を挿入し、BISO のブラウザと並行して一部ユーザーに Containers ベースのブラウザを提供するデュアルサポートで開発を進めました。これによりパフォーマンス比較や実装バグの切り分けが容易になり、Container 駆動アプローチの利点を確信できました。

採用の段階は次の通りです：

  1. Quick Actions のエンドポイントをまず Containers ブラウザで提供
  2. 次に Workers ブラウザバインディング経由で無料アカウントに適用
  3. 続いて pay-as-you-go（従量課金）アカウントで安定性を検証
  4. 最終的に残る契約顧客全てへ展開（顧客側のワーカー再デプロイ等は不要）

課題：新プラットフォームの学習とスケールのボトルネック

初期の Containers プラットフォームはドキュメントや観測性が十分でなく、不安定である側面があり、同時に重複タイムゾーンの技術者が少ないといった運用上の挑戦がありました。しかし、私たちが内部の Customer Zero としてフィードバックを回すことでプラットフォーム自体の改善につながり、外部顧客にも恩恵が波及しています。

技術的なハードルとしては、DO によってリクエストに近い場所に Durable Object を作成できる一方で、実際に接続される Container が世界の別の場所で起動するケースが起きます。単発の "start my app" のようなメッセージなら問題ありませんが、WebSocket を張ってスクリーンショットのために何十通りものメッセージを交換する場合は、地理的距離によるミリ秒単位の遅延が積み重なって影響してきます。

解決策

地域ごとの事前ウォーム済み DO バックドのブラウザコンテナプールを作り、DO とコンテナ間の最大距離（＝最大レイテンシ）を制約する設計にしました。リクエスト時には、そのリージョン内でユーザーに最も近い DO–コンテナペアを選択します。これにより「ユーザー → DO」と「DO → コンテナ」の両方のホップでレイテンシを低く保てます。全体のアーキテクチャには可動部が増えますが、各ブラウザのグローバルな状態を観測できることにより、需要に応じたキャパシティの割当・再割当が可能になり、この設計は有益だと判断しました。

Workers KV は良いところもあるが限界があった

ヘッドレスブラウザへの需要は昨年の頭から急増しており、AI エージェント開発者の利用が急増して既存キャパシティを超えるリクエスト量が発生しました。ここで問題になったのが Workers KV の最終的一貫性（およそ 30 秒）です。KV を確認して "利用可能" と見えても、実際にそこへルーティングするまで（30 秒後）には既に別のリクエストに取られていることがあり、レースコンディションや過剰割当を招いてスパイクへの迅速なスケールを阻害しました。

KV から D1 + Queues への移行

以前は各コンテナの状態を KV に格納していましたが、キャッシュ TTL により最大で 1 分近い古い状態を参照してしまう可能性がありました（最近 KV の最小キャッシュ TTL は 30 秒に変更されましたが、それでも依然高すぎる）。そのため、コンテナ状態を D1（SQLite ベース）へ移行しました。D1 のトランザクション性はここに最適です。ブラウザをユーザーに割り当てたら排他で保持するため、SQLite トランザクションにより原子的な割当が担保され、同一ブラウザを複数リクエストが同時に取得するレースを防げます。

簡略化したブラウザ取得クエリの例は次の通りです：

WITH candidate_pool AS ( -- candidate pool logic to pick based on latency and other rules )
UPDATE containers SET status = 'picked' WHERE sessionId IN (
  SELECT sessionId FROM candidate_pool ORDER BY RANDOM() LIMIT ?5
) RETURNING data

各ロケーションに D1 シャードを配置しており、数千のコンテナが稼働する環境では、各コンテナが 5 秒ごとに状態更新を行うためにデータベースを過負荷にしがちでした。例えば各書き込みが 1ms かかるとすると、1,000 回しか書き込み処理が行えず、1 行ごとの書き込みであれば 5,000 コンテナでデータベースが飽和してしまいます。

そこで書き込みをバッチ化しました。バッチ書き込みは個別書き込みと比べて著しく遅くならないため、スループットを桁違いに向上できます。我々は 100 行単位のバッチを採用し、これによりロケーションあたり最大 500,000 コンテナまで更新可能になりました。この余裕によりキャパシティ計画はもはやボトルネックではありません。現在、バッチ書き込みの P95 は 0.1ms です。

書き込みバッチ化にはQueues を利用しています。各コンテナは 5 秒ごとに自身の状態を算出し、そのロケーション専用のキューへメッセージを追加します。ワーカー側のコンシューマを次のように設定します：

{
  "queues": {
    "consumers": [
      {
        "queue": "production-core-containers-queue-weur",
        "max_batch_size": 100,
        "max_batch_timeout": 1,
        "max_retries": 1
      },
      ...
    ]
    ...
  }
}

この構成により、実効的な遅延は 2 秒を大幅に下回る値を達成しています。ただしキューのバックログが溜まると状態が古くなる可能性があり、その場合は各リージョンが指定されたバックアップリージョンへフォールバックしてプライマリキューの追いつきを待ちます。

Quick Actions に対する追加の利点

専用インフラを持てたことで、BISO など他プロダクトに不要な副作用や肥大化を招かずにブラウザコンテナイメージを改良できるようになりました。これによりスクリーンショットやコンテンツ抽出といった Quick Actions の最適化が可能になっています。

従来は Worker がリモートブラウザへ WebSocket を張り、ページを開く → 指定 URL へ遷移 → 読み込み完了を待つ → スクリーンショット取得、という各ステップを逐次的に指示していました。現在は全パラメータを単一の HTTP リクエストとしてコンテナへ送り、処理全体をコンテナ内で完結させるため、Worker とブラウザ間の往復が削減されて遅延が大幅に低下しました。

結果：大幅な性能向上と上限拡大

  • Quick Action の平均応答時間は著しく減少しました。
  • Workers バインディング経由で毎分 60 ブラウザの起動、同時 120 実行（従来比 4 倍）を達成しました。
  • Quick Action の応答時間は 50% 以上短縮されました。

また、リアルタイム状態管理の課題を克服したことで、新機能開発に注力できるようになり、最近公開した /crawl エンドポイントのような拡張も可能になりました。

ブラウザの柔軟性向上

共有の Browser Isolation コンテナから離れたことで、ブラウザのアップグレードサイクルが高速化しました。以前は Chrome のアップグレードに複数チームやプロダクトの調整が必要でしたが、独自のコンテナイメージであればブラウザのバージョンやフラグを自在に制御できます。その結果、要望の多かった WebGL のブラウザベースレンダリング対応や、WebMCP（Model Context Protocol for the web）といった新しいエージェント的相互作用パターンのサポートが可能になりました。

要するに、ブラウザをスケールさせる力を解放したばかりで、特にエージェント開発の分野ではこれからが本番です。ぜひお試しください — docs をご確認ください。

はじめ方

  • Browser Run はすべての Workers プランで利用可能です。
  • quick start guide から始めるか、Quick Actions を試す、またはサイト内のリンクを辿ってデータを深掘りする /crawl エンドポイントをお試しください。
  • AI エージェントを構築する場合は、Browser Run を組み込んだ Agents SDK をご利用ください。

タグ: server-island-start Developers Developer Platform Browser Run Containers Cloudflare Workers Chrome Agents Browser Rendering Browser Run