判定で終わらせない
自動判定の結果だけを見るのではなく、再撮影が必要なケース、目視確認へ進むケース、確認が完了したケースをひとつの運用線上で扱います。
- 再撮影理由を利用者の次の操作へつなげる
- 目視確認が必要なケースを確認待ちとして整理
- 最終結果を連携先へ返す
製品情報
本人確認は、
判定だけじゃない。
IDENTAは、同意から書類撮影、顔ライブネス、判定、再撮影、目視確認、結果連携、情報の削除までを見渡して設計する法人向け本人確認サービスです。
01
製品の考え方
IDENTAが変える、
3つの当たり前。
確認を「点」から「継続」へ
テナント設定と利用者の同意が揃った場合、初回の本人確認だけに頼らず、その後も必要な場面で本人性を確かめられる設計を目指します。
- 実施の前提は設定と同意
- 目的に応じて確認を分ける
- 実施履歴を運用上確認できる構造
保管より先に、削除を考える
情報を集めることからではなく、目的、保護境界、アクセスできる役割、保持する期間、不要になったときの削除までをひとつのライフサイクルとして考えます。
- 目的別の保護境界と暗号化
- 役割に応じたアクセス制御
- 退会等の状態変化に連動する削除
02
利用者フロー
6ステップで、
迷いを減らす。
- 01理解して始める
目的と内容を確認
本人確認の目的、取り扱う情報、同意内容を確認して開始します。
- 02撮影案内
本人確認書類を撮影
画面上の案内に沿って必要な面を撮影し、読み取りに必要な状態を確認します。
- 03本人性の確認
顔ライブネスを確認
その場にいるご本人であることを、案内に沿った自然な操作で確かめます。
- 04結果を整理
自動判定
取得した情報をもとに確認し、次の運用へつなげます。精度や処理時間の断定は行いません。
- 05運用分岐
必要に応じて再撮影・目視確認
再撮影が必要な場合は利用者へ案内し、目視確認が必要な場合は専用管理画面の確認待ちへ進めます。
- 06業務へ接続
結果を連携
確認結果をAPI／Webhookで連携し、導入先の業務フローへ戻します。
03
専用管理画面
判断すべきことだけ、
目の前に。
専用管理画面では、確認の進行状況、再撮影が必要なケース、目視確認の待ち行列、設定、権限、操作履歴、連携状況を役割に応じて扱う構造を想定しています。実際の画面名称や提供範囲は導入時の確認事項です。
専用管理画面概要確認ケース目視確認設定権限・監査連携状況
確認済み完了したケース
要対応再撮影の案内
確認待ち目視確認の待ち行列
ケース現在の状態次の対応
確認ケース確認待ち内容を確認
確認ケース再撮影案内済み
確認ケース確認済み連携済み
ケース管理
進行中、再撮影、目視確認待ち、確認済みなど、現在の状態と次の対応を整理します。
目視確認
自動判定だけで完結しないケースを確認し、役割に応じた操作へつなげます。
設定・同意条件
利用する確認フローや継続確認の前提など、提供範囲に応じた設定を扱います。
権限と監査
閲覧・確認・設定変更などの役割を分け、重要な操作を後から確認できる構造にします。
情報管理
目的別の保管、保持期間、削除の状態を運用上確認できるようにします。
連携状況
API／Webhookによる結果連携の状態を確認し、業務フローとの接続を支えます。
04
継続的な本人性確認
確認する前に、
理由を揃える。
継続的な本人性確認は、無条件に行うものではありません。テナント設定と利用者の同意が揃っていることを前提に、目的に応じて実施する構造を想定します。
初回確認、必要な場面での再確認、実施履歴、情報の保持・削除を切り分け、運用者が確認できる形へつなげます。
- 前提 1テナント設定利用目的と実施条件を設定
- 前提 2利用者の同意内容を理解したうえで同意
- 実施必要な場面で確認目的に応じた本人性確認
05
システム連携
結果を返す。
業務が動く。
導入先システム確認開始
→IDENTA確認・運用
→API／Webhook結果連携
API連携
導入先のサービスから本人確認を開始し、必要な情報を連携するための接続点を用意します。
Webhook連携
確認状態の変化や結果を導入先へ通知し、後続処理へつなげます。
公開しないもの
内部ホスト、管理API、判定ロジック、認証情報、個別テナントの設定は公開サイトや資料へ含めません。
製品資料
読めば、導入の
輪郭が見える。
10ページの資料で、利用者フロー、運用分岐、専用管理画面、継続確認、安全設計、連携、導入時の確認事項をご覧いただけます。