Firebase で AI 搭載アプリを構築して実行する方法のデモを、2024 年の Demo Day でご覧ください。ぜひご覧ください。

Firebase Crashlytics データを BigQuery にエクスポートする

Firebase Crashlytics データを BigQuery にエクスポートして、詳細に分析できます。BigQuery では、BigQuery SQL を使用してデータを分析できます。また、データを別のクラウドプロバイダにエクスポートできるほか、可視化や Google データポータルのカスタムダッシュボードでデータを使用できます。

BigQuery へのエクスポートを有効にする

Firebase コンソールで、[統合] ページに移動します。
[BigQuery] カードで [リンク] をクリックします。
画面上の指示に従って、BigQuery へのエクスポートを有効にします。

BigQuery の Crashlytics データにほぼリアルタイムでアクセスする場合は、ストリーミングエクスポートへのアップグレードを検討してください。

エクスポートを有効にした場合の影響

データセットのロケーションを選択します。データセットの作成後はロケーションを変更できませんが、データセットを別のロケーションにコピーするか、データセットを別のロケーションに手動で移動（再作成）することはできます。詳細については、既存のエクスポートのロケーションを変更するをご覧ください。

このロケーションは、BigQuery にエクスポートされたデータにのみ適用されます。Firebase コンソールの Crashlytics ダッシュボードや Android Studio で使用するために保存されたデータのロケーションには影響しません。

注: データのエクスポートのロケーションを選択して変更する機能は、2024 年 10 月中旬以降にエクスポートを有効にした場合、または新しいエクスポートインフラストラクチャにアップグレードした場合にのみ使用できます。
デフォルトでは、プロジェクト内のすべてのアプリが BigQuery にリンクされ、後からプロジェクトに追加するアプリもすべて BigQuery に自動的にリンクされます。データを送信するアプリを管理することもできます。
Firebase は、BigQuery へのデータの毎日の同期を設定します。
- 通常、プロジェクトをリンクした後、最初のデータセットが BigQuery にエクスポートされる翌日の同期まで待つ必要があります。
- 毎日の同期は、BigQuery でスケジュール設定したエクスポートに関係なく、1 日 1 回行われます。同期ジョブのタイミングと所要時間は変更される可能性があるため、エクスポートの特定のタイミングに基づいてダウンストリームオペレーションやジョブをスケジュールすることはおすすめしません。
Firebase は BigQuery に既存データのコピーをエクスポートします。エクスポートするデータの初回の読み込みには、最長で 48 時間かかる場合があります。
- 各リンク済みアプリでは、このエクスポートには毎日の同期によるデータを含むバッチテーブルも含まれます。
- 過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）、バッチテーブルのデータバックフィルは手動でスケジュールできます。
2024 年 10 月中旬より前に Crashlytics データのエクスポートを有効にした場合は、エクスポートを有効にした日から 30 日前までバックフィルすることもできます。
Crashlytics から BigQuery へのストリーミングエクスポートを有効にすると、すべてのリンク済みアプリに常に更新されるデータを含むリアルタイムテーブルも作成されます。

BigQuery へのエクスポートを無効にするには、Firebase コンソールでプロジェクトのリンクを解除します。

BigQuery にエクスポートされるデータの概要

Firebase Crashlytics データは、firebase_crashlytics という名前の BigQuery データセットにエクスポートされます。デフォルトでは、プロジェクト内のアプリごとに用意される Crashlytics データセットに個々のテーブルが作成されます。Firebase は、アプリの ID に基づいてテーブルの名前を付けます。ピリオドはアンダースコアに変換され、名前の末尾にプラットフォーム名が追加されます。

たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納されます。このバッチテーブルは毎日 1 回更新されます。BigQuery への Crashlytics ストリーミングエクスポートを有効にすると、Crashlytics データも com_google_test_ANDROID_REALTIME という名前のテーブルにリアルタイムでストリーミングされます。

テーブルの各行はアプリで発生したイベント（クラッシュ、致命的でないエラー、ANR など）を表します。

