Cloudflare Browser RunのSession RecordingsにInspectパネル：失敗したブラウザ自動化を再現せずに調査できる

要約

Cloudflare Browser Run の Session Recordings に Inspect パネルが追加されました。公式の言い方は「セッション中に何が起きたかを、再現しなくても理解できるようにする」です。セッションが終わった後の録画に対して、ブラウザの開発者ツールに相当する情報を後から読める形になりました。

この更新の意味は、ブラウザ自動化の失敗調査の前提が変わる点にあります。ヘッドレスブラウザやブラウザ操作エージェントの調査で一番厄介なのは、失敗が手元で再現しないことです。相手のサイトの状態、タイミング、広告やトラッキングの読み込み、地域による出し分け。どれも実行のたびに変わります。ログを仕込んでおけば残りますが、仕込んでいなかった情報は取れません。そして、調べたい情報はたいてい仕込んでいなかった方にあります。

Inspect パネルは、録画さえ有効にしておけば、後から必要な観点を選んで読めるという形でこの問題に対処します。

パネルは3つのタブで構成されます。Logs タブはセッション中に取得したコンソール出力を検索でき、メッセージのレベルで絞り込めます。Network タブはリクエストの method / status / headers / payload / response と、タイミングのウォーターフォールを表示し、HAR ファイルとしてダウンロードできます。ネットワーク情報はAPI 経由でも生 JSON または HAR として取得可能です。DOM タブは録画終了時点のページ構造を展開可能なツリーで表示し、再構成した HTML をコピーできます。複数タブのセッションでは、選択したタブに応じてパネルの内容が切り替わります。

利用するには、セッション起動時に録画を有効化しておく必要があります。セッション終了後、Cloudflare ダッシュボードの Browser Run > Runs から該当セッションの録画アイコンを開きます。なお、セットアップ手順と現時点の上限は公式の session recording ドキュメント側に置かれており、changelog 本文には上限の記載がありません。 保存期間や録画できるセッション数の条件は、導入前にドキュメント側で確認する必要があります。

何が変わったか

• Session Recordings に Inspect パネルを追加。セッション終了後に事後調査できる
• Logs タブ: コンソール出力を検索、メッセージレベルで絞り込み
• Network タブ: method / status / headers / payload / response / タイミングのウォーターフォールを表示。HAR ダウンロードに対応
• ネットワーク情報は API 経由で生 JSON または HAR として取得可能
• DOM タブ: 録画終了時点のページ構造を展開表示、再構成 HTML をコピー可能
• 複数タブのセッションでは、選択タブに応じてパネルの内容が切り替わる
• 利用条件: セッション起動時に録画を有効化。ダッシュボードの Browser Run > Runs から開く
• 上限・保存期間は changelog に記載なし（session recording ドキュメント側）

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

ブラウザ自動化を業務に乗せる際の運用設計が変わります。 これまでは「失敗したら再現を試みる」が起点でしたが、録画をデフォルトで有効にしておけば、失敗した回そのものを読めるようになります。運用ルールとして「本番のブラウザ自動化は録画を有効にする」を先に決めておく価値があります。録画を有効にしていなかったセッションの失敗は、依然として再現待ちだからです。

HAR ダウンロードは、組織をまたぐ切り分けで効きます。 自動化が失敗したとき、原因が自社側の実装なのか、相手システムの変更なのか、ネットワーク経路なのかを切り分ける必要があります。HAR は開発者ツールで読める標準形式なので、社内の別チームや相手先のベンダーへ「このファイルを見てください」と渡せます。再現手順を文章で伝える往復が消えるのは、実務では大きい差です。

API 経由での取得は、失敗時の自動収集に組み込めます。 自動化ジョブが失敗した際に、ネットワーク情報を JSON / HAR で取得してチケットへ添付する、という流れを作れます。人が気づいてダッシュボードを開くまでの時間差がなくなるため、断続的にしか起きない失敗の調査が現実的になります。

一方で、記録される情報の扱いには注意が要ります。 Network タブには headers と payload が含まれます。 つまり、認証トークン、セッション Cookie、フォームに入力した個人情報が録画に残りうるということです。HAR を社外へ渡す運用を作るなら、先に何が含まれるかを確認し、マスキングや共有範囲のルールを決める必要があります。 「デバッグに便利だから全部録画してベンダーに渡す」は、そのままだと情報の持ち出しになります。情シス・法務と事前に握るべき論点です。

副業・個人活用視点

受託でスクレイピングや業務自動化を請ける場合、納品後の保守で最も時間を食うのが「たまに失敗する」への対応です。 相手サイトの小さな変更で落ちる、特定の時間帯だけ落ちる、といった案件は、再現できないまま報告だけが来る状態になりがちです。録画とInspectパネルがあると、発生した回を直接読んで原因を返せます。 保守契約の中身として「失敗時は録画を確認して原因を報告する」と書けるようになり、見積もりの根拠も立てやすくなります。

提案段階での説得材料にもなります。 「動かなくなったらどうするのか」は必ず聞かれる質問です。「再現を試みます」より「記録が残るので、起きた回をそのまま調査します」の方が、発注側の不安に直接答えています。 ブラウザ自動化を提案しづらい理由の多くはこの不安なので、返答の質が案件化率に効きます。

個人開発でもコストの観点で意味があります。 再現のための試行は、相手サイトへのアクセス回数と実行時間をそのまま消費します。録画を読む方が、再現を回すより安い場面は多いはずです。ただし録画自体の保存コストと上限はドキュメント側にあるため、常時録画にする前に条件を確認するのが順序です。

HAR に何が入るかは、個人で使う場合こそ気をつける点です。 自分のアカウントでログインして自動化している場合、その認証情報が録画に残ります。 公開リポジトリや記事に HAR をそのまま貼る、といった事故が起きやすい形なので、共有する前に中身を見る習慣を付けておく方が安全です。