一意の識別子に関するおすすめの方法

このドキュメントでは、ユースケースに基づいてアプリに適した識別子を選択するためのガイダンスを提供します。

Android の権限の概要については、権限の概要をご覧ください。Android の権限を操作する際の具体的なベスト プラクティスについては、アプリの権限に関するベスト プラクティスをご覧ください。

Android ID の使用に関するベスト プラクティス

ユーザーのプライバシーを保護するには、アプリのユースケースに対応した最も制限の厳しい識別子を使用します。特に、次のベスト プラクティスに従ってください。

  1. 可能な限り、ユーザーがリセット可能な識別子を選択します。アプリは、再設定不可能なハードウェア ID 以外の識別子を使用する場合でも、ほとんどのユースケースを実現できます。

  2. ハードウェア ID を使用しない。ほとんどのユースケースでは、必要な機能を制限することなく、国際移動体装置識別番号（IMEI）などのハードウェア識別子の使用を回避できます。

    Android 10（API レベル 29）では、リセットできない ID（IMEI とシリアル番号の両方を含む）に制限が追加されています。これらの識別子にアクセスするには、アプリがデバイスまたはプロファイル オーナー アプリであるか、特別な携帯通信会社の権限を持っているか、READ_PRIVILEGED_PHONE_STATE 特権を持っている必要があります。

  3. ユーザー プロファイル作成や広告のユースケースでは広告 ID だけを使用する。広告 ID を使用する場合は、常に広告トラッキングに関するユーザーの選択を尊重してください。広告 ID を個人を特定できる情報に関連付ける必要がある場合は、ユーザーの明示的な同意がある場合にのみ関連付けることができます。

  4. 広告 ID のリセットをブリッジしないでください。

  5. 支払いに関する不正行為の防止と電話機能を除く、他のすべてのユースケースでは、可能な限り Firebase インストール ID（FID）または非公開環境に保存されている GUID を使用します。ほとんどの非広告のユースケースでは、FID または GUID で十分です。

  6. ユースケースに適した API を使用して、プライバシーのリスクを最小限に抑えます。価値の高いコンテンツの保護には DRM API を、不正行為の防止には Play Integrity API を使用します。Play Integrity API は、プライバシー リスクを伴わずにデバイスが正規のものであるかどうかを判断する最も簡単な方法です。

このガイドの以降のセクションでは、Android アプリの開発という観点から、これらのルールについて詳しく説明します。

広告 ID を使用する

広告 ID はユーザーがリセットできる識別子であり、広告のユースケースに適しています。ただし、この ID を使用する際には、次の点に注意する必要があります。

広告 ID のリセットに関するユーザーの意図を常に尊重します。 ユーザーの同意なしに、別の識別子やフィンガープリントを使用して、後続の広告 ID をリンクすることで、ユーザーのリセットをブリッジしないでください。Google Play デベロッパー コンテンツ ポリシーには、次のように記載されています。

「...ユーザーの明示的な同意なしに、リセットの際に新しい広告 ID を以前の広告 ID や以前の広告 ID からのデータにリンクしてはなりません。」

関連付けられているパーソナライズド広告フラグを必ず尊重する。広告 ID は、ユーザーが ID に関連付けられたトラッキングの量を制限できるように構成可能です。ユーザーの意向を無視しないように、常に AdvertisingIdClient.Info.isLimitAdTrackingEnabled() メソッドを使用してください。Google Play デベロッパー コンテンツ ポリシーには、次のように記載されています。

「...ユーザーが指定した [インタレスト ベース広告をオプトアウト] または [広告のカスタマイズをオプトアウトする] の設定を遵守する必要があります。ユーザーがこの設定を有効にした場合は、広告目的でユーザーのプロフィールを作成したり、ユーザーをパーソナライズド広告のターゲットに設定したりするために広告 ID を使用してはなりません。ただし、コンテンツ ターゲット広告、フリークエンシー キャップ、コンバージョン トラッキング、レポート、セキュリティや不正行為の検出などに使用することはできます。

