データ セーフティ用の App メタデータ バンドル

アプリのメタデータ バンドルを使用すると、デベロッパーは、デベロッパー自身、アプリ、ユーザーデータの収集、共有、保護の有無と方法に関する情報を透明性の高い方法で含めることができます。Google Play ストアでは、配信するアプリについてデベロッパーにこの情報を提供するよう義務付けています。また、Google Play 開発者サービスが搭載された Android デバイスのメーカーは、メーカーがプリロードするアプリのデベロッパーに対しても、システム サービスに限定的な例外を除き、同様の義務を課しています。

他のアプリストアやインストーラは、配信するアプリにアプリのメタデータ バンドルを必須にすることもできます。アプリの配信方法によって、デベロッパーがアプリのメタデータ バンドルを作成して統合する方法が決まります。Android では、アプリのメタデータ バンドルのデータ セーフティ情報がユーザーに表示されます。たとえば、アプリがサードパーティと位置情報を共有することを宣言している場合、その情報は Android 14 以降を搭載したデバイスの位置情報権限プロンプトに表示されます。

概要

アプリ メタデータ バンドルを使用すると、アプリが収集または共有するユーザーデータなど、デベロッパーとアプリに関する情報を共有し、アプリの主なプライバシーとセキュリティの方針を紹介できます。この情報は、権限へのアクセスを許可する際などに、ユーザーがより多くの情報に基づいて選択するのに役立ちます。

アプリのメタデータ バンドルは、デベロッパーが事業を展開する国でデベロッパーが負う可能性のある法的透明性と開示義務とは別個のものであり、それらに加えて提供されるものです。

すべてのデベロッパーは、アプリでユーザーデータをどのように収集、処理するかを申告し、アプリの目的、デベロッパー情報、アプリが暗号化などのセキュリティ保護対策によってユーザーデータをどのように保護するかについて詳細を示すことをおすすめします。これには、アプリで使用されるサードパーティのライブラリまたは SDK を通じて収集、処理されるデータも含まれます。詳細については、SDK プロバイダが公開しているデータ セーフティ情報をご覧ください。デベロッパーは Google Play SDK Index で、ガイダンスへのリンクがプロバイダから提供されているかどうかを確認できます。

App Metadata Bundle がデバイスにアクセスする方法は、アプリの配信方法によって異なります。

• システム イメージにプリロードされたアプリ: デバイス メーカーは、システム イメージのデータ セーフティ XML ファイルにアプリ メタデータ バンドルを組み込む責任を負います。
• インストーラによって配信されるアプリ: インストーラは、アプリのメタデータ バンドルをデバイスに送信します。Google Play で配信されるアプリを開発する場合は、Google Play Console ヘルプの手順をご覧ください。インストーラは、App メタデータ バンドルのスキーマを参照できます。

プリロード アプリのデベロッパーは、次のいずれかの方法でデータ セーフティ XML ファイルを作成できます。

• Google Play ストアで公開するアプリを開発する場合は、Google Play Console のデータ セーフティ フォーム（[アプリのコンテンツ] ページ、[ポリシー] > [アプリのコンテンツ]）を使用します。すでにこのフォームにご記入いただいている場合は、特にご対応いただく必要はありません。
• このページで入手できるテンプレート XML ファイルをダウンロードして編集し、メーカーまたはインストーラに提供します。

情報を準備する

アプリ メタデータ バンドルの作成を開始する前に、次の手順を完了します。

• プライバシー ポリシーが追加されていることを確認します。

• アプリがユーザーデータをどのように収集、共有しているかと、アプリのセキュリティの方針を確認します。特に、アプリで宣言されている権限と、アプリで使用されている API を確認してください。

  デベロッパーは、アプリがユーザーデータを収集、共有する仕組みを確認するだけでなく、アプリ内のサードパーティのコード（サードパーティのライブラリや SDK など）がどのようにユーザーデータを収集、共有しているかも確認する必要があります。アプリのメタデータ バンドルに、サードパーティのコードによって行われるデータの収集または共有を反映させる必要があります。

アプリとデベロッパー情報のセクションでデベロッパーが開示する必要があるもの

このセクションでは、アプリ メタデータ バンドルの [アプリ] セクションと [デベロッパー情報] セクションでデベロッパーが開示する必要がある情報について説明します。アプリが Google Play ストアで配信されている場合は、Google Play Console を使用してこの情報を入力します。