BigQuery への Crashlytics のストリーミングエクスポート

BigQuery ストリーミングを使用すると、Crashlytics データをリアルタイムでストリーミングできます。ライブダッシュボードでの情報の表示、ライブでのロールアウトの監視、アラートやカスタムワークフローをトリガーするアプリケーション問題のモニタリングなど、ライブデータが必要なあらゆる目的で使用できます。

BigQuery への Crashlytics ストリーミングエクスポートを有効にすると、バッチテーブルに加えてリアルタイムテーブルも作成されます。この 2 つのテーブルには次の違いがあります。

バッチテーブル	リアルタイムテーブル
データは 1 日 1 回エクスポートされます。イベントは、BigQuery へのバッチ書き込み前に永続的に保存されます。最大 30 日前までのデータをバックフィルできます*。	データはリアルタイムでエクスポートされます。バックフィルは使用できません。

バッチテーブルには書き込み前のイベントが永続的に保存されるため、このテーブルは長期分析で経時的な傾向を識別する場合に適しています。また、最大で 30 日前まで遡ってテーブルのバックフィルを行うことができます*。リアルタイムテーブルに書き込まれたデータはすぐに BigQuery に書き込まれるため、ライブダッシュボードやカスタムアラートにはリアルタイムテーブルが適しています。この 2 つのテーブルを合成クエリで組み合わせると、両方のメリットを利用できます。

デフォルトでは、リアルタイムテーブルのパーティションの有効期限は 30 日間です。これを変更する方法については、BigQuery ドキュメントのパーティションの有効期限を設定するをご覧ください。

^{* バックフィルのサポートの詳細については、新しいエクスポートインフラストラクチャにアップグレードするをご覧ください。}

BigQuery への Crashlytics のストリーミングエクスポートを有効にする

Firebase コンソールで、[統合] ページに移動します。
[BigQuery] カードで [管理] をクリックします。
[ストリーミングを含む] チェックボックスをオンにします。

この操作により、リンクされたすべてのアプリでストリーミングが有効になります。

エクスポートされたデータで可能な操作

BigQuery へのエクスポートでは、デバイスの種類、オペレーティングシステム、例外（Android アプリ）またはエラー（Apple アプリ）、Crashlytics ログなど、未加工のクラッシュデータを利用できます。

エクスポートされる Crashlytics データとそのテーブルのスキーマについては、このページの後の部分で詳しく説明します。

データポータルのテンプレートを使用する

データポータルのテンプレートでリアルタイムデータを有効にするには、データポータルを使用してエクスポートされた Crashlytics データの可視化の手順に沿って操作します。

ビューを作成する

BigQuery UI を使用して、クエリをビューに変換できます。詳細な手順については、BigQuery ドキュメントのビューを作成するをご覧ください。

クエリを実行する

次の例は、Crashlytics データに対して実行して、障害イベントデータを、より簡単に理解できる概要に集約するレポートを生成するクエリを示しています。このようなレポートは Firebase コンソールの Crashlytics ダッシュボードでは利用できないため、クラッシュデータの分析と理解を補完できます。

例 1: 日別のクラッシュ数を確認する

修正するバグがほとんどなくなり、チームは新しい写真共有アプリをリリース可能な状態になったと考えました。しかし、リリース前に、過去 1 か月間の 1 日あたりの障害件数を確認し、バグバッシュでアプリが時間とともに安定してきたことを確認したいと考えています。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

例 2: 最も多いクラッシュを確認する

生産計画の優先順位を正しく判断するため、アプリで最も発生頻度の高いクラッシュの上位 10 件を特定しようとしています。関連するデータポイントを提供するクエリを作成します。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

例 3: クラッシュ数が多い上位 10 台のデバイスを特定する

秋は新しいスマートフォンのシーズンです。この季節はまた、新しいデバイス固有の問題が多発する時期でもあります（特に Android の場合）。今後起きる可能性がある互換性の問題を事前に把握するため、先週（168 時間）最も多く障害が発生した 10 台のデバイスを特定するクエリを作成しました。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

