Firebase Crashlytics — その概要、クラッシュと障害診断

Firebase Crashlyticsとは

Firebase Crashlyticsは、モバイルアプリの安定性を監視するためのGoogleの無料サービスであり、Googleは2017年にFabric社とともに買収しました。Crashlyticsはアプリのクラッシュに関する情報を自動的に収集し、スタックシグネチャで同一のクラッシュをグループ化し、影響を受けたユーザー数に基づいて優先順位をつけてFirebaseコンソールに表示します。

歴史と進化

Crashlyticsは2011年にFabricプラットフォームの一部としてローンチされ、すぐにiOSでのクラッシュレポートのデファクトスタンダードになりました。2017年にGoogleが推定20億ドル（Fabric全体）で買収した後、CrashlyticsはFirebase SDKに統合されました。バージョン18.0.0（2021年）ではKotlin Multiplatformのサポートが追加され、バージョン19.0.0（2024年）では追加設定なしでAndroidでの自動ANR収集が導入されました。Google（2026年）によると、Crashlyticsは月間100億以上のクラッシュを処理しています。

Crashlyticsの無料制限

Crashlyticsは、Firebaseプロジェクトあたり1日50万セッションの制限付きで無料提供されています。これはほとんどのアプリにとって十分です — Google（2026年）によると、95%のプロジェクトが制限を超えていません。制限を超えた場合、データ収集は停止しませんが、レポートは翌日まで更新されなくなります。高トラフィックのプロジェクトには、FirebaseのSparkおよびBlazeプランが利用可能です — Crashlyticsは両方のプランで無料のままで、セッション制限は別途カウントされます。

Crashlyticsがクラッシュを検出して収集する仕組み

Crashlyticsの収集メカニズムは、プラットフォームおよびランタイムレベルでの例外のインターセプトに基づいています。Androidでは、SDKがUncaughtExceptionHandlerをインストールし、すべての未処理のKotlinおよびJava例外をキャッチします。iOSでは、CrashlyticsはObjective-C/SwiftにNSSetUncaughtExceptionHandlerを、ネイティブコードのクラッシュには独自のMach例外ハンドラを使用します。

インターセプトされるクラッシュの種類

Crashlyticsは5種類のクラッシュを区別します：fatal（致命的なクラッシュ）、non-fatal（手動で渡された非致命的な例外）、ANR（Android — アプリが応答しない）、signal（OSシグナル — SIGSEGV、SIGABRT）、OOM（iOSのメモリ不足）。各タイプは別々のメカニズムで処理され、対応するラベルとともにコンソールに表示されます。

クラッシュレポートの形式

各Crashlyticsレポートには、クラス名と行番号を含む完全なスタックトレース、アプリバージョン（versionName + versionCode）、デバイスモデル、OSバージョン、空きメモリ、画面の向き、起動からの時間など、包括的な情報が含まれます。Firebase Analyticsが接続されている場合、レポートにはクラッシュ前の最後の50のユーザーイベントの経路も含まれます — これはクラッシュの再現にとって極めて重要です。

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

AndroidプロジェクトへのCrashlyticsの統合

AndroidアプリへのCrashlyticsの接続には、build.gradleに2つの依存関係を追加し、Google Servicesプラグインを設定する必要があります。SDKは追加コードなしでFirebaseの初期化時に自動的にクラッシュレポートを有効にします。正しく動作させるには、google-servicesプラグインとFirebaseコンソールのgoogle-services.jsonファイルも必要です。

// build.gradle（プロジェクトレベル）
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle（アプリレベル）
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Crashlyticsプラグインの設定

com.google.firebase.crashlyticsプラグインは2つのタスクを実行します：難読化されたスタックをマッピングするための一意のビルドID（build ID）を生成し、Crashlytics SDKのリソースを自動的に作成します。プラグインがないと、クラッシュは「unmapped」とマークされます — 難読化されたクラス名（a.b.c）のみが表示され、ソースコードを見つけることができません。プラグインはルートのbuild.gradleとアプリモジュールのbuild.gradleに追加されます。

統合の確認

Crashlyticsの統合をテストするには、特別なメソッドforceCrash()を使用してテスト例外を生成します。このメソッドはプロダクションビルドでは使用できません。テストクラッシュを実行した後、レポートは1〜5分以内にFirebaseコンソールに表示されます。レポートが表示されない場合は、google-services.jsonがアプリのパッケージと一致していること、およびAndroidManifestにデータ収集を無効にするフラグがないことを確認してください。

クラッシュ分析とレポートのグループ化

Crashlyticsコンソールは2つの表示レベルを提供します：クラッシュタイプごとにグループ化されたすべてのクラッシュ（Issues）のリストと、トレース、統計、カスタムデータを含む各Issueの詳細レポートです。各Issueは、同じシグネチャ（同じ例外タイプと一致するスタックトレース）を持つすべてのクラッシュを結合します。

