HubSpot Data Syncは、外部アプリとHubSpotのレコードを、設定した条件に沿って一方向または双方向で同期する機能です。設定前に決めたいのは、どちらへ値を送るかだけではありません。誰が正しい値を決め、受け取り先で誰がその値を使うかです。
公式ナレッジでは、同期方向は「Data syncs between apps(双方向)」「Data syncs only to HubSpot(アプリからHubSpotへ)」「Data syncs only to your third-party app(HubSpotからアプリへ)」の3つから選びます。値が食い違ったときの上書き先は、方向とは別の「データ競合の解決」で決めます。初回同期の後は、変更から10分以内に反映される目安です(出典:Connect and use HubSpot data sync)。
「同じ会社情報を両方の画面に入力している」「どちらの値が正しいか分からない」「同期で意図しない上書きが起きないか心配」。こうした状況では、レコードの照合、項目の意味、値が食い違ったときの判断を分けて整理します。会社名が届いても、別の顧客に結び付いていれば引き継ぎには使えません。
この記事では、営業担当者がHubSpotで会社情報を更新し、受注後の担当者が外部アプリで参照する場面を通して、連携方法の選択、同期方向、マッピング、初回同期、運用中の見直しを順に進めます。各段階で判断が分かれる条件と、次へ進む前に確かめる結果を示します。HubSpotで扱う情報の全体像は「HubSpot完全ガイド」も参照してください。
この記事でわかること
設定は、後続業務に必要な情報を決める → 項目ごとの更新元と対象レコードを決める → 接続先で選べる設定を確認する → 両側の値と後続業務で検証する順に進めます。
- 連携方法の選択 — 値を継続して渡すのか、人が確認・加工してから渡すのかを整理し、Data Sync、CSVによる更新、個別の連携設定を同じ条件で比較します。
- 同期方向の決定 — 項目ごとの更新者、利用者、正しい値の判断者を特定し、一方向と双方向を選びます。
- マッピングと競合の確認 — 項目名だけで対応付けず、意味、形式、空欄、値の食い違いについて期待する結果を決めます。
- 展開と運用の判断 — 対象外のレコードと受け取り先での作業も調べ、範囲を広げる条件と問題時の戻り先を決めます。
この記事は、Data Syncを初めて設定する管理者と、すでに接続済みで値のずれに悩んでいる運用担当者に向けています。読み進める際は、実際の業務に近い会社レコードを選び、「誰の作業に必要な情報か」「正しい値を誰が決めるか」「受け取り先で何を確認するか」を書き出してください。答えが決まらない項目は、設定を進める前に入力と確認の担当を決めます。
Data Syncの役割と顧客データの流れ
Data Syncは、接続したアプリ間で対象レコードの情報をそろえるための機能です。まず、情報が入力・修正・利用される画面を業務の流れに沿って並べます。
両方の画面で値を見たい場合と、両方で編集したい場合では、選ぶ方向も確認すべき結果も変わります。
- 営業担当者がHubSpotで会社名を修正し、受注後の担当者が外部アプリで参照する ── HubSpotを更新元にする案から検討できます。
- 受注後の担当者も会社名を修正する ── その理由を聞き、営業担当者への修正依頼で業務が進むかを確認します。依頼では作業を進められない場合に、両側での編集と競合時の判断を設計します。
ここで確認するのは、同じ顧客のレコードが結び付くこと、渡す項目が同じ意味を持つこと、受け取り先で作業できることです。顧客の同一性を説明できなければ、項目の対応付けより先にレコードの照合方法を決めてください。
以下の画面は、撮影時点のHubSpot日本語版Data Hub製品ページ上部です。製品の位置づけを確認する際の画面例として参照し、現在の機能や料金はHubSpot公式ページで確認してください。
この画像は、個別の接続先で選べる同期方向や項目を示すものではありません。

