はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴ホスト型セッション (ユーザー向けフローに推奨)
ホスト型セッションは、ほとんどの連携で推奨されるアプローチです。セッションを作成すると、Diditがユーザーに提示するためのverification_urlを生成します。ユーザーはDiditの最適化されたインターフェースで検証フロー全体を完了し、結果はWebhookまたはAPIで受け取れます。
仕組み
1
セッションを作成する
サーバーからワークフローIDを指定して
POST /v3/session/を呼び出します。Diditはverification_urlとsession_tokenを返します。2
ユーザーに提示する
ユーザーをリダイレクトするか、iframeで埋め込むか、セッショントークンを使ってネイティブSDKを初期化します。
3
ユーザーが検証を完了する
ユーザーはDiditの最適化されたUIで、案内に沿って本人確認書類の撮影、ライブネス検知、その他の追加ステップを進めます。
4
結果を受け取る
Diditが検証の判定をWebhookでサーバーに送信します。または、取得APIでポーリングすることもできます。
セッションを推奨する理由
セッションを使うべき場面
- ユーザーオンボーディング / KYC：新規ユーザーが登録時に本人確認を行う必要がある場合
- 年齢検証：ユーザーが最低年齢要件を満たしていることを確認する場合
- 再検証：既存ユーザーを定期的に再検証する場合
- 生体認証：機密性の高い操作でユーザーが顔による認証を行う場合
- 複数ステップのコンプライアンス：本人確認書類+ライブネス検知+AML+電話番号を一度に行うフローが必要な場合
- エンドユーザーがその場にいて直接操作するあらゆるシナリオ
セッションのエンドポイント
スタンドアロンAPI (サーバー間処理向け)
スタンドアロンAPIを使うと、エンドユーザー向けのUIを介さずに、個々の検証機能をサーバーから直接呼び出せます。データ(画像、書類、氏名)を送信すると、構造化された結果が返されます。仕組み
1
データを送信する
サーバーから、必要なデータ(画像、書類、またはJSONフィールド)を付けてスタンドアロンエンドポイント(例:
POST /v3/id-verification/)を呼び出します。2
結果を受け取る
Diditはリクエストを同期的に処理し、構造化された検証結果をレスポンスで返します。
スタンドアロンAPIを使うべきケース
利用可能なスタンドアロンAPI
本人確認と書類
Document AI
生体認証と顔
コンプライアンスとリスク
銀行口座確認
法人確認 (KYB)
比較一覧
両方を併用できますか
はい。 多くのチームが両方の方式を組み合わせています。- オンボーディングにはセッション: 新規ユーザーは登録時に、ホスト型の検証フロー全体を完了します
- 継続的なモニタリングにはスタンドアロンAML: cronジョブが毎晩、承認済みの全ユーザーを最新のウォッチリストと再照合します
- 重複検出にはスタンドアロン顔検索: 新しいセッションが承認されると、サーバーが顔検索を呼び出して重複を確認します
- オペレーションにはスタンドアロン本人確認: コンプライアンスチームが、例外的なケースのレビューのために書類を手動でアップロードします