こんにちは！日々の開発、本当にお疲れ様です。

システムを運用していて、こんな経験はありませんか？
「本番環境でエラーが発生したけれど、スタックトレースを見ても原因がさっぱりわからない……。ユーザーが一体どんな操作をしてこのエラーにたどり着いたんだろう？」

エラーの通知を受け取っても、発生時の「文脈（コンテキスト）」がわからないと、原因究明はまるで暗闇の中での宝探しになってしまいます。

そんな開発者の救世主となるのが、エラートラッキングツール「Rollbar（ロールバー）」です。そして、Rollbarの真の力を引き出す秘密兵器が、今回ご紹介する「Custom Telemetry（カスタムテレメトリー）」機能です。

この記事では、エラーが発生する直前にユーザーが「何をクリックし」「どんなAPIを叩き」「どう画面を遷移したか」というユーザーの足跡（行動履歴）を自動で記録し、デバッグ効率を劇的に向上させる方法を、優しく丁寧に解説します。

これをマスターすれば、明日のデバッグ時間が10分の1になり、毎日の作業が劇的に楽になりますよ。一緒に一歩ずつ進めていきましょう！

—

1. なぜ「スタックトレース」だけでは不十分なのか？

一般的なエラートラッキングでは、以下のような「スタックトレース（エラーが発生したソースコードの行数）」が送られてきます。

TypeError: Cannot read property ‘id’ of undefined
at checkout.js:42:15
at dispatchEvent (dom.js:99:3)

確かに「どの行で落ちたか」はわかります。しかし、「なぜその変数がundefinedになってしまったのか？」という疑問には答えてくれません。

「ユーザーは、その前にどのボタンを押したのか？」
「直前のAPIリクエストは成功していたのか？」
「何か特殊な入力をして戻るボタンを押したのではないか？」

これら「エラーに至るまでのストーリー」をレコーディングしてくれるのが、RollbarのTelemetry（テレメトリー）機能です。

Rollbarは、エラーが発生した瞬間に、その直前数十秒〜数分間のユーザーの行動ログを巻き戻してエラーレポートに添付してくれます。これにより、まるでユーザーの画面を後ろから眺めていたかのように、一瞬で原因が特定できるようになるのです。

—

2. Rollbarの導入と最もシンプルな「Hello World」

まずは基本から始めましょう。今回は、最も直感的で効果を実感しやすい「ブラウザ（JavaScript）」環境を例に解説します。

ステップ1: HTMLにRollbarを導入する

まずは、Rollbarをプロジェクトにインストールします。
以下のコードをHTMLの``タグの最上部に貼り付けるだけで、Rollbarの自動監視がスタートします。

> プロの知恵袋： Rollbarのスクリプトは、他のスクリプト（アプリケーションのメインコードなど）よりも前に読み込ませてください。そうすることで、アプリ起動直後の初期化エラーも逃さずキャッチできます。

Rollbar Telemetry Demo

Rollbar テレメトリーデモ

動作確認：Hello World!

1. 上記のコードを `index.html` として保存し、ブラウザで開きます。
2. 「エラーを発生させる」ボタンをクリックします。
3. デベロッパーコンソールに `ReferenceError: nonExistentFunction is not defined` と表示されます。
4. Rollbarのダッシュボードを開くと、すでにエラーが届いているはずです！

—

3. Custom Telemetryでユーザーの「真の足跡」を記録する

自動で記録される「クリック」や「ネットワークリクエスト」だけでも強力ですが、開発を進めると、以下のような「ドメイン特有の重要なイベント」を記録したくなります。

「お気に入り登録」ボタンを押した（UIの変更だけでなく、状態の変化）
「カートに商品（ID: 102）を追加した」
「決済処理を開始した（金額: ¥5,000）」

これらを記録するのが「Custom Telemetry」です。Rollbarでは、`rollbar.captureEvent()` というAPIを使って、簡単に独自の足跡を残すことができます。

実装例：Eコマースの購入フローを模したデモコード

以下のコードを動かしてみましょう。ユーザーが「商品をカートに入れ」「決済ボタンを押して」「エラーが発生する」という一連の流れをシミュレートします。

