CRMと会計ソフトの情報を手作業で合わせていませんか。HubSpot Data Hubを検討するときは、接続できる機能を探す前に、どの情報を誰が更新し、どの業務で使うかを決めることが出発点です。
「同じ会社情報をスプレッドシートとCRMの両方に入力している」「表記揺れや重複があり、レポートの数字を判断に使いにくい」「標準ワークフローでは必要な処理を組み立てられない」。こうした課題があると、担当者による個別の確認や補正が続き、更新内容も部門ごとに分散します。
この記事は、CRMの管理者や、営業・マーケティング・顧客対応をまたぐデータの流れを見直したい方に向けています。HubSpot Data Hubの同期、品質管理、自動化、レポートに関わる機能を、業務上の判断と結び付けて整理します。最初に扱うデータを選び、動作を確認してから対象を広げるための手順も示します。
HubSpot Data Hubは、HubSpot CRMと外部アプリのデータ同期、データ品質の管理、ワークフローによる自動化を支える製品です。ただし、機能を有効にするだけでデータの使い方が決まるわけではありません。コンタクトや会社の情報を、取引や顧客対応、その先の業務へどう受け渡すかを先に設計します。
本記事は「AI × CRMで企業価値を上げる設計思想|経営者が知るべきAI CRM戦略」シリーズの一部です。この分野の体系的な情報はHubSpot機能ガイドでまとめています。
本記事はStartLinkの「AI活用完全ガイド」関連記事です。
この記事でわかること
データ連携の対象を決めるところから、同期後の確認、品質管理、自動化へ進むところまで、次の順に説明します。
- Data Hubの役割 — CRM内外の情報を、どの業務へ受け渡すかを整理します。
- データ同期の考え方 — 更新元、レコードの照合、項目の対応、対象範囲を決める順序を示します。
- データ品質の整え方 — 重複や表記揺れが影響する業務を特定し、使う項目を見直します。
- 自動化とレポートの使い分け — 標準機能で足りるかを確かめ、拡張が必要になる条件を整理します。
- 導入時の確認点 — 小さな対象で結果とエラーを確認し、次の対象へ進む条件を決めます。
読み終えたら、まず改善したい業務を一つ選び、その業務に必要なデータ、更新責任者、確認方法を対応付けられるようになります。
Data HubはCRMのデータを業務の流れにつなぐ基盤です
HubSpotの各Hubが担う業務の中で、Data Hubはデータの同期や品質管理、自動化に関わります。機能を選ぶ際は、連携先の数ではなく、情報を受け渡した後に誰が何を判断するかを確認します。
| Hub |
役割 |
| Marketing Hub |
リード獲得・ナーチャリング・MA |
| Sales Hub |
営業管理・パイプライン・SFA |
| Service Hub |
カスタマーサポート・サクセス |
| Content Hub |
Webサイト・ブログ・CMS |
| Data Hub(Data Hub) |
データ同期・品質管理・自動化基盤 |
たとえば、会社情報を営業が更新し、マーケティングと顧客対応が参照するなら、更新元と参照先を区別します。取引の結果を請求業務へ渡したいなら、受け渡す項目と、受け取った側で確認する担当者まで決めます。この関係が曖昧なまま接続を増やすと、情報の食い違いが起きた際に修正先を判断できません。
分散した入力を一元管理に近づける
スプレッドシート、会計ソフト、CRMに同じ会社名や連絡先を個別に入力している場合は、最初に項目ごとの用途を調べます。営業が更新する会社情報、会計ソフト側で管理する請求関連情報など、業務上の更新元を分けてください。
次に、HubSpotで参照したい情報を選びます。更新元が明確で、参照する部門も決まっている項目なら、同期の設計に進めます。どちらのシステムでも同じ項目を編集している場合は、先に更新責任を決めるか、競合時の扱いを確認します。
データの流れをコンタクトから請求まで捉える
データ同期や品質管理は、単独で完結する施策ではありません。コンタクトや会社の情報が取引にどう引き継がれ、顧客対応や請求業務で何を参照するかを順に確認します。
| 業務の段階 |
HubSpotで扱う情報の例 |
次の段階につなぐ観点 |
| コンタクト・会社 |
連絡先、会社情報、接点履歴 |
取引先と担当者の関係を保つ |
| 取引 |
営業状況、金額、進捗情報 |
受注後に顧客情報へつなぐ |
| 顧客対応 |
問い合わせやサポートの記録 |
営業時の情報を参照できるようにする |
| 請求 |
取引に基づく請求関連情報 |
会計ソフトなど外部の業務へ渡す |
各段階について「次の担当者が判断に使う情報は何か」を問い、使う項目から整えます。引き継ぎ先も用途も決まっていない項目は、入力や同期の対象を増やす前に必要性を見直します。
製品の名称だけで導入範囲を決めない
Data Hubの機能を検討する際は、解消したい手作業と必要な処理を対応付けます。連絡先を外部アプリからHubSpotへ受け渡したいなら同期設定を検討します。取引の進捗に応じて請求関連の処理を始めたいなら、開始条件、作成する情報、受け取り側の仕組みまで確認します。
必要な情報の流れを説明できる状態になってから、対象アカウントで利用できる機能を調べます。機能名は選択肢を探す手がかりであり、導入範囲は業務上の目的と運用体制で決めます。
データ同期は方向・対象・項目を決めてから有効にします
Data Syncは、HubSpotと接続アプリの間で対象データを一方向または双方向に同期する機能です。公式ガイドでは、接続後に同期対象のオブジェクトを選び、同期方向やフィールドマッピングを設定する流れが案内されています(出典:Connect and use HubSpot data sync)。
次の表は機能を比較するための一覧です。実際の利用可否は、対象アカウントの表示と契約時点の公式案内で確認してください。使いたい機能が表にあっても、接続先アプリや対象オブジェクトが業務要件に合うかは別に確認します。
| 機能 |
Free |
Starter |
Professional |
Enterprise |
| データ同期(基本) |
対応 |
対応 |
対応 |
対応 |
| カスタムフィールドマッピング |
- |
対応 |
対応 |
対応 |
| データ品質ツール |
一部 |
一部 |
対応 |
対応 |
| カスタムコードアクション |
- |
- |
対応 |
対応 |
| Webhook |
- |
- |
対応 |
対応 |
| Data Studio |
- |
- |
- |
対応 |
| カスタムオブジェクト |
- |
- |
- |
対応 |
| 高度な権限設定 |
- |
- |
- |
対応 |
同期方向は更新の責任者で選ぶ
最初に、項目ごとに更新するシステムと担当者を書き出します。片方だけで変更を管理できる項目なら、その側からの一方向同期を検討します。両方で編集する必要がある項目は、競合時にどちらを優先するか決められる場合に双方向同期を検討します。
| 同期の方式 |
データの流れ |
選ぶときの確認点 |
| 双方向 |
HubSpotと接続アプリの間 |
両システムで同じ項目を編集するか。競合時に優先する側を決められるか |
| HubSpotから外部へ |
HubSpotから接続アプリへ |
HubSpotを更新の基準にできるか |
| 外部からHubSpotへ |
接続アプリからHubSpotへ |
外部側を更新の基準にできるか |
すべての項目を同じ方向にする前提では考えません。更新元を決められない項目は一旦対象から外し、業務担当者と扱いを決めてから追加します。
同期するレコードを照合する
同期方向が決まったら、外部アプリのレコードとHubSpotのレコードをどう対応付けるか確認します。照合に使う情報が欠けていたり、同じ値を複数のレコードが持っていたりすれば、意図した対応関係を作れません。対象データに重複や空欄がないかを先に調べます。
接続先を検討する際は、アプリの分類に加えて、自社で使うオブジェクトと照合方法を確認します。
| カテゴリ |
アプリ例 |
| CRM/SFA |
Salesforce、Microsoft Dynamics、Zoho CRM |
| 会計 |
QuickBooks、Xero、NetSuite |
| Eコマース |
Shopify、WooCommerce |
| ヘルプデスク |
Zendesk、Freshdesk |
| データベース |
Google Sheets、Airtable |
| その他 |
Mailchimp、ActiveCampaign |
メールアドレスや会社のドメインなど、両システムで一貫して管理されている項目は照合条件の候補になります。ただし、選べる方法はアプリやオブジェクトによって異なります。設定画面で利用可能な照合方法を確かめ、対象を絞って既存レコードとの対応結果を見てから先へ進みます。
項目の対応と対象範囲を絞る
HubSpotのプロパティと外部アプリのフィールドを対応付け、値の意味と更新方向を確認します。フィールドマッピングの作成やカスタマイズを検討する場合は、対象アカウントの利用条件と設定画面を確認してください(参考:Understand your data sync field mappings)。
同期設定は、次の順に組み立てます。
- 同期したいオブジェクトと、HubSpot側の対応先を決めます。対応先が曖昧なら、レコードの用途を整理します。
- 照合項目を選び、既存データで同じレコードを判別できるか調べます。重複や空欄が残る場合は、照合条件か対象データを見直します。
- 項目ごとに値の意味、更新元、同期方向を確認します。意味が異なる項目や更新元が決まらない項目は対象から外します。
- 必要に応じてフィルターで対象を絞り、担当者が結果を確認できる範囲で同期します。
- 同期後にレコードの対応、更新された値、エラーを確認します。想定と一致した項目から対象を広げます。
以下の画面は、HubSpotデモ環境の「接続されたアプリ」一覧です。アプリ名や状態などを確認する画面例で、個々の同期結果は示しません。

