AIで顧客台帳の表記ゆれ・重複を整理する方法

顧客台帳の表記ゆれや重複をAIで整理するとき、最も避けたいのは「似ているから同じ顧客だろう」と一括でMergeすることです。AIは候補を見つける役には向きますが、統合の可否は顧客ID・メール・電話・住所など複数の根拠を見て決めます。元データを直接上書きせず、候補表→人の確認→統合→検算という順番に分けるのが基本です。

この記事のゴールは、顧客台帳をいきなりきれいにすることではありません。どの表記を正規化し、何を重複候補とみなし、どの条件なら自動処理・人確認・保留に分けるかを決め、誤統合しても元へ戻せる状態まで作ることです。

まず元データを保護し、「正規化」と「同一人物判定」を分ける

表記ゆれの整理と重複統合は、似ていますが別作業です。株式会社の有無や全角・半角、余分な空白をそろえるのはNormalizationです。一方、「株式会社エクサンプル」と「Example Inc.」が本当に同じ法人かを決めるのはEntity Matchingです。正規化した結果が似たからといって、同一顧客とは限りません。

最初に原本をコピーして、作業用sheetや別fileを作ります。元のrow IDや顧客IDは削除せず、処理前の値も残します。AIへ渡す場合も、氏名・メール・電話番号などの個人情報を必要以上に含めず、可能なら匿名化したsampleでRuleを固めてから本番へ適用します。

完成形：重複候補を3段階に分ける

統合可否をAIのconfidenceだけで決めず、根拠の強さで分けます。

表は横にスクロールできます

判定	代表的な根拠	処理
AUTO候補	同一の不変ID、または明示的に一意と定義されたKeyが一致	Ruleに従い処理。ただし変更Logを残す
REVIEW	正規化社名＋住所、メールdomain＋電話など複数Signalが一致	候補表へ出し、人が確認
HOLD	会社名だけ似る、住所・電話が衝突、情報不足	Mergeしない。追加情報を確認

ここでいうAUTOは「AIが自信ありと言ったら自動統合」という意味ではありません。自社の台帳で一意性が保証されている顧客IDなど、事前に決めたRuleに一致する場合だけです。AIの推論結果はREVIEW候補を作る材料として扱います。

列ごとに正規化Ruleを変える

すべての列へ同じ置換Ruleを当てると、必要な情報まで消えます。たとえば会社名と電話番号では、意味のある記号や表記が違います。まず列ごとに「比較用のCanonical値」を別列へ作ります。原文は残してください。

表は横にスクロールできます

列	比較用に行う例	消してはいけない判断材料
会社名	前後空白、全半角、法人格表記の統一	支店名・法人種別の違い
氏名	前後空白、連続空白の整理	別人を区別する読み・所属
電話	記号を除いた比較用値	国番号・内線の意味
メール	前後空白・大文字小文字の扱いをRule化	local partを勝手に変更しない
住所	空白・丁目表記などを比較しやすくする	部屋番号・建物・拠点差

Google Sheetsで単純な空白整理や重複確認をするなら、TRIMやUNIQUE、標準の重複削除機能も使えます。ただし、これらは「同一顧客か」を推論する仕組みではありません。まず完全一致や明示Ruleで処理できる範囲を機械的に片付け、残った曖昧候補だけをAIへ回す方が安全です。

例：同じ会社に見える4行をどう扱うか

次のような台帳を想定します。

表は横にスクロールできます

Row	顧客ID	会社名	電話	住所
101	C0012	株式会社サンプル	03-1234-5678	東京都A区1-2-3
204	C0012	(株)サンプル	0312345678	東京都A区1-2-3
318	なし	サンプル株式会社	03-1234-5678	東京都A区1-2-3
411	C0911	株式会社サンプル	06-9999-0000	大阪府B市4-5-6

101と204は顧客IDが同じなので、自社ルール上そのIDが一意なら強い一致Signalです。318は会社名・電話・住所が揃っているためREVIEW候補にできます。411は会社名だけ同じでID・電話・住所が異なるので、同一法人の別拠点なのか別法人なのか判断材料が足りません。ここを会社名の類似だけでMergeしないことが重要です。

AIへは「同じか判定して」ではなく、候補と根拠を出させる

AIへ依頼する際は、最終Mergeを許可せず、比較結果を構造化して出させます。

依頼例：

以下は顧客台帳の重複候補を確認するための匿名化sampleです。

各rowについて、同一顧客の可能性があるpairを抽出してください。

ただし、Mergeの確定はしないでください。

比較項目：

• customer_id

• normalized_company_name