例 4: カスタムキーでフィルタリングする

あるゲームデベロッパーが、ゲームのどのレベルで最も多くの障害が発生するかを調べようとしています。

この統計情報をトラッキングするため、current_level というカスタム Crashlytics キーを設定し、ユーザーが新しいレベルに到達するたびに更新します。

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

BigQuery へのエクスポートのそのキーを使用して、各クラッシュイベントに関連付けられた current_level 値の分布を報告するクエリを作成できます。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

例 5: ユーザー ID を抽出する

Android アプリの早期アクセスを有効にしています。ほとんどのユーザーは問題なく利用していますが、3 人のユーザーから異常な数の障害件数が報告されました。根本的な原因を突き止めるため、これらのユーザーの ID を使用して障害イベントを取得するクエリを作成しました。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id

例 6: 特定のクラッシュ問題が発生しているすべてのユーザーを抽出する

チームが誤って、ベータ版テスターのグループに重大なバグをリリースしてしまいました。チームは、上記の「最も多いクラッシュを確認する」の例のクエリを使用して、クラッシュ問題の ID を特定し、このクラッシュの影響を受けたアプリユーザーのリストを抽出するクエリを実行しました。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

例 7: クラッシュの影響を受けたユーザーの数を国別にまとめる

新しいリリースのロールアウト中に重大なバグが見つかりました。上記の「最も多いクラッシュを確認する」の例のクエリを使用して、クラッシュ問題の ID を特定し、次に、このクラッシュが世界的にどのように影響しているのかを確認します。

このクエリを作成するために、次の作業を行う必要があります。

Google Analytics データの BigQuery へのエクスポートを有効にする詳しくは、プロジェクトデータを BigQuery にエクスポートするをご覧ください。

ユーザー ID を Google Analytics SDK と Crashlytics SDK の両方に渡すようにアプリを更新します。

Swift

Crashlytics.sharedInstance().setUserIdentifier("123456789");
Analytics.setUserID("123456789");

Objective-C

CrashlyticsKit setUserIdentifier:@"123456789";
FIRAnalytics setUserID:@"12345678 9";

Java

Crashlytics.setUserIdentifier("123456789");
mFirebaseAnalytics.setUserId("123456789");

ユーザー ID フィールドを使用して、Google Analytics データセットのイベントと Crashlytics データセットのクラッシュを結合するクエリを作成します。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
WHERE
  c.issue_id = "ISSUE_ID"
  AND a._TABLE_SUFFIX BETWEEN '20190101'
  AND '20200101'
GROUP BY
  c.issue_id,
  a.geo.country,
  c.user.id

例 8: 今日ここまでの上位 5 件の問題

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

例 9: DATE 以降から今日までの上位 5 件の問題

バッチテーブルとリアルタイムテーブルを合成クエリと組み合わせて、信頼性の高いバッチデータにリアルタイム情報を追加することもできます。event_id が主キーであるため、DISTINCT event_id を使用して 2 つのテーブルで共通するすべてのイベントの重複を排除できます。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

BigQuery の Crashlytics スキーマの概要

Crashlytics から BigQuery へのデータエクスポートを設定すると、Firebase は最近発生したイベント（クラッシュ、致命的ではないエラー、ANR）をエクスポートします。この中には、リンクの 2 日前までのイベントが含まれており、最大 30 日前まで遡ってテーブルのバックフィルを行えるオプションも用意されています。

その時点からユーザーがエクスポートを無効にするまで、Firebase は Crashlytics イベントを毎日エクスポートします。エクスポート後に BigQuery でデータを利用できるようになるまでに数分かかることがあります。

データセット

Crashlytics は、Crashlytics データ用に BigQuery に新しいデータセットを作成します。このデータセットは、複数のアプリがある場合でもプロジェクト全体をカバーします。

テーブル

ユーザーがアプリのデータエクスポートを無効にしない限り、Crashlytics はプロジェクトに含まれるアプリごとに、データセット内にテーブルを作成します。Firebase は、アプリのバンドル ID に基づいてテーブルの名前を付けます。ピリオドはアンダースコアに変換され、名前の末尾にプラットフォーム名が追加されます。

たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納され、リアルタイムデータ（有効にされてる場合）は com_google_test_ANDROID_REALTIME という名前のテーブルに格納されます。

テーブルには、アプリで定義したカスタム Crashlytics キーに加えて、Crashlytics データの標準セットが含まれています。

行

テーブルの各行は、アプリで発生したエラーを表します。

列

テーブルの列は、クラッシュ、致命的でないエラー、ANR で同じです。BigQuery への Crashlytics ストリーミングエクスポートが有効になっている場合、リアルタイムテーブルにはバッチテーブルと同じ列があります。スタックトレースのないイベントを表す行に列が存在する場合があるのでご注意ください。

エクスポート内の列は次の表のとおりです。

フィールド名	データ型	説明
`platform`	STRING	Firebase プロジェクトに登録されているアプリのプラットフォーム（有効な値: `IOS` または `ANDROID`）
`bundle_identifier`	STRING	Firebase プロジェクトに登録されているアプリの固有識別子（例: `com.google.gmail`） Apple プラットフォームアプリの場合、これはアプリのバンドル ID です。 Android アプリの場合、これはアプリのパッケージ名です。
`event_id`	STRING	イベントの一意の ID
`is_fatal`	BOOLEAN	このフィールドは非推奨になりました。代わりに `error_type` を使用してください。アプリがクラッシュしたかどうか
`error_type`	STRING	イベントのエラータイプ（`FATAL`、`NON_FATAL`、`ANR` など）
`issue_id`	STRING	イベントに関連付けられている問題
`variant_id`	STRING	このイベントに関連付けられている問題のバリアントすべてのイベントに問題のバリアントが関連付けられているわけではありません。
`event_timestamp`	TIMESTAMP	イベントの発生時間
`device`	RECORD	イベントが発生したデバイス
`device.manufacturer`	STRING	デバイスの製造元
`device.model`	STRING	デバイスのモデル
`device.architecture`	STRING	例: `X86_32`、`X86_64`、`ARMV7`、`ARM64`、`ARMV7S`、`ARMV7K`
`memory`	RECORD	デバイスのメモリステータス
`memory.used`	INT64	使用済みのメモリ（バイト）
`memory.free`	INT64	未使用のメモリ（バイト）
`storage`	RECORD	デバイスの永続ストレージ
`storage.used`	INT64	使用済みストレージ（バイト）
`storage.free`	INT64	未使用のストレージ（バイト）
`operating_system`	RECORD	デバイスの OS の詳細
`operating_system.display_version`	STRING	デバイスの OS のバージョン
`operating_system.name`	STRING	デバイスの OS 名
`operating_system.modification_state`	STRING	デバイスに変更が加えられているかどうか（例: 制限解除されたアプリは `MODIFIED`、root 権限を取得したアプリは `UNMODIFIED` など）
`operating_system.type`	STRING	（Apple アプリのみ）デバイスで実行されている OS の種類（`IOS`、`MACOS` など）
`operating_system.device_type`	STRING	デバイスの種類（例: `MOBILE`、`TABLET`、`TV`）。「デバイスカテゴリ」とも呼ばれます。
`application`	RECORD	イベントを生成したアプリ
`application.build_version`	STRING	アプリのビルドバージョン
`application.display_version`	STRING
`user`	RECORD	（省略可）アプリのユーザーに関して収集された情報
`user.name`	STRING	このフィールドは非推奨です。このフィールドは使用しないでください。（省略可）ユーザーの名前
`user.email`	STRING	このフィールドは非推奨です。このフィールドは使用しないでください。（省略可）ユーザーのメールアドレス
`user.id`	STRING	（省略可）ユーザーに関連付けられているアプリ固有の ID
`custom_keys`	REPEATED RECORD	デベロッパーが定義した Key-Value ペア
`custom_keys.key`	STRING	デベロッパーが定義したキー
`custom_keys.value`	STRING	デベロッパーが定義した値
`installation_uuid`	STRING	アプリとデバイスのインストールを一意に識別する ID
`crashlytics_sdk_versions`	STRING	イベントを生成した Crashlytics SDK のバージョン
`app_orientation`	STRING	例: `PORTRAIT`、`LANDSCAPE`、`FACE_UP`、`FACE_DOWN`
`device_orientation`	STRING	例: `PORTRAIT`、`LANDSCAPE`、`FACE_UP`、`FACE_DOWN`
`process_state`	STRING	`BACKGROUND` または `FOREGROUND`
`logs`	REPEATED RECORD	Crashlytics ロガーによって生成されたタイムスタンプ付きのログメッセージ（有効な場合）
`logs.timestamp`	TIMESTAMP	ログの作成時間
`logs.message`	STRING	ログに記録されたメッセージ
`breadcrumbs`	REPEATED RECORD	タイムスタンプ付きの Google Analytics パンくずリスト（有効な場合）
`breadcrumbs.timestamp`	TIMESTAMP	パンくずリストに関連付けられているタイムスタンプ
`breadcrumbs.name`	STRING	パンくずリストに関連付けられている名前
`breadcrumbs.params`	REPEATED RECORD	パンくずリストに関連付けられたパラメータ
`breadcrumbs.params.key`	STRING	パンくずリストに関連付けられたパラメータキー
`breadcrumbs.params.value`	STRING	パンくずリストに関連付けられたパラメータ値
`blame_frame`	RECORD	クラッシュまたはエラーの根本的原因として識別されたフレーム
`blame_frame.line`	INT64	フレームファイルの行番号
`blame_frame.file`	STRING	フレームファイルの名前
`blame_frame.symbol`	STRING	ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。
`blame_frame.offset`	INT64	コードを含むバイナリイメージへのバイトオフセット Java 例外で設定解除
`blame_frame.address`	INT64	コードを含むバイナリイメージのアドレス Java フレームで設定解除
`blame_frame.library`	STRING	フレームを含むライブラリの表示名
`blame_frame.owner`	STRING	例: `DEVELOPER`、`VENDOR`、`RUNTIME`、`PLATFORM`、`SYSTEM`
`blame_frame.blamed`	BOOLEAN	Crashlytics で、このフレームがクラッシュまたはエラーの原因と判断されたかどうか
`exceptions`	REPEATED RECORD	（Android のみ）このイベントで発生した例外。ネストされている例外は発生順と逆に表示されます。つまり、最後のレコードが最初にスローされる例外です。
`exceptions.type`	STRING	例外タイプ（`java.lang.IllegalStateException)` など）
`exceptions.exception_message`	STRING	例外に関連するメッセージ
`exceptions.nested`	BOOLEAN	最後にスローされた例外を除くすべて（すなわち、最初のレコード）の場合は true。
`exceptions.title`	STRING	スレッドのタイトル
`exceptions.subtitle`	STRING	スレッドのサブタイトル
`exceptions.blamed`	BOOLEAN	エラーまたはクラッシュが原因で例外が発生しているかどうかを Crashlytics が判断する場合は true
`exceptions.frames`	REPEATED RECORD	例外に関連付けられているフレーム
`exceptions.frames.line`	INT64	フレームファイルの行番号
`exceptions.frames.file`	STRING	フレームファイルの名前
`exceptions.frames.symbol`	STRING	ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。
`exceptions.frames.offset`	INT64	コードを含むバイナリイメージへのバイトオフセット Java 例外で設定解除
`exceptions.frames.address`	INT64	コードを含むバイナリイメージのアドレス Java フレームで設定解除
`exceptions.frames.library`	STRING	フレームを含むライブラリの表示名
`exceptions.frames.owner`	STRING	例: `DEVELOPER`、`VENDOR`、`RUNTIME`、`PLATFORM`、`SYSTEM`
`exceptions.frames.blamed`	BOOLEAN	Crashlytics で、このフレームがクラッシュまたはエラーの原因と判断されたかどうか
`error`	REPEATED RECORD	（Apple アプリのみ）致命的でないエラー
`error.queue_name`	STRING	スレッドが実行されていたキュー
`error.code`	INT64	アプリのカスタムログに記録された NSError に関連するエラーコード
`error.title`	STRING	スレッドのタイトル
`error.subtitle`	STRING	スレッドのサブタイトル
`error.blamed`	BOOLEAN	Crashlytics で、このフレームがエラーの原因と判断されたかどうか
`error.frames`	REPEATED RECORD	スタックトレースのフレーム
`error.frames.line`	INT64	フレームファイルの行番号
`error.frames.file`	STRING	フレームファイルの名前
`error.frames.symbol`	STRING	ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。
`error.frames.offset`	INT64	コードを含むバイナリイメージへのバイトオフセット
`error.frames.address`	INT64	コードを含むバイナリイメージ内のアドレス
`error.frames.library`	STRING	フレームを含むライブラリの表示名
`error.frames.owner`	STRING	例: `DEVELOPER`、`VENDOR`、`RUNTIME`、`PLATFORM`、`SYSTEM`
`error.frames.blamed`	BOOLEAN	Crashlytics で、このフレームがエラーの原因と判断されたかどうか
`threads`	REPEATED RECORD	イベント発生時に存在していたスレッド
`threads.crashed`	BOOLEAN	スレッドがクラッシュしたかどうか
`threads.thread_name`	STRING	スレッドの名前
`threads.queue_name`	STRING	（Apple アプリのみ）スレッドが実行されていたキュー
`threads.signal_name`	STRING	アプリをクラッシュさせたシグナルの名前。クラッシュしたネイティブスレッドにのみ存在します。
`threads.signal_code`	STRING	アプリをクラッシュさせたシグナルのコード。クラッシュしたネイティブスレッドにのみ存在します。
`threads.crash_address`	INT64	アプリケーションをクラッシュさせたシグナルのアドレス。クラッシュしたネイティブスレッドにのみ存在します。
`threads.code`	INT64	（Apple アプリのみ）アプリケーションのカスタムログの NSError エラーコード
`threads.title`	STRING	スレッドのタイトル
`threads.subtitle`	STRING	スレッドのサブタイトル
`threads.blamed`	BOOLEAN	Crashlytics で、このフレームがクラッシュまたはエラーの原因と判断されたかどうか
`threads.frames`	REPEATED RECORD	スレッドのフレーム
`threads.frames.line`	INT64	フレームファイルの行番号
`threads.frames.file`	STRING	フレームファイルの名前
`threads.frames.symbol`	STRING	ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。
`threads.frames.offset`	INT64	コードを含むバイナリイメージへのバイトオフセット
`threads.frames.address`	INT64	コードを含むバイナリイメージ内のアドレス
`threads.frames.library`	STRING	フレームを含むライブラリの表示名
`threads.frames.owner`	STRING	例: `DEVELOPER`、`VENDOR`、`RUNTIME`、`PLATFORM`、`SYSTEM`
`threads.frames.blamed`	BOOLEAN	Crashlytics で、このフレームがエラーの原因と判断されたかどうか
`unity_metadata.unity_version`	STRING	このデバイスで実行されている Unity のバージョン
`unity_metadata.debug_build`	BOOLEAN	デバッグビルドの場合
`unity_metadata.processor_type`	STRING	プロセッサの種類
`unity_metadata.processor_count`	INT64	プロセッサ（コア）数
`unity_metadata.processor_frequency_mhz`	INT64	プロセッサの周波数（MHz）
`unity_metadata.system_memory_size_mb`	INT64	システムメモリのサイズ（MB 単位）
`unity_metadata.graphics_memory_size_mb`	INT64	グラフィックメモリ（MB）
`unity_metadata.graphics_device_id`	INT64	グラフィックデバイスの ID
`unity_metadata.graphics_device_vendor_id`	INT64	グラフィックプロセッサベンダーの ID
`unity_metadata.graphics_device_name`	STRING	グラフィックデバイスの名前
`unity_metadata.graphics_device_vendor`	STRING	グラフィックデバイスのベンダー
`unity_metadata.graphics_device_version`	STRING	グラフィックデバイスのバージョン
`unity_metadata.graphics_device_type`	STRING	グラフィックデバイスの種類
`unity_metadata.graphics_shader_level`	INT64	グラフィックのシェーダーレベル
`unity_metadata.graphics_render_target_count`	INT64	グラフィカルレンダリングターゲットの数
`unity_metadata.graphics_copy_texture_support`	STRING	Unity API で定義されているグラフィックテクスチャのコピーをサポート
`unity_metadata.graphics_max_texture_size`	INT64	レンダリングテクスチャ専用の最大サイズ
`unity_metadata.screen_size_px`	STRING	画面サイズのピクセル単位のサイズ（幅 x 高さの形式）
`unity_metadata.screen_resolution_dpi`	STRING	浮動小数点数による画面の DPI
`unity_metadata.screen_refresh_rate_hz`	INT64	画面リフレッシュレート（Hz）

