Error Tracking

エラーログを 1 件ずつ読む運用はなぜ破綻するか

エラーは 1 件ずつ見ると、どれも同じくらい緊急に見えます。実際には同じ不具合が利用者の数だけ繰り返し記録されているだけで、対処すべき「問題」の数はずっと少ないはずです。Datadog の Error Tracking はこの差を埋める機能で、数千件の類似エラーを 1 つの Issue にまとめます (2026 年 9 月時点・出典: Error Tracking)。まとめ方は、エラーの型、メッセージ、スタックトレースといった属性から指紋 (fingerprint) を計算し、同じ指紋を持つエラーを同じ Issue に入れる、という規則です (出典: Error Tracking Explorer)。Issue には、影響を受けたユーザーの数、最初に起きた時刻、原因と疑われるコミットが付きます。「今日エラーが 3,000 件」という報告が「未対応の Issue が 4 つ、うち 1 つは今日初めて出た」に変わると優先順位の会話が成立し、検索結果を目で束ねる作業が要らなくなります。

3 つの出所 - RUM / APM / ログで拾える情報の違い

Error Tracking はエラーの出所を 1 つに限定しません。ブラウザーとモバイルの SDK、APM のトレース、ログの 3 系統から取り込み、Explorer の Sources フィルターで All / Browser / Mobile / Backend を切り替えて 1 つの一覧で扱えます (2026 年 9 月時点・出典: Error Tracking Explorer)。出所によって Issue に付く情報が違います。

フロントエンドの Issue は RUM のセッションと結び付くため「何人に影響したか」が出ます。バックエンドの Issue は APM のトレースと結び付くため「どのリクエストのどの処理で起きたか」に直結し、APM 由来なら Exception Replay が例外発生時の変数の値まで残します (出典: Error Tracking)。ログ管理由来の Issue は、SDK を入れられない既存システムのエラーも束ねられます。

一覧で何が見えるか - New / Regression / Crash の印と並べ替え

Explorer の一覧では、Issue ごとにエラーの型とメッセージ、発生元ファイルのパス、初回と最終の発生時刻、発生回数の推移グラフ、選択期間内の件数が並びます (2026 年 9 月時点・出典: Error Tracking Explorer)。Issue には印が付き、初回発生から 2 日未満で状態が FOR REVIEW のものは New、解決済みだったものが新しいバージョンで再び起きると Regression、アプリがクラッシュしたものは Crash と表示されます。並べ替えは Relevance (古さ、直近の件数と急増、クラッシュの有無を組み合わせた優先度)、Count、Newest、Impacted Sessions の 4 種です。絞り込みはファセットで行い、error.type や error.handling (処理済みか未処理か) で切れます。APM 由来のエラーは、親スパンが成功を返していれば handled と判定されます。

Issue の 5 つの状態と自動遷移

Issue には 5 つの状態があり、全て FOR REVIEW から始まります (2026 年 9 月時点・出典: Issue States in Error Tracking)。

この状態遷移の値打ちは自動化にあります。担当を割り当てた瞬間に REVIEWED になり、直したものは 14 日間静かなら RESOLVED になるので、人が手で閉じる作業がほとんど要りません。解決済みの Issue が新しいバージョンで再び起きると Regression として自動で戻ってくるため、「直したはずのバグ」がリリース判定に上がってきます。この再発検知はサービスに versionタグが付いていることが前提で、タグ付けの規約に version を含めておく意味がここでも出ます。

通知は件数のしきい値ではなく「新しい Issue」で切る

エラー件数にしきい値を置くアラートは、既知の Issue の増減でも鳴ります。Error Tracking には専用のモニター種別があり、新しい Issue が現れたとき、または影響の大きい Issue が出たときに通知できます (2026 年 9 月時点・出典: Error Tracking Explorer)。Explorer で組んだ検索条件はそのままモニターの対象範囲として書き出せるので、「決済サービスの Backend で New の印が付いた Issue」のような条件を、一覧で確認した絞り込みから直接モニターにできます。この設計の効き目は、通知の母数が「件数」から「Issue の出現」に変わる点にあります。1 つの不具合が 1,000 回起きても通知は 1 回で、直したはずの不具合が Regression として戻ってきたときも同じ経路で知らせが来ます。全体の傾向は件数で、対処すべき新事象は Issue で、と役割を分けるのが運用しやすい形です。

料金はどう乗るか

Error Tracking はエラーの出所となる各製品の上で動くため、課金もまず RUM / APM / ログの各製品側の単位で発生します (単位の考え方は料金体系の読み解き方を参照)。Error Tracking 単独の単価は本記事では扱わず、独立した SKU の有無と単価は Datadog Pricing で確認してください。公式ドキュメントには、Issue を EXCLUDED にすると新しいエラーの収集が止まり、使用量と課金に数えられなくなると明記されています (2026 年 9 月時点・出典: Issue States in Error Tracking)。想定内の例外の除外は費用面でも意味を持ちます。また、バックエンドは APM のトレースとは別に、SDK の計装から Error Tracking へエラーを送る Standalone Backend Error Tracking の導線もあります (出典: Backend Error Tracking)。

Sentry と同じことができるのか

エラーを Issue に束ねる、状態を回す、再発を検知するという骨格は Sentry のようなエラー監視専業ツールと重なります。違いは Issue の隣に何があるかで、Datadog では同じ画面からエラースパンのトレース、関連ログ、ホストのメトリクスへ移れる点が設計の中心です。Sentry 側が勝る面を含めた比較と、併用か置き換えかの判断は Datadog と Sentry の比較で扱っているので、本記事では Datadog 内の仕組みに話を絞ります。

ログのエラー検索から Issue の推移へ運用を変える順序

最後に、既にログでエラーを検索している組織が Error Tracking へ運用を移す順序を示します。全部を一度に切り替える必要はありません。

順序の要点は 1 と 3 です。最初に 1 系統だけで「件数 → Issue 数」の縮み方を実測すると、この機能に払う手間の見返りが数字で分かります。3 を先に済ませないと、想定内の例外が FOR REVIEW に居座って日課が形骸化します。ここまで整うと、障害対応の起点が「ログを検索して同じものを目で束ねる」から「Issue の一覧で新しい束と戻ってきた束を見る」に変わり、調査の最初の 10 分が問題の切り分けそのものに使えるようになります。