アプリについてデベロッパーが共有する必要がある情報

デベロッパーは、アプリのメタデータ バンドルを作成するとき、以下のセクションで説明するアプリ情報を開示する必要があります。

アプリの目的

アプリの目的を、英語で書かれた人が読めるテキストの blob で説明します（4,000 文字以内）。

アプリのカテゴリ

以下のリストから、アプリの目的に合ったカテゴリを選択します。

以下のカテゴリは、プリロード アプリを対象としています。

• OTA - 無線（OTA）アップデートの受信とインストールを担当するパッケージ
• AOSP - Android オープンソース プロジェクトで利用可能なパッケージ
• セキュリティ
• ストア

次の表に示すカテゴリは、Google Play でも使用されます。

アプリの広告とマーケティング

アプリに広告やマーケティング（アプリ内プロモーションを含む）が含まれているかどうかを指定します。

プライバシー ポリシー

デベロッパーによるユーザーデータの取り扱いを説明するプライバシー ポリシーへのリンクを含めます。このリンクがアプリに含まれていない場合、アプリはユーザーデータを処理しないと見なされます。

デベロッパーが自身について共有する必要がある情報

デベロッパーは、アプリのメタデータ バンドルを作成するとき、以下のセクションで説明するデベロッパー情報を開示する必要があります。

デベロッパー名

アプリを作成したデベロッパー、個人、会社の名前。デベロッパー名は複数設定できます。

アプリ レジストリ

ストアやその他のインストーラなど、アプリ レジストリにアプリが登録されている場合は、このフィールドに入力します。複数のストアの複数のエントリが許されます。

• Android インストーラであるアプリ レジストリの場合: この値には、ストアの Android パッケージ名を設定します。たとえば、Google Play ストアの場合は com.android.vending を使用します。
• その他のアプリ レジストリの場合: 値はレジストリの URL です。

次のいずれかの理由で、このフィールドを省略します。

• デベロッパーが Google Play SDK Index に掲載されている SDK である。
• デベロッパーがアプリストアまたはレジストリに登録していない。

アプリ レジストリ ID

インストーラやストアなど、アプリレジストリに登録されているアプリの場合、この値はデベロッパーのストア、インストーラ、またはレジストリの ID にする必要があります。複数のストアの複数のエントリが許されます。

• Google Play に登録されているデベロッパーの場合: この値はデベロッパー ページの URL にする必要があります（例: https://play.google.com/store/apps/dev?id=5700313618786177705 はデベロッパー Google LLC の URL）。
• デベロッパーが Google Play SDK Index に登録されている SDK デベロッパーの場合: SDK の URL を使用します（たとえば、https://play.google.com/sdks/details/com-google-android-gms-play-services-ads は Google Mobile Ads（GMA）SDK の URL です）。
• デベロッパーが別のストアまたはレジストリに登録されている場合: アプリストアの URL または他の識別子を設定できます。

デベロッパーがどのアプリストアにも登録されていない場合は省略できます。

デベロッパーの連絡先情報

次の情報を提供します。

• メール
• ウェブサイト
• 国または地域
• 住所

デベロッパーがデータ セーフティ セクションで開示する必要がある情報

このセクションでは、アプリ メタデータ バンドルのデータ セーフティ セクションで開示する必要がある情報について説明し、選択できるユーザーデータの種類と用途を示します。アプリを Google Play ストアで配信する場合は、Google Play Console を使用してこの情報を入力します。

データの種類によらず申告する必要があるもの

アプリのメタデータ バンドルを作成する際、デベロッパーは、収集および共有するデータの種類に関する情報を開示する必要があります。詳細は、次のセクションをご覧ください。

データの収集

この場合の「収集」とは、アプリからユーザーのデバイス外にデータを送信することを意味します。次のガイドラインにご注意ください。

• ライブラリと SDK: アプリで使用するライブラリまたは SDK によってアプリからデバイス外に送信されるユーザーデータも対象となります。データの送信先がアプリのデベロッパーかサードパーティのサーバーかは関係ありません。

• WebView: アプリから開いた WebView から収集されるユーザーデータが含まれます（アプリがその WebView を通じて配信されるコードと動作を制御している場合）。

  ユーザーが WebView でオープンウェブ上を移動する場合、デベロッパーがその WebView からのデータ収集を申告する必要はありません。