データポータルでエクスポートされた Crashlytics データを可視化する

Google データポータルを使うと、BigQuery の Crashlytics データセットを、見やすく簡単に共有できるうえ、全面的なカスタマイズも可能なレポートに変換できます。

データポータルの使用方法の詳細については、データポータルクイックスタートガイドのデータポータルへようこそを試してください。

Crashlytics レポートテンプレートを使用する

データポータルには、エクスポートされた Crashlytics BigQuery スキーマからの包括的なディメンションと指標のセットを含む Crashlytics のサンプルレポートがあります。BigQuery への Crashlytics のストリーミングエクスポートを有効にしている場合、エクスポートされたデータはデータポータルのテンプレートの [Realtime trends] ページで確認できます。このサンプルをテンプレートとして使用すると、実際のアプリのクラッシュデータに基づいて新しいレポートやビジュアル資料を手軽に作成できます。

Crashlytics データポータルダッシュボードテンプレートを開きます。
右上にある [テンプレートを使用] をクリックします。
[新しいデータソース] プルダウンから [新しいデータソースを作成する] を選択します。
[BigQuery] カードで [選択] をクリックします。
[My Projects] > [PROJECT_ID] > [firebase_crashlytics] > [TABLE_NAME] の順に選択して、エクスポートされた Crashlytics データを含むテーブルを選択します。

