はじめに
前回の記事では、Claude Code に Firebase プラグインをインストールし、Crashlytics のクラッシュログをターミナルから直接取得する手順を紹介しました。
本記事はその続編として、取得した Crashlytics データをもとに Claude Code にクラッシュの原因分析と修正コードの提案まで一気通貫で行わせるワークフローを、VS Code 上の実践例とともに解説します。
この記事でできるようになること
- Crashlytics の Top Issues を取得し、優先度の高いクラッシュを特定する
- クラッシュのスタックトレースから原因を分析させる
- プロジェクト内の該当ソースコードを特定し、修正コードを提案させる
- 修正の適用まで VS Code 上で完結させる
前提条件
- 前回の記事の手順が完了していること(Firebase プラグインのインストール・認証済み)
- VS Code に Claude Code 拡張機能が導入されていること
- 対象の iOS プロジェクトが VS Code で開かれていること
- (社内プロジェクトの場合)VPN 接続環境
全体ワークフロー
本記事で紹介するワークフローの全体像は以下のとおりです。
① Crashlytics から Top Issues を取得
↓
② 優先度の高いクラッシュを特定
↓
③ スタックトレースの詳細を取得・原因分析
↓
④ プロジェクト内の該当ソースコードを特定
↓
⑤ 修正コードの提案・レビュー
↓
⑥ 修正の適用(VS Code 上で完結)
Step 1: Crashlytics の Top Issues を取得する
VS Code のターミナルで Claude Code を起動し、以下のように入力します。
過去24時間の Crashlytics の issue を取得して
Claude Code が Firebase プラグインの crashlytics_get_report を実行し、以下のように FATAL(クラッシュ)と NON-FATAL(例外)に分類して結果を返します。
FATAL(クラッシュ)— 3件
# | Issue | イベント数 | 影響ユーザー | シグナル
1 | XXX_Runtime_SetProperty | 12 | 12 | EARLY (92%が起動1秒以内)
2 | XXX_Service_GetInfo — EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) | 11 | 11 | EARLY (82%が起動1秒以内)
3 | -[NSISEngine optimize] — バックグラウンドスレッドからのレイアウト変更 | 5 | 5 | —
EARLY シグナルは、アプリ起動から1秒以内に発生したクラッシュを示します。ユーザーがアプリを開いた直後にクラッシュするため、UX への影響が非常に大きく、最優先で対応すべきクラッシュです。
Step 2: 優先度の判断を Claude Code に任せる
取得結果をもとに、Claude Code に優先度の判断を依頼します。
この3件のクラッシュについて、優先度を判断して。
影響ユーザー数、EARLYシグナルの有無、クラッシュの性質を考慮して。
Claude Code は以下のような観点で分析を行います。
- 影響範囲 — イベント数と影響ユーザー数の比率(1:1 なら特定条件で確実に再現)
- EARLY シグナル — 起動直後のクラッシュはユーザー離脱に直結
- クラッシュの性質 — メモリアクセス違反(EXC_BAD_ACCESS)はセキュリティリスクにもなり得る
優先度の判断結果に基づき、最も影響の大きいクラッシュから順に分析を進めます。
Step 3: スタックトレースの詳細取得と原因分析
特定のクラッシュについて、詳細なスタックトレースを取得します。
XXX_Runtime_SetProperty のスタックトレースを取得して、原因を分析して
Claude Code が crashlytics_list_events を実行し、スタックトレースの各フレームを解析します。
Plugin Firebase Firebase [crashlytics_list_events]
filter.issueId: 'xxxxxxxxxxxxxxxxxxxxxxxx'
分析結果として、以下のような情報が返されます。
- クラッシュが発生した 具体的なメソッド・行番号
- 呼び出し元の コールチェーン
- 発生条件の 推定パターン(起動時、特定 OS バージョン、特定デバイスなど)
原因分析のプロンプト例
より深い分析が必要な場合は、以下のように具体的に指示します。
このクラッシュについて以下を分析して:
1. 直接原因(どのコードが例外を起こしているか)
2. 根本原因(なぜその状態に至るか)
3. 再現条件の推定
4. 影響を受ける iOS バージョンやデバイスの傾向
Step 4: プロジェクト内の該当ソースコードを特定する
ここが VS Code 上で Claude Code を使う最大のメリットです。Claude Code はプロジェクトのソースコードにアクセスできるため、スタックトレースの情報とプロジェクト内のコードを突き合わせて該当箇所を特定できます。
このスタックトレースに該当するプロジェクト内のソースコードを見つけて
Claude Code はプロジェクト内のファイルを検索し、該当するクラスやメソッドを特定します。例えば以下のような出力が得られます。
該当ファイル: Sources/Services/XXXService.swift
該当メソッド: func getInfo(for id: String) -> ServiceInfo (L.42-68)
問題箇所: L.55 で Optional の強制アンラップ(force unwrap)を行っており、
nil が入った場合に EXC_BAD_ACCESS が発生します。
-[NSISEngine optimize] の場合
3件目の Auto Layout 関連クラッシュの場合は、以下のように依頼します。
バックグラウンドスレッドから UI を更新している箇所をプロジェクト内から検出して
Claude Code がプロジェクト全体を走査し、DispatchQueue.main.async で囲まれていない UI 更新コードを一覧で提示してくれます。
Step 5: 修正コードの提案
該当箇所が特定できたら、修正コードの提案を依頼します。
この問題の修正コードを提案して。iOS 15 以上をサポート。安全なアンラップと適切なエラーハンドリングを含めて。
Claude Code は、以下のように修正前後のコードを対比して提案します。
例: EXC_BAD_ACCESS の修正提案
修正前:
// ⚠️ force unwrap により nil の場合に EXC_BAD_ACCESS が発生
func getInfo(for id: String) -> ServiceInfo {
let data = cache[id]! // ← クラッシュポイント
return ServiceInfo(data: data)
}
修正後:
// ✅ guard let による安全なアンラップとエラーハンドリング
func getInfo(for id: String) -> ServiceInfo? {
// キャッシュから安全に値を取得し、nil の場合は早期リターン
guard let data = cache[id] else {
// キャッシュミス時のログ出力(Crashlytics にも記録)
Crashlytics.crashlytics().log("Cache miss for id: \(id)")
return nil
}
return ServiceInfo(data: data)
}
例: バックグラウンドスレッドからの UI 更新の修正提案
修正前:
// ⚠️ バックグラウンドスレッドから直接 UI を更新
func updateLayout(with result: FetchResult) {
self.titleLabel.text = result.title // ← メインスレッド以外から呼ばれる可能性
self.view.setNeedsLayout() // ← NSISEngine クラッシュの原因
}
修正後:
// ✅ メインスレッドでの UI 更新を保証
func updateLayout(with result: FetchResult) {
// MainActor で UI 更新をメインスレッドにディスパッチ
DispatchQueue.main.async { [weak self] in
guard let self else { return }
self.titleLabel.text = result.title
self.view.setNeedsLayout()
}
}
iOS 15 以上であれば @MainActor アノテーションを活用した Swift Concurrency ベースの修正も選択肢になります。プロジェクトの Concurrency 移行状況に応じて Claude Code に指示してください。
@MainActor ベースの修正パターンも提案して
Step 6: 修正の適用
提案された修正コードに問題がなければ、Claude Code にそのまま適用を指示します。
この修正を適用して
Claude Code が VS Code 上でファイルを直接編集し、差分(diff)を表示します。VS Code の「Accept」ボタンで修正を確定するか、「Reject」で元に戻すことができます。
適用後の確認
修正適用後は、以下のように追加の依頼を行うと安心です。
この修正に対するユニットテストを作成して
この修正により影響を受ける他の箇所がないか確認して
実践的なプロンプト集
日常のクラッシュ監視・修正で使えるプロンプトをまとめます。
クラッシュの取得・分析
# 期間指定での取得
過去1週間の Crashlytics Top Issues を取得して
# 特定シグナルのフィルタリング
起動時(EARLY)に発生しているクラッシュだけ一覧にして
# バージョン別の比較
v5.2.0 と v5.3.0 でクラッシュ率に差があるか確認して
原因分析・修正
# 包括的な分析依頼
このクラッシュの原因分析、修正コード、ユニットテストをまとめて提案して
# 特定パターンの一括検出
プロジェクト内の force unwrap(!)を全て検出して、安全なアンラップに置き換える提案をして
# 既存コードの予防的改善
EXC_BAD_ACCESS が発生しそうな危険な箇所をプロジェクト全体から検出して
まとめ
Claude Code と Firebase Crashlytics プラグインを VS Code 上で組み合わせることで、以下の一連のワークフローがひとつのターミナルで完結します。
クラッシュログ取得 → 優先度判断 → 原因分析 → コード特定 → 修正提案 → 適用 → テスト作成
従来であれば、Firebase Console でクラッシュを確認 → Xcode でスタックトレースを追跡 → 手動でコードを修正、という複数ツールを横断する作業が必要でした。Claude Code を活用することで、このサイクルを大幅に短縮できます。
特に、スタックトレースとプロジェクト内のソースコードを自動的に突き合わせて原因箇所を特定してくれる点が、単に Crashlytics のデータを見るだけでは得られない大きな価値です。
シリーズ記事
- 【第1弾】Claude Code × Firebase Crashlytics でクラッシュログを直接取得する方法
- 本記事:クラッシュの原因分析から修正コードの提案まで(この記事)
- 【第3弾】CLAUDE.md とカスタムコマンドでワークフローを自動化する
- 【第4弾】Claude Cowork で Crashlytics レポートから PowerPoint 資料を自動生成する
