メインコンテンツへスキップ
Diditのデータベース検証機能は、各ユーザーの本人情報をその国の公的機関のデータソースと照合します。データソースにはRENAPER(アルゼンチン)、Receita Federal(ブラジル)、Tribunal Electoral(パナマ、生体認証による顔照合付き)、Junta Central Electoral(ドミニカ共和国)などがあります。料金は照会が成功した分だけ請求され、月額の最低利用料金はありません。 database_validations[]の各エントリーは、1件の完全なデータベース検証レポートです。これは、1つの発行国に対してデータベース検証ノードを1回実行した結果にあたります。サービスごとの登録機関の照合結果は、そのエントリー内のvalidations[]サブ配列に格納されます。このページでは、各サービスが返す照合結果、登録機関のソースデータ、生体認証スコアを解析できるよう、JSONの構造を説明します。
一致タイプと登録機関のレスポンスフィールドを示すDiditのデータベース検証レポート

概要

データベース検証レポートは、ワークフローのノードがデータベース検証機能を実行するたびに生成されます。database_validations[]配列の各エントリーは、1つの発行国に対する1回のノード実行を表します。ノードがその国で複数のサービスを実行する場合(例: ブラジルのCPFとCNH)、各サービスはエントリーのvalidations[]サブ配列内の個別の項目として表示されます。各レポートには次の情報が含まれます。
  • 機能全体のstatus。FeatureStatusChoicesの値(Not Finished、Approved、Declined、In Review)です。
  • 集約されたmatch_type(full_match、partial_match、no_match、または利用可能な結果を返したサービスがない場合はnull)。照合方式に従って複数のサービスの結果を集約した値です。
  • issuing_state(ISO 3166-1 alpha-3)と、そこから導出されるvalidation_type(one_by_one、two_by_two、またはnot_enabled。nullになることはありません)。
  • screened_dataブロック。登録機関に送信された、ユーザーが提供したデータです。
  • validations[]配列。結果を返したサービスごとに1件のエントリーがあり、カタログのservice_id/service_name、ベンダーに依存しないoutcome_code、任意のoutcome_detail、フィールドごとのvalidationマップ、登録機関のレスポンスから抽出して整形したsource_dataを含みます。
  • errors[]配列。照会が失敗した場合やスキップされた場合の、サービスごとのエラーです。エラーがない場合、このキーは完全に省略されます。
  • warnings[]配列。検証中に発生したリスクイベントです(データベース検証の警告を参照)。
  • node_id。レポートを生成したワークフローのグラフノードを識別します(V3セッションのみ)。

APIレスポンスでの表示位置

このレポートは、GET /v3/session/{sessionId}/decision/のdatabase_validations[]として表示されます。常にJSON配列であり、単一のオブジェクトになることはありません。配列には、ワークフローのグラフ内にあるデータベース検証ノードごとに1件のエントリーが含まれます。さらに、各エントリーのvalidations[]サブ配列には、結果を返したレジストリサービスごとに1件の項目が含まれます。
値がnullの場合は、データベース検証のステップがまだ実行されていないことを意味します。

スキーマ

フィールドごとの正式なスキーマはデータモデルページに掲載しています。このスキーマはDatabaseValidationV3Serializerによって生成されます。

ステータス値

statusは機能レベルの標準列挙型を使用します(ステータス列挙型を参照)。詳しくはステータス列挙型リファレンスを参照してください。この列挙型にはResub Requestedも定義されていますが、実際にはデータベース検証で生成されることはありません。 ノードごとのカスタムステータスルールは、この基本ステータスに上乗せして適用されます。設定可能なアクションとそのデフォルトについては、データベース検証の警告を参照してください。

結果コード

validations[]の各エントリには、ベンダーに依存しないoutcome_codeが含まれます。値はMATCH、PARTIAL_MATCH、NO_MATCH、DOCUMENT_NOT_FOUND、INVALID_DOCUMENT_FORMAT、INVALID_INPUT、MINOR_BLOCKED、DECEASED、BIOMETRIC_NO_MATCH、BIOMETRIC_IMAGE_UNUSABLE、INCONCLUSIVE、DOCUMENT_SUPERSEDED、REGISTRY_UNAVAILABLE、REGISTRY_ERRORのいずれかです。次の違いに注意してください。NO_MATCHは登録機関がデータを確定的に確認しなかったことを意味し、INCONCLUSIVEは登録機関がどちらとも判断できなかったことを意味します(却下ではなくレビューに回してください)。またBIOMETRIC_IMAGE_UNUSABLEはセルフィーの技術的な問題(再撮影が必要)であり、確定的なBIOMETRIC_NO_MATCHとは異なります。分類の全体像と推奨される対応については、結果コードページを参照してください。

サービスごとに1エントリ

validations[]配列には、結果ペイロードを生成したサービスごとに1つの項目(validationマップ、source_data、outcome_code、またはoutcome_detail)が含まれます。ワークフローが同じ国で複数のサービスを実行する場合(例: ブラジルのCPFとブラジルのCNH)、それぞれが独自のservice_id、outcome_code、source_dataを持つ別々の項目として表示されます。集約値のmatch_typeはすべてのサービスを集計したものです(いずれかが完全一致ならfull_match、そうでなくいずれかが部分一致ならpartial_match、それ以外はno_match)。validation_typeは完全一致した異なるサービスの数から導出されます。詳しくは照合方式を参照してください。

署名付き画像URL

source_data(photo、signature)およびscreened_data(selfie、cnh_qr_code_image、document_image)の画像フィールドは、有効期限のある署名付きURLとして返されます。更新するには判定エンドポイントを再度呼び出してください。上流から受け取った生のペイロードは、意図的にAPI経由では公開していません。

例

承認済み: ブラジルCPFステータス確認 (Receita Federal)

承認済み: アルゼンチンDNI生体認証 (RENAPER)

アルゼンチンでは、RENAPERによる生体認証の顔照合を用いて検証します。レスポンスにはface_match_scoreと、登録機関から返される追加の本人情報フィールドが含まれます。

レビュー中: 登録機関による検証を実行できなかった場合

どのサービスからも有効な結果が返されない場合(必須フィールドの欠落や形式不正、または登録機関に到達できない場合)、match_typeはnullのまま、validation_typeはnot_enabledとなり、COULD_NOT_PERFORM_DATABASE_VALIDATION警告が発行され、データが修正されるまで、この機能のステータスはIn Reviewになります。スキップされたサービスには料金は発生しません。
コンソールのセッション詳細ページで不足しているフィールドを入力してください。保存すると自動的に確認が再実行され、成功すると警告が解除されます。

関連情報

最終更新日 2026年11月1日