メインコンテンツへスキップ
手動レビューは、堅牢な本人確認とKYCコンプライアンスのワークフローに欠かせない要素です。自動システムが警告や不整合を検出したセッションはIn Reviewステータスに移行し、トレーニングを受けたレビュアーが最終判定を下す必要があります。 このガイドでは、ユーザーにやり直しの機会を与えるresubmission機能の使い方を含め、手動レビューの一連の流れを説明します。

​
認証ダッシュボードの概要

手動レビューの認証一覧
認証のテーブルビューには、すべてのセッションが現在のステータス、書類の種類、国などの主要な情報とともに一覧表示されます。セッションのステータスは次のとおりです。
レビュー中のセッションは、自動処理の過程で1つ以上の警告シグナルが発生しています。レビュー待ちのセッションの総数は、認証ダッシュボードの上部に表示されます。

​
効果的な手動レビューの進め方

1

初期評価

任意のセッションをクリックして、セッションの詳細ビューを開きます。
  1. すべての警告を確認する：セッション概要に表示される警告を確認します。これらは手動レビューのきっかけとなった具体的なシグナルです（例：低いライブネススコア、AMLの一致、書類の不整合）。
  2. ユーザーの過去の認証試行を確認する：ユーザーのベンダーデータをクリックしてセッション履歴にアクセスし、過去の認証セッションがあるかどうかを確認します。
  3. セッションイベントのタイムラインを確認する：イベントセクションには、セッション中に実行されたすべてのアクションが時系列で記録されています。
2

書類の確認

Diditの自動システムは、セキュリティ機能の検出、フィールド単位のデータ整合性チェック、MRZ検証、有効期限の確認、画質分析など、包括的な書類検証をすでに実行しています。レビュアーの役割は、フラグが付いた警告を評価し、必要に応じて書類を目視で確認することです。
  1. 書類の警告を確認する：システムが出した具体的な警告を確認します。よくある警告には、フィールド間のデータ不整合、MRZチェックディジットの検証失敗、期限切れの書類、改ざんの疑いなどがあります。
  2. 警告の判断が難しい場合は目視で確認する：改ざんの可能性や画質の低さを示す警告がある場合は、書類の画像を直接確認します。デジタル編集、トリミング、画面キャプチャ、物理的な加工の痕跡がないかを確認してください。
  3. 抽出されたOCRデータを確認する：システムが書類から抽出したデータを確認し、整合性があるかを確かめます。信頼度が低いフィールドはシステムによってハイライト表示されます。
  4. デコードされたQRコードとバーコードを確認する：Document AIが書類上のQRコードまたはバーコードを検出すると、セッションビューでは画像またはPDFプレビュー上にその位置がハイライト表示され、デコードされたペイロードが表示されます。検出されたもののデコードできなかったコードは検出のみとして表示され、ペイロードは示されません。この位置のオーバーレイは書類改ざんの警告ハイライトとは別のもので、警告ハイライトは従来どおりの表示のままです。
  5. 書類の一致を確認する：顔検索または重複検出が有効な場合、このユーザーが過去に別の身元で認証されていないか、または書類がブロックリストに含まれていないかを確認します。
Diditコンソールで書類画像にカーソルを合わせると、ズーム機能を使ってピクセル単位で詳細に確認できます。マイクロ印刷やホログラムを検証する際に特に役立ちます。
3

生体認証とライブネスの検証

