「カスタムプロパティを追加するたびに名前の付け方がバラバラで、後から何のためのプロパティか分からなくなる」
「ドロップダウンにすべきか、テキストフィールドにすべきか、データ型の選択に迷う」
——HubSpotを本格運用している企業ほど、こうしたプロパティ設計の悩みに直面します。
HubSpotのプロパティは、CRMに蓄積されるすべてのデータの「型」を決める土台です。プロパティの設計が雑だと、レポートが正しく出力されない、ワークフローの条件分岐が複雑化する、データの重複が増えるなど、後工程のあらゆる業務に悪影響を及ぼします。
この記事では、HubSpotのプロパティ設計における命名規則・データ型選択・グルーピングのベストプラクティスを、具体例を交えて解説します。
この記事でわかること
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
HubSpotのCRMは、コンタクト・会社・取引・チケットなどのオブジェクトに紐づく「プロパティ」によってデータを管理しています。デフォルトで用意されているプロパティだけでも数百項目ありますが、自社のビジネスプロセスに合わせたカスタムプロパティの追加は避けられません。
問題は、カスタムプロパティの設計にルールがない状態で運用を進めると、次のような課題が蓄積していくことです。
Notion社は、HubSpot導入初期にプロパティのガバナンスルールを定めず運用した結果、1年後には大量の未使用プロパティが蓄積し、後からプロパティ設計のガイドラインを策定し直した事例を公開しています。
プロパティの命名規則は、チーム全員が迷わず「このプロパティは何を意味するか」を理解できることが最大の目的です。以下のルールを推奨します。
基本フォーマット: [プレフィックス]_[対象]_[内容]
| 要素 | 説明 | 例 |
|---|---|---|
| プレフィックス | 用途や部門を示す接頭辞 | mktg_（マーケ）、sales_（営業）、cs_（CS） |
| 対象 | 何に関する情報か | lead、deal、company |
| 内容 | 具体的なデータ内容 | source、score、stage_reason |
たとえば、マーケティング部門が管理するリードの獲得チャネルであれば mktg_lead_acquisition_channel となります。
custom_field_1、custom_field_2 のような意味のない連番HubSpotのプロパティには「表示名（ラベル）」と「内部名（Internal name）」の2つがあります。
mktg_lead_acquisition_channel）内部名はAPI連携やワークフローの条件設定で使われるため、一度決めたら変更できません。最初の設計段階で慎重に命名することが重要です。
HubSpotには多様なプロパティタイプ（データ型）が用意されています。目的に応じた適切な型を選ぶことで、レポートの精度やワークフローの柔軟性が大きく変わります。
| データ型 | 用途 | メリット | 注意点 |
|---|---|---|---|
| 単行テキスト | 自由入力（短文） | 柔軟性が高い | レポートのフィルタリングに不向き |
| 複数行テキスト | メモ・備考欄 | 長文記録に適する | 集計・分析には使えない |
| 数値 | 金額・数量・スコア | 計算・集計が可能 | 通貨型と混同しない |
| ドロップダウン選択 | 選択肢から1つ選ぶ | データの一貫性を担保 | 選択肢の設計が重要 |
| 複数チェックボックス | 複数選択 | 複合条件の記録 | 選択肢が多すぎると煩雑 |
| 日付 | 日付情報 | 時系列分析が可能 | タイムゾーンに注意 |
| 日時 | 日付+時刻 | 精密なタイムスタンプ | 日付のみで十分なら日付型を |
| チェックボックス | はい/いいえの二値 | 条件分岐がシンプル | 3値以上には不向き |
| 計算プロパティ | 他プロパティを参照して自動計算 | 手動入力不要 | Professional以上で利用可能 |
プロパティのデータ型を決める際は、次の順番で検討してください。
最も重要な原則は、「レポートやワークフローで使う可能性があるプロパティはテキストフィールドにしない」ことです。テキストフィールドは自由度が高い反面、入力のばらつきが避けられません。「東京」「東京都」「Tokyo」のように表記揺れが発生すると、レポートの集計精度が大幅に低下します。
HubSpotでは、プロパティをグループに分類して管理できます。グループはCRM画面の左サイドバーや、コンタクト/会社レコードのプロパティ一覧でセクションとして表示されるため、営業担当者が必要な情報を素早く見つけるための導線設計にもなります。
推奨するグループ分類は以下のとおりです。
グループ名にも一貫した命名ルールを適用します。表示名には日本語を使い、番号プレフィックスを付けることで画面上の表示順序を制御できます。
例：
こうしたルールを設定画面で統一しておくことで、新しいメンバーがCRMを開いたときにも迷わず情報にアクセスできます。
プロパティは一度設計して終わりではなく、四半期に1回の定期棚卸しを推奨します。チェックすべきポイントは以下のとおりです。
不要なプロパティを削除する際は、以下の手順で安全に進めます。
HubSpotの設定画面では 「プロパティ」→「未使用のプロパティ」 フィルタを使うことで、一定期間使われていないプロパティを一覧表示できます。
はい、HubSpotのプランに応じてカスタムプロパティの作成上限が設定されています。無料プランでは各オブジェクトあたり10個まで、Starterでは1,000個、Professional以上では1,000個（オブジェクトごと）が上限です。Enterpriseではさらに拡張が可能です。上限に達する前に、不要なプロパティの整理を定期的に行いましょう。
いいえ、HubSpotでは一度作成したプロパティの内部名は変更できません。表示名（ラベル）は後から自由に変更できますが、内部名はAPIやワークフローで参照されるため、固定されています。命名を誤った場合は、新しいプロパティを作成し、データを移行した上で旧プロパティを削除する方法をとります。
選択肢が30個を超えると、ユーザーが適切な値を見つけにくくなります。対策としては、階層化（親カテゴリ→子カテゴリの2段階ドロップダウン）の活用や、依存フィールド機能で条件に応じた選択肢の絞り込みを行う方法があります。また、そもそもカテゴリ体系自体を見直し、上位概念でグルーピングし直すことも有効です。
オブジェクトをまたいで同じ情報を持たせる場合は、どのオブジェクトを「マスター」とするかを決め、他のオブジェクトからはアソシエーション経由で参照する設計を推奨します。たとえば「業種」はコンタクトではなく会社オブジェクトに持たせ、コンタクトレコードからは関連会社の情報として参照します。これによりデータの二重管理を防げます。
カテゴリ: HubSpot機能ガイド | HubSpot