こんにちは!プロダクトの開発現場で、日々エラーとの格闘にお疲れ様です。
「ユーザーから『なんか画面が固まって動かないんです』と言われた。でも、手元の開発環境で再現させようとしても、エラーログには `TypeError: Cannot read properties of undefined` とだけ出ていて、一体ユーザーがどんな神業的な操作をしたのかサッパリ分からない……」
夜中にこんなバグ報告を受けて、天井を見上げた経験はありませんか?私は何度も有ります。
そんな現代のフロントエンド開発における「デバッグの迷宮」を、一撃で光の彼方に吹き飛ばしてくれるのが、今回ご紹介する Sentryの「セッションリプレイ(Replays)」機能 です。
これをマスターすれば、「ユーザーが何をポチったか分からない」という恐怖から解放され、毎日の保守作業が劇的に楽になりますよ。さあ、一緒にその扉を開けてみましょう!
—
1. セッションリプレイ機能の概要とプライバシー配慮の仕組み
セッションリプレイとは何か?
セッションリプレイとは、一言で言うと「ユーザーのWebブラウザ上での操作を、まるでビデオカメラで撮影したかのように動画(風)で再現する機能」です。
従来のSentryは、「どこで・どんなエラーが起きたか(スタックトレース)」を教えてくれましたが、リプレイ機能はその前後にユーザーが「どのボタンを押し、どこへスクロールし、どんなテキストを入力したか」を視覚的に追体験させてくれます。
「でも、パスワードや個人情報が盗まれるんじゃ…?」という懸念
ここで鋭いエンジニアなら、「画面をそのまま録画するなんて、ユーザーの入力したパスワードやクレジットカード番号がSentryのサーバーに丸見えになるのでは?」と心配するはずです。当然の懸念ですね。
ご安心ください。Sentryのセッションリプレイは、デフォルトで鉄壁のプライバシー保護が組み込まれています。
1. テキストのマスク(隠蔽): デフォルトですべてのテキスト入力(`` や `
プライバシーを守りながら、バグの原因だけを鮮やかに浮き彫りにする。これがSentryのスマートな設計思想です。
—
2. フロントエンドアプリへのリプレイ機能の組み込み手順
それでは、実際にReact(またはVite/Next.jsなどのモダンな環境)を想定して、Sentryのセッションリプレイをあなたのアプリに組み込んでみましょう。
驚くほど簡単です。数分で終わります。
Step 1: SDKのインストール
まずは、プロジェクトのルートディレクトリで必要なパッケージをインストールします。すでにSentryを導入している場合でも、リプレイ用のパッケージ(`@sentry/replay`)を追加する必要があります。
npmの場合
npm install –save @sentry/react @sentry/replay
yarnの場合
yarn add @sentry/react @sentry/replay
Step 2: 初期化コード(`sentry.config.js` 等)の設定
アプリのエントリーポイント(`main.tsx` や `index.js` など)でSentryを初期化している箇所を以下のように書き換えます。
import as Sentry from “@sentry/react”;
Sentry.init({
dsn: “YOUR_DSN_HERE”, // あなたのSentryプロジェクトのDSNを指定
// 1. パフォーマンス監視のための設定(リプレイと相性が良いです)
integrations: [
// リプレイ統合を有効化
Sentry.replayIntegration({
// マスク(伏せ字)する範囲のカスタマイズ
maskAllText: true, // すべてのテキストをマスク(推奨)
blockAllMedia: true, // 画像や動画要素をブロック
}),
],
// 2. サンプリングレートの設定(重要!)
// すべてのセッションを記録するとデータ容量が爆発するので調整します
replaysSessionSampleRate: 0.1, // 通常セッションの10%を記録
replaysOnErrorSampleRate: 1.0, // エラーが起きたセッションは「100%」確実に記録!
});
> 💡 先輩からのアドバイス:「エラー時100%」の魔法
> 上記の設定では、普段の操作は10%の確率でしか記録しませんが、「エラーが発生した瞬間」のセッションは100%の確率でビデオに保存されます。これにより、ストレージコストを抑えつつ、見逃したくないバグの瞬間を確実に捕らえることができます。
—
3. エラー発生前後のユーザー行動を動画で視覚的に追体験するデバッグ手法
セットアップが終わったら、実際にアプリを動かしてエラーを起こしてみましょう。
Sentryダッシュボードでの確認ステップ
1. Sentryの管理画面にログインし、「Issues(課題)」タブを開きます。
2. アプリで発生させたエラーをクリックして詳細画面を開きます。
3. 画面の右側(またはタブ内)に、「Replay」というセクションが出現しているのを確認してください。
そこには、YouTubeのプレイヤーのような動画再生バーが表示されています。
ここがスゴい!「タイムライン連動型」デバッグ
再生ボタンを押すと、ユーザーがエラーに至るまでの操作が再現されますが、ただの動画ではありません。
- ネットワークリクエストの同期: 「動画のこの秒数で、API(`/api/v1/users`)が 500 Internal Server Error を返した」ということがタイムライン上に視覚的に同期されます。
- コンソールログの同期: ユーザーが操作している最中に、ブラウザのコンソールにどんなWarningやErrorが出ていたかがミリ秒単位で一致します。
「あぁ!ユーザーは、まずこのプルダウンで『その他』を選んで、次にこの空欄のまま送信ボタンを連打したから、このバリデーションエラーを踏んだんだな!」
これが一発で分かるのです。もう「再現手順を教えてください」とユーザーに不毛な問い合わせをする必要はありません。
—
4. 再生データ量の削減とコストコントロールのコツ
セッションリプレイは非常に強力ですが、DOMの動きを細かく記録するため、使い方を誤るとSentryのクォータ(上限枠)をすぐに食い潰してしまいます。
現場で予算オーバーを起こさないための、プロのコストコントロール術を3つ伝授します。
① プライベートな画面や不要なページは最初から除外する
例えば、ダッシュボードの複雑なグラフ画面や、単なる静的LPなど、「エラーが起きても大した影響がない場所」「個人情報が多すぎる場所」では、コード側でリプレイを停止させることができます。
// 特定のコンポーネント内やページ遷移時にリプレイを一時停止・制御する
Sentry.getCurrentHub().getIntegration(Sentry.Replay)?.stop();
② マスクの粒度を調整して、必要十分な情報だけ残す
すべてを厳格にマスク(`maskAllText: true`)すると、デバッグ時に「ユーザーがフォームに何と入力したか」まで分からなくなって困る場合があります。そんな時は、CSSクラスでコントロールしましょう。
- クラスに `sentry-block` を付与した要素:完全に非表示(黒塗り)
- クラスに `sentry-unmask` を付与した要素:マスクを解除してテキストを可視化
③ サンプリングレートをサービスフェーズに合わせてチューニングする
- 開発・ステージング環境: `replaysSessionSampleRate: 1.0` (ガンガンテストして挙動を確認)
- 本番環境(初期リリース・大規模サービス): `replaysSessionSampleRate: 0.01` (1%程度に絞る)、ただし `replaysOnErrorSampleRate: 1.0` は死守。
—
まとめ
Sentryのセッションリプレイは、単なる「画面の録画ツール」ではありません。「フロントエンドエンジニアとユーザーの体験のギャップを埋める、最強のタイムマシン」です。
これを導入すれば、バグ調査のために何時間もローカル環境で首をひねる時間が消え、純粋にコードを書く楽しい時間だけが残ります。
「これをマスターすれば、毎日の作業が劇的に楽になりますよ。」
ぜひ今日のタスクの合間に、あなたのアプリケーションへ組み込んでみてください。未来のあなたが、きっと過去のあなたに感謝するはずです。
それでは、快適なオブザーバビリティライフを!