クロールの進捗をポーリングで見るのをやめる。Browser Run が Queues へイベントを流せるようになった

要約

Cloudflare は 2026-09-25、Browser Run のクロールジョブがライフサイクルイベントを Cloudflare Queues へ配信できるようにしました。

配信されるイベントは3種類です。crawl.started、crawl.updated、crawl.finished です。開始、進行中の更新、完了の3点を取れます。

購読はアカウント単位で作成し、Wrangler CLI から設定します。

npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

これまで、クロールの進捗を知るにはポーリングが必要でした。 ジョブを投げて、ステータスを繰り返し問い合わせて、完了したかどうかを確認する。公式は今回の変更を “without requiring continuous polling mechanisms” と説明しています。

ポーリングが厄介なのは、実装が面倒だからではありません。 サーバーレス環境では待っている間も実行時間を消費するからです。クロール完了を待つコードは、待っている間ずっと動いています。長時間かかるジョブでは、リクエストの実行時間上限に先にぶつかります。 結果として「投げて忘れる、あとで別の経路で確認する」という設計を自前で組むことになり、その別の経路をどう作るかが毎回の設計課題でした。

イベント購読は、そこを埋めます。ジョブを投げたら終わり。 完了は Queues にメッセージが届くことで知り、後続処理はそのメッセージを消費する Consumer Worker として書きます。 クロールの実行時間とリクエストの実行時間が切り離されます。

crawl.updated が含まれている点も見ておく価値があります。開始と完了だけでなく、進行中の更新が取れます。 長時間ジョブの途中経過を利用者に見せる、あるいは想定より遅いことを検知する、といった使い方ができます。

ペイロードの例とスキーマは、Browser Run のイベントスキーマのドキュメントに示されています。提供範囲の制限は告知に記載がありません。

何が変わったか

• Browser Run のクロールジョブが crawl.started / crawl.updated / crawl.finished を Cloudflare Queues へ配信できるようになった
• 購読はアカウント単位。npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events ... で作成
• ポーリングなしで進捗追跡と後続ワークフローの起動ができる
• crawl.updated により進行中の更新も取れる
• ペイロード例とスキーマは Browser Run のイベントスキーマのドキュメントに記載
• 提供範囲の制限は告知に記載なし

業務インパクト（一般企業向け）

該当するのは、社内でクロールを回している組織です。 競合サイトの価格収集、自社サイトのリンク切れ検査、公開情報の定期取得、RAG のためのドキュメント収集。Browser Run を使っているなら、完了待ちの実装を見直す余地があります。

効くのは、失敗の検知です。 ポーリングで完了を待つ実装は、ポーリング側が落ちると完了に気づけません。 ジョブは終わっているのに後続が動かない、あるいは逆にジョブが失敗しているのに気づかないまま古いデータを使い続ける。イベント駆動にすると、届いたメッセージが処理されたかどうかを Queues 側で追えるため、取りこぼしの把握が構造的にやりやすくなります。Queues は再試行とデッドレターの仕組みを持つため、後続処理が失敗したときの扱いも自前で書かずに済みます。

設計の観点では、ジョブと後続処理の疎結合化です。 「クロールして、結果を加工して、保存して、通知する」を1本の処理として書くと、どこかで落ちたときに全体をやり直すことになります。イベントで区切ると、後続処理だけを再実行できます。 クロール自体はコストの高い処理なので、やり直しの単位を小さくできることの価値は大きいです。

RAG のインデックス更新パイプラインには、特に噛み合います。 クロール完了をトリガーにベクトル化を走らせる、という構成が素直に書けます。従来は「クロールが終わったころに定期実行する」という時間ベースの妥協をしていた箇所です。イベントで繋げば、終わり次第すぐ次に進み、かつ終わっていないのに走ることもありません。 スケジュール実行の余白を取る必要が消えます。

副業・個人活用視点

小規模な自動化を組む人に、実利が大きい変更です。 個人でスクレイピングや情報収集の仕組みを作ると、「完了をどう知るか」で必ず詰まります。 素朴に書けばポーリングになり、実行時間を食い、料金がかかり、上限に当たる。ここが標準機能で解決するなら、書くコードが減ります。

受託案件では「情報収集の自動化」の見積もりが下がります。 クロール自体は Browser Run が担い、完了通知は Queues が担い、後続処理は Consumer Worker として短く書く。自前で作る部分が「集めたデータをどう加工するか」だけに絞れます。 見積もりの中で技術的な不確実性が大きいのは通常この待ち受けの部分なので、そこが既製品になると価格を下げても利益が残ります。

crawl.updated の使いどころは、顧客向けの画面です。 長時間かかる処理の進捗が見えないと、利用者は「動いているのか」を気にします。進捗イベントを拾って画面に出せるだけで、体験は大きく変わります。 技術的には難しくないのに効果が分かりやすいため、提案に入れる価値があります。

覚えておくべき一般則は、「投げて忘れる」形に寄せるということです。 待つコードは、待っている間ずっと弱点を抱えます。完了を知る手段が別にあるなら、投げたら離れる。 これはサーバーレスに限らず、時間のかかる処理を扱うときの基本形です。今回の更新は、その基本形を書きやすくするものだと捉えると応用が効きます。