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

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

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

BigQuery へのエクスポートでは、デバイスの種類、オペレーティング システム、例外（Android アプリ）またはエラー（Apple アプリ）、Crashlytics ログなど、未加工のクラッシュ データを利用できます。 エクスポートされる Crashlytics データとそのテーブルのスキーマについては、このページの後半で詳しく説明します。

エクスポートされる Crashlytics データでできることの例を次に示します。

• クエリを実行する
  Crashlytics データに対してクエリを実行することで、クラッシュ イベント データを、より簡単に理解できる概要に集約するレポートを生成できます。これらのタイプのレポートは Firebase コンソールの Crashlytics ダッシュボードでは利用できないため、クラッシュ データの分析と理解を補完できます。このページの後半で示すクエリの例をご覧ください。

• Looker Studio テンプレートを使用する
  Crashlytics エクスポートされたデータを可視化するための事前構築済みの Looker Studio テンプレートを提供します。

• ビューを作成する
  BigQuery UI を使用して、SQL クエリで定義した仮想テーブルである「ビュー」を作成できます。さまざまな種類のビューとその作成方法に関する詳細な手順については、BigQuery ドキュメントをご覧ください。

• Crashlytics 固有のデータと Firebase セッションデータを組み合わせる
  Crashlytics のデータ エクスポートを設定する際に、Firebase セッションデータをエクスポートすることもできます。このセッション データを使用することで、クラッシュの影響を受けていないユーザーとクラッシュが発生しなかったセッションをより詳しく理解することができます。

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

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

BigQuery へのストリーミング エクスポートを有効にすると、バッチテーブルに加えてリアルタイム テーブルも作成されます。どちらのタイプのテーブルも同じデータセット スキーマになりますが、バッチテーブルとリアルタイム テーブルには次のような重要な違いがあります。

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

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

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

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

1. Firebase コンソールで、[統合] ページに移動します。

2. [BigQuery] カードで [リンク] をクリックします。

3. 画面上の指示に従って、BigQuery へのエクスポートを有効にします。次のオプションがあります。

   • クラッシュの影響を受けていないユーザーとクラッシュが発生しなかったセッションをより詳しく理解するには、Firebase セッション データのエクスポートを有効にします。

   • BigQuery で Crashlytics データと Firebase セッション データにほぼリアルタイムでアクセスするには、ストリーミング エクスポートを有効にします。

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

• Firebase は、BigQuery にリンクされているアプリからデータをエクスポートします。

  • セットアップ時に、デフォルトではプロジェクト内のすべてのアプリが BigQuery にリンクされますが、セットアップ時に特定のアプリをリンクしないように選択することもできます。

  • 後から Firebase プロジェクトに追加するアプリはすべて BigQuery に自動的にリンクされます。

  • データをエクスポートするアプリはいつでも管理できます。

• Firebase は、セットアップ時に選択したデータセットのロケーションにデータをエクスポートします。

  • このロケーションは、Crashlytics データセットと Firebase セッション データセットの両方に適用されます（セッションデータのエクスポートが有効になっている場合）。

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

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

• Firebase は BigQuery へのデータの毎日の同期を設定します。

  • BigQuery にリンクしてから、初回のバッチデータのエクスポートが完了するまでに、最長で 48 時間かかることがあります。

  • 毎日の同期は、BigQuery でスケジュール設定したエクスポートに関係なく、1 日 1 回行われます。同期ジョブのタイミングと所要時間は変更される可能性があるため、エクスポートの特定のタイミングに基づいてダウンストリーム オペレーションやジョブをスケジュールすることはおすすめしません。

• Firebase は BigQuery に既存データのコピーをエクスポートします。

  • 各リンク済みアプリでは、このエクスポートには毎日の同期によるデータを含むバッチテーブルも含まれます。

  • 過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）、バッチテーブルのデータ バックフィルは手動でスケジュールできます。

  2024 年 10 月中旬より前に Crashlytics データのエクスポートを有効にした場合は、エクスポートを有効にした日から 30 日前までバックフィルすることもできます。

