はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴概要
本人確認レポートは、政府発行の身分証明書(パスポート、IDカード、運転免許証、居住許可証)からDiditが抽出・検証したすべての情報をまとめたものです。OCRで読み取った個人情報フィールドと書類フィールド、撮影したメディアへの署名付きURL、解析およびジオロケーション済みの住所データ、面ごとの画像品質スコア、MRZの内容、複数文字体系(ラテン文字/非ラテン文字)の内訳、セッションをまたいだ書類の照合結果が含まれます。 このレポートは、ユーザーがワークフロー内の書類撮影ステップを完了した後(またはスタンドアロンのOCRエンドポイントを呼び出した後)に生成されます。Diditは書類の種類を識別し、OCRを実行し、MRZ/バーコード/QRコードを検証し、住所を解析し、改ざん(画面撮影、印刷コピー、顔写真の改変)を検出したうえで、アプリケーション内で撮影された他のすべての書類と照合します。 各レポートは、セッション全体のステータスとは独立した独自のstatusを持ち、IDステップ単体の結果を反映します。
- 承認済み: 書類が認識され、必須フィールドがすべて抽出され、却下に振り分けられる警告が発生していない状態です。
- レビュー中: 1つ以上の警告が発生し、ワークフローでそれらがレビューに振り分けられている状態です。
- 却下: 自動却下の条件(未対応の書類、期限切れの書類、顔写真の欠落、ブロックリストへの一致、適応型年齢チェックの不合格)が発生したか、設定されたアクションが「却下」である警告が発生した状態です(最低年齢/最高年齢はデフォルトで「却下」)。
- 期限切れ: 書類の
expiration_dateで示される有効期限が、検証の後に過ぎた状態です。Diditの継続的な有効期限モニタリングにより、レポートはApprovedからExpiredに切り替わり、DOCUMENT_EXPIRED警告が追加され、承認済みのセッションはKyc Expiredセッションステータスに移行します。 - 未完了: ユーザーが撮影ステップを完了していない状態です。
APIレスポンス内での位置
IDレポートはid_verifications[]配列に含まれて返されます。これは常にJSON配列であり、単一のid_verificationオブジェクトになることはありません。ワークフローで複数の書類ステップが実行される場合(例: 主な本人確認書類に加えてステップアップを行う場合)、複数のエントリが含まれます。
- セッション判定API:
GET /v3/session/{sessionId}/decision/はトップレベルでid_verifications[]を返します。セッション判定の取得を参照してください。 - Webhook:
session.status.updatedのペイロードには、ステップでデータが生成された時点で同じid_verifications[]配列が含まれます。Webhookを参照してください。 - スタンドアロンOCR API: 書類を直接送信すると、同じフィールドを持つ単一の
id_verificationオブジェクトが返されます。OCRスタンドアロンAPIを参照してください。
response.id_verifications[0]を読み取り、配列を反復処理してください。単一のid_verification形式はスタンドアロンOCR APIにのみ存在し、v3の判定エンドポイントには存在しません。スキーマ
フィールドごとの正式なスキーマはデータモデルのリファレンスページにあります。以下のフィールドはIDVerificationV3Serializerからそのまま取得したものです。このシリアライザーはIDVerificationV2Serializerを拡張し、node_id、セッション横断のmatches[]配列、Silent Captureのdocument_selfie_face_matches[]配列を追加しています。
トップレベルのフィールド
issuing_stateは常に国レベルであり、州などの下位区分になることはありません。
州や県が発行する運転免許証(オーストラリア、米国、カナダ)を含むすべての書類種別で、
issuing_stateとissuing_state_nameは州ではなく国を示します
(例: AUS / Australia)。書類に下位区分の値が記載されている場合、
その値はparsed_address.regionで別途取得できます(一部の書類種別では
extra_fields.stateにフォールバックします)。Business
Consoleのセッション概要では、この値がある場合、発行国の下に
Region行として表示されます。2つの番号が記載された運転免許証(オーストラリア)。 オーストラリアの運転免許証には、
保有者の運転資格を識別し、カードを再発行しても変わらない免許番号と、
物理的なカードを識別し、再発行のたびに変わるカード番号の両方が記載されています。
これらの免許証について、Diditは常に次のように番号を対応付けます。
personal_number: 免許番号document_number: カード番号
document_numberとpersonal_numberの両方として返されます。
そのため、認証が完了した時点でdocument_numberには必ず識別子が入ります。
いずれの場合もpersonal_numberは免許番号です。その他の書類種別では、document_numberは
引き続きOCRで読み取った主要な番号であり、それ自体が保有者単位の識別子である場合もあります。アルゼンチンのCUILは
extra_fields.tax_numberであり、personal_numberではありません。
アルゼンチンの書類では、CUIL（AFIP、ANSES、信用情報機関がキーとして使用する11桁の識別子）の
印字位置が書類ごとに異なります。さらにDNIには、その横にもう1つ11桁の番号が印字されています。- 運転免許証では、
personal_numberに格納されるのがCUILです。 - DNIでは、
personal_numberにはnúmero de trámiteが格納されます。これはカードの申請を識別する番号であり、 所持者の識別子ではありません。 DNIのCUILは、専用の印字フィールドから読み取られます。
personal_numberはCUILとして信頼できません。DNIでは11桁の番号ですが、
どの登録機関に照会してもエラーなしで結果が返ってこない番号です。
代わりにextra_fields.tax_numberを読み取ってください。Diditは、値が実在のCUILとして検証できた場合
（個人用プレフィックスとモジュラス11のチェックディジット）に限り、区切り文字のない正規化された数字
（27111111117）でこの値を返します。所持者が提示したアルゼンチンの書類の種類は問いません。カードのCUILを
読み取れなかった場合、このキーはCUILではない番号で埋められるのではなく、存在しません。
こうしたユーザーに対応するには、2つ目の書類として運転免許証を取得するか、アンケートの回答またはセッションのmetadataでCUILを収集してください。画像品質スコア
front_image_quality_scoreとback_image_quality_scoreは、それぞれ以下を返します。
書類の真正性検知スコア
document_livenessは、書類の真正性検知で測定された内容を、警告が発生したかどうかにかかわらず報告します。警告はスコアがワークフローのしきい値のいずれかを下回った場合にのみ発生するため、このフィールドが導入される前は、承認済みの書類には真正性検知の根拠が一切含まれていませんでした。このフィールドにより、通過したセッションを監査できます。チェックが実行されなかった場合（たとえば書類以外の方法の場合や、セッションログに記録されたモデル障害の場合）はnullになります。
不正タイプ（portrait_replace、printed_copy、screen_replay）ごとに1つのオブジェクトが含まれ、それぞれに以下のフィールドがあります。
bucketはnullになります。過去の結果を再構築するために現在のワークフロー設定が使用されることはありません。書類の評価がまだ完了していない撮影についても同様です。
Business Consoleでは、セッションの本人確認セクションにある書類の真正性検知ブロックに、同じ3行が表示されます。
セッション間の一致
matches[]には、アプリケーション内でこの書類と一致する他の書類が最大5件表示されます。一致の条件は、生年月日と発行国が同じで、氏名の類似度が高いことです。ブロックリストに登録された書類については、さらに書類番号の完全一致が必要です。同じユーザー（同じvendor_data）に属するセッションは除外されます。
各エントリには、session_id、session_number、vendor_data、verification_date、user_details（name、document_type、document_number）、status、is_blocklisted（書類がブロックリストに追加されている場合はtrue）、api_service、署名付きのfront_image_urlが含まれます。
ステータス値
複数の文字体系を持つ書類 (ラテン文字と非ラテン文字)
キルギス、カザフスタン、ロシア、日本、韓国、中国、アラビア語圏、タイなどの一部の書類には、所持者の氏名、住所、出生地がラテン文字の翻字と現地の文字の両方で印字されています。トップレベルのレスポンスにどちらの文字体系を使うかは、ワークフロー(またはスタンドアロンAPI)の設定preferred_charactersで選択します。
もう一方の文字体系の値は、
extra_fields内のサフィックス付きのキーに格納されます: first_name_non_latin、last_name_non_latin、middle_name_non_latin、full_name_non_latin、address_non_latin、place_of_birth_non_latin(または対応する_latinのバリエーション)。
別の文字体系のフィールドが含まれる条件
- 書類に両方の文字体系が実際に存在する場合のみです。名目上「Surname-Kyrgyz (Cyrillic)」とラベル付けされたOCRフィールドがラテン文字のテキスト(ホモグリフまたはラテン文字の翻字)として抽出された場合、それは非ラテン文字の代替値とはみなされず、そのキーは省略されます。
full_name_non_latin(およびfull_name_latin)は、名、ミドルネーム、姓の各要素が揃っている場合、常にそれらから再構成されます。一貫性を保つため、OCRの生の「Full Name」フィールドは無視されます。preferred_characters=latinであるにもかかわらず書類に非ラテン文字のテキストのみが含まれる場合(つまりトップレベルのフィールドが非ラテン文字になる場合)、Diditは翻字処理を実行し、ラテン文字のフォールバックとしてfirst_name_latin、last_name_latin、middle_name_latin、full_name_latin、place_of_birth_latin、address_latinを返します。
last_name_non_latinは含まれていません。抽出すべき本物の非ラテン文字の姓が存在しなかったためです。
例
Approved: 全フィールドを含む問題のないスペインの身分証明書
In Review: QRコードがあるはずの書類でQRコードが検出されない場合
一部を省略しています。実際のレスポンスには、上記に示したすべてのフィールドが常に含まれます。セキュリティに関する注意
書類の画像や動画に対して返される署名付きURLは一時的なもので、限られた有効期間が過ぎると失効します。短期間のみ有効なものとして扱い、必要なものは速やかにダウンロードし、キャッシュしたり公開したりしないでください。通常、アプリケーションに必要なのはstatus、いくつかの個人情報フィールド、および警告のみです。将来の情報漏洩による影響範囲を最小限に抑えるため、保存するデータは可能な限り少なくしてください。