%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}
この記事の結論
複数事業の情報を分断せず、運用単位は明確に分ける。共有するCRMデータと分離する活動を先に定義することが核心です。
複数事業の情報を分断せず、運用単位は明確に分ける。共有するCRMデータと分離する活動を先に定義することが核心です。
「グループ会社ごとにHubSpotアカウントが分かれ、全社のデータを横断して見られない」「ひとつのアカウントで複数ブランドを運用しているものの、配信や取引の区別が曖昧になっている」「事業ごとのスプレッドシートとCRMの情報がずれ、集計のたびに確認が必要になる」——複数事業を展開すると、共通化と分離の境界が見えにくくなります。
HubSpotのビジネスユニットとは、ひとつのHubSpotアカウント内に仮想的な仕切りを作り、複数の事業やブランドのマーケティング活動を分けながら、CRMデータを共通で管理する仕組みです。したがって、HubSpot マルチアカウント管理の判断では、ブランド数よりも、コンタクト・会社・取引を共有したいかどうかを先に確認することが重要です。
本記事は「HubSpot Enterprise活用ガイド｜大企業が使いこなすための設計と運用の勘所」シリーズの一部です。
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
「グループ会社ごとにHubSpotアカウントがバラバラで、全社のデータを横断的に見られない」とお感じの方に、特に参考になる内容です。判断の軸から実装後の運用までを順に確認できます。
- ビジネスユニットの基本概念 — 分けられるマーケティング活動と、全ユニットで共有されるCRMデータの違いを整理します。
- マルチアカウントとの判断基準 — データ共有、営業プロセス、権限、管理組織の観点から選び分けます。
- ビジネスユニットの設計手順 — ユニットの定義、共通要素と個別要素、権限の順に設計します。
- ブランド別運用と全社横断レポート — メール配信や購読設定を分けながら、共通のCRMデータを可視化する考え方を解説します。
- グループ会社の関連付け対策 — 同じメールドメインを使う場合の誤った関連付けを、プロパティとワークフローで抑える方法を確認します。
ビジネスユニットとは何か
ビジネスユニットは、複数事業のデータを別々に保管するための機能ではありません。CRMデータを共通の基盤に置いたまま、ブランドごとの配信や表示、レポートを整理するための仕切りです。この違いを理解すると、別アカウントとの選択を判断しやすくなります。
CRMデータは共通で管理する
コンタクト・会社・取引は、全ビジネスユニットで共通のCRMデータとして管理されます。同じ顧客が複数ブランドと接点を持つ場合も、ブランドごとに重複した顧客台帳を作るのではなく、共通のレコードを起点に関係を確認できます。
これは、CRMを単なる入力先ではなく、コンタクトから取引、顧客、その後の請求までをつなぐ業務基盤として扱う考え方です。事業ごとのスプレッドシートを後から集計する運用では、表記や更新時点の差が生まれやすいため、共通の顧客情報をどこに置くかが設計の出発点になります。
ブランドごとに分ける要素を整理する
ビジネスユニットごとに、ブランドロゴ・カラー、メール送信ドメイン、購読設定、マーケティングコンタクト、ダッシュボード・レポートを個別に設定できます。顧客情報は共有しながら、顧客に見えるブランド表現と、社内で確認する活動単位を分ける構造です。
| 管理対象 | 扱い | 設計時の確認点 |
|---|---|---|
| コンタクト・会社・取引 | 全ユニットで共通 | 同じ顧客を横断して把握する必要があるか |
| ブランドロゴ・カラー | ユニット別 | 顧客に見せるブランド表現を分けるか |
| メール送信ドメイン | ユニット別 | 送信元をブランドごとに分けるか |
| 購読設定 | ユニット別 | 配信への意思をどの単位で管理するか |
| ダッシュボード・レポート | ユニット別と横断 | 事業別KPIと全社KPIをどう分けるか |
利用条件と向かないケースを確認する
ビジネスユニットはEnterprise以上のプランで利用でき、追加ユニットはアドオンとして購入します。追加できる数は契約内容によるため、導入前にHubSpotの公式情報または営業担当へ確認してください。
ただし、ビジネスユニットを作ってもCRMデータそのものは共通です。事業間で顧客データを共有できない場合や、管理組織を分離したい場合には、別アカウントの検討が必要です。
マルチアカウントとビジネスユニットの判断基準
判断で要点になってくるのは、ブランドの見た目ではなく、CRMデータを共有できるかどうかです。共通の顧客基盤を持つならビジネスユニットが候補になり、データの完全分離が必要なら別アカウントが候補になります。営業プロセスと管理者の関係も合わせて確認します。
CRMデータ共有の要否を最初に決める
同じ顧客が複数の製品や事業と取引する可能性があり、顧客との接点を横断して見たい場合は、CRMデータを共通にする意味があります。反対に、他事業の担当者に顧客情報を見せないことが前提なら、ビジネスユニットだけで要件を満たせるかを権限設計まで含めて確認します。
検討時は、現在のアカウント数を数える前に、共有したいレコードと分離したい活動を書き出します。この順序にすると、既存組織図をそのままHubSpotへ写すのではなく、業務上必要な境界を設計できます。
ビジネスユニットが適する場面
CRMデータを共有しながら、ブランドや製品ごとにマーケティング活動を分けたい場面では、ビジネスユニットが適します。判断材料は次のとおりです。
| 場面 | ビジネスユニットを検討する理由 |
|---|---|
| 同一企業の複数ブランド | 顧客データを共有しつつ、ブランド別にマーケティングを行うため |
| 複数の製品ライン | 製品別にメール配信と購読管理を分けるため |
| 国内事業と海外事業 | 言語別のコンテンツ配信とドメイン分離を行うため |
| 複数の事業部門 | 部門別の活動を分けながら、全社の顧客情報を共通化するため |
ただし、パイプラインやメールを分けるだけであれば、どの要素にビジネスユニットが必要かを先に整理してください。分離対象が曖昧なままユニットを増やすと、担当者が選ぶ項目や運用ルールも増えます。
別アカウントが適する場面
完全に独立したグループ会社、営業プロセスが根本的に異なる子会社、データの完全分離が必要な組織、管理者が別組織に属する場合は、別アカウントを検討します。ビジネスユニットは共通CRMを前提とするため、分離要件が中心なら構造が合いません。
| 確認項目 | ビジネスユニット | 別アカウント |
|---|---|---|
| CRMデータ | 共通 | 分離 |
| ブランド別の配信 | 分離して運用 | アカウントごとに運用 |
| 全社横断の顧客把握 | 共通レコードを起点に設計 | アカウントをまたぐ集計方法が必要 |
| 管理組織 | 同じ基盤で権限を設計 | 管理者と運用を分離 |
| 向いている前提 | 顧客基盤を共有したい | 顧客基盤を共有しない |
ビジネスユニットの設計手順
設計では、機能設定から始めるのではなく、事業構造と業務フローを先に整理します。ユニットの単位、共通データ、個別運用、権限の順に決めると、設定の目的がぶれにくくなります。汎用的なひな型をそのまま当てはめず、自社で顧客がどの事業をまたぐかを基準にしてください。
ユニットの単位を定義する
最初に、ブランド、製品ライン、地域、事業部門のどれをユニットの境界にするかを決めます。名称だけで区切るのではなく、送信元ドメイン、購読設定、マーケティング活動を独立させる必要がある単位かを確認します。
| 設計観点 | 確認する内容 | 決定するもの |
|---|---|---|
| 顧客 | 同じ顧客が複数事業と接点を持つか | CRMデータを共有する範囲 |
| ブランド | ロゴ、カラー、送信元を分けるか | ユニットの境界 |
| 配信 | 購読への意思を分けて扱うか | 購読設定の単位 |
| 営業 | 営業プロセスが異なるか | パイプラインの分け方 |
| 管理 | 閲覧・編集できる担当者を分けるか | 権限の範囲 |
共通要素と個別要素を対応表にする
次に、コンタクト・会社・取引は共通、パイプラインやメール配信ドメインは個別、レポートは個別と横断の両方、というように対応表を作ります。この表が、設定担当者と現場担当者の共通認識になります。
| 要素 | 共通または個別 | 運用上の理由 |
|---|---|---|
| コンタクト・会社データ | 共通 | 同じ顧客が複数製品を利用する可能性があるため |
| パイプライン | 個別 | 製品ごとの営業プロセスを分けるため |
| メール配信ドメイン | 個別 | ブランド別に送信元を変えるため |
| 購読設定 | 個別 | ひとつの配信解除が別ブランドへ影響しないようにするため |
| レポート | 個別と横断 | 事業別KPIと全社KPIを確認するため |
共通と個別の境界は、設定後の画面だけでなく、コンタクトから取引、顧客、請求へ進む全体フローに沿って確認します。例えば、同じ会社レコードから事業別の取引を作るなら、会社は共通、取引のパイプラインは個別という整理ができます。
権限と入力項目を絞り込む
ビジネスユニットと権限設計を組み合わせ、各ユニットの担当者が閲覧・編集する取引の範囲を決めます。ユニットを分けただけで閲覧範囲まで分かれると考えず、権限要件を別の設計項目として扱うことがポイントです。
また、所属事業やユニットを判定するプロパティは、運用に必要なものへ絞ります。入力項目を増やしすぎると判断が担当者任せになるため、必要な項目と更新条件を定義し、ワークフローで更新できる部分は仕組み化します。これにより、引き継ぎ後や新しい担当者でも同じ基準で運用しやすくなります。
ブランド別のマーケティング運用
設計後は、顧客に見えるブランド表現と、配信への意思を混同しない運用が必要です。送信元やテンプレートを分けるだけでなく、どのコンタクトへ何を配信するかを購読設定と合わせて管理します。CRMの共通化とマーケティング活動の分離を、ひとつの流れとして扱います。
送信元とテンプレートをブランド別にする
ビジネスユニットごとにメール送信ドメインを設定し、ブランドのロゴやカラーを反映したテンプレートを用意します。製品ごとに異なる送信元を使います。
ただし、見た目を分けただけでは誤配信を防げません。配信対象を抽出する条件に、所属ユニットやブランドとの関係を示す情報を使い、送信前に対象が意図した範囲になっているかを確認します。
購読設定をコンタクトの意思に合わせる
同じコンタクトが複数ブランドに関心を持つ場合、ブランドごとの購読設定を分けて管理します。ひとつのブランドで配信解除があっても、別ブランドの購読状態と混同しない設計が必要です。
| 状況 | 管理の考え方 |
|---|---|
| 単一ブランドに関心がある | 対象ユニットの購読設定に基づいて配信する |
| 複数ブランドに関心がある | ユニットごとの購読意思を個別に扱う |
| 配信解除がある | 解除された購読設定を基準に配信を止める |
| 所属ユニットが不明 | 判定条件を確認してから配信対象に含める |
マーケティングから取引までをつなぐ
ブランド別メールの反応を、コンタクトの情報だけで終わらせず、会社や取引と関連付けて確認します。共通のCRMデータがあることで、複数ブランドとの接点と、事業別パイプラインにある取引を同じ顧客の文脈で見られます。
この一気通貫の流れを作るには、ユニット情報を誰がいつ更新するかを決めます。手作業が残る場合も、更新箇所と責任者を限定し、ワークフローで扱える判定は自動化することをおすすめします。
グループ会社で起きる関連付け問題への対処
グループ会社では、メールドメインと会社の関係が実際の所属単位と一致しないことがあります。自動関連付けをそのまま使うと、異なる事業会社のコンタクトが同じ会社レコードへ集まる可能性があります。関連付けの基準を明文化し、人の記憶ではなくプロパティとワークフローで処理します。
メールドメインによる自動関連付けの落とし穴
HubSpotはメールドメインに基づいて、コンタクトを会社へ自動関連付けします。全社員が同じメールドメインを使うグループでは、事業会社が異なっていても同じ会社レコードに紐づくことがあります。
この状態では、会社単位の取引やレポートを見たときに、所属事業会社とHubSpot上の会社が一致しません。後から手作業で直し続けるのではなく、自動関連付けの対象と例外を最初に決めます。
所属事業会社をプロパティで管理する
対処の流れは、自動関連付けを特定ドメインで無効化し、「所属事業会社」のカスタムプロパティを追加したうえで、手動または申請フォームから値を設定する方法です。その値を使って、事業会社に対応する会社レコードへ振り分けます。
| 手順 | 設定内容 | 確認点 |
|---|---|---|
| 自動関連付けの見直し | 対象ドメインでの自動関連付けを無効化 | 他のドメインへの影響がないか |
| プロパティの追加 | 所属事業会社を保持する | 選択肢と表記を統一する |
| 値の取得 | 手動または申請フォームで設定 | 未入力時の扱いを決める |
| 振り分け | 事業会社名に基づき会社へ関連付ける | 想定した会社レコードかを確認する |
ワークフローと人の確認を組み合わせる
所属事業会社が判定できるレコードは、ワークフローで振り分けます。一方、値が空欄である場合や、既存の会社レコードとの対応が曖昧な場合は、担当者が確認する運用へ回します。
ただし、自動化の条件が曖昧なままでは、誤った関連付けが広がります。判定できるものだけを自動化し、例外を確認する一覧を用意すると、担当者が替わっても同じ基準で処理できます。
全社横断レポートの設計
ビジネスユニットを分ける目的は、事業別の数字を見ることだけではありません。共通のCRMデータを使い、各ユニットのKPIと全社の動きを同じ基準で確認することも重要です。入力ルールとレポートの条件を対応させて設計します。
ユニット別KPIと全社KPIを分ける
横断レポートには、全ユニット合計のパイプライン金額、同じ顧客が複数ユニットの取引を持つクロスセル機会、全社のリード獲得トレンドがあります。まず事業別に見る指標と、全社でまとめる指標を分けます。
| レポートの単位 | 確認する内容 | 必要なデータ |
|---|---|---|
| ユニット別 | 事業ごとのKPIとパイプライン | ユニットを識別できる取引情報 |
| 全社横断 | 全ユニットの合計と推移 | 共通の定義で入力された金額や日付 |
| 顧客横断 | 複数ユニットとの取引状況 | 会社・コンタクトと取引の関連付け |
担当者別の目標と実績を可視化する
事業別や担当者別にレポートを分けても、表示する金額や日付の定義が同じでなければ横断比較は難しくなります。レポートを作る前に、どの取引を集計対象にするか、担当者をどのプロパティで判定するかをそろえます。
以下の画面は、担当者ごとのクローズ済み金額と売上目標を横並びで確認するレポートです。
入力ルールからレポートの信頼性を作る
レポートのずれは、可視化の問題ではなく、入力と更新の定義がそろっていないことで起きるケースがあります。パイプラインをユニット別に作る場合は、取引ステージ、受注確度、ステージの定義、ステージ移行時に入力するプロパティを事業ごとに整理します。
共通指標として合算する項目は、ユニット間で意味をそろえます。個別最適が必要な項目と全社で統一する項目を分けることで、現場の運用と横断レポートを両立しやすくなります。
段階導入と運用定着の進め方
全事業を同時に切り替えると、設計上の問題と操作上の問題を切り分けにくくなります。独立性の高いブランドから始め、運用が安定してから対象を追加する段階的な導入をおすすめします。小さく始めて、確認できたルールを次のユニットへ展開します。
現状の手作業を先に洗い出す
まず、事業別のスプレッドシート、手動のメール配信、担当者ごとの集計で重複している作業を整理します。どの情報がHubSpotと表計算の両方にあり、どの場面で転記や照合が発生しているかを確認します。
| 現状 | 移行後の設計 | 確認すること |
|---|---|---|
| 事業別に顧客表を管理 | CRMデータを共通化 | 同じ顧客の重複をどう扱うか |
| 配信対象を手作業で抽出 | ユニット情報と購読設定で抽出 | 判定条件と例外を定義したか |
| 事業別の数字を後から合算 | 個別と横断のレポートを設計 | 指標の定義がそろっているか |
| 所属を担当者が判断 | プロパティとワークフローで振り分け | 判定できない場合の確認先があるか |
独立性の高い範囲から試す
最初の対象は、送信元、購読設定、担当チームが明確なブランドを選びます。共通CRMに与える影響を確認しながら、プロパティ、権限、ワークフロー、レポートの順に検証します。
ただし、試行段階でも購読設定と権限は省略できません。顧客への配信とデータの閲覧に関わるため、本番運用へ移る前に対象レコードと担当者の範囲を確認します。
ユニット間の移動ルールを決める
コンサルティングの商談から製品の商談へ発展するなど、取引がユニットをまたぐ場面では、元の取引を移すのか、別の取引を作るのかを事前に決めます。担当者の判断だけに任せると、同じ場面でも処理が分かれ、レポートの条件も不安定になります。
運用ルールには、変更するプロパティ、関連付ける会社・コンタクト、確認する担当者を含めます。仕組みで処理できる範囲と、人が確認する例外を分けておくと、引き継ぎや担当変更があっても運用を続けやすくなります。
よくある質問
ビジネスユニットの検討時に確認されやすい点をまとめます。契約内容や機能の提供条件は変更されることがあるため、契約に関わる点は公式情報も確認してください。
ビジネスユニットの追加費用はどれくらいですか？
追加ユニットはアドオンとして月額費用が発生します。正確な費用は契約内容によって確認が必要なため、HubSpot公式サイトまたは営業担当へ問い合わせてください。
既存のアカウントへ後から追加できますか？
Enterpriseプランでは、既存アカウントへビジネスユニットを追加できます。ただし、既存のコンタクトや取引の振り分け、メール購読設定の再設計が必要になるため、現在のデータと配信ルールを先に整理してください。
ビジネスユニット間でワークフローは共有されますか？
ワークフローは全ユニット共通で作成・管理します。特定ユニット向けの処理は、カスタムプロパティやブランド情報をトリガー条件に使い、対象レコードを絞り込みます。
Salesforceのマルチテナントとの違いは何ですか？
Salesforceのマルチテナントはデータを分離する構造で、HubSpotのビジネスユニットはCRMデータを共通にしてマーケティング活動を分離する構造です。データの完全分離が必要な場合は、HubSpotでも別アカウントを検討してください。
2025年3月時点では、HubSpotの機能は定期的に更新されるため、提供条件や設定項目はHubSpot公式サイトでご確認ください。
まとめ
HubSpot マルチアカウント管理では、アカウントをいくつに分けるかより先に、CRMデータを共有するかを決めます。共有するならビジネスユニット、完全分離が必要なら別アカウントという軸で考えると、設計の方向性を整理できます。
設計と運用の要点
- コンタクト・会社・取引は共通データとして扱い、ブランド表現、メール送信ドメイン、購読設定、レポートはユニット別に整理します。
- 権限はビジネスユニットと別に設計し、閲覧・編集できる取引の範囲を定めます。
- グループ共通のメールドメインを使う場合は、所属事業会社のプロパティとワークフローで関連付けを制御します。
- ユニット別KPIと全社KPIを分け、共通指標の入力定義をそろえます。
- 独立性の高い範囲から始め、運用ルールを確認してから対象を広げます。
まず取り組むこと
まずは、現在使っているアカウント、スプレッドシート、配信リストを並べ、共通化するデータと分ける活動を整理します。次の順で進めると、設定前に論点を確認できます。
- コンタクト・会社・取引を事業間で共有できるかを確認します。
- ブランドごとに分ける送信元、購読設定、パイプライン、権限を表にします。
- 独立性の高い範囲で、関連付け、配信対象、レポートを確認します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
マルチアカウント管理と関係する、設計・権限・自動化の記事です。検討している論点に合わせてご覧ください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
