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

このドキュメントでは、ユースケースに応じて適切なアプリ ID を選択する方法について説明します。

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

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

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

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

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

    Android 10（API レベル 29）以降、IMEI やシリアル番号など、リセット不可能な ID に関して制限が追加されています。このような 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 やフィンガープリントを使用して新しい広告 ID とリンクする）ことはしないでください。Google Play デベロッパー コンテンツ ポリシーに次のような規定があります。

「リセットが行われた場合に、ユーザーの明示的な同意なしに、新しい広告 ID と、以前の広告 ID や以前の広告 ID から派生したデータとをリンクしてはなりません。」

関連付けられているパーソナライズド広告フラグを必ず尊重する。ユーザーが広告 ID に関連付けられているトラッキングの頻度や範囲を制限できるように広告 ID を設定することができます。ユーザーの目的を回避しないように、常に AdvertisingIdClient.Info.isLimitAdTrackingEnabled() メソッドを使用します。Google Play デベロッパー コンテンツ ポリシーに次のような規定があります。

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

広告 ID の使用に関して、使用している SDK に適用されるプライバシー ポリシーやセキュリティ ポリシーに注意する。たとえば、Google アナリティクス SDK から enableAdvertisingIdCollection() メソッドに true を渡す場合は、適用されるすべてのアナリティクス SDK ポリシーを確認し、遵守する必要があります。

また、Google Play デベロッパー コンテンツ ポリシーは、広告 ID を「個人情報にリンクしたり、永続的なデバイス ID（SSAID、MAC アドレス、IMEI など）に関連付けたりしない」ことを求めています。

たとえば、情報を収集してデータベース テーブルの次の列に入力しようとしている場合を考えてみましょう。

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

この例の場合、両方のテーブルの account_id 列を使用することで、ad_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

この場合は、クリック イベントがごくまれにしか発生しなかったときに、イベントのタイムスタンプとデバイスモデルを使用して TABLE-01 の広告主 ID と TABLE-02 の PII が関連付けられる可能性があります。

多くの場合、データセットにこのような疑似識別子が一切存在しないようにすることは困難ですが、関連付けが発生する明らかなリスクがある場合については、できる限り一意のデータを一般化することによってリスクを回避できます。上記の例では、これはタイムスタンプの精度を下げることを意味します。これにより、同じモデルの複数のデバイスがすべてのタイムスタンプについて現れます。

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

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

  • 広告 ID のキー付きデータと PII の両方にアクセスできるユーザーまたは役割のアクセス コントロール リストを分離および監視する。両方のソースに同時にアクセスする機能を厳密に制御し、監査することで（テーブル間の結合を行うなど）、広告 ID と PII が関連付けられるリスクを軽減できます。一般的に、アクセスの制御とは、次の操作のことです。

    1. 広告主 ID をキーとするデータ用と PII 用の各アクセス制御リスト（ACL）を相互に関連付けないように維持し、両方の ACL に含まれるメンバーやロールの数を最小限に抑える。
    2. アクセスログ作成と監査の機能を実装し、ルールの例外を検知して管理する。

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

FID と GUID を操作する

デバイス上で実行されているアプリのインスタンスを特定する方法としては、Firebase インストール ID（FID）が最もわかりやすく、広告以外の大多数のユースケースではこの方法をおすすめします。インスタンス ID にアクセスできるのは、割り当てられたアプリ インスタンスだけに限られます。また、インスタンス ID は、アプリがインストールされている間しか存続しないため、比較的簡単にリセットできます。

そのため、FID は、リセット不可能なデバイスレベルのハードウェア ID に比べて、優れたプライバシー特性を備えています。詳細については、firebase.installations API リファレンスをご覧ください。

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

Kotlin

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

Java

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

この ID はグローバルに一意であるため、特定のアプリ インスタンスを識別する際に使用できます。複数のアプリ間での識別子の関連付けによる問題を避けるため、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 API、getifaddrs() API、Netlink ソケットではなく、ConnectivityManager の上位レベル API を使用してください。たとえば、現在のルートの最新情報を必要とするアプリは、ConnectivityManager.registerNetworkCallback() を使用してネットワークの変更をリッスンし、ネットワークに関連付けられた LinkProperties.getRoutes() を呼び出すことで、この情報を取得できます。

識別子の特性

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

範囲

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

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

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

リセット可能性と永続性

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

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

リセットできる場合、ユーザーは既存のプロファイル情報との関連付けが解除された新しい ID を作成できます。初期化後も存続する識別子など、識別子が存続する期間が長くなり安定性が高くなるほど、ユーザーが長期にわたるトラッキングの対象とされるリスクが高まります。アプリの再インストール時に識別子がリセットされる場合は、アプリ内やシステム設定からユーザーが明示的に識別子をリセットする手段がなくても、識別子の永続性が低くなり、ID をリセットする手段が提供されることになります。

一意性

一意性により、衝突の可能性が決まります。つまり、関連付けられたスコープ内に同一の ID が存在することになります。一意性が最高レベルの GUID（Globally-Unique ID）の場合、他のデバイスやアプリも含めて競合は発生しません。それ以外の場合、一意性のレベルは、識別子のエントロピーと識別子の作成に使用したランダム性のソースによって異なります。たとえば、暦上のインストール日（2019-03-01 など）に基づいて作成したランダム ID は、インストールの Unix タイムスタンプ（1551414181 など）に基づいて作成した ID に比べて、競合が発生する可能性が格段に高くなります。

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