• BigQuery へのストリーミング エクスポートを有効にすると、次のようになります。

  • リンクされた各アプリには、常に更新されるデータを含む独自のリアルタイム テーブルも作成されます（アプリの日次バッチ エクスポート用のバッチテーブルに加えて）。

  • ストリーミングを有効にしてからデータのストリーミングが開始されるまで、最大で 1 時間かかることがあります。

  リアルタイム テーブルにデータが表示されない場合

  1. アプリから Crashlytics に少なくとも 2 つのイベントを送信し、送信後に数分待機したことを確認します。

  2. Firebase プロジェクトが 従量課金制の Blaze 料金プランに登録されていることを確認します。
     これは、Firebase コンソールの左下隅で確認できます。

  3. 2 つのイベントを送信し、数分間待機しても、リアルタイム テーブルにデータが表示されない場合は、次の手順を実行します。

     1. Firebase コンソールの BigQuery カードに移動します。

     2. ストリーミング エクスポートを無効にしてから再度有効にします。

     3. サービス アカウント service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com が Firebase プロジェクトに存在し、Firebase Crashlytics サービス エージェントのロールが付与されていることを確認します。
        これは、Google Cloud コンソールの [IAM] ページで確認できます（[Google 提供のロール付与を含める] チェックボックスをオンにしてください）。

     4. Crashlytics に 2 つ以上のイベントを送信し、数分間待機します。

  4. リアルタイム テーブルにデータが表示されない場合は、Firebase サポートにお問い合わせください。

クエリの例

例 1: Firebase セッション データを使用してクラッシュの影響を受けていない指標を計算する

最新バージョンでは、重要なユーザー ジャーニーでのクラッシュに対処するため、大幅な改良を実施しました。ユーザーから素晴らしいレビューが寄せられていますが、アプリが以前よりも安定していることを示す定量的な証拠が欲しいと思っています。

クラッシュの影響を受けていない指標は、この情報の提供に役立ちます。これらの指標は、アプリの全体的な健全性を把握するうえで重要な測定値です。Firebase セッション データと Crashlytics イベントを使用して、基本的なクエリでこれらの指標を計算できます。

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

特定のバージョンのクラッシュの影響を受けていないユーザー:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL"
  AND crashlytics.application.display_version="APP_VERSION"
  AND sessions.application.display_version = "APP_VERSION"
GROUP BY
  event_date
ORDER BY
  event_date

過去 1 週間（過去 168 時間）のクラッシュが発生しなかったセッション:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT crashlytics.event_id) / COUNT (DISTINCT sessions.session_id))) AS CFS
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND _PARTITIONTIME < CURRENT_TIMESTAMP()
GROUP BY
  event_date
ORDER BY
  event_date

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

修正するバグがほとんどなくなり、チームは新しい写真共有アプリをリリース可能な状態になったと考えました。しかし、リリース前に、過去 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;

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

生産計画の優先順位を正しく判断するため、アプリで最も発生頻度の高いクラッシュの上位 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;

例 4 クラッシュ数が多い上位 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;

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

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

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

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

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

例 6: ユーザー 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
 

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

チームが誤って、ベータ版テスターのグループに重大なバグをリリースしてしまいました。チームは、上記の「最も多いクラッシュを確認する」の例のクエリを使用して、クラッシュ問題の 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;

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

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

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

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

2. ユーザー 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");
   

3. ユーザー 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

例 9: 今日ここまでの上位 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;

例 10: 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

エクスポートした Crashlytics データを Looker Studio で可視化する

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

Looker Studio を使用する方法について詳しくは、スタートガイドをご覧ください。

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

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

1. CrashlyticsLooker Studioダッシュボード テンプレートを開きます。

2. 右上にある [テンプレートを使用] をクリックします。

3. [新しいデータソース] プルダウンから [新しいデータソースを作成する] を選択します。

