「ご担当者様」「テスト」「あ」——CRMに住み着くダミーレコードの正体

2026.08.30データ整備の考え方AI名寄せ

CRMに残っている「ご担当者様」「テスト」「あ」といったダミーレコードの正体は、宛名不明のまま取り込まれたリスト・動作確認の消し忘れ・必須項目を埋めるためだけの回避入力の3つです。件数にすれば全体のごく一部でも、集計の数字・メール配信・AI活用・そして名寄せそのものを静かに壊します。試しに、お使いのCRMの検索窓に「テスト」と入れてみてください——誰も入れた覚えのない住人が、たいてい何件か見つかります。この記事では、ダミーレコードがどこから来るのか、なぜ少数でも危険なのか、そして検出条件の作り方から掃除の仕組み化までを解説します。

CRMに住み着く「名前のない住人」たち

架空の例で情景を再現します。株式会社山田製作所のマーケティング担当が、メール配信の前に配信リストを眺めていました。宛名の差し込み確認をしていると、姓の欄に「ご担当者様」と入ったレコードが数百件あることに気づきます。会社名はある、メールアドレスもある、でも人の名前だけがない——展示会の主催者から届いたリストを、そのまま取り込んだ跡です。

気になって検索を続けると、次々に見つかります。会社名「テスト」、担当者「山田太郎」、メールアドレスは自社の社員のもの——数年前、フォーム連携の動作確認をしたときの残骸です。姓「あ」名「あ」というレコードもあります。電話対応の途中、必須項目を埋めないと保存できない画面を前に、誰かがとりあえず入力したのでしょう。

この日、1回の点検で見つかった住人たちを並べると、こうなります。

• 姓「ご担当者様」——数百件。主催者提供リストを一括取込した跡
• 会社名「テスト」担当者「山田太郎」——数年前のフォーム連携の動作確認の残骸
• 姓「あ」名「あ」——必須項目を埋めるためだけの、とりあえずの入力

どれも、誰かが悪意で入れたものではありません。業務が正しく回った副産物として生まれ、消す工程がどこにもないから残り続けている——それがダミーレコードの正体です。人間はこれらを一目で「本物ではない」と見分けられますが、システムにとっては正規のレコードと完全に同格です。配信にも集計にもAIの読み込みにも、堂々と混ざります。

どこから来るのか——ダミーレコード3つの発生源

ダミーレコードの発生源は、大きく3つに整理できます。それぞれ生まれ方が違うため、あとで見る検出条件も変わります。

注目したいのは3つ目の回避入力型です。「入力規則を厳しくすればデータはきれいになる」と考えがちですが、現場が急いでいるとき、必須項目は正しく埋められるのではなくとりあえず埋められるのです。氏名を必須にすれば「あ」が生まれ、電話番号を必須にすれば「999-9999-9999」が生まれます。入口の統制と、入ってしまったものの掃除は、別の対策として両方必要です。

また、宛名不明型は展示会リードの重複と同じ入口から入ってきます。展示会のリストを取り込むという1つの行為が、重複とダミーの両方を同時に生む——リード取込の後処理を仕組み化すべき理由が、ここでも1つ増えます。

少数でも壊れる——集計・配信・AI活用・名寄せへの被害

ダミーレコードの怖さは、被害が件数に比例しないことです。数万件のデータベースに数百件のダミー——率にすれば1%前後でも、壊れる場所は要所ばかりです。

まず集計です。「今月の新規リード数」「フォーム経由の獲得数」といった数字にダミーがそのまま乗ります。特に動作確認型は新しい施策の計測期間に生まれやすいため、「新フォームの初週コンバージョン」のような、少数の差が意思決定を左右する数字ほど歪みます。

次にメール配信です。宛名不明型はメールアドレスが実在するため、配信は正常に届きます。「ご担当者様 様」という宛名で。差し込みの事故として受け手に見えるのはもちろん、動作確認型のレコードに顧客向けキャンペーンが届けば、社内から「これは何だ」という問い合わせが来ます。配信リストの信頼は、こうした細部から削られていきます。

そしてAI活用です。顧客データをAIに読ませて提案や要約を作らせる場面が増えるほど、ダミーは雑音として効いてきます。「あ」という顧客への営業提案が生成され、「テスト」社が有望リードのリストに載る——AIはデータを疑わないため、入力の汚れは出力の汚れに直結します。データ整備がAI活用の前提だと言われる理由の、最も分かりやすい実例です。

最後に、見落とされがちな被害が名寄せそのものを壊すことです。「ご担当者様」が数百件あるデータベースで人単位の名寄せを実行すると、氏名が一致する「ご担当者様」同士が同一人物の候補として大量にヒットします。ダミーレコードは重複判定の偽陽性製造機であり、承認キューを無意味な候補で埋めて、本当に判断すべきグレーな候補を押し流してしまいます。名寄せの前にダミーを退避させることは、名寄せの精度対策そのものです。

被害の現れる場所を整理すると、次のようになります。どれも、データの「出口」にあたる要所です。

• 集計——新施策の計測など、少数の差が意思決定を左右する数字ほど歪む
• 配信——「ご担当者様 様」宛のメールが、実在のアドレスに正常に届いてしまう
• AI活用——入力の汚れが出力の汚れに直結し、提案やリストに雑音が乗る
• 名寄せ——「ご担当者様」同士の偽陽性が、承認キューを無意味な候補で埋める

検出条件の作り方——「ダミーらしさ」をルールとして宣言する

