Web録画がずれる・真っ白になる原因は？セッションリプレイの再現を確認する手順

Web録画を開いたら、画像が消え、文字が重なっている。

実際のサイトは普通に表示されるのに、セッションリプレイだけ真っ白になる。

こうした場合、まず分けたいのは「利用者が本当に見ていた不具合」と「記録を再生するときの不具合」です。

両者を混同すると、正常なページを直したり、必要なマスキングを外したりすることにつながります。

Clarityの公式資料では、録画は動画の撮影ではなく、ページの情報と操作から再構成する仕組みだと説明されています（参考：Clarityの録画の仕組み）。

そのため、再生に必要な素材を取得できない場合や、対応していない描画がある場合には、実画面と違って見えることがあります。

この記事では、Web録画のずれ、白い画面、画像や文字の欠落を、症状ごとに切り分ける手順を紹介します。

ClarityとFullstoryの公式仕様を例にしますが、設定名や取得範囲は利用する製品で確認してください。

仕様は2026年10月5日に確認しており、掲載する切り分け表は自社サイトでの調査に使うためのひな型です。

Web録画の不具合を症状で分ける

最初からタグを入れ直す前に、いま起きていることを一行で書きます。

「録画が変」では、確認する場所が広すぎるためです。

録画がない場合と再生できない場合

まず、対象の録画が一覧に存在するかを確認します。

存在しない場合は、検索期間、対象プロジェクト、ページ条件、取得設定などを調べます。

存在するのに開けない場合は、保存期間、閲覧権限、プレイヤー側の状態も確認対象です。

開けるが画面が崩れている場合は、素材の取得や再現方法を中心に調べます。

症状	最初に確認する場所	すぐには判断できないこと
一覧に録画がない	期間、フィルター、プロジェクト、タグの取得条件	訪問そのものがなかったか
一覧にはあるが開けない	閲覧権限、保存期間、再生画面のエラー	サイトの表示も壊れていたか
再生は進むが真っ白	画面の構造、素材、マスク・除外、描画方式	利用者も白い画面を見たか
一部の要素だけ違う	対象要素、素材URL、埋め込み、ページの版	ページ全体の記録が失敗したか

Clarityでは、集計にセッションがあっても、再生に十分なデータがなく録画として表示できない場合があります（参考：ダッシュボードと録画の違いを調べる）。

集計件数と再生できる本数が違うだけで、すべてをタグの故障と決めないようにします。

録画が一件もない場合は、導入確認の手順へ戻り、正しいプロジェクトのタグが対象ページで動いているかを点検してください（参考：Clarityの設定トラブルシューティング）。

この先は、主に「記録はあるが、再生画面がおかしい」場合を扱います。

文字・画像・配置の違いを分ける

画面を見て、どの種類の要素が欠けているかを分けます。

文字だけが記号に置き換わっているなら、まずマスキングを確認します。

画像が枠だけになっているなら、画像の取得条件や対応範囲を確認します。

文字の大きさや配置まで崩れているなら、CSSやフォントの取得を疑う材料になります。

ただし、見た目だけで原因を断定することはできません。

見え方	確認候補	記録すること
文字が伏せ字になる	マスキング	対象の文章と適用ルール
画像だけ表示されない	素材URLや除外	画像の位置、URLの種類
全体の配置が崩れる	CSS・フォント	欠けたファイルと応答
埋め込み部分だけ空白	iframeなどの対応範囲	自社管理か外部サービスか
動く部品だけ再現されない	特殊な描画方式	部品名と使用技術

最初に気付いた場面の再生時刻も残します。

冒頭からおかしいのか、ある操作の後で崩れるのかで、調べる対象が変わります。

同じ録画の前後と、同じページの別の録画を比べると、単発の問題かどうかを整理できます。

Web録画と実際の画面を比べる

現在のサイトと過去の録画を比べるだけでは、正しい差分が分からないことがあります。

記録されたときのページと、比較している画面の条件をそろえます。

計測時点のページ版を確認する

対象録画の日時を確認し、その時点で公開されていたページの版を調べます。

