HubSpotの関連付けラベルは、コンタクトと会社、コンタクトと取引のように「2つのレコードの関係」に意味を付ける機能です。 決裁者・請求先・契約担当といった役割を、コンタクトのプロパティではなく関係そのものに記録できるため、同じ人が会社ごと・取引ごとに別の役割を持つ状況にも対応できます。作成にはスーパー管理者権限が必要で、利用にはProfessionalまたはEnterpriseが前提です。
多くの現場で起きるのは、「決裁者」というプロパティを作ったものの、1人が複数の会社に関わる場合や、取引ごとに窓口が変わる場合に表現しきれなくなる事態です——役割は人の属性なのか、関係の属性なのか。
この記事でわかることは次のとおりです。
- ラベル・プロパティ・カスタムオブジェクトの使い分け基準 ── 役割をどこに持たせるかの判断表
- 画面での作成手順と、作る前に決める「役割辞書」 ── 内部名・ラベルの型・上限を一覧にする方法
- 上限の優先関係と、ワークフロー・セグメント・レポートでの使い方 ── 公式ナレッジで確認できた動きだけを整理
- 失敗しやすい箇所と、StartLinkの設計工程での決め方 ── 削除・インポート・連携の落とし穴
役割をどこに持たせるか:ラベル・プロパティ・カスタムオブジェクトの判断
役割を記録する場所は、大きく3つあります。コンタクトのプロパティ、関連付けラベル、そして独立したカスタムオブジェクトです。どれを選ぶかは、「その役割が誰と誰の関係に属するか」で決まります。
たとえば「請求先」は、特定のコンタクトの性格ではなく、「この会社に対してこのコンタクトが請求先である」という関係の事実です。同じコンタクトが別の会社では請求先ではない場合があるため、人のプロパティに持たせると矛盾します。関係に属する情報は、関係に付けるのが原則です。
| 持たせ方 |
向く役割 |
注意点 |
| コンタクトのプロパティ |
人に固有の属性(職種、言語、配信の可否など) |
複数の会社・取引にまたがる役割は表現できない |
| 関連付けラベル |
関係に属する役割(決裁者、請求先、契約担当、技術窓口) |
付与にはレコード間の関連付けが前提。ラベルは1ペアあたり最大50個 |
| カスタムオブジェクト |
関係そのものが属性・履歴・金額を持つもの(契約、参画、紹介など) |
Enterpriseが前提で、設計と保守の範囲が広がる |
判断のコツは、「その役割に、日付・金額・状態のような固有の項目を付けたいか」を自問することです。付けたいなら、関係を独立したレコードにするカスタムオブジェクトが候補になります。付けたくないなら、ラベルで足ります。カスタムオブジェクトの判断軸はHubSpotカスタムオブジェクトの設計判断で詳しく整理しています。オブジェクト・プロパティ・関連付けの全体像はCRMデータベース設計の基本が土台になります。
ラベルの型と、データモデル画面で見える構造
HubSpotの公式ナレッジでは、ラベルの型として「1つのラベル」と「ペアのラベル」が説明されています。1つのラベルは、両方のレコードに同じ意味で付く型で、「同僚」「パートナー」が例です。ペアのラベルは、関係の両側で異なる語が必要な型で、「マネージャーと従業員」「親と子」「本社と支店」が例です。一方に付けると、もう一方に反対側のラベルが自動で付き、カスタムラベル数の上限では1つとして数えられます。

