こんにちは！開発チームの守り神、そしてオブザーバビリティ（可観測性）の探求者である先輩エンジニアです。
新しいプロダクトをリリースし、意気揚々と開発を進めている最中……Slackの通知チャンネルが、こんなことになっていませんか？
- `[Error] TypeError: Cannot read property ‘map’ of undefined` （3秒に1回）
- `[Warning] DeprecationNotice: …` （無限ループ）
- 気づけば、本当に対応すべき致命的なデータベース接続エラーが、大量のノイズの海の底に沈んでいる……。
これこそが、エンジニアを蝕む「アラート疲れ（Alert Fatigue）」の正体です。通知が多すぎると、人間は麻痺して重要なエラーを見落とします。結果として障害対応が遅れ、ユーザーからのクレームでバグに気づくという最悪の事態を招くのです。
今回は、エラー監視ツール「Rollbar」と「Slack」を賢く連携させ、「本当に見るべきエラーだけを、美しく、正確に通知する」ための極上のベストプラクティスを授けましょう。
これをマスターすれば、毎日のSlackチェックが劇的に楽になり、睡眠不足からも解放されますよ。さあ、一緒にノイズのない世界へ行きましょう！
—
1. そもそも「Rollbar」とは何か？
開発の世界では、コードを書けば必ずバグ（エラー）が出ます。本地環境（ローカル）ならコンソールを見れば済みますが、本番環境（プロダクト）で何が起きているかを知るには、エラーを収集・整理する専用のツールが必要です。
Rollbarは、アプリケーションで発生した例外やエラーをリアルタイムでキャッチし、以下のような情報をまとめてくれる「エラートラッキングの神ツール」です。
- エラーが起きたスタックトレース（どこのファイルの何行目で壊れたか）
- どんなリクエストパラメータやユーザー情報だったか
- 「何回、何人のユーザーに影響を与えたか」という発生頻度
このRollbarが検知したエラーを、チャットツールのSlackに飛ばすのが今回のメインテーマです。しかし、そのまま繋ぐと先ほどのような「ゴミ通知の嵐」になります。だからこそ、「フィルタリング（選別）」が必要なのです。
—
2. 基礎セットアップ：RollbarとSlackを繋ぐ
まずは、基本の架け橋を作りましょう。すでにRollbarでプロジェクトを作成し、アプリ側でエラー捕捉（SDKの導入）が完了している前提で進めます。
ステップ1: Slackインテグレーションの有効化
1. Rollbarのダッシュボードにログインし、左メニューの [Settings]（歯車マーク）を開く。
2. [Integrations] から [Slack] を選択。
3. 「Add to Slack」ボタンを押し、通知を飛ばしたいワークスペースとチャンネルを許可する。
これで、RollbarとSlackのパイプラインが開通します。しかし、この初期状態のままだと、すべてのエラーが無慈悲にSlackへ流れ込んできます。ここからが本番です。
—
3. アラート疲れを撲滅する！Rollbar「Rules（ルール機能）」の極意
Rollbarには、「こういう条件のエラーだけを、ここに通知する」という強力な条件分岐機能、[Rules] が備わっています。これを使って、「ノイズを捨て、シグナルを残す」設定を構築していきましょう。
ベストプラクティス設計：通知を3段階に仕分けろ
優秀な監視設計とは、ゴミを捨て、重要度でチャンネルや通知方法を変えることです。
1. 捨てる（Ignoreする）エラー: ユーザー側のネットワーク切断、ブラウザの拡張機能が原因のJSエラー、すでに修正パッチを出した既知の軽微な警告。
2. 静かに溜める（通知しない・Rollbarのダッシュボードだけで見る）エラー: 影響度が極めて低いWarning。
3. Slackに即時通知するエラー: 500系サーバーエラー、決済処理の失敗、未キャッチの致命的な例外。
では、Rollbarの画面で「Slackへの通知ルール」をカスタマイズします。
具体的な設定手順：Rulesの作成
1. Rollbarのサイドメニューから [Settings] ＞ [Notifications] ＞ [Slack] を開く。
2. [Rules] セクションで、デフォルトの通知ルールを編集（または新規追加）します。
ここで、以下のような「フィルター条件」を設定します。
【ルール例：本当に重要なエラーだけを #prod-alerts チャンネルに飛ばす】
■ 送信先チャンネル: #prod-alerts
■ トリガー条件 (Filters):
1. Level (レベル) が [error] または [critical] であること
2. Occurrence Count (発生回数) が [1回目] または [急増した時]
3. Environment (環境) が [production] であること
この設定により、開発環境（development）の泥臭いデバッグエラーや、大した影響のないWarningは、Slackの画面から完全に消え去ります。あなたの目に飛び込んでくるのは、「本番環境で起きた、ユーザーを救うべき本物のエラー」だけになります。
—
4. 精度を高めるための応用テクニック（コード側での制御）
ツール側のルール設定だけでなく、アプリケーションコード側からもRollbarへの通知をコントロールすると、さらに精度が跳ね上がります。
例えば、特定の許容できるエラー（例：バリデーションエラーや、予測されたAPIタイムアウト）は、そもそもRollbarに送らない、あるいは重要度を下げるべきです。
Node.js（Expressなど）を例にした、知的なエラーハンドリングのコードを見てみましょう。
const Rollbar = require(‘rollbar’);
const rollbar = new Rollbar({
accessToken: ‘YOUR_ACCESS_TOKEN’,
environment: ‘production’,
});
// エラーミドルウェアの例
app.use((err, req, res, next) => {
// 1. クライアント側の入力ミス（400 Bad Requestなど）はノイズなので、Rollbarに送らない！
if (err.status && err.status < 500) {
return res.status(err.status).json({ error: err.message });
}
// 2. 500系サーバーエラーなど、本当にヤバいものだけRollbarに投げる
rollbar.error(err, req, (rollbarErr) => {
if (rollbarErr) {
console.error(‘Rollbarへの送信に失敗しました:’, rollbarErr);
}
// ユーザーにはシンプルに500エラーを返す
res.status(500).json({ error: ‘Internal Server Error’ });
});
});
このコードの美しさ:
ビジネスロジック上の「ただの入力ミス」でSlackが鳴り響くのを防いでいます。本当にサーバーが悲鳴を上げている瞬間だけをキャッチするため、Slackの通知音が鳴った瞬間に「対応が必要だ」と脊髄反射で動けるようになります。
—
5. 動作確認（HelloWorld）で正しく動くかテストしよう
設定が終わったら、正しくフィルタリングされているかテスト（HelloWorld的な動作確認）をしましょう。
1. テスト1（無視されるべきエラー）:
開発環境（またはあえてWarningレベル）で、意図的に軽微なログを出力してみます。
- 期待値: Rollbarのダッシュボードには記録されるが、Slackの通知は鳴らないこと。
2. テスト2（通知されるべきエラー）:
本番環境設定で、致命的な `rollbar.critical(“Test critical error from my app!”);` を実行してみます。
- 期待値: 指定したSlackチャンネルに、スタックトレース付きの美しいアラートが即座に飛んでくること。
このテストをクリアした瞬間、あなたのSlackは「騒がしいチャットツール」から「精確無比なレーダー基地」へと生まれ変わります。
—
おわりに
監視やオブザーバビリティの目的は、「すべてのエラーを知ること」ではありません。「ユーザーに深刻な影響が出る前に、エンジニアが正しいアクションを起こせること」です。
大量のエラー通知に疲弊していた昨日の自分とは今日でおおば゙゙ら！ Rollbarのルール機能を使いこなし、ノイズのない洗練された監視ライフを手に入れてください。あなたの開発体験が、この設定一つで劇的に快適になることを確信しています。