• 一時的な処理: デバイスから送信されて一時的に処理されるユーザーデータは、次の基準を満たしている場合、アプリのメタデータ バンドルに含める必要はありません。

  「一時的に処理される」とは、データがメモリにのみ保存され、特定のリクエストにリアルタイムで対応するために必要な間だけ保持され、他の目的には使用されないことを意味します。

  たとえば、ユーザーの位置情報をデバイスから送信して現在地の天気情報を取得するアプリで、位置情報をメモリ内でのみ使用し、リクエストの実行後にそのデータを保存しない場合、このような位置情報の使用は「一時的な使用」と見なされます。ただし、データを広告プロファイルやその他のユーザー プロフィールの作成に使用する場合は「一時的な使用」とは見なされず、該当する目的のための収集または共有として申告する必要があります。

• 仮名データ: 仮名で収集されたユーザーデータは開示する必要があります。たとえば、ユーザーに合理的に再び関連付けることができるデータは開示する必要があります。

データ収集の開示の対象外

次のユースケースは、収集として開示する必要はありません。

• デバイス上でのアクセスまたは処理: アプリがアクセスするが、ユーザーのデバイス上でローカルで処理されるだけで、デバイス外には送信されないユーザーデータは、開示する必要はありません。

• エンドツーエンドの暗号化: デバイス外に送信されるが、エンドツーエンドの暗号化を行って、送信者と受信者以外の誰かやデベロッパーには判読不能となるユーザーデータは、開示する必要はありません。

  暗号化されたデータは、デベロッパーなどの中間者にとって判読可能な状態であってはなりません。また、送信者と受信者のみが必要な鍵を持つことができます。

データの共有

この場合の「共有」とは、アプリから収集したユーザーデータをサードパーティに転送することを意味します。これには、以下のように転送されるユーザーデータが含まれます。

• デバイス外（サーバー間転送など）: たとえば、デベロッパーがアプリから収集したユーザーデータを、デベロッパーのサーバーからサードパーティのサーバーに転送する場合。

• デバイス上での別のアプリへの転送: デバイス上でそのアプリから別のアプリに直接ユーザーデータを転送する場合です。この場合、アプリがユーザーのデバイス外にデータを送信しない場合でも、デベロッパーはデータ セーフティ セクションでデータ共有を開示する必要があります。

• アプリのライブラリと SDK から: アプリから収集したデータを、アプリに含まれるライブラリや SDK を使用して、ユーザーのデバイス外のサードパーティに直接転送する場合です。

• アプリで開いた WebView からの転送: アプリで開いた WebView を介してサードパーティにユーザーデータを転送する場合です。ただし、アプリがその WebView を通じて配信されるコードや動作を制御している場合です。

  ユーザーが WebView でオープンウェブ上を移動する場合、デベロッパーがその WebView からのデータ共有を申告する必要はありません。

以下のようなデータ転送は「共有」として開示する必要はありません。

• サービス プロバイダ: デベロッパーの代わりにデータを処理するサービス プロバイダにユーザーデータを転送する場合。「サービス プロバイダ」とは、デベロッパーの代わりに、デベロッパーの指示に基づいて、ユーザーデータを処理するエンティティを指します。

• 法的な目的: 法的義務や政府のリクエストへの対応など、特定の法的な目的のためにユーザーデータを転送する場合。

• ユーザーが開始したアクション、または認識しやすい開示とユーザーの同意: ユーザーが開始した特定のアクションに基づいて、ユーザーデータをサードパーティに転送する場合です。その際、ユーザーはデータが共有されることを合理的に予期しています。または、認識しやすいアプリ内の開示と同意に基づいて転送する場合です。

• 匿名データ。個々のユーザーへの関連付けができなくなるように、完全に匿名化されたユーザーデータを転送する場合です。

• ファースト パーティとサードパーティ: ファースト パーティとは、アプリで収集されるデータの処理について責任を負う、主となる組織のデベロッパーのことです。ストアを通じて配布されるアプリの場合、通常はストアでアプリを公開している組織がファースト パーティとなります。

  ファースト パーティには、アプリで収集されるデータの処理に主として責任を負っている組織をユーザーに明確に示す義務があります。

  「サードパーティ」とは、ファースト パーティとそのサービス プロバイダ以外の組織のことです。

データの取り扱い