使用する SDK に関連するプライバシー ポリシーやセキュリティ ポリシーのうち、広告 ID の使用に関連するものに注意してください。 たとえば、Google アナリティクス SDK の enableAdvertisingIdCollection() メソッドに true を渡す場合は、該当するすべてのアナリティクス SDK ポリシーを確認し、遵守してください。

また、Google Play デベロッパー コンテンツ ポリシーでは、広告 ID を「個人を特定できる情報または永続的なデバイス識別子（SSAID、MAC アドレス、IMEI など）に関連付けることはできません」と規定されています。

たとえば、次の列を含むデータベース テーブルにデータを入力するために情報を収集するとします。

TABLE-01
timestamp ad_id account_id clickid
TABLE-02
account_id name dob country

この例では、ad_id 列は両方のテーブルの account_id 列を介して PII に結合される可能性があります。これは、ユーザーから明示的な許可を得ていない場合、Google Play デベロッパー コンテンツ ポリシーに違反することになります。

広告主 ID と PII のリンクは、必ずしもこのように明示的であるとは限りません。PII と広告 ID のキー付きテーブルの両方に「準識別子」が表示される可能性があり、これも問題の原因となります。たとえば、TABLE-01 と TABLE-02 を次のように変更するとします。

TABLE-01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

この場合、クリック イベントが十分にまれであれば、イベントのタイムスタンプとデバイスモデルを使用して、広告主 ID TABLE-01 と TABLE-02 に含まれる PII を結合できます。

データセットにこのような準識別子が存在しないことを保証することは困難ですが、可能な限り一意のデータを一般化することで、最も明白な結合リスクを防ぐことができます。上記の例では、タイムスタンプの精度を下げて、同じモデルの複数のデバイスがすべてのタイムスタンプに表示されるようにします。

他にも次のような解決策が考えられます。

  • PII と広告 ID を明示的にリンクするようなテーブル設計は行わない。上記の最初の例では、TABLE-01 に account_id 列を含めないことを意味します。

  • 広告 ID をキーとするデータと PII の両方にアクセスできるユーザーまたはロールのアクセス制御リストを分離してモニタリングする。 両方のソースに同時にアクセスする機能（テーブル間の結合など）を厳密に制御して監査することで、広告 ID と PII の関連付けのリスクを軽減できます。一般的に、アクセスを制御するとは、次のことを行うことを意味します。

    1. 広告主 ID キーデータと PII のアクセス制御リスト（ACL）を分離して、両方の ACL に含まれる個人またはロールの数を最小限に抑えます。
    2. アクセス ロギングと監査を実装して、このルールの例外を検出して管理します。

広告 ID を責任を持って扱う方法については、AdvertisingIdClient API リファレンスをご覧ください。

FID と GUID を操作する

デバイスで実行されているアプリ インスタンスを識別する最も簡単な方法は、Firebase インストール ID（FID）を使用することです。これは、広告以外のほとんどのユースケースで推奨されるソリューションです。この識別子にアクセスできるのは、識別子がプロビジョニングされたアプリ インスタンスのみです。また、アプリがインストールされている間のみ保持されるため、（比較的）簡単にリセットできます。

その結果、FID は、リセットできないデバイス スコープのハードウェア ID と比較して、プライバシー特性が向上しています。詳しくは、firebase.installations API リファレンスをご覧ください。

FID が実用的でない場合は、カスタムのグローバルに一意の ID（GUID）を使用して、アプリ インスタンスを一意に識別することもできます。最も簡単な方法は、次のコードを使用して独自の GUID を生成することです。

Kotlin

var uniqueID = UUID.randomUUID().toString()

Java

String uniqueID = UUID.randomUUID().toString();

この識別子はグローバルに一意であるため、特定のアプリ インスタンスを識別するために使用できます。アプリ間で識別子をリンクすることに関連する懸念を回避するには、GUID を外部（共有）ストレージではなく内部ストレージに保存します。詳細については、データとファイル ストレージの概要ページをご覧ください。

MAC アドレスは使用しない

MAC アドレスはグローバルに一意であり、ユーザーがリセットすることはできず、出荷時の設定にリセットしても保持されます。このような理由から、ユーザーのプライバシーを保護するため、Android バージョン 6 以降では、MAC アドレスへのアクセスはシステムアプリに制限されています。サードパーティ製アプリはアクセスできません。

