こんにちは！開発現場の「夜中のアラートで起こされるストレス」や「Slackが通知の津波で埋もれて肝心の情報が見えない絶望感」に、そろそろ別れを告げませんか？
今回は、世界中のエンジニアに愛されているエラートラッキングツール「Sentry」の通知連携を極め、「本当に対応が必要なエラーだけを、最高に分かりやすい形でチームに届ける」ための実践的なノイズ削減術を伝授します。
これをマスターすれば、毎日の作業やオンコールのストレスが劇的に楽になりますよ。さあ、一緒に「静かで、かつ的確なオブザーバビリティの世界」へ踏み出しましょう！
—
1. なぜ「デフォルト通知のまま」だと地獄を見るのか？
Sentryを導入して最初にやりがちなのが、「とりあえずプロジェクトを作って、Slackのチャンネルをポチッと繋ぐ」という初期設定です。
これ、実は現場のエンジニアにとっては「テロ」に等しい状態を生み出します。
- 通知地獄の正体：
- ユーザーのブラウザ拡張機能（AdBlockなど）が引き起こすスクリプトエラー
- ネットワークが不安定なユーザーによる、どうしようもないタイムアウト
- 開発環境やステージング環境からのゴミエラーの乱れ打ち
- 「1回起きたら終わり」ではなく、ユーザーがリロードするたびに飛んでくる同一エラーの連投
結果として、Slackのチャンネルは1日に何百件ものアラートで埋め尽くされ、誰も通知を見なくなります。「狼少年」状態の完成です。 本当にクリティカルな本番障害が発生したとき、その重要なお知らせは、無数のノイズの海の底へ沈んでしまうのです。
優れたオブザーバビリティとは、「すべての情報を集めること」ではなく、「ノイズを限界まで削ぎ落とし、シグナル（本質的な異常）を際立たせること」に他なりません。
—
2. 基礎知識：Sentryの通知の軸を知る（Issue Alert と Metric Alert）
Sentryで通知をコントロールするためには、まず2つのアラート機構の役割を明確に区別する必要があります。ここが設計の分かれ道です。
[Sentryの監視・通知の2大柱]
├── 1. Issue Alert (エラートラッキングの主役)
│ └─ 「特定のバグ・例外が発生したとき」に発火（例: NullPointerExceptionが起きた）
└── 2. Metric Alert (外形監視・SLAの守り神)
└─ 「数値の変動や閾値を超えたとき」に発火（例: エラー率が5分間で5%を超えた）
- Issue Alert（イシューアラート）：
「新しいバグが起きた」「既存のバグが再発した」という個別の事象（Issue）単位でフックします。開発者がデバッグするための詳細なスタックトレースを伴う通知に向いています。
- Metric Alert（メトリックアラート）：
「エラーの発生頻度」や「トランザクションの遅延（レイテンシ）」などを時系列で監視し、「一定の閾値を超えた瞬間」に発火します。例えば、「直近10分で500エラーが100件を超えた場合のみ通知する」といった、深夜の安眠を守るための防波堤として機能します。
今回は特に、前者の「Issue Alertのノイズを綺麗に刈り込む技術」にフォーカスして解説します。
—
3. 無視すべき無害なエラーを消し去るフィルタリング術
まずは、そもそもSentryに「送る必要のないゴミエラー」をシャットアウトする方法、そして「Sentryには届くけれど、Slackには通知させない」ためのフィルタリングを構築します。
方法A: クライアントサイド（SDK）での事前フィルタリング
例えば、ブラウザ拡張機能や古すぎるブラウザが原因の `ResizeObserver loop limit exceeded` や、CORS関連のよくある無害なエラーは、コードの初期化時（`Sentry.init`）に弾いてしまいましょう。
// フロントエンドの初期化設定 (Sentry.init) の例
Sentry.init({
dsn: “https://example@o0.ingest.sentry.io/0”,
// 意図的に無視したいエラーパターンを ignoreErrors に登録する
ignoreErrors: [
// ブラウザ拡張機能や既知の無害なエラー
“ResizeObserver loop limit exceeded”,
“Non-Error promise rejection captured”,
/CORS error/i, // 正規表現も使えます
],
// 特定のURL（外部スクリプトなど）からのエラーは無視する
denyUrls: [
/extensions\//i,
/^chrome-extension:\/\//i,
],
});
これだけで、フロントエンド起因のどうしようもないノイズの3割〜5割は消え去ります。
方法B: Sentryダッシュボードでの「Inbound Filters」の活用
コードをいじれない場合や、サーバーサイド・クライアントサイド共通で弾きたい場合は、Sentryのプロジェクト設定にある [Inbound Filters] を使います。
1. Sentryのプロジェクト設定画面を開く
2. `Processing` > `Inbound Filters` に移動する
3. 以下の項目にチェックを入れる（または必要に応じて追加する）
- “Block common source code errors”（一般的なブラウザのノイズや古いクローラーからのエラーを自動排除）
- “Block health check”（`/healthz` や `/ping` などの死活監視エンドポイントで起きたエラーを排除）
—
4. 開発チームが即座に対応できる！理想的な通知フォーマットの構築
ノイズを削ぎ落としたら、いよいよ本番です。SlackやDiscordに届く通知を、「見た瞬間に状況がわかり、誰が・どう動くべきか即決できるフォーマット」にカスタマイズしましょう。
Sentryの [Alerts] > [Create Alert] > [Issue Alert] から、カスタムルールの作成画面を開きます。
ステップ1: フィルター条件（When / If）の設定
「すべての条件に一致する場合」に通知を送るよう設定します。
- WHEN (いつ発火するか):
- `A new issue is created` （新しいIssueが作成されたとき）
- または `The issue changes its state from resolved to unresolved` （解決済みのバグが再発したとき）
- ※「Every time an event occurs（エラーが起きるたび）」は絶対に選ばないでください。通知地獄に逆戻りします。
- IF (どんな条件のときか):
- `The issue’s event count is greater than 10 in the last 1h` （過去1時間で10件以上発生した場合など、重要度の高いものに絞る）
- `The environment is production` （環境が `production` のものだけに絞る。Stagingの細かいエラーでSlackを汚さない）
ステップ2: アクション（Then）のカスタマイズ
通知先（SlackやDiscord）を指定する際、デフォルトのままだと「味気ないテキストリンク」だけが飛んできます。ここで一手間加えましょう。
SentryのSlackインテグレーションでは、カスタムメッセージを使って通知文面をリッチに装飾できます。以下のようなフォーマットを設定してみてください。
💡 推奨Slack通知フォーマット（Markdown形式）
🚨 【本番環境】クリティカル・エラー検知
> プロジェクト: {{ project.name }}
> エラー内容: {{ issue.title }}
> 発生回数: `{{ issue.times_seen }}` 回 / 影響ユーザー数: `{{ issue.users_affected }}` 人
> 環境: `{{ environment }}`
🔍 アクション:
• <{CultureInfo.url}|Sentryでスタックトレースを確認>
•担当者は直ちに調査を開始してください。
このフォーマットの優れた点は、「クリックしなくても、どの環境で、どれだけの規模の影響が出ているか」がSlackのプレビューだけで完結する点です。インシデントレスポンスの初動スピードが圧倒的に変わります。
—
まとめ：静寂と確実性を手に入れた開発チームへ
お疲れ様でした！ ここまで設定を進めれば、あなたのSlackやDiscordは、以下のような「理想的な状態」に生まれ変わっているはずです。
1. 無害なブラウザエラーや開発中のゴミエラーは完全にシャットアウトされている
2. 本当に対応すべき本番のバグ、あるいは再発したバグだけが厳選されて届く
3. 通知を見ただけで、影響範囲と次に取るべきアクションがクリアにわかる
オブザーバビリティの本質は、「見張ること」ではなく「迷わず行動できること」です。ノイズのない洗練されたアラート環境を手に入れれば、毎日の開発やオンコールが驚くほど快適になりますよ。
ぜひ今日から、あなたのSentryの通知設定をアップデートしてみてくださいね。