名寄せで一番怖いのは、重複を残すことより、別人を同じ相手として統合することです。
「田中太郎が2件あるから同じ人」とは限りません。
名前は弱いキー
氏名・会社名には、
- 同姓同名
- 同名企業
- 法人格の違い
- 支店名
- 表記ゆれ
があります。
名前一致は候補抽出には使えますが、単独で自動統合する条件としては弱い場合があります。
強いキー
相手を一意に識別しやすいものです。
例：
- 自社で発行した顧客ID
- 会員番号
- 外部システムの固定ID
- 契約ID
ただし「IDが違うから別人」とも限りません。重複登録によって同じ人へ別IDが付くこともあります。
補助キー
本人確認の材料として使いやすいものです。
- メールアドレス
- 電話番号
- 住所
- 生年月日
- 業務上利用が認められ、目的に適合する識別情報
業務と法令・契約の範囲で必要なものだけ使います。
弱いキー
- 氏名
- 会社名
- 部署名
- 担当者名
など、重複しやすい項目です。
弱いキーは1つでは決めず、別情報と組み合わせます。
複数条件で候補を作る
たとえば、
名前一致 + 電話一致 → 強い候補
名前一致 + メール一致 → 強い候補
名前だけ一致 → 要確認
のようにします。
「一致数が多ければ自動統合」ではなく、業務リスクに応じて人が確認する境界を残します。
空欄を一致とみなさない
電話が両方空欄だから一致、という扱いは危険です。
欠損は「同じ」ではなく「比較できない」です。
名寄せロジックでは、空欄と一致を分けます。
自動化するなら候補抽出まで
大量データでは、
- 正規化
- キー生成
- 候補グループ化
までは自動化できます。
一方、顧客履歴や権利関係に影響する統合は、人間確認を残す方が安全です。
レビュー記録を残す
統合した場合は、
何を根拠に同一と判断したか
を残します。
誤統合が起きたときに戻せるからです。
キーごとの扱いを表にしておく
|種類|例|一致したときの扱い|
|---|---|---|
|Strong|自社顧客ID、固定の外部ID|同一候補として最優先で確認|
|Support|メール、電話、住所の一部|Strongを補強する|
|Weak|氏名、会社名、担当者名|単独では統合しない|
たとえば、
|氏名|メール|電話|判断|
|---|---|---|---|
|一致|一致|一致|同一候補として強い|
|一致|不一致|不一致|別人の可能性を確認|
|不一致|一致|一致|改姓・表記違い等を確認|
|一致|空欄|空欄|判断材料不足|
強いキーが衝突したときほど自動統合しない
顧客IDは同じなのにメールアドレスが完全に別、という状態なら、
- 情報更新があった
- IDを使い回している
- データ移行で誤対応した
など複数の可能性があります。
「Strongが一致したから正しい」と上書きするのではなく、強いキーと補助情報が矛盾した行を優先レビュー対象にする方が安全です。
名寄せの精度は「一致させる力」だけでなく、違う相手を混ぜない力で評価した方が安全です。