Diditは顔照合、ライブネス検知、および有効な場合は顔検索を自動的に実行します。レビュアーの役割は、フラグが付いた場合にその結果を確認することです。
  1. 顔照合スコア：システムはセルフィーと書類の顔写真の間の生体認証類似度スコアを算出します。フラグが付いた顔照合を確認する際は、目の形、鼻の形状、あごのライン、顔の特徴的な痕跡といった構造的な特徴に注目してください。
  2. ライブネス検知スコア：ライブネスシステムは、印刷された写真、画面の再生、ディープフェイク、3Dマスクなどのプレゼンテーション攻撃を検知します。カメラの品質が低い場合や照明が暗い場合、本人であるユーザーでもスコアが低くなることがあります。却下するのではなく、再提出を依頼を検討してください。
  3. 顔検索の結果：一致があれば慎重に確認します。
    • 重複検出：別のセッションとの一致は、同一人物が複数の身元で認証を行っている可能性を示します。
    • ブロックリストとの一致：顔がブロックリストに登録されたユーザーと一致する場合、通常は却下が妥当です。
    • 誤検知：別人同士で顔が似ていることは実際にあります。信頼度スコアを評価し、画像を目視で比較してください。
4

リスクとシグナルの確認

AML、Device & IP Analysis、Database Validationの各セクションを順に確認し、状況に応じたリスクを評価します。
手動レビューにおけるAMLスクリーニングの結果
AML Screening
  • No matches：低リスクです。世界のウォッチリスト、制裁リスト、PEPデータベースのいずれにもヒットしていません。
  • Matches found：一致した各エントリを確認します。真陽性か誤検知かを確認し、一致のカテゴリー（PEP、制裁、ウォッチリスト、ネガティブメディア）を確認したうえで、データの出典と新しさを考慮してください。
  • ラベルだけでなくスコアを使う：セクションヘッダーには、AMLステータスの算出元となった集計リスクスコアが表示されます（誤検知としてマークされていないヒットの中で最も高いリスクスコアであり、ワークフローの承認しきい値およびレビューしきい値と比較されます）。各行にはヒットのMatch score（身元の信頼度）とリスクスコア（エンティティのリスク）が表示され、どちらかにカーソルを合わせると算出方法を確認できます。これらは、連携で判定ペイロードで受け取るscore、match_score、risk_scoreと同じものです。
デバイス・IP分析およびデバイスインテリジェンス
  • 地理的な整合性：書類の発行国、ユーザーが申告した住所、IPアドレスの位置情報を比較します。
  • VPN/プロキシ検出：ユーザーがVPN、プロキシ、またはTorネットワーク経由で接続していないかを確認します。
  • デバイスのメタデータ：デバイスの種類、オペレーティングシステム、ブラウザの情報に異常がないかを確認します。

​
判定を下す

レビューが完了したら、承認、却下、再提出を依頼の3つから選択します。

承認

  • 書類が真正で、改ざんされていないと判断できる
  • すべてのデータフィールドに整合性があり、判読できる
  • セルフィーの生体照合で同一人物であることが確認できる
  • ライブネスチェックのスコアが許容範囲内である
  • 該当するAML、制裁、PEPの一致がない
  • デバイスと位置情報のデータに整合性がある

却下

  • 書類が改ざん、偽造、または加工されていると判断できる
  • セルフィーが書類の顔写真と一致しない
  • 信頼度の高いAMLまたは制裁リストとの一致が確認された
  • プレゼンテーション攻撃の強い兆候がある
  • 身元詐称のパターンが検出された
  • デバイスや位置情報に重大な不整合がある

再提出を依頼

  • 書類の画像がぼやけている、または画質が低い
  • 技術的な問題でライブネスチェックに失敗した
  • 誤った書類が提出された
  • 検証ステップが未完了、または期限切れになっている
  • ユーザーが修正できる問題である
却下理由の選択ダイアログ
セッションを却下する際は、必ず却下理由を選択し、詳細なレビューメモを追加してください。品質保証、規制当局による監査、社内分析に役立ちます。

​
再提出をリクエストする

セッションを明確に承認または却下できない場合(多くは修正可能な問題が原因です)、特定の検証ステップの再提出をユーザーにリクエストできます。

​
再提出をリクエストする方法

1

セッションを開く

Didit Consoleで対象のセッションに移動します。
2

