メインコンテンツへスキップ
Diditの生体認証は、再訪ユーザー向けに合理化された認証体験を提供します。ワークフローは、単純な本人の存在確認のためにライブネスのみのチェックを行う設定にも、保存済みの顔写真と照合して本人をより強く確認するためにライブネスと顔認識を組み合わせる設定にもできます。この柔軟性により、高いセキュリティ水準を保ちながら、手間のない体験を実現します。

​
主な機能

​
高速な再認証

  • 書類のスキャンは不要
  • 数秒で認証を完了
  • ユーザーの手間と離脱を減らす

​
高度なセキュリティ

  • 顔照合1:1と同じニューラルネットワークアーキテクチャを使用
  • アカウント乗っ取りの試みを防止
  • ライブネス検知により、なりすましを防止

​
柔軟な連携

  • Webベースで利用可能
  • 設定可能な照合しきい値
  • 任意のデバイス・IP分析でセキュリティを強化

​
仕組み

セッションの作成

顔照合を有効にしたワークフローで生体認証セッションを作成する場合、Diditはライブの自撮りと比較するための基準となる顔を必要とします。 次の2つの方法があります。
  • ご自身のデータベースから、Base64形式(最大2MB)の**portrait_imageを送信**します。指定した場合は常にこちらが優先されます。
  • portrait_imageを省略し、ユーザーのvendor_dataを渡します。Diditは、そのユーザーについてすでに保存されている顔を、次の順序で解決して自動的に再利用します。
    1. 承認済みのライブネスチェックで撮影された顔
    2. 承認済みの本人確認のePassportチップの写真
    3. 承認済みの本人確認のID書類から切り出した顔写真
    4. 手動で登録されたプロファイルの顔(Users APIまたはコンソールからのアップロード)
再利用されるのは、承認済みセッションの顔(またはご自身で登録した顔)のみです。portrait_imageを省略し、ユーザーに保存済みの顔がない場合、セッションの作成は400で失敗し、メッセージはNo stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first.です。vendor_dataも省略した場合の400のメッセージは、portrait_imageか、保存済みの顔を持つvendor_dataを送信するよう求めるものになります。

ライブ写真の撮影

認証プロセスでは、次のことが行われます。

検証と結果の処理

システムは、ワークフローの設定に基づいて検証を処理します。
ワークフローで顔照合が無効の場合、システムはユーザーのライブネスのみを確認します。基準となる顔は不要で、portrait_imageも必要ありません。チェックに成功すると認証は承認済みとなり、単純な本人の存在確認に便利です。
ワークフローで顔照合が有効の場合(基準となる顔はportrait_imageまたはユーザーの保存済みの顔):
  1. システムはまずライブネスチェックを実行します
  2. ライブネスに合格したら、新しい自撮りを基準となる顔と比較します
  3. **類似度スコア(0–100%)**が生成されます
  4. 設定したしきい値を上回るスコア → 承認済み
  5. しきい値を下回るスコア → 拒否
結果は、APIレスポンス、ビジネスコンソール、Webhookで確認できます。