判定ルールとしきい値

すべてのチェックは警告を生成し、その警告をどう扱うかはあなたが決めます - 通過、レビュー、または拒否です。そのマッピングにこそ、あなたのリスク許容度が表れます。

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

Short answer

各ステップは、自身の警告をアクションに対応させます。通過、レビュー、または拒否です。拒否するよう設定されたステップはワークフローを停止させます - 後続のステップは実行されず、その分の課金もされません。そのため、ルールの順序はリスクの判断であると同時にコストの判断にもなります。

#判定が実際に決まる場所

ワークフローを「実行するチェックの集まり」と考えたくなります。しかしチェックはその半分にすぎません。もう半分 - そして承認率を左右する半分 - は、各チェックの警告が何をするように設定されているかです。

機能ノードとPublishボタンを備えたDiditワークフロービルダー
  1. 各機能ノードは、それぞれ独自のしきい値と独自の判定を持ちます。
  2. チェックを必須にするか任意にするかも、誰を通過させるかについての判断そのものです。
  3. ワークフローが保存されると、変更したルールが新しいセッションに適用されます。
各ノードが自身の結果を決め、ワークフローがその意味を決めます。

各ステップについて、そのステップが発生させうる警告はそれぞれ、次の3つのアクションのいずれかに対応します。

アクション効果
承認（または無視）警告は記録されるが、結果は変わらない
レビューセッションはIn Reviewになり、人が判断する
拒否セッションは拒否され、ワークフローは停止する

このマッピングこそが、設定として表現されたあなたのポリシーです。

#拒否はワークフローを停止させる

これは人々を最も驚かせる挙動なので、明示的に述べておく価値があります。あるステップが拒否すると、そこで実行が停止します。それ以降のステップは一切実行されません。

結果は2つあります。

  1. 想定していたチェックが結果に含まれません。 失敗したのではなく、実行されなかったのです。ID検証で拒否されたセッションには、ライブネスも顔照合もAMLも含まれません。
  2. それらに対して課金されません。 課金は完了した機能ごとに行われるため、実行されなかったステップにはコストがかかりません。

#ルールの順序でコストを制御する

拒否がフローを止める以上、ステップの順序はコストのレバーになります。高額なチェックの束の前に安価なリスクチェックを置くことで、どのみち通過しなかったはずのトラフィックを、高額な部分に料金を払う前に止められます。

デバイス・IP分析（0.03ドル）を完全なKYCフローの前段に置くのが典型例です。どのみち拒否していたはずのトラフィックを、安価にふるい落とせます。

Important

このトレードオフは、ユーザー体験と誤検知です。デバイスとIPのシグナルは、Diditが提供する中で最もノイズの多いチェックです。企業ネットワーク、キャリアのNAT、クラウドブラウザはいずれも、正当なユーザーを共有アドレスの背後に置いてしまいます。フロー全体をこれらのシグナルでゲートすると、実際の顧客をブロックしてしまうため、自社のトラフィックを測定していない限りは拒否ではなくレビューに振り分けてください。

#自動化ではなく判断が必要なルール

一部の警告は明確で、拒否すべきものです。MRZチェックサムの失敗、発行局への署名チェーンが通らないチップ、ブロックリストに載っている顔などです。これらは整合性の失敗です。

一方、ほぼ常にレビューの方が適しているものもあります。

  • 住所証明における部分的な一致 - 形式は国によって異なります。
  • データベースバリデーションにおける部分的な氏名一致 - 権威あるソースは氏名の記録方法が異なります。
  • 信頼度の低いAML候補ヒット - よくある名前は絶えずこれを発生させます。
  • 境界線上の顔照合 - 顔照合スコアとしきい値をご覧ください。
  • 重複顔フラグ - 新規アカウントであれば不正の兆候ですが、既存顧客の再訪であれば正常です。

そして、判定ではなくリトライにふさわしいユーザビリティ上の失敗もあります。読み取れなかったNFCチップ、ぼやけたキャプチャ、途切れたカメラフレームなどです。

#年齢に関するポリシー

最低年齢と最高年齢はワークフローごとに設定でき、違反時のアクションは自分で選べます。MINIMUM_AGE_NOT_METは即座に拒否することも、ポリシー上証拠付きの例外を認める場合はレビューに送ることもできます。どちらも正当な選択なので、意図的に選んでください。

#抽出データに対するカスタムルール

警告ごとのマッピングに加えて、あるステップが抽出したデータに対してルールを書くこともできます。例えば、抽出されたフィールドが特定の値を取った場合に拒否するなどです。念頭に置くべき点が2つあります。

  • ルールは、そのステップが実際に生成したデータに対してしか動作できません。OCRがそのフィールドを抽出しなかった場合、ルールには評価対象がありません。
  • 拒否するルールも、上記と同じ結果でワークフローを停止させます。

保護対象の属性に基づいてオンにするルールを構築しようとしている場合は、それをエンジニアリングの問題として扱う前に、コンプライアンスチームに相談すべき法的な問題として扱ってください。

#ステップだけでなくルールもテストする

ワークフローのステップは目で見て簡単に確認できます。ルールはそうではありません。警告が思った通りに振り分けられているかを知る唯一の方法は、その警告を実際に発生させることです。

サンドボックスはまさにこのために存在します。各シナリオは特定の警告を1つ強制的に発生させるため、decline_document_expired、review_face_match_borderline、decline_aml_hit、review_poa_partial_matchなどで、各ルールのアクションをエンドツーエンドに確認できます。サンドボックスでのテストをご覧ください。

Tip

拒否パスと同じくらい丁寧にレビューパスもテストしてください。レビューに振り分けるルールは、実際に誰かがそのキューを処理して初めて意味を持ちます。自社のレビュープロセスが機能しているかを知る方法は、実際の顧客が待っている前に、合成セッションをそこに通してみることです。

#変更は新しいセッションに適用される

ワークフローを編集しても、すでに作成済みのセッションには遡って反映されません。セッションは作成時点の設定を保持するため、ルールを変更した後は、古いセッションを再確認するのではなく新しいセッションでテストしてください。