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

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

Android の権限の概要については、権限 概要をご覧ください。特定のベスト プラクティス Android の権限を使用する際のおすすめの方法については、アプリの権限に関する推奨事項をご覧ください プラクティスをご覧ください。

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

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

1. 可能な限り、ユーザーがリセット可能な識別子を選択します。アプリは ほとんどのユースケースでは ハードウェア ID。

2. ハードウェア ID を使用しない。ほとんどのユースケースでは International Mobile Equipment Identity（国際移動機構番号）などのハードウェア識別子を使用する 。

   Android 10（API レベル 29）以降、IMEI やシリアル番号など、リセット不可能な ID に関して制限が追加されています。このような ID にアクセスできるのは、デバイス オーナーまたはプロファイル オーナーのアプリや、特別な携帯通信会社パーミッションを持っているアプリ、READ_PRIVILEGED_PHONE_STATE 特権パーミッションを持っているアプリに限られます。

3. ユーザー プロファイル作成や広告のユースケースでは広告 ID だけを使用する。日時 使用する場合は、広告 ID を使用して、ユーザーの選択することもできます 広告トラッキング条件 広告 ID と個人を特定できる情報を 使用者の明示的な同意がある場合にのみ、 user です。

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 を設定することができます。必ず AdvertisingIdClient.Info.isLimitAdTrackingEnabled() メソッドを使用して、ユーザーが選択した設定が無視されることのないようにしてください。Google Play デベロッパー コンテンツ ポリシーに次のような規定があります。

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

注: 2021 年後半に予定されている Google Play 開発者サービスの更新では、ユーザーが広告 ID を使ったカスタマイズを Android 設定でオプトアウトすると、その広告 ID が削除されるようになります。削除された広告 ID にアクセスしようとすると、ID の代わりにゼロの文字列が返されます。詳しくは、Google Play Console ヘルプをご覧ください。

広告 ID の使用に関連して、ご利用の SDK にプライバシー ポリシーやセキュリティ ポリシーが適用されることを確認してください。 たとえば、true を enableAdvertisingIdCollection() 使用する場合は、Google アナリティクス SDK の 該当するアナリティクス 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

このケースでもクリック イベントの発生はまれですが、 広告主 ID TABLE-01 と TABLE-02 に含まれる PII を、 タイムスタンプとデバイスモデルが含まれます。

多くの場合、そのような疑似識別子が存在しないことを保証するのは困難 結合する方法を一般化することで、明らかな結合のリスクを回避できます。 使用することは避けましょう。この例では、タイムスタンプの精度を低下させると、同じモデルの複数のデバイスが同じタイムスタンプで存在することになります。

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

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

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

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

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

FID と GUID を操作する

Compute Engine で実行されているアプリ インスタンスを特定する最も簡単な方法は、 Firebase インストール ID（FID）を使用することが推奨されます。 統合できます対象のアプリ インスタンスのみ ID にアクセスでき、比較的簡単に アプリケーションがインストールされている間だけ保持されるため、リセット可能です。

そのため FID は、 デバイス スコープのハードウェア ID。リセットできません。詳細については、firebase.installations API リファレンスをご覧ください。

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

KotlinJava

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

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 API、getifaddrs() API、Netlink ソケットではなく、ConnectivityManager の上位レベル API を使用してください。たとえば、 ConnectivityManager.registerNetworkCallback() を使用してネットワークの変更をリッスンすることにより、現在のルートでこの情報を取得できます。 関連付けられているネットワークの LinkProperties.getRoutes()。

識別子の特性

Android OS では、動作特性の異なるさまざまな ID を使用できます。どの ID を使用するべきかは、以下の特性がそのユースケースでどのように機能するかによって判断します。これらの特性にはプライバシーへの影響もあります ですからこれらの特性がビジネスモデルと 相互に通信します。

範囲

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

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

識別子に付与されるスコープが広いほど、識別子が悪用されるリスクは高くなる 使用しないでください。逆に、ID にアクセスできるのが トランザクション間でのデバイスのトラッキングには使用できません。 使用できます。

リセット可能性と永続性

リセット可能性と永続性により、識別子の有効期間が定義され、 確認します。一般にリセットのトリガーとなるイベントは、アプリ内リセット、システム設定を介したリセット、起動時のリセット、インストール時のリセットなどです。Android 識別子の有効期間にはばらつきがあるが、通常、識別子の有効期間は ID のリセット方法を指定します。

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

