クラッシュレポート収集

AIBudsCrashReporter はクラッシュレポートをローカルに保存します。ホストアプリは次回起動時にレポートを検出し、社内向け診断フローで確認して、独自バックエンドへアップロードした後に削除できます。

このモジュールは、ユーザー同意、アップロード方式、保存期間、サポート担当者のアクセス権を定義しません。これらはホストアプリ側で設計してください。

Animated workflow

起動をまたぐクラッシュレポートのライフサイクル

クラッシュした起動でレポートを収集し、次回起動後に検出して製品側の方針に従って処理します。

01現在の起動

H

早期にインストール

アプリケーションのライフサイクルから 1 つのレポーターをインストールします。

02Crash Reporter

D

クラッシュを収集

プロセス異常終了時にクラッシュレポートをローカルへ保存します。

03次回起動

%

アプリを再起動

起動後に前回起動時のクラッシュを検出します。

起動をまたいで処理

04ホストアプリ

S

レポート一覧を取得

起動のクリティカルパス外で、新しい順にレポートパスを取得します。

05製品バックエンド

H

同意に基づいて処理

アプリが管理する保護されたフローで確認またはアップロードします。

06保持ポリシー

✓

処理後に削除

受領確認または期限切れ後に、一覧から取得したパスだけを削除します。

↳承認済みアップロードの受領確認、またはローカル保持期限までレポートを保存してください。

早期に導入し、次回起動時に処理する

機能処理を開始する前に、アプリケーションのライフサイクルから CrashReporterSDK を一度だけインストールします。既定では、レポートはアプリの Documents ディレクトリにある .aibuds/crash_logs へ保存されます。明確な保存ポリシーがある場合は、任意のルートパスを指定できます。

前回の起動時にクラッシュしていた場合、last-crash コールバックは利用可能な最新レポートのパスを通知します。report-list コールバックはローカル一覧の変更を通知します。どちらのコールバックも、レポートのアップロードや削除は行いません。

Swift

Swift

CrashReporterSDK.install(
    withLastCrashReportCallback: { path in
        guard let path else { return }
        // Enqueue consent-aware inspection or upload outside this callback.
    },
    reportListUpdateCallback: {
        // Refresh internal diagnostic state.
    }
)

Objective-C

Objective-C

[AIBudsCrashReporterSDK
    installWithLastCrashReportCallback:^(NSString *_Nullable path) {
        if (path == nil) {
            return;
        }
        // Enqueue consent-aware inspection or upload outside this callback.
    }
              reportListUpdateCallback:^{
                  // Refresh internal diagnostic state.
              }];

All-in-One にもこのモジュールは含まれますが、installCrashReporter の明示的な呼び出しは必要です。

AI を活用して実装

AI で実装

AI でこのワークフローを実装

公式の「AIBuds クラッシュレポートの管理」スキルを使い、アプリに合わせて実装します。

https://docs-aibuds.github.io/ja/skills/manage-aibuds-crash-reports を読み、その指示に従ってください。このスキルで「AIBuds クラッシュレポートの管理」をこの iOS プロジェクトに実装し、検証してください。

公式スキルを見る↗

レポートの管理責任

allCrashReportPaths() はレポートパスを新しい順に返します。レポートの読み込みまたはアップロードを非同期で行い、成功を確認してから、その一覧から取得したパスに限って deleteCrashReport を呼び出してください。

削除 API に任意のファイルパスを渡さないでください。再試行は冪等になるよう設計し、バックエンドが受領を確認するか、保持期限が切れるまでレポートを残します。

ユーザー情報

setUserInfo(_:forKey:) には String、Int、UInt、Double、Bool、Date を指定でき、キー単位で値を削除できます。クラッシュレポートに保存しても安全で、値の種類が限定された診断情報だけを追加してください。

アクセストークン、文字起こし、音声、メールアドレス、完全なデバイス識別子、正確な位置情報などの個人データを含めないでください。後のクラッシュへ古い情報が付加されないよう、セッション終了時にセッション限定の値を削除します。

プライバシーと運用

• 収集とアップロードに必要な同意を取得します。
• アップロードを暗号化し、サポート用バックエンドを認証します。
• ローカルおよびサーバー側のアクセスを制限します。
• レポートの最長保存期間とディスク使用量を定めます。
• 対応するビルド成果物を使い、信頼できる環境でシンボリケートします。
• クラッシュレポートの送信失敗がアプリ起動を妨げないよう分離します。
• 本番環境の検証フローで意図的にクラッシュを発生させないでください。

検証チェックリスト

• 起動初期に一度だけインストールされる。
• 前回起動時のレポートは起動のクリティカルパス外で処理される。
• アップロード受領を確認してから削除する。
• 一覧から取得したレポートパスだけを削除する。
• ユーザー情報に秘密情報や機密コンテンツを含めない。
• 無効になったセッション限定メタデータを削除する。
• 保持期間、同意、シンボリケート、バックエンドアクセスを文書化する。
• 承認済みの非本番シナリオで、リリースビルドのクラッシュ収集をテストする。