🔍

「エラー発生時の状況を楽に正確に再現」Sentry Session Replayを活用する

2025/03/11に公開

導入の背景

フロントエンドのエラー発生時「状況再現」にに困ること、しばしばないでしょうか?

「Sentryにエラーが来た。エラーの内容はわかるが、これどういう経緯で発生したんだ、、??」
という調査に時間がかかることが多く、なんとかしたいなと考えていました。

このような「エラー発生時の状況再現」に非常に便利なのがSentry Session Replay(以後Session Replay)です。

Session Replay導入の結果「状況再現」が精度良く、かつ迅速に行えるようになり、エラーの修正が非常に楽になりました。

ただ導入前は「具体的にどういうことができるんだ?」というイメージがあまり明確になっておらず、もっと早くから導入すればよかったという反省があります。

また、導入した際も費用などの点で事前に注意が必要そうだなと感じた点がいくつかありました。

この記事では実際の導入画面等を掲載しつつ簡単に感想を述べたいと思います。
「Session Replayってこんな感じなんだ〜」と感じて頂けると嬉しいです。

Sentry Session Replayとは

https://docs.sentry.io/product/explore/session-replay/web/

Session Replay allows you to see video-like reproductions of user sessions which can help you understand what happened before, during, and after an error or performance issue occurred. You'll be able to gain deeper debugging context into issues so that you can reproduce and resolve problems faster without the guesswork. As you play back each session, you'll be able to see every user interaction in relation to network requests, DOM events, and console messages. It’s effectively like having DevTools active in your production user sessions.
セッション・リプレイでは、ユーザー・セッションをビデオのように再現して見ることができ、エラーやパフォーマンスの問題が発生する前、発生中、発生後に何が起こったかを理解するのに役立ちます。問題に対するより深いデバッグ・コンテキストを得ることができるため、推測作業なしで問題を再現し、迅速に解決することができます。各セッションを再生すると、ネットワーク・リクエスト、DOMイベント、コンソール・メッセージに関連するすべてのユーザー・インタラクションを見ることができます。事実上、本番のユーザー・セッションでDevToolsをアクティブにしているようなものです。

「推測」をできるかぎりなくし、「何が起きたか」を精度よく観測できるツールですね。

実際の画面

個人的にはこの機能は、画面を見た方がイメージつきやすいと思うので
早速一連の画面を紹介します。

左のタブから、「Replays」を選択します。

キャプチャしたSessionがずらっと並びます。

2025-03-11-21.06.56.png

エラー発生時のSessionを確認したい場合は、「ERRORS」を押して、エラー発生数で降順に並べ替えましょう。
(Fireマークの横にはそのSessionで発生したエラー数が表示されます)

2025-03-11-21.06.56-2.png

適当なSessionを押して、詳細画面を見てみましょう。

2025-03-11-21.06.56-4.png

Sessionの詳細ページはこんな感じです。

2025-03-09-21.32.06.png

「Breadcrumbs」のタブを選択した状態(詳細ページを開くとデフォルトで表示されるページ)には、Session(ユーザによる一連の操作)の流れにそって発生したイベントが表示されます。

  • Reload
  • Web Vital
  • User Click
  • Error
  • Page Load

など、主要なイベントが表示されています。

画面中央部には、操作した実際の画面を模擬したものが表示されています。 (セキュリティの観点で、文字列・画像などはマスクすることが可能です)

イベントが発生した時点での画面の模擬が表示されるので、エラー発生時の画面がイメージしやすくなっています。

2025-03-11-21.20.50.gif

他にも、タブの切り替えで様々な情報が確認できます。

2025-03-09-21.43.19.png
Console / コンソールへの出力を確認できます

2025-03-09-21.47.44.png
Network / Session内でのリクエストを時系列で確認できます

2025-03-09-21.43.19.png
Errors / 複数のエラーが発生した際など、一覧で見れて便利です

2025-03-09-21.51.40.png
Trace / エラーとその他イベントをタイムラインで確認できます

2025-03-09-21.54.48.png
Memory / 負荷がかかっている処理の特定に役立ちます

2025-03-09-21.56.01.png
Tags / Session Replay取得時の関連情報を確認できます

Session ReplayとIssueの関連付け