バッチテーブルは常に選択可能です。BigQuery への Crashlytics ストリーミングエクスポートが有効になっている場合は、代わりにリアルタイムテーブルを選択できます。
[Configuration] で、[Crashlytics Template level] を [Default] に設定します。
[Connect] をクリックして新しいデータソースを作成します。
[Add to Report] をクリックして Crashlytics テンプレートに戻ります。
最後に、[Create Report] をクリックして Crashlytics データポータルダッシュボードテンプレートのコピーを作成します。

新しいエクスポートインフラストラクチャにアップグレードする

2024 年 10 月中旬に、Crashlytics は Crashlytics データを BigQuery にエクスポートするための新しいインフラストラクチャをリリースしました。現時点では、この新しいインフラストラクチャへのアップグレードは任意です。

この新しいインフラストラクチャは、米国外の Crashlytics データセットのロケーションをサポートしています。

2024 年 10 月中旬以前にエクスポートを有効にした場合は、必要に応じて BigQuery でサポートされているデータセットのロケーションについて、データエクスポートのロケーションを変更できます。
2024 年 10 月中旬以降にエクスポートを有効にした場合は、セットアップ時に BigQuery でサポートされているデータセットのロケーションを選択できます。

新しいインフラストラクチャのもう 1 つの違いは、エクスポートを有効にする前のデータのバックフィルをサポートしていないことです（以前のインフラストラクチャでは、有効化した日付の 30 日前までバックフィルできました）。新しいインフラストラクチャは、過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）のバックフィルをサポートしています。