アプリによって収集される各データの種類が「オプション」か「必須」かについても開示できます。「オプション」には、データ収集の有効 / 無効を選択できるという意味が含まれています。たとえば、ユーザーがデータの収集を管理でき、データを提供しなくてもアプリを使用できる場合や、ユーザーがそのデータタイプを手動で提供するかどうかを選択できる場合は、そのデータの種類をオプションとして宣言できます。アプリの主要な機能でそのデータの種類が必要な場合は、そのデータを必須として申告する必要があります。

デベロッパーは、デバイスや地域にかかわらず、すべてのユーザーが、任意で情報を提供したり、データ収集の有効 / 無効を選択したりできる場合に限り、アプリが特定のデータを任意で（オプションとして）収集すると申告できます。

オプションのデータ収集の例:

• マーケティング コミュニケーションのためにユーザーの生年月日の入力を求めるソーシャル メディア アプリ。ただし、その情報は必須ではなく、ユーザーはその情報を提供しなくても登録できます。

• ユーザーがログインしなくてもアプリを利用できる環境で、ユーザーがアプリにログインしているときにのみ収集されるユーザーデータ。

その他のアプリによる開示とデータの開示

データ セーフティ セクションは、デベロッパーがアプリのプライバシーとセキュリティの方針を紹介するチャンスでもあります。たとえば、デベロッパーは次の情報をハイライト表示できます。

• 転送データの暗号化: アプリによって収集または共有されるデータが、エンドユーザーのデバイスからサーバーへのユーザーデータのフローを保護するために、転送中に暗号化を使用するかどうか。

  アプリの中には、ユーザーがデータを別のサイトやアプリに転送できるよう設計されているものもあります。たとえば、メッセージ アプリでは、さまざまな暗号化方式を維持するモバイル サービス プロバイダを介して SMS メッセージを送信するオプションをユーザーに提供できます。このようなアプリは、ユーザーのデバイスとアプリのサーバー間の転送時に最適な業界標準に基づいてデータを安全に暗号化している限りは、安全な接続を介してデータを転送していることをデータ セーフティ セクションで申告できます。

• 削除リクエスト メカニズム: ユーザーがデータの削除をリクエストする方法をアプリが提供しているかどうか。

独立したセキュリティ審査（すべてのアプリで利用可能）

デベロッパーは、アプリがグローバルなセキュリティ基準に基づく独立した審査を受けたことをデータ セーフティ セクションで申告できます。これは、デベロッパーが自ら受けて費用を支払うオプションの審査です。たとえば、Mobile Application Security Assessment（MASA）を使用して、デベロッパーはラボと直接連携し、Open Worldwide Application Security Project（OWASP）の Mobile Application Security Verification Standard（MASVS）に基づいてアプリを評価できます。第三者組織がデベロッパーに代わって審査を実施します。

データタイプと用途

デベロッパーは、次の表に示すように、一連のユーザーデータの種類について、収集、共有、その他の取り扱い方法と、デベロッパーがそのデータを使用する目的を提供するよう求められます。

目的

データ セーフティ XML ファイルを手動で作成する

次のデータ セーフティ XML ファイルの例は、ユーザーの位置情報に関連するデータを共有するプリロード アプリのファイル構造を示しています。アプリで開示する必要がある情報の種類に応じて、要素を追加、編集、削除して、この構造を編集します。

サンプル ファイルは必ずしも完全なものではありません。アプリに含める必要があるアプリ メタデータ バンドルのアプリ、デベロッパー、データ セーフティのセクションに必要な XML 構造については、アプリ メタデータ バンドルのスキーマをご覧ください。

<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<bundle>
<long name="version" value="2" />

  <pbundle_as_map name="safety_labels">
    <long name="version" value="1" />

      <pbundle_as_map name="data_labels">
        <pbundle_as_map name="data_shared">
          <pbundle_as_map name="location">
            <pbundle_as_map name="approx_location">
              <int-array name="purposes" num="4">
                  <item value="1" />
                  <item value="2" />
                  <item value="5" />
                  <item value="6" />
              </int-array>
            </pbundle_as_map>
            <pbundle_as_map name="precise_location">
              <int-array name="purposes" num="2">
                  <item value="1" />
                  <item value="6" />
              </int-array>
            </pbundle_as_map>
          </pbundle_as_map>
        </pbundle_as_map>

    </pbundle_as_map>
</pbundle_as_map>
</bundle>

よくある質問

デベロッパーからよく寄せられる質問とその回答については、次のセクションをご覧ください。