整合性保護と否認防止

なりすましやリプレイ攻撃が難しい ID を使用することで、関連付けられているデバイスやアカウントが特定の特性を持っていることを証明できます。たとえば、デバイスがスパム送信者が使用している仮想デバイスではないことを証明できます。なりすましが難しい ID は、否認防止性も備えています。デバイスがシークレット鍵を使用してメッセージに署名すると、「他の誰かのデバイスがメッセージを送信した」と主張することは困難になります。否認防止は、ユーザーにとって望ましいものであるとき（決済の認証に使用する場合など）もあれば、望ましくないものであるとき（送信すべきでないメッセージを送信してしまった場合など）もあります。

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

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

アカウント

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

アプリが携帯通信会社アカウントを使用してデバイスの通話機能やテキスト メッセージ機能を操作する場合です。

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

この ID が推奨される理由

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

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

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

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

サブスクリプション 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 を使用するように移行する必要があります。

シングル サインオン

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

推奨される ID: アカウント マネージャーと互換性のあるアカウント（Google アカウントのリンクなど）

この ID が推奨される理由

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

広告

ターゲティング

この場合、アプリによってユーザーの興味や関心のプロファイルが作成され、より関連性の高い広告が表示されます。

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

この ID が推奨される理由

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

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

測定

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

使用する推奨 ID: 広告 ID または Play インストール リファラー API

この ID が推奨される理由

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

コンバージョン

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

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

この ID が推奨される理由

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

リマーケティング

この場合、アプリはユーザーの過去の興味 / 関心に基づいて広告を表示します。

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

この ID が推奨される理由

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

アプリ分析

この場合、アプリはユーザーの動作を評価して、以下を判断します。

  • お客様に適した、組織の他のプロダクトやアプリ
  • ユーザーがアプリの使用に興味を持ち続けるようにする方法。
  • ログアウト状態または匿名ユーザーの使用統計情報と分析情報を測定します。

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

  • アプリセット ID: アプリセット ID を使用すると、広告目的でユーザーデータを使用しない限り、組織が所有する複数のアプリ全体でユーザーの行動を分析できます。Google Play 開発者サービスを搭載したデバイスを対象としている場合は、アプリセット ID を使用することをおすすめします。
  • Firebase ID（FID）: FID は、作成したアプリに適用されるため、複数のアプリでユーザーをトラッキングするために使用されることはありません。また、ユーザーがアプリのデータを消去したりアプリを再インストールしたりすることで簡単にリセットできます。FID の作成プロセスは簡単です。Firebase のインストール ガイドをご覧ください。

アプリの開発

クラッシュ レポート

この場合、アプリはユーザーのデバイスでクラッシュしたタイミングと原因に関するデータを収集します。

推奨 ID: FID またはアプリセット ID

この ID が推奨される理由

FID は、その ID を作成したアプリがスコープとなるため、複数のアプリを横断してユーザーをトラッキングする目的には使用できないようになっています。また、ユーザーがアプリデータを消去したり、アプリを再インストールしたりできるため、リセットも簡単です。FID の作成プロセスは簡単です。Firebase インストール ガイドをご覧ください。アプリセット ID を使用すると、ユーザーデータを広告目的で使用しない限り、組織が所有する複数のアプリでユーザーの行動を分析できます。

パフォーマンス レポート

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

推奨される ID: Firebase Performance Monitoring

この ID が推奨される理由

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

アプリのテスト

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

推奨 ID: FID またはアプリセット ID

この ID が推奨される理由

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

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

1 人のユーザーが複数のデバイス上に同じアプリをインストールした場合に、アプリ インスタンスを正しく識別する必要があるケースが該当します。

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

この ID が推奨される理由

FID は、まさにこの目的のために設計されています。スコープがそのアプリに限定されているため、複数のアプリ間でのユーザーのトラッキングには使用できません。また、再インストール時にリセットされます。まれに、FID では不十分な場合は、GUID を使用することもできます。

セキュリティ

不正行為の検出

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

推奨される ID: Google Play Integrity API 完全性トークン

この ID が推奨される理由

エミュレータや、デバイスになりすましたコードではなく、正規の Android デバイスから送信されたリクエストであるか検証するには、Google Play Integrity API を使用します。

広告の不正行為

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

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

この ID が推奨される理由

Google Play デベロッパー コンテンツ ポリシーの規定により、広告のユースケースでは、ユーザーがリセット可能な広告 ID を使用する必要があります。

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

この場合、アプリは知的財産または有料コンテンツへの不正アクセスを保護することを目的としています。

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

ユーザー設定

このケースでは、特にログインしていないユーザーのデバイスごとのユーザーの状態をアプリで保存します。この状態は、同じデバイス上の同じ鍵で署名された別のアプリに移行できます。

推奨される ID: FID または GUID

この ID が推奨される理由

ユーザーが設定をリセットするためにアプリを再インストールする場合があるため、再インストール後も存続する情報を使用することは推奨されません。