HubSpotを数年運用した企業のポータルを開くと、コンタクトのプロパティが数百個に膨らんでいることがあります。「業種」「業種区分」「顧客業種」「industry_new」が並び、どれにも値が入っていて、どれが正かは誰も答えられない。レポートを作ろうとすると、同じ意味の項目が複数のドロップダウンに出てきて、どれを選ぶべきか決められない。AIにデータを渡そうとしても、同じ概念が4つの箱に分散しているため、まともな答えが返ってきません。
これは運用の怠慢ではなく、プロパティを作るときのルールが存在しなかった結果です。プロパティの作り方そのものは画面を数回クリックすれば終わるため、誰でも作れてしまいます。本記事では、作る前に決めるべきこと、命名規則、データ型の選び方、選択肢の統一、入力規則、計算プロパティとロールアップの使い分け、そして使われないプロパティの棚卸しまでを、設計と運用のルールとして整理します。プロパティの機能そのものはHubSpotプロパティーとは？カスタムプロパティーの作成方法で扱っているため、本記事は設計論に絞ります。
目次
プロパティの増殖には再現性のあるパターンがあります。どの企業でも同じ順序で増え、同じ場所で破綻します。先に増殖のメカニズムを把握しておくと、どこに歯止めをかけるべきかが見えます。
最初のきっかけは、たいてい「標準プロパティで足りるかを確認せずに作る」ことです。カスタムプロパティを作る前に、既定のプロパティで要件を満たせるかを確認します。コンタクト・会社・取引・チケット・リード・明細・商品といったオブジェクトごとに既定のプロパティが用意されています。
次のきっかけは、インポートです。CSVの列をそのままマッピングしていくと、既存プロパティに対応づけずに新規作成してしまいます。三つ目は、部門ごとの個別要望です。営業企画が作った「確度」とカスタマーサクセスが作った「受注確率」が並び、どちらも使われます。四つ目は、連携アプリが自動生成するプロパティです。作る権限を誰に与えるかを決めていない組織では、この4経路すべてが開きっぱなしになります。
作成権限は「プロパティ設定の編集」権限で制御できます。この権限はオブジェクトのプロパティの作成・編集・アクセス管理に加えて、パイプラインとステージの作成・編集も可能にします。プロパティの統制は、権限設計とセットでしか成立しません。
壊れるのはレポートとセグメントと自動化、そしてAIです。同じ概念のプロパティが複数あると、レポートの軸が分裂し、セグメントの条件が噛み合わず、ワークフローの分岐が意図せず外れます。AIにデータを渡す局面では影響がさらに大きくなり、同じ意味の項目が複数あるだけで回答の根拠が揺れます。AIが動かない本当の理由はデータにあるで整理したとおり、データ基盤の整備なしにAIは機能しません。
もう一つの実害は、レコード画面の見づらさです。項目が多すぎると、営業担当者は必要な情報にたどり着けず、入力もしなくなります。レコードに表示する項目の構成はCustomize recordsで設定できますが、根本的にはプロパティの総数を抑えることでしか解決しません。
プロパティ設計で最も重要なのは、後から変更できない項目を作成時に決め切ることです。HubSpotのプロパティは、ラベルや説明文のように後から自由に変えられるものと、作成時にしか決められないものが混在しています。この区別を知らないまま量産すると、作り直し以外に手がなくなります。
| 項目 | 作成後の変更 | 設計上の含意 |
|---|---|---|
| オブジェクトの種類 | 変更できない | どのオブジェクトに持たせるかを先に決める |
| 内部名 | 作成後は編集できない | 命名規則を先に確定させる |
| ラベル | 変更できる | 表示名は後から日本語化できる |
| フィールドタイプ | 変更できるが既存値が無効になる場合がある | 変更前にエクスポートを取る |
| 一意の値の必須化 | 作成時のみ設定可能 | キー項目は作成時に決める |
| 機密データの指定 | 作成後は変更できない | 機密性の判定を作成時に行う |
| 計算プロパティの種類 | Time between／since／untilの別は変更できない | 計算の型を先に決める |
既存プロパティの編集画面では、オブジェクトタイプと内部名を編集できません。内部名はAPI、ワークフロー、計算プロパティの数式、連携アプリのマッピングから参照される識別子であり、変えると参照元がすべて壊れるためです。計算プロパティの数式でプロパティを手入力する場合は、`[properties.{内部名}]` の形式で指定します。
なお、削除済みの非一意プロパティと同じ内部名で一意制約を有効にするとエラーになり、詳細タブの編集アイコンから内部名を別の値に変更して解決します。この操作が可能な範囲と、作成後は編集できないという記載との境界について、公式ドキュメントに明示的な説明は確認できませんでした。運用の前提としては、内部名は変えられないものとして扱うのが安全です。
既存プロパティのフィールドタイプを変更すると現在の値が無効になる場合があるため、変更前にすべての情報をエクスポートすることが推奨されています。アカウント全体に変更が反映されるまで、最大30分かかる場合があります。
特に注意が必要なのが、テキストからドロップダウンへの変換です。複数行テキストまたは1行テキストをドロップダウン系（複数チェックボックス、ラジオ選択、ドロップダウン選択）に変更すると、そのプロパティに存在するユニークなテキスト値ごとに選択肢が自動生成されます。LinkedIn、linkedin、linked in は別々の値として扱われ、それぞれが選択肢になります。表記ゆれを放置したまま型を変えると、ゆれの数だけ選択肢が増えます。
どちらも作成時です。一意の値の必須化は、オブジェクトごとに最大10個まで作成でき、プロパティの作成時にのみ設定できます。フィードバック送信、マーケティングイベント、商品は現時点で非対応です。取引先コードや契約番号のような外部キーを持たせる場合は、この枠を何に使うかを先に決めてください。
機密データの指定も、作成後は変更できません。既定のプロパティを機密データプロパティに変換することもできないため、機密性のある情報は新規のカスタムプロパティとして定義する必要があります。
命名規則をシステム側で強制する設定について、公式ドキュメントに記載は確認できませんでした。つまり規律は運用で守るしかありません。だからこそ、誰でも同じ判断ができる単純な規則にしておく必要があります。
ラベルは利用者が画面で見る名前、内部名はシステムが参照する識別子です。この2つに同じ文字列を使う必要はありません。私たちが設計する際は、ラベルは業務用語の日本語、内部名は英数字とアンダースコアのみという分離を徹底しています。ラベルは後から変えられるため、業務側の言い方が変わっても追随できます。
内部名の構成は、接頭辞で出自を示す形が扱いやすくなります。たとえば自社で追加したものには共通の接頭辞を付け、連携アプリが生成したものと区別できるようにします。HubSpotの既定プロパティは `hs_` で始まるものが多く、Quote propertiesのような一覧ページで内部名の付け方を確認できます。既定プロパティと同じ命名パターンを自社プロパティに使うと、どちらが標準かを後から判別できなくなります。
名前に入れるべき情報は3つに絞れます。何の概念か、どの業務領域のものか、どの型かです。逆に入れてはいけないのは、作成年、作成者名、プロジェクト名、「new」「old」「tmp」といった時間的な位置づけです。これらは半年後に意味を失い、「industry_new」のほうが古い、という事態を生みます。
プロパティの説明文も命名の一部として扱ってください。プロパティエディタのDocumentationタブで説明を追加でき、ユーザーが値をどう入力すべきかの案内を書けます。似た名前のプロパティが並んだとき、説明文の有無が選択の決め手になります。エディタ各タブの役割はUnderstand the property editorに整理されています。
グループは設定画面の中だけで効く分類です。既定のグループに加えてカスタムグループを作成でき、レコード上での表示順はグループではなくレコードサイドバーで制御します。
グループは部門名ではなく、データの出自で切るのが運用に向いています。手入力されるもの、フォームから入るもの、連携で同期されるもの、計算で求まるもの、という4分類にしておくと、値がおかしいときに原因の切り分けが速くなります。オブジェクト全体の構成を考える段階ではHow to use objects for business processesとHubSpotカスタムオブジェクトの設計判断と作らない基準を併せて参照してください。
データ型の選択は、入力のしやすさではなく、後工程での使われ方で決めます。レポートで集計したいのか、セグメントで絞りたいのか、ワークフローで分岐させたいのか。この3つのどれにも使わない項目は、そもそも作る必要がありません。
集計・絞り込み・分岐のいずれかに使うなら、選択肢型を選びます。テキスト型は表記ゆれを止められないためです。1行テキストと複数行テキストはCRM経由での入力時に65,536文字の上限があり、フォーム送信では上限がありません。
選択肢型には技術的な上限があります。列挙型プロパティでは、各選択肢はラベル・値・説明を含めて最大3,000文字、プロパティ全体のサイズは512,000バイトまたは5,000個の選択肢のいずれか先に達したほうが上限です。選択肢が数千に達する項目は、プロパティではなく別オブジェクトとして持つべき兆候です。選択肢の統合や並べ替えはManage enumeration property optionsの手順で行えます。
数値型は書式の選択が結果を左右します。書式ありの数値は20桁を超えると指数表記になり、書式なしの数値は文字列として扱われるため桁数を多く持てますが、レポートでの精度を考えると合計38桁、うち小数点以下10桁までに収めることが推奨されています。パーセント型の値は小数として保存されます。
通貨型はアカウントの既定通貨の設定に従って書式が決まります。多通貨を扱う場合、表示上の通貨と集計上の通貨が食い違いやすいため、レポート要件を先に固めてから型を決めてください。
日付型には、日付のみと日付と時刻の2種類があります。日付と時刻のプロパティは、閲覧・編集時はユーザーの端末のタイムゾーン、フィルタ時は既定でアカウントのタイムゾーンが使われます。同じ値が人によって別の日付に見えるという事象は、ここから生じます。
さらに、フォームでの扱いにも制約があります。旧エディタのフォームでは日付と時刻のプロパティは日付のみ表示され、CRMに値が入りません。更新版のフォームビルダーでは日付と時刻のプロパティをフォームに追加できないため、フォームで取得する項目は日付型を使うことが推奨されています。フォーム経由の取得を想定する項目は、この制約を前提に型を選んでください。
表記ゆれは、入力の瞬間に止めるのが最も安く済みます。後から一括置換すると履歴が壊れ、レポートの前年比較が成立しなくなります。HubSpotには入力時点で縛るための仕組みが用意されています。
入力規則は1行テキスト、複数行テキスト、日付、日付と時刻、電話番号、数値のフィールドタイプに設定できます。テキストでは、前後の空白の禁止、すべての空白の禁止、最小文字数、最大文字数、禁止文字の自動削除、数字のみ、記号や特殊文字の禁止、大文字のみ、小文字のみ、各単語の先頭を大文字にする、といった指定ができます。正規表現によるカスタムルールはProfessionalまたはEnterpriseが必要です。
数値では最小値・最大値・小数点以下の桁数を、電話番号では自動の書式検証と既定の国コードを設定できます。カスタムプロパティだけでなく、会社の住所や年間売上、コンタクトのメールアドレスや氏名、取引の金額や失注理由といった既定プロパティにも設定できます。既定プロパティにも規則をかけられる点は見落とされがちです。
ここが設計の要点です。入力規則が適用されない経路もあります。ワークフロー、チャットフロー、ミーティングのスケジューリングページへの送信、旧エディタで作成したフォームへの送信では適用されません。更新版のフォームエディタで作成したフォームへの送信では適用されます。また、既存の値がさかのぼって整形されることはありません。
つまり、入力規則だけではデータ品質は守り切れません。ワークフローで値を書き込んでいる箇所、旧エディタのフォーム、インポートの3経路については、別の手当てが必要です。インポートファイルの作り方はFormat import filesに整理されており、実務の手順はHubSpotにデータをインポートする方法にまとめています。ワークフローで値をコピーする際の型の互換性はCompatible property types for copying values with workflowsで確認できます。
一意の値を必須にしたプロパティは、重複の抑止にも使われます。一意の値プロパティは、重複排除の仕組みの中でも使われます。コンタクトはメールアドレス、会社はドメインという既定の識別子がありますが、取引先コードを正とする業務では、自社のキーを一意プロパティとして持たせる設計が有効です。
キー設計は、外部システムとの連携とセットで考えてください。基幹システムの取引先コードを一意プロパティに持たせておくと、同期の突合が単純になります。データ統合の全体設計はSSOT（信頼できる唯一の情報源）とはで扱っています。
計算系のプロパティは、手入力を減らす最も効果的な手段です。入力されない項目は品質が上がらないため、計算で求まるものは計算に寄せます。ただし種類ごとに制約が異なり、後から型を変えられないものもあります。
計算プロパティとロールアップは、Marketing Hub・Sales Hub・Service Hub・Content Hub・Smart CRM・Revenue HubのProfessionalまたはEnterprise、およびData Hub Professionalで利用できます。ロールアップでは、関連付けられたレコードのプロパティについて、最小値、最大値、件数、合計、平均、最も古い日付、最も新しい日付を求められます。
設計上有用なのは、関連付けラベルで対象を絞れる点です。特定の関連付けラベルを持つレコードだけを対象に計算できます。意思決定者ラベルの付いたコンタクトに紐づく営業活動数を、取引側で数えるといった使い方です。さらに、ロールアップ1つあたり最大50個の数値型・列挙型の条件を設定できます。メールは集計元としてサポートされていない点は制約として押さえてください。
Time between、Time since、Time untilの3種類があり、作成後にこの区別を変更することはできません。開始日・終了日のプロパティは後から差し替えられます。Time betweenには週末を除外するオプションがあり、週末は土曜0時から日曜23時59分までとアカウントのタイムゾーンを基準に定義されます。
最も事故が起きやすいのは、値の単位です。期間、Time between、平均といった計算プロパティの生の値は、ミリ秒で保存されます。フィルタや他の計算プロパティの数式でこれらを参照する場合、ミリ秒の値を使う必要があります。想定より桁が大きい結果が出たときは、まず単位を疑ってください。
表示上の単位にも閾値があります。2.5年以上は年、3か月以上は月、1日以上は日、2.5時間以上は時間、2.5分以上は分、それ未満は秒で表示されます。また、Time sinceとTime untilは、カスタムレポートビルダーのフィルタ、計算プロパティやロールアップの入力、カスタムデータ同期のフィールドマッピングではサポートされていません。レポートで使いたい期間指標は、Time betweenで作ると覚えておくと手戻りが減ります。
判断の基準は、値をレコードに残す必要があるかどうかです。レコード上で参照したい、ワークフローの分岐条件に使いたい、他のプロパティの計算元にしたい、という要件があれば計算プロパティにします。レポートの中だけで使う一時的な計算であれば、Create formula fields in the custom report builderにあるレポート側の計算フィールドで足ります。
計算プロパティはレコードごとに値を持つため、作りすぎると棚卸しの対象が増えます。レポートで一度しか使わない計算をプロパティにしないというルールを置くだけで、増殖はかなり抑えられます。入力の自動化をさらに進める場合はAutomatically populate records using smart propertiesにあるスマートプロパティも選択肢になります。
設計ルールを決めても、過去に作られたプロパティは残ります。棚卸しは一度やって終わりではなく、四半期ごとの定例作業として組み込むものです。HubSpot側に検出の仕組みがあるため、手作業で数える必要はありません。
Use data quality toolsのデータ品質の概要ページには、プロパティインサイトの項目があり、プロパティの総数と期間内の課題件数をグラフで確認できます。凡例には重複、データなし、未使用の3種類が示されており、どの観点で問題のあるプロパティがどれだけあるかを把握できます。書式の問題を検出して一括で修正する機能や、重複レコードの検出と統合も同じ画面から扱えます。
提供条件は、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content HubのStarter以上、Smart CRMとRevenue HubはProfessional以上です。閲覧にはスーパー管理者権限、またはデータ品質ツールへのアクセス権と表示権限が必要です。週次のデータ品質ダイジェストをメールで受け取る設定も用意されています。データ品質の自動化についてはデータエージェントとは？CRMデータクレンジングへの活用法で扱っています。
個別のプロパティについては、プロパティの編集画面にUsages、Data quality、Data sourcesの各タブがあり、CRM内のどこで使われているか、どのツールがこのプロパティを更新しているかを確認できます。「使われていないから消す」の前に、「どこから更新されているか」を見てください。
アーカイブしたプロパティはアーカイブタブに格納され、90日後に完全に削除されます。アーカイブできるのは、レコードやアセットで使われていないプロパティです。セグメント、フォーム、ワークフローなどで使われている場合は、先にそちらから外す必要があります。
アーカイブ操作の画面では、そのプロパティの入力率、アーカイブを妨げているアセット、そのプロパティを使っているその他のアセットが表示されます。入力率が表示されるため、値が入っているかどうかを根拠に判断できます。値があってもアーカイブ自体は可能です。複数まとめてアーカイブする場合は、対象件数を数字で入力して確認する手順になっています。
私たちが定着支援で回している手順は4段階です。第一に、プロパティ定義をエクスポートして一覧化します。第二に、入力率と使用箇所を見て、不要・統合・残すの3分類に振り分けます。第三に、統合対象は値の移送をワークフローで行ったうえで旧プロパティをアーカイブします。第四に、新規作成の申請経路を1本に絞り、次の四半期までに増えた分を追跡します。
第四段階が抜けると、棚卸しの翌月から再び増え始めます。プロパティ設定の編集権限を持つ人数を絞り、作成の依頼をチケットやフォームで受ける形にしてください。誰がいつプロパティを作ったかは、View and export account activity historyの監査ログで追跡できます。各機能の提供条件はProduct and Services Catalogに定義されており、内容は変更される可能性があります。
なお、サブスクリプションごとに作成できるカスタムプロパティには上限がありますが、同ページで具体的な数値は確認できませんでした。上限に近づいている場合は、プログラムから一覧を取得して集計するのが確実です。取得方法はProperties APIにあります。カスタムオブジェクトを追加する場合のプロパティ設計はCreate and edit custom objectsを参照してください。データ品質が整っていないままAIを載せた場合の問題はAgent Hub導入で失敗する組織の共通点で扱っています。
プロパティ設計を進める過程で、本文の流れには乗らないものの実務で必ず直面する論点をまとめます。
全件を一度に整理しようとすると終わりません。レポートとセグメントで実際に使われている項目を先に特定し、それ以外を候補プールに落とす順序が現実的です。プロパティの編集画面のUsagesタブで使用箇所を確認できるため、使われている項目から逆算してください。
既存プロパティの内部名は編集できないため、直すには新しいプロパティを作り、値を移送して旧プロパティをアーカイブする手順になります。値の移送はワークフローで行えますが、型の互換性を事前に確認してください。移送後はレポート、セグメント、連携のマッピングをすべて張り替える必要があります。
選択肢の削除や統合を行う前に、その値を持つレコードがどれだけあるかを確認してください。統合の操作は列挙型プロパティの管理画面から行えます。レポートの前年比較を維持したい場合は、統合前の状態をエクスポートして保全しておくことを推奨します。
既存の値が、さかのぼって整形されることはありません。規則は編集時とインポート時に適用されるため、既存データの是正は別途クレンジングが必要です。データ品質ツールの書式の問題のタブから一括で修正できる項目もあります。
まず単位を確認してください。期間、Time between、平均の生の値はミリ秒で保存されます。次に、関連付けラベルの条件と、ロールアップに設定した条件を確認します。それでも合わない場合は、計算元のプロパティに空値が含まれていないかを確認してください。
その情報が「誰について」の情報かで決まります。人に紐づくならコンタクト、組織に紐づくなら会社、案件に紐づくなら取引です。判断に迷う項目は、更新のタイミングで考えてください。案件ごとに変わる値を会社に持たせると、上書きで履歴が失われます。
仕様です。カスタムの商品プロパティを作成すると、変更できない同一の明細プロパティが作成されます。商品プロパティの値の更新は明細プロパティに同期されます。カスタムの明細プロパティは商品側には影響しません。
アーカイブで枠を空けるのが第一手です。アーカイブ後90日で完全削除されますが、枠の扱いについては自社のポータルで実測して確認してください。構造的に項目が多すぎる場合は、プロパティを増やすのではなくカスタムオブジェクトに分離する設計を検討する段階です。
本記事に記載したHubSpotの仕様・提供条件・上限値は、2026年10月23日時点で公式ナレッジベースおよび開発者向けドキュメントを確認したものです。機能および提供条件は変更される可能性があるため、実装前に必ず最新の一次情報をご確認ください。