RollbarのUIは「入口」に過ぎない：GraphQL APIで構築する最強のカスタム・オブザーバビリティ
Rollbarの標準ダッシュボードを眺めて満足しているなら、あなたはまだその真価の10%も引き出せていない。
エラー監視の本質は「エラーが起きた」と知ることではない。「どのビジネスメトリクスが、どのコードの変異によって破壊されたのか」を、コンテキストを失わずに特定することだ。標準UIは汎用的すぎる。真のテックリードは、自社のドメインに最適化された「自分たち専用の司令塔」を持つべきだ。
今日は、RollbarのGraphQL APIを叩き、開発スピードを劇的に加速させる「カスタム・エラートラッキング・ダッシュボード」の構築術を伝授する。
—
1. なぜGraphQL APIを直叩きするのか？
標準ダッシュボードは「全容把握」には適しているが、「特定サービスの死活とビジネスインパクトの相関」を可視化するには不十分だ。APIを使う最大のメリットは、「自分たちのデプロイサイクルや機能フラグと、エラー発生率を同一タイムラインで重ね合わせられる」ことにある。
認証情報の管理：絶対にやってはいけないこと
APIトークンをフロントエンドのコードに直書きするのは論外だ。
- ベストプラクティス: `Next.js` や `Nuxt` のAPI Routesをプロキシとして挟むか、`AWS Lambda` を介してトークンを隠蔽せよ。
- IAM管理: Rollbarのトークンは「Read-only」かつ「スコープを絞ったもの」を生成すること。
—
2. 実践：GraphQLクエリの核心を突く
RollbarのGraphQLは強力だ。特定のプロジェクトIDに対して、高頻度エラーと未解決の重大課題を抽出するクエリ例を見てほしい。
query GetCriticalErrors($projectId: Int!) {
project(id: $projectId) {
# 発生数順にソートし、ノイズを排除して「今」対応すべきものだけを抜く
items(sort: OCCURRENCE_COUNT, status: ACTIVE, limit: 10) {
edges {
node {
fingerprint
title
level
occurrenceCount
# 直近の発生時刻を特定し、デプロイ後のスパイクを検知する
lastOccurrence {
timestamp
}
}
}
}
}
}
プロのヒント: `fingerprint` をキーにすることで、似たようなエラーをグルーピングして集計できる。UI上の数値を鵜呑みにせず、このIDをキーにして自社のDB（例えばBigQuery）に蓄積し、長期的な「負債の傾向」を分析するのが真のアーキテクトだ。
—
3. 生産性を最大化する「ツール使い」の極意
Rollbarを日常的に使うなら、以下の設定は「礼儀」だ。
① 隠れたキーボードショートカット
- `Shift + ?`: Rollbar UI内のショートカットリストを呼び出す（これは基本）。
- `Cmd + K` (検索): プロジェクト間を爆速で移動するための必須ショートカット。マウスに触れる時間を1秒でも減らせ。
② チーム開発の「設定共有化ルール」
Rollbarの通知設定は、チーム全員のSlackに垂れ流すな。それは「ノイズ」であり、誰も見なくなる。
- ルールの設計: 「Severity: Critical」かつ「Occurrences > 10/min」の場合のみアラートを飛ばす。
- Configの共有: `rollbar.yaml` 等の構成ファイルをリポジトリのルートに置き、CI/CDで同期させる。
.rollbar/config.yaml – チームの知見をコード化する
notification_thresholds:
- environment: “production”
critical_only: true
slack_channel: “#alerts-critical”
- environment: “staging”
auto_resolve: true # ステージングは過剰なアラートを自動解決させる
—
4. 開発スピードを底上げする「神プラグイン・連携」
- GitHub/GitLab連携: エラーのスタックトレースから該当コードへ直接ジャンプできるよう、必ずリポジトリ連携を済ませておけ。「ファイル名をコピーしてIDEで検索」している時間は無駄だ。
- Sentry vs Rollbarの併用: もしSentryと併用しているなら、Rollbarを「ビジネスロジックエラー」、Sentryを「システム例外」と役割分担させろ。両方を比較して「エラーの質」を議論するのが、シニアエンジニアの嗜みだ。
—
結論：ダッシュボードは「作るもの」
RollbarのUIでエラーを確認するのは、あくまで「調査の開始点」にすぎない。
自前でダッシュボードを構築し、「デプロイ直後の例外発生数」をグラフ化して開発者の目の前に突きつける。それだけで、コードの品質に対する意識は劇的に変わる。
ツールに使われるな。ツールを統合し、自分たちの開発プロセスという「プロダクト」を磨き上げろ。それが、真のオブザーバビリティだ。
—
追記：もし具体的なGraphQLクエリの叩き方や、Grafanaへの統合について深く知りたい場合は、またいつでも聞いてくれ。アーキテクチャの泥沼から引き上げてやる。