セッションリプレイとは何か、そしてデバッグに本当に役立つ理由

リプレイは「再構築」であって動画ではない

セッションリプレイについて最もよくある誤解は、画面を録画しているというものです。そうではありません。リプレイが記録するのは DOM、つまりページの構造と、そこに加えられたすべての変更、さらにクリック、スクロール、入力イベント、ネットワークの所要時間、コンソールエラーです。再生時には、そのデータからブラウザ上でページが組み立て直されます。

この違いこそが本質です。リプレイはピクセルではなく構造化されたデータなので、検索でき、エラーが発生した正確な瞬間まで飛べ、その時点の DOM の状態を読み取れます。画面録画ではそのどれもできず、しかも通信量ははるかに多くなります。

スタックトレースでは得られないもの

エラートラッカーが教えてくれるのは、214 行目で TypeError が発生したという事実だけです。そのユーザーがすでに二度フォームを送信していたことも、二度目は回線が遅かったことも、その後ボタンが無効のままだったことも教えてくれません。リプレイは、コードが詰まった状態を生み出した一連の出来事そのものを提供します。

実務上、これはデバッグで最も時間のかかる工程、すなわち「再現」を消し去ります。一行のバグ報告から手順を推測する代わりに、ユーザーが実際にたどった経路をそのまま見られるのです。

バグ報告が届いたときの使い方

セッションの先頭から順に追うのではなく、障害地点から逆向きにたどってください。監視ツールでエラーを見つけ、リンクされたリプレイを開き、そのタイムスタンプへ飛びます。そこから30 秒だけ巻き戻すのがコツです。原因は症状の直前 30 秒に潜んでいることがほとんどで、セッションの冒頭にあることはまずありません。

確認するのは次の三点、この順序です。直前にユーザーが何をクリックしたか。失敗した、あるいは応答が返らなかったリクエストはないか。そして画面に表示されていたものが、描画されるはずだったものと一致していたか。大半のバグはこの三つのどれかで決着します。

リプレイでは解決できないこと

リプレイが示すのは何が起きたかであって、その人がなぜそうしたかではありません。ユーザーがフォームを離脱した場合、記録から分かるのは手が止まった項目だけです。その質問が分かりにくかったのか、立ち入りすぎだと感じたのか、単に長すぎたのかまでは分かりません。それは本人に尋ねて初めて分かることです。

集計的な問いにも向きません。一件の記録は逸話にすぎません。どれくらいの頻度で起きているかを知りたいなら、それはファネルやイベントの集計の仕事です。リプレイは離脱を説明するために使うものであって、測るために使うものではありません。

デバッグ目的で選ぶときの基準

デバッグが目的なら、他の何より次の三点を重視してください。コンソールとネットワークの記録。これがなければ無声映画を見ているのと同じです。エラーからリプレイへの直接リンク。例外から、それを生んだセッションへ一足飛びに移動できることが重要で、一覧を探し回るようでは意味がありません。そしてツールとしての有用性を保てるだけの細かなプライバシー制御です。すべての入力をマスクすればユーザーは守られますが、バグの引き金になった値まで隠れてしまいます。全か無かの切り替えではなく、項目単位のルールを備えたものを選んでください。