営業会議で同じ会社の名前が2回出てきて、担当者が別々に報告している。パイプラインの合計額が経理の見ている数字と合わない。メール配信の宛先が重複していて、同じ相手に同じ内容が2通届く。どれも「名寄せができていない」の症状ですが、現場で最初に困るのは数字が合わないことではありません。困るのは、どちらのレコードが正しいのかを決める人が社内にいないことです。

株式会社100はHubSpotの認定エリートパートナーとして、複数の事業部・複数のシステムから顧客データが流れ込む組織のCRM統合を支援しています。その過程で必ず通るのが重複レコードの整理です。そして毎回、技術的な作業よりも統合ルールの合意に時間がかかります。理由は単純で、マージは取り消せない操作だからです（「It's not possible to unmerge records.」）。

この記事では、HubSpotの名寄せで何が自動化され、何が人の判断として残るのかを分解し、統合ルールを決める順序と、重複を再生産しないための入口設計までを整理します。データを1つの正に揃える考え方そのものはSSOT（信頼できる唯一の情報源）とデータガバナンスに整理しているため、本記事はその実装編にあたります。

HubSpotの名寄せは、どこまでが自動で、どこからが判断なのか？

名寄せという一語の中に、自動処理と人の判断が混ざっています。この2つを分けないまま「HubSpotは名寄せしてくれますか」という問いを立てると、答えがどちらにも転びます。まず自動で処理される範囲を確定させます。

自動で重複排除される範囲は、どこまでか？

コンタクトはEメールアドレス、企業は会社ドメイン名を見て、自動的に重複排除されます。手動作成時に既存と同じ値を入れようとするとアラートが出ますし、フォーム送信では既存コンタクトに情報が追加される挙動になります。

ここで押さえておくべき例外が1つあります。APIで作成された企業には、会社ドメイン名による重複排除が適用されません。外部システムから企業レコードを流し込んでいる組織で重複が増え続ける原因の多くは、この挙動です。連携を設計する時点で、受け側ではなく送り側で一意性を担保する必要があります。

私たちがポータルの現状を診断するときは、まず「この企業レコードはどの経路で作られたか」をレコードソースで分類します。画面からの手入力、フォーム、インポート、API、連携アプリ。経路ごとに重複の発生率がまったく違うため、ここを分けずに件数だけ数えても打ち手が決まりません。

インポート時は、何をキーに同一と判定されるのか？

インポートの重複排除には3つの軸があります。全オブジェクト共通のレコードID、コンタクトのEメール、企業の会社ドメイン名です。レコードIDの列に値がない行だけが、新規レコードとして作成されます。

加えて、カスタムの一意値プロパティを重複排除に使えます。1オブジェクトあたり最大10個まで設定でき、プロパティの作成時にのみ指定できます（Set validation rules for a property）。基幹システムの顧客コードを持ち込みたい組織では、この枠をどう使うかが設計の分かれ目になります。

インポートファイル自体にも上限があります。有料プランでは1ファイルあたり1,048,576行・512MB、列は1,000列未満、1日あたり10,000,000行までで、無料プランでは20MB・500,000行が上限です。こうした上限は改定されることがあるため、大規模移行を計画する時点で現行値を見ておいてください。インポートの実務はHubSpotのインポートにまとめています。

自動では防げない重複は、どこから入ってくるのか？

自動排除が効くのはEメールとドメインという「同じ文字列かどうか」で判定できる軸だけです。実務で問題になる重複は、ほとんどがこの軸の外側にあります。

1. 個人のメールアドレス違い — 異動・改姓・部署用アドレスへの変更で、同一人物が別レコードになる
2. 法人格・表記ゆれ — 「株式会社○○」「（株）○○」「○○株式会社」が別企業として登録される
3. グループ会社とドメイン共有 — 持株会社と事業会社が同一ドメインを使い、逆に1社が複数ドメインを持つ
4. 事業所・支店の扱い — 本社と支店を別レコードにするか、1レコードにするかの合意がない
5. 外部連携の往復 — 他システム側で重複しているものが、そのまま流れ込む

このうち1から4は、ツールの設定では解けません。解くのは「自社にとって企業の1件とは何か」という定義です。この定義を決めずにマージを始めると、作業が進むほど判断がぶれます。

