HAR ファイルで原因を追う：Cloudflare Browser Runの失敗調査

Cloudflareは2026年9月18日、失敗したジョブを調べる手順を刷新しました。完了済みのBrowser Run録画から、コンソールログ、HAR ファイルに書き出せるネットワークリクエスト、最後に残ったページ構造を確認できます。つまり、別のブラウザを起動する前に、すでに料金を払って生成した証拠から原因を絞り込めます。

実行後に残る証拠：ログ、DOM、HAR ファイル

従来、ブラウザジョブが終わったあとに残るのは、出力とエラー処理、それにSession Recordingを有効にしていた場合のリプレイでした。失敗の理由がそこから読み取れなければ、ログを増やしてもう一度ジョブを走らせるのが定石でした。

新しいInspectパネルでは、完了した録画の横に3つのビューが並びます。

• Logsでは、収集済みのコンソール出力を検索し、レベルで絞り込めます。
• Networkでは、各リクエストのメソッド、ステータス、ヘッダー、ペイロード、レスポンス、所要時間を確認できます。さらに、ブラウザの通信履歴を保存する標準形式であるHAR ファイルとして書き出せます。
• DOMでは、録画終了時のページ構造を確認し、復元されたHTMLをコピーできます。DOMとは、ブラウザがページから構築した要素ツリーのことです。

これは実行後の証拠を調べる機能であり、リアルタイムのデバッグ画面がもう1つ増えたわけではありません。CloudflareのSession Recordingは動画ではなく、構造化されたrrwebイベントデータです。DOMの変化、マウスやキーボードの操作、ページ遷移を記録します。セッション終了後、Inspectパネルがそのリプレイに検索可能な手掛かりを加えます。

この点が、Cloudflareによる以前のBrowser Run更新とは異なります。セッションのアクセス制限と読み取り専用のLive Viewは、実行中のジョブがアクセスできる場所と、監視中のクライアントができる操作を制御します。Inspectは、完了したジョブがなぜ失敗したのかを自社チームが説明するための機能です。

録画から原因を特定できる失敗

このパネルが役立つのは、ブラウザ内に失敗の痕跡が残っているケースです。

個人SaaS創業者：拒否されたリクエストを突き止める

定期実行する抽出ジョブがページには到達したものの、データを返さなかったとします。Networkビューを見れば、APIが401を返したのか、レート制限で429になったのか、リダイレクトで想定外の場所へ移動したのか、あるいは特定の依存先が実行時間の大半を消費したのかを確認できます。

一時的なログを追加する前に、リクエストとレスポンスの詳細を調べられます。初動の切り分け範囲を狭められるのが利点です。既存の実行で露呈した認証情報、バックオフ、リダイレクト、遅い依存先のうち、どこに手を入れるべきか判断できます。

制作会社の責任者：ページ変更とスクリプト不具合を切り分ける

クライアント向けのワークフローは、セレクターの変更、想定画面に代わって表示されたログインページ、アセット取得時のエラーなどで失敗します。最終DOMとコピーしたHTMLを見れば、ブラウザが実際にどの画面で終了したかが分かります。そこへ至った経路はリクエスト履歴で追えます。

実装チームへの引き継ぎも具体的になります。「自動化が壊れた」という曖昧な報告ではなく、最後の要素ツリーと、取得できたヘッダー、ペイロード、ステータス、所要時間を含むHARを渡せます。

プラットフォームエンジニア：対象タブを正しく追う

録画のイベント配列は、target-1のようなChrome DevTools Protocolのターゲット別に管理されます。通常、各ターゲットがブラウザの1つのタブに対応します。複数タブの録画ではターゲットが個別に公開され、ダッシュボードのInspectパネルは選択したタブに追従します。

認証の引き継ぎやエージェント型ワークフローでは、この区別が重要です。ログイン用タブが成功していても、作業用タブは失敗しているかもしれません。ターゲット単位の証拠なら、2つの経緯を混同せずに済みます。

ジョブを記録してネットワークトレースを取得する

録画はオプトインです。ブラウザセッションを最初に取得するときに有効化する必要があり、既存セッションへの再接続時にあとから有効にすることはできません。

実用になる最小構成は、失敗するたびに手作業で再現している定期Browser Sessionを1つ選ぶことです。

1. 1

   起動時に録画を有効にする

   CloudflareのPuppeteerサンプルでは、最初の起動呼び出しにrecording: trueを渡します。ブラウザを閉じる前にセッションIDを保存します。

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   Playwrightでも同じ起動オプションを使います。CDP接続では、WebSocket URLにrecording=trueを指定します。

2. 2

   完了した録画を取得する

   セッションが閉じたら、そのセッションIDを使って録画をリクエストします。

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   レスポンスでは、イベント配列がresult.eventsの下に入ります。target-1のようなキーが、ネットワークリクエストで必要になるターゲットIDです。新しい録画はCloudflare側の確定処理中に一時的な404を返すことがあるため、最初の404だけで録画が存在しないと判断せず、取得を再試行します。

3. 3

   ターゲットの生リクエストを取得する

   録画レスポンスに含まれるターゲットを選びます。targetパラメーターは必須です。

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   取得できるのは、利用可能なリクエストとレスポンスの詳細を含むJSON形式の通信記録です。

