セッションリプレイでJavaScriptエラーを調べる方法｜再現手順を開発者に渡すまで

「申込ボタンを押しても進めない」という問い合わせだけでは、開発者が同じ問題を再現できないことがあります。

そのとき役立つのが、操作の前後を確認できるセッションリプレイです。

ただし、録画にJavaScriptエラーが出ているからといって、それが不具合の原因だと決まるわけではありません。

操作の順序、実際に止まった場所、技術記録、期待する動作をそろえて渡すことで、調査を始めやすくなります。

この記事では、セッションリプレイから問題のある場面を選び、開発者向けの不具合チケットにまとめる手順を解説します。

ClarityとFullstoryの公式資料、Chrome DevToolsの説明を例に、製品ごとの違いも整理します。

最後まで読むと、録画付き不具合チケットの記入例を、自社の調査用に置き換えられます。

掲載するサイト・エラー・件数・チケットは架空の例であり、特定サービスで実測した障害ではありません。

セッションリプレイとエラー調査の役割

録画は「何をしたか」をたどる材料です。

原因を確定するには、アプリの状態や処理の記録も必要になります。

操作とエラー時刻を合わせる

まず、問題の操作とエラーが出た位置を、同じ時間軸で確認します。

例えば、送信ボタンを押す前から出ていた警告と、押した直後の例外は分けて記録します。

Clarityの録画では、検出されたJavaScriptエラーとエラー文字列をタイムラインで確認できます（参考：録画プレーヤーのイベント）。

該当時刻だけを見るのではなく、その手前の入力や画面遷移も再生してください。

「ボタンを押した→読み込み表示になった→次の画面が出なかった」という順序が分かると、調べる範囲を絞れます。

同時に、「エラー表示の後も操作を続けられたか」を確認します。

警告が出ても申し込みが完了した記録なら、その警告だけで手続きが止まるとは言えません。

チケットには、録画内の経過時間と、セッションの日時を両方残すと便利です。

サーバーのログがUTC、管理画面が日本時間という場合は、タイムゾーンも明記します。

時刻が近いことは照合の手がかりであり、因果関係の証明ではありません。

「同じ場面で見つかった」と「原因を特定した」を別の状態として管理してください。

記録される技術情報を確認する

セッションリプレイなら、すべてのコンソール出力や通信本文を記録できるわけではありません。

契約、権限、設定、ブラウザの制約によって、取得できる情報は変わります。

Fullstoryには録画と合わせてコンソール情報を確認する機能がありますが、取得の設定や制約も説明されています（参考：Fullstory Console）。

使用中の製品で、エラー文字列、スタック、通信先、ステータスなどのうち何が見られるかを先に確認してください。

スタックとは、エラーに至るまでの関数の呼び出しをたどるための情報です。

それがなければ、録画だけから原因となるコードの行を特定できないことがあります。

ブラウザのerrorイベントと、処理されなかったPromiseの拒否を知らせるunhandledrejectionも、同じ仕組みではありません（参考：Windowのerrorイベント、unhandledrejectionイベント）。

ある種類のエラーが記録されていないからといって、問題がなかったとは限らない理由の一つです。

以下のように、現在使える情報を表にしておくと、調査途中の行き詰まりを減らせます。

情報	確認すること
操作の録画	対象ページと前後の操作が残っているか
エラー	文字列・時刻・発生ページを確認できるか
コンソール	取得対象と権限、保存期間はどうなっているか
通信	URL・ステータス・時間・本文の取得範囲
アプリの版	問題の発生時に配信していた版を特定できるか

取得していなかった情報を、後から録画へ追加できると期待しないことも大切です。

エラーがあるセッションを選ぶ

調査の初めに、関係のないページや端末の記録を混ぜないようにします。

同時に、エラーのある記録だけを見て影響を大きく見積もらないように注意します。

画面と端末を絞る

最初に対象ページと発生期間を指定します。

問い合わせで端末やブラウザが分かっていれば、その条件を追加します。

ClarityではFiltersのPageにあるJavaScript errorsで、ブラウザで検出されたエラーを条件にできます（参考：JavaScriptエラーによる絞り込み）。

