---
title: "Capacitor SDKでユーザーを識別する"
description: "Adapty SDKを使用してCapacitorアプリでユーザーを識別する方法を学びます。"
---

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`パラメーターとして渡すだけです：

```typescript showLineNumbers

try {
  await adapty.activate({
    apiKey: 'YOUR_PUBLIC_SDK_KEY',
    params: {
      customerUserId: 'YOUR_USER_ID'
    }
  });
} catch (error) {
  console.error('Failed to activate Adapty:', error);
}
```

### 設定後にCustomer User IDを設定する \{#setting-customer-user-id-after-configuration\}

SDKの設定時にユーザーIDがない場合は、`.identify()`メソッドを使っていつでも後から設定できます。このメソッドの最も一般的なユースケースは、ユーザーが匿名ユーザーから認証済みユーザーに切り替わる際の登録後または認証後です。

```typescript showLineNumbers

try {
  await adapty.identify({ customerUserId: 'YOUR_USER_ID' });
  console.log('User identified successfully');
} catch (error) {
  console.error('Failed to identify user:', error);
}
```

リクエストパラメーター：

| パラメーター | 必須/任意 | 説明 |
|---------|--------|-----------|
| **customerUserId** | 必須 | 文字列のユーザー識別子。 |

:::warning
重要なユーザーデータの再送信

ユーザーが再度アカウントにログインする場合など、Adaptyのサーバーにすでにそのユーザーの情報が存在していることがあります。このような場合、Adapty SDKは自動的に新しいユーザーに切り替えて動作します。カスタム属性やサードパーティネットワークからのアトリビューションなど、匿名ユーザーに渡したデータがある場合は、識別されたユーザーに対してそのデータを再送信する必要があります。

また、新しいユーザーのデータが異なる可能性があるため、ユーザーを識別した後にすべてのペイウォールとプロダクトを再取得する必要があることも重要です。
:::

### ログアウトとログイン \{#logging-out-and-logging-in\}

`.logout()`メソッドを呼び出すことで、いつでもユーザーをログアウトできます：

```typescript showLineNumbers

try {
  await adapty.logout();
  console.log('User logged out successfully');
} catch (error) {
  console.error('Failed to logout user:', error);
}
```

その後、`.identify()`メソッドを使ってユーザーをログインできます。

## `appAccountToken`を設定する（iOS） \{#assign-appaccounttoken-ios\}

[`appAccountToken`](https://developer.apple.com/documentation/storekit/product/purchaseoption/appaccounttoken(_:))は、App Storeのトランザクションを内部ユーザーIDにリンクするための**UUID**です。  
StoreKitはこのトークンをすべてのトランザクションに関連付けるため、バックエンドがApp StoreのデータをユーザーIDと照合できます。

ユーザーごとに生成した安定したUUIDを使用し、同じアカウントに対してデバイスをまたいで再利用してください。
これにより、購入とApp Storeの通知が正しく紐付けられます。

トークンは2つの方法で設定できます。SDKのアクティベーション時、またはユーザーを識別する際です。

:::important
`appAccountToken`は必ず`customerUserId`と一緒に渡す必要があります。
トークンのみを渡した場合、トランザクションに含まれません。
:::

```typescript showLineNumbers
// During configuration:
await adapty.activate({
    apiKey: 'YOUR_PUBLIC_SDK_KEY',
    params: {
        customerUserId: 'YOUR_USER_ID',
        ios: { appAccountToken: "YOUR_APP_ACCOUNT_TOKEN" },
    }
});
// Or when identifying users
await adapty.identify({
    customerUserId: 'YOUR_USER_ID',
    params: {
        ios: { appAccountToken: 'YOUR_APP_ACCOUNT_TOKEN' },
    }
});
```

### 難読化されたアカウントIDを設定する（Android） \{#set-obfuscated-account-ids-android\}

Google Playでは、ユーザーのプライバシーとセキュリティを強化するために、特定のユースケースで難読化されたアカウントIDが必要です。これらのIDにより、Google Playはユーザー情報を匿名のまま購入を識別できます。これは不正防止や分析において特に重要です。

アプリが機密性の高いユーザーデータを扱う場合や、特定のプライバシー規制に準拠する必要がある場合は、これらのIDを設定する必要があります。難読化されたIDにより、Google Playは実際のユーザー識別子を公開せずに購入を追跡できます。

```typescript showLineNumbers
// During configuration:
await adapty.activate({
  apiKey: 'YOUR_PUBLIC_SDK_KEY',
  params: {
    android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' },
  }
});
// Or when identifying users
await adapty.identify({
    customerUserId: 'YOUR_USER_ID',
    params: {
        android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' },
    }
});
```

## デバイスをまたいだユーザー検出 \{#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()`完了後にアクセスが欠落している場合のデバッグなど、強制的に新しいレシートチェックを行う場合にのみ使用してください。