その後に見出し、画像、テーマ、CSSを変更していないかも確認してください。

広告用のLPなら、同じURLのまま内容を差し替えていることもあります。

ABテストや会員状態によって表示が変わる場合は、どのパターンが記録されたかを残します。

Fullstoryは、過去の見た目を再現するために、参照された画像やCSSを保存する仕組みを説明しています（参考：サイト変更後の過去セッション）。

ただし、その素材を取得できなければ、保存の仕組みがあっても期待どおりの再生にならない場合があります。

「いまのCSSで正しく見える」だけで、過去の記録も正しくなると考えないようにします。

次の情報を並べて、比較対象をそろえてください。

• 録画された日時とタイムゾーン
• 当時のページ版と公開日時
• 比較した現在のページ版
• 対象のURLと表示パターン
• CSSや画像の更新・削除の有無

版の情報が分からない場合は、分からないまま記録します。

推測で「同じページ」と扱うより、比較に限界があることを残した方が、次の調査につながります。

同じ端末条件で試す

スマートフォンの記録を、大きなPC画面のレイアウトと比較しないようにします。

端末の種類だけでなく、ブラウザ、画面の向き、表示領域の幅を確認します。

メニューや固定ボタンは、画面幅によって位置や表示方法が変わることがあります。

ChromeのDevice modeでは、幅と高さを指定して表示を近づけられますが、実機そのものを再現する機能ではありません（参考：Device modeと実機の違い）。

まずPCの開発者ツールで条件を近づけ、端末固有の問題が疑われる場合は実機でも試します。

テスト操作は、ページを開く、対象の場所まで移動する、部品を操作する、という短い流れにします。

そのときの実画面を、個人情報のない状態で記録してください。

後から生成されたリプレイと、同じ操作の場面を比較します。

実画面も崩れたならサイト側の問題を調べ、実画面は正常でリプレイだけ違うなら再現側の条件を調べます。

どちらか分からない場合は、録画だけで利用者の体験を断定せず、追加の再現確認を行います。

Web録画で画像やCSSが欠ける場合

自分のブラウザで画像が見えることと、録画サービスがその画像を取得できることは別です。

ログイン状態や社内ネットワークに依存する素材では、この違いが表れます。

素材の取得条件を確認する

まず、欠けている画像、CSS、フォントのURLを特定します。

一般公開の素材か、認証が必要な素材か、期限付きのURLかを分けてください。

Fullstoryの公式資料でも、外部から取得できない素材は保存できず、再生で欠ける原因になると説明されています（参考：画像やCSSが再生されない場合）。

たとえば管理画面にログインした自分だけが見られる画像は、外部の取得処理でも見られるとは限りません。

また、公開直後に古いファイルを削除すると、記録に参照先だけが残る場合があります。

調査では、Chromeの開発者ツールでNetworkを開き、CSS、Img、Fontなどの種類で絞ります（参考：Networkで素材を絞り込む）。

対象の行を選び、Statusと応答内容を確認します。

200と表示されても、素材ではなくログイン画面のHTMLが返っていないかを見てください。

応答の例	確認すること	対応を相談する相手
404	素材が削除されたか、URLが違うか	配信・開発担当
401・403	認証やアクセス制限があるか	配信・セキュリティ担当
リダイレクト	ログイン画面などへ移動していないか	アプリ・配信担当
200だが表示されない	内容とファイル種別が合っているか	開発担当
ブロックの表示	制限の種類と対象ドメイン	管理者・開発担当

Clarityでは、素材の公開範囲、アクセス制限、期限、Content-Typeなどが確認項目として案内されています（参考：Clarityの再生表示を調べる）。

機密画像を一般公開すればよい、という対応にはしないでください。

公開できる素材だけを分けるか、製品が提供する別の取り込み方法を検討します。

Fullstoryには素材をアップロードする仕組みもありますが、対象ファイルの確認と版ごとの管理が必要です（参考：Web用のAsset Uploading）。

再生側の制約を確認する

素材の配信元だけでなく、録画を見ているブラウザ側でも確認します。

同じ録画を別の承認済み環境で開き、症状が変わるかを比べてください。

