---
title: "プロファイルの仕組み"
description: "Adaptyがユーザープロファイルをどのように作成・追跡・紐付けするかを理解しましょう — 匿名プロファイル、識別済みユーザー、親/継承プロファイルの関係を含みます。"
---

アプリのすべてのユーザーには、購入履歴・イベント・サブスクリプションの状態を追跡するAdaptyプロファイルが割り当てられます。プロファイルがどのように作成・紐付けされるかを理解することで、インテグレーションのバグを防ぎ、データの断片化を避け、[プロファイル](profiles-crm)セクションのデータを正しく解釈できます。

## プロファイルの作成 \{#profile-creation\}

Adaptyはユーザーがアプリを初めて起動したタイミングで、自動的にプロファイルを作成します。

**Customer User IDがない場合**、プロファイルは匿名になります。以下のタイミングで毎回新しい匿名プロファイルが作成されます：
- ユーザーがアプリを再インストールしたとき
- ユーザーがアプリからログアウトしたとき（アプリが`Adapty.logout()`を呼び出したとき）

購入はアプリのインストールに紐付けられ、永続的なユーザー識別情報には紐付けられません。

**Customer User IDがある場合**、プロファイルは再インストールやデバイスをまたいで維持されます。Customer User IDを使うことで、次のことが可能になります：

1. 再インストールや複数デバイスにまたがってユーザーを追跡できます。
2. [**Profiles**](profiles-crm)セクションでCustomer User IDからユーザーを検索できます。
3. [サーバーサイドAPI](getting-started-with-server-side-api)でCustomer User IDを使用できます。
4. AdaptyはCustomer User IDをすべてのインテグレーションに送信します。

Customer User IDを使用する場合のプロファイルの動作は、いつ設定するかによって異なります：

- **SDKの初期化時**：そのCustomer User IDを持つ既存のプロファイルを使用します（再訪ユーザーの場合）、または新しいプロファイルを作成します（初回ユーザーの場合）。
- **SDK初期化後**：初期化時に匿名プロファイルが作成されます。その後ユーザーを識別すると、AdaptyはCustomer User IDを匿名プロファイルに紐付けます（初回ユーザーの場合）、または既存のプロファイルに切り替えます（再訪ユーザーの場合）。

**どちらのアプローチを使うか：**

- **アプリ起動時にCustomer User IDが利用可能な場合**（例：前回のセッションから保存されている）— SDKの初期化時に`activate()`へ渡します。
- **ユーザーがアプリ起動後にサインインする場合**— 認証後に`identify()`を呼び出します。AdaptyはそのIDを現在のプロファイルに紐付けます（IDが新規の場合）、または既存のプロファイルに切り替えます（IDが既に存在する場合）。
- **ログイン前に購入できる場合**— ログイン後に`identify()`を呼び出します。Customer User IDがAdaptyに既に存在する場合は、その後プロファイルを取得して現在のアクセスレベルを同期してください。

実装の詳細については、[ユーザーの識別](identifying-users)SDKガイドを参照してください。

:::note
以前にCustomer User IDなしでアプリを使用したことがある再訪ユーザーの場合、SDK初期化時に識別を開始しても、それらの匿名プロファイルは自動的にマージされません。そのようなユーザーの完全な履歴を維持するには、ログイン後に`identify()`を使用してください。
:::

## 親プロファイルと継承プロファイル \{#parent-and-inheritor-profiles\}

同じストア側のサブスクリプションが複数のAdaptyプロファイルに関連付けられている場合、Adaptyはそれらのプロファイルをチェーンとして扱います：1つの**親**プロファイルと、同じ購入からアクセスを共有する1つ以上の**継承**プロファイルです。

これは以下の場合に発生します：

- [ユーザーアカウント間での有料アクセスの共有](sharing-paid-access-between-user-accounts)が有効で、別のプロファイルが購入したデバイスにユーザーがサインインしたとき。
- ユーザーが`customer_user_id`なしでアプリを再インストールし、新しいプロファイルが前のインストールの購入を引き継いだとき。
- 異なる識別済みユーザーが同じデバイスで購入を復元したとき。
- アプリがApple Team IDを変更し、新しいアプリが旧Team IDで行われた購入を引き継いだとき。

**親の決定方法。**

親は**最初に購入を記録したプロファイル**です — プロファイルの作成順ではなく、Adaptyでの購入レシートの順序によって決定されます。例：アプリをインストールして購入せず、再インストールしてサブスクリプションを購入した場合、2番目のプロファイルが親になります（購入を行ったため）。最初のプロファイルは継承プロファイルとなり、共有によってアクセスを得ます。

**イベントの分配方法：**

- **トランザクションイベント**（購入、更新、キャンセル、請求の問題、グレース期間、返金）：購入を行った**親プロファイル**にのみ表示されます。サブスクリプションの更新・変更はすべてこのプロファイルに表示され続けます。
- **`access_level_updated`イベント**：アクセスレベルの状態が変化するたびに、**親プロファイルと継承プロファイルの両方**に表示されます。これにより、紐付けられたすべてのプロファイルが現在のアクセス状態を把握できます。

