日記アプリのクラッシュレポートには何が含まれる可能性があるか？
日記アプリのクラッシュレポートには、クラッシュのスタックトレース、端末やアプリのバージョン、タイムスタンプ、その前後の診断イベントといった技術的な詳細が含まれる場合があります。オペレーティングシステム、レポートサービス、アプリの設定によっては、アプリ内で入力または表示されたコンテンツを露出させてしまうログ、添付ファイル、セッションリプレイデータが含まれることもあります。レポートにあらゆるケースで日記のエントリが自動的に含まれるわけではありませんが、決して含まれないと決めつけるのも安全ではありません。レポートを共有する前に、特定のレポートの内容とアプリの設定状況を確認してください。
標準的なクラッシュレポートには何が表示されるか？
スタックトレースには、クラッシュに関連する関数呼び出しが一覧表示されます。これは開発者が関係するコードパスを特定するのに役立ちますが、通常はそれ単体で詳細な状況を説明したり、ユーザーが何をしていたかを証明したりするものではありません。レポートには、アプリおよびOSのバージョン、端末モデル、クラッシュの発生時刻、その他の環境情報が含まれる場合もあります。Appleはクラッシュレポートを「クラッシュ発生時のアプリの状態の記録」と説明し、完全なOSレポートの分析を推奨しています。そのガイダンスでは、端末、アプリ、OS情報などのフィールドが明記されています。Appleの[クラッシュレポート分析ガイド](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report)をご覧ください。
レポートの形式は、その取得元によって異なります。Xcode経由で収集されたAppleのクラッシュレポートとAndroidのバグレポートは別物です。Androidの公式ガイドによると、バグレポートには端末ログ、スタックトレース、システムサービスからの診断出力、エラーログ、そしてAndroidの `Log` クラスを使用しているアプリからのシステムメッセージが含まれる場合があります。これは、クラッシュ専用の記録よりも広範な内容です。個々のレポートの内容は、実際に収集され含まれたものに左右されます。[Androidのバグレポートの取得と読み取りに関するガイド](https://developer.android.com/studio/debug/bug-report)をご覧ください。
レポートに日記の本文が含まれることはあるか？
一部の設定では含まれる可能性がありますが、クラッシュレポートが存在すること自体が、エントリの本文が含まれていることを示すわけではありません。重要なのは、クラッシュとともにアプリが何を記録しているか、そしてレポートの形式が何を捕捉しているかです。
たとえば、アプリ開発者が診断ログメッセージやカスタムイベントを追加している場合があります。それらのメッセージに日記のエントリ、タイトル、検索語句、またはエディタからコピーされたテキストが含まれている場合、その情報がイベントとともに送信される可能性があります。Sentryはブレッドクラム（Breadcrumbs）を「問題が発生する前の一連のイベントの記録」と説明しており、それぞれにメッセージと任意の構造化データを持たせることができます。ブレッドクラムは、有効化されたインテグレーションを通じて自動的に収集される場合もあれば、アプリによって追加される場合もあります。[Sentryのブレッドクラムに関するドキュメント](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/)をご覧ください。また、Androidのバグレポートにもシステムメッセージログが含まれており、これにアプリによって書き込まれたメッセージが含まれることがあります。どちらの事実も、すべてのアプリがプライベートなテキストを記録していることを意味するわけではありません。それはアプリの実装と設定によります。
ログ、ブレッドクラム、添付ファイル、リプレイとは何か？
これらの用語は、それぞれ異なる種類の診断データを指します。ログは、アプリまたはシステムによって記録されたメッセージです。ブレッドクラムは、エラーに至るまでに選択された一連のイベントであり、タイムスタンプ、カテゴリ、メッセージ、キーと値のペアのデータが含まれる可能性があります。アプリが何を記録しているかによって、どちらもスタックトレース以上のコンテキストを明らかにする場合があります。
添付ファイルは、ログファイル、スクリーンショット、クラッシュダンプなど、イベントとともに送信されるファイルです。Sentryは、ネイティブのミニダンプに環境変数、ローカルパス、入力フィールドのメモリ内表現などの機密情報が含まれる可能性があると指摘しています。同社のドキュメントによると、ミニダンプはイベント作成に使用されデフォルトでは破棄されますが、設定が有効になっている場合は添付ファイルとして保存されることがあります。また、添付ファイルはSentryのデータスクラビング（個人情報削除処理）の対象外であるとも記載されています。クラッシュデータに関する[Sentryのドキュメント](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/)および[添付ファイルに関するドキュメント](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/)をご覧ください。
セッションリプレイは独立したオプション機能であり、すべてのクラッシュレポートの標準コンポーネントではありません。SentryのJavaScriptリプレイに関するドキュメントでは、DOMの状態や操作を含む、ブラウザアクティビティの動画のような再構築について説明されています。SDKはデフォルトでDOMテキスト、画像、ユーザー入力をマスキングする一方、設定オプションも提供しているとされています。マスキング設定と対応プラットフォームが重要となります。実際のプロバイダーの設定やプライバシー設定を確認せずに、日記のコンテンツが表示されている、あるいは保護されていると推測しないでください。[SentryのJavaScript Session Replayガイド](https://docs.sentry.io/platforms/javascript/session-replay/)をご覧ください。
レポートを共有する前に何を確認すべきか？
実際のファイルまたはレポートのプレビューに対してこのチェックリストを使用し、レポートの内容が不明確な場合はアプリやプロバイダーのプライバシードキュメントを確認してください：
このチェックリストは、レポートを送信する前に確認する日記ユーザー向けの実用的なエディトリアルガイダンスです。これは開発者向けの指示とは異なります。開発者は独自のロギング、リプレイ、添付ファイルの設定を管理しており、それらの機能が何を収集するかを文書化し、診断フィールドにユーザーが入力したコンテンツが含まれ得るかどうかを確認する必要があります。
なぜアプリや端末によってレポートが異なるのか？
オペレーティングシステムによって生成されるレポート形式や収集経路は異なります。また、開発者が独自の設定でサードパーティ製SDKを使用している場合もあります。Appleによると、App StoreおよびTestFlightのクラッシュレポートはXcodeを通じて入手できますが、その他の診断ログは端末から転送する必要がある場合があります。Androidでは、完全なバグレポートと、Google PlayやFirebaseなどのサービスを通じて提供されるクラッシュレポートを区別しています。さらにプロバイダーの設定によって、どのイベント、ブレッドクラム、添付ファイル、リプレイデータが捕捉・保存されるかが決まります。すべてのサービスが同じフィールドを送信すると決めつけるのではなく、アプリのプライバシー通知と実際のレポートを、個別のケースに応じた判断基準としてください。