極上コーヒーショップ

コードの解説

`rollbar.captureEvent()` を使うことで、アプリの重要な節目（マイルストーン）に目印（ブレッドクラム＝パンくずリスト）を置いています。
`metadata` の中に、商品の価格や決済手段など、デバッグ時に知りたい具体的な値を詰め込んでいます。ここが最も重要なポイントです！

—

4. 魔法の瞬間：Rollbarのダッシュボードで「足跡」を確認する

上記のデモコードを実行し、以下の順に操作してみましょう。

1. 「カートにプレミアム珈琲豆を追加」ボタンを押す。
2. 「注文を確定する」ボタンを押す（エラー画面が表示されます）。

この後、Rollbarのダッシュボードにログインし、発生したエラーの詳細画面を開いてみてください。
画面の下部に「Telemetry」というタイムラインセクションが表示されているはずです。

そこには、以下のようなタイムラインが美しく並んでいます！

[12:00:05] [DOM] click: button#add-cart-btn
[12:00:05] [Custom Log] (info): ユーザーがカートに商品を追加しました: Premium Coffee Bean
├ itemName: “Premium Coffee Bean”
├ price: “1800”
└ currentCartCount: 1
[12:00:10] [DOM] click: button#checkout-btn
[12:00:10] [Custom Log] (info): 決済処理を開始しました。
└ paymentMethod: “Credit Card”
[12:00:10] [Error] (error): 決済処理中に深刻なエラーが発生しました (ReferenceError: config is not defined)

いかがでしょうか？
「エラーが発生した」という事実だけでなく、「プレミアム珈琲豆（1800円）をカートに入れた後に、クレジットカード決済を選んで、決済ボタンを押した瞬間に落ちた」というストーリーが一目瞭然ですね。

これなら、ユーザーに「どんな操作をしましたか？」と問い合わせる必要もありません。再現環境を作るのも容易になります。

—

5. 現場で差がつく！Telemetryを汚さないための「ノイズ削減」の極意

Telemetryは非常に強力ですが、何でもかんでも記録すれば良いというわけではありません。ログが多すぎると、本当に必要な情報が埋もれてしまいます（これを「アラートノイズ」と呼びます）。

現場で実践すべき3つのルールをお伝えします。

ルール1: ループ処理や高頻度イベントの中では記録しない

`window.onscroll`（スクロール）や `mousemove`（マウス移動）といった、1秒間に何十回も発生するイベントの中で `captureEvent` を呼ぶのは絶対に避けましょう。Telemetryのバッファ（通常、直近の100件程度）が一瞬で埋まってしまい、本当に知りたい直前のアクションが消えてしまいます。

ルール2: 個人情報（PII）は絶対に含めない

パスワード、クレジットカード番号、本名、住所などの個人情報は、Telemetryの `metadata` に絶対に含めないでください。
Rollbarにはデータをマスク（隠蔽）する機能もありますが、実装段階で「IDやステータスコードなどの識別子のみを記録する」という癖をつけておくのが一流のエンジニアです。

ルール3: 意味のある「名詞＋動詞」にする

メッセージは `user clicked` のような曖昧なものではなく、`item_added_to_cart` や `navigation_to_checkout` のように、システム的な意味を持つ名前（イベント名）に統一すると、チームメンバーが見た時にも一瞬で理解できるようになります。

—

まとめ

Rollbarの Custom Telemetry は、エラーという「点」の情報を、ユーザー行動という「線」のストーリーへと昇華させてくれる、オブザーバビリティの極めて強力な機能です。

スタックトレースだけではわからない「原因の文脈」がわかる
`rollbar.captureEvent()` を要所に仕込むだけで、デバッグ効率が劇的に向上する
適切なフィルタリングとノイズ管理で、常に綺麗なログを保つ

この手法を一度体験すると、これまでの「暗闇の手探りデバッグ」には二度と戻れなくなるはずです。

あなたの開発するアプリケーションに、ぜひこの「光」を灯してみてください。毎日のエラー調査が、きっと少し楽しい謎解きゲームに変わりますよ。

何かわからないことがあれば、いつでも相談してくださいね。ハッピー・デバッグ！