• normalized_phone

• normalized_address

• email_domain

出力列：

1. row_a

2. row_b

3. 一致した項目

4. 衝突した項目

5. 判定：REVIEW / HOLD

6. 人が追加確認すべき情報

会社名の類似だけではREVIEW以上にしないでください。

情報が不足している場合は推測で埋めずHOLDにしてください。

この形なら、AIが「同じに見える」という結論だけを返すのではなく、どのSignalが一致し、何が矛盾しているかを確認できます。AIが出したconfidence scoreを使う場合も、scoreそのものをMerge権限にはしません。

候補表には「一致」と「衝突」を両方残す

重複候補をReviewするときは、一致情報だけを並べない方が安全です。異なる情報が見えないと、人も同一顧客だと思い込みやすくなります。

表は横にスクロールできます

Pair	一致	衝突	判定	次Action
101 / 204	customer_id、電話、住所	会社名表記のみ	AUTO候補	Rule確認後に統合
101 / 318	電話、住所、正規化社名	customer_id欠損	REVIEW	ID付与元を確認
101 / 411	社名	ID、電話、住所	HOLD	拠点・法人関係を確認

「一致が3つあるからMerge」のような件数ルールにしないことも大切です。顧客IDのように強いSignalと、会社名のように重複しやすいSignalでは意味が違います。

Merge時はSurvivor Ruleを先に決める

統合候補を承認した後も、どのrowを残すか、どの値を採用するかを決める必要があります。ここをAIに任せると、更新日時が新しいだけの誤情報を採用したり、片方の値を勝手に消したりする可能性があります。

先にSurvivor Ruleを定義します。たとえば「基幹CRMのcustomer_idを正本にする」「電話は検証済みflagのある値を優先」「住所が複数拠点なら統合せず別recordを維持」のように、列ごとの扱いを決めます。値が衝突したら空欄で埋めず、Conflictとして残す選択肢も必要です。

統合後は件数だけでなく参照関係まで検算する

Merge後にrow数が減っただけでは成功とは言えません。誤統合や参照切れがないか、最低限次を確認します。

1. 処理前後の総row数と、統合した件数が計算上合う。

2. 一意Keyに重複が残っていない。

3. 必須列の欠損が増えていない。

4. 旧customer_idから新customer_idへの対応表がある。

5. 商談・問い合わせ・請求など他tableからの参照先が壊れていない。

6. HOLDにした候補が勝手にMergeされていない。

7. 誰が、いつ、どのRuleで変更したかLogが残っている。

特にCRMや請求データとつながっている台帳では、顧客recordをまとめるだけで関連データのOwnerや履歴が変わることがあります。まず小さなPilotで処理し、参照先まで確認してから範囲を広げてください。

Rollbackできる状態を作ってから一括処理する

大量処理では、元recordを削除する前に対応表を残します。最低でもold_id、new_id、decision、reason、reviewer、processed_atを保存しておくと、後で「なぜこの2件を統合したか」を追えます。

自動処理を組む場合も、最初は候補CSVやReview sheetを出すだけにし、実際のMergeは別Stepに分ける方が安全です。候補抽出とデータ変更を同じWorkflowにすると、Ruleの調整中に本番台帳まで書き換える事故につながります。

自動化してよい処理・止めるべき処理を分ける

台帳整理では、機械的に再現できる処理と、人の判断が必要な処理を分離します。前後空白の削除、比較用電話番号の生成、完全一致候補の抽出などは自動化しやすい一方、別法人・別拠点・同姓同名を含むMerge判断は保留できる設計にします。

目安は「間違えたとき元へ戻せるか」「誤判定が顧客履歴や請求へ波及するか」です。影響が大きい処理ほど、AIの出力を直接writeせずReview Queueを挟みます。大量処理へ広げる前に、AUTO候補から無作為にsampleを取り、人がRuleの精度を確認してください。

AIものさしの判断

顧客台帳の整理では、AIの価値は「人が見落としやすい候補を広く出すこと」にあります。最終統合までAIに任せる必要はありません。

まず原本を保護し、列ごとのCanonical Formを作る。完全一致と一意Keyは明示Ruleで処理し、曖昧な候補は一致SignalとConflictを並べてREVIEWへ回します。会社名の類似だけ、あるいはAI confidenceだけでMergeしないでください。

実務で次にやるなら、いきなり全台帳へかけず、50〜100行程度のsampleで「AUTO / REVIEW / HOLD」の判定Ruleを作ります。そのRuleで誤統合が出ないことを確認してから、候補抽出範囲を広げるのが安全です。