社内プロキシやブラウザ拡張機能など、閲覧環境の違いがないかを記録します。

セキュリティ設定をまとめて無効にするのではなく、何がブロックされているかを先に調べます。

ConsoleにCSPの違反が出ているなら、対象のリソースと指示された制限を確認します。

CSPは、読み込めるコンテンツなどを制御する仕組みであり、再生を直すために全体を解除するものではありません（参考：CSPの役割）。

必要な変更は、製品の現行ドキュメントと自社の方針を照合して、管理者が範囲を決めます。

また、録画サービスのサーバーが素材を取得する通信と、自分のブラウザが再生画面を開く通信は別です。

自分のNetworkにエラーがないだけで、サービス側の取得も成功したとは限りません。

ブラウザ側で確認できない取得失敗は、配信ログや製品サポートへの問い合わせで補います。

問い合わせには、素材のURL、発生日時、確認した応答を、共有可能な範囲で添えます。

Web録画で文字や入力が見えない場合

入力内容が伏せられていることは、意図した情報保護の結果かもしれません。

見えないことと、再生に失敗していることを分けます。

マスキング設定を確認する

現在のマスキングモードと、対象要素に適用されるルールを確認します。

入力欄だけが隠れるのか、親要素を含めた領域が隠れるのかを見てください。

Clarityでは入力欄やドロップダウンなどに保護が適用され、設定変更は新しい録画に反映されます（参考：Clarityのマスキング）。

既存の録画を開き直しても、設定変更前に取得されなかった文字が後から現れるわけではありません。

確認するときは、反映時間を考慮して新しいテスト記録を作ります。

「住所が読めない」ことを直すのではなく、「住所を隠したまま、入力位置とエラー表示が分かるか」を確認してください。

入力の中身を見なくても、同じ欄へ戻る操作や、送信後のエラー表示から調べられることがあります。

必要な情報が足りない場合は、値そのものを取得する前に、個人情報を含まないイベントやエラー分類で補えるかを検討します。

設定を変更した理由と対象範囲を残すと、後から保護を弱めすぎていないかを確認できます。

対象要素だけを点検する

原因を調べるために、ページ全体のマスクを外す必要はありません。

個人情報のないテスト画面で、問題が起きる要素だけを確認します。

たとえば、実際の顧客名を含む表を、架空の項目名だけの表へ置き換えて再現できるかを試します。

親の領域に指定したルールが、子のボタンや説明にも適用されていないかを見ます。

Fullstoryではマスクと除外で取得される操作の範囲が異なるため、文字が見えない場合と要素の操作がない場合を分けて確認します（参考：Fullstoryのマスクと除外）。

対象要素の指定が変わっていないかも確認してください。

サイトの改修でクラス名や構造が変わると、以前に作ったルールの対象が変わる可能性があります。

点検メモには、対象の要素、適用したルール、テスト日時、確認した録画を残します。

修正後は、隠すべき値が引き続き隠れていることも確かめます。

見た目が直ったことだけで、マスキングの確認を終えないようにしてください。

Web録画で動的画面が合わない場合

ページ全体は表示できても、地図、動画、グラフ、ポップアップだけが違う場合があります。

この場合は、部品の作り方と変化するタイミングを調べます。

埋め込みと特殊描画を調べる

問題の部品が、通常のHTML、Canvas、WebGL、iframeのどれで表示されているかを開発担当へ確認します。

同じ「画像のような見た目」でも、再現する仕組みは異なります。

Clarityのインラインプレイヤーでは、外部のiframeとHTML Canvasに制限があります（参考：Clarityプレイヤーの制限）。

一方、Fullstoryの対応資料では、Canvasは条件付きの対応で、WebGLなどは非対応として案内されています（参考：Fullstoryの描画方式への対応）。

製品ごとの違いがあるため、あるツールで見えたことを別のツールにも当てはめないでください。

外部の予約フォームや決済画面では、自社で内部のソースを管理できない場合があります。

Fullstoryでも、スクリプトを設置できない外部iframeの内容は取得できないと説明されています（参考：iframeの取得条件）。