リセットの可否により、関連付けのない新しい ID をユーザーが作成できるようになります。 取得することもできます期間が長く、信頼性が高いほど、 初期状態へのリセット後も持続する ID、 ユーザーが長期的な追跡の対象となるリスクが高くなります。アプリの再インストール時に識別子がリセットされる場合は、アプリ内やシステム設定からユーザーが明示的に識別子をリセットする手段がなくても、識別子の永続性が低くなり、ID をリセットする手段が提供されることになります。

一意性

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

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

整合性保護と否認防止

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

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

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

アカウント

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

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

推奨される ID: IMEI、IMSI、Line1

この ID が推奨される理由

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

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

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

推奨される ID: サブスクリプション ID API デバイスで使用されている SIM を識別する。

サブスクリプション ID は、デバイスで使用されている装着済みの SIM（物理 SIM、電子 SIM など）を一意に識別するためのインデックス値（1 から開始）を提供します。この ID により、アプリは特定の SIM のさまざまな定期購入情報に機能を関連付けることができます。この値は特定の SIM で不変です 。ただし、同じ SIM でデバイスごとに異なる定期購入 ID が割り当てられる場合や、異なる SIM でデバイスごとに同じ ID が割り当てられる場合もあります。

注: この ID にアクセスするには、READ_PHONE_STATE 権限が必要です。

この ID が推奨される理由

一部のアプリでは、現在この目的で ICC ID を使用している場合があります。ICC ID はグローバルに一意であり再設定不可能なため、 は READ_PRIVILEGED_PHONE_STATE のアプリに制限されています 権限が必要になります。Android 11 以降、Android はさらに 規則による ICCID へのアクセス制限 getIccId() API のみをサポートしています。影響を受けるアプリは、代わりにサブスクリプション ID を使用するように移行する必要があります。

シングル サインオン

この場合、シングル サインオンが用意されており、ユーザーは 既存のアカウントを組織に関連付ける。

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

この ID が推奨される理由

Google アカウントのリンクを使用すると、ユーザーがユーザーの既存の Google アプリと関連付けることで、アプリへのシームレスかつ安全なアクセスを 提供することです。さらに、 カスタム OAuth スコープの定義 必要なデータのみを共有できるようにして、共有方法を明確に定義することで、 使用されます。

広告

ターゲティング

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

使用に推奨される識別子: アプリで広告、アップロード、 広告 ID である必要があります。

この ID が推奨される理由

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

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

測定

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

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

この ID が推奨される理由

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

コンバージョン

マーケティング戦略の成否を判断するためにコンバージョンをトラッキングするケースが該当します。

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

この ID が推奨される理由

これは広告関連のユースケースであり、利用可能な ID が必要になる場合があります 使用されるため、広告 ID は、 最適なソリューションを選ぶことができます広告配信 ID の使用が必須の場合、 使用ケースについて、 Google Play デベロッパー コンテンツ ポリシー ユーザーがリセットできるからです。

リマーケティング

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

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

この ID が推奨される理由

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

アプリ分析

この場合、アプリはユーザーの行動を評価して、 説明します。

• 組織の他のプロダクトやサービスのうち、 ユーザーです。
• ユーザーの関心を維持する方法。
• ログアウト状態または匿名ユーザーの使用統計情報と分析情報を測定します。

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

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

アプリの開発

クラッシュ レポート

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

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

この ID が推奨される理由

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

パフォーマンス レポートの作成

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

推奨される ID: Firebase Performance Monitoring

この ID が推奨される理由

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

アプリのテスト

この場合、アプリをテストする目的で、アプリに関するユーザー エクスペリエンスが評価されます 使用しないでください。

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

この ID が推奨される理由

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

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

この場合、アプリは適切なインスタンスを特定する必要があります。 同じユーザーの複数のデバイスにインストールされる場合です。

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

この ID が推奨される理由

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

セキュリティ

不正行為の検出

このケースでは、自社を攻撃している複数の偽のデバイスを検出しようとしています。 提供します

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

この ID が推奨される理由

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

広告の不正行為

この例では、アプリでのユーザーのインプレッションとアクションが 本物であり、検証可能です。

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

この ID が推奨される理由

次の規定により、広告のユースケースでは広告 ID の使用が必須です。 Google Play デベロッパー コンテンツ ポリシー ユーザーがリセットできるからです。

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

今回の場合、お客様のアプリは、 有料コンテンツなどです

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

ユーザー設定

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

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

この ID が推奨される理由

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