%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
HubSpotのマージは取り消せません。重複の管理ツールの場所、残る側の選び方、マージ後に残る値、重複を生まない設定を、判断表と手順で整理します。
HubSpotの重複レコード管理は、「データ品質」の「重複を管理」タブで重複の候補を確認し、残す側を決めてマージする作業です。ただしマージは取り消せません。 公式ナレッジでも、個別・一括・カスタムルールのいずれのマージも元に戻せないと明記されています。最初に決めるべきなのは、操作の手順よりも「どちらを残し、どの値を採用するか」の基準です。
重複を統合したいと思って画面を開くと、似たレコードが並んでいても、どちらを残すか、どの値が消えるかが分からず手が止まります——「名寄せ」と呼ばれる作業のうち、HubSpotの画面で実行できる範囲と、実行後に戻せない点を整理します。
- ツールの場所と検出条件 ── コンタクトと会社で、何を手がかりに重複と判定されるか
- 残す側の決め方 ── 一括マージの結合条件5種類を、どの場面で選ぶかの判断表
- マージ後に残る値 ── プロパティー・アクティビティー・関連付け・ワークフローの扱い
- 戻せない点と戻せる点 ── 却下の取り消しと、メール・ドメインから再作成する方法
- 重複を生まない設定 ── 入力経路ごとの対策と、一意の値プロパティー
重複の管理ツールの場所と、検出の仕組み
重複の確認は、データ品質ツールの中の専用タブで行います。公式ナレッジ（日本語版）によると、対象製品は Marketing Hub、Sales Hub、Service Hub、Data Hub、Smart CRM で、対象プランは Professional と Enterprise です。使うには、データ品質ツールへのアクセス権と、コンタクトまたは会社の「編集」権限（スーパー管理者でも可）が必要です。
画面の場所は2通り
1つ目は、「その他」→「データ管理」→「データ品質」を開き、「重複を管理」タブを選ぶ方法です。2つ目は、コンタクトまたは会社の一覧画面の右上の縦に並んだ3つの点のアイコンから「重複を管理」を選ぶ方法です。一覧から入ると、そのオブジェクトの重複に絞って確認できます。
編集権限がコンタクトと会社の片方にしか無い場合は、権限のあるオブジェクトの重複だけが管理できます。権限が足りずに「タブが見えない」「会社だけ出ない」ときは、まず権限設定を疑います。権限の設計はHubSpot権限設定・チーム管理ガイドで整理しています。
何を手がかりに重複と判定されるか
既定の判定に使われるプロパティーは、オブジェクトごとに決まっています。
| オブジェクト | 既定の判定プロパティー | 見落としやすい点 |
|---|---|---|
| コンタクト | 名、姓、Eメールアドレス、IPの国、電話番号、郵便番号、会社名 | 判定の材料が多く、会社より類似度を細かく見られる |
| 会社 | 会社のドメイン名、会社名、国／地域、電話番号、業種 | ドメインが空の会社は、名前や電話番号の一致に頼る |
検出は、新しいコンタクトや会社が作成されるたびに計算され、加えて1日に1回、レコードが作成されていないかが確認されます。つまり、大量インポートの直後に画面を開いても、すべての候補が出そろっていない場合があります。候補の絞り込みは、所有者・作成日・類似度・前回のアクティビティー日・発見日・ライフサイクルステージで行えます。
カスタムルールで判定を足す
既定の判定で拾えない重複には、カスタムルールを作れます。作成には Data Hub の Professional または Enterprise が必要で、「重複を管理」タブでオブジェクトを選び、「新しいルールを追加」から「カスタムルールを作成」を選びます。上限はオブジェクトごとに2ルール、1ルールあたり9プロパティーです。
公式ナレッジには、州／地域のような広いプロパティーだけで構成すると、追加のプロパティーを求められるとあります。電話番号、カスタムID、連携システムの一意なIDのように、個体を特定しやすいプロパティーを入れるほど精度が上がります。
マージの前に決める「残す側」の基準
マージでは、2つのレコードのうち一方が「プライマリー」（残る側）、もう一方が「セカンダリー」（統合される側）になります。個別マージでは1件ずつ選べますが、件数が多いと一括マージを使うことになり、その場合は結合条件で自動的に決まります。
一括マージの結合条件5種類
公式ナレッジに示された条件は次の5つです。どれを選ぶかで、残る側が変わります。
| 結合条件 | 残る側 | 向いている場面（当社の見解） |
|---|---|---|
| 直近のエンゲージメント | 前回のエンゲージメント日が最も新しいレコード | 営業が実際に連絡を取っている側を残したいとき |
| 最も古いエンゲージメント | 前回のエンゲージメント日が最も古いレコード | 通常は選ばない。意図がある場合に限る |
| 最初に作成 | 作成日が最も古いレコード | 古いIDを他システムが参照していて、変えたくないとき |
| 最後に作成 | 作成日が最も新しいレコード | 新しい入力経路のほうが正確だと確認できているとき |
| 直近の更新 | 最も新しく更新されたレコード | 運用中の側を残したいとき。非表示の内部プロパティーの更新も評価される点に注意 |
最後の行の補足は重要です。「直近の更新」は、画面に表示されない内部プロパティーの更新も評価対象になります。画面上は動いていないレコードでも、内部の更新で「新しい」と判定される場合があるため、一括で実行する前に、少数のペアで結果を確認してください。
マージルール（ベータ）で順序を組む
Data Hub の Professional または Enterprise で、ベータ版への参加が済んでいれば、条件を順番に評価するマージルールを作れます。前の条件で決まらないときに次の条件を判定する仕組みで、条件には「プロパティーの状態」「関連付けが最も多いもの」「記録されたアクティビティー数が最も多いもの」「最高充填率」を選べます。同点のときのための選択肢もあります。1ルールに置ける条件の数やプロパティーのオーバーライドの上限は、確認した公式ナレッジに記載がないため、設定画面で確かめてから設計します。
当社では、取引や活動が最も多く紐づくレコードを残す方針を、まず検討します。後から付け替える関連付けの数が少なく済むためです。ベータ機能のため、本番ポータルで使う前にテスト用のペアで挙動を確認してください。
残す側の基準は、マージを実行する前に文書で決めておきます。一括マージの結合条件は、一度走ると結果を戻せないため、「なぜその条件にしたか」を後から説明できる状態にしておくことが、運用上の最大の保険です。
マージ後に残る値と、変わる値
次に、マージの結果として何が起きるかを確認します。以下は、公式ナレッジ「レコードのマージ」に記載された既定の動作です。マージ自体は、別記載がない限りすべての製品とプランで使え、レコードのマージ権限（またはスーパー管理者権限）が必要です。
共通の扱い
| 項目 | マージ後の扱い |
|---|---|
| レコードID | 既定では新しいIDが発行される。以前のIDは「マージされた［レコード］ID」プロパティーで確認できる。ベータ版「統合レコードのプライマリID保持」に登録済みなら、プライマリーのIDが保持される |
| 作成日 | 古いレコードの値が残る |
| プロパティー値 | 原則としてプライマリーの値。プライマリーが空ならセカンダリーの値。タイムスタンプはマージ実行日時 |
| プロパティー履歴 | 両方の履歴が統合される |
| アクティビティー | 両方のタイムラインのアクティビティーが新しいレコードに表示される |
| 関連付け | 両方が引き継がれる。会社の「プライマリー」ラベルはプライマリー側が優先される |
| 静的セグメント | セカンダリーはすべての静的セグメントから外れる |
ここで見落としやすいのは、レコードIDが変わる点です。外部システムや自作のスクリプトがHubSpotのレコードIDで連携している場合、マージ後は旧IDで参照できなくなる可能性があります。連携の鍵に何を使っているかは、マージの前に確認します。ポータルがIDの保持ベータに登録済みかも、あわせて確認してください。関連付けキーの設計はHubSpot移行の関連付けキー設計で整理しています。
コンタクトと会社の例外
| 対象 | 例外の内容 |
|---|---|
| コンタクト | セカンダリーのメールは追加メールになる。ライフサイクルステージは最も進んだ段階。マーケティングステータスは最もマーケティング可能な値。コンバージョン数と送信フォーム数は合算 |
| 会社 | プライマリーのドメインが維持され、セカンダリーのドメインは追加ドメインになる。ライフサイクルステージは最も進んだ段階。アナリティクス値は合算 |
| 共通（トラフィック） | オリジナルトラフィックソースは最も古い値（手動更新があればその値） |
| チケット | 担当者は、関連するコミュニケーションのうち最後に更新されたものの担当者 |
ライフサイクルステージが「最も進んだ段階」になる点は、レポートの集計に効きます。たとえば、片方が「リード」、もう片方が「顧客」だった場合、マージ後は「顧客」になります。ステージ別の件数や転換率を月次で見ている場合は、マージの前後で数字が動くことを、関係者に事前に伝えておくと混乱を避けられます。
ワークフローと外部連携への影響
プライマリーは登録されたままですが、セカンダリーはマージ時点で有効だったすべてのワークフローから登録解除されます。ベータ版の「統合レコードのプライマリID保持」に登録していない場合は、両方が登録解除される点が公式ナレッジに明記されています。進行中のフォローが途切れるため、ステップメールや営業シーケンスの対象レコードをマージする前には、登録中のワークフローを確認します。ワークフローの登録状況の見方はHubSpotワークフローが動かない原因と確認手順にまとめています。
Salesforce連携では、コンタクトはプライマリーのみが同期を継続します。会社は、旧バージョンの連携ではマージできず、新バージョンではマージできます。
戻せない点と、戻せる点
「戻せますか」という質問への答えは、対象によって分かれます。ここは、公式ナレッジの記述を分けて整理します。
| 操作 | 戻せるか | 根拠と条件 |
|---|---|---|
| マージ（個別・一括・カスタムルール） | 戻せない | 公式ナレッジに明記 |
| 却下（非重複として除外した提案） | 戻せる | 却下から最大14日間、「履歴のビュー」から「元に戻す」。その間にレコードのプロパティーなどを変更すると対象外になる |
| マージ済みレコードの再作成 | 条件付き | セカンダリーのメールやドメインを使って新規レコードを作れる。ただし、統合後のレコードから該当のメールやドメインを先に削除する必要がある |
マージの後に分離するときの考え方
再作成は、元のレコードを復元するものではありません。新しいレコードが作られるだけで、元のレコードのアクティビティーや履歴、関連付けは自動では戻りません。したがって、「戻せる」ではなく「同じメールやドメインで新しく作り直せる」と理解しておくのが正確です。
誤ってマージした可能性がある場合の実務は、次の順で進めます。
- 「マージされた［レコード］ID」プロパティーで、統合に関与したレコードを一覧画面でフィルターして特定する
- マージ前に自分でエクスポートしておいた控えと、データ品質ツールで行ったマージなら「マージ履歴のエクスポート」（マージ前のプロパティー値を含む）を突き合わせ、失われた値を洗い出す
- 必要に応じて、統合後のレコードからセカンダリー側のメールまたはドメインを削除し、新規レコードを作成する
- 失った活動や関連付けを手作業で付け替える
公式ナレッジでは、マージ履歴のエクスポートはデータ品質ツールで行ったマージだけが対象で、最大90日前までです。個別のレコード画面など他の経路で行ったマージは対象外のため、期間を過ぎたものや対象外のマージでは、マージ前の自前のエクスポートが突き合わせの元になります。このため、マージ前のエクスポートは最初の備えとして取っておきます。
却下の運用で気をつけること
却下した提案は表示されなくなりますが、却下済みのペアに含まれるレコードが別のレコードとマージされると、重複チェックのツールに再び表示される場合があります。却下の理由を記録しておかないと、再び表示されたときに「前に判断したはず」という議論になります。却下と保留の違いを、運用ルールに書いておくことを勧めます。
マージが止まる条件と、事前に見ておく上限
マージは、条件によって実行できない、または失敗します。公式ナレッジに記載された制限を、事前確認の観点でまとめます。
| 制限 | 内容 | 事前にやること |
|---|---|---|
| コンタクトの件数 | 合計250件以上のマージに含まれるコンタクトはマージできない | 大量の重複グループは、分割して実行する |
| 関連付けの上限 | 上限を超えるとマージが失敗することがある | 関連付けを減らしてから再試行する |
| 親子関係の会社 | マージできない、または失敗することがある。親子関係にループがあると失敗する | 親子関係を先に確認し、必要なら整理する |
| 通話中のレコード | 通話中にマージすると、通話は自動的に切断される | 通話中でない時間帯に実行する |
| 同期の完了 | 全アクティビティーの同期に最大30分かかることがある | 実行直後に件数を確認せず、時間をおいて見る |
重複管理ツールにも件数の上限があります。個別管理は最大10,000組の重複ペア、一括管理は Data Hub の Professional で最大30,000組、Enterprise で最大100,000組です。この数を超える規模の場合は、画面操作の前に、対象を絞り込む計画が要ります。
マージの履歴は、「重複を管理」タブの「アクション」から「マージ履歴のエクスポート」で取れます（Data Hub の Professional または Enterprise が必要）。公式ナレッジでは、データ品質ツールで行ったマージについて、最大90日分の履歴をエクスポートできるとされています。監査ログでは、自動マージされたレコードと却下された提案を、手動マージと区別して確認できます。
重複を生まないための設定と入力経路の整理
マージは対症療法です。同じ重複が毎月発生するなら、入口の設計に原因があります。ここでは、公式ナレッジで確認できた範囲で、入力経路ごとの対策を整理します。
入力経路別の重複の発生源と対策
| 入力経路 | 重複が生まれる典型 | 対策（公式ナレッジで確認した範囲） |
|---|---|---|
| インポート | 一意の識別子が無い行は、既存レコードと照合できず新規作成になる | レコードIDまたはメール／ドメイン／一意の値プロパティーを含める |
| 手入力（画面） | 表記ゆれ・別の担当者による重複登録 | 一意の値を要求するプロパティーを設定する |
| 外部システムとの連携 | 連携元のIDがHubSpotに無く、毎回新規作成になる | 連携システムの一意IDを、一意の値プロパティーで持つ |
インポートで照合に使われる識別子
公式ナレッジのインポート記事は、すべての製品とプランが対象です。照合の優先順位は、まずレコードID（全オブジェクト共通で最優先）、次にコンタクトならEメール、会社ならドメイン名、そして一意の値を要求するカスタムプロパティーです。ファイルにレコードIDが無い行は、新規レコードとして作成されます。
「インポート方法」は3種類から選びます。「レコードの作成と更新」は新規作成と既存更新の両方、「新規のレコードの作成のみ」は既存に対応する行を無視、「既存のレコードの更新のみ」は新規行を無視します。既存データの補正が目的なら、「更新のみ」を選ぶと、意図しない新規作成（＝重複）を防げます。ただし更新のみには、一意の識別子が必要です。
セカンダリメールだけでは照合できない点にも注意が必要です。レコードIDを含めない限り、セカンダリメールはプライマリメールの代わりにはなりません。また、既存のEメール、ミーティング、メモ、タスクは更新できず、再インポートすると重複が生じる可能性があるとされています。インポート全般の手順はHubSpotインポートでコンタクト移行を成功させる手順、エラー時の対応はHubSpotのインポートエラーの直し方に整理しています。
一意の値を要求するプロパティー
プロパティーに「固有の値」を要求する設定は、次の手順で行います。設定には「プロパティー設定の編集」権限が必要です。
- 上部ナビゲーションバーの設定アイコンをクリックし、左のサイドバーの［プロパティー］を開く
- ［オブジェクトを選択］から対象オブジェクトを選び、対象プロパティーの名前をクリックする
- ［ルール］タブを開き、固有の値のオプションをオンにする（1行テキスト・複数行テキストは「このプロパティーには固有の値」が必要です、電話番号・数値は「このプロパティーでは、重複にならない値を必須にする」）
- ［作成］または［保存］をクリックする
公式ナレッジでは、フィールドタイプは1行テキスト、複数行テキスト、電話番号、数値で、オブジェクトごとに最大10個まで作れます。ルールはCRMの画面からの入力とインポートの両方に適用され、同じ値を複数のレコードに入力できなくなります。一方で、ワークフロー、チャットフロー、ミーティングのスケジュール設定ページからの送信、旧エディターで作成されたフォームからの送信には適用されません。この例外は、自動で値を書き込む経路が多いポータルでは見落とされがちです。
なお、公式ナレッジには、既に重複がある状態で設定したときの挙動が記載されていません。また、「作成時のみ設定できる」という記述と、既存プロパティーのルールタブから設定する手順が併記されており、整合していません。既存のプロパティーに追加できるかは、設定画面で確認してから進めてください。
マージ作業の進め方（当社の推奨手順）
ここからは当社の見解です。公式ナレッジが示すのは機能の仕様で、「どの順序で実行するか」は運用の設計です。企業様（チーム）によって最適な形は異なりますので、自社の権限構成と件数に合わせて調整してください。
マージを実行する前の確認と実行の手順
- 判定の対象を決める。コンタクトか会社か、どのライフサイクルステージまでか、所有者の範囲を絞る
- 対象レコードをエクスポートして控えを取る。マージ前のプロパティー値と、関連付けの件数を残す
- 残す側の基準を文書にする。結合条件（またはマージルール）、タイブレークの方針、例外の扱いを書く
- 連携の鍵を確認する。外部システムがレコードIDやメールで参照していないかを確認する
- 登録中のワークフローとシーケンスを確認する。進行中のものがある場合は、マージの時期を調整する
- 10〜20組程度の少数で実行し、結果を確認する。残った値、関連付け、ライフサイクルステージを見る
- 問題がなければ、対象を広げて一括で実行する。件数の上限と250件の制限に注意する
- 実行後、時間をおいて件数を確認し、「マージされた［レコード］ID」でフィルターして結果を記録する
手順6の少数での試行は、公式に求められているものではありません。取り消せない操作の前に、小さな範囲で確認するという当社の運用上の勧めです。
誤判定を防ぐための見分け方
重複の候補に見えても、実際は別の人物や別の会社であることがあります。たとえば、同じ会社名でも別の拠点、同じ電話番号でも代表番号を共有する別の担当者、といった場合です。会社名と電話番号の一致だけで一括マージすると、別の会社を誤って統合する恐れがあります。ドメインやカスタムIDのような個体を特定しやすい項目で一致するかを、まず確認してください。判断が付かないペアは、却下ではなく保留とし、判断記録に残します。
StartLinkの支援の進め方：重複を工程の中で扱う
重複の管理は、掃除の作業ではなく、設計・移行・運用の各工程に組み込むものと考えています。当社は、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の工程で支援しており、重複については次のように工程へ割り当てます。
| 工程 | 重複に関する作業 | 成果物 |
|---|---|---|
| 現状の整理・要件定義 | 重複管理ツールで候補の規模を把握し、連携の鍵と、重複が生まれる入力経路を洗い出す | 入力経路の一覧、残す側の基準案 |
| 設計・構築 | 一意の値プロパティーとカスタムルールを設計し、インポートの照合キーを決める | 識別子の設計書 |
| データ移行 | 移行前に元データ側の重複を整理し、移行後に重複の件数を照合する | 移行後の重複の照合記録 |
| テスト・検証 | テスト用のペアでマージの結果を確認し、ワークフローへの影響を見る | マージの試行結果 |
| 定着・運用改善 | 週次で候補を確認する担当を決め、判断記録と却下の理由を残す | 運用ルール、判断記録 |
スモールスタートでは、最初にコンタクトか会社のどちらか1つに絞り、残す側の基準を決めて、少数のペアで試行します。結果を確認してから対象を広げる進め方です。準委任での伴走では、基準の策定と、初回の実行に同席して結果を共有し、以降は自社で回せる状態にしていきます。
重複の根本には、入力の経路が複数あることが多く、連携アプリで埋められる部分もあります。当社は、HubSpotゴールドパートナーであり、Sync for freee / Sync for Notion の開発元として、外部システムとの連携で識別子を揃える設計も扱っています。移行後の重複の照合はHubSpotデータ移行の検証手順、運用の定着は週次パイプラインレビューとデータ品質ダッシュボード、重複の考え方全般はCRMデータクレンジングの設計と運用と企業データ名寄せ実務ガイドをご覧ください。
よくある質問
Q1. HubSpotでマージした重複レコードを元に戻せますか。
できません。公式ナレッジに、個別・一括・カスタムルールのいずれのマージも元に戻せないと明記されています。ただし、セカンダリーのメールアドレスまたはドメインを使って、新規レコードを作り直すことはできます。その場合は、統合後のレコードから該当のメールやドメインを先に削除する必要があります。元のレコードの履歴は戻らないため、マージ前のエクスポートを最初の備えにします。データ品質ツールで行ったマージなら、90日以内は履歴のエクスポートにもマージ前の値が残ります。
Q2. 重複の管理ツールは無料プランでも使えますか。
公式ナレッジでは、「重複を管理」ツールの対象プランは Professional と Enterprise です。なお、個別のレコードを手動でマージする機能は、別記載がない限りすべての製品とプランで利用できます。カスタムルールやマージ履歴のエクスポートには、Data Hub の Professional または Enterprise が必要です。
Q3. マージすると、ワークフローの登録はどうなりますか。
プライマリーは登録されたままで、セカンダリーはマージ時点で有効だったすべてのワークフローから登録解除されます。ベータ版の「統合レコードのプライマリID保持」に登録していない場合は、両方が登録解除されます。進行中のステップメールがあるレコードは、実行前に確認してください。
Q4. 重複レコードを自動でマージする設定はありますか。
公式ナレッジの「重複レコードの確認と管理」には、自動マージのオンとオフを切り替える設定項目の記載はありません。監査ログでは、自動マージされたレコードと却下された提案を、手動マージと区別して確認できます。設定項目としての記載があるのは、新規作成時と1日に1回の検出、手動の個別・一括マージ、条件を組むマージルール（ベータ）です。システムが自動で行ったマージの有無は、監査ログで確かめられます。自動で統合する運用を考える場合は、自社の環境で確認してから進めてください。
Q5. 重複を増やさないために、最初に何を設定すべきですか。
インポートと連携の入口で、一意の識別子を決めることです。インポートにはレコードIDまたはメール・ドメイン・一意の値プロパティーを含め、連携システムの一意IDは「固有の値」を要求するプロパティーで持ちます。ただし、ワークフローや旧エディターのフォームからの書き込みには一意の値ルールが適用されない点に注意してください。
まとめ：残す側の基準を先に決めてから、マージを実行する
- マージは取り消せない ── 却下は14日間戻せるが、マージは戻せない。実行前のエクスポートが最初の備えになる。データ品質ツールのマージは90日以内なら履歴エクスポートにも前の値が残る
- 残す側は結合条件で決まる ── 一括マージの5条件のどれを選ぶかを、文書で決めてから実行する
- 値はプライマリー優先、ただし例外がある ── ライフサイクルステージ、ドメイン、メールなどは別の規則で統合される
- ワークフローの登録解除に注意 ── セカンダリーは登録解除される。進行中の自動化を確認する
- 入口の識別子で重複を減らす ── インポートの照合キーと一意の値プロパティーを設計する
最初の一歩は、「重複を管理」タブで、コンタクトまたは会社のどちらか一方の候補件数を確認し、10〜20組を目視で見ることです。残す側の基準案を作ってから、少数で試行してください。自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
参考：公式ナレッジ
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
