【入門編】Crashlyticsのカスタムキー(Custom Keys)を活用してバグ特定スピードを10倍にする裏技 – 運用監視・オブザーバビリティ活用バイブル

Crashlyticsのカスタムキーで「再現できないバグ」を撲滅する—デバッグ速度を10倍にする現場の技術

こんにちは。オブザーバビリティの世界へようこそ。

現場で開発をしていると、一度は経験するはずです。「なぜか特定の環境でだけ落ちる」「再現手順が不明でバグ報告が放置される」という悪夢。Crashlyticsは単なるクラッシュレポートツールではありません。 使いこなせば、あなたのアプリの「死因」を即座に特定し、修正を最短距離で終わらせるための最強の武器になります。

今回は、Crashlyticsのポテンシャルを解放する「カスタムキー」の極意を伝授します。

—

1. なぜ「カスタムキー」なのか?(本質を理解する)

標準のCrashlyticsは、スタックトレース(どこで落ちたか)は教えてくれます。しかし、「なぜその状態になったのか」という文脈(Context)までは教えてくれません。

例えば:

  • どの画面で?
  • どんな入力値を渡した時に?
  • 直前にどのAPIを叩いたか?

これらが分かれば、再現手順を推測する時間はゼロになります。カスタムキーは、クラッシュした瞬間のアプリの「思考状態」を記録するスナップショットなのです。

—

2. 導入:まずは「HelloWorld」で感覚を掴む

まずは、最もシンプルな設定から始めましょう。Firebaseプロジェクトにアプリを登録し、SDKを導入済みであることを前提に進めます。

実装:Crashlyticsに情報を埋め込む

Swift(iOS)を例にしますが、Androidでも概念は同じです。

import FirebaseCrashlytics

func processPayment(amount: Double, screenName: String) {
// 【重要】エラー発生時に備えてコンテキストを記録する
Crashlytics.crashlytics().setCustomValue(amount, forKey: “last_payment_amount”)
Crashlytics.crashlytics().setCustomValue(screenName, forKey: “current_view”)

// 何らかの処理…
// もしここで落ちたら、これら二つの値がクラッシュログと共に送信される
}

たったこれだけです。これだけで、ダッシュボード上の「Keys」タブに、クラッシュ時の金額と画面名が鮮明に表示されます。

—

3. 現場で震えるほど役立つ「ログ設計」ベストプラクティス

初心者から脱却し、シニアエンジニアの領域に入るための「3つの鉄則」を紹介します。

① 「状態」を上書きし続ける(Circular Bufferの思想)

全てのログを保存しようとするとメモリを圧迫します。直近の操作だけを保持しましょう。

// 画面遷移ごとにキーを更新するだけで、クラッシュ時の直前画面が判明する
Crashlytics.crashlytics().setCustomValue(currentViewControllerName, forKey: “last_visited_view”)

② ユーザーIDは絶対に紐付ける(匿名化しつつ識別)

ログインしているユーザーが特定できれば、「そのユーザーのDBデータがおかしいのか?」という仮説検証が1秒で終わります。

// 個人情報を直接含めず、システム固有のUIDをセットする
Crashlytics.crashlytics().setUserID(“user_12345_uuid”)

③ ログレベルを混ぜる(Log + Keyの合わせ技)

クラッシュに至るまでの経緯を追いたい場合、`log`メソッドを併用するのがプロの流儀です。

Crashlytics.crashlytics().log(“Payment process started”)
Crashlytics.crashlytics().setCustomValue(transactionID, forKey: “tx_id”)
// 意図的なエラーログ送信
Crashlytics.crashlytics().record(error: myError)

—

4. なぜこれが「デバッグ速度10倍」になるのか?

想像してください。バグ報告が上がってきたとき、あなたはもう「再現手順」を探して画面をポチポチする必要はありません。

1. Firebaseダッシュボードを開く
2. クラッシュログを見る
3. カスタムキーを確認する:「ああ、この入力値の時だけバリデーションが抜けてるのか!」
4. 修正完了。

このプロセスには「推測」がありません。あるのは「事実」だけです。これがオブザーバビリティの力です。

—

最後に:心構え

オブザーバビリティとは、「システムに語らせる技術」です。
コードを書く時、「この変数がクラッシュの瞬間に見えなかったら、自分はどうやってデバッグするだろう?」と自問自答してみてください。

その疑問に対する答えを`setCustomValue`としてコードに埋め込むだけで、あなたの開発体験は劇的に変わります。今日から、ログをただのテキストではなく「宝の地図」に変えていきましょう。

迷ったときはいつでも戻ってきてください。また次の極限の知見を授けましょう。

タイトルとURLをコピーしました