「取引だけでは管理しきれないので、カスタムオブジェクトを作ってください」——CRM導入プロジェクトの要件定義で、事業部門から必ず出てくる要望です。製造業なら装置や製番、商社なら案件と引合の別管理、サービス業なら契約単位の履行状況。いずれも実務上の理由があります。
ところが、この要望をそのまま受け入れると、半年後に扱いにくいCRMができあがります。オブジェクトが増えるとレポートは複雑になり、入力箇所が分散し、現場は「どこに何を入れるのか分からない」と言い始めます。しかも、カスタムオブジェクトには後から変更できない設定があります。
本記事では、HubSpot公式ナレッジベースの記載に基づき、カスタムオブジェクトを作る判断基準と、作らずに済ませる代替手段を整理します。作り方の手順そのものよりも、作る前に確定させておくべき事項に重点を置きます。
目次
カスタムオブジェクトは、標準で用意されているコンタクト・会社・取引・チケット以外に、自社固有のデータの単位を定義できる機能です。定義したオブジェクトは標準オブジェクトと同様に、プロパティを持ち、他のオブジェクトと関連づけられ、レポートの対象になります。
ここで押さえておくべきは、カスタムオブジェクトが「項目の追加」ではなく「レコードの種類の追加」だという点です。既存のレコードに列を足す作業とは性質が違います。新しい表を作り、その表と既存の表の関係を定義する作業に相当します。
公式ナレッジベースによれば、カスタムオブジェクトの作成には次のいずれかのEnterpriseサブスクリプションが必要です。Marketing Hub、Sales Hub、Service Hub、Data Hub、Content Hub、Smart CRM、Revenue Hub。
この要件は選定の初期に効きます。「カスタムオブジェクトが必要」という要件が確定した時点で、Professionalは選択肢から外れます。Professionalで検討を進めた後にこの要件が出てくると、予算の前提が変わります。エディションによる価格差はHubSpot料金プラン解説で確認できます。
作成はデータモデルの画面から行います。手順自体は難しくありませんが、途中で決める項目のうち一部が後から変更できないため、事前準備が実質的な作業になります。
| 手順 | 操作 | 後から変更できるか |
|---|---|---|
| 1 | ［詳細］→［データ管理］→［データモデル］にアクセス | — |
| 2 | 「カスタムオブジェクトを作成」をクリック | — |
| 3 | オブジェクト名（単数形・複数形）を設定 | 表示名は変更可、内部名は変更不可 |
| 4 | 主表示プロパティを設定（ラベル、タイプ、内部名、一意性チェック） | API経由でのみ編集可 |
| 5 | セカンダリプロパティを設定（任意・複数可） | 変更可 |
| 6 | 「作成」をクリック | — |
3行目と4行目が実務の要点です。内部名は変更できません。主表示プロパティは管理画面から編集できず、API経由でのみ編集可能です。つまり、この2つを決める段階が事実上の設計フェーズであり、ここを事業部門との擦り合わせなしに決めると、後戻りのコストが高くつきます。
公式ナレッジベースには、いくつかの制約が明記されています。HubSpotが定義済みのオブジェクトと同名のカスタムオブジェクトは作成できません。他のツールで使用中のオブジェクトは削除できません。オブジェクトおよびプロパティの内部名は変更できません。
「他のツールで使用中のオブジェクトは削除できない」という制約は、試作を繰り返す運用では厄介です。ワークフローやレポートに組み込んだ後に設計を見直したくなった場合、参照を外してから削除する必要があります。検証用に作ったオブジェクトが消せずに残る事故は、この経路で起きます。検証は本番ポータルではなく、サンドボックスまたは明確に検証用と分かる命名で行ってください。
要望を受けたときに問うべきは「必要か」ではありません。ほとんどの要望は必要です。問うべきは「レコードの種類として独立させる必要があるか」です。判定の観点は3つあります。
最初の観点です。そのデータが、それ自体で状態変化を持ち、独立して管理される必要があるかを見ます。
たとえば製造業の「装置」は、納入され、保守契約が結ばれ、部品が交換され、やがて更新提案の対象になります。この一連の流れは取引のライフサイクルとは別に進行します。この場合、独立したオブジェクトにする合理性があります。
一方、「引合の分類」や「案件のランク」は、取引の属性にすぎません。状態変化は取引に従属します。これはカスタムプロパティで足ります。
2番目の観点です。1つの取引に対して複数のレコードが紐づくか、あるいは1つのレコードが複数の取引に紐づくかを確認します。
1対1で対応するなら、プロパティで表現できます。1対多、多対多の関係が必要な場合は、オブジェクトとして独立させる必要があります。ここは判定が明確で、議論の余地が少ない観点です。
3番目の観点です。運用が始まってから最も差が出ます。
「装置別の保守売上」「製番別の進捗」のように、そのレコードを軸にした集計を見たいのであれば、オブジェクトが必要です。逆に、集計の軸が常に取引や会社であり、そのデータは参照するだけであれば、オブジェクト化しても管理コストだけが増えます。
実務では、この観点を確認せずにオブジェクトを作り、結果として誰も見ないレコードが大量に生成されるケースが最も多く見られます。入力の負荷は現場が負い、集計は使われない。この状態はCRMへの信頼を確実に損ないます。
3つの観点で判定した結果、オブジェクト化が不要と分かった場合の受け皿を用意しておく必要があります。「作りません」だけでは事業部門は納得しません。代替案を同時に示すことが実務です。
| 要望の型 | 代替手段 | 適する条件 |
|---|---|---|
| 取引を種類別に分けて管理したい | 複数パイプライン | ライフサイクルの段階が種類ごとに異なる |
| 属性を追加したい | カスタムプロパティ | 1対1で対応し、独立した状態変化がない |
| 関係の意味を区別したい | 関連付けラベル | 同じオブジェクト間で役割が複数ある |
| 外部システムのデータを見たい | Data Studio／データ同期 | 正が外部システムにあり、CRMでは参照のみ |
| 製品と価格を管理したい | 製品ライブラリ・価格表 | 見積・請求の対象となる商材である |
4行目は見落とされやすい選択肢です。基幹システムに正があるデータを、カスタムオブジェクトとしてCRMに複製すると、二重管理が始まります。参照だけで足りるなら、CRM側にレコードを持たない構成のほうが運用は安定します。
設計の前に上限を把握しておく必要があります。上限に達してから設計を見直すのは、最も避けたい事態です。
公式ナレッジベースには、カスタムオブジェクトの数とプロパティの数に上限がある旨が記載されており、具体的な数値はProduct & Services Catalogを参照するよう案内されています。契約前に、自社の設計が上限内に収まるかをカタログの数値で確認してください。
関連する上限として、パイプラインと関連付けの制約があります。カスタムオブジェクトのパイプライン数はEnterpriseで350とされており、この上限はオブジェクトごとではなく全カスタムオブジェクトの合計に対して適用されます。レコード関連付けの上限は、カスタム設定として最大10,000まで構成できます。
現在の使用状況はCRMデータの使用状況から確認できます。設計時に一度見るだけでなく、管理者の月次確認項目に入れて定点観測してください。上限に達してから設計を見直すと、稼働中のワークフローとレポートの作り直しが伴います。
権限の設計は、技術的な論点ではなく統制の論点です。公式ナレッジベースには、カスタムオブジェクトの作成・編集・管理にはアカウントアクセス権限が必要であると記載されています。
1,000名規模の組織では、この権限を誰に与えるかが運用品質を左右します。事業部門の担当者に開放すると、部門ごとに似たオブジェクトが乱立します。逆に情報システム部門に閉じると、要望のたびに数週間の待ちが発生し、現場はExcelに戻ります。
推奨するのは、作成権限は限定し、要望の受付と判定のプロセスを明文化する運用です。前述の3つの観点を判定シートにして、要望者に記入させる方式が実務的に機能します。判定基準が文書になっていれば、「なぜ作らないのか」の説明が属人的になりません。権限設計の全体像はHubSpotのユーザー権限とは？で整理しています。
2026年に入って、カスタムオブジェクトの設計に新しい観点が加わりました。AIエージェントが参照するデータの範囲です。
HubSpotのAIコンテキストとKnowledge Vaultsは、エージェントやアシスタントに業務上の前提情報を与える仕組みです。公開されているアップデート情報によれば、Knowledge Vaultsはカスタムオブジェクトの接続にも対応しています。
これは設計の意味を変えます。従来、カスタムオブジェクトの価値は「人が見るレポート」でした。今後は「AIが参照する構造化データ」という価値が加わります。自由記述のメモに埋もれていた情報を構造化しておくと、エージェントが判断に使えるようになります。逆に、構造化されていない情報はAIにも使えません。
ただし順序は変わりません。使われないオブジェクトを作ることが正当化されるわけではありません。「AIが使うから」という理由で無条件にオブジェクトを増やすと、品質の低いデータが増え、エージェントの出力精度が下がります。Context設計の詳細はAgent HubのContext設計とKnowledge Vaultの使い分けで解説しています。
公正に整理します。柔軟性には必ず運用負荷が伴います。
| 観点 | 利点 | 負担 |
|---|---|---|
| データモデル | 業務の実態に合わせた構造を作れる | 内部名・主表示プロパティが後から変えにくい |
| レポート | 独自の軸で集計できる | オブジェクトが増えるほどレポート設計が複雑化する |
| 入力 | 情報が構造化され、検索・自動化に使える | 入力箇所が分散し、現場の負荷が上がる |
| AI活用 | エージェントが参照できる構造化データになる | 品質の低いデータはAIの精度を下げる |
| 費用 | — | Enterpriseが必要になる |
株式会社100がCRMの全社設計を支援する際、カスタムオブジェクトの議論で最も時間をかけるのは、作り方ではなく「その要望の背後にある業務課題は何か」の確認です。オブジェクトが必要に見える要望の多くは、実際にはパイプラインの分割や関連付けラベルで解決します。要望を機能の言葉で受け取らず、業務の言葉に戻して聞き直すことが、設計の入口になります。
公式ナレッジベースには、いずれかのEnterpriseサブスクリプションが必要と記載されています。Professionalでは作成できません。要件が確定している場合、エディション選定の前提として扱ってください。
表示名は変更できますが、内部名は変更できません。API連携やワークフローの参照に影響するため、内部名は命名規則を決めてから作成してください。
管理画面からは編集できず、API経由でのみ編集可能とされています。開発リソースが必要になるため、作成時に確定させておくことが現実的です。
他のツールで使用中のオブジェクトは削除できないと明記されています。ワークフロー・レポート・リストなどからの参照を外してから削除してください。検証は本番ポータルを避けることをおすすめします。
不要な場合が多いです。見積・請求の対象となる商材であれば、製品ライブラリと価格表で扱えます。商材以外の1対多の関係であれば、オブジェクト化を検討する余地があります。
正が基幹システムにあるなら、複製ではなく参照を検討してください。データ同期やData Studioでの参照であれば、二重管理を避けられます。CRM側で編集する必要がある場合に限り、複製が正当化されます。
あります。具体的な数値はProduct & Services Catalogに記載されているため、契約前に自社の設計が収まるかを確認してください。パイプラインについては、Enterpriseで350という数値が全カスタムオブジェクトの合計に対して適用されるとされています。
断るのではなく、判定基準を先に共有してください。独立したライフサイクルを持つか、1対多の関係が必要か、そのレコード単位でレポートを見るか——この3点を要望者に記入させる方式にすると、判断が属人的でなくなり、代替手段の提示もしやすくなります。
本記事はHubSpot公式ナレッジベースおよびProduct & Services Catalogの公開情報（2026年9月1日取得時点）に基づいて作成しています。上限値・エディション要件は変更される可能性があるため、設計判断の際は公式ドキュメントの最新記載をご確認ください。Knowledge Vaultsのカスタムオブジェクト対応については公開されているアップデート情報に基づく記述です。