マージは、なぜ「戻せない操作」として設計に組み込むべきなのか？

マージはボタン1つで実行できますが、実行後に元の2件へ戻す機能は用意されていません。取り消せない操作を日常業務の権限に含めるかどうかは、情報システム部門が判断すべき論点です。何が起きるのかを具体的に見ていきます。

マージすると、何が統合され、何が失われるのか？

統合の既定動作は次のとおりです。プロパティ値は主レコードの値が優先され、主レコードに値がない項目だけ副レコードの値が入ります。作成日は古いほうが残り、プロパティ履歴は両方が統合され、アクティビティのタイムラインと関連付けも両方が引き継がれます。

失われるのは「2件だった」という構造です。レコードIDは新しいものが発行されます（Primary ID Preservationのベータに登録しているアカウントでは主レコードのIDが維持されます。詳細はマージ後のレコードID保持に整理しています）。旧IDは「Merged record IDs」プロパティから参照でき、誰がいつマージしたかも確認できますが、どちらの値がどちらのレコードのものだったかは、プロパティ履歴を1件ずつ追う作業になります。

見落とされやすいのは、プロパティ値のタイムスタンプがマージ実行時に更新される点です。「最終更新日が3か月以内のレコード」といった条件でセグメントやワークフローを組んでいる場合、マージ作業そのものが大量のレコードを条件に合致させてしまいます。アクティブなセグメントは条件に合致したレコードを自動で出し入れする仕様のため（Create active or static lists）、マージを実行する前に、日付系プロパティを条件に使っているワークフローとセグメントの登録条件を洗い出してください。

実行権限も確認してください。マージの実行には「レコードのマージ」権限またはスーパー管理者権限が必要です。HubSpotの権限はCRMオブジェクトの閲覧・編集・削除それぞれについて対象範囲を設定する構造になっており（HubSpot user permissions guide）、マージ権限はこの範囲設定とは別枠で管理します。

主レコードと副レコード、どちらを残すべきか？

既定では主レコードの値が優先されるため、どちらを主にするかが結果を決めます。私たちがクライアントと決めるときの判断順序は次のとおりです。

1. 関連付けが多いほうを主にする — 取引・チケット・アクティビティがぶら下がっている側
2. 外部システムと同期している側を主にする — 連携のキーが切れると復旧工数が跳ね上がる
3. 入力が新しい側ではなく、正しい側を主にする — 新しさと正しさは別物
4. 判断がつかない場合はマージしない — 保留のまま残すほうが、誤ったマージより安い

4つ目が最も重要です。取り消せない操作に対する既定の答えは「やらない」であるべきです。判断がつかないペアを溜めておく置き場所を先に作っておくと、現場が無理にマージしなくなります。

マージが実行できないのは、どういうときか？

マージが失敗する条件はいくつかあります。最も知られていないのが累計回数の制限です。

2つのレコードが関わったマージの累計が250回以上になると、それ以上マージできません。たとえば、Contact A と Contact B がそれぞれ130回のマージに関わっている場合がこれに当たります。この状態に達したら、新規レコードを作るか手動で編集するしかありません。長年の運用で名寄せを繰り返してきた大規模ポータルでは、実際に到達します。

ほかに、関連付けの上限を超える場合、企業で親子関係にあるレコード同士の場合もマージできません。処理自体にも時間がかかり、最大30分を要することがあります。一括作業の計画では、この待ち時間を見込んでください。

オブジェクトごとに、統合の挙動はどう違うのか？

「マージの挙動」は1種類ではありません。オブジェクトによって、どの値が勝つかのルールが変わります。移行計画を書くときは、この差を一覧にしておくと関係部署との合意が早くなります。

オブジェクトの考え方そのものはHow to use objects for business processesに整理されています。どの単位をレコードにするかの設計を飛ばしたまま重複を潰しても、同じ重複が別の形で戻ってきます。

APIから統合する場合も挙動は同じです。objectIdToMerge と primaryObjectId を指定してマージを実行します（Merge two companies、Merge two tickets、Merge two objects with same type）。スクリプトで一括処理する場合、取り消せない操作をループで回すことになるため、実行前に対象一覧をエクスポートして人の目を通す工程を必ず挟んでください。オブジェクトAPIの共通仕様はUsing Object APIsに、プロパティの定義と取得はProperties APIに整理されています。

