> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# エンティティのライフサイクル：ユーザーと企業のステータス

> Diditのユーザー・企業エンティティの状態と遷移を解説します。作成、認証、ACTIVE/FLAGGED/BLOCKED間の遷移、削除までを網羅。API呼び出しごとの従量課金です。

ユーザーおよび企業の各エンティティは、Didit内で予測可能なライフサイクルをたどります。このライフサイクルを理解することが、オンボーディング、継続的なモニタリング、是正対応のフローを設計するうえでの鍵となります。

## ライフサイクル図

```mermaid theme={null}
stateDiagram-v2
    [*] --> ACTIVE: Created (API, console, or auto from session)
    ACTIVE --> FLAGGED: Rule match / analyst review / suspicious pattern
    FLAGGED --> ACTIVE: Analyst clears / remediation completed
    ACTIVE --> BLOCKED: Session declined / manual block / blocklist match
    FLAGGED --> BLOCKED: Investigation concludes blocked
    BLOCKED --> ACTIVE: Manual unblock (analyst only)
```

## ステータスの詳細

| ステータス | 意味 | 適用される制御 |
| - | - | - |
| `ACTIVE` | デフォルト。エンティティは良好な状態です | 新しいセッションと取引は、設定済みのワークフローとルールに従って処理されます |
| `FLAGGED` | エンティティにレビューが必要な未解決の問題があります | 新しいセッションは引き続き処理されますが、デフォルトで`IN_REVIEW`になります。取引はルールに応じて自動的にエスカレーションされる場合があります |
| `BLOCKED` | エンティティはプラットフォームからブロックされています | 新しいセッションは自動的に却下されます。新しい取引も自動的に却下されます。この`vendor_data`に対して新しいセッションリンクは作成できません |

> [!NOTE]
>
> `PATCH /v3/users/{vendor_data}/update-status/`または`PATCH /v3/businesses/{vendor_data}/update-status/`でステータスを変更すると、Webhook(`user.status.updated`/`business.status.updated`)が送信されるため、下流のシステムがリアルタイムで対応できます。

## ライフサイクルのフェーズ

**1. 作成**

エンティティは次の3つの方法のいずれかで作成されます。

* 新しい`vendor_data`でセッションを開始すると**自動作成**されます。エンティティは`ACTIVE`ステータスで作成されます。
* `POST /v3/users/create/`または`POST /v3/businesses/create/`を使用して**APIで事前作成**します。ステータスはデフォルトで`ACTIVE`になります。
* コンプライアンス担当者が**コンソールで作成**します。担当者が別のステータスを指定しない限り、ステータスは`ACTIVE`となります。

すべてのエンティティには、Diditが生成する`uuid`と、顧客が管理する`vendor_data`識別子が付与されます。

**2. 検証**

セッションは`vendor_data`を介してエンティティに紐付けられます。各セッションは、設定済みの[ワークフロー](https://docs.didit.me/ja/console/workflows.md)に従って実行されます。本人確認、ライブネス検知、顔照合、AML、書類、KYBの法人登記照会などです。

完了したセッションにより、エンティティの集計カウンターが更新されます。

* `session_count`、`approved_count`、`declined_count`、`in_review_count`
* `features`マップ:すべてのセッションにおける各機能の最新ステータス(例:`{ "id_verification": "APPROVED", "aml": "IN_REVIEW" }`)
* プロフィールのフィールドは、最新の承認済みセッションから反映されます(例:`full_name`、`date_of_birth`、`portrait_image`)。

**3. 利用中**

エンティティに承認済みのセッションが1件以上あれば、次のことができます。

* 取引のペイロードで`vendor_data`を指定してエンティティを参照し、**取引を送信**する
* **継続的なAMLモニタリングを実行**する:制裁、PEP、ネガティブメディアの各リストを定期的に再スキャンします
* **スケジュールに沿って再検証**する:同じ`vendor_data`に対して定期的に新しいセッションを作成します
* セッションと取引をまたいで**リスクシグナルを集約**する

**4. ステータスの遷移**

エンティティのステータスは、自動または手動で変更されます。

**自動遷移**

* セッションが`DECLINED`となり、ワークフローが自動ブロックに設定されている場合は`ACTIVE → BLOCKED`。
* 取引がレビューのしきい値を超えた場合、またはルールによりエンティティがウォッチリストに追加された場合は`ACTIVE → FLAGGED`。
* 顔の生体情報がブロックリストのエントリと一致した場合は`ACTIVE → BLOCKED`。

**手動遷移**は、アナリストがコンソールからステータスを変更した場合、または`update-status`エンドポイントを呼び出した場合に発生します。

すべての遷移で、`user.status.updated`または`business.status.updated`のWebhookが送信されます。

**5. 削除**

エンティティは`POST /v3/users/delete/`または`POST /v3/businesses/delete/`(一括)で削除します。エンティティのレコードは完全に削除されます。ユーザーを削除すると、セッション削除後も保持されていたそのユーザーの[生体認証テンプレート](https://docs.didit.me/ja/management-api/biometric-templates/overview.md)もすべて消去されるため、その人物は重複検出や顔検索で一致しなくなります。

これらのエンドポイントは本人確認セッションを対象としておらず、取引も対象外です。セッションは[セッションの削除](https://docs.didit.me/ja/sessions-api/delete-session.md)または[セッションの一括削除](https://docs.didit.me/ja/management-api/sessions/batch-delete.md)で削除し、取引はコンソールから削除します。

## アクティビティのタイムスタンプ

エンティティはアクティビティを追跡し、休眠中またはアクティブなプロフィールを特定するのに役立ちます。

| タイムスタンプ | 更新されるタイミング |
| - | - |
| `first_session_at` | このエンティティに対して最初のセッションが作成されたとき |
| `last_session_at` | 最新のセッションが作成または更新されたとき |
| `last_activity_at` | セッション、取引、ステータス変更、プロフィール更新など、何らかの変更が発生したとき |

これらのタイムスタンプを使用して、休眠中のエンティティを絞り込んだり、再検証をスケジュールしたり、継続的なモニタリングをトリガーしたりできます。

## ライフサイクル中に送信されるイベント

| ライフサイクルのフェーズ | 送信されるWebhook |
| - | - |
| 作成(セッションからの自動作成) | `status.updated`(セッション)、`user.data.updated`または`business.data.updated` |
| 検証 | `status.updated`(セッション)、`data.updated` |
| ステータス変更 | `user.status.updated`または`business.status.updated` |
| 取引の送信 | `transaction.created` |
| 取引のステータス変更 | `transaction.status.updated` |

ペイロードの構造と配信の仕組みについては、[エンティティのWebhook](https://docs.didit.me/ja/entities/webhooks.md)を参照してください。

## 次のステップ

> [card] [vendor\_dataによる紐付け](https://docs.didit.me/ja/entities/vendor-data-linking.md)
>
> `vendor_data`がセッション、取引、エンティティをどのように結び付けるかを説明します。

> [card] [ユーザーの操作](https://docs.didit.me/ja/entities/users/operations.md)
>
> ユーザーエンティティの作成、更新、ステータス変更、削除を行います。

> [card] [企業の操作](https://docs.didit.me/ja/entities/businesses/operations.md)
>
> 企業エンティティの作成、更新、ステータス変更、削除を行います。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.