一般的な質問

次のセクションでは、アプリ メタデータ バンドルに関する一般的な質問とその回答について説明します。

デベロッパーから iOS に関する同様の情報が送信されました。デベロッパーは、その作業のどの程度を Android アプリのメタデータ バンドルで再利用できますか？

デベロッパーがアプリのデータの取り扱いを適切に扱っていることは素晴らしいことです。アプリのメタデータ バンドルを正しく完成させるには、これまで使用したことのない追加情報が必要な場合があります。そのため、追加の作業が必要になることを想定する必要があります。Android アプリ メタデータ バンドルの分類とフレームワークは、他のアプリストアで使用されるものとは大きく異なる場合があります。

Google はデベロッパーが正確な情報を共有していることをどのように確認するのですか？こうした情報が必ずしも正確とは限らない、という例を業界で見てきました。

プライバシー ポリシーと同様に、デベロッパーはアプリのメタデータ バンドルで開示される情報について責任を負います。

デベロッパーはアプリのメタデータ バンドルをどのくらいの頻度で更新する必要がありますか？

アプリのデータ取り扱い方法を変更した際に、デベロッパーはアプリのメタデータ バンドルを更新する必要があります。

データ セーフティ セクションの記入に関する質問

以降のセクションでは、アプリ メタデータ バンドルのデータ セーフティ セクションの記入に関する質問に回答します。

サポートされている Android バージョンによってアプリの動作が異なる場合はどうすればよいでしょうか？

アプリのアプリのメタデータ バンドルは、使用状況、アプリのバージョン、リージョン、ユーザーの年齢に依存しないように、正確でなければなりません。データ セーフティ セクションには、すべての地域とユーザータイプにわたるアプリのデータ収集とデータ共有の概要が記載されます。

地域によって取り扱いが異なる場合があることをデベロッパーが示すにはどうすればよいですか？たとえば、ヨーロッパでは特定のライブラリを使用していませんが、使用していない地域もあります。

アプリ メタデータ バンドルには、アプリごとのデータ取り扱いのグローバルな表現が反映されています。データ セーフティ セクションには、すべての地域とユーザータイプにわたるアプリのデータ収集とデータ共有が総合的に記載されます。

データ セーフティ セクションは、ユーザーによる同意に基づくメカニズムで管理されていますか？デベロッパーは、追加の手順を行って、アプリ内で認識しやすい開示を掲載する必要がありますか？

いいえ、ユーザーがアプリをインストールする際に開示確認を行うことも、この機能に関して改めてユーザーによる同意を求めたりすることもありません。ユーザーの個人情報や機密情報を収集する Google Play アプリと、Google Play サービスが搭載された Android デバイス向けのモバイル バンドルアプリのデベロッパーは、ポリシーで求められている場合、アプリ内での開示と同意を実装する必要があります。

アプリに権限が含まれているものの、実際にデータを収集または共有していない場合、デベロッパーはデータを申告する必要がありますか？

データを実際に収集または共有していない限り、収集または共有を申告する必要はありません。Google Play 開発者サービスが搭載された Android デバイス上の Google Play アプリとモバイル バンドル アプリは、該当するすべてのポリシーに準拠する必要があります。

あるデータの種類が別のデータの一部として収集される場合、デベロッパーは両方とも申告する必要がありますか？たとえば、デベロッパーがユーザーのメールアドレスを含む連絡先を収集した場合、「連絡先」と「メールアドレス」の両方のデータの種類を申告するのですか？

デベロッパーが別のデータの種類を収集する際に特定のデータの種類を意図的に収集している場合は、両方とも開示する必要があります。たとえば、デベロッパーがユーザーの写真を収集し、それを使用してユーザーの特性（民族や人種など）を判断する場合は、民族や人種の収集も開示する必要があります。

デベロッパーは削除メカニズムを提供する必要がありますか？また、そのメカニズムはすべてのユーザーデータを対象にする必要がありますか？

データ セーフティ セクションには、ユーザーからデータ削除リクエストを受け取るメカニズムを提供しているかどうかをデベロッパーが知らせるサーフェスがあります。デベロッパーは、データ セーフティ セクションへの情報入力の一環として、そのようなメカニズムを提供しているかどうかを示す必要があります。

アプリがユーザーデータの削除リクエストに対応していることを示すためにデベロッパーが提供する必要がある特定の種類のメカニズムはありますか？