アップグレードの前提条件

新しいインフラストラクチャにアップグレードする前に、次の前提条件を満たしていることを確認してください。現在のバッチ BigQuery テーブルに、登録済みの Firebase アプリに対して設定されているバンドル ID またはパッケージ名と一致する ID があること。

次に例を示します。

com_yourcompany_yourproject_IOS という名前の BigQuery テーブルがある場合は、Firebase プロジェクトにバンドル ID com.yourcompany.yourproject で Firebase iOS+ アプリが登録されている必要があります。
com_yourcompany_yourproject_ANDROID という名前の BigQuery テーブルがある場合は、Firebase プロジェクトに Firebase Android アプリがパッケージ名 com.yourcompany.yourproject で登録されている必要があります。

Firebase プロジェクトに登録されているすべての Firebase アプリを確認する方法は次のとおりです。

Firebase コンソールで、 [プロジェクト設定] に移動します。
[アプリ] カードまで下にスクロールし、目的の Firebase アプリをクリックして、ID などのアプリの情報を確認します。

新しいエクスポートインフラストラクチャは、登録済みの Firebase アプリに設定されているパッケージ名またはバンドル ID に基づいて各アプリのデータをエクスポートします。BigQuery ワークフローを中断しないようにするには、新しいインフラストラクチャがすべての新しいデータを既存のテーブルに追加できるように、現在のバッチテーブルにすでに正しい名前が付いていることを確認することが重要です。登録済みの Firebase アプリと一致しないバッチテーブル名があるものの、引き続きアップグレードを希望する場合は、Firebase サポートにお問い合わせください。