統合ルールは、誰がどの順序で決めるのか？

名寄せのプロジェクトが止まる原因は、作業量ではなく決裁者の不在です。「どちらが正か」を決める権限を持つ人が決まっていないと、現場は手を止めます。決めるべき項目を順序どおりに並べます。

企業の一意キーを、何に置くか？

最初に決めるのはこれです。ドメイン、法人番号、基幹システムの取引先コードのいずれを「同一企業の判定軸」にするか。この選択は経営の問いであって、システムの都合ではありません。

ドメインを軸にすると、HubSpotの自動重複排除とそのまま噛み合います。一方で、持株会社と事業会社が同一ドメインを使っている場合や、M&Aで複数ドメインが残っている場合に破綻します。法人番号を軸にすると法人格の単位で正確に揃いますが、HubSpot側の自動排除は効かないため、一意値プロパティと検証ルールで担保する必要があります。取引先コードを軸にすると会計との突合は楽になりますが、見込み客の段階ではコードが存在しません。

私たちが設計するときは、ドメインを既定の軸に置いたうえで、法人番号を一意値プロパティとして併設し、受注後にコードを付与する三段構えにすることが多くあります。どの段階でどの軸が主になるかを先に決めると、現場が迷いません。

システム間で値が食い違ったとき、どちらを正とするか？

マージの話に見えて、実はシステム間の優先順位の話です。顧客名は基幹システム、担当者情報はCRM、与信情報は会計、といった形で、項目ごとにどのシステムを正とするかを表にします。

この表を作ると、部門間の議論が「どちらが正しいか」から「どの項目をどちらが持つか」に変わります。所有を分けた時点で、サイロの議論も具体化します。組織横断のデータ設計については組織のサイロを解消するデータ設計に整理しています。

判断に迷うペアを、どう扱うか？

重複候補のすべてが重複ではありません。HubSpotの重複管理ツールには、重複ではないと判断して両方を残す「拒否」の操作があります。拒否したペアは以降のスキャンに出てきません。

精度を上げる仕組みも用意されています。「Refine suggestions」から最大3つのプロパティを選び、値が異なるペアを候補から外せます。業種や所在地のように、同一企業なら一致するはずの項目を選ぶと、ノイズが大きく減ります。

運用として決めておくべきは、拒否の判断を誰がするかです。拒否も「戻しにくい操作」であるため、作業者が単独で判断できる範囲を決めておきます。私たちが運用ルールを作るときは、拒否は作業者が実行してよいがログを残す、マージは承認者を立てる、という切り分けを標準にしています。

重複を「作らない」ための入口設計は、どう組むか？

既存の重複を片付けても、入口が開いたままでは同じ状態に戻ります。片付けと並行して、入口を塞ぐ作業を進めてください。ここを後回しにしたプロジェクトは、半年後に同じ数の重複を抱えます。

検証ルールと一意値プロパティで、何を防げるか？

プロパティ単位で入力の形式を縛れます。テキスト・電話番号・数値のプロパティでは、一意の値を必須にできます。前後の空白を許可しない設定、正規表現によるカスタムルール、文字数の上下限も指定できます。

ただし適用範囲には穴があります。ワークフロー、チャットフロー、ミーティングスケジュールページへの送信、旧エディタで作成したフォームからの送信には、検証ルールが適用されません。入口を塞いだつもりで、塞げていない経路が残りやすい箇所です。プロパティ設計の基礎はHubSpotのプロパティにまとめています。

インポートの運用ルールを、どう決めるか？

重複の発生源として最も頻度が高いのがインポートです。複数オブジェクトを同時に取り込むこともできます。運用として決めるのは、技術ではなく手続きです。

私たちがクライアントに置いていただくルールは4つです。第1に、インポートは申請制にして実行者を限定する。第2に、ファイルには必ずレコードIDか一意値の列を含める。第3に、本番実行の前に少量で試し、作成件数と更新件数の内訳を確認する。第4に、実行後にインポート履歴から対象を追えるよう、ファイル名に日付と目的を含める。

外部システムとの連携で、重複はどう生まれるか？

連携の仕様を理解していないと、片側の重複が両側に広がります。HubSpotはSalesforceのリードとコンタクトをEメールアドレスで識別します。同じEメールを持つ複数レコードがある場合は、最初に返されたレコードと同期し、以降は直近に更新されたレコードと同期します。