規定のメカニズムはありませんが、リクエスト メカニズムはユーザーが見つけやすく、アクセスできるようにすることをおすすめします。ユーザーがデータ削除をリクエストできる手段を明確に示すメカニズムの一般的な例としては、アプリ内機能、お問い合わせフォーム、専用のメール エイリアスなどがありますが、これらに限定されません。

自動的に削除または匿名化されるデータについて削除メカニズムを提供していることをデータ セーフティ セクションに示すにはどうすればよいですか？

デベロッパーは、次のオプションを 1 つ以上指定した場合、ユーザーがデータの削除をリクエストできることを宣言できます。

• データの削除をリクエストするメカニズム。

• 収集から 90 日以内に収集したデータの削除または匿名化を開始する自動プロセス。

  デベロッパーは、法令遵守や不正使用防止などの正当な理由で特定のデータを保持する必要がある場合でも、ユーザーがデータの削除をリクエストできることを宣言できます。

デベロッパーが提供する削除メカニズムを世界中のすべてのユーザーが利用できるわけではない場合はどうなりますか？その場合でも、削除リクエスト メカニズムを提供していることを示すことができますか？

アプリのメタデータ バンドルごとに利用できるグローバル データ セーフティ セクションは 1 つだけです。あらゆる使用方法、地域、ユーザーの年齢に基づくデータの取り扱いを記載する必要があります。つまり、世界のどこかで、アプリのいずれかのバージョンでなんらかのデータの取り扱いが存在する場合は、デベロッパーはそうした取り扱いを申告する必要があります。そのため、データ セーフティ セクションには、すべてのユーザーと地域にわたるアプリのデータ収集とデータ共有の概要が記載されます。

データを匿名にするには、どのような手法を使用できますか？

個々のユーザーに関連付けられないようにデータを匿名化するには、さまざまな方法が考えられます。デベロッパーは、ユースケースに適用できる方法を特定するために、プライバシーとセキュリティの専門家に相談する必要があります。例として、このページでは、差分プライバシーなど、Google が使用しているデータ匿名化手法を紹介しています。

デベロッパーは IP アドレスの収集と使用をどのように扱うべきですか？

デベロッパーは、他のデータの種類と同様に、特定の使用状況や運用方法に基づいて、IP アドレスの収集、使用、共有を開示する必要があります。たとえば、デベロッパーが場所を判断する手段として IP アドレスを使用する場合は、そのデータの種類（場所）を宣言する必要があります。

デベロッパーは、他の種類の識別子の収集と共有について、どのように開示すればよいですか？

他のデータの種類と同様に、デベロッパーは、デベロッパーの特定の使用状況や運用方法に基づいて、さまざまな種類の識別子の収集、使用、共有を開示する必要があります。たとえば、特定可能な個人に関連付けられたアカウント名の収集は「個人識別子」として宣言し、ユーザーの Android 広告 ID の収集は「デバイスまたはその他の識別子」として宣言する必要があります。別の例として、特定のアプリ内イベントに関連する識別子で、個々のデバイス、ブラウザ、アプリに合理的に関連していない場合は、「デバイスまたはその他の識別子」として開示する必要はありません。

前述のとおり、仮名でのデータ収集は、アプリのメタデータ バンドルのデータ セーフティ セクションで、関連するデータの種類の下で開示する必要があります。たとえば、デバイス ID を含めて診断情報を収集する場合は、データ セーフティ セクションで「診断」の収集を開示する必要があります。

「サービス プロバイダ」はどのような種類のアクティビティを実行できますか？

サービス プロバイダは、デベロッパーに代わってユーザーデータの処理のみを行えます。たとえば、デベロッパーの代わりにアプリのユーザーデータを処理する分析プロバイダや、デベロッパーが使用するためにアプリのユーザーデータをホストするクラウド プロバイダなどは、通常「サービス プロバイダ」に該当します。一方、SDK プロバイダがアプリデータに基づいて複数の顧客の広告プロファイルを構築している場合、データ セーフティ セクションでは「サービス プロバイダ」のアクティビティとは見なされず、アプリのメタデータ バンドルのデータ セーフティ セクションで「共有」として開示する必要があります。

アプリにおいて、外部の決済サービスを利用した金融取引を可能にしています。アプリのメタデータ バンドル内で、クレジット カード情報などの財務情報を開示する必要がありますか？

