はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴概要
本人確認レポートの警告は、Diditが書類の読み取りと検証の過程で検出したすべての条件を示します。警告はid_verifications[]の各項目にあるwarnings[]配列に格納され(本人確認レポートを参照)、その構成はデータモデル：Warningオブジェクトに記載のとおりです：feature、risk、additional_data、log_type、short_description、long_description、node_id。
すべての警告は3つの層で構成されます。
riskコード：コード内で照合に使える、変わることのない識別子です。log_type：評価時に設定がそのリスクに割り当てたアクションから導出されます。却下 →error、レビュー →warning、それ以外 →informationとなります。- 判定への影響：ワークフローの設定可能なリスクグループによって決まります。同じ
riskコードでも、アプリケーションの設定に応じて承認、レビュー、却下のいずれかに振り分けられます。
自動却下の条件
ワークフローでは、以下のリスクが発生すると、IDレポート(およびセッション)は必ずDeclinedになります。これらは設定で変更できません。
スタンドアロンOCR APIでは、無条件で却下となるリスクは
DOCUMENT_EXPIRED、MINIMUM_AGE_NOT_MET、PORTRAIT_IMAGE_NOT_DETECTED、SCREEN_CAPTURE_DETECTED、PRINTED_COPY_DETECTED、PORTRAIT_MANIPULATION_DETECTED、PUBLIC_DOCUMENT_IMAGE_DETECTEDです。ワークフローでは、最低年齢は設定可能(デフォルトは却下)で、3つの書類ライブネス関連のリスクはしきい値に基づいて判定されます(後述)。
このAPIでは、設定可能なリスクに対して、レビュー判定ではなくDECLINEまたはNO_ACTIONをリクエストパラメーターとして指定します。このAPIが返す可能性のある唯一のレビュー判定は設定できません。要求された書類ライブネスチェックで使用可能なスコアが得られなかった場合、レスポンスはIn Reviewとなり、DOCUMENT_LIVENESS_NOT_COMPUTED警告が付与されます(書類ライブネスを参照)。
設定可能な検証設定
Didit コンソールでは、残りの本人確認リスクが設定グループにまとめられており、それぞれを 承認、確認、拒否 のいずれかに振り分けられます(ワークフローごと、グラフワークフローではノードごとに設定できます):
サイレントキャプチャの重複およびブロックリストに関するリスクは、書類撮影中に撮影されたセルフィーに対する顔検索から生成されます。この検索は、サイレントキャプチャ顔検索(
document_selfie_face_search_enabled)が有効(デフォルト)で、かつライブネスステップで顔検索が無効化されていない場合に実行されます。それ以外の場合、これら6つのリスクはいずれも発生しません。
書類関連リスクのうち2つのファミリーは、承認/確認/拒否の切り替えではなく、しきい値によって判定されます:
- 書類の真正性検知:
SCREEN_CAPTURE_DETECTED、PRINTED_COPY_DETECTED、PORTRAIT_MANIPULATION_DETECTED。不正の種類ごとに拒否と確認のしきい値がそれぞれ設定されています。スコアが拒否のしきい値を下回る場合はerror+ 却下、確認のしきい値を下回る場合はwarning+ レビュー中、それ以外はinformationとなります。 - カメラ間の顔照合:
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY。document_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_thresholdによって制御されます。
書類の真正性検知のしきい値を設定する
ワークフローエディターでは、これらのしきい値は本人確認ステップの 偽造 タブにあり、不正の種類ごとに 肖像の差し替え、印刷したコピー、画面キャプチャ の3枚のカードが用意されています。 各チェックは、書類がどの程度本物らしいかを0 から 100 のスコアで評価します。スコアが高いほど、書類が本物である可能性が高くなります。 カード上の2つの値によって、このスケールが3つの帯に分かれます:
どちらの値を上げてもチェックはより厳しくなり、上の表でその値の1つ上の帯に入るセッションが増えます。値を下げると、通過するセッションが増えます。エディターでは、拒否 の値を 確認 の値より上に設定することはできません。APIを通じて 拒否 の値を 確認 の値より上に設定すると、レビュー中の帯がなくなります。
ワークフローで値が設定されていない場合に使用されるプラットフォームのデフォルト値:
まずはデフォルト値から始め、値は1つずつ変更してください。各カードにはデフォルト値と デフォルトに戻す ボタンが表示されるため、いつでも元に戻せます。また、エディターは次の設定について警告を表示します:
- 確認を
100に設定。 満点のスコアのみが合格となるため、ほぼすべてのセッションがレビュー中になるか却下されます。 - 拒否を
100に設定。 満点のスコアのみが拒否を免れるため、ほぼすべてのセッションが却下されます。 - 両方の値を
0に設定。 どのスコアもフラグが立たないため、チェックは実質的に無効になります。
SCREEN_CAPTURE_DETECTED のみが報告されます。
カメラ間の顔照合も同じ考え方を採用していますが、境界値の扱いが1点異なります。スコアが確認のしきい値と等しい場合も、レビュー中になります。
4つのIDリスクは、設定で変更できず、しきい値にも左右されません。POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLISTは常に確認に振り分けられます。ブロックリストに登録された顔に近いものの、一致が確定していないセルフィーは人が判断すべきものであり、自動的に却下されることも、無視されることもありません。BARCODE_SIGNATURE_INVALIDは常に確認に振り分けられます。これはバーコードに含まれる発行機関の署名が暗号学的検証に失敗した場合にのみ発生するため、偽造が証明されたものが無視される設定は存在しません。DOCUMENT_BACK_SIDE_NOT_AVAILABLEは常に情報扱いであり、判定に影響することはありません。これは提示された書類の特性ではなく、Diditの書類カタログの制約を報告するものであるため、正当な所持者を却下したり確認に回したりする設定は存在しません。
FRONT_CAMERA_CAPTURED_DOCUMENTは常に確認に振り分けられます。
これは、書類のスキャン中にフロントカメラで撮影されたフレームに本人確認書類が写っていて人物が写っていない場合にのみ発生します。そのため、誰が書類を持っていたかについて何も示さない撮影は、必ず人の判断に回されます。
この確認は、書類撮影時のセルフィー照合(is_document_selfie_portrait_match_enabled)が有効な場合に常に行われます。
発生する警告
collect_ocr_logs、書類撮影フロー、process_ocr_logs_and_get_statusと照合して検証済みです。以下の短い説明は、APIが返すshort_description文字列そのままです。
書類の認識と品質
撮影フローでは、フィードバックコード
IMAGE_RESOLUTION_TOO_LOW、DOCUMENT_NOT_FULLY_VISIBLE、IMAGE_QUALITY_TOO_LOW、DOCUMENT_OCCLUSION_DETECTED（指や物体が印字されたテキストを物理的に覆っていると判断された場合）でアップロードを拒否することもあります。いずれもSDKで再撮影を促し、Image Quality設定に従って処理される個別のリスクとしてレポートに記録されます。DOCUMENT_OCCLUSION_DETECTEDとIMAGE_QUALITY_TOO_LOWは同じアクションを共有します。これらは撮影に関するもので、再撮影に成功すると警告は消去されます。覆われたフィールドを判定に反映させるかどうかは、後述する整合性側の別のリスクCRITICAL_FIELD_OCCLUSION_DETECTEDが扱います。これは判定時に発生し、デフォルトはReviewです。フィールド抽出
MRZ・QR・バーコード
MRZの信頼性が低いことがわかっている書類タイプでは、3つのMRZリスクはいずれもスキップされます。バーコードの署名検証は現在、フランスの国民IDカードを対象としています。このカードのANTS 2D-Docバーコードには発行機関が署名しています。
BARCODE_SIGNATURE_INVALIDが発生するのは、署名チェック自体がペイロードを拒否した場合のみです。署名のないバーコード、まだDiditのトラストストアに登録されていない機関が署名したバーコード、または署名をデコードできないバーコードは、認証されていないデータとして扱われ、従来どおりMRZや印字テキストと照合して検証されます。この場合、このリスクは発生しません。米国およびカナダの運転免許証（AAMVA）のバーコードは暗号学的に検証されません。これらの地域ではデジタル署名は任意かつ管轄区域ごとに異なり、検証用の鍵を公開している管轄区域もないため、Diditはペイロードに署名が含まれているかどうかを検出してログに記録するだけで、署名自体は一切チェックしません。現時点では、AAMVAの署名の失敗はリスクシグナルではありません。改ざんされたAAMVAのペイロードはBARCODE_VALIDATION_FAILEDとしてのみ表面化し、それも改ざんによってバーコードがMRZや印字/OCRデータと一致しなくなった場合に限られます。それ以外の点で内部的に整合しているペイロードに偽造署名が付いていても、何のシグナルも出ずに通過します。BARCODE_SIGNATURE_INVALIDが発生しても、ユーザーに再撮影を求めることはありません。ペイロードと一致しない署名は、より良い写真を撮っても解決できないためです。本人情報の照合
書類ライブネス (改ざん)
ワークフローでは、不正の種類ごとにしきい値で判定されます。スタンドアロンのOCR APIでは、これら3つのリスクは無条件で却下となり、リクエストされたチェックで有効なスコアが得られない場合は、承認ではなくIn Reviewを返します。
スコア自体は、警告が発生しなかった場合も含め、すべてのV3レポートにdocument_livenessとして含まれるため、承認済みの書類でも後から監査できます。
撮影チャネルの完全性
log_typeは設定されたアクションに対応します。却下（Decline）の場合はerror、レビュー（Review）の場合はwarning、アクションなし（No action）の場合はinformationです。
推奨アクション：却下されたセッションはインジェクションされたキャプチャとして扱い、本人に物理デバイスの内蔵カメラで再試行するよう依頼してください。
本物の人物でも生じうるシグナルがINJECTION_ATTACK_DETECTEDを発生させることはなく、情報レベルにとどまります。
実際のカメラ映像を中継するアプリ（ウェブカメラとして使用するスマートフォンや、実際のウェブカメラに重ねるエフェクトレイヤーなど）は、インジェクション攻撃として報告されません。
これはインジェクション攻撃の検知であり、プレゼンテーション攻撃の検知（実際のカメラに偽物を提示する攻撃）とは別のものです。
既知の公開書類画像
期待値との不一致
セッションにexpected_detailsを渡すと、一致しないフィールドごとにDiditが不一致の警告を発生させます。これらすべてのルーティングは、1つのグループ設定（expected_details_mismatch_action、デフォルトはレビュー）で制御されます。
各不一致の警告には、
additional_dataに期待値と抽出値が含まれます。
年齢
住所
セッション間の書類一致
上記の警告に加えて、V3のIDレポートにはmatches[]配列が含まれます。これは、アプリケーション内で生年月日と発行国が同じで、氏名が非常に類似している他の書類を最大5件示すものです（ブロックリストに登録された書類については、さらに書類番号の完全一致が必要です）。同じユーザーに属するセッションは除外されます。ブロックリストに追加された書類はis_blocklisted: trueとして表示されます。許可リストに登録された書類も一致には表示されますが、重複ユーザーのアクションはスキップされます。
各一致には、session_id、session_number、vendor_data、verification_date、user_details（name、document_type、document_number）、status、is_blocklisted、api_service、署名付きのfront_image_urlが含まれます。
例
デフォルトのルーティング（information）が設定された設定可能な警告
期限切れの書類による自動却下
ペイロードを含む期待される詳細の不一致
警告の種類
各リスクには、アプリケーションの設定に基づいて重大度が割り当てられます。重大度は次の3種類です。関連情報
- 本人確認レポート：レポートの完全なスキーマとステータス。
- 書類モニタリング：Diditが改ざんやセッション間の重複を検出する仕組み。
- Webhook：IDステップが完了するとすぐに、
session.status.updatedに警告が含まれます。 - データモデル：本人確認：フィールドごとの正式なスキーマ。
- データモデル：Warningオブジェクト：
warnings[]の各エントリの構造。