HubSpotプロパティ設計のベストプラクティス｜命名規則・データ型選択・グルーピングの指針

「カスタムプロパティを追加するたびに名前の付け方がバラバラで、後から何のためのプロパティか分からなくなる」

「ドロップダウンにすべきか、テキストフィールドにすべきか、データ型の選択に迷う」

——HubSpotを本格運用している企業ほど、こうしたプロパティ設計の悩みに直面します。

HubSpotのプロパティは、CRMに蓄積されるすべてのデータの「型」を決める土台です。プロパティの設計が雑だと、レポートが正しく出力されない、ワークフローの条件分岐が複雑化する、データの重複が増えるなど、後工程のあらゆる業務に悪影響を及ぼします。

この記事では、HubSpotのプロパティ設計における命名規則・データ型選択・グルーピングのベストプラクティスを、具体例を交えて解説します。

この記事でわかること

• HubSpotプロパティの基本構造とオブジェクトごとの考え方
• 命名規則の設計パターンとルール化の方法
• データ型ごとの特性と適切な使い分け
• プロパティグループによる整理・管理の指針
• 運用フェーズでのプロパティ棚卸しの進め方
• 既存プロパティの整理・統廃合の手順

本記事はStartLinkの「HubSpot完全ガイド」関連記事です。

プロパティ設計がCRMの品質を左右する理由

HubSpotのCRMは、コンタクト・会社・取引・チケットなどのオブジェクトに紐づく「プロパティ」によってデータを管理しています。デフォルトで用意されているプロパティだけでも数百項目ありますが、自社のビジネスプロセスに合わせたカスタムプロパティの追加は避けられません。

問題は、カスタムプロパティの設計にルールがない状態で運用を進めると、次のような課題が蓄積していくことです。

• 同じ意味のプロパティが複数存在する（例：「業種」「業界」「業種分類」）
• プロパティ名だけでは何を入力すべきか判断できない
• テキストフィールドに自由入力されたデータがレポートに使えない
• 部署ごとに独自のプロパティが乱立し、全体像を把握できない

Notion社は、HubSpot導入初期にプロパティのガバナンスルールを定めず運用した結果、1年後には大量の未使用プロパティが蓄積し、後からプロパティ設計のガイドラインを策定し直した事例を公開しています。

命名規則の設計パターン

推奨する命名ルール

プロパティの命名規則は、チーム全員が迷わず「このプロパティは何を意味するか」を理解できることが最大の目的です。以下のルールを推奨します。

基本フォーマット: [プレフィックス]_[対象]_[内容]

たとえば、マーケティング部門が管理するリードの獲得チャネルであれば mktg_lead_acquisition_channel となります。

命名で避けるべきパターン

• 曖昧な名前: 「メモ」「フラグ」「ステータス」など、単体では意味が通じない名前
• 日本語と英語の混在: 内部名（API名）は英語に統一し、表示名で日本語を使う
• 略語の多用: 部門内では通じても、他チームには理解できない略語は避ける
• 連番: custom_field_1、custom_field_2 のような意味のない連番

表示名と内部名の使い分け

HubSpotのプロパティには「表示名（ラベル）」と「内部名（Internal name）」の2つがあります。

• 表示名: 日本語で分かりやすく記載する（例：「マーケ_リード獲得チャネル」）
• 内部名: 英語のスネークケースで統一する（例：mktg_lead_acquisition_channel）

内部名はAPI連携やワークフローの条件設定で使われるため、一度決めたら変更できません。最初の設計段階で慎重に命名することが重要です。

データ型の選び方と使い分け

HubSpotで使えるデータ型一覧

HubSpotには多様なプロパティタイプ（データ型）が用意されています。目的に応じた適切な型を選ぶことで、レポートの精度やワークフローの柔軟性が大きく変わります。

データ型選択の判断フロー

プロパティのデータ型を決める際は、次の順番で検討してください。

1. 選択肢が決まっているか？ → はい → ドロップダウン or 複数チェックボックス
2. 数値として計算に使うか？ → はい → 数値 or 計算プロパティ
3. 日時の記録が目的か？ → はい → 日付 or 日時
4. はい/いいえの二択か？ → はい → チェックボックス
5. 上記すべてに該当しない → 単行テキスト or 複数行テキスト