「再提出をリクエストする」を選択する

セッションのステータス操作を開き、Resubmittedを選んでからContinueを選択します。
3

再提出する機能を選ぶ

ダイアログには、承認されていないすべての機能が現在のステータスとともに表示されます。個々のステップを選択または選択解除します。一度も開始されていない機能は自動的に必須になります。
4

必要に応じてメール通知を送信する

ユーザーのメールアドレスが利用できる場合は、再開用の直接リンクを含むローカライズされた通知を送信できます。メールには各ステップの理由が記載されます。書類の期限切れを理由にすべてのステップがリクエストされた場合は、一般的な「もう一度お試しください」ではなく、その旨を伝えて有効な書類の提出を求めます。文面はWhite Label → Textsでロケールごとにカスタマイズできます。
5

プレビューして確定する

Previewを選択すると、受信者、送信者、件名、ローカライズされたメールを確認できます。 ホワイトラベルのセッションでは、設定済みのブランディングと検証済みの送信者が使用されます。 Editを選択するとチェック項目、受信者、言語を変更でき、その後あらためてプレビューを生成します。 Confirmで再提出がリクエストされます。プレビューだけではセッションは変更されず、メールも送信されません。 ユーザーの追加操作なしで自動チェックにより検証が完了した場合、アクションを求めるメールは送信されません。

​
再提出後の流れ

  1. 以前の結果は引き続き閲覧できます: やり直しになるのは選択したステップだけです。それらのステップの以前の結果は過去の提出として扱われます。セッションでは各ステップの提出タブ(“Submission 2 · latest”、“Submission 1”)に表示され、APIではRetrieve Sessionに?include=resubmissionsを付けると返されます。
  2. ユーザーが検証フローに再び入ります: リクエストされた特定のステップだけを完了すれば済みます。
  3. セッションは再提出済みステータスのままになります: In Progressとは区別されるため、再提出中のセッションを個別に追跡できます。
  4. 自動で再評価されます: 再提出されたすべての機能が完了すると、システムが最終ステータスを自動的に再計算します。
  5. 新しいWebhookが送信されます: 更新された最終ステータスを含むWebhookがサーバーに届きます。
同じセッションで再提出を複数回リクエストできます。各リクエストには番号が付けられ、過去の提出はすべて、誰がなぜリクエストしたかとともに引き続き閲覧できます。1つのステップ内での試行(たとえばフローが求めた2枚目の写真)は提出には含まれません。セッションには最新の試行が表示され、Eventsにはすべての試行が一覧表示されます。セッションを削除すると、すべての提出が削除されます。

​
再提出と新しいセッション作成の比較

​
レビューのベストプラクティス

すべてのレビューに同じ基準を適用してください。判断の根拠を記録しておくと、他のチームメンバーがその判定を理解し、同じように再現できます。
写真がぼやけている、または技術的なエラーが問題であれば、再提出を依頼することでセッションを維持でき、正当なユーザーに不要な手間をかけずに済みます。
書類画像は必ず拡大して確認し、通常の倍率では見えない微細な改ざん、マイクロプリント、セキュリティ機能をチェックしてください。
シグナルを個別に評価しないでください。ライブネススコアの低さにVPN接続や位置情報の不一致が重なっている場合、どの要因も単独で見るより懸念が大きくなります。
すべての判定、特に却下について詳細なレビューメモを追加してください。これらのメモは社内の品質保証や規制当局の監査に役立ち、新しいチームメンバーの育成にも活用できます。
セッションがレビュー中ステータスになったときにすぐ通知を受け取れるよう、メールまたはSlackのアラートを設定してください。迅速な対応は、コンプライアンスとユーザー体験の両方を向上させます。
ユーザーが再提出を何度も繰り返している場合は、履歴全体を注意深く確認してください。同じ機能で失敗が繰り返される場合、根本的な問題がある可能性があります。
最終更新日 2026年11月1日