同じ会社にAlex Chenが二人いる。Agentが統合すると、別々の営業活動が一人へ結び付く。リストは短くなっても、顧客関係は壊れてしまう。
名前や一つのフィールドの一致は、同一人物の証明ではない。 AIによるCRM重複検出は、規則と反証、確認不足を付けた候補一覧から始める。判断は関係を知る担当者に残す。
BudaのCRM業務でも、まず検出する。重複タスクを防ぐキーと、人の同一性は別問題だ。
八行をそのまま保つ
全行架空の教材で、.example は実連絡先ではない。実CRMの試験結果ではない。取得日は2026年10月18日とし、実務では各行の元システムと更新日時も保存する。
| 元:ID | 氏名 | 元メール | 状況 |
|---|---|---|---|
| A:101 | Alex Chen | alex@north.example | North・営業窓口 |
| B:101 | Alex Chen | alex.chen@north.example | North・技術窓口、同一性不明 |
| A:102 | Priya Rao | priya@harbor.example | Harbor |
| B:202 | Priya Rao | priya@HARBOR.example | Harbor・部署不一致 |
| A:103 | Mei Lin | team@cedar.example | 共用受信箱・受注 |
| B:203 | Kai Lin | team@cedar.example | 共用受信箱・技術 |
| A:104 | Jordan Lee | jordan@old.example | 旧会社の履歴 |
| B:204 | Jordan Lee | j.lee@new.example | 新会社。本人確認資料S04が旧メールを結ぶ |
A:101とB:101はnamespaceが違う。同じ数値だけで主キー重複としない。候補作成、本人確認、統合は別工程で、必ず四組にする必要もない。
比較値だけを正規化する
email_rawを保存し、比較用に外側空白の除去とドメイン小文字化を行う。ローカル部は保持し、その大小文字を無視できるかは元データと明示ルールで確認する。この規則ならPriyaの比較値は一致するが、統合許可ではない。
+tagやGmailの点を勝手に除去せず、事業者ごとの別名規則を一般化しない。形式が自然でも有効性、受信可能性、所有者は未証明。確認メールの送信も読取作業の範囲外だ。
電話は元値を保ち、国番号不明なら会社所在地で補わない。末尾番号、氏名、会社ドメイン、役職の一致は単独で本人を決めない。
確率ではなく三分類を返す
| 組 | 分類 | 根拠と反証 | 次の確認 |
|---|---|---|---|
| A:102 / B:202 | 強い候補 | 名前と比較メール一致、部署は競合 | 担当者が本人と部署の時点を確認 |
| A:104 / B:204 | 関連の可能性 | S04は旧新メールを結ぶ。会社は変更 | 原文、日付、関係の扱いを確認 |
| A:101 / B:101 | 統合しない | 同名同社だけで、役割が違い根拠不足 | 両方を保持 |
| A:103 / B:203 | 統合しない | 同じ共用メールでも別人・別責任 | 人物と共用連絡先を保持 |
強い候補も承認ではない。S04は架空の明示確認であり、現実に同等の許可済み証拠がなければ不明とする。人物と会社所属は別の関係になり得る。「92%同一人物」といった未校正の値ではなく、発火規則と不足を渡す。
一組ごとに元行へ戻れる形にする
candidate-pairs.csvにpair-id、双方namespaceとID、規則版、元値と比較値、元日時、根拠、反証、不足、分類、確認役割を記録する。
v1|A:102|B:202のように識別子を固定順に並べれば再計算できる。Buda標準の冪等ロックではない。同じ入力と規則で二度同じIDを出すのは推奨確認で、ここでは未実行だ。
AとB、BとCに線索があっても、AとCが同人とは限らない。共用連絡先や履歴を見ずに推移的に全統合しない。
conflicting-fields.mdでは部署などの原値、元、更新日時を残す。異動、取得時点差、誤入力を区別して業務担当者が保留値を選ぶ。最新日時だけで勝者を決めず、Agentはowner、stage、amountを変えない。
review-decisions.csvには人による同人・別人・不足の判断、確認者、根拠、時刻、次動作を記録する。提案欄と確認欄を分け、未確認候補を確定重複と数えない。
同人でも統合は別の判断
履歴、商談、工単、購読、権限の関連がある。主レコード、移行、取消の実挙動を知らずに「間違えば戻せる」とは約束しない。
まずエクスポートと候補だけ。書込権限を接続せず、削除、統合、担当移管をしない。本人確認後、CRM管理者が保持字段と関連影響を調べ、別途許可された操作に進む。特定CRM連携の試験済みという主張もしない。
Budaで読取専用の一巡を行う
許可済み匿名化出力、辞書、規則、必要な確認資料をDriveへ置く。Agent DriveとSpace Driveは共有範囲が異なり、新Sessionは権限境界ではない。
指定コピーだけを読み、namespace、ID、原値を保存する。比較だけを正規化し、候補、字段競合、人の判断テンプレートを出す。出典、反証、不足を残す。未校正の確率、CRM書込、削除、統合、送信、業務字段変更は禁止。
同名別人、共用メール、転職、複数メールの例を開き、元行と未確定欄を照合する。ファイルがあるだけでは正しい照合にならない。RevOps全体の設計に進む前に、何を誰が調べるかを明確にする。
候補数より、人の確認後の精度を見る
候補精度は、同人と確認した組数÷本人確認を完了した組数で求められる。証拠不足は別に出し、確認済み分母に入れない。分類と規則版を残す。
これは送審候補の精度で、見逃しは分からない。再現率には代表的な人手ラベル集合が別に必要。八行の教材で業務精度や時間削減を示さない。
共用メールならどうする？
連絡方法として扱い、人物を一人にしない。別の責任と関係を保ち、CRMの関係表現を管理者が確認する。
転職した人は同じ連絡先か？
明示的な許可済み確認があれば同人になり得る。ただし旧会社の活動や商談を新会社へ移す許可にはならない。
誰が確定する？
関係担当者が本人を、管理者が関連と操作を確認する。根拠、役割、日時、保持値を残し、足りなければ保留する。
Buda AIのMarketplaceでデータ処理Skillを検索してインストールし、規則と停止条件を読んで匿名化コピーを試す。最初の目的は短い名簿ではなく、「統合しない」と言える根拠付き候補である。