【入門編】Crashlyticsの「Velocity Alerts（急増アラート）」でリリース直後のクリティカルバグを秒速で検知する運用ルール – 運用監視・オブザーバビリティ活用バイブル

こんにちは！アプリをリリースした瞬間に来る「お疲れ様でした！」の乾杯のビールの直後、Slackに轟音のように鳴り響くエラー通知の嵐……。あの背筋が凍るような経験、エンジニアなら誰もが一度は味わったことがあるのではないでしょうか。

「どの端末で落ちているんだ？」「ユーザー全体に影響しているのか？」
リリース直後の暗闇の中、パニックになりながらログの海を泳ぐのは、もう終わりにしましょう。

今回は、モバイルアプリの監視において最強の相棒である「Firebase Crashlytics」、そしてその中でもリリース直後のクリティカルバグを秒速で察知するための「Velocity Alerts（急増アラート）」の極意を、優しく、そして徹底的に解説していきます。

これをマスターすれば、リリース直後の夜もぐっすり眠れるようになりますよ。さあ、一緒に見ていきましょう！

—

1. Crashlyticsと「Velocity Alerts」の役割とは？

そもそもCrashlyticsとは何か？ 一言で言えば、「アプリがクラッシュした瞬間を捉え、開発者の元へ正確に届けてくれる黒衣のオブザーバビリティ・ツール」です。

アプリがクラッシュしたとき、ユーザーは黙ってアンインストールボタンを押します。開発者はその悲鳴に気づけません。Crashlyticsは、裏側で何が起きていたのか（スタックトレース、OSのバージョン、デバイス、さらにはユーザーがクラッシュ直前にどんな操作をしたかのカスタムログ）を自動で収集し、ダッシュボードにまとめてくれます。

そして、真骨頂が「Velocity Alerts（急増アラート）」

通常の通知は「エラーが出たら教えます」というものですが、Velocity Alertsは違います。
「特定のクラッシュが、短期間に異常なスピードで急増（Velocity）したとき」にのみ発動する、いわば「バグの津波警報」です。

新バージョンのリリース直後、特定の環境でのみ発生するクリティカルなバグ（起動直後のクラッシュなど）は、まさにこの「急増」として現れます。これを利用することで、ユーザーから問い合わせが来るよりも前に、あるいはApp Storeのレビューが荒れるよりも前に、エンジニアが先回りして検知できるのです。

—

2. 怖くない！最短で終わる基礎セットアップ

「監視ツールの導入って、なんか設定が難しそう…」と思うかもしれませんが、ご安心ください。現代のFirebaseは非常に洗練されています。

① SDKのインストール（iOS / Android共通の心構え）

まずはプロジェクトにFirebase SDKを組み込みます。ここでは概念に絞って解説しますが、基本は「Firebaseの管理画面でプロジェクトを作り、指示された設定ファイルを所定の位置に置く」だけです。

iOS (Swift / CocoaPods or Swift Package Manager) の場合:

import FirebaseCore

class AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
// 1. アプリ起動時に必ずFirebaseを初期化する
FirebaseApp.configure()

return-true
}
}

Android (Kotlin) の場合:

import android.app.Application
import com.google.firebase.FirebaseApp

class MyApplication : Application() {
onCreate() {
super.onCreate()
// 1. Firebaseの初期化（自動初期化が有効な場合は省略可ですが、明示すると安全）
FirebaseApp.initializeApp(this)
}
}

② 最も重要な「HelloWorld的」な動作確認

「ちゃんと動いているか？」を確認するために、意図的にテストクラッシュを発生させるコードを一度だけ仕込みます。これをやらずにリリースするのは、パラシュートなしでスカイダイビングするようなものです。

ボタンをタップした瞬間にアプリを強制終了させる、一番簡単なコードを書いてみましょう。

Swiftでのテストクラッシュ例:

Button(“Crash Test”) {
// 意図的な例外を発生させてCrashlyticsの動作を確認する
// ※本番コードに残さないよう注意してください！
fatalError(“Crashlytics Test Crash”)
}

Kotlinでのテストクラッシュ例:

val crashButton = Button(this).apply {
text = “Crash Test”
setOnClickListener {
// 強制的にRuntimeExceptionを発生させる
throw RuntimeException(“Crashlytics Test Crash”)
}
}

確認の手順:
1. 上記のコードを実行し、アプリをわざとクラッシュさせます。
2. アプリを再起動します（Crashlyticsは、次にアプリが起動したタイミングでレポートを送信する仕様になっています）。
3. Firebaseコンソールを開き、「Crashlytics」のダッシュボードにエラーが届いていることを確認します。

これが確認できれば、あなたのアプリはもうCrashlyticsに守られています！

—

3. 現場で生きる！Velocity Alertsの最適な閾値設定

さて、ここからが本題です。デフォルトのままだと、アラートが多すぎて「またか」とスルーしてしまったり（アラート疲れ）、逆に重要なバグを見落としたりします。