同じ場所にあるClick errorは、クリック後に検出されたJavaScriptエラーを調べるための条件です。

公式資料では、複数のエラーをORまたはANDで組み合わせる方法も示されています。

ORとANDでは対象が変わるため、選んだ条件を調査メモに残してください。

画面の表示名が異なる場合は、エラーの有無や文字列を指定する現在の項目を確認します。

次に、同じ期間・ページ・端末で、正常に完了した記録も確認します。

同じエラーが成功した場面にも出ていれば、別の条件が関係している可能性があります。

反対に、特定の画面遷移でだけ同じ症状が続くなら、その経路を優先して再現します。

録画を絞り込んだ条件と、実際に確認した件数は、後の影響範囲の説明に使うため保存しておきます。

個人情報を隠したまま調べる

不具合の調査であっても、利用者の入力内容を無制限に見られる状態へ変える必要はありません。

まず、現在のマスキングを保ったまま、操作の順序と画面の変化を確認します。

Clarityでは入力欄やドロップダウンの内容がマスキングされ、設定変更は過去の記録へさかのぼって適用されません（参考：Clarityのマスキング）。

入力値が見えない場合は、見えない内容を推測してチケットへ書かないでください。

入力の種類や長さが関係しそうなら、テスト環境で架空の値を使って再現条件を調べます。

例えば、「会社名が空欄のとき」と「長い会社名を入力したとき」を別々に試す方法があります。

実在の顧客名やメールアドレスを、再現用の値として貼り付ける必要はありません。

共有リンクは、見てほしい場面だけでなく、録画全体の情報が共有される可能性も確認してください。

Clarityではチーム向けとリンクを知る人向けの共有方法があり、閲覧範囲や期限の扱いが異なります（参考：Clarityの共有設定）。

録画の開始時刻を指定することは、それ以前の内容を削除する編集ではありません。

開発者へ渡す前に、共有相手・記録内容・閲覧期限を確認します。

エラー前の操作を再現する

録画を見た担当者の頭の中だけに、再現条件を残さないようにします。

別の担当者が同じ状態から始められる手順に直します。

最初のページから順序を書く

再現手順には、操作の前提を先に書きます。

ログインの有無、権限、選んでいるプラン、直前に保存した設定などが、動作を変えることがあります。

ただし、パスワードや認証トークンをチケット本文へ書いてはいけません。

テスト用アカウントの利用方法は、社内の認められた共有経路で管理します。

手順は「いつものように申し込む」ではなく、押す項目と移動するページが分かる形にします。

架空の資料請求フォームなら、次のように記録できます。

1. 未ログインの状態で、テスト用の資料請求ページを開く
2. 必須項目へ指定の架空データを入力する
3. 「確認へ進む」を押す
4. 確認画面から「入力へ戻る」を押す
5. 会社名を変更し、もう一度「確認へ進む」を押す

この例では、最初から入力した場合と、確認画面から戻った場合を区別しています。

一度成功した後の操作だけで起きる不具合なら、前の画面へ戻る工程を省くと再現できません。

最初は録画通りの順序で再現し、その後に不要な操作を一つずつ減らします。

最小限の手順にする作業と、最初から手順を省略することは別です。

他の人が追試できた段階で、「再現確認済み」と記録してください。

失敗した画面を特定する

「動かない」だけでは、表示・入力・通信・保存のどこで止まったのか分かりません。

期待する状態と、実際の状態を対にして書きます。

架空の例なら、「確認画面へ移動するはずが、入力画面のまま待機表示が続く」と表現できます。

次に、その時点で他の操作ができたかを確認します。

スクロールはできたのか、戻るボタンは使えたのか、入力内容は残っていたのかを記録してください。

画面が止まったように見えても、録画の再生が止まっているだけの場合があります。

リプレイでCSSや画像を取得できず、実際の利用画面とは違う表示になることもあります（参考：Clarity録画の表示トラブル）。

そのため、白い画面の録画を見ただけで、利用者にも白い画面が出ていたとは断定できません。

実ページでの再現や、他の技術記録と照らし合わせて切り分けます。