同期の対象と仕組み
HubSpot Data Syncの接続と利用方法は、公式ガイドで確認できます。(出典:Connect and use HubSpot data sync)
会社情報を引き継ぐ場合は、受け取り先の作業から逆にたどって対象を決めます。
- 受注後の担当者が行う作業を決め、必要な情報がどのオブジェクトと項目にあるか特定します。
- 接続先の設定画面で、そのオブジェクトとレコードを対象にできるか確認します。
- 必要な項目を、業務に合う方向と形式で渡せるか確認します。
- 両側で同じ顧客のレコードを開き、結び付きと値を照合します。
- 受け取り先の担当者が、その情報で予定した作業を始められるか確かめます。
受注後の担当者が会社名と連絡先を使うなら、「会社を同期できる」という確認では足りません。対象の会社を特定できるか、連絡先をどの画面で確認するかまで試します。
会社名は届いても連絡先が見つからない場合は、確認する画面と担当を決めるか、引き継ぐ情報を見直します。
この段階の通過条件は、設定画面に項目が表示されることではありません。担当者が対象の顧客を特定し、必要な情報を使って作業を始められることです。
公式の設定名で読む同期方向と競合解決
設定画面は「設定(歯車)> Integrations(連携)> Connected Apps(接続済みアプリ)」から対象アプリを開き、「Set up your sync」で始めます。日本語表示では表記が異なる場合があるため、以下は公式ナレッジの英語表記に沿って整理します。
| 設定名(公式ナレッジの表記) |
動き |
選ぶ基準 |
| Data syncs between apps |
双方向。両方に存在するレコードはプロパティが統合される |
両側の担当者が同じ項目を更新する必要がある場合だけ |
| Data syncs only to HubSpot |
アプリからHubSpotへの一方向 |
外部アプリが値の確定元で、HubSpotは参照・分析に使う場合 |
| Data syncs only to your third-party app |
HubSpotからアプリへの一方向 |
営業担当者がHubSpotで確定した値を、受注後の担当者が外部アプリで使う場合 |
| データ競合の解決(既定で優先するアプリ) |
値が異なるとき、選んだアプリの値が他方を上書きする。優先側が空欄なら、他方の値は変わらない |
同期方向を上書きする設定ではない。方向を決めたうえで空欄の扱いを試す |
空欄は「消したつもり」で同期されません。優先側のアプリに値がなければ、もう一方のデータは変更されないと公式ナレッジに書かれています。値を意図して消す業務がある項目は、同期で消えない前提で手順を決めてください。
CSVや個別連携との違い
連携方法を選ぶときは、同じ会社情報について「値の確定」「受け渡し」「結果の照合」を並べます。更新頻度だけで選ばず、渡す前に人の判断や加工が必要か、渡した後に誰が確認するかを調べてください。
- 営業担当者が確定した会社名を受注後の担当者がそのまま使う ── Data Syncの対象条件とマッピングで渡せるか試します。
- 表記を人が確認・加工してから渡す ── その作業を含めてCSVによる更新を検討します。
- 業務独自の変換や条件分岐が必要 ── 処理内容と失敗時の確認先を定めてから個別の連携設定を検討します。
比較するときは、各方法で同じ問いに答えます。「誰が値を確定するか」「受け渡し前に判断が必要か」「意図しない顧客や項目の更新をどう見つけるか」です。
会社名の表記が両側で異なる場合は、方法を選ぶ前に正しい表記を判断する担当者を決めます。判断者を決めても受け渡し前の加工が必要なら、その作業を含む方法を選びます。
| 方法 |
更新の扱い |
初回にあるデータ |
| Data Sync |
設定した方向で新規・更新レコードを同期 |
初回同期で照合 |
| CSV手動同期 |
担当者が出力・加工・取り込み |
ファイルに含めて取り込み |
| 個別の連携設定 |
設定した条件や処理に沿って連携 |
連携方式による |
運用で確認することは、方法ごとに次のとおりです。
- Data Sync ── 対象範囲、項目対応、競合時の優先先
- CSV手動同期 ── 更新対象、重複、取り込み結果
- 個別の連携設定 ── 条件、変換、エラー時の再処理
カスタム項目の対応付けやデータ品質の自動化まで含めて設計する場合は、Data Hubの機能全体を先に整理すると判断しやすくなります。製品の範囲は「HubSpot Data Hubとは?データ同期・自動化・レポートの使い方」、StartLinkの支援内容はData Hub支援で確認できます。
方法を選んだら、同じ対象レコードと期待する値を使い、受け渡し後の確認まで試します。値の確定や結果の照合を担う人が決まっていなければ、その工程を決めてからテストへ進みます。
顧客情報の流れの中での位置づけ
同期結果は、受け取り先の作業までたどって評価します。受注後の担当者に対象レコードを開いてもらい、その画面で顧客を特定し、予定した作業に必要な情報を見つけられるか確かめてください。
会社名が届いても必要な連絡先が見つからなければ、対象項目か引き継ぎ手順を見直します。同じ「ステータス」という名称でも、営業と受注後の担当者で意味が異なるなら、対応付ける前に双方の定義を確認します。
| 業務の段階 |
先に決めること |
同期後に確認すること |
| 顧客情報の管理 |
管理元と更新する項目 |
両アプリの値と重複 |
| 受注後の引き継ぎ |
渡す情報とタイミング |
後続担当者が使える項目 |
| 請求・契約などの処理 |
担当者と確認方法 |
同期後の処理が完了したか |
受け取り先で確認が止まった場所によって、見直す設定を分けてください。
- 顧客を特定できない ── レコードの照合情報に戻ります。
- 顧客は特定できても作業に必要な値が足りない ── 項目と引き継ぎ手順に戻ります。
- 値が届いていても意味が違う ── 項目定義をそろえるまで対応付けを保留します。
同期方向とマスターを決める
同期方向は、アプリ全体ではなく項目ごとの更新と利用の実態から決めます。会社名など後続業務で使う項目について、次の担当を書き出してください。
- 最初に入力する人
- 誤りに気付く人
- 正しい値を判断する人
- 値を使う人
会社名を営業担当者がHubSpotで更新し、受注後の担当者が外部アプリで参照するなら、HubSpotから外部アプリへの一方向を検討できます。
その際、受け取り先で誤りを見つけた人が誰に修正を依頼し、修正後にどの画面を確認するかも決めます。依頼先が決まらなければ、方向を選ぶ前に正しい値の判断者を決めてください。
設定案は、実際の更新担当者と利用担当者に確認します。利用担当者が日常的に受け取り先で値を修正しているなら、その作業を更新元への依頼に変えられるかを試します。変えられない理由が明確になってから、両側で編集する項目として扱います。
双方向同期が合うケース
両側の担当者が同じ項目を更新する必要があり、変更した値を双方で利用する場合は、双方向同期を検討します。参照するだけの項目は、両側で編集する必要があるかを別に判断します。
テストでは、片方だけが変更した場合と、双方に異なる値がある場合を分けます。
- 片方だけが変更した場合 ── 外部アプリの同じ顧客のレコードに反映されるか確認します。
- 双方に異なる値がある場合 ── 業務担当者が残すべき値と理由を先に決め、実際の結果と照合します。
営業担当者がHubSpotで会社名を訂正し、受注後の担当者が外部アプリで別の表記に変えたとします。画面に残った値だけで正しさは判断できません。
変更理由と正しい表記の判断者を確認し、修正経路を決めてからテスト用レコードで再現します。テスト結果が期待と異なる場合は、その項目を広げる前に、どちらの画面で正式な値を確定するか決め直します。
両側で編集する理由、食い違ったときの判断者、修正経路を説明できれば、双方向の設定を試します。説明できなければ、優先先を設定する前に編集の役割を見直します。
一方向同期が合うケース
一方で更新し、他方で参照する項目には、一方向同期を検討します。HubSpotから外部アプリへ渡すか、外部アプリからHubSpotへ取り込むかは、実際に値を確定する担当と画面に合わせて決めます。
参照先で誤りを見つけた場合は、依頼先、修正する画面、修正後に確認する画面を指定します。参照先で直接修正する作業が残るなら、その変更が設定上どう扱われるかも試してください。
期待する値が残らなければ、修正依頼の手順に切り替えるか、更新元と方向を決め直します。
一方向で進める条件は、更新元で確定した値が受け取り先に届き、受け取り先で見つけた誤りも決めた経路で直せることです。
| 同期の方向 |
データの流れ |
判断の例 |
| 双方向 |
HubSpotと外部アプリの双方 |
両方で更新した値を相互に利用する |
| HubSpotから外部アプリ |
HubSpotから外部へ |
HubSpot側を情報の基準にする |
| 外部アプリからHubSpot |
外部からHubSpotへ |
外部側を情報の基準にする、またはHubSpotで参照する |
判断基準を項目ごとにそろえる
会社名、連絡先、業務上のステータスでは、更新担当が異なる場合があります。項目ごとに次の内容を記録し、接続先の設定画面で選べる内容と照合します。
- 更新する人と画面
- 利用する人と画面
- 正しい値の判断者
- 希望する方向
記録には、方向を選んだ理由も残します。たとえば会社名について「営業担当者がHubSpotで確定し、受注後の担当者は外部アプリで参照する」と書けば、担当が変わったときに方向を見直す理由が分かります。
単に「HubSpotを優先」とだけ書くと、受け取り先で修正が必要になったときの判断に使えません。
- 希望する方向を選べる項目 ── 更新担当者がテスト用レコードを変更し、利用担当者が受け取り先で値を確認します。
- 選べない項目 ── 後続業務に必須かを判断します。必須なら更新する画面を一方にそろえるか、別の受け渡し手順を決めます。別の画面で確認できるなら、その画面と確認担当を指定します。
手順で補う場合も、利用担当者が必要な値を見つけて使えるか試します。利用場面や確認担当が決まらない項目は、追加を保留します。
企業様によって最適な形は異なります。業務での入力場所と確認責任を基準に選んでください。
フィールドマッピングを設計する
フィールドマッピングでは、HubSpotのプロパティと外部アプリのフィールドを対応付けます。項目名が似ていても、値の意味や入力形式が一致するとは限りません。
判断は、意味 → 形式 → 更新方向の順です。
- 意味 ── 意味が違えば対応付けません。
- 形式 ── 意味が同じでも形式が合わなければ、入力方法や項目設計を見直します。
- 更新方向 ── そのうえで、どちらの変更を反映するかを決めます。
各項目について、同じ顧客のレコードで「送る前の値」「受け取り先で期待する値」「その値で行う作業」を並べます。たとえば会社名なら、営業担当者が確定した表記と、受注後の担当者が顧客を探す際に使う表記を照合します。
期待値を決められなければ項目の定義に戻り、決められたら正しい顧客のレコードに表示されるかを試してください。
初期設定の流れ
接続済みアプリの設定画面で、対象、方向、競合時の扱い、項目対応、レコード条件を順に確認します。表示される名称と選択肢は、利用中の環境で確かめてください。
- 接続済みアプリを開く — HubSpotの設定から「連携」内の「接続済みアプリ」を開き、対象アプリを選びます。
- 同期するオブジェクトを選ぶ — コンタクトや会社など、HubSpot側と外部側で対応させるデータ種別を決めます。
- 同期方向を指定する — 双方向か一方向かを選び、情報の管理元と合わせます。
- 競合解決を設定する — 値が食い違ったときに優先するアプリを決めます。
- マッピングを確認する — 標準の対応付けを見直し、必要な項目だけを残します。
- 対象条件を設定する — 同期対象を限定し、想定したレコードだけが対象になるか確認します。
- 設定を見直して同期を開始する — ルールを読み返し、テスト対象で同期結果を確認します。
公式ナレッジの画面名で追うと、設定は次の順に進みます。
- 「Set up your sync」を開き、「Select the data you want to sync」でアプリ側のオブジェクトとHubSpot側のオブジェクトを選びます。
- 「Configure」ページで同期方向の矢印を選び、競合解決の既定アプリを選びます。
- 「Mapped fields」で項目対応を確認します。必須項目には「*」が付きます。「Generate mappings」で候補を出し、不要な候補は個別に外します。
- 「Limit」ページで同期ルールを決めます。取引ならパイプラインとステージを「Auto-map」で対応させます。対応させたステージの取引だけが同期されます。
- コンタクトの同期では「Only sync contacts with an email address」が既定でオンです。メールアドレスのないコンタクトも対象にするときだけ外します。
- 「Review」ページで内容を読み返し、「Save and sync」で初回同期を始めます。
次の点は、設定した後に気づくと手戻りが大きい項目です。
| よくある失敗 |
公式ナレッジで確認できる事実 |
回避策 |
| フィルターで対象を絞ったのに、後から追加したレコードが同期される |
フィルターが限定するのは初回同期だけ |
継続的に対象を絞りたい場合は、取引ステージの対応やメール有無などの同期ルールで設計する |
| 項目や選択肢を追加したのに反映されない |
ドロップダウン選択などは初回同期で現在の値と選択肢をコピーする。新しい選択肢や型の変更は自動では拾われない |
選択肢を変えたら設定を保存し直して同期を再開する。保存し直すと初回同期がやり直される点も計画に入れる |
| 担当者(オーナー)が空になる |
オーナーはメールアドレス、次に名前で照合する。両方のシステムにユーザーが必要 |
同期前に、両側のユーザーのメールアドレスをそろえる |
| カスタム項目を対応付けられない |
カスタムのマッピングにはData Hubのサブスクリプションが必要(未契約でも「Try out custom mappings」で試せる) |
標準の対応で足りるかを先に確認し、足りない項目だけData Hubの対象にする |
| 取引ステージが対応しない |
取引ステージ・チケットステータスは、アプリ側の値がHubSpotのプロパティのラベルと完全に一致する必要がある |
ラベルの表記ゆれを先に直す |
項目の対応の細則は、公式の「Understand your data sync field mappings」で確認できます(出典:Understand your data sync field mappings)。1つの氏名項目は、最初の語が名、残りが姓として対応付けられるため、名と姓の両方の対応をオンにしてください。メールアドレス・電話番号・住所のような複数の値を持つ項目は、カスタム項目に対応付けられません。
開始前には、対象に入るレコードと入らないレコードを選び、両者を分ける業務上の条件を説明できるようにします。
- 対象レコード ── 受け取り先で使う項目と期待値を記録します。
- 対象外レコード ── 除外する理由を記録します。
受注後の引き継ぎに必要な会社だけを対象にするなら、引き継ぎ対象と対象外の会社を用意します。設定条件が業務上の判断と一致することを確認してから結果を見ます。
対象外の会社まで変わった場合は、マッピングより先に対象条件とその会社の値を調べます。
以下の画面は、HubSpotデモ環境の「接続されたアプリ」一覧です。接続先を探し、アプリ名や状態などを確認する際の画面例として参照してください。
個々の同期結果を示すものではないため、対象アプリを選んだ後は、その接続先で表示される設定と処理状態を確認します。