連携数よりも運用上の責任分担を優先する
接続後に情報の食い違いが見つかった場合、どちらのシステムを直すか決めていなければ対応が止まります。同期対象の項目ごとに、更新元、結果を確認する人、情報を利用する部門を記録します。
双方向同期が必要な項目では、両側で変更が起きた場合の扱いを設定で選べるか確認します。優先ルールと修正担当を決められたら対象に加え、決められなければ同期範囲から外して運用を整理します。
データ品質は重複の統合と使う項目の整理から改善します
データ品質を見直すときは、まず不備がどの業務に影響しているかを確認します。重複したコンタクトが連絡履歴の確認を妨げているのか、表記揺れがレポートの分類を難しくしているのかによって、先に直す対象は変わります。
品質管理で確認する機能の例を以下に示します。利用できる機能や処理方法は、対象アカウントの表示を確認してください。
| 機能 |
内容 |
| 重複検出・マージ |
重複コンタクト/会社を自動検出し、マージを提案 |
| フォーマットの自動修正 |
電話番号、日付、氏名のフォーマットを自動統一 |
| データ異常アラート |
データ品質の低下を検知して通知 |
| プロパティの利用分析 |
使用率の低いプロパティを特定 |
以下の画面は、HubSpotデモ環境の「データ品質」概要です。重複や書式の問題、推奨対策が表示されています。件数は撮影時のデモ値です。