再現できなければ、「録画では確認」「実機では未再現」と状態を分けて残します。

録画のずれが疑わしい場合は、Web録画がずれる・真っ白になる場合の確認手順から先に調べてください。

セッションリプレイを技術記録と照合する

ここからは、開発担当者と一緒に進める段階です。

録画の表示と、コンソールや通信の結果を結び付けます。

コンソールや通信と対応づける

ブラウザで再現する場合は、操作を始める前にChrome DevToolsを開きます。

Consoleでログの表示条件を確認し、画面遷移をまたぐ調査ではPreserve logを使って必要な記録を残します（参考：Chrome Consoleの記録と表示）。

表示するログのレベルやフィルターを狭めていると、必要なメッセージを見落とすことがあります。

次にNetworkを開き、対象操作の前後で送られたリクエストを確認します。

ステータス、開始時刻、所要時間、要求先を照合すると、処理がどこまで進んだかを調べる材料になります（参考：Networkパネルの確認項目）。

通信が成功しているのに画面へ結果が反映されていない場合と、要求自体が失敗した場合は、調べる場所が異なります。

HTTP 200でも、応答内容が業務上のエラーを示している場合があるため、成功コードだけで完了扱いにしません。

Fullstoryで通信本文を調べる場合も、Network Allowlistingなどの取得条件を事前に確認する必要があります（参考：FullstoryのNetwork Allowlisting）。

認証情報や個人情報を含む本文を、原因調査のために丸ごと取得する設定へ変えないようにしてください。

HARなどの通信記録を共有する場合も、URLのクエリや要求・応答の本文を確認します。

一部の認証ヘッダーが除かれたファイルでも、すべての秘密情報が自動で消えるとは限りません。

共有するのは、調査に必要な範囲へ絞った情報です。

無関係なエラーを分ける

コンソールに赤い表示があると、そこを直せば解決すると考えがちです。

しかし、広告タグの通信失敗と、フォームの保存処理が止まる問題は、別の原因かもしれません。

発生元のファイルやドメイン、エラーの時刻、影響した画面を整理します。

そのうえで、成功した操作にも同じエラーが出るかを確認してください。

共通して出ているから無関係と確定するわけではありませんが、原因を絞る材料になります。

開発者は、必要に応じて例外が起きる場所で処理を一時停止できます。

Chrome DevToolsのSourcesでは、未処理の例外や、処理される例外で止める設定を分けて使えます（参考：例外ブレークポイント）。

圧縮されたJavaScriptしか見えない場合は、ソースマップを使って元のコードと対応付けられるか確認します（参考：ソースマップによる調査）。

ここで重要なのは、問題が起きた版と対応するコードを使うことです。

古い録画に対して現在のコードだけを調べると、既に変わった処理を前提にしてしまう可能性があります。

調査結果は「関連が疑われる」「再現時に同じ例外を確認」「原因を特定」と段階を分けてください。

推測のまま担当部署へ責任を帰さず、確認できた事実を積み上げます。

開発者へ不具合を渡す

チケットの目的は、録画の存在を知らせることだけではありません。

受け取った人が再現し、影響を判断し、修正後の確認までできる状態にします。

期待する動作と実際を分ける

タイトルには、対象の画面と具体的な症状を書きます。

「フォームのエラー」より、「確認画面から戻って再送信すると、入力画面の待機表示が終わらない」の方が調べやすくなります。

次は、録画付き不具合チケットの架空の記入例です。

実際のURLや識別子を共有する際は、閲覧権限と情報の内容を確認してください。

項目	架空の記入例
対象	資料請求フォームの確認・再送信
症状	確認画面から戻った後の再送信で待機表示が続く
期待	変更内容を反映した確認画面へ移動する
実際	入力画面に残り、完了画面へ進まない
前提	未ログイン、テスト用ページ、対象の公開版
再現手順	入力→確認→入力へ戻る→会社名変更→再送信
録画の位置	録画リンクと、再送信の直前の経過時間
技術記録	同時刻にTypeErrorを確認、原因は未確定
影響の確認	同条件の記録と、成功した記録を追加確認中
修正後の確認	同じ往復操作から正常に確認・完了できること

