アプリとゲーム
ログインと決済機能があるアプリのプライバシーポリシー
ログインと決済を備えたアプリは、広告や公開プロフィールがなくても個人情報を処理することがあります。認証では本人に関する情報を扱い、決済では取引記録が作られ、Webhookがその記録をプロダクト内の利用権限に結び付けます。ポリシーは、この流れ全体に基づいて作成してください。「すべてサービス提供者が処理する」と述べるだけでは、自社が受け取る情報や管理するアカウントを説明できません。
初回登録とログインの流れを整理する
テスト用アカウントを作り、任意のプロフィール項目も含め、求められる入力項目をすべて記録します。その後、保存されたレコードと認証のレスポンスを調べてください。ソーシャルログインでは、自社の登録フォームには表示されない識別子、表示名、画像が返されることがあります。コードがどの項目を保存し、どの項目を破棄するかを確認します。
パスワードの再設定、メールアドレスの確認、セッションも追跡してください。主なログインフォームが最小限でも、配信サービスやセキュリティ記録が関わる場合があります。アプリのプライバシーポリシーガイドでは、この洗い出しをほかの機能に広げる方法を説明しています。実際に使われているパスワード、セッショントークン、復旧リンクを質問票に貼り付けてはいけません。
購入手続きからアプリに戻るまでを追う
購入手続きを作成するときに、アプリが決済サービスへ送る情報を確認します。商品や価格の情報とともに、顧客識別子やメールアドレスが送られる場合があります。その後、ブラウザーのリダイレクトと検証済みのWebhookで何が戻ってくるかを調べてください。利用権限のデータベースは、提供者側の記録とは別に、購入状態を保存していることがよくあります。
アプリが実際に永続保存する項目、保存する目的、閲覧できるスタッフを記録します。ホスティング型の決済フォームは、カード情報を扱う範囲を減らせても、請求情報の処理そのものをなくすわけではありません。請求書の参照情報や購入履歴を保存しているなら、「決済データを一切受け取らない」といった広い表現は避けてください。重要なのは、具体的な情報と責任の範囲を区別することです。
目立つ二つの連携以外にも目を向ける
ログインと購入手続きには、確認メール、領収書、サポート、不正対策、ホスティングのログ、エラー報告など、複数の付随サービスが関わることがよくあります。スターターテンプレートでは、画面をカスタマイズする前から一部が有効になっている場合もあります。デプロイ済みの設定とネットワークの動作から経路を見つけ、コード内の呼び出し元で確かめてください。
提供者、情報、目的、保存期間の設定をまとめた小さな表を使います。秘密情報の値は含めないでください。ログイン失敗を記録しているなら、保存情報はプロフィール画面の内容だけだと説明せず、そのセキュリティ上の利用も記載します。より広い機能を持つホスティング型ソフトウェアについては、SaaSの生成ガイドで、受領者が増える要因となるチームメンバー、バックグラウンドジョブ、共有ワークスペースを説明しています。
サービス上のメールと任意のマーケティングを区別する
確認メールと販促ニュースレターは同じ配信サービスを使う場合でも、目的とユーザーの期待が異なります。自動送信されるメッセージ、配信希望の記録方法、マーケティングを断ってもアカウントを使い続けられるかを確認してください。同じ提供者が送信するというだけで、すべてのメールを必須と説明してはいけません。
メールのテンプレートに追跡機能があるかを調べ、連絡先リストの同期先も確認します。ニュースレターを有効にしていないなら、メールプラットフォームにその機能があるだけでマーケティングを選択しないでください。問い合わせフォームのガイドにも、必要な返信と任意の連絡を区別する例があります。生成する説明は、実装されている区別に沿う必要があります。
返金、解約、削除を個別に予行する
取引の返金、継続課金の解約、アカウント削除という3つの独立したテストを行います。それぞれが利用権限、決済記録、ファイル、メール設定に及ぼす影響を確認してください。通常、これらの操作の結果は異なります。返金してもアカウントは有効なままかもしれませんし、プロフィールを削除しても、コードで明示的に処理しなければ決済サービス側のサブスクリプションは解約されない場合があります。
確立した動作として説明する前に、不整合を修正します。また、すべての請求で完全消去を約束せず、取引処理や紛争対応など、記録された理由に基づいて保持する情報も記載してください。別のウェブサイト利用規約ガイドでは、プライバシーの説明を情報の取り扱いに集中させながら、これらのプロダクト上の判断を契約に結び付ける方法を説明しています。
確認済みの事実から質問票に回答する
App Privacy Policy Generatorから始めます。運営者とプロダクトを特定し、確認したアカウント情報、決済に関する関係、サービス提供者、セキュリティ目的の利用、対象ユーザー、地域、削除手順を入力してください。公開するプロダクトで実際に行う処理だけを選びます。決済サービスの任意機能を、自社ポリシー上の架空の機能にしてはいけません。
回答できない質問があれば、先に関連設定を調べるか、判断する担当者に確認します。AIコーディングアシスタントは実装箇所を探す助けになりますが、保存スケジュールや顧客の居住地域を作り上げるべきではありません。検証メッセージとプレビュー全体を確認してください。フォームを正常に送信できたことと、事業上の事実を確認できたことは同じではありません。
必要な場面で読めるようにリンクを公開する
フッターのリンクは再訪時に便利ですが、登録や購入手続きの場面にも、プライバシー情報を読むための分かりやすい導線が必要です。個人情報を送信する前からリンクを利用できるようにしてください。ログイン後のアプリでは、後から再び読めるよう、設定やアカウント内の一定の場所に配置します。
ログインせずにリンク先を開き、文書が実際に表示されるか確認します。非公開プレビューや一時的な開発環境に紐付くURLは使わないでください。配置の詳細は、プライバシーポリシーのリンクを置く場所を参照してください。利用規約の配置は別途確認し、データ利用の説明とサービス契約への同意が画面上で混同されないようにします。
収益化の仕組みが変わったらポリシーを見直す
年間プラン、二つ目の決済経路、モバイルアプリ内課金、紹介プログラムの追加によって、情報の流れが変わることがあります。認証サービスの変更でも、識別子の移動や新たなアカウント連携が生じ得ます。こうした変更と承認済みの回答を比較する担当者を明確にしてください。
以前の版を保存し、プロダクトで変わった点を記録します。購入画面やログイン画面の再設計後は、ポリシーへのリンクを確認してください。共通コンポーネントの変更で、法的文書へのリンクが意図せず消えることがあります。ポリシー更新ガイドは、これらの確認を整理するのに役立ちます。安定した公開ページも、そこにある説明がアプリの動作と一致し続けてこそ役立ちます。
よくある質問
決済が別のウェブサイトで行われてもポリシーは必要ですか?
ホスティング型の購入手続きを使っても、自社のアカウントデータやアプリに返される購入情報はなくなりません。Webhookイベントや顧客識別子も含め、送信、受信、保存する情報を正確に洗い出してください。重要なのはカード情報が自社ドメインのページを通るかどうかではなく、自社が行う処理です。
ソーシャルログインなら個人データを収集していないことになりますか?
いいえ。アカウント識別子、メールアドレス、名前、プロフィール画像、そのほか要求した情報を受け取る場合があり、アプリは独自のセッションや記録も管理しています。スコープ、提供者のレスポンス、保存項目を確認してください。パスワードを収集しないというだけで、データを収集しないと説明してはいけません。
アカウントを削除したら有料サブスクリプションも解約すべきですか?
明確な手順を決めて実装し、画面と文書で一貫して説明してください。請求側の動作を明示的にテストします。データベースの行を削除しても、決済サービス側に影響するとは限りません。削除を請求したときに、利用権限、更新、記録がどうなるかをユーザーが理解できる必要があります。
同じ事実からプライバシーポリシーと利用規約を生成できますか?
確認済みの運営者情報やプロダクト情報は再利用できますが、それぞれの文書には追加の質問があります。プライバシーポリシーは情報の取り扱いを、利用規約は決済や利用権限の判断を含むサービス上の関係を説明します。一方の解約や削除の説明が他方と矛盾しないよう、両方の出力を併せて確認してください。
このガイドで確認した公式情報源
プラットフォームのルールや法令は変更されることがあります。公開前や重要な判断の前に、最新の条文を確認してください。