検証が拒否された理由

1つ以上のチェックが失敗すると、セッションは拒否になります。具体的な理由の見つけ方と、拒否・再提出・手動承認のどれを選ぶべきかの判断方法を説明します。

執筆: Didit サポート · 更新日: 2026年8月19日

Short answer

セッションを開き、失敗した個々のチェックにある警告を読んでください。全体の「拒否」というステータスは理由を語りませんが、警告は必ず語ります。ほとんどの拒否は、最終的な却下ではなく再提出で解決できます。

セッションは、1つ以上のチェックが失敗すると拒否とマークされます。具体的な理由は必ずセッションに記録されているため、推測する必要はありません。

#正確な理由を見つける

ビジネスコンソールの検証でセッションを開いてください。セッション上の各チェック（書類、ライブネス、顔照合など）には、それぞれ独自の結果と、発生した警告が表示されます。これらの警告こそが拒否の実際の理由であり、単なる全体ステータスではありません。

Overview、ID Verification、Eventsの各タブを持つ、Diditコンソール内の拒否されたセッション
  1. 拒否理由はOverviewにあります。まずここを読んでください。
  2. 書類の問題はここに表示されます: 期限切れ、読み取り不能、または真正性チェックの失敗。
  3. Eventsには、ルールによる判定か人による判定かが表示されます。
理由はOverviewに、失敗したチェックのタブに詳細があります。

#チェックが失敗するよくある理由

書類の問題

  • IDの有効期限が切れている（DOCUMENT_EXPIRED）。
  • ワークフローが受け付けていない書類タイプである - 非常によくある原因で、ユーザー側の問題ではなく設定上の問題です。詳細は書類タイプが拒否された理由をご覧ください。
  • 必須フィールドを読み取れなかった（COULD_NOT_RECOGNIZE_DOCUMENT）。
  • MRZチェックサムの検証に失敗した（MRZ_VALIDATION_FAILED） - 印字された機械読取領域の整合性が取れておらず、これは実際の改ざんの兆候です。
  • ワークフローが要求する年齢の下限（または上限）を満たしていない（MINIMUM_AGE_NOT_MET）。
  • 書類がブロックリストの登録内容と一致した。

ライブネスの問題

  • 撮影中に顔が検出されなかった。
  • なりすまし攻撃が検出された（LIVENESS_FACE_ATTACK） - 生きた人間の代わりに、写真や画面、マスクがカメラにかざされた。

顔照合の問題

リスクとスクリーニングの問題

  • AMLヒットが拒否閾値を超えた。
  • ブロック対象のIPアドレス、または対応していない国からの接続だった。
  • 顔が、既存の検証済みユーザーやブロックリストの登録内容と一致した。詳細は重複検知をご覧ください。

これらのうちどれが実際に拒否を引き起こすか（再提出の依頼や通過ではなく）は、ワークフロー内で各チェックがどう設定されているかによります。一部の警告は自動で拒否となり、それ以外は手動レビューに回されます。詳細は判定ルールと閾値をご覧ください。

#拒否されたステップがワークフローの残りを止めることがある

あるステップが特定の警告で拒否するよう設定されている場合、ワークフローはそこで止まり、後続のステップは一切実行されません。これには知っておくべき2つの帰結があります。

  • セッション結果には、表示されるはずだったチェックが欠けます。失敗したのではなく、実行されなかっただけです。
  • 実行されなかったステップの料金は発生しません。課金は完了した機能ごとに行われるためです。

安価なチェックで、より高価なチェックをゲートしたい場合は、意図的にそのチェックをワークフローの前段に配置してください。

#拒否は必ずしも最終決定ではない

写真がぼやけている、書類の面を間違えた、撮影中に技術的な障害が起きたなど、根本原因が修正可能なものであれば、レビュアーはセッションを拒否のままにせず、そのステップだけをユーザーにやり直してもらうよう依頼できます。詳細は検証をもう一度試してもらう方法をご覧ください。

Note

拒否された検証でユーザーに表示されるメッセージは、現時点ではどのワークフローでも同じであり、表示内容をカスタマイズすることは現在できません。

#レビュアーが拒否は誤りだと判断した場合

コンプライアンス担当のレビュアーは、コンソールから自動拒否を上書きできます。セッションを開き、理由を記したノートとともにステータスを承認に変更します。すべての上書きは記録されるため、監査証跡には誰が何を判断したかが残ります。レビューの全プロセスについては手動レビューをご覧ください。

#回避可能な拒否を減らす

拒否率が想定より高い場合、通常の原因は不正ではなく設定です。

  1. 書類の許可リストが狭すぎる。 ワークフローが受け付けている書類タイプとサブタイプを、実際にユーザーが保有している書類と照らし合わせて確認してください。
  2. 顔照合の閾値が厳しすぎる。 詳細は顔照合スコアと閾値をご覧ください。
  3. 低スペック端末でのアクティブライブネス。 パッシブライブネスは、古いスマートフォンや悪条件の照明に対してはるかに寛容です。
  4. 誤検知を生むマッチスコアで設定されたAML拒否閾値。 それらはレビューに回してください。詳細はAMLヒットの解決をご覧ください。

#あなたが企業ではなく、拒否された本人である場合

企業から検証リンクを受け取り、拒否された場合、Diditはその企業の代わりに検証を処理しているだけで、判定を下したり、変更したり、説明したりする権限はありません。判定について確認できるのは、検証を依頼した企業のサポートだけです。詳細はDiditで本人確認を求められた場合、およびDiditがどのようにデータアクセスを管理しているかについてはDiditがユーザーのデータを保護する方法をご覧ください。