「HubSpot にデータが入っているはずなのに古い」「Salesforce と HubSpot で情報がズレている」「毎朝 CSV をエクスポートして別システムに取り込む作業が続いている」——これらはすべて Data Sync が解決する問題だ。本章では100+ アプリとの双方向リアルタイム同期の仕組み・フィールドマッピング設計・同期フィルターと競合解決ルール・Salesforce 連携の具体的設計・トラブルシューティングを体系的に解説する。
Data Sync は HubSpot と外部アプリの間で双方向・リアルタイムのデータ同期を行う機能だ。Zapier や Make のようなイベントトリガー型（「何かが起きたとき」にのみ動く）とは異なり、Data Sync は常時接続型の双方向ライブ同期——どちらのシステムでレコードが更新されても、もう一方に即座に反映される。
| 比較項目 | Data Sync（HubSpot） | Zapier / Make |
|---|---|---|
| 同期の方向 | ✓ 双方向（デフォルト） | ✗ 原則一方向（追加設定が必要） |
| リアルタイム性 | ✓ 常時接続・即時反映 | △ ポーリング型（最短5〜15分遅延） |
| 履歴データ | ✓ 初回接続時に過去データも同期 | ✗ 接続後の新規データのみ |
| 競合解決 | ✓ ルールベースで自動解決 | ✗ 手動設定が必要（複雑） |
| コスト構造 | ✓ Data Hub 料金に含まれる | △ タスク数に応じた従量課金 |
| 対応アプリ数 | △ 100+ アプリ（ネイティブ対応） | ✓ 5,000+ アプリ（幅広い） |
Data Sync が得意なのは「常に最新の状態を保ちたい主要ビジネスシステム（CRM・ERP・サポートツール）との双方向同期」。Zapier・Make が得意なのは「HubSpot ネイティブ連携のない細かいツールとの一方向トリガー連携・スプレッドシートへの通知送信」など。主要5〜10システムは Data Sync、その他はツールで補完という組み合わせが多くの組織での正解だ。
Data Sync で最も多く相談される統合は Salesforce との連携だ。多くの企業が「Salesforce を営業チームの主戦場、HubSpot を Marketing の主戦場」として使い分けているため、2つの CRM の間でどのデータをどの方向に同期するかの設計が組織のデータガバナンスの中核になる。
双方向同期では「HubSpot と外部アプリの両方でほぼ同時にデータが更新された場合、どちらを正とするか」という競合（コンフリクト）が発生する。Data Sync ではフィールドごとに競合解決ルールを設定できる。
「どちらが正かわからないから最新を優先」という設定は、マーケティングが丁寧に設定したセグメント情報を Salesforce からの古い更新が上書きするという問題を引き起こす。フィールドごとに「どのチームが責任を持つか」を決め、そのチームが使うシステムを「優先」に設定するのが正しいアプローチだ。
Data Sync の標準設定では、システム間の「名前が同じフィールド」は自動的にマッピングされる。しかし実際の統合ではフィールド名が異なる・データ型が異なる・変換が必要なケースが大半だ。カスタムフィールドマッピングでこれらを明示的に設定する。
① オブジェクトのレベルで対応を整理する——Salesforce の Lead・Contact・Account・Opportunity は HubSpot の Contact・Contact・Company・Deal にそれぞれ対応する。まずオブジェクト単位で何を同期するか決め、その後フィールドを決める。
② Picklist（選択肢）の値変換ルールを事前定義する——Salesforce の LeadSource = "Web" を HubSpot では "Organic Search" に変換するといった値のマッピングが必要なフィールドがある。変換表を事前にスプレッドシートで作成してから HubSpot に設定すると後戻りが少ない。
③ 新しいカスタムプロパティは HubSpot 側に先に作る——HubSpot に存在しないプロパティに同期しようとするとエラーになる。Salesforce 側のカスタムフィールドを HubSpot にマッピングする前に、HubSpot の「プロパティ設定」から対応プロパティを作成しておく。
統合設計前にスプレッドシートで「Salesforce フィールド名 / データ型 / HubSpot プロパティ名 / データ型 / 同期方向 / 競合ルール / 値変換の要否」の列を持つマッピング台帳を作成する。これが後の設定・デバッグ・引き継ぎを劇的に楽にする。実際の設定作業より台帳作成に時間をかける価値がある。
Data Sync のデフォルト設定では接続したアプリのすべてのレコードが同期される。しかし全件同期は「ノイズデータの流入」「CRM の肥大化」「不要な重複」「AI 精度の低下」を引き起こす。フィルター設計によって「必要なデータだけを、必要な方向に、必要なタイミングで」同期する設計が重要だ。
Data Sync のデフォルト設定では、外部アプリでレコードを削除した場合に HubSpot 側も削除される（またはその逆）。誤削除が伝播するリスクがあるため、削除の同期（Delete Sync）は基本的に無効にし、必要な場合のみ有効化するのがベストプラクティスだ。「アーカイブ」や「Status = Inactive」フィールドでの論理削除に変換する設計が安全。
Data Sync を本番運用に乗せた後、最も重要なのは「同期が止まっていることに気づくまでの時間を短くする」こと。同期エラーに気づかずに数日間データが古い状態で営業・マーケティングが動いていた——という事態を防ぐ監視設計が必要だ。
| 監視項目 | 確認方法 | 推奨頻度 | アラート設定 |
|---|---|---|---|
| 同期ステータス | 設定 → 統合 → 接続済みアプリ → 各アプリの「同期」タブ | 週1回 | Paused になったら HubSpot がメール通知 |
| 同期エラー数 | 同期ログの「エラー」フィルター → 件数トレンドを確認 | 週1回 | エラー率が5%を超えたら調査開始 |
| スキップレコード数 | 同期ログの「スキップ」フィルター → 理由別集計 | 月1回 | スキップが急増したらフィルター設定を確認 |
| 重複レコード生成数 | データ品質 → 重複タブ（第2章で詳述） | 週1回 | 重複数が前週比 +20% 以上で調査 |
| API 認証の有効期限 | 接続済みアプリの認証情報の有効期限確認 | 四半期 | 期限30日前にカレンダーリマインダー |
Zapier・Make のイベントトリガー型（発生時のみ動く・一方向・遅延あり）とは異なり、Data Sync は常時接続・双方向・即時反映・履歴データ初回同期に対応。主要ビジネスシステム（Salesforce・NetSuite・Zendesk等）との統合には Data Sync が最適解。
HubSpot と Salesforce のどちらが「正」かは全体で決めるのではなくフィールドごとに決める。Marketing 管理フィールドは HubSpot Wins、Sales 管理フィールドは Salesforce Wins が基本。「最新優先」をすべてに適用すると意図しない上書きが発生する。
「Salesforce フィールド / HubSpot プロパティ / 同期方向 / 競合ルール / 値変換の要否」を1行ずつ記録したマッピング台帳を事前に作成する。設定後のデバッグ・引き継ぎが劇的に楽になる。特に Picklist の値変換ルールは事前に洗い出すことが重要。
全件同期はノイズデータの流入・CRM 肥大化・AI 精度低下の原因になる。「MQL 以上のリードのみ」「年商500万円以上の顧客のみ」など、マーケティング・CS が実際に使う対象に絞ったフィルター設計が CRM の品質を守る。削除の同期はデフォルト無効が安全。
同期ステータス・エラー数・スキップ数・重複生成数を週次でチェックする習慣を作る。HubSpot の Paused 通知は自動で届くが、エラー率の緩やかな増加は手動確認しないと見逃す。四半期ごとの API 認証有効期限確認もカレンダーに設定しておく。
外部アプリのデータが汚れた状態で Data Sync を開始すると、HubSpot 側に大量の重複レコードが生成される。初回同期の前に外部アプリ側のメール正規化・空欄補完・重複削除を実施してから接続する。「同期後に重複を消す」より「同期前に汚れを落とす」が正解。