Issuesとグループ化

クラッシュのグループ化はCrashlyticsの重要な機能です。何千もの個別のクラッシュを表示する代わりに、サービスはフィンガープリント（スタックトレースのチェックサム）に基づいてそれらをIssuesに結合します。1つのIssueには1から数百万のクラッシュが含まれる可能性があります。各Issueには、致命的な発生数、一意のユーザー数、クラッシュが発生したアプリバージョン、問題に遭遇したユーザーの割合が表示されます。

Google（2026年）によると、平均して20%のIssueがすべての致命的なアプリクラッシュの80%を占めています（パレートの法則）。Crashlyticsは自動的にIssueを重大度でソートします — 影響を受けるユーザーが多いほど優先度が高くなります。これにより、開発者はまず最も広範囲に及ぶ問題を修正できます。

バージョン統計

Crashlyticsは各アプリバージョンの安定性を個別に追跡します。クラッシュフリーユーザーのグラフは、各バージョンで致命的なクラッシュに遭遇しなかったユーザーの割合を示します。アップデート時にこの割合がしきい値（デフォルト99%）を下回ると、CrashlyticsはメールとFirebaseコンソールで通知を送信します。これにより、問題のあるバージョンを迅速にロールバックしたり、ホットフィックスをリリースしたりできます。

カスタムキー、ログ、Breadcrumbs

Crashlyticsは、レポートにコンテキストを追加するための3つのメカニズムを提供します：構造化データ用のカスタムキー（keys）、テキストトレース用のログ（logs）、ユーザー経路用のAnalyticsのBreadcrumbsです。3つのデータタイプすべてがクラッシュレポートに添付され、その詳細カードに表示されます。

カスタムキー

Custom Keysは、各クラッシュとともに送信されるキーと値のペアです。アプリあたり最大64キー、各キーは最大1024文字の文字列です。キーはアプリの状態をラベル付けするのに便利です：サブスクリプションレベル、認証ステータス、最後の画面、VPNが有効かどうか。値は上書きされます — 同じ名前の新しいキーが古いものを置き換えます。

イベントログ

Custom Logsは、Crashlyticsが64KBのリングバッファに保存するテキストメッセージです。ログは自動的に次のクラッシュに添付されます。クラッシュが発生しない場合、ログはサーバーに送信されません（トラフィックを消費しません）。ログはクラッシュ前のユーザーの手順を記録するために使用されます：「payment_processing_started」、「api_call_initiated」、「response_received_200」。

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

AnalyticsのBreadcrumbs

プロジェクトにFirebase Analyticsが接続されている場合、Crashlyticsは自動的にBreadcrumbsを受け取ります — クラッシュ前の最後の50の分析イベントです。各breadcrumbにはイベント名とそのパラメータが含まれます。これにより、クラッシュに至った正確なアクションの順序を再構築できます：ユーザーが画面を開いた → 商品を追加した → 支払いに進んだ → クラッシュが発生した。BreadcrumbsはIssueカードの「Logs」タブに表示されます。

クラッシュ対応のベストプラクティス

Crashlyticsは、コンテキストとIssue処理プロセスが適切に設定されている場合に最も効果的です。クラッシュ管理ワークフローを実装したチームは、重要なバグの修正時間を60%削減することが実践で示されています（Googleデータ、2026年）。

Issueの優先順位付け

すべてのクラッシュが同じように重要ではありません。ユーザー数と頻度による優先順位付けは、最も重要な問題に集中するのに役立ちます。経験則：0.1%以上のユーザーに影響を与えるIssueは24時間以内に修正します。単一発生のIssue（0.01%未満）は次の計画リリースまで延期できます。Crashlyticsは自動的にリグレッションをマークします — 修正されたが新しいバージョンで再発したIssueです。

CI/CDとの統合

Crashlytics APIを使用すると、REST APIまたはFirebase CLIを介してクラッシュレポートをCI/CDパイプラインに統合できます。新しいリリースごとに、クラッシュフリーユーザーの割合がしきい値を超えているかどうかを自動的に確認できます。しきい値を超えた場合、CI/CDはロールアウトをブロックし、チームに通知を送信します。Firebase CLIは、ProGuard/R8マッピングファイルをアップロードするためのfirebase crashlytics:builds:uploadコマンドをサポートしています — これがないとスタックが読み取れなくなります。

Google（2026年）によると、CI/CDで自動クラッシュフリーしきい値チェックを使用するアプリは、本番環境へのリグレッションが40%減少します。推奨しきい値：クリティカルリリースではクラッシュフリーユーザー >= 99.5%、通常リリースでは >= 99.0%。