--- title: "Firebase Crashlyticsとは｜収集の3層とシンボル運用・速度アラート設計【2026年8月時点】" url: "https://www.issoh.co.jp/tech/details/17039/" published: 2026-08-27 updated: 2026-08-27 categories: ["開発"] publisher: "株式会社一創" --- # Firebase Crashlyticsとは｜収集の3層とシンボル運用・速度アラート設計【2026年8月時点】 Firebase Crashlytics は、配布したアプリが利用者の端末で落ちたときの状況を集めて、読める形に整える仕組みです。導入は依存関係を足してビルド設定を1か所いじる程度で終わります。運用で効くかを分けるのは、記号ファイルを切らさない経路があるか、非致命的例外がいつ届くかを踏まえた設計か、敷居値を誰が決めるかです。この記事では収集イベント3種の性質差、シンボル運用、アラート設計、併用判断を扱います。数値は2026年8月時点の実測値です。 ## まとめ：導入より先に記号の経路とアラート敷居値を決める Crashlytics が集めるのはクラッシュ・非致命的例外・ANR の3種類で、届くまでの時間がそれぞれ違います。クラッシュは次回の起動時、非致命的例外は次の致命的イベントか再起動時、ANR は Android 11以降の端末のみ。「今この瞬間の障害を見る監視盤」としては設計されていない、と読み替えてください。障害対応へ組み込むなら、この遅延を前提にした位置づけにします。 実務で詰まるのは記号ファイル側です。Android はプラグインがマッピングを自動で送るので事故は少ない一方、Apple は run スクリプトと入力ファイル登録が抜けると、レポートがアドレスの羅列のまま読めなくなります。CI でビルドするなら、本番用ビルドでも経路が通っているかを一度確かめておくと後が楽です。 アラートは既定値のまま始めて構いません。既定は30分間でセッションの1%超かつ25ユーザー超。この値で数リリース分のクラッシュフリー率を実測し、鳴りすぎるか鳴らなすぎるかを見てから割合と最少人数を動かします。 ## Crashlyticsが集める3種類のイベントは届く速さが違う 最初に押さえるのは、集まるデータの種類と到達のタイミングです。ここを揃えずに運用ルールを決めると、通知が来ない理由を延々と設定側に探すことになります。 ### 致命的なクラッシュが次回の起動時にまとめて送信されるまでの流れ アプリが強制終了した瞬間、端末はネットワーク送信ができる状態にありません。Crashlytics は落ちる直前までの情報を端末のストレージへ書き出しておき、次に起動されたときレポートとして送ります。ここに1つ目の遅れがある。落ちたきり二度と起動されない端末のクラッシュは、そもそも届きません。 送られたレポートは共通点で自動的にまとめられ、コンソール上では「問題（issue）」という単位になります。同じ落ち方でも呼び出し経路が違うものは、その問題のなかで別のバリアントに分かれる作り。件数の多い順に並べれば、着手の順番は自然に決まります。 ### 非致命的な例外は次のクラッシュか再起動まで届かないという制約 アプリを落とさずに握りつぶした例外も、明示的に記録すれば非致命的イベントとして送れます。API 呼び出しの失敗、画像デコードの失敗、想定外のレスポンス形式。落ちてはいないが放置したくない事象を、クラッシュと同じ画面で追える点は便利です。 ただし公式ドキュメントは送信タイミングをこう書いています。非致命的イベントは端末上に記録され、次の致命的イベントのレポートと一緒に、あるいは利用者がアプリを再起動したときに送られる、と。記録した直後にコンソールへ反映されるものではありません。**サーバ側の障害検知やSLA監視の代わりに非致命的例外を使う設計は、この一点で成立しません。**数時間から数日ぶん遅れて届く前提で、傾向を見る用途に置いてください。 ### ANRはAndroid 11以降のみでPlay Consoleの数値と一致しない Android では、応答が止まったまま戻ってこない状態、いわゆる ANR も追加設定なしで収集されます。Android の `ApplicationExitInfo` から終了時の情報を取り出す形で、この API が入った Android 11 が下限。Android 10 以前で起きた ANR は Crashlytics 側に出てきません。 結果として、Play Console の Android vitals に出る ANR 率と Crashlytics の数字は一致しません。Play Console 側は収集に同意した端末を広く含むためで、母集団が別物だと最初に共有しておくほうが早いところ。なお Android 11 と一部の Android 12 で ANR の BuildId が欠ける既知事象があり、Crashlytics Android SDK 18.3.5系以降（BoM 31.2.2系以降）で解消します。 ## 導入の手数は少なく記号ファイルを切らさない仕組みが本体になる 導入手順そのものは各プラットフォームの公式ガイドで足ります。ここで扱うのは受託案件で引っかかりやすい設定だけです。導入の全体像は[プロジェクト作成からSDK導入と初回デプロイまでの手順](https://www.issoh.co.jp/tech/details/16678/)にまとめてあります。 ### AndroidはGradleプラグインがマッピングを自動で送信する Android 側で足すのは3つです。`google-services` プラグイン（4.5系）、Crashlytics Gradle プラグイン `com.google.firebase.crashlytics`（3.0.8系）、そして Firebase Android BoM 34.18.0系ごしの `firebase-crashlytics` 依存。ブレッドクラムを出すなら `firebase-analytics` も同時に入れます。 | 要素 | 値（2026年8月時点） | 役割 | | ------------------ | ------------ | --------- | | Firebase BoM | 34.18.0系 | SDK版を束ねる | | Crashlytics プラグイン | 3.0.8系 | マッピング自動送信 | | google-services | 4.5系 | 設定ファイル読込 | | firebase-analytics | BoM準拠 | ブレッドクラム | 難所が少ないのは、難読化したビルドを検知するとプラグインがマッピングファイルを自動で送るからです。ProGuard・R8・DexGuard で検証済みと明記されており、Android Gradle プラグイン 4.2.0 以降の R8 なら追加作業なしで読めるスタックトレースになります。 ### AppleはDWARF with dSYM Fileの設定とrunスクリプトの追加 Apple 側は手数が増えます。まず Build Settings の Debug Information Format を、すべてのビルド種別で DWARF with dSYM File にすること。次に build phases へ run スクリプトを追加し、Swift Package Manager 構成なら次のパスを指定します。 ``` "${BUILD_DIR%/Build/*/}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run" ``` そのうえで、同じフェーズの Input Files に5行を登録します。dSYM フォルダ、そのなかの DWARF バイナリ、Info.plist、GoogleService-Info.plist、実行ファイルのパス。5行が抜けていても Xcode はビルドを通すため、気付くのは「dSYM が見つからない」と出てからです。React Nativeアプリへ組み込む経路は、[React Native Firebaseとは](https://www.issoh.co.jp/tech/details/17052/)で扱っています。 ``` ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME} ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME} ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist $(TARGET_BUILD_DIR)/$(UNLOCALIZED_RESOURCES_FOLDER_PATH)/GoogleService-Info.plist $(TARGET_BUILD_DIR)/$(EXECUTABLE_PATH) ``` iOS 側の開発体制そのものを設計するなら、[iOSアプリ開発の進め方と体制づくりの整理](https://www.issoh.co.jp/column/details/15765/)もあわせて見ておくと、この工程をどこに置くかの判断がしやすくなります。 ### テスト用のクラッシュを一度通すまでは導入完了と見なさない理由 公式ガイドがどのプラットフォームでもテストクラッシュを勧めるのは、経路の疎通確認が目的です。Android なら例外を投げるボタン、Apple なら `fatalError` を呼ぶボタンを一時的に置く。落として、再起動して、コンソールに出るところまで見て初めて設定が正しいと分かります。リリース前に手元に無い機種でクラッシュを拾う経路は[Firebase Test Labを扱った記事](https://www.issoh.co.jp/tech/details/17046/)で扱っています。 確かめたいのは表示の中身です。行番号とファイル名が出ているならシンボルの経路も通っており、アドレスの羅列なら記号ファイルが届いていません。**デバッグビルドだけで終わりにせず、配布に使う本番構成で一度通すこと。**構成ごとに設定が違うため、デバッグで通っても本番で読めない事態が起きます。テスト版そのものをテスターへ配る経路は[Firebase App Distributionの配信設計とテスター名簿の持ち方](https://www.issoh.co.jp/tech/details/17043/)にまとめました。 ## 読めるスタックトレースが崩れる3つの典型パターンと復旧の手順 導入して数か月たった案件で相談が来る内容は、だいたいこの章に集まります。届いてはいるのに読めない、という状態です。 ### dSYMが不足しているという通知が出たときに確かめる3つの点 Apple 側で最も多い通知です。1つ目は Debug Information Format が該当ビルド構成で DWARF with dSYM File になっているか。Release だけ設定して Ad Hoc 配布用を直し忘れる取りこぼしが典型です。2つ目は run スクリプトと Input Files 5行が該当ターゲットに入っているか。複数ターゲットの構成では片方にしか入っていない場合があります。 3つ目は App Store Connect 側で生成された dSYM の扱いです。配信側の再処理を経ると、手元のビルドとは別の dSYM が正になることがある。そのときは取得した dSYM を、SDK 同梱の `upload-symbols` スクリプトへ設定ファイルのパスとあわせて渡し、手動で送ります。CI から定期実行にしておけば、通知のたび手作業する状態から抜けられる。認証情報の扱いは[firebase-toolsの認証とデプロイ運用の記事](https://www.issoh.co.jp/tech/details/16680/)で整理した考え方がそのまま使えます。 ### ProGuard構成で残す2行とマッピング送信を切るときの判断 Android で ProGuard を使う場合、構成ファイルに `-keepattributes SourceFile,LineNumberTable` と、例外クラスを保持する行を入れておきます。前者が無いと、トレースからファイル名と行番号が消える。R8 の既定構成は公式が動作を確認済みなので、ProGuard へ寄せている案件だけ気にすれば足ります。 逆に送信を止めたい場面もあります。ビルド時間を削りたい開発用バリアントでは、モジュールの Gradle 設定で `mappingFileUploadEnabled` を false にできます。**配布して他人が触るビルドは必ず送信を有効にし、手元でしか動かさないバリアントだけ切る。**社内テスト配布まで切ると、検収期間のクラッシュが読めないまま流れます。 ### NDKのシンボルとBuildIdが欠けたときに読めなくなる範囲 C++ を含むアプリでは、Java 層と別に NDK 用の設定が要ります。ネイティブシンボルのアップロードを有効にしないと、落ちた場所がネイティブライブラリ内だったときトレースが途中で切れます。「クラッシュは出ているのに原因の関数が分からない」状態は、ここが未設定なことがほとんどです。 ANR 側では BuildId の欠落という別の症状があります。前述のとおり Android 11 と一部 Android 12 で起きる既知事象で、SDK を 18.3.5系以降へ上げれば解消します。BoM で版を束ねているなら 31.2.2系以降に上げるだけで済むので、古い案件を引き継いだときは真っ先に確かめる箇所です。 ## カスタムキーとログとユーザーIDで再現条件を残す設計を決める スタックトレースだけでは再現できない不具合があります。特定の画面遷移を経たときだけ、特定の機能フラグが有効なときだけ、といった条件付きの落ち方です。Crashlytics はレポートへ任意の情報を添える手段を用意しています。 ### カスタムキーに何を入れておくかで障害調査の初速がほぼ決まる点 カスタムキーは任意のキーと値の組をレポートへ添える機能で、コンソール側では絞り込みの軸になります。効くのは、コードを読まなくても状況が想像できる値を入れておくこと。表示中の画面ID、直前に叩いた API 名、機能フラグの有無、ログイン状態、回線種別あたりが定番です。 同じ問題に集まった数百件のうち「機能フラグ有効の端末だけ」と絞れれば、原因の範囲が一気に狭まります。何も入れていないと、標準情報である端末機種・OS版・メモリ状態だけで当たりを付けることになり、再現待ちの時間が延びます。 ### Analytics連携で入るブレッドクラムと足りない情報の補い方 Firebase Analytics を同じアプリに入れておくと、クラッシュは `app_exception` というイベントとして Analytics 側にも記録され、Crashlytics のレポートには落ちる直前のイベント列がブレッドクラムとして並びます。画面の遷移履歴が自動で残るぶん、再現手順を推測しやすくなる仕掛けです。計測イベントの設計は[Firebase Analyticsの特徴とイベント計測の解説](https://www.issoh.co.jp/tech/details/5919/)で扱っています。 足りない部分は、カスタムログで補います。自分で文字列を書き出す方式で、条件分岐のどちらへ入ったか、リトライが何回目かといった、イベント設計に載せるほどでもない情報を残す用途に向きます。両方を同じ粒度で入れると読みづらくなるので、画面遷移はブレッドクラム、内部状態はカスタムログ、と役割を分けておくのが扱いやすいところ。 ### ユーザーIDとログに個人情報を載せないための線引きを先に決める ユーザー識別子を設定すると、どの利用者がその不具合に当たったかを追えます。問い合わせと突き合わせられる一方、入れる値の設計を後回しにすると事故になります。メールアドレスや氏名をそのまま入れる実装は避け、内部IDやハッシュ済みの値に寄せてください。 カスタムログとカスタムキーも同じ扱いにします。リクエストボディをまるごとログへ流す実装は、個人情報や認証トークンを外部へ送る経路になりかねません。**「調査に要る最小限の識別子だけを残し、内容そのものは残さない」という線を、実装前に文章にしておくこと。**後から削るより、入れないほうが安く済みます。 ## アラートを障害対応のフローへ組み込むときの敷居値の決めどころ 集めるところまでは自動で進みます。運用の質を分けるのは、どの条件で誰に飛ばすかの設計です。 ### 速度アラートの既定は30分内で1%のセッションと25人という条件 アラートは大きく3種類あります。新しい問題が現れたとき、修正済みとした問題が再発したとき、そして特定の問題が急に増えたとき。3つ目が速度アラート（velocity alert）で、既定の条件は30分間のあいだに「セッションの1%を超えて発生」かつ「影響を受けた利用者が25人を超える」の両方を満たすこと。 | 項目 | 既定 | 変更できる範囲 | | ------- | --- | ------- | | 時間枠 | 30分 | 固定 | | セッション割合 | 1% | 0〜100% | | 最少ユーザー数 | 25 | 10以上 | 割合と最少ユーザー数はアプリ単位で変えられます。変更には `firebasecrashlytics.config.update` 権限が要るので、運用担当へ権限を渡すかどうかも合わせて決めておく形になります。 ### 通知先をメールとSlackとPagerDutyでどう切り分けるか 通知はメールとコンソール内表示が基本で、Slack・Jira・PagerDuty との連携も用意されています。切り分けは緊急度と受け手で決めます。速度アラートは PagerDuty か Slack の当番チャンネルへ、新規問題は開発チームへ、再発は Jira の課題として起票する、といった具合です。 もう一段踏み込むなら、Cloud Functions でアラートのトリガーを受けて自前の処理を挟む方法もあります。社内の障害管理システムへ登録する、影響範囲を判定してから通知先を振り分ける、といった構成です。関数側の設計は[トリガー設計と第2世代の実装判断をまとめた記事](https://www.issoh.co.jp/tech/details/16683/)を参照してください。 ### 敷居値は既定のまま始めてクラッシュフリー率を実測してから直す 敷居値を先に細かく決めようとすると、たいてい外れます。アプリごとに利用者数もセッション長も違うので、既定の1%と25人が緩いのか厳しいのかは実測しないと分かりません。まずは既定のまま2〜3リリース分を回し、コンソールのクラッシュフリー率と、実際に鳴ったアラートの件数を並べて見ます。 そのうえで調整します。利用者数が少ない社内向けアプリなら25人の下限に届かず一度も鳴らないので、最少ユーザー数を10まで下げる。数十万ユーザー規模なら割合を下げる。**基準は「鳴ったら必ず手を止める水準か」で、放置される通知が出始めたら緩すぎる合図です。**BigQuery へ出して独自集計を組むこともでき、エクスポート基盤は2026年3月2日に全プロジェクトが新方式へ移行済み。Crashlytics 自体は無償ですが BigQuery 側はプランに依存するため、[無料枠とBlaze超過単価の実額をまとめた記事](https://www.issoh.co.jp/tech/details/16672/)で費用の全体像を確かめておくと見積もりがぶれません。 ## Crashlyticsだけで足りる案件と別ツールの併用が要る案件 ここが判断の章です。無償で入れやすいぶん「とりあえず入れる」で終わりがちですが、向いていない用途にあてがうと、障害が起きてから足りなさに気付きます。 ### Crashlyticsを主役に据えてよい受託案件の3つの条件 次の3つが揃うなら、Crashlytics を中心に据えて問題ありません。第1に、監視対象がモバイルアプリのクライアント側に閉じていること。第2に、障害の検知が分単位ではなく時間単位で足りること。第3に、バックエンドに別の監視基盤があり、サーバ側の異常はそちらで拾えること。 受託開発ではこの3条件を満たす案件が多数派で、無償かつ件数上限なしに iOS と Android を1画面で見られます。有償のエラー監視を最初から積む理由は、下の4場面に当たらない限り薄いと言い切れます。 ### Crashlytics以外のエラー監視を併用したい4つの実務上の場面 1つ目は、サーバ側とクライアント側のエラーを1本のトレースで突き合わせたい場面。API のエラー率上昇とアプリのクラッシュ増加が同じ原因かを即座に見たいなら、同じ基盤へ集めるほうが早く着きます。[Sentryのエラー監視とAPMの機能と料金の解説](https://www.issoh.co.jp/tech/details/4148/)のような、横断型の製品が候補です。 2つ目は、分単位の検知が契約上求められる場面。前述のとおり非致命的例外は遅れて届くため、応答時間や到達率のSLAには向きません。3つ目は、Android 10以前の端末が一定割合いて、その ANR も見る必要がある場面。4つ目は、Web やバックエンドを含めて横断的にエラーを見たい場面です。範囲外は別の手段を足します。 なお、不正クライアント対策として [プロバイダ選定と監視から強制への移行の記事](https://www.issoh.co.jp/tech/details/16691/)で扱う App Check を入れている場合でも、Crashlytics は App Check の保護対象に含まれません。守れる範囲が別だという前提で構成を組んでください。 ### 受託開発で引き渡す前に決めておきたい運用面での4つの取り決め 納品して終わりにしない場合、次の4点を文章で残すと引き継ぎが軽くなります。第1に CI のどのジョブが dSYM とマッピングを送っているか。第2にアラートの宛先と敷居値、変更権限を誰が持つか。第3にカスタムキーの一覧と、何を入れない約束にしたか。第4に、どの水準のクラッシュフリー率を割ったら緊急対応へ切り替えるかです。 この4点はコードには書かれないため、担当者が変わると失われます。運用まで含めて設計する体制を外部に求めるなら、[iOS・Androidアプリの受託開発](https://www.issoh.co.jp/service/apps/native/)のように、リリース後の障害対応まで見据えて相談できる先を選ぶと、引き渡し時のこの手の取りこぼしが減ります。 ## よくある質問 ### Firebase Crashlyticsは無料で使えますか？ 2026年8月時点の料金ページでは、Crashlytics は Spark と Blaze のどちらでも「No-cost」と記載され、レポート件数による課金はありません。費用が出るのは BigQuery へエクスポートして分析する場合の BigQuery 側で、Spark はサンドボックスの制限内、Blaze は従量課金です。 ### クラッシュがコンソールに表示されないときは何を疑いますか？ まず送信タイミングを疑ってください。クラッシュは落ちた瞬間ではなく次回起動時に送られるため、一度アプリを立ち上げ直す必要があります。それでも出ないなら、設定ファイルが正しいプロジェクトのものか、デバッガを接続したまま落としていないか、依存の記述が該当ビルド構成に入っているかの順です。 ### ANRの数値がPlay Consoleと合わないのはなぜですか？ 母集団が違うためです。Crashlytics の ANR は Android 11以降の端末に限られる一方、Play Console の Android vitals は収集に同意した端末を広く含みます。設定の誤りではないので、同じ数字として扱わない前提で運用してください。 ### 非致命的例外はリアルタイム監視の代わりになりますか？ なりません。公式ドキュメントは、非致命的イベントが端末上に記録されたあと、次の致命的イベントの送信時か再起動時に送られると明記しています。数時間から数日の遅れが起きうるため、即応が要る監視は別の仕組みへ置き、Crashlytics は傾向の把握に使います。 ### 難読化したAndroidアプリでもスタックトレースは読めますか？ 読めます。Crashlytics Gradle プラグインが難読化を検知してマッピングを自動で送るため、R8 の既定構成なら追加作業は要りません。ProGuard を使う構成では SourceFile と LineNumberTable を保持する設定を入れておきます。開発用バリアントで送信を切っていると、そのビルドだけ難読化されたまま残ります。 ## 関連記事 - [Firebaseの導入手順](https://www.issoh.co.jp/tech/details/16678/)：プロジェクト作成からSDK導入までの前段です。 - [Firebase CLIとは](https://www.issoh.co.jp/tech/details/16680/)：CIからシンボルを送るときの認証運用です。 - [Firebase Analyticsとは](https://www.issoh.co.jp/tech/details/5919/)：ブレッドクラムの元になるイベント計測です。 - [Cloud Functions for Firebaseとは](https://www.issoh.co.jp/tech/details/16683/)：アラートを受けて処理を挟む関数側の設計です。 - [Firebaseの料金](https://www.issoh.co.jp/tech/details/16672/)：BigQueryエクスポートまで含めた費用の全体像です。 - [Sentryとは](https://www.issoh.co.jp/tech/details/4148/)：サーバとクライアントを横断する併用先の候補です。 - [Firebase Remote Configとは](https://www.issoh.co.jp/tech/details/17048/)：段階ロールアウトの異常検知と組で使う設定配信です。 --- 出典: [Firebase Crashlyticsとは｜収集の3層とシンボル運用・速度アラート設計【2026年8月時点】]()（株式会社一創）