IDENTITY RESOLUTION / SAFE MATCHING
AI電話注文の
セキュリティ設計。
一致した。でも、まだ本人ではない。電話番号、会員ID、氏名。どれかが顧客マスタに一致しても、それだけで本人確認済みにはしません。ContactX Orderは、検索・候補確定・正式な本人確認・情報開示を分けて扱います。
「以前の電話は
080-1111-2222です」
- 旧電話番号
- +35
- 独立手掛かり
- 1種類
THE SAFETY BOUNDARY
「検索できる」と、
「開示できる」の間に線を引く。
ここで扱うのは、会話を続けるための顧客候補の照合です。法的・契約上の本人確認そのものではありません。
- 01手掛かりを抽出
発話と音声認識候補を保持
- 02顧客を検索
一致・近似・旧情報を区別
- 03候補を確定
強い一致または独立2手掛かり
- 04正式に本人確認
業務ごとの認証手段を実施
- 05情報を開示
注文履歴・住所・配送状況など
WEIGH THE EVIDENCE
情報の種類ごとに、
“強さ”を変える。
下記は公開デモのスコアです。普遍的な本人確認基準ではなく、候補検索の挙動をテスト可能にする実装値です。
会員ID / 現電話の完全一致
confidence 0.55以上、または音声認識を介さない入力
氏名の完全一致
候補を強くするが、同姓同名を残す
旧電話番号の一致
履歴として候補化。単独では確定しない
会員IDの1文字違い
入力ミスの可能性。別種類の手掛かりが必要
名字だけの一致
検索の入口。本人候補の確定には使わない
合計65点以上
ただし、上位2候補の差が25点未満なら曖昧として止めます。
KEEP THE HYPOTHESES
音声認識の候補を、
一つに潰さない。
「18425」と「18426」の両方が認識候補なら、文字列とconfidenceをそのまま保持します。AIがもっともらしい会員IDを作るのではなく、実際に聞こえた値だけを照合へ渡します。
会員IDは NYO-18425 です
0.92会員IDは NYO-18426 です
0.84SIX FAILURE-RESISTANT CASES
当たるケースより先に、
間違えて確定しないケースを試す。
公開デモでは、6地域の顧客データと10本の顧客照合テストで、完全一致だけでなく近似・旧情報・同姓同名・低confidenceを確認しています。
会員IDが完全一致
NYO-18426 / 高confidence
電話番号が完全一致
現在の登録番号 / 高confidence
会員IDが1文字違い
近似一致だけでは確定しない
旧電話番号 ＋ 氏名
異なる種類の証拠を組み合わせる
同姓同名 / 名字だけ
上位候補の差が25未満なら確定しない
低confidenceの認識候補
聞こえた値を勝手に補正しない
FROM DEMO TO PRODUCTION
本番では、顧客DBの
完全一致検索を起点にする。
公開デモはブラウザ内の架空データで挙動を再現しています。本番接続済みと誤解させず、実導入では顧客DB側の一意制約・完全一致検索・監査記録を中心に組み直します。
完全一致を先に検索
正規化した会員ID・現在電話番号を、索引のあるDB検索へ渡す。
弱い情報は候補化だけ
旧番号、近似ID、氏名は追加確認のために使い、単独確定しない。
認証と開示を制御
照合結果、認証手段、開示項目を監査できる形で記録する。
顧客だけでなく、曖昧な商品名も決めつけない。
DESIGN THE BOUNDARY FIRST