4. [BigQuery] カードで [選択] をクリックします。

5. [My Projects] > [PROJECT_ID] > [firebase_crashlytics] > [TABLE_NAME] の順に選択して、エクスポートされた Crashlytics データを含むテーブルを選択します。

   バッチテーブルは常に選択可能です。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合は、代わりにリアルタイム テーブルを選択できます。

6. [Configuration] で、[Crashlytics Template level] を [Default] に設定します。

7. [Connect] をクリックして新しいデータソースを作成します。

8. [Add to Report] をクリックして Crashlytics テンプレートに戻ります。

9. 最後に、[Create Report] をクリックして Crashlytics Looker Studio ダッシュボード テンプレートのコピーを作成します。

の BigQuery スキーマの概要

Firebase は、エクスポートされたデータ用に BigQuery に新しいデータセットを作成します。

• Crashlytics データセット

• Firebase セッション データセット（セッション データのエクスポートが有効になっている場合）

Crashlytics 個のデータセット

Crashlytics データは、firebase_crashlytics という名前の BigQuery データセットにエクスポートされます。このデータセットは、複数のアプリがある場合でもプロジェクト全体をカバーします。

テーブル

デフォルトでは、Firebase は BigQuery にリンクされているプロジェクト内のアプリごとに、Crashlytics データセット内に個々のテーブルを作成します。

テーブルの名前は、アプリの ID（ピリオドはアンダースコアに変換）に基づいて付けられ、アプリのプラットフォーム（_IOS または _ANDROID）が末尾に追加されます。たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納されます。

• BigQuery へのストリーミング エクスポートが有効になっている場合、データは _REALTIME が付加されたテーブル（com_google_test_ANDROID_REALTIME など）にもリアルタイムでストリーミングされます。

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

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

行

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

列

テーブルの列は、クラッシュ、致命的でないエラー、ANR で同じです。

• BigQuery へのストリーミング エクスポートが有効になっている場合、リアルタイム テーブルにはバッチテーブルと同じ列があります。

• スタック トレースのないイベントを表す行に列が存在する場合があります。

エクスポートされた Crashlytics データのテーブルの列は次のとおりです。

Firebase セッション データセット

Firebase セッション データは、firebase_sessions という名前の BigQuery データセットにエクスポートされます。このデータセットは、複数のアプリがある場合でもプロジェクト全体をカバーします。

テーブル

デフォルトでは、Firebase は BigQuery にリンクされているプロジェクト内のアプリごとに、Firebase セッション データセット内に個々のテーブルを作成します。

テーブルの名前は、アプリの ID（ピリオドはアンダースコアに変換）に基づいて付けられ、アプリのプラットフォーム（_IOS または _ANDROID）が末尾に追加されます。たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納されます。

行

テーブルの各行は、発生したセッション イベントを表します。

列

BigQuery へのストリーミング エクスポートが有効になっている場合、リアルタイム テーブルにはバッチテーブルと同じ列があります。

エクスポートされた Firebase セッションデータのテーブル内の列を次に示します。

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

2024 年 10 月中旬に、Crashlytics は Crashlytics データを BigQuery にバッチ エクスポートするための新しいインフラストラクチャをリリースしました。

すべての Firebase プロジェクトは、2025 年 9 月 15 日までに新しいバッチ エクスポート インフラストラクチャに自動的にアップグレードされます。 この日付より前にアップグレードできますが、BigQuery バッチテーブルがアップグレードの前提条件を満たしていることを確認してください。

新しいインフラストラクチャにアップグレードできますが、BigQuery バッチテーブルがアップグレードの前提条件を満たしていることを確認してください。

新しいインフラストラクチャを使用しているかどうかを確認する

2024 年 10 月中旬以降にバッチ エクスポートを有効にした場合、Firebase プロジェクトでは新しいエクスポート インフラストラクチャが自動的に使用されます。