この表の「TypeError」は説明用の架空例です。

実際のチケットでは、取得できたメッセージを必要な範囲で残し、個人情報を伏せてください。

録画に含まれない操作や、推測した入力値を、確認済みの事実に混ぜないことが重要です。

担当者が追加で確認したいことがある場合は、未確認欄へ書き足せます。

長い録画を全部見てもらう前提にせず、最初に見る位置と、そこへ至る手順を示します。

再現条件と影響範囲を添える

再現条件には、端末・ブラウザ・アプリの版・ログイン状態を含めます。

同じ症状に見えても、特定の権限や入力状態だけで発生する場合があります。

分かっていない条件は「不明」と書いて構いません。

推測の情報を確定事項として埋めるより、次に調べる場所が明確になります。

影響範囲は、エラーの表示回数と、影響したセッション数を分けて記録してください。

一人の利用者が繰り返し押したことで、同じ例外が何度も発生している可能性があります。

架空の例として、エラー条件で選んだ録画10件のうち6件で停止を確認しても、「全利用者の60%が停止」とは言えません。

そもそもエラーがある記録だけを選んでいるためです。

対象ページの全セッションを母数にするのか、該当操作を行ったセッションを母数にするのかを先に決めます。

計測できていない操作があるなら、現時点で割合を出せないことも明記します。

優先順位は、発生回数だけでなく、主要な業務が止まるか、回避方法があるか、どの利用者へ影響するかで判断します。

少数でも決済や重要な申請を止める問題なら、影響の大きさを伝える必要があります。

修正後のセッションリプレイ確認

修正を公開したことと、不具合が解消したことは別です。

同じ操作で再試験し、周辺の経路にも問題がないか確認します。

同じ操作を再試験する

チケットに書いた前提と手順を使い、修正後の版で再現を試します。

途中の画面を省かず、問題があった操作から完了まで進めてください。

その際、エラーが消えたことだけで合格にしません。

イベントの記録処理が動かなくなっただけなら、エラーが見えなくなっても利用者の問題は残ります。

期待する画面へ移動し、必要な保存や送信が正常に完了したことを確認します。

計測が必要なイベントも、テスト環境や適切な検証方法で確かめてください。

GA4を使う場合、DebugViewではデバッグ用のイベントを確認できます（参考：GA4のDebugView）。

計測イベントが出たことと、業務処理が成功したことは分けて検証します。

修正後の確認メモには、試験した版、端末、結果、確認日時を残します。

本番の記録を確認するときも、利用者の操作を無理に発生させず、通常の対象条件に合う記録を見ます。

エラーが再発していないかと、操作が正常に進んでいるかを、両方確認してください。

別の経路への影響を調べる

一つの不具合を直した結果、別の操作が変わっていないかも確認します。

先ほどのフォームの例なら、最初から一度で送信する経路と、確認画面から戻る経路を試します。

必須項目が足りない状態で、適切なエラー案内が出るかも対象です。

画面上のエラーは、利用者が修正すべき場所と内容を理解できる形で示す必要があります（参考：エラーの識別）。

処理を止める例外を消すために、入力チェックまで消してしまう対応は避けてください。

また、同じ部品を使っている別のフォームや画面があれば、変更の影響に応じて確認範囲を決めます。

サイト全体を毎回同じ深さで試すのではなく、変更した処理と関係する経路を開発者と整理します。

結果は、次のように短く残せます。

確認する経路	残す内容
問題があった操作	期待する状態まで進めたか
通常の操作	修正前から使えた経路が使えるか
入力不足などの操作	適切な案内が出て修正できるか
計測	必要な記録が取れているか
共有部品を使う画面	変更による影響がないか

不具合チケットを閉じる際は、確認した結果と、残っている制約を記録してください。

録画付きの報告を整える方法は、Web録画を改善提案に変える報告書の作り方でも紹介しています。

最初の一歩は、問題の録画を一つ選び、「何を期待して、実際にはどうなったか」を一文ずつ書くことです。

そこへ再現手順と必要な技術情報を添えれば、開発者が調査を始められる不具合報告になります。