> ## 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：実質的支配者（UBO）と役員の認証

> Diditなら、実質的支配者（UBO）・株主・取締役・役員を1つのKYBフローで認証できます。役割に応じたチェックとKYCセッションの連携に対応。1件あたり$2.00から、契約不要。

**主要人物**は、検証対象の企業に関係するすべての自然人と法人を扱うDiditの統合モデルです。UBO、株主(個人および法人)、取締役、代表者、その他の役員が対象です。1つの主要人物フローですべてを扱えます。役割に応じて検証を振り分け、法人登記から取得した関係者とユーザーが提出した関係者を並べて詳細に比較できます。

> [!NOTE]
>
> 企業エンティティにおける主要人物(役員やUBOがセッションをまたいでどのように集約されるか)については、[企業 → 主要人物](https://docs.didit.me/ja/entities/businesses/key-people.md)を参照してください。

## 仕組み

**1. 登記情報の事前入力(任意)**

ワークフローで登記情報の事前入力を有効にすると、登記確認で抽出されたUBO、株主、役員のうち取得できたものが、主要人物の画面にあらかじめ入力されます。
エンドユーザーは、所有構造の情報がまだ取得待ちの段階でも、提出前に関係者を編集、追加、削除できます。
すでに受信した役員の情報は、所有構造レポートの取得中も引き続き利用できます。
提出前に遅れて届いた結果は、未編集のフィールドを埋め、不足している人物を追加します。編集内容を上書きしたり、削除された関係者を復元したりすることはありません。
開いている編集画面の内容は変わりません。追加の事前入力は、申請者が編集画面を閉じた後に反映されます。
登記情報の事前入力を無効にした場合、申請者が自分で人物を入力し、遅れて届いた結果はこのフォームに反映されません。
提出後に届いた登記データは登記確認の証跡の一部として残りますが、提出済みの人物リストは変更されず、追加の子検証セッションが自動的に作成されることもありません。

**2. ホスト型フローからの提出**

エンドユーザーは、ホスト型の検証フローを通じて主要人物の最終リストを提出します。デフォルトでは、このステップを開発者が呼び出す必要はありません。[セッションの作成](https://docs.didit.me/ja/sessions-api/create-session.md)で発行したURLのKYBフロー内で処理されます。
独自のフロントエンドを使う場合は、[関係者の下書き](https://docs.didit.me/ja/sessions-api/kyb-create-party-draft.md)と[関係者の提出](https://docs.didit.me/ja/sessions-api/kyb-submit-parties.md)のエンドポイントを使用してください。

**3. 役割に応じた検証の振り分け**

提出された各関係者について、Diditはその役割に設定された検証設定を確認します。

* ワークフローの所有比率のしきい値を適用します。設定された割合を下回るUBOと株主は、個別の検証を必要としません。
* 役割でスキップが許可されている場合は、エンドユーザーが設定した「検証をスキップ」フラグに従います。
* KYCが必要な個人の関係者に対して、子のユーザー認証(KYC)セッションを作成します。
* ワークフローでネストされたKYBが有効な場合、法人のUBOに対して子のKYBサブセッションを作成します。

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

必須の子セッションが1つでも進行中の間、主要人物機能のステータスは`Awaiting User`になります。すべての子セッションが完了すると、その結果に基づいてステータスが`Approved`、`Declined`、`In Review`のいずれかに集約されます。

## 収集する役割

主要人物には、以下の役割を1つ以上割り当てられます。1人が複数の役割を同時に持つこともできます(例: 取締役**かつ**株主)。全分類は次のとおりです。

| カテゴリ | 役割 |
| - | - |
| **所有構造** | `ubo`, `shareholder`, `beneficiary`, `settlor`, `protector`, `investor` |
| **ガバナンス・代表** | `director`, `non_executive_director`, `chairman`, `secretary`, `representative`, `authorized_signatory`, `trustee`, `company_officer`, `founder`, `legal_advisor`, `other` |

すべての役割はワークフロー内で個別に設定できます。有効か無効か、KYCを必須とするか任意とするか、どのKYCワークフローに割り当てるか、スキップを許可するかを指定できます。検証の振り分けの詳細は[所有構造](https://docs.didit.me/ja/business-verification/ownership.md)を参照してください。

## 主要人物ごとに収集するデータ

ホスト型フローでは、デフォルトのフィールド一式と、ワークフローで設定した追加のカスタムフィールドの入力を求めます。全一覧は[所有構造 → 収集するフィールド](https://docs.didit.me/ja/business-verification/ownership.md#主要人物ごとに収集するデータ)を参照してください。

## 登記情報の確認

主要人物ステップの前に、エンドユーザーは登記確認で抽出された企業データを確認し、必要に応じて任意のフィールドを編集します。その後、ホスト型フローは次の内容を保存します。

* 登記確認からDiditが正規化した**登記の詳細**(`registry_data`)。
* ユーザーが確認した時刻を示すタイムスタンプ付きの**ユーザー確認済みデータ**(`user_provided_data`)。
* 最上位の企業フィールドに対する正規化された統合ビュー。ユーザー確認済みの値があればそれを使い、なければ登記情報を使います。

モデル全体については[企業データ → 登記データとユーザー提供データ](https://docs.didit.me/ja/business-verification/company-data.md#登記データとユーザー提供データ)を参照してください。

## 判定レスポンスでの構造

提出後、収集された主要人物はKYBの判定内の`key_people_checks[]`に表示され、2つのグループに分かれます。**registry**(プロバイダーが開示した内容)と**submitted**(企業の管理者がフローを通じて確認した内容)です。さらに、UBO KYCの進捗をまとめた`ubo_kyc_summary`が含まれます。詳細は[key\_people\_checksリファレンス](https://docs.didit.me/ja/business-verification/response-schema.md#key_people_checks)を参照してください。

## 再提出時の動作

* **主要人物**と**登記確認**は直接再提出できません。特定の人物を再検証するには、その人物の個別の子KYCセッションを再提出してください。
* 子KYCセッションが再提出されると、親の主要人物機能のステータスは自動的に`Awaiting User`に戻ります。
* 再提出された子セッションが完了すると、親の主要人物機能のステータスは、すべての子セッションのステータスに基づいて再集計されます。
* 削除された子セッション、または本人が開始する前に期限切れになった子セッションは再提出できません。同じ関係者に新しいリンクを発行するには、[関係者を再生成](https://docs.didit.me/ja/sessions-api/regenerate-kyb-party.md)してください。

## 主要人物の認証リンクの有効期間

主要人物の子KYCセッションは、KYBワークフローではなく、その主要人物の役割に設定されたKYCワークフローのセッション有効期限に従います。役割を4週間の有効期限を設定したKYCワークフローに割り当てると、企業セッションの有効期限がそれより短く設定されていても、その人物のリンクは4週間利用できます。

この値はワークフローごとの設定で、1時間から4週間の範囲で指定します（`session_expiration_time`、秒単位）。設定場所は*ワークフロー → \[KYCワークフロー] → 設定*です。

有効期限が切れると、その当事者に対して行える操作が変わります。本人が認証を開始する前に期限切れになったリンクは、セッションが削除された場合と同様に、[主要人物のKYCセッションの再生成](https://docs.didit.me/ja/sessions-api/regenerate-kyb-party.md)で再発行できます。削除されたセッションは、本人がすでに認証を開始または完了していても対象になります。インポートされたセッションは、期限切れを理由に対象となることはなく、削除されている必要があります。削除されておらず、本人がすでに開始しているセッションは、期限切れでは対象になりません。

## 設定オプション

主要人物に関する動作はすべて、Business Consoleでワークフローごとに設定します。

| 設定 | 制御する内容 |
| - | - |
| **登記情報の事前入力** | 登記データをもとに主要人物フォームに事前入力します |
| **追加フィールド（個人）** | 個人の当事者ごとに収集するカスタムフィールド |
| **追加フィールド（法人）** | 法人の当事者ごとに収集するカスタムフィールド |
| **UBO所有権しきい値** | UBOに分類するための最低所有比率 |
| **株主所有権しきい値** | 株主に分類するための最低所有比率 |
| **役割ごとの設定** | 役割ごとに、有効/無効、KYCの必須化、使用するKYCワークフロー、スキップ可否を設定します |
| **法人UBOのネストされたKYB** | 有効にすると、法人UBOごとに専用の子KYBセッションがトリガーされます |
| **検証済み個人の再利用** | 後述の[KYB審査間での検証済み個人の再利用](#kyb審査間での検証済み個人の再利用)を参照してください |
| **当事者にメールで通知** | 各主要人物に認証リンクを自動でメール送信します |

コンソールの*ワークフロー → \[KYBワークフロー] → 主要人物*で設定します。

## KYB審査間での検証済み個人の再利用

ワークフローで**検証済み個人の再利用**が有効な場合（デフォルト）、主要人物は新しいKYB審査に登場するたびにKYCをやり直す必要がありません。Diditは以前のKYB審査で承認済みとなった既存のKYCを探し、新しい子KYCセッションを作成する代わりに、そのKYCを新しい当事者に紐付けます。

> [!NOTE]
>
> これは[再利用可能なKYC](https://docs.didit.me/ja/core-technology/reusable-kyc/overview.md)とは別の仕組みです。再利用可能なKYCでは、*エンドユーザー*が共有/インポート用のトークンを使い、完了済みの1つのセッションを、Diditと連携した別々のアプリケーション間で任意に持ち運べます。このページで説明するKYBの再利用設定は自動で行われ、ワークフローで設定し、単一アプリケーション内の主要人物に限定されます。共有トークンは不要で、エンドユーザーによるアクションも必要ありません。

**照合。** 候補となる一致は、送信された人物の氏名（大文字と小文字を区別せず、前後の空白を除去）を、同じアプリケーションの他のKYB審査の主要人物と比較することで検出されます。これ以外の照合シグナルはありません。書類番号、メールアドレス、電話番号の一致は必須ではなく、確認もされません。綴りの異なる名前、ミドルネームを含む名前、翻字された名前は一致しません。また、まれに同姓同名の別人が一致する場合があります。この点を踏まえて主要人物の結果をレビューしてください。

**範囲。** 照合の対象は、*同じアプリケーション*に属する他のすべてのKYB審査です。現在のKYB審査だけに限定されませんが、組織内の他のアプリケーションは対象外です。A社のUBOとして検証された人物は、両方の審査が同じアプリケーションで実行されている限り、後にB社の取締役として登場した際に一致させることができます。

**対象となるステータス。** 再利用の対象になるのは、当事者の最新の**承認済み**KYCのみです。その名前で**却下**されたKYCがある場合、再利用は完全にブロックされます。当事者にはフラグが付けられ、却下されたKYCに戻るのではなく、新しいKYCが要求されます。**レビュー中**のKYCが候補になることはありません。

**保持。** 照合の対象は、おおむね過去1年以内に作成され、削除されていないKYCセッションのみです。一致するセッションがこの期間外にしかない場合、または本人や組織がそのセッションを削除している場合、対象となる一致は見つからず、通知なしで新しいKYCが要求されます。この処理によって失敗したり、主要人物の送信がブロックされたりすることはありません。

**請求。** 再利用されたKYCが再度請求されることはありません。承認済みのセッションを新しい当事者に紐付けても追加料金は発生せず、請求は元のKYCに対する1回のみです。

```txt Example theme={null}
Company A: Jane Doe submitted as UBO, KYC approved.
Company B (same application): Jane Doe submitted as a director.
"Reuse verified individuals" is enabled, so Company B's Key People
check links Jane's existing approved KYC instead of requesting a
new one - free, and instantly Approved for that party.
```

## 次のステップ

> [card] [所有構造](https://docs.didit.me/ja/business-verification/ownership.md)
>
> 収集されるフィールド、カスタムデータ、法人登記と提出内容の照合。

> [card] [役員と代表者](https://docs.didit.me/ja/business-verification/officers.md)
>
> 主要人物モデルにおけるガバナンス上の役割。

> [card] [レスポンススキーマ](https://docs.didit.me/ja/business-verification/response-schema.md#key_people_checks)
>
> `key_people_checks[]`のフィールド別リファレンス。


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