Android 11 での MAC アドレスの可用性の変更

Android 11 以降をターゲットとするアプリでは、Passpoint ネットワークの MAC ランダム化は Passpoint プロファイルごとに行われ、次のフィールドに基づいて一意の MAC アドレスが生成されます。

  • 完全修飾ドメイン名（FQDN）
  • レルム
  • 認証情報（Passpoint プロファイルで使用されている認証情報に基づく）:
    • ユーザー認証情報: ユーザー名
    • 証明書認証情報: 証明書と証明書タイプ
    • SIM 認証情報: EAP タイプと IMSI

また、非特権アプリはデバイスの MAC アドレスにアクセスできません。IP アドレスを持つネットワーク インターフェースのみが表示されます。これは、getifaddrs() メソッドと NetworkInterface.getHardwareAddress() メソッド、および RTM_GETLINK Netlink メッセージの送信に影響します。

この変更がアプリに与える影響は次のとおりです。

  • NetworkInterface.getHardwareAddress() はどのインターフェースにも null を返します。
  • アプリは NETLINK_ROUTE ソケット上で bind() 関数を使用できません。
  • ip コマンドはインターフェースに関する情報を返しません。
  • アプリは RTM_GETLINK メッセージを送信できません。

ほとんどのデベロッパーは、NetworkInterface、getifaddrs()、Netlink ソケットなどの下位レベルの API ではなく、ConnectivityManager の上位レベルの API を使用する必要があります。たとえば、現在のルートに関する最新情報を必要とするアプリは、ConnectivityManager.registerNetworkCallback() を使用してネットワークの変更をリッスンし、ネットワークに関連付けられた LinkProperties.getRoutes() を呼び出すことで、この情報を取得できます。

識別子の特性

Android OS には、動作特性の異なるさまざまな ID が用意されています。どちらの ID を使用するかは、次の特性がユースケースにどのように影響するかによって異なります。ただし、これらの特性はプライバシーにも影響するため、これらの特性が互いにどのように影響し合うかを理解することが重要です。

スコープ

識別子のスコープとは、どのシステムがその識別子にアクセスできるかということです。Android 識別子のスコープは、一般的に次の 3 種類に分類されます。

  • 単一アプリ: 識別子はアプリの内部に存在し、他のアプリからはアクセスできません。
  • アプリグループ: 所定の関連アプリグループからアクセスできます。
  • デバイス: デバイスにインストールされたすべてのアプリからアクセスできます。

識別子に付与されるスコープが広いほど、トラッキング目的で使用されるリスクが高くなります。逆に、1 つのアプリ インスタンスからしかアクセスできない識別子は、異なるアプリのトランザクション間でデバイスを追跡するために使用することはできません。

リセット可能性と永続性

リセット可能性と永続性は、識別子の有効期間を定義し、リセット方法を説明するものです。一般的なリセット トリガーには、アプリ内リセット、システム設定によるリセット、起動時のリセット、インストール時のリセットなどがあります。Android 識別子の有効期間はさまざまですが、通常は ID のリセット方法に関連しています。

  • セッションのみ: ユーザーがアプリを再起動するたびに新しい ID が使用されます。
  • インストール リセット: ユーザーがアプリをアンインストールして再インストールするたびに、新しい ID が使用されます。
  • FDR リセット: ユーザーがデバイスを初期化するたびに新しい ID が使用されます。
  • FDR 後存続: デバイスを初期化しても ID は失われません。

リセット可能にすることで、ユーザーは既存のプロフィール情報に関連付けられていない新しい ID を作成できます。識別子の持続期間が長く、信頼性が高いほど（出荷時の設定にリセットしても持続する識別子など）、ユーザーが長期的なトラッキングの対象となるリスクが高くなります。アプリの再インストール時に識別子がリセットされると、永続性が低下し、アプリ内またはシステム設定からリセットするための明示的なユーザー コントロールがなくても、ID をリセットする手段が提供されます。

一意性