ダミーレコードの掃除は「見つける→裁く」の2段階です。そして見つける段階でまずやるべきは、条件を書くことではなく、実物を見に行くことです。

ダミーの語彙は組織ごとに違います。「ご担当者様」の会社もあれば「担当者様」「御中」の会社もあり、動作確認の名前が「テスト」の組織もあれば歴代の担当者名の組織もあります。データブラウザでステージングテーブルを直接歩き、姓だけで件数を集計したり、登録の古い順に並べたりすると、自社のダミーの「顔ぶれ」が見えてきます。この観察が、検出条件の材料になります。

顔ぶれが分かったら、条件を宣言します。重複条件と同じ選べる3通りの入り口で、「姓が1文字だけ、または氏名にテスト・ダミーを含み、または姓がご担当者様のレコード」と日本語で書くだけでも、SQLを直接書いても構いません。どの入り口から入っても、最終的には画面で確認・編集できる透明なルールに着地し、実行のたびに同じ基準で動きます。

ここで大事なのは、機械判定を断定にしないことです。「あ」は回避入力でしょうが、1文字の姓には「呉」や「林」といった実在の姓があります。「テスト」を含む文字列を機械的に消せば、実在する社名を巻き込む恐れもあります。だから条件はあくまで候補出しであり、確定は人が行います。

• 観察——データブラウザで実物を見て、自社のダミーの顔ぶれを把握する
• 宣言——顔ぶれを検出条件として書く。日本語で書くだけでもSQL直接でもよい
• 候補出し——条件に合ったレコードが候補として並ぶ。この時点では何も変わらない
• 人の確定——候補を人が確認し、ダミーと確定したものだけを処理する

一度作った条件は資産になります。次の取込からは同じ条件が自動で効くため、「ご担当者様」が再び数百件入ってきても、翌朝には候補として並んでいます。

ナヨセルの場合——見つける・裁く・再発を防ぐ

当社のAI名寄せ・顧客データ統合クラウド「ナヨセル」では、ダミーレコードの掃除を単発の作業ではなく、名寄せと同じ台の上の定常工程として設計しています。

• 見つける——データブラウザで実態を観察し、検出条件を編集できる透明なルールとして宣言する。AIに「ダミーらしいレコードの条件」の叩き台を提案させることもできる
• 裁く——候補は承認キューに入り、人が確認して確定するまで正式なデータは1件も変わらない。「呉」さんを誤って消す事故は、この関門が防ぐ
• 戻せる——処理の前にはスナップショットが取られ、間違えても1クリックで復元できる。判断の記録は監査ログに残る
• 再発を防ぐ——スケジュール実行で検出を定常化し、新しく入ったダミーを取込のたびに捕まえる

処理の中身も「削除」一択ではありません。活動履歴が紐づいたレコードを消すと履歴ごと失われるため、統合対象から外して退避する、宛名不明のまま会社単位のレコードに寄せる、といった扱いを選べます。ダミーレコードは名寄せの偽陽性製造機でもあるため、名寄せ本体の前段としてダミーの検出を走らせる構成が、精度面でも効きます。

自社にどれだけのダミーが住み着いているか分からない場合は、AI名寄せ診断から始めるのが早道です。重複率とあわせて、データの汚れの全体像を実行前に数字で把握できます。料金はマージ対象レコード数だけで決まり（Starter月額5万円〜・税抜）、実行回数は課金対象外なので、検出を毎日走らせても費用は変わりません。詳しくは料金プランをご覧ください。

よくある質問

ダミーレコードは削除してしまってよいのでしょうか？

即削除はおすすめしません。動作確認型には過去の連携テストの履歴が、宛名不明型には実在の会社・メールアドレスが紐づいていることがあります。まず関連レコードへの影響を確認し、削除ではなく退避や統合を選ぶ余地を残すのが安全です。ナヨセルでは処理前にスナップショットが取られるため、確定後でも1クリックで戻せます。

「テスト」を含む実在の会社名を誤って消しませんか？

条件だけで断定しない設計にしています。検出条件はあくまで候補出しで、確定は人が承認画面で行います。会社名であれば、500万法人超の法人マスタとの照合で実在の裏付けを取ることもできます。機械の網羅性と人の判断力を分担させるのは、名寄せ本体と同じ思想です。

入力規則を厳しくすれば、ダミーは防げますか？

一部は防げますが、必須項目を増やすほど「あ」「999」のような回避入力が増える側面があります。入口の統制は宛名不明型・動作確認型には効きにくく、回避入力型を悪化させることもあるため、入口対策と定常的な掃除の両輪で考えることをおすすめします。

どのくらいの件数になったら対処すべきですか？

件数ではなく、用途で判断してください。メール配信を始める、経営指標をCRMから取る、AIに顧客データを読ませる——データの出口が増えるタイミングが対処のタイミングです。被害は件数に比例しないため、「まだ数百件だから」という基準は当てになりません。

ダミーの検出と名寄せは、どちらを先にやるべきですか？

ダミーの検出が先です。「ご担当者様」同士が同一人物としてヒットするなど、ダミーは名寄せの判定を汚し、承認キューを無意味な候補で埋めます。ナヨセルでは検出と名寄せを同じ台の上で扱えるため、前段にダミー検出、後段に名寄せという構成を1つの運用として組めます。

料金プランと導入支援の内容がわかる
資料をご用意しています

サービス概要から料金プラン、2ヶ月の導入支援の進め方まで
まとめた資料を無料でダウンロードいただけます。

資料ダウンロード無料 料金プランを見る