LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

エラー監視とは何か・ログ監視との役割分担

エラー監視・エラートラッキングとは、アプリケーションの実行時に発生した例外(エラー)を自動で収集し、発生元・発生頻度・影響ユーザー数を集約して開発者に通知する仕組みを指します。Sentryはこの領域の代表的なツールの一つです。

Sentry公式ドキュメントは、issue(問題)の考え方を次のように説明しています。「A typical application sends a large number of events to Sentry. You can think of an issue as a single bug or problem with your app」^*1。つまり大量のエラーイベントを、同一原因と推定されるもの同士でグルーピングし、1件の「issue」として管理する仕組みです。

ログ監視やAPM(Application Performance Monitoring、アプリケーションの応答速度・リソース使用状況を継続的に測定する仕組み)は、システム全体の稼働状況や性能傾向の把握を主目的にします。一方でエラー監視は、個々の例外1件ごとにスタックトレース(エラー発生時の呼び出し履歴)を保持し、原因特定を速める点に特徴があります。

Sentry公式ドキュメントは、issueへのグルーピングによって得られる効果を次のように述べています。「This grouping of events into issues allows you to see how frequently a problem is happening and how many users it’s affecting」^*1。発生頻度と影響ユーザー数を軸に問題の優先度を判断できる点が、エラー監視ツール特有の価値です。

本記事は、こうした例外(エラー)の収集・集約・通知に特化した仕組みの導入を外注で進める際の要点を整理します。監視基盤全体(メトリクス・ログ・トレースのインフラ監視)やクラッシュ率改善(モバイルアプリのクラッシュ計測)、SaaS監視のコスト最適化とは異なる、エラートラッキング固有の論点に絞って解説します。

DSN・リリース紐付け・ソースマップが導入の要点

Sentryなどのエラー監視ツールを導入する際、最初に設定するのがDSN(Data Source Name、SDKがエラーを送信する送信先を識別する接続文字列)です。アプリケーションにSDKを組み込み、DSNを設定することで、発生した例外がSentry側のプロジェクトに送信されるようになります。

次に重要なのがリリースとの紐付けです。Sentry公式ドキュメントは、リリース情報を提供する目的を次のように説明しています。デプロイのたびにリリース情報を送ることで「新しい問題とリグレッション(過去に解決した問題の再発)を識別し、問題が解決されたかどうかを判断し、新しくデプロイされたアプリの健全性を監視する」^*2ことができます。どのコミットが問題を引き起こしたかを推定し、担当者の特定にもつながる仕組みです^*2。

フロントエンド(JavaScript・TypeScript)開発では、ソースマップの設定も欠かせません。本番環境ではコードが圧縮・変換されているため、そのままではスタックトレースが読み取れません。Sentry公式ドキュメントは、ソースマップをアップロードする目的を「readable stack traces in your errors」^*3の実現と説明しています。圧縮前の元コードの行番号でエラー箇所を特定できるようにする設定です。

ソースマップの生成・アップロードは、本番ビルド時に行うのが前提です。Sentry公式ドキュメントは「Source maps are only generated and uploaded during production builds」^*3と明記しており、開発ビルドでは通常生成されません。webpack・Rollup・Vite・esbuild・TypeScript(tsc)など主要なビルドツールに対応した設定ガイドが用意されています^*3。

DSN設定・リリース紐付け・ソースマップという3点は、いずれもビルドパイプライン(CI/CD)への組み込みが必要です。アプリケーションコードの変更ではなく、デプロイフロー全体の見直しを伴う作業のため、既存のCI設定を理解した上での実装が求められます。

サンプリングとPII除去で運用コストと情報漏えいを抑える

エラー監視ツールを本番環境にそのまま適用すると、想定以上のイベント量が送信され、運用コストが増える場合があります。Sentry公式ドキュメントは、サンプリング機能の目的を次のように説明しています。「すべてのページロードやAPIリクエストのトレースをキャプチャするとシステムに望ましくない負荷が加わる」^*4ため、送信するイベント量を制御する機能が用意されています。

具体的には、エラーイベントの送信率(sampleRate)、パフォーマンストレースの送信率(tracesSampleRate)、セッションリプレイの記録率(replaysSessionSampleRateなど)をそれぞれ0から1の範囲で設定できます^*4。値を下げるほど送信データ量が減り、コストを抑えられる一方、検知の網羅性は下がるトレードオフがあります。

もう一つの重要な要点がPII(個人識別情報)の除去です。エラー発生時のスタックトレースやリクエスト内容には、氏名・メールアドレス・アクセストークンなどの機密情報が含まれる場合があります。Sentry公式ドキュメントは、プロジェクト・組織の設定を通じてこうした機密データを管理する複数のスクラビング(除去)機能を提供していると説明しています^*5。

具体的には、Sentryが標準で有効にするサーバーサイドでの自動スクラビング、保存前に機密情報を編集する高度なデータスクラビング、添付ファイルに対するスクラビング、セッションリプレイのプライバシー保護設定など、複数のレイヤーで対応する仕組みです^*5。個人情報保護の観点では、導入時にどの項目を除去対象にするかを事前に設計しておく必要があります。

アラート設計と既知エラーのノイズ抑制

エラー監視ツールを導入しても、通知が多すぎると開発チームが対応しきれなくなります。Sentry公式ドキュメントは、アラート機能の役割を「組織内の問題が事前定義したルールに一致したときにアクションを実行する」^*6ものと説明しています。

Issue Alert(問題単位のアラート)は、トリガー(問題の作成・割り当て・エスカレーションなどの状態変化)・フィルター(重要度や担当チームなどの条件)・アクション(Slack通知やチケット起票などの実行内容)という3段階で構成されます^*6。この3段階を組み合わせることで、重要度の高い問題だけを関係者に届ける設計が可能になります。