一意性により、衝突の可能性、つまり、関連するスコープ内に同一の識別子が存在する可能性が確立されます。最上位レベルでは、グローバルに一意の識別子は、他のデバイスやアプリでも競合することはありません。それ以外の場合、一意性のレベルは、識別子のエントロピーと、識別子の作成に使用されるランダム性のソースによって異なります。たとえば、インストールの Unix タイムスタンプ（1551414181 など）をシードとするランダムな識別子よりも、インストールのカレンダー日付（2019-03-01 など）をシードとするランダムな識別子の方が、衝突の可能性がはるかに高くなります。

一般に、ユーザー アカウント ID は一意であると見なすことができます。つまり、デバイスとアカウントの組み合わせごとに一意の ID があります。一方、母集団内で識別子の一意性が低いほど、個々のユーザーのトラッキングに役立たないため、プライバシー保護が強化されます。

整合性保護と否認防止

なりすましやリプレイが困難な識別子を使用して、関連付けられたデバイスまたはアカウントに特定のプロパティがあることを証明できます。たとえば、デバイスがスパマーによって使用されている仮想デバイスではないことを証明できます。なりすましが難しい ID は、否認防止性も備えています。デバイスが秘密鍵でメッセージに署名した場合、他のデバイスがメッセージを送信したと主張することは困難です。否認防止は、支払いの認証時など、ユーザーが望む場合もあれば、後悔するメッセージを送信した場合など、望ましくない場合もあります。

一般的なユースケースと使用すべき識別子

このセクションでは、ハードウェア ID（IMEI など）の代わりに使用できる ID について説明します。ハードウェア ID は、ユーザーがリセットできず、デバイスにスコープされるため、使用は推奨されません。多くの場合、アプリをスコープとする ID で十分です。

アカウント

携帯通信会社のステータス

この場合、アプリは携帯通信会社のアカウントを使用して、デバイスの電話機能やテキスト メッセージ機能とやり取りします。

推奨される識別子: IMEI、IMSI、Line1

この ID が推奨される理由

携帯通信会社関連の機能で必要な場合は、ハードウェア識別子を利用しても問題ありません。たとえば、これらの識別子を使用して、携帯通信会社や SIM スロットを切り替えたり、IP（Line1 用）を介して SMS メッセージを配信したりできます（SIM ベースのユーザー アカウント）。ただし、権限のないアプリの場合は、アカウント ログインを使用してサーバー側でユーザーのデバイス情報を取得することをおすすめします。その理由の一つは、Android 6.0（API レベル 23）以降では、これらの識別子は実行時の権限を介してのみ使用できるためです。ユーザーがこの権限をオフに切り替える可能性があるため、アプリはこれらの例外を適切に処理する必要があります。

モバイル サブスクリプションのステータス

この場合、アプリの機能をデバイス上の特定のモバイル サービス サブスクリプションに関連付ける必要があります。たとえば、SIM を介したデバイスのモバイル サブスクリプションに基づいて、特定のプレミアム アプリ機能へのアクセスを確認する必要がある場合などです。

推奨される識別子: デバイスで使用されている SIM を識別するための Subscription ID API。

サブスクリプション ID は、デバイスで使用されているインストール済みの SIM（物理 SIM と電子 SIM を含む）を一意に識別するためのインデックス値（1 から始まる）を提供します。この ID を使用すると、アプリの機能を特定の SIM のさまざまなサブスクリプション情報に関連付けることができます。この値は、デバイスが出荷時の設定にリセットされない限り、特定の SIM に対して安定しています。ただし、同じ SIM が異なるデバイスで異なるサブスクリプション ID を持つ場合や、異なる SIM が異なるデバイスで同じ ID を持つ場合があります。

この ID が推奨される理由

一部のアプリでは、この目的で ICC ID が使用されている場合があります。ICC ID はグローバルに一意であり、リセットできないため、Android 10 以降では、READ_PRIVILEGED_PHONE_STATE 権限を持つアプリにアクセスが制限されています。Android 11 以降、Android では、アプリの対象 API レベルに関係なく、getIccId() API を介した ICCID へのアクセスがさらに制限されています。影響を受けるアプリは、代わりにサブスクリプション ID を使用するように移行する必要があります。

シングル サインオン