リリース直後のパニックを防ぐための、「ノイズのない、実用的な閾値（Threshold）」を設定しましょう。

黄金の閾値ルール

Firebaseコンソールの Crashlytics 設定（またはAlerts設定）から、以下のように「Velocity（急増）」の条件をカスタマイズします。

  • 条件のトリガー: 「特定の問題（Issue）の発生頻度が、1時間あたりのセッション数の一定割合を超えた場合」に通知。
  • 推奨の閾値:
  • 影響ユーザーの割合: `1%` 以上のアクティブユーザーが影響を受けた場合
  • または、クラッシュ発生回数: リリース直後（最初の24時間）は、単一のエラーが `50回` を超えた場合

> 💡 先輩エンジニアの知見:
> 単に「エラーが10件起きたら通知」にすると、ユーザー数が数百万いるアプリでは一瞬で通知が埋もれます。必ず「影響を受けているユーザーの割合（Percentage of users）」を基準にしてください。「全ユーザーの1%がこのバグを踏んでいる」という状態は、一刻を争う緊急事態（Sev-1）のサインです。

—

4. アラートを受信したエンジニアの「初動対応フローチャート」

深夜、SlackにVelocity Alertが飛んできました。さあ、どう動くべきか？ パニックを防ぐための「秒速トリアージ・フロー」を体に叩き込みましょう。

[SlackにVelocity Alert受信]
↓
①【1分以内】影響範囲の確認（全ユーザーか？ 特定OSだけか？）
↓
②【3分以内】スタックトレースの最深部（バグの震源地）を特定
↓
③【5分以内】ロールバック（旧バージョンへの差し戻し）の判断
↓
④【状況共有】ステータスチャンネルへの第一報投稿

1. 影響範囲の特定（1分）
Crashlyticsのダッシュボードを開き、「Devices」や「Operating Systems」タブを確認します。もし「iOS 17.4の特定機種だけ」であれば、OS依存のバグです。「全ユーザー」であれば、アプリの共通初期化処理（データベースのマイグレーション失敗など）に致命的なバグがあります。
2. 震源地の特定（3分）
スタックトレースの上から順に見ていくのではなく、「自分たちの書いたコード（自社パッケージ名）」が一番最初に登場する行を探します。そこがエラーの出発点です。
3. ロールバックの判断（5分）
原因の修正に時間がかかりそう、かつ影響ユーザーの離脱リスクが高いと判断した場合は、迷わずストアの配信停止や、CI/CDパイプラインから直前の安定版（前回リリース）への切り戻しを実行します。「直す」ことよりも「被害を最小限に食い止める」ことがプロの仕事です。

—

5. 誤検知を防ぐためのチューニング術

「大したことないエラーで何度も夜中に起こされる…」そんな誤検知地獄を防ぐための、知っておくべきチューニングテクニックを2つ伝授します。

① 既知の非致命的エラー（Non-fatal）のグループ化

ネットワークのタイムアウトや、サードパーティ製SDK内部での既知の軽微な例外など、「アプリは落ちていないがエラーログとして飛んでくるもの」がノイズになります。
これらは、コード内でキャッチした際に `Crashlytics.crashlytics().record(exception)` で意図的に送っている場合が多いです。

// ノイズになるエラーは、重大度を見極めて記録をコントロールする
do {
try someThirdPartyOperation()
} catch {
// アプリがクラッシュしない軽微なエラーは、Velocity Alertsの対象外にするか、
// あるいはカスタムキーで情報を付加してフィルタリングしやすくする
let crashlytics = Crashlytics.crashlytics()
crashlytics.setCustomValue(“NonCritical”, forKey: “ErrorSeverity”)
crashlytics.record(error: error)
}

② 「閉じた問題（Closed Issues）」の再発防止

一度修正して「Closed」にしたはずのエラーが、次のリリースで形を変えて復活することがあります。Crashlyticsでは、一度解決した問題が再び急増したときにもアラートを飛ばす設定が可能です。これを有効にしておくことで、「デグレ（退行不具合）」を秒速で検知できるようになります。

—

まとめ

いかがでしたか？

CrashlyticsのVelocity Alertsは、単なる「エラー通知機能」ではありません。リリース直後のエンジニアの不安を安心に変え、ユーザー体験の低下を最小限に食い止めるための「最強のレーダー」です。

  • 適切なSDKの初期化とテストクラッシュで動作を担保する。
  • 影響ユーザーの割合に基づいたスマートな閾値を設定する。
  • アラートを受け取ったら、冷静にフローチャートに沿って初動対応する。

この運用ルールをチームに導入すれば、毎日のリリース作業やデプロイが劇的に楽になり、自信を持ってプロダクトを世に送り出せるようになりますよ。

さあ、次のリリースは、安心してぐっすり眠りましょう！

スポンサーリンク
タイトルとURLをコピーしました