Skip to content

Most visited

Recently visited

navigation

一意の識別子のベスト プラクティス

アプリでは、アプリのインスタンスや端末上の認証されていないユーザーよりも、端末を識別する必要がある場合がありますが、大部分のアプリにおいて最も必要なのは、特定のアプリのインストール(実際の実機ではなく)を識別することです。

幸いにも、インスタンス ID を使用するか、インストール時に独自の GUID を作成すると、Android へのアプリのインストールを簡単に識別できます。このドキュメントでは、ユースケースに基づいて、アプリで適切な識別子を選択するためのガイダンスを提供します。

Android パーミッションの概要については、パーミッションとユーザーデータを参照してください。Android パーミッションの操作に関する特定のベスト プラクティスについては、アプリ パーミッションのベスト プラクティスを参照してください。

Android 識別子を扱うときの原則

Android 識別子を扱うときは、次の原則を順守することをお勧めします。

#1: ハードウェア識別子の使用を避けます。必要な機能を制限することなく、ほとんどのユースケースで SSAID(Android ID)や IMEI などのハードウェア識別子の使用を避けることができます。

#2: ユーザー プロファイリングまたは広告のユースケースに対して、広告 ID のみを使用します。広告 ID を使用するときは、広告トラッキングの制限のフラグを常に尊重し、個人を特定できる情報(PII)に識別子を関連付けることができないようし、広告 ID がリセットされないようにする必要があります。

#3: 不正な支払いの防止と電話のユースケースを除いて、その他のすべてのユースケースに対して、可能な限り、インスタンス ID またはプライベートに保存された GUID を使用します。非広告のユースケースのほとんどでは、インスタンス ID または GUID を使用するだけで十分です。

#4: ユースケースで適切な API を使用し、プライバシー リスクを最小限にします。価値の高いコンテンツの保護に DRM API API を使用し、不正使用の防止に SafetyNet API を使用します。Safetynet API は、プライバシー リスクを招くことなく、端末が正規品であるかどうかを判定する最も簡単な方法です。

このガイドの残りのセクションでは、Android アプリの開発における、これらのルールについて解説しています。

Android 6.0 以降の識別子

MAC アドレスはグローバルに一意であり、ユーザーによるリセットやファクトリー リセットで変更されません。通常、ユーザーを識別するために MAC アドレスを使用することは推奨されません。そのため、Android M 以降では、サードパーティの API を介して、ローカルの端末 MAC アドレス(たとえば、Wifi や Bluetooth など)は利用できませんWifiInfo.getMacAddress() メソッドと BluetoothAdapter.getDefaultAdapter().getAddress() メソッドの両方が 02:00:00:00:00:00 を返します。

また、Bluetooth や Wifi スキャンを介して、近くの外部端末の MAC アドレスにアクセスするには、次のパーミッションを保持している必要があります。

メソッド / プロパティ 必要なパーミッション
WifiManager.getScanResults() ACCESS_FINE_LOCATION または ACCESS_COARSE_LOCATION
BluetoothDevice.ACTION_FOUND ACCESS_FINE_LOCATION または ACCESS_COARSE_LOCATION
BluetoothLeScanner.startScan(ScanCallback) ACCESS_FINE_LOCATION または ACCESS_COARSE_LOCATION

広告 ID の使用

広告 ID は、ユーザーがリセットできる識別子であり、広告のユースケースに適していますが、使用上の注意点がいくつかあります。

広告 ID のリセットに関しては、常にユーザーの意図を優先してください。ユーザーの同意なしに、より永続性が高い端末の識別子や指紋を使用して、ユーザーによるリセットをブリッジすることにより、以降の広告 ID をリンクしないでください。Google Play デベロッパー コンテンツ ポリシーでは、次のように定められています。

...リセットした場合は、ユーザーの明示的な同意なしに、新しい広告 ID を以前の広告 ID または以前の広告 ID から派生したデータにリンクしないでください。

