こんにちは！開発現場の修羅場をいくつもくぐり抜けてきた先輩エンジニアの私です。
毎朝出社してSlackを開いた瞬間、「昨夜リリースしたバージョンで、一部のユーザーのアプリが落ちまくっています！」というアラートを見る……。エンジニアにとって、これほど胃がキリキリする瞬間はありませんよね。
アプリ開発の現場において、「エラーとの戦い」は避けて通れません。そして、その最前線で私たちの盾となってくれるのが Firebase Crashlytics です。
「Crashlyticsなら、すでにダッシュボードで見ているよ」と思いましたか？
もちろん、標準のダッシュボードも素晴らしいです。しかし、無料版の保持期間はたったの90日。しかも、「どの画面で最も収益を落としているか？」といった、ビジネス指標と掛け合わせた深い分析をするには、標準機能だけでは少し物足りないのが現実です。
今回は、CrashlyticsのデータをBigQuery（ビッグクエリ）にエクスポートし、永遠のログ保管庫と最強のビジネス分析ダッシュボードを作る方法を、基礎から優しく丁寧に解説していきます。
これをマスターすれば、ただのエラー対応係から、「データでプロダクトを守る戦略的エンジニア」にステップアップできますよ。さあ、一緒に扉を開けましょう！
—
1. そもそもなぜ、CrashlyticsのBigQuery連携が必要なのか？
多くのチームが、Crashlyticsのデフォルト画面だけで満足しています。しかし、本当にプロダクトを成長させたいなら、BigQuery連携は「マスト」です。
理由は主に3つあります。
1. 90日間の壁を超える「全期間のログ保管」
標準機能では過去90日分しかエラーが見えません。「半年前のアップデートと、今回のクラッシュに関係性はあるか？」といった長期トレンドの追跡には、BigQueryへの蓄積が不可欠です。
2. SQLによる無限のカスタマイズ分析
「iOS 17.2かつ、特定のプレミアムプランに加入しているユーザーで、どのクラッシュが一番売上に影響しているか？」といった、ビジネスに直結する多軸の深掘りがSQL一発で可能になります。
3. BIツール（Looker Studioなど）とのシームレスな結合
エンジニアだけでなく、プロダクトマネージャーやカスタマーサポートチームも交えて「今、どのバグを最優先ですべきか」を共通のダッシュボードで見られるようになります。
—
2. 基礎セットアップ：BigQuery連携の魔法をかける
それでは、実際に手を動かしていきましょう。セットアップは驚くほど簡単ですが、ここを正確にやっておかないとデータが流れてきません。
ステップ1：Firebase Consoleでのリンク設定
1. [Firebase Console](https://console.firebase.google.com/)を開き、対象のプロジェクトを選択します。
2. 左メニューの 「プロジェクトの設定」（歯車マーク）をクリックし、「連携」（Integrations）タブを開きます。
3. 「BigQuery」 のカードを見つけ、「リンクする」（Link）をクリックします。
4. ウィザードに従って進め、「データセットの場所（例: `asia-northeast1` など）」を指定して完了させます。
たったこれだけで、Firebase側が自動的に毎日BigQueryへCrashlyticsのデータを流し込んでくれるようになります。
ステップ2：BigQuery側でデータを確認する
リンクが完了して少し時間が経つ（通常は翌日、または最初のクラッシュが発生してデータが蓄積される）と、Google CloudのBigQueryコンソールに `firebase_analytics` や `crashlytics` といったデータセットが出現します。
中を覗いてみると、`com_google_firebase_crashlytics` のようなテーブルがあり、スタックトレース、OSバージョン、デバイス名、カスタムキーなどの膨大なデータがJSON形式や構造化データとして格納されています。
—
3. HelloWorld的・最初のSQLクエリ：クラッシュトレンドを暴く
データが入ってきたら、まずは「挨拶代わり」の簡単なSQLを書いてみましょう。
BigQueryのクエリコンソールを開き、以下のSQLを実行してみてください。
> 💡 先輩のアドバイス
> 以下の `your-project-id.your_dataset.firebase_crashlytics` の部分は、ご自身の環境のプロジェクトIDとデータセット名に書き換えてくださいね。
— 過去7日間における、OS別・クラッシュ発生件数の推移を調べる
SELECT
— タイムスタンプを日付（YYYY-MM-DD）に変換
DATE(event_timestamp) AS crash_date,
— OSのプラットフォーム（iOS / Android）
platform,
— 発生したエラーの総数
COUNT(1) AS crash_count
FROM
`your-project-id.your_dataset.firebase_crashlytics`
WHERE
— 過去7日間に絞り込み
event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
crash_date,
platform
ORDER BY
crash_date DESC,
platform ASC;
このクエリがやってくれること：
直近1週間で、iOSとAndroidのどちらでどれだけエラーが起きているのかを時系列で綺麗に集計してくれます。「あれ？昨日のリリース以降、iOSだけ急激にエラーが増えてないか？」という異変に、朝会の前に気づくことができる最初のステップです。
—
4. 現場で使える！機種別・OS別の影響度ディープダイブ
基礎ができたら、次は一歩進んだ実践的な分析です。「どの機種で、どのOSのバージョンでユーザーが路頭に迷っているか」を特定する、少しリッチなSQLをお見せします。
— OSバージョンとデバイス機種ごとのクラッシュ影響度分析
SELECT
device.model AS device_model, — 機種名 (例: iPhone 14 Pro, Pixel 7)
os_version, — OSバージョン (例: 17.2.1, 14.0)
COUNT(DISTINCT user.pseudo_id) AS affected_users, — 影響を受けたユニークユーザー数
COUNT(1) AS total_crashes — 総クラッシュ回数
FROM
`your-project-id.your_dataset.firebase_crashlytics`
WHERE
event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
device_model,
os_version
— 影響ユーザー数が多い順に上位20件を表示
ORDER BY
affected_users DESC
LIMIT 20;
なぜ「総クラッシュ回数」ではなく「影響を受けたユーザー数」を見るのか？
ここにプロの視点があります。
1人のユーザーがアプリのバグで「連続して100回アプリが落ちた」場合、総クラッシュ回数は「100」になります。しかし、被害を受けたのは「1人」です。
プロダクトの健康度を測る上で重要なのは、「何人の顧客体験を損ねたか（`affected_users`）」です。このSQLを使えば、「一部のコアな機種で致命的なバグが起きていないか」を正確に把握できます。
—
5. 【究極の奥義】ビジネス指標ダッシュボードの作り方
さて、ここからが本番です。集めたデータをBigQueryに閉じ込めておくのはもったいない。無料のBIツールである Looker Studio（旧Googleデータスタジオ） と連携させて、チーム全員が見られる「ビジネス指標ダッシュボード」を作ってみましょう。
連携の手順
1. [Looker Studio](https://lookerstudio.google.com/)を開き、新しいレポートを作成します。
2. データソースとして 「BigQuery」 を選択します。
3. 先ほど作成したCrashlyticsのテーブル（または、集計用のビュー）を指定します。
4. グラフや表を配置します。
ダッシュボードに配置すべき「神の3指標」
ダッシュボードには、以下の3つを並べるのがおすすめです。
1. 「影響ユーザー数」の時系列グラフ（折れ線グラフ）
- チーム全体のモチベーションと、アプリの安定性を一目で示すバロメータ。
2. 「課金ユーザー vs 無料ユーザー」のエラー発生割合（円グラフ）
- Crashlyticsのカスタムキー（例: `is_premium = true`）をBigQuery側で結合しておき、「課金ユーザーがどれだけエラーを踏んでいるか」を可視化します。売上に直結するバグを優先的に潰すための最強の根拠になります。
3. 「未解決エラーのトップ10一覧表」（テーブル）
- カスタマーサポートから「ユーザーから不具合報告が来ています」と言われた時に、この表のリンクから瞬時に該当するスタックトレースに飛べるようにしておきます。
—
まとめ：データでバグを制し、開発を楽しもう
今回は、CrashlyticsとBigQueryを連携させ、長期的なトレンド分析からビジネスインパクトを考慮したダッシュボードの作り方までを解説しました。
- 90日の壁を突破し、BigQueryにデータを永続化する
- SQLで「総クラッシュ数」ではなく「影響ユーザー数」を正確に測る
- Looker Studioでチーム全体が見られるダッシュボードに昇華させる
最初は難しく感じるかもしれませんが、一度この仕組みを作ってしまえば、毎朝のステータスチェックや、リリース判定の会議が劇的に楽になります。「感覚」ではなく「データ」で語れるエンジニアは、チームから絶大な信頼を得られますよ。
ぜひ今日から、あなたのプロジェクトでも試してみてくださいね。それでは、快適なオブザーバビリティライフを！