Session Replayを活用すると、Issueの詳細ページに、「Session Replay」の項目が現れるようになります。

2025-03-09-21.32.59.png

Replayの概要はこの画面で確認ができます。
詳細に情報を確認したい場合は右の「See Full Replay」を押すと、先ほどのSession Replay詳細ページに飛ぶことができます。

Issueの詳細ページではでSession Replayの内容ををさっと見て原因にアテをつけて、
もっと掘り下げたくなったらSession Replayの詳細ページに飛んで調査を進めるという使い方ができます。

数ヶ月運用した感想

  • Slack/Mailでエラー通知が飛んでくる
  • Issueを見る

といういつもの流れで、「何のエラーが発生したのか?」だけでなく「どうやって発生したのか?」の情報が楽に得られます。

億劫な状況再現・確認をシームレスに行うことができ、修正の着手までの時間を短縮することができます。

導入方法

https://docs.sentry.io/platforms/javascript/session-replay/

基本的にこのページに従っていけば導入までスムーズに完了します。
(本記事では詳細な導入手順は割愛します)

注意点

https://sentry.io/pricing/

この記事では、詳細な導入検討事項・方法については記述しませんが一つだけ注意点です。
「想定外の費用の発生」を防ぐために、料金形態について注意が必要です。

「Session Replay」には、「追加料金無しで利用できる枠(無料枠と呼ぶことにします)」があり、超えた分は従量課金となります。

Developer、Team、Businessプランは全てその枠が
「50 Session/月」
なので、現実的には従量課金での利用が前提となるかと思います。

とりあえず2点、気をつけたほうがいいかなと思いました。

1. 従量課金の予算を適切に設定する

先に記載の通り、Session Replayは無料枠ではほぼ間違いなく足りなくなるので
従量課金での利用が必要となる場合が多いかと思います。

従量課金(PAG = Pay As you Go)枠を適切に設定しておかない(とりあえず大きな値にしておく等)と、請求額に驚くことになるので注意です。
(後述のもう一つの注意点の設定を誤っても、こちらの予算枠適切に設定しておけば予期せぬ課金を防ぐことはできます。)

2. replaysSessionSampleRateを抑えめに、replaysOnErrorSampleRateはできれば「1.0」に設定する

https://docs.sentry.io/platforms/javascript/session-replay/#sampling

公式のデフォルトの設定を記載します。

// This sets the sample rate to be 10%. You may want this to be 100% while
// in development and sample at a lower rate in production
// これはサンプルレートを10%に設定します。開発中は100%にして、
// 本番環境ではより低いレートでサンプリングすることをお勧めします
replaysSessionSampleRate: 0.1,
// If the entire session is not sampled, use the below sample rate to sample
// sessions when an error occurs.
// セッション全体がサンプリングされない場合、エラー発生時にセッションを
// サンプリングするために以下のサンプルレートを使用します
replaysOnErrorSampleRate: 1.0,

Session Replayの活用ケースは
「エラーが発生した時の状況再現」が多いかと思います。

そんな時に「取れてなかった!」という事態を防ぐためには、「replaysOnErrorSampleRate」を「1.0」にしておく必要があります。
(エラーの数がめちゃくちゃに多い場合には、あっという間に課金額が跳ね上がる可能性があるので注意しましょう。)

一方、「replaysSessionSampleRate」についてはユーザのアクセス数によって本当に大きく変動します。
まずは控えめにして、ダッシュボードでサンプリングした数を眺めながら調整しましょう。


100%を超えており、従量課金となっている様子

ちょっとお得に利用する方法

https://docs.sentry.io/pricing/

いわゆる「ボリュームディスカウント」に加え「リザーブドディスカウント(適切な表現かはわからない)」が適用されます。
事前に枠を買っておくと割引というやつです。(AWSのリザーブドインスタンス的な)
20%位割引効くので、結構嬉しいですね。

サブスクリプションの管理画面から設定できるので、「これくらいは使う」というラインがわかっているのであれば活用すると良いと思います。

まとめ

手軽に利用を開始でき、「エラー発生時の状況再現を楽にする」ツールとしてSession Replayが便利だったので簡単にまとめました。

料金には注意が必要ですが、導入も楽でおすすめなツールです。

Discussion