関連付けられているパーソナライズド広告フラグを常に考慮してください。ユーザーが広告 ID に関連付けられているトラッキングの頻度や範囲を制限できるように広告 ID を設定することができます。常に AdvertisingIdClient.Info.isLimitAdTrackingEnabled() メソッドを使用して、ユーザーの意図を無視することがないようにしてください。Google Play デベロッパー コンテンツ ポリシーでは、次のように定められています。

...ユーザーの「インタレストベース広告をオプトアウト」または「広告のパーソナライズをオプトアウト」の設定に従う必要があります。ユーザーがこの設定を有効にしている場合、広告の目的のために、またはユーザーをパーソナライズド広告の対象にするために、広告 ID を使用して、ユーザー プロファイルを作成しないでください。許可されるアクティビティには、コンテキスト広告、頻度の制限、コンバージョン トラッキング、レポート、セキュリティおよび不正使用の検知が含まれます。

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

また、Google Play デベロッパー コンテンツ ポリシーにより、広告 ID を「ユーザーの明示的な同意なしに、個人を特定できる情報にリンクしたり、永続的な端末識別子(たとえば、SSAID、MAC アドレス、IMEI など)に関連付けたりしない」ことが求められている点に注意してください。

例として、情報を収集して、データベース テーブルの次の列に入力するとします。

timestamp ad_id account_id clickid

TABLE-01

account_id name dob country

TABLE-02

この例では、両方のテーブルの account_id 列を使用して、ad_id 列を PII に関連付けることができますが、この操作は、ユーザーの明示的な同意がない場合は、Google Play デベロッパー コンテンツ ポリシーに違反しています。

広告主の ID と PII 間のリンクが常にこのように明確であるとは限らないことに注意してください。PII と 広告 ID のキー付きテーブルの両方に表示される「疑似識別子」が存在する可能性があり、疑似識別子によって問題が発生することもあります。たとえば、TABLE-01 と TABLE-02 を次のように変更するとします。

timestamp ad_id clickid dev_model

TABLE-01

timestamp demo account_id dev_model name

TABLE-02

この場合、非常にまれなクリック イベントにより、イベントのタイムスタンプと端末モデルを使用して、広告主 ID TABLE-01 を TABLE-02 に格納されている PII に関連付けることが引き続き可能になります。

多くの場合、データセットにこのような疑似識別子が存在しないようにすることは困難ですが、関連付けによる明確なリスクの多くは、可能な限り一意のデータを生成することによって防止できます。この例では、タイムスタンプの精度が低下すると、同じモデルの複数の端末がすべてのタイムスタンプに表示されます。

その他のソリューションには、次のようなものが含まれます。

広告 ID を責任を持って操作することに関する詳細については、広告 IDのヘルプセンターの記事を参照してください。

インスタンス ID および GUID の使用

端末上で実行されているアプリ インスタンスを識別するための最も簡単なソリューションは、インスタンス ID を使用することです。これは、ほとんどの非広告のユースケースで推奨されるソリューションです。インスタンス ID がプロビジョニングされたアプリ インスタンスのみがこの識別子にアクセスできます。インスタンス ID はアプリがインストールされている間だけ維持されるため、インスタンス ID を(比較的)簡単にリセットすることができます。

そのため、インスタンス ID は、リセット不可の端末固有のハードウェア ID よりも優れたプライバシー特性を提供します。また、インスタンス ID はメッセージに署名する(および同様のアクション)ためのキーペアを備えており、Android、iOS、おおび Chrome で使用できます。詳細については、インスタンス ID とはのヘルプセンターのドキュメントを参照してください。

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

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

この識別子はグローバルに一意であるため、特定のアプリ インスタンスの識別に使用できます。アプリに識別子をリンクすることに関連する不安を解消するためには、外部(共有)ストレージではなく、内部ストレージに GUID を保存する必要があります。詳細については、ストレージ オプション ガイドを参照してください。

識別子の特性の理解

