Rollbarで「エラーの墓場」を「改善の宝庫」に変える：Node.js/Express実装の極意
多くのエンジニアがRollbarを導入する際、単に「エラーログを飛ばすための箱」として扱っている。だが、それはRollbarのポテンシャルを1割も引き出せていない。
真のオブザーバビリティとは、「何が起きたか」を知ることではなく、「なぜそれが起き、どう修正すべきか」をコンテキストから即座に導き出すことにある。今回は、Node.js/Express環境において、開発速度を劇的に高め、運用の心理的負荷をゼロにするための「現場の神髄」を伝授する。
—
1. 守りの要：Expressミドルウェアの最適解
単に `rollbar.errorHandler()` を置くだけでは足りない。重要なのは、リクエストの「文脈」を確実にキャプチャしつつ、アプリのレスポンスをブロックさせないことだ。
const Rollbar = require(‘rollbar’);
const rollbar = new Rollbar({
accessToken: process.env.ROLLBAR_ACCESS_TOKEN,
captureUncaught: true,
captureUnhandledRejections: true,
payload: {
environment: process.env.NODE_ENV || ‘development’,
}
});
// Expressミドルウェアの配置は「最後」が鉄則
// これにより、他のミドルウェアで発生した例外を全て拾える
app.use(rollbar.errorHandler());
// 独自のエラーハンドラをチェーンさせる場合の注意点
app.use((err, req, res, next) => {
// Rollbarに送った後、ユーザーに適切なエラーレスポンスを返す
res.status(500).json({ error: ‘Internal Server Error’, incidentId: req.rollbarErrorId });
});
【プロの知見】
`req.rollbarErrorId` をフロントエンドに返せ。ユーザーから「エラーが出た」と報告を受けた際、RollbarのダッシュボードでそのIDを検索すれば、スタックトレースとリクエストボディが数秒で手元に揃う。この「IDの橋渡し」が、障害対応時間を数時間から数分に短縮する。
—
2. Uncaught Exceptionの「墜落」を許すな
Node.jsにおいて、`uncaughtException` や `unhandledRejection` を放置するのは自殺行為だ。Rollbarはこれを検知できるが、重要なのは「検知した後に安全にプロセスを終了させる（Graceful Shutdown）」ことだ。
process.on(‘uncaughtException’, (err) => {
rollbar.error(‘Uncaught Exception’, err, () => {
// 送信完了を待ってからプロセスを終了する
process.exit(1);
});
});
※ PM2やKubernetesを使っているなら、この `exit(1)` が再起動をトリガーし、健全な状態への復帰を自動化してくれる。
—
3. チーム開発で差がつく「設定の標準化」
設定ファイルが各エンジニアの環境でバラバラだと、ノイズにまみれて「本当の緊急事態」を見逃すことになる。`config/rollbar.js` を切り出し、環境変数で制御するのが正義だ。
// config/rollbar.json
{
“enabled”: true,
“reportLevel”: “error”,
“scrubFields”: [“password”, “token”, “credit_card”, “authorization”],
“checkIgnore”: “process.env.NODE_ENV === ‘test'”
}
【現場の鉄則】
- `scrubFields` の徹底: 個人情報（PII）の流出は致命的。正規表現によるマスク設定をデフォルトのホワイトリストに含めろ。
- 環境ごとのノイズ制御: ローカル開発環境でエラーが飛んでくるのは「ノイズ」だ。`.env` で制御し、ステージング以上でのみ詳細なログを吐くようにせよ。
—
4. 開発速度を爆速化する「隠れたテクニック」
キーボードショートカットと神プラグイン
- Rollbar CLI: デプロイ時に `rollbar-cli deploy` を叩く習慣をつけろ。どのコミットでエラーが混入したかがタイムライン上に表示される。これだけで「いつのデプロイが原因か」の特定が不要になる。
- Slack連携の「フィルター」: すべてのエラーをSlackに流すな。Slackは「即時アクションが必要なもの」だけに絞り、それ以外はRollbarの「Items」で週次レビューする運用にせよ。通知の洪水は、エンジニアの集中力を削ぐ最大の敵だ。
「カスタムコンテキスト」の注入
単なるスタックトレースではなく、「誰の、どの処理で」エラーが起きたかを付与しろ。
rollbar.configure({
payload: {
person: { id: req.user.id, email: req.user.email } // ユーザーIDを紐づける
}
});
これがあるだけで、特定のユーザーのみ発生するエッジケースのバグを、数分で特定できる。
—
結論：オブザーバビリティは「文化」である
Rollbarは単なるツールではない。チームが「エラーを隠蔽せず、誇りを持って修正する」ためのコミュニケーション・ハブだ。
1. IDを介したフロントとの連携
2. Graceful Shutdownによる自律的復旧
3. デプロイ連携による因果関係の可視化
これらを実装した瞬間、君たちのバックエンドは「落ちない」のではなく「落ちても即座に直せる」最強のシステムへと進化する。
さあ、コードを書き換えろ。エラーログの海に溺れるのは、今日で終わりだ。