親プロファイルには完全なトランザクション履歴が表示されます。継承プロファイルには、アクセスレベルの更新のみが表示され、**Access level**セクションに親プロファイルへのリンクが表示されます。

  <img src="/assets/shared/img/98d0dad-non-original_profile.webp"
  style={{
    border: '1px solid #727272',
    width: '700px',
    display: 'block',
    margin: '0 auto'
  }}
/>

**複数のプロファイルにまたがる同一サブスクリプションの追跡。**

各継承プロファイルは独自の`profile_id`を持つため、`profile_id`はチェーン全体で一定ではありません。複数のプロファイルにまたがって同じサブスクリプションを特定するには（例：Webhookイベントの照合や、ダッシュボードのプロファイルと1人のユーザーの対応付け）、ストア側の識別子を使用してください。

| フィールド | 用途 |
| --- | --- |
| `store_original_transaction_id` | プロファイルをまたいだサブスクリプションチェーンの識別。Appleのサブスクリプションごとに一意。 |
| `profiles_sharing_access_level`（Webhookフィールド） | 共有が有効な場合に、そのサブスクリプションによって権限を付与されているすべてのプロファイル。 |
| `profile_id` | クロスプロファイル追跡には**不適切** — 各継承プロファイルが独自のIDを持つため。 |

## プロファイルなしのトランザクション \{#transactions-without-profiles\}

Adaptyの一部のトランザクションはプロファイルに紐付けられていません — アナリティクスとエクスポートには表示されますが、プロファイルリストには表示されません。これは、Adapty SDKを通じてアプリに接続したことがないユーザーへの**サーバー間（S2S）ストア通知**が届いた場合に発生します。既知の発生源は以下の通りです：

- App Store S2S通知（返金イベントを含む）
- Google Play S2S通知
- StripeおよびPaddleのWebhookイベント

これらのトランザクションは：

- **アナリティクスチャートに表示されます**（全体の指標にカウントされます）
- **エクスポートに表示されます**（S3、GCS、BigQuery）— `profile_id`は`null`に設定されます
- **プロファイルリストには表示されません** — 紐付けるプロファイルが存在しないため

アナリティクスやエクスポートで、プロファイルUIで見つけられるより多くのイベントが表示される場合、その差はおそらくこれらのプロファイルなしトランザクションによるものです。エクスポートで見つけるには、`profile_id IS NULL`の行でフィルタリングしてください。

## ユーザーアカウント間での有料アクセスの共有 \{#sharing-paid-access-between-user-accounts\}

:::link
メイン記事: [ユーザーアカウント間での有料アクセスの共有](sharing-paid-access-between-user-accounts)
:::

アクセスレベルの共有ポリシーを設定するには、[**General**](general)設定ページで共有オプションを選択します。[サンドボックス環境](test-purchases-in-sandbox)に対して別のポリシーを設定することもできます。

---
no_index: true
---

**有効（デフォルト）**