この場合、アプリはシングル サインオン エクスペリエンスを提供し、ユーザーは既存のアカウントを組織に関連付けることができます。

推奨される識別子: アカウント マネージャー互換のアカウント（Google アカウントのリンクなど）

この ID が推奨される理由

Google アカウントのリンクを使用すると、ユーザーは既存の Google アカウントをアプリに関連付けることができ、組織のプロダクトやサービスにシームレスかつ安全にアクセスできるようになります。さらに、カスタム OAuth スコープを定義して、必要なデータのみを共有し、データの使用方法を明確に定義することで、ユーザーの信頼を高めることができます。

広告

ターゲティング

この場合、アプリはユーザーの関心のプロフィールを作成し、より関連性の高い広告を表示します。

推奨される識別子: アプリで広告用の ID を使用し、Google Play にアップロードまたは公開する場合は、その ID を広告 ID にする必要があります。

この ID が推奨される理由

これは広告関連のユースケースであり、組織のさまざまなアプリで使用できる ID が必要になる可能性があるため、広告 ID を使用するのが最も適切なソリューションです。Google Play デベロッパー コンテンツ ポリシーに基づき、広告のユースケースでは広告 ID の使用が必須です。これは、ユーザーが広告 ID をリセットできるためです。

アプリでユーザーデータを共有するかどうかにかかわらず、広告目的でユーザーデータを収集して使用する場合は、Google Play Console の [アプリのコンテンツ] ページの [データ セーフティ セクション] で広告目的を宣言する必要があります。

測定

この場合、アプリは、同じデバイス上の組織のアプリ全体でのユーザーの行動に基づいて、ユーザーのプロファイルを作成します。

推奨される識別子: 広告 ID または Play Install Referrer API

この ID が推奨される理由

これは広告関連のユースケースであり、組織のさまざまなアプリで使用できる ID が必要になる可能性があるため、広告 ID を使用するのが最も適切なソリューションです。広告のユースケースで ID を使用する場合は、ユーザーがリセットできる広告 ID を使用する必要があります。詳しくは、Google Play デベロッパー コンテンツ ポリシーをご覧ください。

コンバージョン

この場合、コンバージョンをトラッキングして、マーケティング戦略が成功しているかどうかを検出します。

推奨される識別子: 広告 ID または Play Install Referrer API

この ID が推奨される理由

これは広告関連のユースケースであり、組織のさまざまなアプリで使用できる ID が必要になる可能性があるため、広告 ID を使用するのが最も適切なソリューションです。Google Play デベロッパー コンテンツ ポリシーに基づき、広告のユースケースでは広告 ID の使用が必須です。これは、ユーザーが広告 ID をリセットできるためです。

リマーケティング

この場合、アプリにはユーザーの過去の関心に基づいて広告が表示されます。

推奨される識別子: 広告 ID

この ID が推奨される理由

これは広告関連のユースケースであり、組織のさまざまなアプリで使用できる ID が必要になる可能性があるため、広告 ID を使用するのが最も適切なソリューションです。Google Play デベロッパー コンテンツ ポリシーに基づき、広告のユースケースでは広告 ID の使用が必須です。これは、ユーザーが広告 ID をリセットできるためです。

アプリ解析

この場合、アプリはユーザーの行動を評価して、次のことを判断できるようにします。

  • 組織の他のプロダクトやアプリのうち、ユーザーに適している可能性があるもの。
  • ユーザーがアプリを使い続けるようにする方法。
  • ログアウトしたユーザーまたは匿名ユーザーの使用統計情報と分析を測定する。

考えられる解決策は次のとおりです。

  • アプリセット ID: アプリセット ID を使用すると、組織が所有する複数のアプリにわたってユーザーの行動を分析できます。ただし、ユーザーデータを広告目的で使用することはできません。Google Play 開発者サービスを搭載したデバイスをターゲットとする場合は、アプリセット ID を使用することをおすすめします。
  • Firebase ID（FID）: FID のスコープは、FID を作成するアプリに限定されます。これにより、アプリ間でユーザーを追跡するために識別子が使用されるのを防ぐことができます。また、ユーザーがアプリデータを消去したり、アプリを再インストールしたりすることで、簡単にリセットできます。FID の作成プロセスは簡単です。Firebase インストール ガイドをご覧ください。

