名寄せツールの選び方——外してはいけない5つのチェックポイント
名寄せツールの検討で怖いのは、「高機能なツールを選んだのに、肝心の作業が終わらない」という失敗です。原因の多くは、機能の一覧表では見えにくい部分——統合した後の反映、表記揺れの吸収力、間違えたときに戻せるか——にあります。この記事では、名寄せツールを選ぶときに外してはいけないチェックポイントを5つに絞り、最後にそのまま使えるチェックリストとしてまとめます。
①「書き戻し」まで対応しているか
最初に確認すべきは、そのツールがどこまでやって終わるのかです。名寄せツールと呼ばれるものの中には、重複候補のリストを出すところまでが守備範囲——つまり「検出止まり」のツールが少なくありません。
検出止まりのツールで見落とされがちなのは、リストが出た後の作業量です。重複を統合し、残す側のレコードを決め、その結果をSalesforceやデータベースといった元のシステムに反映(書き戻し)するところまでやって、初めてデータはきれいになります。この後半部分が手作業だと、重複1,000組で数十時間規模の作業が発生し、しかも重複は増え続けるため毎月繰り返すことになります。書き戻しをAPI開発で補う場合は、開発費用が別途必要になることが多い点にも注意が必要です。
よくある失敗は、トライアルで検出画面の精度に納得して契約し、本番運用の初月に「出てきたリストを元のシステムに反映する人がいない」と気づくパターンです。トライアルの評価項目には、検出精度だけでなく「統合を実行して書き戻すところまで」を最初から含めておくことをおすすめします。確認の仕方はシンプルで、「統合した結果は、誰がどうやって元のシステムに反映するのですか?」と聞くことです。回答が「CSVでエクスポートできます」であれば、その先の取り込み作業は自社持ちだと分かります。ツール・方式ごとの守備範囲の違いは「名寄せツール比較——方式別4タイプ」で整理しています。
② 表記揺れをどの層で吸収するか
「㈱プラート」「株式会社プラート」「(株)プラート」——人間には同じ会社でも、完全一致の突き合わせではすべて別物です。名寄せの検出精度は、表記揺れをどれだけ吸収できるかでほぼ決まります。見るべきは、吸収の仕組みがどの層まで用意されているかです。
| 層 | 吸収できる揺れ | 例 |
|---|---|---|
| 1. 文字の正規化 | 機械的に変換できる揺れ | 全角/半角、大文字/小文字、「㈱」→「株式会社」、スペースの有無 |
| 2. 辞書 | 知識がないと同一とわからない揺れ | 旧社名と新社名、通称と正式名称、略称(「日商」と「日本商事」) |
| 3. 類似度 | 正規化でも辞書でも拾えない揺れ | 入力ミス、「プラート」と「プラ―ト」のような微妙な違いを距離で判定 |
正規化だけのツールは完全一致に毛が生えた程度の検出力しかなく、逆に類似度だけに頼ると誤検出(別会社を同一と判定)が増えます。3つの層が揃っているか、そして辞書がゼロからの自作なのか、標準辞書が同梱されているのかは、精度と初期工数の両方に効くポイントです。辞書については「標準辞書には何件・どんな種類の語が入っていますか」「自社特有の略称や旧社名を追加する画面はありますか」まで聞くと、実力が具体的に見えてきます。
もうひとつ忘れやすいのが逆方向の確認、つまり「同じに見える別会社を、別物と見分けられるか」です。例えば「プラート」という名前の会社は愛知・栃木・福岡に3社実在します。名前だけで寄せる設定にすると、この3社は誤って1社に統合されます。誤検出の統合は、見逃しよりも復旧がはるかに大変です(商談や請求先が混ざるため)。住所・電話番号・法人番号といった補助項目で見分けられるかを必ず確認してください。実力を測る手っ取り早い方法は、実データのサンプル1,000件程度に「見つかるはずの重複」10組と「間違えやすい同名別会社」数組を仕込み、検出率と誤検出の両方を見ることです。検出率だけを見ると、緩い条件のツールが不当に高評価になります。
辞書についてはもうひとつ、導入後に誰が育てるのかも決めておきたいポイントです。辞書は生き物で、社名変更・合併・新しい略称は毎月生まれます。追加のたびにベンダーへの依頼が必要なのか、自社の画面で登録できるのか、登録した語が次回の実行から効くのか——ここが重いと、せっかくの辞書が初期整備のまま古びていきます。
③ 安全装置は揃っているか
名寄せは、間違えるとデータ事故になる作業です。別々の会社を1つに統合してしまうと、商談も請求先も混ざります。だからこそ、検出精度と同じくらい間違えたときに気づけて、戻せる仕組みが重要です。確認すべきは次の4点セットです。
| 安全装置 | 何を守るか | 確認する質問 |
|---|---|---|
| プレビュー | 実行前に件数と中身を確認できる | 「マージされる組み合わせを、実行前に一覧で確認できますか?」 |
| 承認フロー | 機械の判定を人が確定させる | 「自動でマージする/しないの境界を、自社で調整できますか?」 |
| ロールバック | 誤マージを元に戻せる | 「実行後に間違いに気づいたら、どうやって・いつまで戻せますか?」 |
| 監査ログ | 誰が・いつ・何を統合したか説明できる | 「統合の履歴を、根拠となったルールごと出力できますか?」 |
図のとおり、4つは「実行前を守る2つ」と「実行後を守る2つ」で対になっています。プレビューと承認フローだけあっても、実行後に間違いが発覚したら戻せません。ロールバックだけあっても、そもそも間違いに気づく仕組み(監査ログ)がなければ発動できません。4つ揃って初めて機能すると考えてください。
デモで確かめるコツは、わざと間違えてみることです。「この2社は実は別会社です。誤ってマージしてから、元に戻すところを見せてください」と依頼すると、戻せる範囲(関連レコードの付け替えまで戻るのか、レコード本体だけか)と戻せる期間が具体的に分かります。特にロールバックは差が出やすい項目です。「バックアップから復元できます」と「1クリックで実行前の状態に戻せます」の間には、事故対応で数日分の差があります。
④ 関連レコード(商談・対応履歴)の扱い
顧客レコードは単体では存在しません。取引先には商談・対応履歴・請求情報・ケースがぶら下がっています。重複した取引先を統合するなら、消える側にぶら下がっていた関連レコードを、残る側に付け替える必要があります。
ここが対象外のツールだと、統合した瞬間に「あの商談が消えた」「過去のやり取りが見えない」という業務事故になります。逆に、付け替えの仕様が粗いと、本来分けておきたい履歴まで機械的に合流してしまう。確認すべきは次の3点です。
- 関連レコードの付け替えは自動で行われるか、手作業か、そもそも対象外か
- どのオブジェクト(商談・活動・ケース・カスタムオブジェクト等)まで付け替えの対象か
- 付け替えの結果を実行前に確認できるか
具体的に想像してみてください。消える側の取引先に商談3件・活動12件・進行中のケース1件がぶら下がっていたとします。付け替えが対象外のツールで統合すると、この16件は宙に浮き、営業とサポートの現場から「顧客の履歴が見えない」という問い合わせが始まります。また、標準オブジェクトは付け替え対象でもカスタムオブジェクト(契約、請求、保守機器の管理など)が対象外という仕様は珍しくありません。デモには自社のオブジェクト構成の一覧を持って臨み、「このオブジェクトは付け替え対象ですか」と1つずつ確認するのが確実です。また、対象が複数サービスにまたがる場合(Salesforceとkintone、CRMと基幹DBなど)は、付け替えに加えて「どのIDとどのIDが同一顧客か」の対応表(統合ID)を保持できるかも確認しておくと、BIでの集計や他システムとの結合が後で楽になります。Salesforceを使っている場合、この論点は標準マージ機能の仕様とも絡みます。詳しくは「Salesforceの重複データを安全に統合する方法」で解説しています。
⑤ 料金体系が自社のデータ量と合うか
名寄せツールの課金体系には、レコード数課金・ユーザー数課金・実行回数課金・件数単価の代行型があり、同じデータ量でもどの体系かで総額が大きく変わります。ポイントは、自社の使い方に対して費用が読めるかどうかです。
- 定期実行(日次・週次)できれいな状態を保ちたいのに、実行回数課金——回すほど費用が増え、運用と相性が悪い
- 判定・承認に営業マネージャーも関わるのに、ユーザー数課金——関係者が増えるたびに費用が膨らむ
- 継続運用したいのに件数単価の代行型——毎回費用が発生し、書き戻しは別料金のことが多い
試算の手順はこうです。まず対象データの合計レコード数を概算します(例:Salesforceの取引先8万件+kintoneの顧客3万件+基幹DBの得意先4万件=計15万件)。次に実行頻度(週次できれいさを保ちたいなら月4〜5回)と、承認に関わる人数(営業マネージャー2人+管理部1人など)を決めます。この3つの数字を各社の料金表に当てはめると、レコード数課金なら月額が一意に決まる一方、実行回数課金やユーザー数課金では使い方次第で費用が変動することが具体的に見えてきます。運用を始めてから「実行回数を節約するために月次に減らす」のは本末転倒です。もうひとつ、料金表の外にある費用として導入支援の扱いを確認してください。重複条件の設計や辞書の初期整備は最初の山場で、ここが「別料金のコンサルティング」なのか「標準付帯」なのかで、初年度の総額と立ち上がりの速さが変わります。課金体系ごとの相場観と見落としがちな費用は「名寄せツールの料金相場」にまとめています。
そのまま使える選定チェックリスト
5つのポイントを、ベンダーへの確認にそのまま使えるチェックリストにまとめます。比較検討の際は、候補ツールごとにこの10項目を埋めてみてください。
- 統合した結果を元のシステムに書き戻せるか?(追加開発なしで)
- 関連レコード(商談・対応履歴)の付け替えまで対象か?
- 表記揺れの吸収は「正規化・辞書・類似度」の3層が揃っているか?
- 標準辞書は同梱されているか?(ゼロから自作は工数が大きい)
- 実行前に、マージされる組み合わせをプレビューできるか?
- 自動マージと人の承認の境界を、自社で調整できるか?
- 誤マージを1クリックで元に戻せるか?(戻せる期間も確認)
- 誰が・いつ・どのルールで統合したかの監査ログが残るか?
- 課金の単位(レコード数/ユーザー数/実行回数/件数単価)は自社の使い方と合うか?
- 条件設計・辞書整備などの導入支援は標準か、別料金か?
使い方のコツを2つ。まず、この10項目は口頭ではなくメールで質問して、文書で回答をもらうことをおすすめします。「対応しています」の一言と「◯◯の範囲で対応、△△は対象外」という文書回答では、契約後の齟齬の起きやすさがまったく違います。次に、全項目◯のツールを探すことが目的ではありません。×の項目を自社の体制でカバーできるか(できないか)を判断するための表です。例えば書き戻しが×でも、情報システム部門にAPI開発の余力があるなら選択肢に残ります。余力がないなら、その×は失格条件です。最後に、文書回答で絞った候補は実データのトライアルで検証してください。②で述べたサンプル(見つかるはずの重複+同名別会社)を仕込んだデータで、検出→プレビュー→承認→書き戻し→ロールバックまでを一巡する。この一巡ができないツールは、本番でもその工程が自社の手作業になるということです。
ナヨセルの場合——5つのポイントへの対応
参考までに、当社が提供するAI名寄せ・顧客データ統合クラウド「ナヨセル」の、5つのチェックポイントへの対応を簡潔にまとめます。
- ① 書き戻し——検出からマージの実行、元サービスへの書き戻しまで一気通貫。ファーストリリースはSalesforce・RDBMSに対応し、追加開発は不要です
- ② 表記揺れ——文字の正規化・辞書・類似度の3層で吸収。デフォルト辞書を同梱し、貴社辞書の追加とAIによる辞書ドラフトにも対応。gBizINFO・法人番号公表サイト由来の法人マスタ(500万法人超・月次更新)で同名別会社の見分けも支えます
- ③ 安全装置——実行前スナップショット(1クリックロールバック)と、確信度で自動マージ・承認待ち・対象外に分類する承認キュー(しきい値調整可)を全プランに標準搭載。CSV出力できるマージ監査ログはProfessional以上で利用できます
- ④ 関連レコード——Salesforceでは商談・対応履歴などの関連レコードの付け替えに対応。付け替え結果は実行前に確認できます
- ⑤ 料金——名寄せ対象のレコード数だけで決まります(Starter 月額5万円・税抜)。接続サービス数・実行回数・ユーザー数は課金対象外。2ヶ月の導入支援(50万円〜・選択制オプション)で、条件設計・辞書整備・初回マージの伴走までカバーできます
重複条件はAIのレコメンド/日本語で書くだけ/SQLの直接指定から選べ、AIが叩き台をつくり、確定は人の承認で、実行は編集できる透明なルールで行われます。処理性能の目安として、582万件の突合シミュレーションは90秒で完了します(実測)。詳細は料金プランのページをご覧ください。
料金プランと導入支援の内容がわかる
資料をご用意しています
サービス概要から料金プラン、2ヶ月の導入支援の進め方まで
まとめた資料を無料でダウンロードいただけます。