> ## 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.

# KYB役員・代表者API：主要人物の役割を検証

> Diditの主要人物モデル、複数の役割タグ、AMLスクリーニングで取締役・役員・権限を持つ代表者を検証できます。1件あたり$2.00から。

取締役、役員、代表者は**DiditのKYBモデルでは独立した概念ではありません**。これらはUBOや株主と同じく[主要人物](https://docs.didit.me/ja/business-verification/key-people.md)に含まれ、1人ごとに1つ以上の役割が付与されます。1人の人物が取締役**かつ**株主である場合や、代表者**かつ**署名権者である場合もあります。人物には1つの役割だけでなく、すべての役割が紐づけられます。

## 役割の完全な分類

各主要人物は、次の役割を1つ以上持つことができます。

### ガバナンス / 代表

| 役割 | 説明 |
| - | - |
| `director` | ガバナンス上の責任を負う取締役会のメンバー |
| `non_executive_director` | 日常の経営業務を担わない取締役会のメンバー |
| `chairman` | 取締役会の議長 |
| `secretary` | 管理業務およびコンプライアンス業務を担う会社秘書役 |
| `representative` | 会社の法定代表者または選任された代表者 |
| `authorized_signatory` | 会社を代表して署名する権限を持つ人物 |
| `trustee` | 会社の持分を保有するストラクチャーの受託者 |
| `company_officer` | 一般的な役員 |
| `founder` | 会社の創業メンバー |
| `legal_advisor` | 会社が委任している法律顧問 |
| `other` | 標準の分類に含まれないその他の役割 |

### 所有 / 受益

| 役割 | 説明 |
| - | - |
| `ubo` | 最終実質的支配者。会社を最終的に所有または支配する個人 |
| `shareholder` | 登録株主(個人または法人) |
| `beneficiary` | 信託または類似のストラクチャーの受取人 |
| `settlor` | 信託の委託者 |
| `protector` | 信託のプロテクター |
| `investor` | 正式な株式所有構造に含まれない投資家 |

1人の人物が両方のカテゴリーに該当することもあります。たとえば、取締役かつUBOでもある創業者は、同じ主要人物レコード上に3つの役割を持ちます。

## 複数の役割を持つレコード

各主要人物レコードには役割のリストが含まれ、該当する場合は役割ごとに所有比率や議決権比率が含まれます。取締役かつ株主である人物は、レスポンスでは次のように表示されます。

```json theme={null}
{
  "uuid": "...",
  "name": "Jane Doe",
  "first_name": "John",
  "last_name": "Doe",
  "entity_type": "person",
  "roles": [
    { "role": "director", "ownership_percent": null, "voting_percent": null },
    { "role": "shareholder", "ownership_percent": 15.0, "voting_percent": 15.0 }
  ],
  "kyc_status": "Approved",
  "kyc_session_url": "https://verify.didit.me/..."
}
```

## KYCとの紐付け

各主要人物は、個人のユーザー認証(KYC)セッションに紐付けることができます。役割のワークフロー設定でKYCが必須とされている場合、紐付けは自動的に行われます。システムは子KYCセッションを生成し、(このオプションが有効な場合は)本人に認証リンクをメールで送信し、ステータスを当事者に反映します。

ルーティングロジックの全容は[所有構造 → 役割の設定による認証の制御](https://docs.didit.me/ja/business-verification/ownership.md#役割設定による検証の制御)を参照してください。各当事者に表示されるB2Cで安全に表示できるKYCステータス値(`Approved`、`Declined`、`Pending`)については、[レスポンススキーマ](https://docs.didit.me/ja/business-verification/response-schema.md#companyブロック)を参照してください。

## AMLスクリーニング

特定されたすべての主要人物は、法人確認プロセスの一環として、グローバルなAMLウォッチリストと自動的に照合されます。PEPとの一致は、ガバナンス上の役割において特に重要です。規制対象企業の取締役や署名権者は、PEPリストに掲載されていることがよくあります。詳しくは[企業のAMLスクリーニング](https://docs.didit.me/ja/business-verification/aml.md)を参照してください。

## 認証要否フラグ

各当事者には`requires_verification`フラグがあり、ワークフローがその人物にKYCを求めているかどうかを示します。

| 値 | 意味 |
| - | - |
| `true` | セッションが承認されるには、この人物のKYCが完了している必要があります。 |
| `false` | 人物は特定されAMLスクリーニングも実施されますが、個別のKYCは不要です。 |

どの役割に認証を必須とするかは、*ワークフロー → \[KYBワークフロー] → 主要人物 → 役割ごとの設定*で設定します。一般的なデフォルトは次のとおりです。

* ワークフローのしきい値を超える取締役とUBO → `requires_verification: true`。
* 署名権者と会社秘書役 → 任意。
* 非業務執行の取締役会メンバー → 任意。

## 主要人物のスキップ

人物の認証ができない場合(死亡、連絡不能、過去の人物など)は、`is_skipped: true`を設定できます。設定するのは、ホスト型フロー内のエンドユーザー(役割の設定でスキップが許可されている場合)か、コンソールのアナリストです。スキップされた関係者は認証ゲートの対象から除外されますが、監査のためにレスポンスには引き続き表示されます。

## 複数ソースの相互照合

各主要人物のデータは3つのソースから取得でき、コンソールではこの3つが並べて表示されます。

* **Registry records**:公的な登記簿で開示された情報。
* **User-submitted**:企業の管理者が主要人物フローで確認または追加した情報。
* **Uploaded documents**:定款、株主名簿、委任状からOCRで抽出された氏名。

不一致はセッションの判定に警告として表示されます。

## Businessエンティティへの影響

KYCを通じて主要人物をUserエンティティに紐付けると、[Businessエンティティ](https://docs.didit.me/ja/entities/businesses/overview.md)との永続的な関係が作成されます。これにより、次のことが可能になります。

* 各人物がガバナンスまたは所有の役割を担っているすべての企業を確認する。
* Userのステータス変更(フラグ付き、ブロック)を、その人物が主要人物となっている企業に反映する。
* 特定のKYBセッションとは独立して、紐付けられた各人物に継続的なAMLモニタリングを実施する。

## 次のステップ

> [card] [主要人物](https://docs.didit.me/ja/business-verification/key-people.md)
>
> 主要人物フローの全体像。

> [card] [所有構造](https://docs.didit.me/ja/business-verification/ownership.md)
>
> UBOの特定と所有関係の連鎖。

> [card] [AML](https://docs.didit.me/ja/business-verification/aml.md)
>
> 企業と個人のAMLスクリーニング。


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