ようこそ、オブザーバビリティの深淵へ。私は君たちのガイドを務めるアーキテクトです。
日々、アプリケーションから流れてくる「エラー」をどう扱っていますか？
多くの現場では、Rollbarに届いた通知を見て修正し、「Resolve（解決済み）」ボタンを押して終わり。……もしそうなら、君たちは宝の山をドブに捨てているのと同じです。
エラーとは単なるバグの報告ではありません。それは「ユーザーが体験した負の感情」のログであり、システムが発する「悲鳴」の記録です。そして、Rollbarの標準プランでは、その貴重な記録は一定期間（30日〜180日程度）で消えてしまいます。
「半年前、同じような障害が起きなかったっけ？」
「この特定のエラー、月単位で見ると増加傾向にないか？」
そう思ったとき、データが消えていては手遅れです。
今日は、Rollbarの制限を突破し、エラーストリームをBigQueryという「永遠の記憶」に刻み込み、Looker Studioで「ビジネスに与える影響」を可視化する究極のアーキテクチャを伝授しましょう。
これをマスターすれば、君は「バグを直す人」から「システムの健全性を経営的視点で語れるエンジニア」へと進化できますよ。
—
1. なぜ「Rollbar × BigQuery」なのか？
Rollbarは「今、何が起きているか」を知るには世界最高のツールです。しかし、過去を振り返る「分析」には、より強力な計算リソースとストレージが必要です。
- データ保持期間の超越: Rollbarのプランに縛られず、数年分のエラー推移を保持できます。
- 多角的な分析: 「特定の有料プランのユーザーだけに発生しているエラー」など、DBのユーザーデータと突合させた分析が可能になります。
- ビジネスインパクトの可視化: エラー数だけでなく、「エラーによって失われた可能性のあるCV（コンバージョン）」をダッシュボード化できます。
—
2. アーキテクチャの全体像
仕組みはシンプルですが、堅牢です。
1. Rollbar (Data Streaming): 発生したエラーをリアルタイムで外部へ流す。
2. Google BigQuery: 受け皿となる超巨大なデータ倉庫。
3. Looker Studio: データを魔法のようにグラフ化するキャンバス。
Rollbarには標準で「BigQuery Integration」が備わっています。これを利用するのが最もスマートな近道です。
—
3. 【実践ステップ1】BigQueryの受け皿を用意する
まずはGoogle Cloud側で、エラーデータを受け入れる「家」を建てましょう。
1. Google Cloudコンソールでプロジェクトを選択。
2. BigQueryを開き、新しい「データセット」を作成します（例：`rollbar_logs`）。
3. データセットの場所は、自身のサービスと同じリージョン（`asia-northeast1`など）にするのが定石です。
> プロの助言:
> Rollbarからのストリーミングを直接受ける場合、スキーマ（テーブル構造）はRollbarが自動で生成してくれます。最初は空のデータセットを用意するだけでOKです。
—
4. 【実践ステップ2】Rollbarからデータを流し込む
次に、Rollbarの設定画面で「蛇口」をひねります。
1. Rollbarのプロジェクト設定から [Integrations] -> [Data Analysis] -> [BigQuery] を選択。
2. Google Cloudの「プロジェクトID」と、先ほど作った「データセットID」を入力します。
3. 認証（サービスアカウントの発行など）手順に従い、RollbarにBigQueryへの書き込み権限を与えます。
ここで「Occurrences（発生ごと）」をストリーミング対象に選ぶのがポイントです。
「Items（エラーの種類ごと）」ではなく「Occurrences」を選ぶことで、いつ、誰に、どのブラウザでエラーが起きたかという全生データがBigQueryに蓄積されます。
—
5. 【実践ステップ3】SQLでデータを「黄金」に変える
BigQueryにデータが溜まり始めたら、次はそれを使いやすく整形します。Rollbarの生データはJSON構造を含んでいるため、SQLで叩き直すのがコツです。
以下は、「どの日、どのエラーが、何人のユーザーに影響したか」を集計する魔法のSQLです。
— エラー発生の推移と影響ユーザー数を集計するビュー
SELECT
TIMESTAMP_TRUNC(timestamp, DAY) AS error_date, — 日付ごとに丸める
item.title AS error_title,
item.level AS severity,
COUNT() AS occurrence_count,
COUNT(DISTINCT person.id) AS affected_users — 影響を受けたユニークユーザー数
FROM
`your-project.rollbar_logs.occurrences`
WHERE
_PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY) — 直近90日に絞ってコスト削減
GROUP BY
1, 2, 3
ORDER BY
error_date DESC, occurrence_count DESC
> プロの助言:
> `person.id` をRollbarに送るようにアプリ側を実装しておきましょう。これがあるだけで、エラーの深刻度が「回数」から「被害人数」というビジネス指標に昇華します。
—
6. 【実践ステップ4】Looker Studioで可視化する
最後に、マネジメント層やチームが見て「一瞬で状況がわかる」ダッシュボードを作ります。
1. [Looker Studio](https://lookerstudio.google.com/)を開き、データソースとしてBigQueryを選択。
2. 先ほど作成したSQL（またはテーブル）を読み込みます。
3. 「時系列チャート」を配置し、指標に `occurrence_count`、ディメンションに `error_date` を設定。
4. 「スコアカード」を使い、総エラー数と影響ユーザー数をデカデカと表示。
おすすめの構成は、「エラーのピラミッド表示」です。
- 頂上：致命的なCriticalエラー（即対応が必要）
- 中段：頻発しているが軽微なエラー（UX改善対象）
- 底辺：無視しても良い警告（ノイズ削減対象）
—
7. 動作確認と運用の極意
セットアップが終わったら、わざと開発環境でエラーを投げてみてください。数分後、BigQueryのテーブルに行が追加され、ダッシュボードの数字がピクッと動くはずです。その瞬間、君はシステムの「真の支配者」への第一歩を踏み出したことになります。
最後に、これだけは覚えておいてください。
監視の本質は、通知に振り回されることではありません。「過去から学び、未来の障害を予測すること」です。
BigQueryに溜まったデータは、数ヶ月後に「特定のライブラリをアップデートしてから、サイレントにエラー率が3%上がっている」という、Rollbar単体では気づけなかった真実を教えてくれるでしょう。
「毎日の作業が劇的に楽になりますよ。だって、もう勘に頼る必要はないんですから。」
さあ、今すぐ最初のデータセットを作ってみましょう。君の挑戦を応援しています。