ラベルは「オブジェクトのペア」ごとに管理されます。コンタクトから取引、会社からコンタクトのように、方向を持った組が単位です。1つのオブジェクトペアに作れるラベルは最大50個です。この上限は十分に大きく見えますが、部署別・案件別・拠点別にラベルを増やすと、すぐに管理しきれなくなります。ラベルは「役割」だけに使い、「部署」「拠点」のような分類は別の手段で持たせるのが安全です。
また、関連付けは常に双方向です。レコードAがBに関連付けられていれば、BもAに関連付けられます。ラベルは方向ごとに表示されるため、設計の際は「会社から見たコンタクト」「コンタクトから見た会社」の両方で、どう見えるかを確認します。
画面での作成手順
ラベルの作成は、設定画面ではなくデータモデルから行います。公式ナレッジの手順は次のとおりです。
- 「その他」から「データ管理」>「データモデル」に移動します
- 右上の「データモデルを編集」をクリックします
- グラフビューのアイコンをクリックします
- 「オブジェクトの検索」欄で、対象のオブジェクト(例:コンタクト)を検索します
- オブジェクトカードの「〜件の関連付けられたオブジェクト」の横にある「すべてビュー」をクリックします
- 相手側のオブジェクトの三点アイコンから「関連付けラベルを作成」を選びます
- ラベルの型を選び、名前を入力します。内部名を編集できますが、作成後は変更できません
- 「次へ」を押し、関連付けの方向ごとの上限を設定して「作成」をクリックします
「関連付けラベルを作成」が表示されないときは、そのオブジェクトがカスタムラベルに対応していない可能性があります。公式ナレッジでは、商品項目などが例として挙げられています。また、この作成はBreezeアシスタントからも行えると記載されています。
レコード上でラベルを付けるときは、関連付けカードにカーソルを合わせ、「その他」から「関連付けラベルを編集」を選びます。ドロップダウンでラベルを追加し、「更新」で確定します。新しい関連付けは追加する際にラベルを設定でき、多数のレコードへの一括付与はインポートで行えます。
作成前に決めておくのは、名前・内部名・型・上限の4点です。内部名は作成後に変更できず、削除したラベルは復元できません。画面操作より、辞書づくりに時間を使ってください。
作る前に「役割辞書」を書く
ラベルの設計は、画面に入る前の表づくりで8割が決まります。StartLinkが現状の整理・要件定義の段階で作るのは、次のような役割辞書です。業務の言葉を拾い、役割ごとに「どの関連付けに」「どの型で」「何人まで付けるか」を決めます。以下は設計の考え方を示す例であり、業種や運用によって内容は変わります。

