マルチアカウント 1:N
本人確認が「正しい人物か？」を問うのに対し、マルチアカウント 1:N は「この顔は事業者のベース内のどこかに既に存在するか？」を問います。
機能の概要
事業者のベース内でセグメント化された1:Nの生体認証検索を実行し、受信した顔を同じ clientReferenceSegment に関連付けられたすべてのレコードと照合します。生体認証が既に別の clientReference にリンクされているかどうかを検出します — これは、同一人物が同一事業者で複数のアカウントを作成した、または作成しようとしていることを示します。
導入の差別化点： ベースの衛生管理を目的として、事業者のベースに既に保存されているセルフィー（数か月または数年前に撮影されたもの）を受け入れます。
入力
multi-accountsフローで Create Process (Web & Native) または Create Process (API) を使用して作成されたプロセス。imageBase64形式のユーザーのセルフィー（PNG、JPEG、または WebP；最小 640×480；最大 800 KB）。subject.clientReferenceフィールド — 事業者 のシステムにおけるユーザーの一意の識別子。
考えられるレスポンス
| レスポンス | 意味 |
|---|---|
reproved | マルチアカウントが検出されました。顔の生体認証が同一セグメント内の別の clientReference に既にリンクされています。 |
inconclusive | マルチアカウントは検出されませんでした。顔は事業者のベース内の他のアカウントに登録されていません。 |
YES または NO のレスポンスはありませんマルチアカウント 1:N は YES または NO を返しません — 重複の不在は inconclusive として表されます。リスクが絶対に存在しないという確認ではありません。
利用可能なサーフェス
| サーフェス | サポート |
|---|---|
| SDK（Android、iOS、Flutter） | — |
| Web（iFrame、リダイレクト） | — |
| API（ヘッドレス、SDK不使用） | ✅ |
有効な組み合わせ
パイプライン内で、マルチアカウント 1:N はライブネス（Unico が使用する場合）が前に来ることもそうでないこともあり、その後に Conditional Enroll が続きます。Conditional Enroll は、結果が INCONCLUSIVE であり、そのセグメント内の最初の clientReference である場合にのみ顔を登録し、生体認証の汚染を防ぎます。
multi-accounts 1:N → Conditional Enroll
検索スコープは APIKey に設定された clientReferenceSegment フィールドによって制御されます。