項目名でなく意味と形式を合わせる
電話番号を対応付ける場合は、双方で同じ連絡先の情報を表しているかを実際の値で確認します。自由入力と選択式のように形式が違う場合は、設定画面のマッピングと更新方向を確かめ、受け取り先で値を使えるか試します。(出典:Understand your data sync field mappings)
特に「ステータス」は名称だけで判断できません。一方が商談状況、他方が受注後の処理状況を表すなら、別の情報です。
両側の担当者に選択肢の意味を確認し、対応する値を判断します。対応しない値があれば、その値を持つレコードで後続担当者が何をするか確認し、入力ルールを直すか、その項目の追加を保留します。
| 確認項目 |
設計時に見る点 |
判断 |
| 項目の意味 |
同じ顧客情報を指しているか |
意味が異なる場合はマッピングしない |
| データ形式 |
文字列、選択肢、数値などが扱えるか |
変換できない場合は項目設計を見直す |
| 選択肢 |
値の名称や意味が対応しているか |
対応しない値があれば選択肢を整理する |
| 更新方向 |
どちらから値を更新するか |
双方で更新する理由がなければ一方向にする |
| 必須項目 |
同期先で入力が求められる項目か |
空欄でエラーになるなら取得元を定める |
意味と形式が合っていても、空欄時に担当者が作業できなければ、その項目の入力元と確認手順を決めます。通常の値と空欄を分けて試し、どちらの状態でも次の作業を判断できるようにしてから追加します。
同期対象は必要な項目に絞る
項目を追加する前に、「この値が届かなければ、誰のどの作業が止まるか」を確認します。
- 作業に必要な値 ── 管理元、意味、形式を照合し、テスト用レコードで正しい顧客に期待する値が届くことを確かめます。
- 別の画面で確認できる値 ── その画面と確認担当を記録したうえで、同期対象に含める必要性を判断します。
- 利用場面や値の意味を説明できない項目 ── 追加を保留します。
- 必要でも希望する形式や方向で渡せない項目 ── 入力方法を見直すか、担当者が確認する手順を決めます。
追加した項目には、期待する値と確認担当を設定記録に残します。入力担当や利用場面が変わった際は、その記録を起点に、方向とマッピングを続けてよいか見直します。
競合解決ルールと重複を扱う
双方に異なる値があるときは、設定上の優先先と業務上の正しい値を分けて考えます。更新した人と目的を確認し、どちらを残すべきか決めてから、設定結果と照合してください。
値の食い違いとレコードの重複も別の問題です。
- 食い違い ── 同じ顧客の同じ項目に異なる値がある状態です。
- 重複 ── 両側で開いたレコードが業務上同じ顧客を指すかを確認します。同一性を判断できなければ、値の優先先を調整する前に照合方法を決めます。
競合時の優先アプリ
設定画面で競合時の優先先を確認し、双方に異なる値がある場合と、片方が空欄の場合を分けて試します。空欄の扱いは予想せず、実際の結果と業務上の期待を照合してください。(出典:Connect and use HubSpot data sync)
- 食い違いのテスト ── 残すべき値とその理由を操作前に記録します。
- 空欄のテスト ── 未入力なのか、担当者が意図して値を消したのかを確認します。
理由によって期待する扱いが違うなら、同じ設定で両方の業務を進められるかを判断します。進められなければ、空欄を作る業務手順か、その項目の受け渡し方法を見直します。
HubSpot側で会社名を訂正し、外部アプリ側に以前の表記が残っている場合も、まず正しい表記を決めます。同期後の値がその判断と違ったら、管理元の方針、操作前の値、マッピング、同期方向を確認します。
原因を説明できるまで、同じ項目の対象を広げません。
項目単位で管理元を決める
同じオブジェクトでも項目ごとに更新担当が異なる場合は、項目名、更新担当、希望する方向、設定画面での選択可否を並べます。
希望する方向を選べない項目は、後続業務で必要かを確認します。
- 不要な場合 ── 対象から外します。
- 必要な場合 ── 更新する画面を一方にそろえられるか検討します。
- それも難しい場合 ── 元の値を確認する人、修正する画面、受け取り先で照合する項目を決めてください。担当者や照合方法を決められなければ、その項目の追加を保留します。
会社名は営業担当者が更新し、別の項目は受注後の担当者が更新するなら、それぞれの利用先と修正経路を確認します。設定と更新元が一致する項目から試し、手順で補う項目は、受け取り先で必要な情報を使えたことを通過条件にします。
レコード照合と重複の確認
項目の対応が正しくても、別の顧客に結び付けば業務では使えません。両側に同じ顧客がある場合と、片側にだけある場合を分け、意図したレコードに結び付くか、重複が増えていないかを調べます。
名前が似ているだけで同一と判断せず、業務上同じ顧客と確認できる情報を見比べます。判断できないレコードは、識別情報の修正担当と確認手順が決まるまで、対象に含める判断を保留します。
記録には、次の内容を残します。
- 両側で開いたレコード
- 同じ顧客と判断した理由
- 判断した担当者
同一性を説明できてから、そのレコードの値の更新結果を評価します。結び付く先が想定と異なれば、項目の値を直す前に照合情報を確認します。
初回同期と範囲を小さく始める
初回同期では、既存レコードがどのように扱われるかも確認します。対象アプリ、オブジェクト、項目、レコード条件を絞り、処理状態と両側の値を確かめてから対象を広げてください。
範囲を広げる条件は、次のとおりです。
- 結び付き ── 対象レコードが正しく結び付くこと。
- 値の利用 ── 必要な値を受け取り先で使えること。
- 対象外 ── 対象外のレコードに意図しない変更がないこと。
処理の表示だけで判断せず、操作前に決めた期待値と実際の結果を比べます。説明できない状態のレコードがあれば、その状態を含む範囲への展開を保留します。
初回同期で確認すること
対象に入る予定のレコードと対象外にする予定のレコードを、両方の画面で確認します。対象レコードでは結び付きと値を、対象外レコードでは意図しない変更がないことを調べます。処理中の表示がある場合は、結果を確定する前に状態を見直します。
| 初回同期の確認項目 |
確認する内容 |
| 対象範囲 |
想定したレコードだけが対象か |
| 項目対応 |
値の意味と形式が合っているか |
| 競合時の扱い |
管理元の値が意図どおり優先されるか |
記録には「操作前の両側の値」「変更した画面と項目」「期待する操作後の値」「実際の操作後の値」「後続担当者の作業結果」を並べます。
たとえば会社名の更新なら、変更前の両側の表記、営業担当者が修正した画面、受け取り先で期待する表記、実際に表示された表記、受注後の担当者が顧客を特定できたかを記録します。
- 対象は合っていても値が違う ── 方向やマッピングを調べます。
- 値が合っていても担当者が使えない ── 項目の意味や引き継ぎ手順を見直します。
- 対象外のレコードが変わった ── 対象条件に戻ります。
調べた原因と再確認の結果を残し、同じ状態のレコードへ広げてよいか判断します。
テスト用レコードで動作を確かめる
新規作成、更新、食い違い、空欄、対象外の状態を分けて試します。それぞれ操作前の両側の値と期待する結果を記録し、操作後に照合してください。
- 新規作成 — 対象となる顧客をどちらの画面で作るか決め、受け取り先で意図した顧客として確認できるか調べます。見つからなければ、対象条件とレコードの照合に戻ります。
- 更新 — 管理元の会社名を変更し、受け取り先の同じ顧客の値を確認します。別の項目が変わった場合はマッピングを、値が届かない場合は方向と処理状態を調べます。
- 食い違い — 両側に異なる値を置き、業務担当者が選んだ正しい値と同期後の値を比べます。違えば管理元の決定と競合時の扱いを見直します。
- 空欄 — 片側の値が空欄のレコードで、受け取り先に必要な情報が残るか確かめます。作業に必要な値を確認できなければ、入力元と空欄時の業務手順を決め直します。
- 対象外 — 条件に合わないレコードを用意し、両側の値が意図せず変わっていないか確認します。更新されていたら展開を止め、対象条件と実際のレコード情報を照合します。
違いが出た場合は、「どの状態で」「どの値が」「期待とどう違ったか」を残します。設定を直した後は同じ状態を再び試し、期待した結果になってから、その状態のレコードを対象に含めます。設定だけでは解決しない場合は、値を確定する担当や受け渡し手順を見直します。
担当者に依存しない運用にする
管理元、同期方向、マッピング、競合時の優先先、対象条件、エラーの確認場所を記録します。設定値だけでなく、その判断に使った業務上の理由と、確認できたテスト結果も残してください。
新しい担当者が記録を読んで、同じ条件のレコードを対象に含めるか判断できる状態を目指します。
参照先で会社名の誤りを見つけた場合の依頼先と確認先も記録します。入力担当や利用する画面が変わったら、まず項目ごとの更新者と判断者を見直します。対象条件や項目の意味が変わった場合は、影響する状態のレコードで再びテストし、値と後続作業を確認してから運用に反映します。
モニタリングとエラー対応
同期開始後は、画面上の状態と実際の値を合わせて確認します。エラー表示がなくても、必要なレコードが対象に入り、受け取り先で値を使えるかを確かめてください。
問題が見つかったら、該当レコードと期待した結果を先に記録します。そのうえで、対象に入っていない、処理が進んでいない、処理後の値が違う、値は合うが業務で使えないのどこに当たるかを分けます。
- 対象や処理の問題 ── 条件と状態を確認します。
- 値の問題 ── 方向とマッピングを確認します。
- 利用上の問題 ── 項目の意味と表示場所を確認します。
同期ヘルスを見る
「設定」から「連携」「接続済みアプリ」を開き、対象アプリの同期に関する表示を確認します。表示名や詳細の開き方は、その画面で確かめます。
- 対象外 ── 条件と識別情報を調べます。
- 処理が失敗している ── 表示された理由を調べます。
- 処理済みで値が違う ── 方向、マッピング、競合時の扱いを調べます。
- 値が合っていても業務で使えない ── 項目の意味、表示場所、引き継ぎ手順を利用担当者と見直します。
入力担当、項目、対象条件が前回の確認から変わっていれば、その変更が影響する状態のレコードでテストをやり直します。特定のレコードだけ期待と異なる場合は、そのレコードの値と照合情報を確認し、共通の設定を変える必要があるか判断します。
公式ナレッジの画面では、次の順に状態を確認できます。
- 「CRM syncs」タブの「Object view」で、オブジェクトごとの「In sync」「Failing」「Excluded」の件数を見ます。
- 「Failing」の数字を開き、エラー横の矢印から「Sync Activity」の詳細を読みます。「Troubleshoot」でBreezeアシスタントに修正手順を尋ねることもできます。
- 「Record view」でレコードを選び、「Rerun sync」で個別に再実行します。
- 「Excluded」はフィルターに合わないか、照合に使う一意の識別子がないレコードです。件数を開いて原因を分けます。
- 削除されたレコードを戻す場合は「Resync deleted records」、同期を止める場合は対象オブジェクトの「More」から「Turn off sync」を選びます。再開は「Edit sync settings」からです。
初回同期の完了はメールで通知されます。データ量が多い場合、初回は数日かかることがあります。HubSpotは5分ごとに変更を確認し、初回同期の後は変更から10分以内に反映されます。結果が見えないと感じたら、まず時間を置いてから「Object view」の状態を確認してください。
エラーの原因別に対処する
| 状態 |
確認する原因 |
次の対応 |
| 項目マッピングの失敗 |
データ形式や読み取り権限 |
項目の意味・形式と接続権限を見直す |
| 重複や照合漏れ |
識別項目の不一致、空欄 |
照合項目と既存レコードを確認する |
| 選択肢の同期失敗 |
値の名称や対応関係 |
双方の選択肢を照合し、対応しない値を整理する |
| 同期対象外 |
フィルター条件や識別情報 |
対象条件に合うか、照合情報があるか確認する |
| 同期の遅れ |
初回処理中、外部アプリの応答 |
処理状態を見て、完了後に更新結果を再確認する |
| 状況 |
確認すること |
次の対応 |
| 同期エラー |
原因と影響したレコード |
設定やデータを修正して再確認 |
| 値の食い違い |
管理元と競合ルール |
更新方向を見直す |
| 重複レコード |
照合に使った項目 |
重複の範囲を確認する |
原因を直した後は、影響したレコードの値を両側で再確認します。
- 特定のレコードだけで失敗する ── その値や識別情報を調べます。
- 同じ項目の複数のレコードで失敗する ── 共通するマッピングや対象条件を確認します。
- 重複が見つかった ── 先に同じ顧客を指すか判断してください。
次へ進む条件は、影響したレコードが意図した顧客に結び付き、受け取り先で期待する値を使えることです。画面の状態が変わっても担当者が作業を始められなければ、引き継ぎに必要な情報を見直します。
再同期や停止を判断する
問題が一部のレコードに限られるなら、表示された理由と該当データを確認し、修正後の処理状態と両側の値を見直します。同じ項目で想定外の更新が広がっているなら、影響範囲を特定し、画面で利用できる停止方法を確認して処理を止めることを検討します。
判断の分かれ目は、特定のレコードの値や識別情報で原因を説明できるか、共通の設定がほかのレコードにも影響するかです。
- 特定のレコードで説明できる ── 該当レコードを修正して再確認します。
- 共通の設定がほかのレコードにも影響する ── 対象を広げず、方向、マッピング、競合時の扱い、対象条件を確認します。
再開前には、問題が出た状態をテスト用レコードで再現し、修正後に期待した結果となることを確かめます。影響したレコードも両側で照合し、後続担当者が必要な情報を使える状態になってから対象を広げてください。
StartLinkでの進め方と、外部アプリごとの選び分け
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援の中でデータ連携の設計を担ってきました。Data Syncの設定は、次の順で進めます。投資の規模は範囲によって変わるため、まず1つのオブジェクトから始めるスモールスタートを前提にします。
- 現状の整理・要件定義 — 受注後の担当者が使う項目を洗い出し、項目ごとに更新者・利用者・判断者を表にします。
- 設計・構築 — 同期方向、競合解決の既定アプリ、同期ルールを決め、テスト用のポータルまたは少数のレコードで設定します。
- データ移行 — 初回同期の前に、メールアドレスや識別子の重複を整理します。
- テスト・検証 — 新規・更新・食い違い・空欄・対象外の5状態を試し、結果を記録します。
- 定着・運用改善 — 「Failing」の件数を定期的に確認する担当を決め、範囲を広げるときは同じ手順を繰り返します。準委任で伴走し、Breezeなどの AI を使った確認の自動化も設計に組み込めます。
標準の同期で足りない業務(見積・請求書の発行や、Notionのページ連携など)は、StartLinkが開発元の連携アプリで埋める選択肢があります。会計はSync for freee、ナレッジ管理はSync for Notion、シリーズ全体はSyncシリーズ一覧で確認できます。
| 状況 |
選ぶ方法 |
理由 |
| 外部アプリの対象オブジェクトが標準の同期に対応している |
Data Sync |
Connected Appsから、方向・競合解決・ルールを画面で設定できる |
| 値を人が確認・加工してから渡したい |
CSVによる更新 |
渡す前の判断を手順に含められる |
| 独自の変換や外部APIの呼び出しが必要 |
API・Webhookによる個別開発 |
条件分岐とエラー時の再処理を自前で設計できる。API・Webhook開発ガイドを参照 |
| Salesforceと併用する |
Salesforce連携の設定 |
オブジェクトと項目の設計が異なる。HubSpot Salesforce連携ガイドを参照 |
連携全体の地図は「HubSpot連携ガイド」にまとめています。Slack・Zoom・iPaaSなど目的別の選び方は「HubSpotアプリ連携の選び方と活用法」、ノーコードで外部サービスをつなぐ場合は「HubSpot Zapier Make連携の選び方と自動化パターン」が参考になります。
よくある質問
Data Syncは双方向同期だけですか?
いいえ、一方向も選択できます。片方だけが更新し、もう片方が参照する項目なら、更新元に合わせた一方向を検討します。双方で更新する必要がある項目は、食い違ったときの判断者と修正経路を決め、テスト結果が業務上の期待と一致してから双方向の対象に含めます。更新する人を決められない場合は、入力ルールから整理してください。
同期方向と競合解決は同じ設定ですか?
異なります。同期方向は値をどちらへ渡すか、競合解決は値が食い違った場合にどちらを優先するかに関わります。片方だけで変更したレコードと、双方に異なる値があるレコードを分けて試してください。前者で期待と違えば方向を、後者で違えば管理元と優先先を確認します。
初回同期では既存レコードも対象になりますか?
既存レコードの扱いを含め、設定した範囲と実際の結果を確認してください。両方のアプリにあるレコードと片方にだけあるレコードを分けて調べます。意図しない結び付きや重複があれば、識別情報と確認担当を決めてから対象を広げます。対象レコードの結果に加え、対象外レコードに意図しない変更がないことも確認します。
独自の項目をマッピングできますか?
利用できるマッピングは、契約内容、設定画面に表示される選択肢、接続先フィールドの制約を照らし合わせて確認します。項目が表示されても、希望する方向と形式で扱えるかをテストしてください。値が届いても受け取り先で意味が異なるなら対応付けを見直します。設定を選べなければ、その項目の必要性を確認し、入力方法や受け渡し手順を決めてから連携範囲を見直します。
同期に失敗したレコードはどうすればよいですか?
対象アプリの同期に関する画面で、レコードの状態と表示された理由を確認します。対象条件と処理状態を見たうえで、項目形式、権限、選択肢、照合情報を調べます。修正後は両側の値と受け取り先での利用結果を確認してください。同じ失敗がほかのレコードにもある場合は、共通する条件や項目を確かめ、影響する状態をテストしてから対象を広げます。
まとめ
HubSpot Data Syncの設定は、受け取り先で行う作業から逆にたどります。
- 必要な情報と対象顧客を決め、項目ごとの更新者、利用者、正しい値の判断者を特定します。
- 同期方向、マッピング、競合時の扱いがその決定と一致するか確認してください。
希望する設定を選べない項目は、必要性を判断し、別の受け渡し手順を決めます。
連携対象の項目と管理元を一覧にしたら、新規作成と更新に加え、値の食い違い、空欄、対象外のレコードを試します。正しい顧客に結び付き、値が期待どおりで、受け取り先の担当者が作業できた範囲から対象を広げてください。
結果を説明できない場合は、対象条件、管理元、項目の意味、業務手順のうち該当する決定へ戻ります。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
顧客情報の整理から設定の確認まで、作業に合わせて次の資料を参照してください。業務で使う情報を洗い出すときは全体ガイドを、接続や項目対応を確かめるときはHubSpotの公式ガイドを確認できます。接続先で選べる内容は、利用中の設定画面でも照合してください。