新しいインフラストラクチャにアップグレードする方法

エクスポートをすでに有効にしている場合は、Firebase コンソールで Crashlytics データエクスポートをオフにしてからオンに戻すだけで、新しいインフラストラクチャにアップグレードできます。

詳しい手順は次のとおりです。

Firebase コンソールで、[統合] ページに移動します。
[BigQuery] カードで [管理] をクリックします。
Crashlytics のスライダーをオフに切り替えて、エクスポートを無効にします。プロンプトが表示されたら、データエクスポートの停止を確定します。
すぐに Crashlytics スライダーをオンに切り替えて、エクスポートを再度有効にします。プロンプトが表示されたら、データのエクスポートを確定します。

これで、BigQuery への Crashlytics データエクスポートで、新しいエクスポートインフラストラクチャが使用されるようになりました。

Firebase Crashlytics データを BigQuery にエクスポートする

BigQuery へのエクスポートを有効にする

エクスポートを有効にした場合の影響

BigQuery にエクスポートされるデータの概要

BigQuery への Crashlytics のストリーミング エクスポート

BigQuery への Crashlytics のストリーミング エクスポートを有効にする

エクスポートされたデータで可能な操作

データポータルのテンプレートを使用する

ビューを作成する

クエリを実行する

例 1: 日別のクラッシュ数を確認する

例 2: 最も多いクラッシュを確認する

例 3: クラッシュ数が多い上位 10 台のデバイスを特定する

例 4: カスタムキーでフィルタリングする

Swift

Objective-C

Java

例 5: ユーザー ID を抽出する

例 6: 特定のクラッシュ問題が発生しているすべてのユーザーを抽出する

例 7: クラッシュの影響を受けたユーザーの数を国別にまとめる

Swift

Objective-C

Java

例 8: 今日ここまでの上位 5 件の問題

例 9: DATE 以降から今日までの上位 5 件の問題

BigQuery の Crashlytics スキーマの概要

データセット

テーブル

行

列

データポータルでエクスポートされた Crashlytics データを可視化する

Crashlytics レポート テンプレートを使用する

新しいエクスポート インフラストラクチャにアップグレードする

アップグレードの前提条件

新しいインフラストラクチャにアップグレードする方法

BigQuery への Crashlytics のストリーミングエクスポート

BigQuery への Crashlytics のストリーミングエクスポートを有効にする

Crashlytics レポートテンプレートを使用する

新しいエクスポートインフラストラクチャにアップグレードする