iOS+
Android
Flutter
Unity
このページでは、Crashlytics の使用に関するトラブルシューティングのヘルプ情報と、よくある質問への回答を紹介します。お探しの情報が見つからない場合や、サポートが必要な場合は、Firebase サポート にお問い合わせください。
一般的なトラブルシューティングとよくある質問
クラッシュの影響を受けていないユーザーはどのように計算されますか？
クラッシュなしの値は、特定の期間にアプリを利用したユーザーのうち、クラッシュが発生しなかったユーザーの割合を表します。
クラッシュの影響を受けていないユーザーの割合を計算する式は次のとおりです。入力値は Google アナリティクスから提供されます。
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS ) x 100
注: クラッシュの影響を受けていないアプリユーザーの割合を自分で計算する場合は、アプリの app_exception イベントの数をアナリティクス ダッシュボードで確認できます。ただし、クラッシュの処理方法に多少の違いがあるため、アナリティクス ダッシュボードに表示される app_exception の値は、クラッシュの影響を受けていないユーザーの割合を計算するのに Google が使用する値と異なる場合があります。 クラッシュの影響を受けていないユーザーの割合は、時間の経過に伴う集計 です。平均ではありません。
たとえば、アプリに 3 人のユーザーがいて、それぞれユーザー A、ユーザー B、ユーザー C とします。次の表は、それぞれの日にアプリを利用したユーザーと、その日にクラッシュが発生したユーザーを示しています。
月曜日
火曜日
水曜日
アプリを利用したユーザー
A、B、C
A、B、C
A、B
クラッシュが発生したユーザー
C
B
A
水曜日にクラッシュの影響を受けていないユーザーの割合は 50% です（ユーザーの 2 人に 1 人はクラッシュの影響を受けませんでした）。水曜日にアプリを利用したユーザーは 2 人でしたが、そのうち 1 人（ユーザー B）にはクラッシュが発生しませんでした。
過去 2 日間にクラッシュの影響を受けていないユーザーの割合は 33.3% です（ユーザーの 3 人に 1 人はクラッシュの影響を受けませんでした）。過去 2 日間にアプリを利用したユーザーは 3 人でしたが、クラッシュが発生しなかったのはそのうち 1 人（ユーザー C）だけでした。
過去 3 日間にクラッシュの影響を受けていないユーザーの割合は 0% です（ユーザー 3 人の中にクラッシュの影響を受けなかったユーザーはいませんでした）。
クラッシュの影響を受けていないユーザーの値を、異なる期間で比較しないでください。1 人のユーザーがクラッシュを経験する確率は、アプリの使用回数が増えるほど高くなるため、クラッシュの影響を受けていないユーザーの値は、期間が長くなるほど小さくなる可能性があります。
注: 非致命的な問題のみが表示されるように [イベントの種類]
問題に関するノートを表示、書き込み、削除できるのは誰ですか？
ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。
ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。
ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。
インテグレーション
アプリで Google Mobile Ads SDK を使用しているが、クラッシュが取得されない
プロジェクトで Google Mobile Ads SDK と Crashlytics を併用している場合、例外ハンドラの登録時にクラッシュ レポート機能が干渉している可能性があります。この問題を解決するには、disableSDKCrashReporting を呼び出して Mobile Ads SDK でクラッシュ レポートをオフにしてください。
BigQuery データセットはどこに配置されますか？
Crashlytics を BigQuery にリンクすると、作成される新しいデータセットは、Firebase プロジェクトのロケーションに関係なく自動的に米国に配置されます。
問題の回帰
問題の回帰とは
以前にクローズした問題が再発して Crashlytics が新しいレポートを受け取った場合、その問題で回帰が発生したと言います。回帰が発生した問題は、アプリに適した方法で対応できるよう Crashlytics によって自動的に再オープンされます。
次のような場合、Crashlytics は問題を回帰として分類します。
Crashlytics が初めて、クラッシュ「A」に関するクラッシュ レポートを受け取りました。Crashlytics は、そのクラッシュに対応する問題（問題「A」）をオープンしました。
あなたはこのバグを速やかに修正し、問題「A」をクローズしてから、アプリの新しいバージョンをリリースしました。
問題をクローズにした後で、Crashlytics が問題「A」に関する別のレポートを取けとりました。
このレポートが、この問題をクローズしたときに Crashlytics で認識されていたバージョン（つまり、なんらかのクラッシュに関するレポートを送信したことがあるバージョン）のアプリから送信されたものである場合、問題は回帰と見なされません。
このレポートが、この問題をクローズしたときに Crashlytics で認識されていなかった バージョン（つまりクラッシュに関するレポートを以前に送信したことがないバージョン）のアプリから送信されたものである場合、問題は回帰と見なされて再オープンされます。
注: 2022 年 2 月以前は、問題をクローズしたときに認識されていたアプリのバージョンであるかないかに関わらず、Crashlytics は再発した問題をすべて回帰として分類していました。 問題の回帰が発生すると、回帰検出アラートが送信されます。つまり回帰シグナルを問題に追加して、Crashlytics が問題を再オープンしたことを知らせます。この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
古いバージョンのアプリで問題の回帰が発生するのはなぜですか？
レポートを送信したアプリのバージョンが、問題をクローズした時点でクラッシュ レポートを一度も送信したことのない古いバージョンである場合、Crashlytics は問題の回帰が発生したと見なし、その問題を再オープンします。
このような状況は、バグを修正し、新しいバージョンのアプリをリリースしたにもかかわらず、バグが修正されていない古いバージョンを利用しているユーザーがいる場合に発生することがあります。問題をクローズした時点でクラッシュ レポートを一度も送信したことのない、古いバージョンのアプリがまだ使用されている場合、そのバージョンで
この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
注: 2022 年 2 月以前は、問題をクローズしたときに認識されていたアプリのバージョンであるかないかに関わらず、Crashlytics は再発した問題をすべて回帰として分類していました。その結果、Crashlytics で回帰を正確に識別できないことがありました。そこで現在は、上記の規則が使用されています。