識別済みユーザー（[Customer User ID](identifying-users#set-customer-user-id-on-configuration)が設定されているユーザー）は、同じApple/Google IDでサインインしているデバイスであれば、Adaptyが提供する同じ[アクセスレベル](access-level)を共有できます。これは、ユーザーがアプリを再インストールして別のメールアドレスでログインした場合でも、以前の購入へのアクセスを維持できるため便利です。このオプションでは、複数の識別済みユーザーが同じアクセスレベルを共有できます。

アクセスレベルは共有されますが、過去および将来のすべてのトランザクションは、一貫したアナリティクスを維持し完全なトランザクション履歴（トライアル期間、サブスクリプション購入、更新など）を同じプロファイルに紐付けるため、元のCustomer User IDのイベントとして記録されます。

**新しいユーザーへアクセスを移譲**

識別済みユーザーは、デバイスが同じApple/Google IDでサインインしている限り、別の[Customer User ID](identifying-users#set-customer-user-id-on-configuration)でログインしたりアプリを再インストールしたりしても、Adaptyが提供する[アクセスレベル](access-level)を引き続き利用できます。

前のオプションとは異なり、Adaptyは識別済みユーザー間で購入を移譲します。これにより購入済みコンテンツへのアクセスが保証されますが、一度にアクセスできるのは1人のユーザーのみです。たとえば、UserAがサブスクリプションを購入し、同じデバイスでUserBがログインしてトランザクションをリストアした場合、UserBがサブスクリプションへのアクセスを取得し、UserAからはアクセスが取り消されます。

いずれかのユーザー（新しいユーザーまたは古いユーザー）が識別されていない場合でも、Adapty内でそれらのプロファイル間でアクセスレベルは共有されます。

アクセスレベルは移譲されますが、過去および将来のすべてのトランザクションは、一貫したアナリティクスを維持し完全なトランザクション履歴（トライアル期間、サブスクリプション購入、更新など）を同じプロファイルに紐付けるため、元のCustomer User IDのイベントとして記録されます。

**新しいユーザーへアクセスを移譲**に切り替えた後、アクセスレベルはすぐにはプロファイル間で移譲されません。特定のアクセスレベルの移譲プロセスは、サブスクリプションの更新、リストア、またはトランザクションの検証など、ストアからのイベントをAdaptyが受信したときにのみトリガーされます。

**無効**

最初にアクセスレベルを取得した識別済みユーザープロファイルが、それを永続的に保持します。これは、ビジネスロジック上、購入を単一のCustomer User IDに紐付ける必要がある場合に最適なオプションです。

なお、匿名ユーザー間ではアクセスレベルは引き続き共有されます。

[オーナーのユーザープロファイルを削除する](https://adapty.io/docs/ja/api-adapty/operations/deleteProfile)ことで、購入の紐付けを解除できます。削除後、アクセスレベルは最初にそれを要求したユーザープロファイル（匿名または識別済みを問わず）に付与されます。

共有の無効化は新しいユーザーにのみ影響します。すでにユーザー間で共有されているサブスクリプションは、このオプションを無効にした後も共有され続けます。

:::warning

AppleとGoogleは、購入をApple/Google IDに紐付けているため、ユーザー間でアプリ内課金を共有または移譲することを求めています。共有がなければ、その後の再インストール時に購入のリストアが機能しない可能性があります。

共有を無効にすると、ログイン後にユーザーがアクセスを取り戻せなくなる場合があります。

共有の無効化は、ユーザーが購入前に**ログインを必須とする**場合にのみ推奨します。そうでない場合、識別済みユーザーがサブスクリプションを購入した後に別のアカウントにログインすると、アクセスを永続的に失う可能性があります。
:::

### どの設定を選べばよいですか？ \{#which-setting-should-i-choose\}

| アプリの条件                                                    | 選択するオプション                                             |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| ログインシステムがなく、AdaptyのみMatch anonymous profile IDを使用している。 | デフォルトオプションを使用してください。3つのオプションすべてで、匿名プロファイルID間ではアクセスレベルが常に共有されます。 |
| オプションのログインシステムがあり、アカウント作成前に購入できる。 | **新しいユーザーへアクセスを移譲**を選択してください。アカウントなしで購入したユーザーが後でトランザクションをリストアできるようになります。 |
| 購入前にアカウント作成を必須とするが、購入を複数のCustomer User IDに紐付けることを許可している。 | **新しいユーザーへアクセスを移譲**を選択してください。一度にアクセスできるCustomer User IDは1つに限られますが、別のCustomer User IDでログインしても有料アクセスを失わずに済みます。 |
| 購入前にアカウント作成を必須とし、購入を単一のCustomer User IDに厳密に紐付けるルールがある。 | **無効**を選択してください。アカウント間でトランザクションが移譲されないことが保証されます。 |

## 未来の日付のイベントタイムスタンプ（Apple/iOS） \{#event-timestamps-with-future-dates-appleios\}

この動作はApple App Storeに特有のものです。Google Playの通知システムはイベントを事前に送信しません。

プロファイルやインテグレーションのイベントタイムスタンプが未来の日付を示すことがあります。これはAppleが更新イベントを事前に送信するためです。

- **発生理由**：Appleはサブスクリプションが期限切れになる前に自動更新されるようにしており、ユーザーのサービス中断を防ぐためです。詳細はAppleのデベロッパーフォーラムをご覧ください：[Server Notifications for Subscriptions](https://developer.apple.com/forums/tags/app-store-server-notifications)。
- **影響するイベントの種類**：通常、サブスクリプションの更新とトライアルから有料への転換に適用されます。これらのイベントはAppleが事前に通知するため、未来のタイムスタンプを持つ場合があります。
- **その他のイベントの種類**：追加のアプリ内課金とサブスクリプションプランの変更は、事前に予測できないため、実際のタイムスタンプで記録されます。
- **アナリティクスとイベントフィードへの影響**：これらのイベントは、タイムスタンプが過ぎた後にのみ**Analytics**と**Event Feed**に表示されます。未来のタイムスタンプを持つイベントはどちらのセクションにも表示されません。
- **インテグレーションへの影響**：Adaptyはイベントを受信したらすぐにインテグレーションへ送信します。イベントが未来のタイムスタンプを持つ場合、Adaptyはその未来のタイムスタンプをそのままインテグレーションに送信します。

## 次のステップ \{#next-steps\}

- プロファイルダッシュボードを使用してユーザーを検索・管理するには、[プロファイル](profiles-crm)を参照してください。
- アプリでのユーザー識別を設定するには、[ユーザーの識別](identifying-users)SDKガイドを参照してください。
- アクセス共有ポリシーを設定するには、[ユーザーアカウント間での有料アクセスの共有](sharing-paid-access-between-user-accounts)を参照してください。