---
title: "Android SDKでユーザーを識別する"
description: "Adaptyでユーザーを識別して、パーソナライズされたサブスクリプション体験を向上させます（Android）。"
---
Adaptyはすべてのユーザーに対して内部プロファイルIDを作成します。ただし、独自の認証システムがある場合は、独自のCustomer User IDを設定する必要があります。[Profiles](profiles-crm)セクションでCustomer User IDによってユーザーを検索したり、すべてのインテグレーションに送信される[サーバーサイドAPI](getting-started-with-server-side-api)で使用したりできます。
### 設定時にCustomer User IDを設定する \{#setting-customer-user-id-on-configuration\}
設定時にユーザーIDが存在する場合は、`.activate()`メソッドの`customerUserId`パラメータとして渡すだけです：
```kotlin showLineNumbers
Adapty.activate(applicationContext, "PUBLIC_SDK_KEY", customerUserId = "YOUR_USER_ID")
```
:::tip
Adapty SDK がモバイルアプリにどのように統合されているか、実際の例を見てみませんか？ペイウォールの表示、購入処理、その他の基本機能を含む完全なセットアップを実演している[サンプルアプリ](sample-apps)をご覧ください。
:::
### 設定後にCustomer User IDを設定する \{#setting-customer-user-id-after-configuration\}
SDK設定時にユーザーIDがない場合は、`.identify()`メソッドを使っていつでも後から設定できます。このメソッドを使う最も一般的なケースは、ユーザーが匿名ユーザーから認証済みユーザーに切り替わる登録後や認証後です。
```kotlin showLineNumbers
Adapty.identify("YOUR_USER_ID") { error ->
if (error == null) {
// successful identify
}
}
```
```java showLineNumbers
Adapty.identify("YOUR_USER_ID", error -> {
if (error == null) {
// successful identify
}
});
```
リクエストパラメータ：
- **Customer User ID**（必須）：文字列のユーザー識別子。
:::warning
重要なユーザーデータの再送信
ユーザーが再度アカウントにログインする場合など、Adaptyのサーバーにそのユーザーの情報がすでに存在するケースがあります。このような場合、Adapty SDKは自動的に新しいユーザーとして切り替えて動作します。カスタム属性やサードパーティネットワークからのアトリビューションなど、匿名ユーザーに渡したデータがある場合は、識別済みユーザーに対してそのデータを再送信する必要があります。
また、新しいユーザーのデータが異なる場合があるため、ユーザーを識別した後はすべてのペイウォールとプロダクトを再取得する必要がある点にも注意してください。
:::
### ログアウトとログイン \{#logging-out-and-logging-in\}
`.logout()`メソッドを呼び出すことで、いつでもユーザーをログアウトできます：
```kotlin showLineNumbers
Adapty.logout { error ->
if (error == null) {
// successful logout
}
}
```
```java showLineNumbers
Adapty.logout(error -> {
if (error == null) {
// successful logout
}
});
```
その後、`.identify()`メソッドを使ってユーザーをログインできます。
### デバイスをまたいでユーザーを検出する \{#detect-users-across-devices\}
---
no_index: true
---
SDKが有効化されると、StoreKit（iOS）またはGoogle Play Billing（Android）からユーザーの既存のエンタイトルメントを自動的に読み取り、Adaptyバックエンドと同期します。有効なサブスクリプションは、アプリが`restorePurchases`を呼び出すことなく、Adaptyプロファイルに表示されます。
**自動では行われない**のは、新しいデバイスのプロファイルが元のデバイスと同じユーザーのものであることの認識です。AdaptyはCustomer User IDでプロファイルを照合するため、同一性の継続性はCUIDとして何を使用するかによって異なります。
**デバイス間でAdaptyが検出できること**
| あなたの設定 | Adaptyが検出すること | 必要な対応 |
| --- | --- | --- |
| Customer User ID = `device_id`（アプリのログインなし） | 新しいデバイスは異なるCUIDを取得するため、異なるプロファイルが作成されます。サブスクリプションは**Access level updated**イベントを通じて新しいプロファイルに同期されますが、`subscription_started`は発火しません。新しいプロファイルは元の購入の継承者として扱われます。`subscription_started`に基づくアナリティクスは、リターニングユーザーをカウント不足します。 | リターニングユーザーが既存のプロファイルをデバイス間で照合できるよう、安定したアカウントIDをCustomer User IDとして使用してください。 |
| Customer User ID = 安定したアカウントID（すべてのデバイスでログイン） | SDKは`activate()`でサブスクリプションを自動同期し、`identify()`がCUIDで既存のプロファイルを照合します。 | 追加の設定は不要です。IDとサブスクリプションの両方が自動的に解決されます。 |
| Apple Family Sharing の継承者 | ファミリーメンバーは**Access level updated**イベントのみを通じてサブスクリプションを受け取ります。`subscription_started`は発火しません。 | **Access level updated**をリッスンしてください。完全なイベントマトリクスは[Apple Family Sharing](apple-family-sharing)を参照してください。 |
| 同じApple/Googleアカウント、異なるアプリ内ユーザー | 最初に購入を記録したプロファイルが親になります。その後のプロファイルは継承者チェーンを通じてサブスクリプションを確認し、**Access level updated**イベントが1回発生します。 | ログインを必須にし、あなたのモデルに合った[共有モード](sharing-paid-access-between-user-accounts)を選択してください。 |
**新しいデバイスでの購入の復元**
ペイウォールにユーザーが操作できる「購入を復元」ボタンを設置してください。Apple App Review（ガイドライン3.1.1）で必須とされており、自動同期がエッジケースを見逃した場合のフォールバックとして機能します。このボタンはSDKの`restorePurchases`を呼び出す必要があります。
初回起動時にプログラムで`restorePurchases`を呼び出すことは、通常の使用では必要ありません。SDKはすでに`activate()`で同等の処理を実行しています。プログラムによる呼び出しは、`activate()`完了後にアクセスが欠落している場合のデバッグなど、強制的に新しいレシートチェックを行う場合にのみ使用してください。