アプリの開発

クラッシュ レポート

この場合、アプリはユーザーのデバイスでクラッシュした日時と理由に関するデータを収集します。

推奨される識別子: FID またはアプリセット ID

この ID が推奨される理由

FID は、それを作成したアプリにスコープ設定されるため、アプリ間でユーザーを追跡するために使用されることはありません。また、ユーザーがアプリデータを消去したり、アプリを再インストールしたりすることで、簡単にリセットできます。FID の作成プロセスは簡単です。Firebase インストール ガイドをご覧ください。アプリセット ID を使用すると、組織が所有する複数のアプリにわたってユーザーの行動を分析できます。ただし、ユーザーデータを広告目的で使用することはできません。

パフォーマンス レポート

この場合、アプリは読み込み時間やバッテリー使用量などのパフォーマンス指標を収集して、アプリの品質向上に役立てます。

使用が推奨される識別子: Firebase Performance Monitoring

この ID が推奨される理由

Firebase Performance Monitoring を使用すると、最も重要な指標に焦点を当て、アプリの最近の変更の影響をテストできます。

アプリのテスト

この場合、アプリはテストまたはデバッグを目的として、アプリでのユーザー エクスペリエンスを評価します。

推奨される識別子: FID またはアプリセット ID

この ID が推奨される理由

FID は、それを作成したアプリにスコープ設定されるため、アプリ間でユーザーを追跡するために使用されることはありません。また、ユーザーがアプリデータを消去したり、アプリを再インストールしたりすることで、簡単にリセットできます。FID の作成プロセスは簡単です。Firebase インストール ガイドをご覧ください。アプリセット ID を使用すると、ユーザーデータを広告目的で使用しない限り、組織が所有する複数のアプリにわたってユーザーの行動を分析できます。

クロスデバイス インストール

この場合、アプリが同じユーザーの複数のデバイスにインストールされているときに、アプリの正しいインスタンスを識別する必要があります。

推奨される識別子: FID または GUID

この ID が推奨される理由

FID は、この目的のために明示的に設計されています。そのスコープはアプリに限定されているため、異なるアプリ間でユーザーを追跡するために使用することはできません。また、アプリの再インストール時にリセットされます。FID では不十分なまれなケースでは、GUID を使用することもできます。

セキュリティ

不正行為の検出

この場合、バックエンド サービスを攻撃している複数の偽のデバイスを検出しようとしています。

使用が推奨される識別子: Google Play Integrity API の完全性トークン

この ID が推奨される理由

リクエストが、エミュレータや他のデバイスを偽装するコードではなく、正規の Android デバイスから送信されたものであることを確認するには、Google Play Integrity API を使用します。

広告の不正行為

この場合、アプリは、アプリ内でのユーザーのインプレッションとアクションが真正で検証可能であることを確認します。

推奨される識別子: 広告 ID

この ID が推奨される理由

Google Play デベロッパー コンテンツ ポリシーに基づき、広告のユースケースでは広告 ID の使用が必須です。これは、ユーザーが広告 ID をリセットできるためです。

デジタル著作権管理（DRM）

この場合、アプリは知的財産や有料コンテンツへの不正アクセスを防止したいと考えています。

推奨される識別子: FID または GUID を使用すると、ユーザーはコンテンツの上限を回避するためにアプリを再インストールする必要があります。これは、ほとんどのユーザーにとって十分な負担となります。この保護が不十分な場合、Android には、コンテンツへのアクセスを制限するために使用できる DRM API が用意されています。これには、APK ごとの識別子である Widevine ID が含まれます。

ユーザー設定

この場合、アプリはデバイスごとのユーザーの状態をアプリに保存します。特に、ログインしていないユーザーの状態を保存します。この状態を、同じデバイスで同じ鍵を使用して署名された別のアプリに転送することもできます。

推奨される識別子: FID または GUID

この ID が推奨される理由

ユーザーがアプリを再インストールして設定をリセットしたい場合があるため、再インストール時に情報を保持することはおすすめしません。