重複や表記揺れが後続業務へ与える影響を整理する
同じ人のコンタクトが複数登録されていると、連絡履歴が分かれて確認しにくくなります。会社名の表記が「株式会社」「(株)」のように揺れると、会社単位の検索や集計にも確認が必要になります。
修正前に、対象レコードを利用するリスト、取引、レポートを確かめます。統合するレコードや残す値を判断できる場合は修正に進み、判断できない場合は利用部門に確認します。修正後は、影響を受けた業務で期待する情報を参照できるか見直します。
不要なプロパティを減らして入力を分かりやすくする
項目が増えると、入力する人が用途を判断しにくくなります。利用状況を確認し、使われていないように見えるプロパティは、削除対象と決める前に参照先を調べます。
ワークフロー、ビュー、レポート、外部連携で使われているなら、用途を記録して残すか、参照先の変更を検討します。参照先がなく、今後の業務でも使わないと確認できた項目から整理を進めます。入力画面では、後続の判断に必要な項目の意味と担当者が分かるようにします。
不備を個人の注意ではなく仕組みで防ぐ
「正しく入力してください」と伝えるだけでは、担当者による判断差が残ります。照合条件、同期対象のフィルター、入力ルール、更新後に確認する処理を組み合わせ、不備が生じる場面を特定します。
次の表は、更新元を考える際の運用例です。実際の反映の仕方は接続先と設定で確認し、業務で求める更新方法に合うかを判断します。
| モード |
動作 |
使用シーン |
| 双方向同期 |
両方のシステムの変更がリアルタイムに反映 |
CRMとCRMの併用 |
| HubSpot→外部 |
HubSpotの変更が外部に反映 |
HubSpotをマスターにする場合 |
| 外部→HubSpot |
外部の変更がHubSpotに反映 |
外部システムをマスターにする場合 |
運用開始時には、結果を確認する担当者と、修正内容を決める担当者を分けて記録します。同じ不備が繰り返される場合は個別のレコードだけを直すのではなく、入力元、照合条件、項目の対応のどこで生じているかを見直します。
自動化は標準ワークフローから始め必要な処理だけ拡張します
自動化する前に、開始条件、実行する処理、変更されるレコード、失敗時の確認先を書き出します。その処理を標準ワークフローで表せるなら、対象を絞って動作を確認します。標準機能では必要な処理を表せない場合に、カスタムコードやWebhookを検討します。
以下の画面は、HubSpotデモ環境の「自動化」内にあるワークフロー一覧です。名称やオン・オフなどの管理項目が並ぶ画面例で、各処理の実行結果は示していません。

