React×Sentryで実現する実践的なエラー監視

ツール導入前の課題

Sentry 導入前、本番環境で発生するエラーを体系的に把握する手段がありませんでした。

• エラーが見えない: ユーザーのブラウザコンソールは確認できず、環境の多様性から再現も困難でした
• 影響範囲が不明: 1 人だけの問題なのか 1,000 人規模の問題なのか、判断する材料がありませんでした

どのような状態を目指していたか

• 本番エラーをリアルタイムに検知し、影響ユーザー数と環境情報を即座に把握できること
• サンプリング制御でコスト効率を保ちつつ、重要なエラーは確実にキャプチャできる運用にすること

Sentry の採用は、社内で 2 段階の比較検討を経て決まりました。本記事はフロントエンド視点ですが、実際の検討プロセスはバックエンド側から始まっていたのが実態に近いため、両方のフェーズを簡潔にご紹介します。

① 2017年2月：バックエンド（Rails）観点での調査

バックエンドでは当時 New Relic で計測していた本番エラー件数の規模感から、体系的な収集基盤の必要性が浮上していました。BE チームが料金モデルの柔軟性・SDK 対応・GitHub/Slack 連携を軸に複数サービスを比較した結果、2017 年 2 月に Sentry が従量課金モデルへ移行したタイミングで、データ量の伸びに追従しやすい Sentry が優勢になりました。

② 2017年5月：フロントエンド観点での再検討

FE チームではこの時期、「画面の読み込み中に止まる」といった問い合わせが続き、JavaScript のエラーが疑われる状況でした。minify された状態のスタックトレースでは原因を特定しづらく、Web 向けのエラー収集ツール導入を改めて検討することになります。

• Minify コードの原因特定能力 — Source Maps 対応の有無、CI/CD への組み込みやすさ
• 無料枠でのスタート可否 — 導入ハードルを下げるため、初期は無料枠で運用できること
• FE/BE 共通基盤化 — 既にバックエンド側で検討されていた候補との親和性
• サンプリング / ノイズ除外の制御性 — ユーザー起因の例外（ID/PW 入力ミス等）を除外しながら、無料枠に収める運用が可能か

最終的に Sentry を選んだ決め手は、次の 4 点です。

• FE/BE 基盤の統一: バックエンド側で先行して導入が動いていたため、フロントエンドも同じ基盤に寄せることで、エラー監視の一元化とノウハウの共有を同時に進められました
• Source Maps 運用の現実性: sentry-cli で複数ファイルを一括アップロードする流れが CI に組み込みやすく、minify されたスタックトレースでも元コード上で原因を特定できる体制を、最小限のコストで構築できました
• 無料枠とサンプリング設計の両立: sampleRate による動的サンプリングと ignoreErrors によるノイズ除外を組み合わせることで、10k events/月 の無料枠に収めつつ、重要なエラーは確実に拾える運用を実現できました
• 料金プランの追従性: 2017 年 2 月からの従量課金化により、エラー件数の変動に対して柔軟にコストを調整できる構造になっていた点も、採用の後押しになりました

こうして検討時に挙がった論点が、7 年以上たった今も運用の中核として生き続けていることは、Sentry を長く使い続けてきた理由のひとつでもあります。

改善したかった課題はどれくらい解決されたか

どのような成果が得られたか

上の Before / After に加えて、長く運用するなかで見えてきた成果もいくつかあります。

• エラーに向き合う文化の醸成: トリアージ定例が定着し、ノイズ排除から優先度付け、issue 化、担当アサインまでを一貫して回せるようになりました
• 動的サンプリングとクリティカルエラー 100% キャプチャの両立: デフォルト 25% サンプリングでコストを抑えつつ、重要なエラーは sampleRate タグで 100% 送信する、といった使い分けができるようになりました
• Debug Mode の仕組みづくり: 特定ユーザーのブラウザで数日間 100% エラーを収集できる独自機構を構築しました（カスタマーサポート連携としての実運用は、これから運用フローの整備とあわせて稼働させていく予定です）
• AI 自動トリアージの着手: 運用初週の時点で、AI が要対応と判定した issue を resolve するところまでは実際に到達しています
• リリース追跡の精度向上: リグレッションが入った PR までその場で遡れるようになりました

