Google Playの「データセーフティ」は、ストアを見た利用者に、アプリがどのデータを収集・共有し、どのように扱うかを伝える欄です。個人開発では「自分はサーバーを持っていないから収集なし」と判断しがちですが、広告、分析、クラッシュ報告などのSDKが端末外へデータを送る場合があります。
正しく回答する近道は、Play Consoleの質問を見ながら推測することではありません。先にアプリのデータフローを一覧化し、その結果をフォームへ転記します。この記事では、その順番を具体的にまとめます。
データセーフティで確認されること
大きく分けると「収集するデータ」「共有するデータ」「利用目的」「データの扱い方」です。Google Playの公式説明では、端末外へ送信されるユーザーデータは、SDKによる送信も含めて確認対象になります。一方、端末内だけでアクセス・処理し、外部へ送らないデータは、通常は収集として申告する範囲に含まれません。
- どの種類のユーザーデータを端末外へ送るか
- 開発者または第三者がデータを受け取るか
- 機能提供、分析、広告、不正防止など何に使うか
- 収集が必須か、ユーザーが選択できるか
- 転送時に暗号化されるか
- 削除を依頼できる仕組みがあるか
「収集」と「共有」を分けて考える
収集は、アプリからユーザーの端末外へデータを送ることを軸に判断します。送信先が自分のサーバーでなく、組み込んだライブラリの提供会社でも確認が必要です。仮名化された識別子でも、ユーザーと再関連付けできる可能性がある情報は見落とせません。
共有は、収集したデータを第三者へ移すことを軸にします。ただし、サービスプロバイダーとして処理する場合など、公式定義上「共有」に該当しないケースもあります。契約、処理目的、相手との関係によって判断が変わるため、SDK提供元の説明とGoogle Playの定義を両方確認します。
実務手順1：機能ごとにデータフローを書く
アプリ全体を一度に考えると漏れやすいため、ログイン、バックアップ、写真選択、広告表示、エラー報告など機能単位で確認します。次の6項目を1行ずつ記録すると、そのまま申告の根拠資料になります。
- 扱うデータの種類
- 取得するタイミング
- 端末外へ送るか
- 送信先
- 利用目的
- 保存期間と削除方法
例として、クラッシュ報告を導入している場合、アプリの診断情報や端末情報が送信される可能性があります。どの項目が送られるかは、利用しているサービス、設定、SDKバージョンによって異なるため、サービス名だけで決めず自分の構成を確認します。
実務手順2：権限・通信・SDKを照合する
- 権限：AndroidManifest.xmlとマージ後のManifestを確認する
- 通信：自作API、WebView、アップロード、ログ送信を確認する
- SDK：Gradle依存関係とSDK提供元のデータ開示を確認する
- 設定：自動収集、広告ID、同意管理、地域別設定を確認する
- 配布版：デバッグ版ではなく、実際に配布するビルドで確認する
ライブラリが追加した権限は、ソースのManifestだけでは見えないことがあります。Android StudioのMerged Manifestや依存関係ツリーを確認すると、意図していない権限や古いSDKを発見しやすくなります。不要なものは申告だけで済ませず、削除できないか検討します。
実務手順3：フォームに転記する
Play Consoleの「アプリのコンテンツ」からデータセーフティを開き、棚卸し結果に基づいて回答します。収集または共有するデータがある場合は、種類ごとに目的、必須・任意、保存や処理の性質を答えます。迷う項目は推測で送信せず、下書き保存してSDK資料や実装を再確認します。
アプリのバージョンや地域で動作が違う場合、現在Google Playで配布している各バージョンのデータ処理を含めた全体像が必要です。「日本では使わない」「新バージョンでは削除した」という理由だけで、まだ配布中の旧版の処理を無視しないようにします。
よくある誤りと直し方
- 誤り：サーバーがないので収集なし → 確認：SDKとWebViewの通信を調べる
- 誤り：権限一覧だけで回答する → 確認：実際の端末外送信と利用目的を調べる
- 誤り：SDKの一般的な説明をそのまま転記する → 確認：自分の設定とバージョンを照合する
- 誤り：プライバシーポリシーと別々に更新する → 確認：同じ棚卸し表から両方を更新する
- 誤り：初回公開後は見直さない → 確認：機能・権限・SDK変更を更新条件にする
「収集なし」のアプリでも行う確認
完全オフラインのアプリでも、データセーフティフォームの提出とプライバシーポリシーのリンクが必要になる場合があります。クラッシュ報告や広告を後から追加すれば回答も変わります。現在の実装で端末外送信がないことを確認し、その状態をリリース記録に残しておくと更新時の比較が簡単です。
更新時チェックリスト
- 新しい権限を追加した
- SDKを追加・更新・削除した
- ログイン、同期、広告、分析の設定を変えた
- 対象年齢や配布地域を変えた
- データの保存期間や削除方法を変えた
- プライバシーポリシーのURLや内容を変えた
どれかに当てはまれば、リリース前にデータセーフティを見直します。実装のPull Requestやリリースチェックリストに項目を入れておくと、申告の更新忘れを防げます。
まとめ
正確なデータセーフティ申告には、機能・権限・通信・SDKをつないだデータフローの確認が欠かせません。まず事実を棚卸しし、それをPlay Consoleとプライバシーポリシーへ一貫して反映します。準備全体はAndroidアプリ公開チェックリスト、開発の進め方はAIを使ったAndroid個人開発の進め方も参考にしてください。
あわせて読みたい
参考にした公式情報
- Google Play Console ヘルプ：データセーフティ セクションの情報を提供する
- Google Play Console ヘルプ：SDKを安全に使用する
- Google Play Console ヘルプ：目立つ開示と同意のベストプラクティス
※要件や画面構成は変更されることがあります。提出時はPlay Consoleと最新の公式ヘルプをご確認ください。