最も重要な原則は、「レポートやワークフローで使う可能性があるプロパティはテキストフィールドにしない」ことです。テキストフィールドは自由度が高い反面、入力のばらつきが避けられません。「東京」「東京都」「Tokyo」のように表記揺れが発生すると、レポートの集計精度が大幅に低下します。

プロパティグループによる整理

グループ設計の基本方針

HubSpotでは、プロパティをグループに分類して管理できます。グループはCRM画面の左サイドバーや、コンタクト/会社レコードのプロパティ一覧でセクションとして表示されるため、営業担当者が必要な情報を素早く見つけるための導線設計にもなります。

推奨するグループ分類は以下のとおりです。

• 基本情報: 社名・氏名・連絡先・住所など
• マーケティング: リードソース・スコア・キャンペーン関連
• セールス: 商談ステージ・受注理由・失注理由・予算
• カスタマーサクセス: 契約情報・NPS・ヘルススコア
• 管理用: 内部管理フラグ・同期ステータス・更新日時

グループの命名と表示順序のコントロール

グループ名にも一貫した命名ルールを適用します。表示名には日本語を使い、番号プレフィックスを付けることで画面上の表示順序を制御できます。

例：

• 「01_基本情報」
• 「02_マーケティング」
• 「03_セールス」
• 「04_カスタマーサクセス」
• 「99_管理用（非表示）」

こうしたルールを設定画面で統一しておくことで、新しいメンバーがCRMを開いたときにも迷わず情報にアクセスできます。

運用フェーズでのプロパティ棚卸し

定期棚卸しのチェック項目

プロパティは一度設計して終わりではなく、四半期に1回の定期棚卸しを推奨します。チェックすべきポイントは以下のとおりです。

• 使用頻度の確認: 過去90日間で一度も更新されていないプロパティを洗い出す
• 重複プロパティの統合: 同じ意味のプロパティが複数ないか確認する
• データ充填率の確認: 入力率が10%未満のプロパティは必要性を再検討する
• ワークフロー依存の確認: 削除・変更する場合、依存するワークフローがないか調べる

プロパティの統廃合手順

不要なプロパティを削除する際は、以下の手順で安全に進めます。

1. 依存関係の調査: 当該プロパティを使用しているワークフロー・レポート・リストを検索
2. データのエクスポート: 削除前に該当プロパティのデータをCSVでエクスポート
3. 統合先への移行: 重複プロパティの場合、データを統合先のプロパティにコピー
4. アーカイブ期間の設定: 即削除ではなく、まず「未使用」グループに移動して30日間様子を見る
5. 最終削除: 問題が発生しなければ削除を実行

HubSpotの設定画面では 「プロパティ」→「未使用のプロパティ」 フィルタを使うことで、一定期間使われていないプロパティを一覧表示できます。

よくある質問（FAQ）

Q1: カスタムプロパティの上限数はありますか？

はい、HubSpotのプランに応じてカスタムプロパティの作成上限が設定されています。無料プランでは各オブジェクトあたり10個まで、Starterでは1,000個、Professional以上では1,000個（オブジェクトごと）が上限です。Enterpriseではさらに拡張が可能です。上限に達する前に、不要なプロパティの整理を定期的に行いましょう。

Q2: 一度作成したプロパティの内部名（API名）は変更できますか？

いいえ、HubSpotでは一度作成したプロパティの内部名は変更できません。表示名（ラベル）は後から自由に変更できますが、内部名はAPIやワークフローで参照されるため、固定されています。命名を誤った場合は、新しいプロパティを作成し、データを移行した上で旧プロパティを削除する方法をとります。

Q3: ドロップダウンの選択肢が増えすぎた場合はどうすればよいですか？

選択肢が30個を超えると、ユーザーが適切な値を見つけにくくなります。対策としては、階層化（親カテゴリ→子カテゴリの2段階ドロップダウン）の活用や、依存フィールド機能で条件に応じた選択肢の絞り込みを行う方法があります。また、そもそもカテゴリ体系自体を見直し、上位概念でグルーピングし直すことも有効です。

Q4: 複数のオブジェクトに同じプロパティを作るべきですか？

オブジェクトをまたいで同じ情報を持たせる場合は、どのオブジェクトを「マスター」とするかを決め、他のオブジェクトからはアソシエーション経由で参照する設計を推奨します。たとえば「業種」はコンタクトではなく会社オブジェクトに持たせ、コンタクトレコードからは関連会社の情報として参照します。これによりデータの二重管理を防げます。

カテゴリ: HubSpot機能ガイド | HubSpot