4. 4

   HARを書き出す

   開発者がブラウザのネットワークビューアーや別の解析ツールでトレースを確認する場合は、format=harを追加します。

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   このファイルは、アクセス経路を限定したデバッグ用アーティファクトとして扱います。仕様上、レスポンスには取得可能なヘッダーやペイロードが含まれるため、ジョブが扱うデータと同じ水準で管理する必要があります。

ありがちな失敗は、最初の障害が起きてから録画を有効にすることです。過去にさかのぼって調べられる証拠は残りません。次回の失敗を見逃したくない定期ジョブから始めます。

本当に重いのはブラウザ料金ではない

Cloudflareが現在公開しているBrowser Runの料金には、録画や録画データの保存に対する別料金は記載されていません。録画したBrowser Sessionにも、通常のブラウザ稼働時間と同時実行数に基づく料金がかかります。Session Recordingはベータ版なので、これは現時点で公開されている料金であり、今後も続く保証ではありません。

Workers Freeには1日10分のブラウザ利用と、3ブラウザの同時実行枠が含まれます。Workers Paidはアカウントあたり月額最低$5で、10時間のブラウザ利用と10ブラウザの同時実行枠を含みます。超過分はブラウザ1時間あたり$0.09、追加の同時実行枠1つあたり$2で、各日のピーク値を月平均した数に基づいて課金されます。

診断のために1回再実行する直接費用はごくわずかです。負担が大きいのは、その前後にかかる人件費です。以下は計画用の試算であり、Cloudflareのベンチマークではありません。

• アカウントは、すでに付帯する10時間のブラウザ利用枠を使い切っています。
• 1つの定期ジョブは10分かかり、1か月に12回失敗します。
• 各障害の再現と診断には、担当者が20分を費やします。
• 既存の録画を調べる作業は、担当者が5分で終えます。
• 担当者の総人件費を1時間あたり$75と仮定します。
• 調査によって診断用の再実行を1回避けられますが、修正確認のために後日もう1回実行する可能性はあります。

この差額のうち、ブラウザの稼働時間そのものはわずか18セントです。残りの$225は担当者の人件費です。またCloudflareでは、請求期間全体の利用量を合計してからアカウント単位でブラウザ利用時間を丸めます。そのため、10分の実行にかかる1.5セントが請求書の明細にそのまま現れるとは考えないでください。

ここに業務上の意味があります。Inspectパネルによってブラウザ計算資源の費用が大幅に減るわけではありません。障害対応から、計測を仕込み、再現し、結果を待つというループを1回減らせる可能性があります。

録画では見えないもの

記録されるのはドキュメントの状態とイベントであり、描画されたすべてのピクセルではありません。

こうした制約に当たる失敗には、別の診断方法が必要です。Canvas上のグラフ、サードパーティーiframe内の決済フォーム、動画の状態、WebGLシーン、マスクされたフィールドへの入力値は、周囲の記録が正常に見えても誤っている可能性があります。

DOMビューが示すのも、録画終了時点の構造です。ジョブが最後に到達したページは説明できますが、それ以前の各状態をピクセル単位で忠実に再現したスクリーンショットではありません。

運用上の制限もあります。録画は30日間保持され、長さは最短1秒、最長2時間です。launch()またはCDPを使うBrowser Sessionsで利用できますが、Quick Actionsでは作成できません。DOMが頻繁に変化するページでは、その変化がすべて録画データになるため、イベントストリームが大きくなる場合があります。

今すぐ運用を変えるべきチーム

Puppeteer、Playwright、CDPの定期ジョブを運用していて、失敗のたびに誰かが再現作業から始めているなら、今週中に動く価値があります。すべてのジョブではなく、まず1つだけ録画を有効にし、初動で確認したい問いに記録だけで答えられるかを測ります。

重要な状態が主にCanvas、WebGL、メディア、クロスオリジンiframe、マスクされたフォームフィールドにある場合は待つべきです。その種の処理では、スクリーンショット、アプリケーションログ、対象を絞った計測を残してください。録画だけでは代替できません。

Quick Actionsだけを使っている場合、この変更による影響はありません。録画だけを目的にBrowser Sessionsへ移行すると、実装が変わり、料金モデルに同時実行数が加わります。その変更に見合うデバッグ効果があるかを判断する必要があります。

月曜日にやること

複数回失敗したことのある定期Browser Sessionを1つ選びます。最初の起動時にrecording: trueを追加し、自社のジョブIDと一緒にセッションIDを保存して、次の定期実行を通常どおり終了させます。

終了後に録画を取得し、最初の関連ターゲットIDを選んで、生のネットワークトレースまたはHARをリクエストします。失敗したリクエストや最後のページ状態を特定するまでの時間を測ります。その証拠によって診断用の再実行を1回減らせたなら、そのジョブでは録画を継続し、トレースをインシデント記録に含めます。減らせなければ録画を無効に戻し、死角になっている場所へ不足したシグナルを追加します。

プラットフォームの変更を運用担当者の目線で解説する記事をもっと読みたい方は、ニュースレターにご登録ください。