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

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

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

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

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

  1. 可能な限り、ユーザーがリセット可能な識別子を選択する。リセット不可能なハードウェア ID 以外の識別子を使用するアプリでも、ほとんどのユースケースを実現できます。
  2. ハードウェア ID を使用しない。ほとんどのユースケースでは、必要な機能を制限することなく、International Mobile Equipment Identity(IMEI)などのハードウェア ID を使用しないようにできます。

    Android 10(API レベル 29)では、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 やフィンガープリントを使用してユーザーのリセットをブリッジし、後続の広告 ID をリンクしないでください。Google Play デベロッパー コンテンツ ポリシーには、以下のように記載されています。

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

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

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

広告 ID の使用に関連して、使用している SDK に関連するプライバシー ポリシーやセキュリティ ポリシーに注意してください。 たとえば、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

この例では、両方のテーブルの 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

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

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

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

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

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

    1. 両方の ACL に含まれる個人またはロールの数を最小限に抑えるために、広告主 ID をキーとするデータと PII の分離のアクセス制御リスト(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 メッセージを送信できません。

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

識別子の特性

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

範囲

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

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

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

リセット可能性と永続性

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

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

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

一意性

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

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

整合性保護と否認防止

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

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

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

アカウント

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

この場合、アプリは携帯通信会社 アカウントを使用してデバイスのスマートフォンやテキスト送信機能を操作します。

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

この ID が推奨される理由

携帯通信会社関連の機能に必要なハードウェア識別子は許容されます。たとえば、これらの識別子を使用して、携帯通信会社や SIM スロットを切り替えることや、(Line1 の)IP 経由で SMS メッセージを配信することができます(SIM ベースのユーザー アカウント)。ただし、権限のないアプリの場合は、アカウント ログインを使用して、サーバー側でユーザー デバイス情報を取得することをおすすめします。その理由の 1 つは、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 を使用する必要があります。

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

測定

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

推奨される識別子: 広告 ID または Play インストール リファラー API

この ID が推奨される理由

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

Conversions

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

推奨される識別子: 広告 ID または Play インストール リファラー API

この ID が推奨される理由

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

リマーケティング

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

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

この ID が推奨される理由

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

アプリ分析

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

  • 組織の他のどのプロダクトやアプリがユーザーに適しているか。
  • アプリに興味を持ってもらうにはどうすればよいか。
  • ログアウトしたユーザーや匿名ユーザーの使用統計情報と分析を測定。

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

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

アプリの開発

クラッシュ レポート

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

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

この ID が推奨される理由

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

パフォーマンス レポート

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

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

この ID が推奨される理由

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

アプリのテスト

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

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

この ID が推奨される理由

FID のスコープは FID を作成するアプリになるため、ID がアプリ間でのユーザーのトラッキングに使用されるのを防ぐことができます。また、ユーザーがアプリデータを消去したり、アプリを再インストールしたりできるため、簡単にリセットできます。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 の使用が必須です。

デジタル著作権管理(DRM)

このケースでは、アプリで知的財産または有料コンテンツへの不正なアクセスを保護する必要があります。

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

ユーザー設定

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

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

この ID が推奨される理由

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