Sentry公式ドキュメントは、アラート設計の目標について「価値があり、うるさすぎないアラートを作ること」^*6と述べています。あらゆるエラーを同じ重要度で通知すると、対応の優先順位がつけられず、重大な問題が見落とされる可能性があります。

既知のエラーやビジネス上対応が不要なエラーへの対処として、issueをアーカイブする機能があります。Sentry公式ドキュメントによれば、アーカイブは「ノイズの多い問題を問題ストリームから移動させ、アラートを一時停止する」^*7ための機能です。永久にアーカイブするほか、指定期間・発生回数・影響ユーザー数を条件にした一時的なアーカイブも選べます^*7。アーカイブ中もイベント自体の記録は継続されるため、後から傾向を追うことができます^*7。

アラート設計とノイズ抑制は一度作れば終わりではありません。サービスの成長に応じてエラーの種類・量は変化するため、しきい値やフィルター条件を定期的に見直す運用が必要です。この見直しを怠ると、通知が形骸化し、重大な障害の検知が遅れるリスクがあります。

内製が難しい理由と外注に委ねる範囲

エラー監視ツールの導入自体は、SDKを組み込みDSNを設定するだけであれば短時間で完了します。しかし、リリース紐付け・ソースマップ・PII除去・サンプリング・アラート設計まで含めて実運用に耐える形に仕上げるには、複数の専門知識が必要です。

内製で対応する場合、CI/CDパイプラインの構成理解、フロントエンド・バックエンド双方のビルド設定、個人情報保護に関する社内ルールの把握、SlackやJiraなど通知先システムとの連携設定といった知識が求められます。これらを1人の担当者が兼務すると、他の開発業務を圧迫する可能性があります。

設定を誤ると、次のような影響が生じます。ソースマップが正しくアップロードされていないと、スタックトレースが圧縮後のコードのままとなり、原因特定に要する時間が延びます。PII除去の設定が漏れていると、機密情報を含むエラー詳細が監視ツール側に蓄積される状態になり、情報管理上の見直しが必要になります。

外注(委託)を検討する場合、委ねる範囲を次のように整理できます。第一に、SDK導入・DSN設定・CI連携までの初期構築です。第二に、リリース紐付け・ソースマップ・サンプリングといった運用品質を左右する詳細設定です。第三に、アラートルールの設計と、導入後一定期間の調整(既知エラーの仕分け・しきい値の見直し)です。

初期構築だけを外部に依頼し、運用は内製に切り替える体制もあれば、アラート調整まで含めて継続的に委託する体制もあります。自社の開発体制にCI/CDやフロントエンドビルドの知見を持つ人材がどの程度いるかによって、委託範囲を判断する必要があります。

発注準備で確認すべき項目

エラー監視の導入を外部パートナーに依頼する際は、事前に整理しておくべき情報があります。整理が不十分だと、要件のすり合わせに時間がかかり、着手が遅れる原因になります。

特に予算・データ量の想定は、契約前に共有しておくべき項目です。Sentryの料金は従量課金制であり、公式サイトによれば有料プランには月次の基本ボリューム(例としてエラー5万件など)が含まれ、超過分は使用量に応じた追加課金となります^*8。サンプリング設定の方針を事前に決めておくことで、想定外のコスト増を避けやすくなります。

また、既存のログ監視・APMの有無も重要な確認項目です。すでに監視基盤がある場合は、エラー監視ツールとの通知先・ダッシュボードの統合方法を合わせて検討する必要があります。逆に監視基盤が未整備の場合は、エラー監視の導入を足がかりに、監視体制全体の設計を見直す機会にもなります。

よくある質問

まとめ：エラー監視導入を外注で進める3つの判断軸

本稿では、エラー監視・エラートラッキング(Sentry等)の導入を外注で進める際の要点を整理しました。要点を3つに集約すると次の通りです。第一に、ログ監視・APMとは役割が異なり、個々の例外をグルーピングして原因特定を速める仕組みである点です。第二に、DSN設定・リリース紐付け・ソースマップ・サンプリング・PII除去・アラート設計という複数の専門領域を組み合わせる必要がある点です。第三に、外注する場合は初期構築・運用品質設定・アラート調整のどこまでを委託するかを、自社のCI/CD知見に応じて判断する必要がある点です。

導入後も、エラーの種類・量の変化に応じてアラートしきい値やノイズ抑制の設定を見直す運用が欠かせません。導入時点の設計だけで終わらせず、継続的な調整を前提に計画することが望まれます。

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Sentry「Issues」（Sentry Docs, product/issues）https://docs.sentry.io/product/issues/
2. *2　出典：Sentry「Releases」（Sentry Docs, product/releases）https://docs.sentry.io/product/releases/
3. *3　出典：Sentry「JavaScript Source Maps」（Sentry Docs, platforms/javascript/sourcemaps）https://docs.sentry.io/platforms/javascript/sourcemaps/
4. *4　出典：Sentry「Sample Rates」（Sentry Docs, concepts/key-terms/sample-rates）https://docs.sentry.io/concepts/key-terms/sample-rates/
5. *5　出典：Sentry「Scrubbing Sensitive Data」（Sentry Docs, product/data-management-settings/scrubbing）https://docs.sentry.io/product/data-management-settings/scrubbing/
6. *6　出典：Sentry「Alerts」（Sentry Docs, product/alerts）https://docs.sentry.io/product/alerts/
7. *7　出典：Sentry「Issue States and Triage」（Sentry Docs, product/issues/states-triage）https://docs.sentry.io/product/issues/states-triage/
8. *8　出典：Sentry「Pricing」（Sentry公式サイト）https://sentry.io/pricing/

Tweet