Android オペレーティング システムは、さまざまな動作特性を持つ多数の ID を提供しています。使用すべき ID は、ユースケースで以下の特性が機能する方法に応じて決定してください。ただし、これらの特性はプライバシーに密接に関わるため、これらの特性がプライバシーに対してどのように機能するかを把握することが重要になります。

スコープ

識別子のスコープにより、識別子にアクセスできるシステムが指定されます。通常、Android 識別子のスコープは次の 3 種類に分類されます。

識別子に付与されるスコープが広くなると、識別子がトラッキングのために使用されるリスクが増大します。一方、単一のアプリ インスタンスのみが識別子にアクセスできる場合は、異なるアプリのトランザクションで端末をトラッキングするために識別子を使用することができなくなります。

リセット可能性と永続性

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

リセット可能性により、ユーザーは既存のプロファイル情報との関連付けが解除された新しい ID を作成できるようになります。識別子がより長期に渡って安定的に維持されると(たとえば、ファクトリー リセットなどで変更されない場合)、ユーザーが長期に渡るトラッキングの対象になるリスクが増大します。アプリの再インストール時に識別子がリセットされる場合は、アプリ内またはシステム設定からユーザーが明示的に識別子をリセットできないときでも、識別子の永続性が短縮され、ID をリセットする手段が提供されます。

一意性

一意性により、関連付けられているスコープに同一の識別子が存在する可能性が規定されます。他の端末またはアプリ上であっても、最上位レベルでは GUID が競合することはありません。一方、一意性のレベルは、識別子のサイズと識別子の作成に使用したランダム性のソースによって異なります。たとえば、インストールしたときのカレンダー日付(たとえば、2015-01-05)でシード処理されたランダムな識別子に競合が発生する可能性は、インストールしたときの Unix タイムスタンプ(たとえば、1445530977)でシード処理された識別子の場合よりもはるかに高くなります。

一般的に、ユーザー アカウントの識別子は、一意であると見なされます(つまり、端末とアカウントの各組み合わせに一意の ID があります)。一方、母集団(たとえば、端末の)の中で識別子の一意性のレベルが低くなると、個々のユーザーのトラッキングに使用される際の有用性が低くなるため、プライバシーの保護が強化されます。

整合性保護と非否認性

なりすましや再生成が難しい識別子を使用して、関連付けられている端末やアカウントに特定の特性があること(たとえば、スパム送信者によって使用される仮想端末ではないこと)を証明できます。また、なりすましが難しい識別子は非否認性を提供します。端末でシークレット キーを使ってメッセージが署名された場合、他の誰かの端末からメッセージが送信されたと主張することが難しくなります。非否認性は、ユーザーに必要な特性(たとえば、支払いの認証)にも、望ましくない特性(たとえば、不適切なメッセージの送信)にもなり得ます。

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

このセクションでは、IMEI や SSAID などのハードウェア ID の代わりに、多くのユースケース使用する別の識別子について説明します。ユーザーはハードウェア ID をリセットできないことに加えて、ハードウェア ID の収集を限定的にしか制御できないため、ハードウェア ID の使用はお勧めしません。

ログアウトしたユーザー設定のトラッキング

このケースでは、サーバー側で端末ごとの状態を保存します。

推奨する識別子:インスタンス ID または GUID。

推奨する理由:

アプリの再インストール後も情報を維持することはお勧めしません。ユーザーは、アプリを再インストールすることにより、ユーザー設定をリセットしなければならない場合があるからです。

ログアウトしたユーザー行動のトラッキング

このケースでは、同じ端末の異なるアプリやセッションでのユーザーの行動に基づいて、ユーザーのプロファイルを作成します。

推奨する識別子:広告 ID。

推奨する理由:

Google Play デベロッパー コンテンツ ポリシーで規定されているように、ユーザーは広告 ID をリセットできるため、広告のユースケースでは、広告 ID を必ず使用する必要があります。

ログアウトしたユーザーまたは匿名のユーザー分析の生成

このケースでは、ログアウトしたユーザーまたは匿名のユーザーの使用統計情報や分析を評価します。