| 業務上の役割 |
付ける関連付け |
上限の考え方 |
| 決裁者 |
会社とコンタクト、取引とコンタクト |
取引ごとに1人が基本。複数承認の業務なら複数 |
| 請求先 |
会社とコンタクト |
1社に1人に絞ると、請求書の宛先が一意になる |
| 契約担当 |
取引とコンタクト |
取引ごとに1人。契約更新で担当が替わる前提を確認 |
| 導入責任者 |
会社とコンタクト |
複数拠点なら拠点ごとに複数。上限は拠点数から決める |
| 親会社と子会社 |
会社と会社 |
ペアのラベルにする。両側で語が異なる |
この表を作る過程で、「そもそも1人に絞れない役割」が見つかることが少なくありません。たとえば請求先が経理と担当者の2人いる運用なら、ラベルを分けるか、上限を2にするかを決める必要があります。決め切れない場合は、最小のラベル数で始めて広げるスモールスタートが有効です。ラベルは後から追加できますが、内部名と削除の制約があるため、最初から増やしすぎないほうが安全です。
役割辞書ができたら、関係者で読み合わせます。営業・経理・カスタマーサクセスで、同じ言葉が違う意味で使われていることがあるためです。「決裁者」が、予算を持つ人を指すのか、最終承認印を押す人を指すのかを、ここで定義します。
上限の設計:全体の上限とラベルの上限
関連付けには、2種類の上限があります。オブジェクトペア全体の上限と、ラベルごとの上限です。公式ナレッジでは、どちらもスーパー管理者が設定でき、Professional以上で利用できると説明されています。
全体の上限は、データモデルのグラフビューで、2つのオブジェクトを結ぶ線上の「関連付けの制限」から設定します。各方向について、「多数」(HubSpotの既定の上限に従う)か「カスタム」(任意の数。最大10,000)を選びます。ラベルごとの上限は、対象オブジェクトのカードから、ラベル横の三点アイコンの「ラベルの上限を編集」で設定します。
押さえておくべきは優先関係です。全体の上限が1のとき、ラベルの上限を「多数」にしても、関連付けられるレコードは1件のままです。公式ナレッジには、コンタクトの全体上限を1にし、「意思決定者」ラベルを多数に設定しても、関連付けられるコンタクトは1件のみになる例が示されています。
| 設定したい運用 |
全体の上限 |
ラベルの上限 |
| 取引ごとに決裁者を1人に絞る |
取引側は複数を許可 |
決裁者ラベルを1に設定 |
| 取引に関わる人を1人だけにする |
1に設定 |
ラベルは上限に影響しない |
| 会社ごとに請求先を1人にする |
会社側は複数を許可 |
請求先ラベルを1に設定 |
上限に達すると、それを超える関連付けやラベルの付与はできません。保存後の運用で現場が詰まらないよう、上限は業務の実態から決め、運用開始後に現場の声で見直します。
ラベルを使い切る:ワークフロー・セグメント・レポート
ラベルは付けて終わりではなく、後工程で使って初めて価値が出ます。公式ナレッジで確認できた使い道は次のとおりです。
| 使う場面 |
公式ナレッジで確認できた動き |
設計上の留意 |
| ワークフロー |
登録条件・分岐でラベルを指定できる。関連レコードのプロパティの設定・クリア・コピー、関連コンタクトへのメール送信(送信先ラベルの指定可)ができる |
コピーはプロパティタイプの互換性が必要 |
| セグメント |
「任意のオブジェクト」の代わりにラベルを選び、そのラベルが付いた関連レコードのみで判定できる |
関連付けでの絞り込みはProfessional以上 |
| カスタムレポート |
ラベルを軸・内訳・フィルターに使える |
ペアのラベル(例:決裁者と、その決裁者が属する会社側のラベル)は、どちらの方向から見るかで結果が変わるため、集計する向きを決めてから使う |
たとえば、取引が成立した際に、その取引に「請求先」ラベルで関連付けられたコンタクトへ案内メールを送る、という設計が組めます。決裁者へだけ別の案内を送る運用も、ラベルを送信先に指定することで実現できます。ワークフローの作り方はHubSpotワークフローの設定ガイド、セグメントの設計はHubSpotリスト・セグメントの設計で整理しています。
プライマリー会社も、押さえておく役割の1つです。会社とコンタクトの関係には、既定の「プライマリー」ラベルがあります。コンタクトのプライマリー会社は必須で、メールや通話などのアクティビティは自動的にプライマリー会社へ関連付けられます。ライフサイクルステージの同期やセグメント、レポートでも参照されます。自社で作る「決裁者」などのラベルとは役割が別物で、置き換える関係ではありません。
インポートとAPIで一括付与するときの注意
既存のデータにラベルを付ける場合は、インポートが入り口になります。公式ナレッジでは、ラベル名に英数字以外の文字を使うとインポート時にエラーが起きる可能性があり、複数値の区切りにセミコロンが使われるため、ラベル名にセミコロンを含めないよう案内されています。インポート側の列の設計やキーの決め方は、HubSpotインポートの手順と関連付け設計が参考になります。
開発者向けのAPIでは、関連付けごとに「カテゴリー」と「タイプID」を指定します。HubSpotが用意する既定のラベルは HUBSPOT_DEFINED、カスタムラベルは USER_DEFINED です。カスタムラベルのタイプIDは、関連付けのラベル一覧を取得するエンドポイントで確認します。公式ドキュメントでは、コンタクトから会社へのPrimaryのタイプIDは1、会社からコンタクトへのPrimary contactは2と記載されており、方向によってタイプIDが異なります。ラベルを置き換えるときは新しいラベルだけを送り、既存を残して追加するときは既存と新規の両方を送ります。
設計の段階で、タイプIDの対応表を役割辞書に加えておくと、連携アプリや自動化の開発で取り違えを防げます。自社開発の連携アプリを含む構成では、StartLinkはこの対応表を設計書に残す形で進めています。会計連携との関係は、Sync for freeeやCRM会計連携の設計のように、請求先の一意性が宛先の取り違えを防ぐ場面で効いてきます。
よくある失敗と回避策
ラベルの失敗は、作り方より決め方に原因があります。公式ナレッジの制約と照らして、典型的なものを整理します。
| 失敗 |
起きる理由 |
回避策 |
| 内部名を仮の名前で作った |
内部名は作成後に変更できない |
役割辞書で内部名まで決めてから作る |
| 不要なラベルを消せない |
レコードや他のツールで使用中のラベルは、先に除去が必要。削除後は復元できない |
削除前に、使用箇所をワークフロー・セグメント・レポートで洗い出す |
| ラベルが増えすぎた |
1ペアあたり最大50個。部署や拠点まで入れてしまう |
役割だけに絞り、分類は別の手段にする |
| 全体の上限で意図せず詰まった |
全体の上限がラベルの上限に優先する |
上限は2種類を一覧にして設計する |
| 連携先に反映されない |
Salesforce連携による同期では、会社・取引・チケット・カスタムオブジェクトの関連付けラベルが対象(公式ナレッジの記載)。記載のないオブジェクト(例:コンタクト)の扱いは公式ナレッジで確認する |
連携を使う場合は、同期対象のオブジェクトを事前に確認する |
もう1つ多いのが、ラベルを付ける運用が定着しない問題です。入力を現場の手作業に頼ると、付与漏れが起きます。ラベルの付与を、取引の作成時やインポート時に組み込むか、レポートで付与漏れを一覧化するかで、定着を仕組みにします。権限については、関連付けの作成・編集にスーパー管理者または「関連付けを編集」権限が必要なため、HubSpotの権限設計と合わせて決めます。
StartLinkの進め方:辞書から始めて、効く役割だけ広げる
StartLinkはHubSpotゴールドパートナーとして、Sync for freee / Sync for Notion の開発元でもあります。関連付けラベルの設計は、導入支援の次の工程に沿って進めます。
- 現状の整理・要件定義:営業・経理・CSが使う役割の言葉を集め、役割辞書の草案にする
- 設計・構築:内部名・型・上限・方向を確定し、データモデル画面で作成する
- データ移行:既存データのラベル列を整え、インポートで付与して件数を照合する
- テスト・検証:ワークフローの分岐とセグメントが、ラベルで意図どおりに動くかを確認する
- 定着・運用改善:付与漏れをレポートで見張り、使われないラベルを整理する
スモールスタートでは、最初に効果が大きい2〜3の役割(決裁者・請求先など)から始めます。運用で必要性が確認できた役割を、準委任の伴走で追加していきます。AIの活用では、Breezeで関連付けの状態を確認する、Claudeで役割辞書と実データの突合を支援するといった組み込みが考えられます。企業様(チーム)によって最適な形は異なりますので、業務の実態に合わせて設計します。
よくある質問
Q1. 関連付けラベルは、どのプランで使えますか。
公式ナレッジでは、Marketing Hub、Sales Hub、Service Hub、Data Hub、Content Hub、Smart CRMのいずれも、ProfessionalまたはEnterpriseで利用できると記載されています。作成にはスーパー管理者権限が必要です。契約中のプランは、必ず自社の設定画面と公式ナレッジで確認してください。
Q2. ラベルの名前は後から変えられますか。
ラベル名と上限は編集できます。一方、内部名は作成後に変更できません。内部名は連携やAPIで使われるため、作成前に決めます。
Q3. 1つのレコードに、複数のラベルを付けられますか。
付けられます。1組のレコード間には、上限の範囲で複数のラベルを付けられると公式ドキュメントに記載されています。たとえば、同じコンタクトに「決裁者」と「契約担当」を重ねて付与する設計も可能です。
Q4. 決裁者のプロパティを作るのと、ラベルを使うのはどちらがよいですか。
役割が会社や取引ごとに変わるならラベル、人に固有の情報ならプロパティが向きます。迷う場合は、「別の会社や取引でも同じ答えになるか」で判断します。同じ答えにならないなら、関係に付けるラベルです。
Q5. 作ったラベルを消したいときはどうすればよいですか。
レコードや他のHubSpotツールで使用中のラベルは、先にそれらから除去する必要があります。削除したラベルは復元できません。ワークフロー・セグメント・レポートでの使用箇所を洗い出してから、削除します。
まとめ:関連付けラベルは「辞書づくり」と「上限の設計」で決まる
- 役割が関係に属するなら、ラベルで持たせる:人に固有の情報はプロパティ、固有の項目を持つ関係はカスタムオブジェクトが候補です
- 内部名・型・上限を、作る前に役割辞書へ書く:内部名は変更できず、削除したラベルは復元できません
- 全体の上限がラベルの上限に優先する:2種類の上限を一覧にして設計します
- ワークフロー・セグメント・レポートで使って初めて価値が出る:付与漏れは、レポートで見張ります
- スモールスタートで、効く役割から広げる:増やしすぎは、50個の上限と保守の負担を招きます
最初の一歩は、現在の運用で「誰が決裁者で、誰が請求先か」を、どこに記録しているかを書き出すことです。記録先が人のプロパティやメモ欄に散らばっているなら、役割辞書の作成から始められます。
自社の状況に当てはめた設計を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。HubSpotの導入支援はHubSpot導入・活用支援のサービスページにもまとめています。
参考(公式情報)