プロジェクトで使用されているインフラストラクチャを確認するには、Google Cloud コンソールに移動します。「データ転送構成」に Firebase Crashlytics with Multi-Region Support というラベルが付いている場合、プロジェクトで新しいエクスポート インフラストラクチャが使用されています。

以前のエクスポート インフラストラクチャと新しいエクスポート インフラストラクチャの重要な違い

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

  • 2024 年 10 月中旬以前にエクスポートを有効にし、新しいエクスポート インフラストラクチャにアップグレード済み - 必要に応じてデータ エクスポートのロケーションを変更できるようになりました。

  • 2024 年 10 月中旬以降にエクスポートを有効にした - セットアップ時に、データ エクスポートのロケーションを選択するよう求められました。

• 新しいインフラストラクチャでは、エクスポートを有効にする前のデータのバックフィルをサポートしていません。

  • 以前のインフラストラクチャでは、エクスポートを有効にした日付の 30 日前までバックフィルが可能でした。

  • 新しいインフラストラクチャは、過去 30 日間または、BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）のバックフィルをサポートしています。

• 新しいインフラストラクチャでは、Firebase プロジェクト内の Firebase アプリに設定されている ID を使用して BigQuery バッチテーブルに名前が付けられます。

  • 以前のインフラストラクチャでは、アプリのバイナリ内のバンドル ID またはパッケージ名に基づいて名前が付けられたバッチテーブルにデータが書き込まれていました。

  • 新しいインフラストラクチャでは、Firebase プロジェクトに登録されている Firebase アプリに設定されているバンドル ID またはパッケージ名に基づいて名前が付けられたバッチテーブルにデータが書き込まれます。

ステップ 1: アップグレードの前提条件

1. 既存の BigQuery バッチテーブルで、Firebase プロジェクトに登録されている Firebase アプリに設定されているバンドル ID またはパッケージ名と一致する ID が使用されていることを確認します。一致しない場合は、エクスポートされたバッチデータで中断が発生する可能性があります。ほとんどのプロジェクトは適切で互換性のある状態ですが、アップグレードする前に確認することが重要です。

   • Firebase プロジェクトに登録されているすべての Firebase アプリは、Firebase コンソールで確認できます。settings [プロジェクト設定] に移動し、[マイアプリ] カードまでスクロールして、すべての Firebase アプリとその情報を表示します。

   • BigQuery バッチテーブルはすべて、Google Cloud コンソールの BigQuery ページで確認できます。

   たとえば、アップグレードで問題が発生しない理想的な状態は次のとおりです。

   • com_yourcompany_yourproject_IOS という名前のバッチテーブルと、バンドル ID com.yourcompany.yourproject の Firebase iOS+ アプリが Firebase プロジェクトに登録されている。

   • com_yourcompany_yourproject_ANDROID という名前のバッチテーブルと、パッケージ名 com.yourcompany.yourproject の Firebase Android アプリが Firebase プロジェクトに登録されている。

2. 登録済みの Firebase アプリに設定されている ID と一致しないバッチテーブル名がある場合は、手動でアップグレードする前、または 2025 年 9 月 15 日より前に、このページの後半の手順に沿ってバッチ エクスポートの中断を回避してください。

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

2024 年 10 月中旬より前にバッチ エクスポートを有効にした場合は、Firebase コンソールで Crashlytics データ エクスポートをオフにしてからオンに戻すだけで、新しいインフラストラクチャに手動でアップグレードできます。

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

1. Firebase コンソールで、[統合] ページに移動します。

2. [BigQuery] カードで [管理] をクリックします。

3. Crashlytics のスライダーをオフに切り替えて、エクスポートを無効にします。プロンプトが表示されたら、データ エクスポートの停止を確定します。

4. すぐに Crashlytics スライダーを再度オンに切り替えて、エクスポートを再度有効にします。プロンプトが表示されたら、データのエクスポートを確定します。

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

既存のバッチテーブル名が Firebase アプリ ID と一致しない