メインコンテンツへスキップ
セッションは、Diditにおける認証の単位です。認証を開始するとセッションが作成され、認証が完了すると、そのセッションに判定ペイロード全体が格納されます。同じセッションAPIで両方の種類を扱います。 Academyの「ユーザーに表示される内容」に関するレッスンでは、5:34のチャプターでホスト型フローと独自画面の構築を比較検討しています。これはまさに、このAPIによって決まるトレードオフです。

​
種類はワークフローによって決まる

セッションを作成する際には、workflow_idを渡します。ワークフローの種類によって、セッションが本人確認になるか法人確認になるかが決まり、呼び出し側が別途選択することはありません。KYBワークフローでは法人確認セッションが、KYCワークフローでは本人確認セッションが作成されます。

​
session_kindによる種類の判別

作成、取得、一覧取得、ステータス更新、共有、インポートのいずれのセッションレスポンスにも、次のトップレベルフィールドが含まれます。
  • "user"：セッションは本人確認（KYC）セッションです。レスポンスにはユーザー固有の機能のarrayが含まれます。
  • "business"：セッションは法人確認 (KYB)セッションです。レスポンスには企業固有の機能のarrayが含まれます。
お客様側では、このフィールドを使ってレスポンスの構造に応じた処理を切り替えてください。
enum値は短い識別子の"user"と"business"です。APIの使いやすさを考慮して短くしています。ドキュメント全体では、わかりやすさのために正式名称の本人確認（KYC）と法人確認 (KYB)を使用しています。

​
種類ごとの機能配列

判定に含まれる機能配列は種類によって異なります。一方の種類に存在しないフィールドは、そのレスポンスには一切現れません（nullやプレースホルダーも含まれません）。

​
共通のトップレベルフィールド

すべてのセッション（両方の種類）に次のフィールドが含まれます。

​
対象のエンドポイント

以下のエンドポイントはすべて、どちらの種類にも対応しています。/v3/business-session/*のような個別のパスはありません。

​
検索の仕組み

本人確認セッションと法人確認セッションは、それぞれ異なる2種類のセッションです。IDにはUUIDを使用しているため、衝突は起こりません。session_idを指定してエンドポイントを呼び出すと、Diditは次のように処理します。
  1. まず本人確認のテーブルでIDを検索します（トラフィックの大部分はこれで処理されます）。
  2. 見つからない場合は、法人確認のテーブルを検索します。
  3. どちらのテーブルにも一致するものがなければ、404を返します。
どちらの種類を探しているかをAPIに伝える必要はありません。

​
ステータスは両方の種類で共通

ステータス値は両方の種類で同じであり、APIはここに記載されているとおりの表記で返します。"Not Started"、"In Progress"、"Approved"、"Declined"、"In Review"、"Abandoned"、"Expired"、"Kyc Expired"、"Resubmitted"、"Awaiting User"。完全一致かつ大文字と小文字が区別されます。詳細なリファレンスは認証ステータスを参照してください。

​
Webhook

Webhookイベントにはすでにsession_kindフィールドが含まれているため、Webhookハンドラーで種類ごとに処理を振り分けられます。 署名検証と再試行の仕組みについてはWebhookを、法人確認 (KYB)のイベント一覧についてはKYB Webhookを参照してください。

​
次のステップ

セッションの作成

ユーザー認証または企業認証を開始します。

セッションの取得

判定を取得します。両方の種類に対応しています。

セッションの一覧

session_kindでフィルターできます。

ステータスの更新

承認、却下、レビュー、再提出を行います。

PDFの生成

種類ごとのPDFレポートを生成します。

共有とインポート

アプリケーション間でセッションを移動します。
最終更新日 2026年11月1日