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

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

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

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

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

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

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

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

  • 単一アプリ: ID はアプリの内部にあり、他のアプリからはアクセスできません。
  • アプリのグループ: ID には、事前定義された関連アプリのグループがアクセスできます。
  • デバイス: デバイスにインストールされたすべてのアプリからアクセスできます。

識別子に付与されるスコープが広いほど、トラッキング目的で使用されるリスクが高くなります。逆に、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 以降、アプリの対象 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 のスコープはアプリに限定されているため、異なるアプリ間でユーザーを追跡するために使用することはできません。また、アプリの再インストール時にリセットされます。まれに 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 が推奨される理由

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