推奨する識別子:インスタンス ID。インスタンス ID が不十分な場合は、GUID を使用できます。

推奨する理由:

インスタンス ID または GUID は、これらの ID を作成したアプリに適用されるため、これらの ID を使用して複数のアプリでユーザーをトラッキングすることが防止されます。アプリのデータをクリアするか、アプリを再インストールすることにより、これらの ID を簡単にリセットできます。インスタンス ID と GUID は簡単に作成できます。

収集しているデータが匿名であることをユーザーに通知している場合、識別子を PII に関連付けていないことや、識別子を PII とリンクされている可能性のあるその他の識別子に関連付けていないことを確認する必要があることに注意してください。

Google Analytics for Mobile Apps を使用することもできます。Google アナリティクスは、アプリ単位で分析するためのソリューションを提供します。

ログアウトしたユーザー コンバージョンのトラッキング

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

推奨する識別子:広告 ID。

推奨する理由:

これは広告関連のユースケースであり、さまざまなアプリで利用できる ID が必要であるため、広告 ID の使用が最も適切なソリューションになります。

複数のインストールの処理

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

推奨する識別子:インスタンス ID または GUID。

推奨する理由:

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

不正防止:無料コンテンツ制限の適用および結託攻撃の検知

このケースでは、ユーザーが端末に表示できる無料コンテンツ(記事など)の数を制限します。

推奨する識別子:インスタンス ID または GUID。

推奨する理由:

GUID またはインスタンス ID を使用すると、ユーザーは、コンテンツの制限を超えるためにアプリを再インストールする必要があります。これは、ほとんどのユーザーにとって、十分な障壁になります。この対策では十分ではない場合、Android は、コンテンツへのアクセスを制限できる DRM API を提供します。

電話機能および携帯通信会社機能の管理

このケースでは、アプリで端末の電話機能とテキスト送信機能を操作します。

推奨する識別子:IMEI、IMSI、および Line1(Android 6.0(API レベル 23)以降では PHONE パーミッション グループが必要)。

推奨する理由:

電話および携帯通信会社に関連する機能にハードウェア ID が必要な場合、ハードウェア ID の使用が許容されます。たとえば、SIM ベースのユーザー アカウントで、携帯通信会社 / SIM スロットを切り替える場合や、IP(Line1 用)を介して SMS メッセージを配信する場合などです。ただし、Android 6.0 以降では、ランタイム パーミッションを使用する場合にのみ、これらの識別子を使用でき、ユーザーがこのパーミッションをオフに切り替えた場合は、アプリでこれらの例外を適切に処理する必要があることに注意してください。

不正使用の検知:ボットおよび DDoS 攻撃の特定

このケースでは、バックエンド サービスを攻撃する複数の疑似デバイスを検知します。

推奨する識別子:Safetynet API。

推奨する理由:

単独の識別子を使用した場合、端末が正規のものであるかどうかの判定が難しくなります。Safetynet API の SafetyNet.SafetyNetApi.attest(mGoogleApiClient, nonce) メソッドを使用して、リクエストを実行している端末が正規のものであるかどうかを判定することにより、正規の Android 端末(エミュレータ、または別の端末になりすましたコードではなく)からリクエストが送信されていることを確認できます。詳細については、Safetynet の API ドキュメントを参照してください。

不正使用の検知:盗まされた価値の高い認証情報の検知

このケースでは、盗まれた価値の高い認証情報を使用して、単一の端末が繰り返し使用されている(不正な支払いを行う目的などで)かどうかを検知します。

推奨する識別子:IMEI または IMSI(Android 6.0(API レベル 23)以降では PHONE パーミッション グループが必要)。

推奨する理由:

端末で盗まれた認証情報が使用されると、盗まれた価値の高い複数の認証情報(トークン化されたクレジット カードなど)が換金される可能性があります。こうしたシナリオでは、検知を避けるためにソフトウェア ID がリセットされる場合があるため、ハードウェア ID を使用することがあります。

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)