この挙動が意味するのは、連携先の重複を放置したままHubSpot側だけを整えても、同期のたびに揺り戻しが起きるということです。連携を伴う名寄せでは、どちらのシステムを先に整えるかを工程表に明記してください。連携の全体像はHubSpotとSalesforceの連携に整理しています。

既存の重複は、どの順序で片付けるのか？

一度にすべてを片付けようとすると、判断の質が落ちます。私たちが実際に使っている進め方を、工程として示します。全体で3か月程度を見込む規模感です。

順序の要点は、第3段階を第4段階より前に置くことです。入口を塞ぐ前に既存処理を始めると、作業中にも新しい重複が生まれ、終わりが見えなくなります。

検出のためのツールはHubSpot側に用意されています。データ品質ツールはMarketing Hub・Sales Hub・Service Hub・Content Hub・Data HubのStarter以上、Smart CRMとRevenue HubはProfessional以上で利用でき、重複・書式の問題・データ欠落・未使用プロパティといった区分で問題を検出します（Use data quality tools）。プロパティの異常検出はData HubのProfessional以上の機能です。書式の問題については、提案を個別に受け入れるか、ルール化して以降を自動処理するかを選べます（Use data quality tools）。ガバナンスとしての進め方はMaintain a trusted source of customer dataに、スキーマ定義・フィールドレベル権限・検証ルールという順序で整理されています。AIによる重複検出と書式修正の運用はデータエージェントによるCRMデータクレンジングに整理しています。

名寄せの成果は、どの指標で測るのか？

重複件数だけを追うと、途中で評価が止まります。件数は作業量に連動するだけで、業務が改善したかを示しません。私たちが定着フェーズで見る指標を挙げます。

第1に、新規発生件数の週次推移。入口対策の効果はここに出ます。第2に、主要顧客（取引金額上位）における重複ゼロの維持。全件を追うより、影響の大きい範囲を守るほうが現実的です。第3に、必須プロパティの記入率。名寄せの副産物として、空欄が埋まっているかを見ます。第4に、拒否されたペアの件数と理由の分布。ここに「判断がぶれている」兆候が出ます。

指標の置き場所も決めてください。カスタムレポートで作っておけば、月次の定例で自動的に見る状態になります（Create custom reports）。見る場が決まっていない指標は、必ず形骸化します。

法令・ガバナンスの観点では、何を押さえるべきか？

名寄せは情報の精度の問題であると同時に、法令対応の論点でもあります。稟議で「なぜ今やるのか」を問われたとき、業務効率だけでは弱い場面があります。

個人情報保護法第22条は、利用目的の達成に必要な範囲内で個人データを正確かつ最新の内容に保つよう努めること、利用する必要がなくなったときは遅滞なく消去するよう努めることを定めています。個人情報保護委員会のガイドライン（通則編）は、この対応として入力時の照合・確認の手続の整備、誤りを発見した場合の訂正等の手続の整備、記録事項の更新、保存期間の設定を挙げています（個人情報の保護に関する法律についてのガイドライン（通則編））。

同ガイドラインは、一律に又は常に最新化する必要はなく、利用目的に応じて必要な範囲内で正確性・最新性を確保すれば足りるとも記しています。つまり「全件を完璧に揃える」ことが要求されているわけではありません。どの範囲をどの精度で保つかを自社で決め、その手続きを整備することが求められています。この整理は、名寄せの対象範囲を絞る根拠としてそのまま使えます。

削除についても運用を決めておきます。削除されたレコードは、90日以内であれば復元できます。恒久的な削除やGDPR関連の削除はごみ箱に保持されず復元できず、GDPR削除は最大30日かけてシステムから完全に除去されます。マージと削除は別の操作であり、戻し方も異なります。

自動化と手作業、それぞれの利点と限界は何か？

名寄せを「全部自動でやりたい」という要望は必ず出ます。公正に整理すると、自動化が効く領域と効かない領域ははっきり分かれます。

結論として、自動化は「候補を出すところまで」と「入口で防ぐところ」に使い、統合の実行そのものは重要度に応じて人を挟むのが安全です。取り消せない操作を無人で回す構成は、規模が大きいほど事故の影響が大きくなります。ワークフローで書式を揃える自動化は有効なので、利用できるアクションの一覧（Choose your workflow actions）を確認したうえで、HubSpotのワークフローと組み合わせて設計してください。