自動化する業務条件を先に定義する
たとえば、取引が特定のステージに進んだら請求関連の処理を始めたい場合、まず対象となる取引をどう判別するか決めます。次に、受け渡す情報、同じ処理が重複して起きた場合の扱い、失敗に気付く担当者を整理します。
条件と期待する結果を説明できたら、標準ワークフローのアクションで組み立てられるか確認します。必要な結果が得られれば、その方法で運用します。足りない処理が具体的に分かった場合だけ拡張方法を比較します。
カスタムコードは標準機能で不足する処理に使う
カスタムコードアクションは、標準アクションだけでは表しにくい処理をワークフローに組み込む際の候補です。利用を検討する場合は、対象アカウントで使える言語や実行条件を公式資料と設定画面で確認してください(参考:Unlocking the Power of Webhooks & Custom Workflow Actions in HubSpot’s New Developer Platform)。
| ユースケース |
内容 |
| 請求書の自動分割 |
受注時に12ヶ月分の請求レコードを自動作成 |
| 外部API連携 |
会計ソフトやERPのAPIを直接呼び出し |
| 複雑なデータ変換 |
住所の正規化、金額の通貨変換 |
| AI連携 |
外部のLLM APIを呼び出してデータを分類・要約 |
| 条件分岐の拡張 |
標準のIF/THENでは対応できない複雑なロジック |
表の処理は用途の例です。実際に取り組む際は、業務上必要な結果から方法を選びます。
| 処理の例 |
まず検討する方法 |
拡張を検討する場面 |
| 条件に応じた担当者通知 |
標準ワークフロー |
条件判定が標準機能で表しにくい |
| 取引情報の更新 |
標準ワークフロー |
複数項目の変換や複雑な計算が必要 |
| 外部システムへの連絡 |
利用可能な連携機能 |
専用のWebhookやAPI処理が必要 |
| 請求情報の作成 |
既存の連携や標準処理 |
取引条件に応じた複雑な作成ロジックが必要 |
カスタムコードを採用する前に、保守担当者、処理の記録方法、入力と出力の確認方法、エラー時の対応を決めます。これらを担う体制が決まらない場合は、標準機能で扱える範囲を先に運用し、不足する要件を整理します。
Webhookは外部システムへのイベント通知に使う
外部システムで処理を続ける必要がある場合は、Webhookを候補にします。送る情報だけでなく、外部側が受け取れる形式、受信後の処理、失敗時に確認する担当者を合わせて設計します。
標準機能や既存の連携で必要な結果が得られるなら、その動作を確認して進めます。外部側に受信処理と保守担当を用意でき、失敗からの復旧方法も決められる場合にWebhookの利用を検討します。
Data Studioやレポートは意思決定に必要なデータから組み立てます
レポートを作る前に、誰が何を判断するために使うかを決めます。次に、指標の定義、元になるレコード、項目の更新元を確認します。集計結果に疑問が出たとき、元の情報までたどれる状態が必要です。
先に管理したい指標と更新元を決める
営業の進捗を確認するなら取引のステージや金額、マーケティング活動を確認するなら対象レコードや接点情報など、判断に必要な項目を洗い出します。同じ名称でも部門ごとに意味が違う項目があれば、集計前に定義を揃えます。
| 確認項目 |
判断の例 |
| 指標の利用者 |
営業担当者が日々使うか、マネージャーが全体を見るか |
| 元データ |
HubSpot内の取引か、外部システムの実績か |
| 更新責任 |
どのシステム・部門が変更するか |
| 集計単位 |
コンタクト、会社、取引のどれを基準にするか |
| 不足時の対応 |
必要項目を追加するか、別データとの統合を検討するか |
元データと更新責任を説明でき、HubSpot内の情報で目的の判断ができるなら、既存のレポートから始めます。数字の解釈が利用者によって分かれる場合は、レポートを増やす前に項目や集計単位の定義を見直します。
外部データとの統合が必要かを見極める
HubSpot内にない会計情報や業務データが判断に必要なら、どの情報が足りないかを特定します。そのうえで、Data Studioなどで必要なデータソースとレポート要件を扱えるか、対象アカウントの機能表示と公式案内で確認します。
外部データを加えても、元になる項目の意味や更新ルールが揃っていなければ、集計結果の確認は難しくなります。まずHubSpot内のデータで確認できる部分を整理し、不足する情報と統合後の確認担当が決まった段階で範囲を広げます。
導入は対象を絞って同期し結果を見ながら広げます
導入の最初の対象には、利用する部門、更新元、照合条件を説明できるデータを選びます。設定を増やす前に、同期した結果を誰がどこで確認するか決めておきます。
- 同期する項目は、後続の業務で使うものから選びます。結果を確認できたら次の項目を追加します。
- 同期エラーは担当者と確認方法を決めます。原因を切り分けられないまま対象を広げないようにします。
- 設定を変更したら、変更内容と確認結果を記録します。想定と異なる更新が起きた際に、設定と結果を照らし合わせます。
導入前には、確認対象と担当者も対応付けます。
| 確認対象 |
決めておくこと |
担当の例 |
| 会社情報 |
更新元と照合項目 |
営業・CRM管理者 |
| 同期エラー |
検知と再処理の手順 |
CRM管理者 |
| レポート |
指標の定義と確認頻度 |
利用部門の責任者 |
Phase 1: データの流れと責任者を整理する
利用中のツール、管理している情報、更新担当者を一覧にします。続いて、HubSpotで参照する情報と、外部システムを更新元とする情報を項目ごとに分けます。
改善したい業務を言葉にしてください。例えば次のような業務です。
- 営業が過去の接点を確認する
- 取引結果を請求処理へ渡す
目的、更新元、利用部門を対応付けられたら同期設計へ進みます。更新元が定まらない項目は、業務側で扱いを決めるまで対象から外します。
Phase 2: 代表的なオブジェクトから同期する
業務で使うコンタクトや会社などから対象を選び、照合項目、同期方向、フィールドマッピング、フィルターを設定します。対象を絞って同期した後は、既存レコードとの対応、更新された値、エラーを確認します。
重複や想定外の更新が見つかったら、対象条件、照合項目、項目の型や対応関係を調べます。原因を直し、同じ確認を行ってから対象を広げます。初期同期による業務への影響が気になる場合は、実施範囲と確認する時間帯を担当部門と調整します。
Phase 3: 品質管理と自動化を追加する
同期したレコードの対応関係と更新結果を確認できたら、重複、表記揺れ、使われていないプロパティを見直します。修正が必要な項目では、入力元や同期設定も調べ、同じ不備が生まれる条件を減らします。
その後、開始条件と期待する結果を説明できる業務から標準ワークフローを検討します。標準機能では不足する処理が明らかになり、保守担当者とエラー時の手順を決められた場合に、カスタムコードやWebhookなどの拡張へ進みます。
導入可否は必要な機能と保守体制を合わせて判断する
プランを比較する際は、使いたい機能名を並べるだけでなく、対象アプリ、オブジェクト、項目、処理後の確認方法を照合します。必要な機能が対象アカウントで利用できるかは、契約時点の公式案内とアカウント内の表示で確認してください。
| 実現したいこと |
検討する機能 |
判断の分かれ目 |
| 基本的な外部アプリとのデータ同期 |
Data Sync |
対象アプリとオブジェクトが対応しているか |
| 同期項目を調整する |
フィールドマッピング |
必要なプランでカスタマイズできるか |
| 標準機能では表せない処理 |
カスタムコード |
保守・テストを担う担当者がいるか |
| 外部システムへイベントを送る |
Webhook |
送信先の受信処理と復旧手順があるか |
| 外部データも含めて分析する |
Data Studioなど |
データソースと必要なレポートが利用可能か |
機能が利用可能でも、更新責任や復旧手順を決められない処理は導入範囲を見直します。必要な結果と運用体制を説明できる範囲から始めると、次に追加すべき機能も判断しやすくなります。
よくある質問
Data Hubは何をする製品ですか?
Data Hubは、HubSpotと外部アプリのデータ同期やデータ品質管理、自動化を支える製品です。まず改善したい業務と必要な情報を決め、同期、品質管理、自動化のどれで扱うかを判断します。
データ同期は双方向にするべきですか?
両方のシステムで同じ項目を更新する必要があり、競合時の優先ルールと確認担当を決められるなら、双方向同期を検討します。片方を更新元にできる項目は一方向を検討し、どちらを正とするか決まらない項目は同期前に運用を整理します。
カスタムコードを使うのはどのような場合ですか?
標準ワークフローで必要な処理を表せず、追加する処理の入力、出力、失敗時の対応を定義できる場合に検討します。保守やエラー対応を担う担当者が決まらない場合は、標準機能で扱える範囲を先に運用します。
Data Studioは最初から導入した方がよいですか?
HubSpot内のデータで必要な判断ができるなら、既存のレポートから始めます。外部データが必要な理由、使うデータソース、統合後の確認方法が明らかになった段階で、利用できる機能と要件を照合します。
Data Hubのプランは何を基準に選びますか?
対象アプリとオブジェクト、必要な項目の対応、標準機能で扱えない処理を先に整理します。そのうえで、必要な機能の利用可否と保守体制を比較します。プランごとの提供範囲は契約時点の公式案内とアカウント内の利用条件で確認してください。
まとめ
Data Hubを使ったデータ基盤づくりでは、最初に情報の更新元、利用部門、照合方法を決めます。同期結果を確認できた範囲から品質管理や自動化へ進み、レポートは判断に必要なデータの定義が揃ってから組み立てます。
着手する際は、次の順に進めてください。
- 手作業やデータの食い違いが起きている業務を選び、必要な情報を洗い出します。
- 項目ごとの更新元、照合条件、結果を確認する担当者を決めます。
- 対象を絞って同期し、レコードの対応、更新された値、エラーを確認します。
- 想定した結果を確認できたら対象を広げ、繰り返す不備や手作業に対して品質管理や自動化を検討します。
企業様によって最適な形は異なります。更新責任を決められる範囲と、運用後に確認できる範囲を起点に設計してください。CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
同期するデータの用途が決まったら、リードスコアリング、メール配信、フォームでどの情報を使うかも確認できます。HubSpotの機能全体から運用を整理したい場合は、機能ガイドも参照してください。