Sentry を入れて終わりではなく、ここに至るまでには、導入直後の技術・運用面の苦労と、その後の運用を続ける中で訪れたいくつかの再評価フェーズがありました。

導入当時の技術・運用面の課題

導入直後は、とにかくエラー監視の仕組みを整えること自体に手一杯でした。代表的には次のような壁にぶつかっています。

• 大量に飛んでくるエラーとノイズに埋もれ、本当に直すべきエラーが見えづらい状態でした
• イベント数ベース課金のためコストが高騰しやすく、全送信を続けるとすぐにプラン上限に達してしまいました
• 導入しても「エラーを見る」という文化がまだなく、有志頼みの運用になり、放置されるエラーも発生していました

運用中の再評価①：エラーに向き合う文化を根付かせるフェーズ

放置されるエラーを減らすため、フロントエンドと SRE の合同で「毎週のトリアージ定例」を発足させました。ここでノイズ排除・優先度付け・issue 化・担当アサインまでを一通り回すことで、エラーを見る／直すという行為が、属人的な有志活動から組織のルーチンへと少しずつ変わっていきました。この時期の一番大きな変化は、まさにこの「文化としての定着」だったと振り返っています。

運用中の再評価②：他ツールへの移行検討と Sentry 継続の判断

運用を続けるなかで、Datadog（RUM / Bits AI）への移行を検討した時期もありました。AI トリアージ機能（Bits AI）への期待と、サンプリングの柔軟性がそのきっかけです。検討して分かったことは大きく 3 点でした。

1. Datadog の費用評価: コスト面で見合わず移行は見送ることにしました
   • 費用を下げるにはサンプリングが必要ですが、その場合は Sentry と同等の機能を自前実装することが求められます
2. Sentry の再評価: 当時やりたかったことはひと通り実現できており、機能面で大きな不足は感じられませんでした
3. サンプリングの構造的課題: Sentry／Datadog のどちらを採用してもサンプリングは避けられず、問い合わせ対応時にログが取れないユーザーが一定数発生します
   • 対策としては、ツールに依存せず自前の API を用意する必要があるとの結論に至り、これがのちの Debug Mode の原型につながっていきました

運用中の再評価③：AI トリアージへの取り組み

トリアージ定例がうまく回るようになると、今度はまた別の課題が見えてきました。「毎週すべての issue を人力で確認して分類するのが、件数の増加とともに現実的でなくなってきた」という悩みです。ノイズを除外しつつ、対応すべきエラーだけを浮上させるトリアージそのものを、何らかのかたちで自動化する必要が出てきました。

私たちが求めていたのは「ノイズを削減し、対応すべきエラーだけを浮上させるトリアージ支援」でしたが、Sentry 公式の Seer は根本原因特定と自動修正提案が軸足で、ねらいとはスコープが合いませんでした。また、Datadog Watchdog や Bits AI は前提となるデータ送信先が Sentry ではないため、選択肢から外れました。最終的には、GitHub Actions と Claude Code で自作のトリアージワークフローを構築する方針に着地しています。

結論としては、他ツールへ移行するのではなく、Sentry と自前の仕組み（Debug Mode ／ 自作 AI トリアージ）の組み合わせで運用を強化していく方向を選びました。

ツールだけでなく組織的プロセスをセットで設計する

Sentry を導入しても、エラーを日々見る習慣がなければ、やはりエラーは放置されてしまいます。定期トリアージ会議（フロントエンドと SRE の合同など）をツール導入とあわせて始めることで、エラーに向き合う文化がようやく根付き始めます。ツール選定よりも先に運用設計を考えておくことを、個人的には強くおすすめしたいポイントです。

動的サンプリング + フィルタリング戦略を最初から

イベント数ベース課金の性質上、全エラーを送っているとプラン上限にすぐ到達してしまいます。beforeSend で動的サンプリング（通常 25%、クリティカル 100%）とノイズフィルタリング（ignoreErrors、thirdPartyErrorFilter）をあわせて導入することで、コストの急激な増加を防げます。

Sentry 運用を「検知から対応文化までを貫く基盤」へと、さらに育てていくことを目指しています。具体的には、Debug Mode を発展させた「ユーザー能動型バグ報告」の仕組みや、自作 AI トリアージの高度化を検討しているところです。ツールと運用、そして AI 基盤を一体で設計していく領域として、Sentry は今後も中核に据えていく予定です。