よくある質問

マージしてしまったレコードを、元の2件に戻す方法はありますか？

ありません。マージの取り消しはできません（「It's not possible to unmerge records.」）。近い状態に戻す手段としては、コンタクトなら追加のEメールアドレスを削除してからそのアドレスで新規作成する、企業なら追加ドメインを削除してからそのドメインで新規作成する方法があります。ただし関連付けやアクティビティは戻らないため、復元ではなく再作成です。

重複が大量にあります。全部マージすべきでしょうか？

全件を対象にする必要はありません。影響の大きい範囲から順に処理し、判断がつかないものは保留にしてください。個人情報保護委員会のガイドラインも、利用目的に応じた必要な範囲で正確性を確保すれば足りると記しています。対象範囲を絞る判断は、法令上も説明がつきます。

法人番号で名寄せしたいのですが、HubSpotは対応していますか？

法人番号を専用に扱う標準機能についての記載は、公式ナレッジベースで確認できませんでした。実装としては、法人番号を格納するカスタムプロパティに一意値を必須とする設定を行い、インポート時の重複排除キーとして使う方法を取ります。1オブジェクトあたり最大10個という一意値プロパティの枠内で設計してください。

重複の判定に、AIを使うことはできますか？

HubSpotのデータ品質ツールには、重複するコンタクトと企業を検出してマージを提案する機能と、書式の問題を解決するルールの適用機能があります。提案を受け入れるか拒否するかは人が判断する設計です。判定の自動化よりも、候補の抽出精度を上げる使い方のほうが実務では効果が出ます。

マージ権限を、営業担当者に与えてよいでしょうか？

取り消せない操作であることを踏まえると、既定では与えないことをおすすめします。マージの実行には専用の権限またはスーパー管理者権限が必要です。営業現場からは「目の前の重複をすぐ直したい」という要望が出ますが、重複を報告する導線を用意し、実行は限定したメンバーが行う運用のほうが、結果的に処理速度が落ちません。

マージが「できません」と表示されます。原因は何ですか？

失敗条件は、累計250回以上のマージ履歴、関連付け数の上限超過、企業の親子関係にあるレコード同士の3つです。累計回数に達した場合は、新規レコードを作成するか手動編集で対応するしかありません。処理自体に最大30分かかることもあるため、反映待ちの可能性も確認してください。

名寄せのプロジェクトは、どれくらいの期間を見ればよいですか？

規模によりますが、本記事で示した5段階で進める場合、合意形成に最も時間がかかります。技術的な作業よりも、一意キーの決定とシステム間の優先順位の承認が律速になります。工程表を引く際は、作業日数ではなく意思決定の回数で見積もってください。当社が支援する場合も、最初の2段階に全体の半分程度の期間を配分しています。

まとめ：名寄せで最初に決めるべきことは何か？

この記事の内容を、着手順に整理します。

1. マージを「戻せない操作」として扱う — 権限と承認を、削除と同じ重さで設計する
2. 企業の一意キーを決裁する — ドメイン・法人番号・取引先コードのどれを軸にするかは経営判断
3. 項目別に正とするシステムを表にする — 「どちらが正しいか」ではなく「どちらが持つか」に論点を移す
4. 入口を既存処理より先に塞ぐ — 検証ルール、一意値プロパティ、インポートの申請制
5. 対象範囲を絞る根拠を持つ — 利用目的に応じた必要な範囲で足りるという整理を使う

重複レコードは、データ入力の雑さから生まれるのではありません。同じ対象を何と呼ぶかの定義が組織内で統一されていないことから生まれます。定義を決めずに統合作業だけを進めると、作業が終わった時点でまた重複が増え始めます。データサイロが事業に与える影響と同じ構造の問題です。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、顧客データの統合ルール策定から実装・定着までを支援しています。自社のポータルでどこから着手すべきか具体的にご相談がある場合は、お問い合わせからご連絡ください。

最終更新日: 2026年10月23日（本記事の記載は同日時点の公式ドキュメントおよび公的ガイドラインに基づきます。仕様・上限・提供条件は変更される可能性があるため、実装前に一次情報をご確認ください）