その場合は、外部画面の中を無理に記録しようとせず、遷移前の操作と、戻ってきた後の結果を確認します。

動画についても、再生画面に動画要素があることと、元の動画を同じタイミングで再現できることは別です。

Fullstoryは動画そのものを記録せず、タイムラインとの同期などにも制限があります（参考：ページ内動画の再現範囲）。

画面遷移のタイミングを確認する

「クリック位置がずれる」ときは、クリックの前後でページの高さや配置が変わっていないかを見ます。

遅れて表示される画像、開閉する説明、固定バナーなどがある場合は、その変化の前後を比較します。

再生速度を通常に戻し、問題の少し前から確認してください。

操作のない時間を省略する設定がある場合は、いったん省略を外して前後を見ます。

ClarityのSkip inactivityは、操作のない時間を飛ばす機能であり、元の時間経過と同じ見え方にはなりません（参考：再生コントロールの設定）。

再生が飛んだように見えるだけなのか、表示の変化が欠けているのかを分けます。

URLを変えずに画面が切り替わるアプリでは、ページ名だけでなく、表示していた部品と操作順を残してください。

同じURLで一覧と詳細が表示されるなら、「一覧の項目を選んだ後の詳細画面」と書きます。

そのうえで、自社のテスト操作でも同じずれが出るかを確認します。

一度だけの現象なのか、同じ操作で繰り返し起きるのかが、製品側へ伝える重要な情報になります。

Web録画の不具合を問い合わせる

自社だけで原因を特定できない場合は、再現条件をまとめて製品サポートへ相談します。

「真っ白です」だけでなく、正常な画面と違う場面を具体的に伝えます。

匿名の再現ページを用意する

可能なら、顧客情報を含まないテストページで同じ症状を再現します。

ここでいう匿名の再現ページは、氏名や注文内容などをダミーにした確認用ページです。

問題の起きる部品と必要なCSSを残し、関係のない要素を減らします。

本番の管理画面を外部へ開放したり、共有アカウントのパスワードを送ったりする方法にはしないでください。

問い合わせには、次の切り分けチェック表を添えます。

項目	記入する内容
製品・環境	製品名、利用環境、対象プロジェクト
症状	録画なし、再生不可、空白、素材欠落、位置ずれ
対象	共有可能な録画リンクと再生時刻
比較条件	記録日時、ページ版、端末、ブラウザ
実画面	個人情報を除いた正常時の表示
再現手順	開くページ、行った操作、違いが出る場面
素材	取得できないCSS・画像・フォントの情報
確認済み	マスク、描画方式、別環境での結果
未確認	自社で調べられなかった項目

通信ログを添付する場合は、Cookieや認証情報だけでなく、URL、入力値、応答本文にも確認が必要です。

Chromeには機密情報を除いたHARの出力がありますが、それだけで業務上の情報がすべて除かれると考えないでください（参考：Networkログの出力）。

共有する内容を確認し、必要な範囲だけを正式な窓口へ送ります。

直った条件を記録する

修正後は、以前の録画を開くだけでなく、新しいテスト記録でも確認します。

素材の修正で変わる場合と、新しい記録から反映される設定変更では、確認対象が異なるためです。

次は、架空のCSS取得不具合を記録する例です。

項目	記入例
事実	実画面は正常で、録画では文字の配置が崩れた
確認	対象CSSへの外部取得が403になっていた
変更	公開可能なCSSの配信条件を管理者が修正
再確認	新しいテスト記録で同じ操作を再生
結果	CSSの取得と配置を確認し、マスクも維持
継続確認	次回の配信変更時にも同じ手順で点検

これは説明用の例であり、403がすべての表示崩れの原因という意味ではありません。

直った後も、何を変更したら直ったかを残します。

一度に複数の設定を変えると、原因と効果の対応が分からなくなります。

担当者、変更日時、戻し方、再確認した記録を一緒に管理してください。

Web録画の表示が崩れたら、まず症状、実画面との差、素材、情報保護、描画方式の順に整理します。

その手順を残しておけば、次の改修で同じ症状が出たときも、闇雲に設定を変えずに調査を始められます。