メインコンテンツへスキップ

概要

顔検索は1:Nの生体認証検索です。Diditはuser_image内で検出された最も大きな顔を取り出し、アプリケーションの顔検索インデックスと照合します。このインデックスには、認証セッション、保存されたスタンドアロンAPI呼び出し、ユーザープロフィールへ直接アップロードされた顔、ブロックリストと許可リストから登録された顔が含まれます。顔検索は1:1の顔照合とは異なります。顔照合はセルフィーを特定の書類の顔写真と比較しますが、顔検索は「この人物を以前どこかで見たことがあるか」を調べます。 レポートを解析する前に、次の2つの動作を理解しておく必要があります。
  • 却下になるのはブロックリストとの一致のみです。 face_search.statusがDeclinedになるのは、FACE_IN_BLOCKLISTまたはPOSSIBLE_FACE_IN_BLOCKLIST警告が発生した場合のみです。重複一致だけの場合はApprovedが返されます。statusだけでなく、matchesとwarningsも確認してください。
  • 永続化と登録は任意です。 save_api_request=true(デフォルト)の場合、呼び出しはAPIタイプのセッションとして永続化され、検索された顔は顔検索インデックスに登録されます。顔検索の呼び出しで登録された顔は以降の顔検索結果から除外されるため、繰り返し行った検索同士が一致することはありません。単発のクエリにするにはsave_api_request=falseを渡してください。何も保存されず、顔も登録されません。

結果が表示される場所

顔検索はスタンドアロンAPIです。検索結果は同期的に、POST /v3/face-search/のレスポンスでのみ返されます。レスポンスのトップレベルにある単数形のface_searchオブジェクトに含まれます。
複数形のface_searches[]配列はどこにも存在しません。セッション判定エンドポイントのid_verifications[]、aml_screenings[]、liveness_checks[]で使われている複数形配列の規則は適用されません。 save_api_request=true(デフォルト)の場合、呼び出しはAPIタイプのセッションとしても永続化されます。
  • Business Console:セッションがセッション一覧に表示され、検索画像、一致結果、警告を確認できます。
  • GET /v3/session/{sessionId}/decision/:返されたrequest_idをセッションIDとして使うと取得できます。永続化されたデータは、features[]内のFACE_SEARCHエントリとして表示されます。また、保存されたmatches(新たに署名されたmatch_image_url値を含む)とwarningsを持つliveness_checks[]項目としても表示されます。face_searchオブジェクトとしては表示されません。
save_api_request=falseの場合、request_idは一時的な相関用UUIDです。セッションは一切保存されないため、コンソールからも判定エンドポイントからも取得できません。

スキーマ

正式なフィールド表については、データモデルリファレンスの顔検索を参照してください。以下の構造は、エンドポイントが実行時に実際に返す内容を反映しています。
フィールドの補足:
  • matches[]は最大5件です。類似度の下限を上回るエントリが、類似度の降順で並びます。search_type=blocklisted_or_approvedの場合は、ブロックリストのエントリ、許可リストのエントリ、類似度の順に並びます。
  • sourceは、一致した顔がどこから登録されたかを示します。値は次のとおりです。sessionは認証セッションまたは保存されたスタンドアロンAPI呼び出しです。importedはユーザープロフィールに直接アップロードされた顔です。list_entryはいずれかのリストに紐付けられた顔です。retained_templateは、アプリケーションが元のセッションを削除した後に保持した、画像を含まない生体認証テンプレートです。imported、list_entry、retained_templateの一致では、session_id、session_number、status、api_serviceはnullになります。
  • retained_templateの一致にはvendor_user_id、vendor_data、biometric_template_idが含まれます。一方で、match_image_url、user_detailsおよびセッション関連のすべての項目は常にnullです。その顔が生成されたセッションはすでに存在せず、テンプレートは画像も本人情報も保持していないためです。保持テンプレートのis_blocklistedは常にfalseです。ブロックリストに登録された顔は、list_entryの一致として別に報告されます。テンプレートを削除するにはDELETE /v3/biometric-templates/{biometric_template_id}/を使用します。
  • api_serviceは、一致したセッションのスタンドアロンAPIの種類です。大文字で表記されます(例:PASSIVE_LIVENESS)。一致した顔が通常のワークフローの認証セッションに由来する場合はnullになります。
  • user_detailsは、一致したセッションの書類認証から取得されます。source: importedの一致では、代わりにユーザープロフィールから値が設定されます。この場合、full_nameには値が入り、document_type/document_numberはnullになります。本人情報が存在しない場合はnullです(例:ライブネスのみのセッション)。
  • 警告の構造はワークフローの警告より簡略化されています。 node_idはありません。文書化されたレスポンス仕様(FaceSearchResponseSerializer)では、risk、additional_data、log_type、short_description、long_descriptionの5つのフィールドが宣言されています。実行時のペイロードにはこれに加えてfeatureが含まれ、ここでは常に"LIVENESS"です。顔検索の警告を参照してください。
  • 同一ユーザーとの一致は除外されません。 ワークフローの重複検出とは異なり、スタンドアロンエンドポイントは同じvendor_dataを持つ過去のセッションを除外しません。そのため、再訪した正当なユーザーは自身の過去のセッションと一致します。

ステータス値

トップレベルのface_search.statusはwarnings[]から導出されます。一致ごとのstatusは一致したセッションの認証結果を表すもので、トップレベルのステータスとは無関係です。 注:検索画像に検出可能な顔が含まれていない場合、APIはface_searchオブジェクトを構築する前に、HTTP 400と{"error": "No face detected in the image"}を返します。このケースに対応するDeclinedステータスはありません。クレジットが不足している場合は、画像処理の前にHTTP 403が返されます。

例

承認済み (重複一致、ブロックリスト一致なし)

却下 (ブロックリスト一致)

関連ページ

save_api_request=trueの場合、match_image_urlの値は署名付きの短時間だけ有効なURLです。新しいURLを取得するには、返されたrequest_idを使ってセッション判定エンドポイントを再度呼び出してください。save_api_request=falseの場合、これらの値は内部ストレージのパスであり、直接ダウンロードすることはできません。自社側には一致したセッションID、ステータス、similarity_percentageのみを保存し、元の生体画像は保持しないでください。
最終更新日 2026年11月1日