決済サービスとの統合の性質によって異なります。アプリが PayPal、Google Pay、Google Play の課金システムなどの決済サービスを使用して支払い取引を完了する場合、デベロッパーは、次のすべての条件が満たされている場合、決済サービスが金融取引の処理に関連して収集するデータ（クレジット カード番号など）の収集を申告する必要はありません。

• アプリがこれらの情報にアクセスすることはありません。

• 決済サービスが独自の利用規約に則って、ユーザーから直接これらの情報を収集すること

デベロッパーは、決済サービスとの統合について慎重に確認し、アプリ メタデータ バンドルのデータ セーフティ セクションで、これらの条件を満たしていない関連するデータの収集や共有が適切に申告されていることを確認する必要があります。また、アプリがその他の財務情報（購入履歴など）を収集しているかどうかや、リスクや不正防止などの目的で決済サービスから関連データを受け取るかどうかも考慮する必要があります。

バックアップや保存のために、ユーザーがデータを Google ドライブや Dropbox に直接アップロードできるアプリ。こうしたデータにアプリがアクセスすることはありません。この場合でも「収集」として開示する必要はありますか？

実際の実装によって異なります。ユーザーが自分の外部ドライブまたはクラウド ストレージ アカウント（Google ドライブ、Dropbox などのサービス）にデータを直接アップロードすることを選択し、このアップロードに外部ドライブまたはクラウド ストレージ プロバイダの利用規約とプライバシー ポリシーが適用され、アプリが問題のデータを収集したりアクセスしたりしない場合、アプリはこのデータの収集を宣言する必要はありません。

転送中のデータはどのように暗号化すればよいですか？

転送中のアプリデータを安全に暗号化するには、最適な業界基準に準拠する必要があります。一般的な暗号化プロトコルには、TLS（Transport Layer Security）や HTTPS（Hypertext Transfer Protocol Secure）などがあります。

アプリにおいて、ユーザーがアカウントを作成し、生年月日や性別などの情報を追加できるようにしています。ユーザーがアカウントに追加するデータはどのように申告すればよいですか？

デベロッパーは、アカウント管理のためにこのデータを収集することを申告し、ユーザーが収集しなくてもよい場合はその旨を明記する必要があります。

さらに、これはアプリで収集するあらゆる種類のデータに当てはまることですが、そのデータをアプリでどのような目的に使用するかについても開示する必要があります。たとえば、ユーザーがアカウントに誕生日を追加できるようになっており、そのデータを使用して誕生日前にプッシュ通知を送信する場合は、アカウント管理に加えてこの目的も申告する必要があります。

アカウント管理は、特定のアプリに固有ではないアカウント データの一般的な使用をカバーするために使用できます。たとえば、デベロッパーがサービス全体で不正行為の防止、広告、マーケティング、デベロッパーとのコミュニケーションにアカウント情報を使用しており、この使用がアプリやアプリ内のアクティビティに固有のものでない場合は、このアカウント データの収集目的として「アカウント管理」を宣言することで、アプリ メタデータ バンドルのデータ セーフティ セクションでこれらの一般的な使用をカバーできます。ただし、アプリ自体がデータを使用する目的は、どのような場合でもすべて申告する必要があります。アカウントレベルの文書化とアカウント登録プロセスの一環として、アプリにおいてアカウント サービスのユーザーデータをどのように取り扱うかについて開示することをおすすめします。

システム サービスとは何ですか？

システム サービスは、コアシステム機能をサポートするプリインストール ソフトウェアです。システム サービスには、transparency_info バンドルと system_app_safety_label バンドルを含める必要があります（後者は safety_labels バンドルの代わりに提供されます）。Google Play を通じて配信されるシステム サービスについては、Google Play データ セーフティ フォームへの記入の免除を申請できます。

一時的な処理で使用するデータを収集する場合はどのように申告すればよいですか？（「一時的な処理」とは、ページから読み込んだデータを、デベロッパーのサーバーに記録したり他の目的に使用したりする前に、他のクライアントサイドのリクエストにリアルタイムで対応することを指します）

この使用が一時的である場合、デベロッパーはアプリ メタデータ バンドルのデータ セーフティ セクションに含める必要はありません。ただし、一時的な処理の範囲を超えてユーザーデータを使用する場合は、記録したユーザーデータをどのような目的に使用するかも含めて申告する必要があります。