Error Reporting

解決する課題

本番アプリでは、同じ原因のエラーが大量に発生してログを埋め尽くし、肝心の「どのエラーが、いつから、どれだけ起きているか」が見えなくなりがちです。Error Reporting は、こうしたエラーを 自動でグループ化 して把握しやすくします。

• 大量のエラーログの中から 同じ原因のものをまとめて 件数や傾向を知りたい
• 新しく出始めたエラー や、収束したはずの 再発 に素早く気づきたい
• どのエラーを 優先して対応すべきか を発生頻度や影響範囲から判断したい
• エラーの発生を メールなどで通知 し、ダッシュボードを常時見なくても見逃さないようにしたい

主要概念と用語

Error Reporting は Google Cloud Observability の一部で、Cloud Logging に取り込まれたエラーから集計を行います。

• エラーグループ（Error Group）: 同じ原因と判断されたエラーの集合。スタックトレースの内容などから自動でまとめられ、重複した個別エラーを 1 つの単位として扱える
• エラーイベント（Error Event）: 個々のエラー発生 1 件。グループ化される前の生のエラーに相当する
• グループ化（Grouping）: スタックトレースのフレームやメッセージをもとに、同じバグに由来するエラーを 1 グループへ束ねる処理
• 発生回数 / 影響ユーザー数: グループごとの発生件数や、影響を受けたユーザー数。優先度付けの指標になる
• 新規エラー（New / Resolved）: 初めて観測されたエラーグループや、いったん解決として扱った後に再発したグループ。ステータスで管理できる
• 通知（Notification）: 新しいエラーグループの発生などを契機にメール等へ知らせる仕組み
• 計装の要否: 多くの言語/ランタイムでは、適切な形式でログ出力されたエラーから自動集計される。クライアントライブラリで明示的にエラーを報告することもできる

仕様・制限・クォータ

• Error Reporting は Cloud Logging に取り込まれたログ のうち、エラーと判定できるものから集計する。したがってエラーがログに出ていることが前提になる
• グループ化は スタックトレースなどの内容 に基づくため、トレースが不完全だと意図どおりにまとまらないことがある
• 集計対象や保持には 期間の制約 があり、古いデータは参照できなくなる。長期保管が必要なら別途ログをエクスポートする
• 対応するランタイムや、自動で認識されるエラーログの形式には条件がある。形式が合わないエラーは取りこぼされ得る
• 具体的な保持期間や対応言語の詳細は変動するため、設計時は最新の公式ドキュメントで確認する

内部の仕組み

アプリが出力したエラーログは、まず Cloud Logging に取り込まれます。Error Reporting はその中からエラー（多くは例外スタックトレースを含むログエントリ）を抽出し、スタックトレースの構造やメッセージ をもとに同一原因と思われるものをグループへ束ねます。グループ単位で発生回数・初出時刻・直近の発生・影響ユーザー数などを集計し、ダッシュボードに一覧表示します。

多くの言語では、標準的な形式でスタックトレースをログ出力していれば追加の計装なしに集計されます。より確実に報告したい場合や、捕捉済み例外を明示的に送りたい場合は、クライアントライブラリやログ連携を使ってエラーを報告します。

設計パターン / ベストプラクティス

• 例外は スタックトレース付きで構造化ログ として出力し、Error Reporting が認識・グループ化しやすい形にする
• 新規エラーグループの発生を 通知 に連携し、リリース直後に出始めたエラーへ素早く気づけるようにする
• グループの 発生回数や影響ユーザー数 を見て対応優先度を決め、件数の多い／影響範囲の広いものから着手する
• 対応済みのグループは 解決済みとして管理 し、再発したら検知できるようにしてノイズと未対応を区別する
• エラーログに バージョンやサービス名 を含め、どのデプロイで増えたかを切り分けられるようにする
• メトリクス（Cloud Monitoring）やトレース（Cloud Trace）と併用し、エラーの増加を起点に原因区間へ掘り下げる

運用・監視

• エラーが集計されない → そもそもエラーがログに出ているか、スタックトレースの形式が認識される形か、Cloud Logging に取り込まれているかを確認
• グループ化が粗い／細かすぎる → ログ出力のスタックトレースが不完全でないか、メッセージに毎回変わる値（ID など）が混ざっていないかを確認
• 通知が来ない → 通知設定の有効化と宛先、対象とするエラーの条件を確認
• リリース回帰の検知 → デプロイ前後で新規エラーグループや発生回数の急増がないかを確認し、悪化したバージョンを切り分ける
• 優先度付け → 発生回数だけでなく影響ユーザー数も見て、少数でも広範囲に影響するエラーを見落とさない

コスト

Error Reporting 自体の集計機能は、Cloud Logging に取り込まれたログを対象にする付加機能としての位置づけです。そのため、実務上のコストの主な変動要因は 元になるログの取り込み・保持（Cloud Logging 側）にあります。

セキュリティ

• Error Reporting の閲覧・編集権限は IAM ロール で最小化し、必要な担当者のみがエラー詳細を参照できるようにする
• エラーログには 個人情報や機微情報を含めない。例外メッセージにリクエストの中身やトークンをそのまま出すと、ログ経由で意図せず流出し得る
• スタックトレースに機微データが混ざり得る場合は、ログ出力の段階でマスキング してから出す
• アプリからのエラー報告は、キー JSON ではなく アタッチされたサービスアカウント（GKE では Workload Identity）を使い、鍵漏洩のリスクを避ける

関連サービス・比較

Error Reporting は単独ではなく、Observability の他サービスと組み合わせて使います。役割の違いを押さえます。

GCP 内では、ログ収集は Cloud Logging、メトリクスは Cloud Monitoring、遅延の可視化は Cloud Trace が担い、Error Reporting は「エラーをまとめて気づく」ことに特化します。これらを併用して可観測性を構成します。

ハンズオン / CLI例

# プロジェクトで Error Reporting API を有効化する
gcloud services enable clouderrorreporting.googleapis.com --project=PROJECT_ID

# 閲覧担当者にエラー閲覧の権限を付与する
# （roles/errorreporting.viewer が参照に必要なロール）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:dev@example.com" \
  --role="roles/errorreporting.viewer"

# エラーグループの一覧参照に専用の gcloud コマンドはない。
# Cloud Console の Error Reporting 画面、または Error Reporting API
# （projects.groupStats.list / projects.events.list）を使う。