HubSpotカスタムオブジェクトの設計判断｜標準で足りない時に何をどう作るか

「標準オブジェクトのプロパティに無理やり詰め込んだ結果、取引レコードが100以上の項目で肥大化してしまった」「カスタムオブジェクトを作ったはいいが、誰も使っていない」「どこまでを標準で対応し、どこからカスタムオブジェクトを作るべきか判断がつかない」

HubSpotの導入支援を重ねる中で、カスタムオブジェクトに関するこうした相談を頻繁に受けます。そして、その多くに共通するのは、「作るべきか・作らないべきか」の判断基準が曖昧なまま設計を進めてしまったという問題です。

カスタムオブジェクトはHubSpotの柔軟性を大幅に高める強力な機能ですが、安易に追加すればCRM全体の複雑性が増し、運用コストが跳ね上がります。逆に、必要な場面でカスタムオブジェクトを使わず、標準オブジェクトに情報を詰め込み続ければ、データ構造が破綻します。

本記事では、多数のHubSpot導入案件から体系化したカスタムオブジェクトの設計判断フレームワークを提供します。「いつ作るべきか」「いつ作らないべきか」の判断基準、設計パターン、そして実務で遭遇する典型的な失敗パターンと成功パターンを具体的に解説します。CRMデータベース設計の基本については前回の記事で解説していますので、あわせてご参照ください。

この記事でわかること

• HubSpotカスタムオブジェクトとは何か、標準オブジェクトとの違い
• カスタムオブジェクトを「作るべきか・作らないべきか」を判断する5つの基準
• 標準オブジェクトで代替できるケースの見極め方
• カスタムオブジェクト設計で失敗する5つのパターンとその回避策
• カスタムオブジェクト設計で成功する3つのパターンと実装例
• MRR管理における「請求」カスタムオブジェクトの設計事例
• カスタムオブジェクト導入後の運用設計と保守の考え方

HubSpotカスタムオブジェクトとは何か

標準オブジェクトの限界を拡張する仕組み

HubSpotには、あらかじめ用意された標準オブジェクトとして「コンタクト」「会社」「取引」「チケット」の4つがあります。これらはBtoBビジネスの基本的なデータ構造をカバーしており、多くの企業はこの4つのオブジェクトで営業・マーケティング・カスタマーサポートの主要な業務データを管理できます。

しかし、すべてのビジネスがこの4つだけで完結するわけではありません。例えば、SaaS企業が月額課金の請求データを管理したい場合、取引オブジェクトでは「1回の商談＝1つの取引」という構造になっており、月次で発生する請求レコードを表現するには不十分です。同様に、不動産業で物件情報を管理したい場合や、人材紹介業で求人案件を管理したい場合も、標準オブジェクトだけでは業務データの全体像を表現できません。

カスタムオブジェクトは、こうした「標準オブジェクトでは表現できない独自のビジネスデータ」を、HubSpot内で独立したテーブルとして作成する機能です。カスタムオブジェクトを作成すると、標準オブジェクトと同様にプロパティ（データ項目）を自由に定義でき、他のオブジェクトとの関連付け（アソシエーション）も設定できます。レポートやワークフロー、ビューのフィルターなど、HubSpotのさまざまな機能でも活用できます。

標準オブジェクトとカスタムオブジェクトの違い

カスタムオブジェクトの設計判断をする前に、標準オブジェクトとの本質的な違いを整理しておきましょう。

この違いを理解した上で押さえるべき最も重要なポイントは、カスタムオブジェクトは「できること」を増やす一方で「管理すべきこと」も増やすということです。標準オブジェクトはHubSpotが設計・最適化したものであるため、アップデートによる機能拡張の恩恵を自然に受けられます。一方、カスタムオブジェクトは自社で設計した独自のデータ構造であるため、その設計の妥当性や運用の維持はすべて自社の責任となります。

カスタムオブジェクトを「作るべきか」を判断する5つの基準

カスタムオブジェクトの設計判断において、最も重要なのは「本当にカスタムオブジェクトが必要なのか」を見極めることです。多数の導入案件から体系化した、5つの判断基準を紹介します。5つすべてに該当する必要はありませんが、少なくとも3つ以上が該当する場合にカスタムオブジェクトの作成を検討すべきです。

基準1: 独立したエンティティであるか

管理したいデータが、既存のオブジェクトの「属性」ではなく、独立した管理単位（エンティティ）として存在するかどうかが、最初の判断基準です。

例えば、「顧客の業種」は会社オブジェクトの属性（プロパティ）であり、独立したエンティティではありません。一方、「契約」は会社や取引に紐づくものの、契約開始日・契約終了日・契約金額・契約ステータスなど独自のプロパティ群を持ち、独立したライフサイクルを持ちます。これは独立したエンティティといえます。

判断のポイントは、「そのデータを削除したとき、紐づく親オブジェクトの意味が失われるか」です。プロパティであれば、その値を削除しても親レコードの本質は変わりません。しかし、独立したエンティティであれば、それ自体が意味を持つ情報の集合体です。

基準2: 1対多のレコードが発生するか

1つの親レコード（例えば1つの会社や1つの取引）に対して、同種のデータが複数レコード発生するかどうかは、カスタムオブジェクトの必要性を判断する上で重要な基準です。

プロパティは1つのレコードに対して1つの値しか持てません。例えば、1社に対して複数の契約が存在する場合、会社オブジェクトに「契約1の金額」「契約2の金額」「契約3の金額」というプロパティを並べるのは明らかに不適切です。レコード数が固定でない以上、プロパティで表現することには限界があります。

このように、1対多の関係でデータが発生する場合は、カスタムオブジェクトとして独立させ、親オブジェクトとの関連付けで管理するのが正しい設計です。

基準3: 独自のプロパティ群が必要か

管理したいデータが、5個以上の固有のプロパティを持つかどうかも判断基準になります。1つや2つのプロパティしか必要ないのであれば、親オブジェクトのプロパティとして追加すれば十分です。しかし、そのデータ固有のプロパティが5個以上ある場合、それは独立したオブジェクトとして管理すべきデータである可能性が高いといえます。

例えば、「請求」というデータには「請求日」「請求金額」「支払期日」「支払ステータス」「請求書番号」「税区分」「従量課金額」「固定費」など、取引オブジェクトのプロパティとは異質な多数の項目が必要になります。これだけのプロパティを取引オブジェクトに追加すると、取引本来の商談管理としての使いやすさが大きく損なわれます。

基準4: そのデータを軸にしたレポートが必要か

そのデータを「行」として集計・分析する必要があるかどうかも重要な基準です。HubSpotのレポート機能では、オブジェクトを軸にしたレポートを作成できますが、プロパティを軸にした集計には限界があります。

例えば、「月別の請求金額推移」「商材別のMRR内訳」「契約更新率」といったデータを軸にしたレポートが必要な場合、そのデータはカスタムオブジェクトとして独立させるべきです。プロパティのままでは、こうした集計レポートを作成することが困難になります。

基準5: 他のオブジェクトとの関連付けが必要か

管理したいデータが、複数のオブジェクトと関連付けを持つかどうかも判断のポイントです。例えば、「プロジェクト」というデータが、会社とも、コンタクトとも、取引とも関連付けが必要な場合、プロパティでは表現しきれません。

特に、多対多の関連付けが必要な場合は、カスタムオブジェクトとしての独立がほぼ必須になります。例えば、1つのプロジェクトに複数の取引が紐づき、1つの取引が複数のプロジェクトに紐づくという構造は、プロパティでは表現できません。

判断フレームワーク: 5つの基準の使い方

「作らない」と判断すべきケース｜標準オブジェクトで代替する方法

カスタムオブジェクトの判断において、「作らない」という判断は「作る」よりも重要です。安易にカスタムオブジェクトを追加すると、CRM全体の複雑性が増し、運用負荷が上がり、将来の変更コストが膨らみます。ここでは、カスタムオブジェクトを作らずに標準オブジェクトで対応すべきケースと、その具体的な方法を解説します。

ケース1: プロパティの追加で対応できる場合

管理したいデータが、既存オブジェクトの「属性」にあたるものであれば、プロパティの追加で十分です。例えば、会社の「契約ステータス」「導入済み製品」「担当営業」といった情報は、会社オブジェクトにカスタムプロパティを追加するだけで管理できます。

判断のポイントは、「そのデータは1つのレコードに対して1つの値しか持たないか」です。1対1の関係であれば、プロパティで十分対応できます。ただし、プロパティの追加であっても、項目の乱立を防ぐために命名規則の統一と利用目的の明確化は不可欠です。

ケース2: 取引パイプラインの分離で対応できる場合

「新規契約」と「アップセル」と「更新」で異なるプロセスを管理したい場合、カスタムオブジェクトを作る必要はありません。HubSpotの取引オブジェクトは複数のパイプラインを設定できるため、プロセスごとにパイプラインを分けることで対応できます。

例えば、「新規営業パイプライン」「既存顧客アップセルパイプライン」「契約更新パイプライン」を分けることで、それぞれ異なるステージ構成とプロパティ管理が可能になります。「取引の種類ごとに管理したい」という要件は、多くの場合パイプラインの分離で解決できます。

ケース3: プロパティグループの整理で対応できる場合

「取引に紐づく詳細情報が多くて管理しきれない」という課題は、プロパティグループの整理で解決できることがあります。HubSpotでは、プロパティをグループ分けして管理できるため、「商談基本情報」「見積情報」「契約条件」「導入情報」のようにグループを分けることで、見た目の整理と入力のしやすさを改善できます。

プロパティが増えること自体が問題なのではなく、整理されていないことが問題であるケースは少なくありません。カスタムオブジェクトの作成を検討する前に、まずプロパティの整理で解決できないかを考えましょう。

ケース4: 関連付けラベルで関係性を区別できる場合

HubSpotでは、オブジェクト間の関連付けに「ラベル」を設定できます。例えば、コンタクトと取引の関連付けにおいて、「意思決定者」「技術担当」「窓口担当」のようにラベルをつけることで、同じ関連付けの中で役割を区別できます。

「関係者の役割ごとに管理したい」という要件は、カスタムオブジェクトではなく関連付けラベルの活用で対応できる場合があります。ラベルを使うことで、新たなオブジェクトを追加することなく、関係性の種類を表現できます。

カスタムオブジェクト設計で失敗する5つのパターン

多数のHubSpot導入案件から見えてきた、カスタムオブジェクト設計における典型的な失敗パターンを紹介します。これらは「やってはいけない」ではなく、「やる前に知っておくべき」注意事項です。

失敗パターン1: 標準オブジェクトの機能を知らずにカスタムで作ってしまう

最も多い失敗は、HubSpotの標準機能を十分に理解しないまま、カスタムオブジェクトを作成してしまうケースです。例えば、「商品管理」のためにカスタムオブジェクトを作ったが、実はHubSpotの「商品（Products）」ライブラリと「商品項目（Line Items）」で対応できたというケースがあります。

同様に、「問い合わせの種類を分けて管理したい」ためにカスタムオブジェクトを作ったが、チケットオブジェクトの複数パイプラインで対応できたというケースも見られます。カスタムオブジェクトの検討を始める前に、HubSpotの標準機能で対応できないかを徹底的に確認することが必要です。

失敗パターン2: データ入力のオペレーションを設計しない

カスタムオブジェクトの「器」は作ったが、「誰が」「いつ」「どのように」データを入力するかのオペレーションを設計していないケースです。標準オブジェクトであれば、HubSpotのUIが入力導線を自然に誘導してくれますが、カスタムオブジェクトはそうした導線が薄くなります。

結果として、カスタムオブジェクトにデータが入力されず、空のテーブルだけが残るという事態に陥ります。カスタムオブジェクトを設計する際は、データ入力のオペレーション設計をセットで行うことが不可欠です。具体的には、入力タイミング（いつ作成するか）、入力責任者（誰が作成するか）、入力方法（手動か自動かAPI連携か）を明確にしましょう。

失敗パターン3: 関連付けの設計が不十分

カスタムオブジェクト単体の設計はしたが、他のオブジェクトとの関連付けの設計が不十分なケースです。カスタムオブジェクトの価値は、それ単体ではなく、他のオブジェクトとの関連付けによって初めて発揮されます。

例えば、「契約」カスタムオブジェクトを作ったが、会社との関連付けしか設定せず、コンタクト（契約担当者）や取引（元になった商談）との関連付けを設計しなかった場合、「この契約の商談はどれだったか」「契約の担当者は誰か」が追跡できなくなります。関連付けの設計では、対象オブジェクト・カーディナリティ（1対多か多対多か）・関連付けラベルの3つを必ず定義しましょう。

失敗パターン4: プロパティを詰め込みすぎる

カスタムオブジェクトの作成を決めた途端、「あれもこれも管理したい」とプロパティを大量に追加してしまう失敗です。これは標準オブジェクトでも発生する問題ですが、カスタムオブジェクトではさらに深刻になります。なぜなら、カスタムオブジェクトには標準オブジェクトのような「よく使われるプロパティ」のベンチマークが存在しないため、適正なプロパティ数の目安がないまま際限なく増える傾向があるからです。

カスタムオブジェクトのプロパティ設計でも、標準オブジェクトと同じ原則が適用されます。「そのプロパティは誰が、いつ、何のために入力するのか」を明確にできない項目は作らないという鉄則を守りましょう。初期リリース時は必要最小限のプロパティで開始し、運用の中で追加していくアプローチが効果的です。

失敗パターン5: 命名規則がなく識別しにくい

カスタムオブジェクトの名称やプロパティの内部名（API名）に一貫性がなく、後から見て何を管理しているオブジェクトなのか識別しにくくなるケースです。特にAPI名は作成後の変更が困難なため、作成時の命名設計が非常に重要です。

推奨する命名規則は以下の通りです。

カスタムオブジェクト設計で成功する3つのパターン

失敗パターンの裏返しとして、多数の導入案件から見えてきた成功パターンを紹介します。これらのパターンに共通するのは、「なぜカスタムオブジェクトが必要か」の理由が明確であり、運用設計がセットで行われているという点です。

成功パターン1: MRR管理のための「請求」オブジェクト

SaaS企業や定額課金ビジネスにおいて、最も導入効果が高いカスタムオブジェクトの一つが「請求」オブジェクトです。取引（Deal）オブジェクトは「1回の商談＝1つの取引」という構造であるため、月次で発生する課金データの管理には適していません。

「請求」カスタムオブジェクトを設計する背景には、取引ベースでは対応できない細かい管理要件があります。具体的には、従量課金と固定費の区分管理、商材ごとの売上分類、事業形態別（月額・年額・スポット）の請求パターンの違いなどです。

「請求」オブジェクトの設計例

「請求」オブジェクトの関連付け設計

請求オブジェクトは、以下の関連付けで他のオブジェクトと接続します。

• 請求 → 会社（多対1）：どの会社への請求か
• 請求 → 取引（多対1）：どの商談から発生した請求か
• 請求 → コンタクト（多対1）：請求先の担当者は誰か

この設計により、会社レコードから「この会社の月次MRR推移」を確認でき、取引レコードから「この商談から発生している月次請求の合計」を確認できるようになります。MRRレポートでは、請求オブジェクトを軸にして「月別MRR推移」「商材別MRR内訳」「MRR区分別の推移（New/Expansion/Contraction/Churn）」などを作成できます。

取引オブジェクトでは対応できない理由

「なぜ取引オブジェクトのプロパティで管理できないのか」という疑問に対して、明確に回答しておきます。取引オブジェクトで月次MRRを管理しようとすると、以下の問題が発生します。

• レコードの粒度が合わない：取引は「商談」単位であり、月次の請求を毎月1レコードずつ作成する運用は、取引オブジェクトの本来の用途から逸脱する
• パイプライン管理と競合する：取引にはパイプラインとステージがあり、月次請求レコードにそれを適用すると管理が破綻する
• レポートの軸が混在する：取引レポートに「新規商談」と「月次請求」が混在し、正確な営業レポートが出せなくなる
• 従量課金・固定費の区分が困難：取引の金額プロパティでは、課金の内訳を構造的に管理できない

成功パターン2: 「契約」オブジェクトによる契約ライフサイクル管理

BtoB企業で頻繁に設計されるもう一つのカスタムオブジェクトが「契約」オブジェクトです。取引（商談）と契約は密接に関連しますが、ライフサイクルが異なります。取引は「商談開始→受注/失注」で完結しますが、契約は「契約開始→運用中→更新/解約」という独自のライフサイクルを持ちます。

「契約」オブジェクトの設計ポイント

契約オブジェクトの設計で特に重要なのは、「契約更新」のワークフローとの連動です。契約終了日の一定期間前（例: 90日前）にワークフローを起動し、更新の案内やカスタマーサクセスへのタスク割り当てを自動化することで、契約管理の実効性が大幅に高まります。

成功パターン3: 「プロジェクト」オブジェクトによる納品管理

コンサルティング会社やSI企業など、受注後に「プロジェクト」として納品・実行フェーズがある業種では、「プロジェクト」カスタムオブジェクトが効果的です。

取引オブジェクトの受注ステージ以降に「納品中」「検収済」などのステージを追加する方法もありますが、プロジェクトの管理情報（進捗率、マイルストーン、アサインメンバー、工数実績など）が多い場合は、取引とは別に管理すべきデータ構造です。

プロジェクトオブジェクトの関連付け

• プロジェクト → 取引（多対1または多対多）：どの商談から発生したプロジェクトか
• プロジェクト → 会社（多対1）：どの会社のプロジェクトか
• プロジェクト → コンタクト（多対多）：プロジェクトの関係者は誰か

この設計のポイントは、営業プロセス（取引）と納品プロセス（プロジェクト）を分離しつつ、関連付けで接続している点です。これにより、「この商談は受注後にどうなったか」を取引から追跡でき、「このプロジェクトはどの商談から来たか」をプロジェクトから逆引きできます。

カスタムオブジェクト設計の実践ステップ

カスタムオブジェクトの作成を決めた後の、具体的な設計ステップを解説します。

ステップ1: 要件定義

最初に行うべきは、カスタムオブジェクトで「何を」「なぜ」管理するかの要件定義です。以下の項目を明確にしましょう。

• 管理対象：何を表すオブジェクトか（請求、契約、プロジェクトなど）
• 業務上の目的：このオブジェクトがあることで、どの業務課題が解決されるか
• データの発生タイミング：レコードはいつ作成されるか（受注時、月次、問い合わせ時など）
• 想定レコード数：月間・年間でどの程度のレコードが発生するか
• 利用者：このオブジェクトのデータを閲覧・入力・活用するのは誰か
• レポート要件：このオブジェクトを軸にどのようなレポートを作成したいか

ステップ2: データモデルの設計

要件定義に基づき、具体的なデータモデルを設計します。ここでは3つの要素を決定します。

（1）プロパティ設計

必要なプロパティを洗い出し、各プロパティのフィールドタイプ、必須/任意の区分、デフォルト値を決定します。前述の通り、初期リリース時は必要最小限のプロパティに絞ることが重要です。目安として、初期プロパティは10個以内に収めることを推奨します。

（2）関連付け設計

他のオブジェクトとの関連付けを設計します。各関連付けについて、対象オブジェクト、カーディナリティ（1対多 or 多対多）、関連付けラベル（必要な場合）を定義します。

（3）表示名とAPI名の決定

オブジェクト名、プロパティ名のそれぞれについて、表示名（日本語）とAPI名（英語）を決定します。前述の命名規則に従い、一貫性のある命名にしましょう。

ステップ3: オペレーション設計

カスタムオブジェクトの設計で見落とされがちなのが、オペレーション（運用）の設計です。以下の項目を明確にしましょう。

ステップ4: テストと検証

設計が完了したら、本番環境に適用する前に十分なテストを行います。テストのポイントは以下の通りです。

• レコード作成テスト：想定した方法でレコードを正しく作成できるか
• 関連付けテスト：他のオブジェクトとの関連付けが正しく機能するか
• レポートテスト：要件で定義したレポートを実際に作成できるか
• ワークフローテスト：自動化ルールが正しく動作するか
• 権限テスト：各ユーザーロールで適切なアクセス制御が行われるか

特に重要なのはレポートテストです。カスタムオブジェクトを作成した目的の多くはレポーティングにあるため、想定したレポートが実際に作成可能かを必ず確認しましょう。レポートのデータソースとしてカスタムオブジェクトを選択し、必要なプロパティでフィルタリング・グルーピング・集計ができることを検証します。

ステップ5: 段階的な展開

テストが完了したら、段階的に展開します。一度にすべてのユーザーに展開するのではなく、パイロットチームで先行運用し、フィードバックを収集してから全体展開する方法が効果的です。

• フェーズ1：パイロットチーム（2〜3名）で1〜2週間運用し、入力のしやすさ・データの正確性・レポートの有用性を検証
• フェーズ2：パイロットのフィードバックを反映し、プロパティの追加・修正・削除を実施
• フェーズ3：全ユーザーに展開し、マニュアルやトレーニングを提供

カスタムオブジェクト導入後の運用と保守

定期的な棚卸し

カスタムオブジェクトは、作成して終わりではありません。定期的な棚卸しによって、設計の妥当性と運用の健全性を維持する必要があります。四半期に一度を目安に、以下の項目を確認しましょう。

• レコード数の推移：想定通りにレコードが蓄積されているか。極端に少ない場合は入力オペレーションに問題がある可能性がある
• プロパティの入力率：各プロパティの入力率を確認し、入力率の低い項目（20%以下）は必要性を再検討する
• レポートの活用状況：カスタムオブジェクトを使ったレポートが実際に活用されているか。活用されていないレポートの存在は、設計の見直しサインである
• 関連付けの整合性：関連付けが正しく設定されているレコードの割合を確認する。未関連付けレコードが多い場合はデータの信頼性が下がる

プロパティの追加と削除のルール

運用を進める中で、プロパティの追加要望が出てくるのは自然なことです。しかし、無秩序な追加はプロパティの乱立を招きます。以下のルールを設けることを推奨します。

• 追加申請制：新しいプロパティの追加は申請制にし、管理者が承認する
• 利用目的の明記：「誰が」「いつ」「何のために」入力するかを明記させる
• 試用期間の設定：新規プロパティには3ヶ月の試用期間を設け、期間終了時に入力率と活用状況を評価する
• 削除の基準：入力率20%以下が3ヶ月以上続く場合、削除候補とする

外部システムとの連携

カスタムオブジェクトのデータは、外部システムとの連携によってさらに価値が高まります。例えば、会計ソフトとの連携で請求データを自動同期したり、プロジェクト管理ツールとの連携でプロジェクトの進捗を自動更新したりすることが可能です。

外部連携を設計する際の注意点は以下の通りです。

• データの方向：HubSpot → 外部、外部 → HubSpot、双方向のいずれかを明確にする
• 同期頻度：リアルタイム、定期バッチ（毎時・毎日）、手動のいずれかを決める
• 一意キーの整合：外部システムとHubSpotで共通のキー項目（契約番号、請求番号など）を定義し、レコードの突合に使用する
• エラーハンドリング：同期エラーが発生した場合の検知方法とリカバリ手順を定めておく

カスタムオブジェクトとデータベース設計全体の関係

S-1で解説した設計原則との接続

CRMデータベース設計の基本で解説した5つの設計原則は、カスタムオブジェクトの設計にもそのまま適用されます。ここでは、各原則がカスタムオブジェクト設計においてどのように具体化されるかを整理します。

カスタムオブジェクトの追加がCRM全体に与える影響

カスタムオブジェクトを追加すると、CRM全体のデータ構造が複雑になります。この複雑性を管理するために、データモデル図（ER図）を作成し、すべてのオブジェクトとその関連付けを可視化しておくことを推奨します。

データモデル図には以下の情報を含めます。

• すべてのオブジェクト（標準 + カスタム）とその役割の概要
• オブジェクト間の関連付けとカーディナリティ（1対多、多対多）
• 各オブジェクトの主要プロパティ（すべてではなく、設計上重要なもの）
• データの流れ（どのオブジェクトからどのオブジェクトにデータが流れるか）

このデータモデル図は、新しいメンバーへのオンボーディング、設計変更時の影響範囲の把握、外部システム連携の設計時に非常に役立ちます。

カスタムオブジェクトとAI活用の関係

CRMにおけるAI活用が加速する中、カスタムオブジェクトのデータもAIの学習・推論対象になります。例えば、請求データを使った解約予測、契約データを使った更新確率の予測、プロジェクトデータを使ったリソース最適化などが可能になります。

AIが効果的に機能するためには、カスタムオブジェクトのデータ品質が高い必要があります。具体的には、以下の条件を満たすことが求められます。

• データの網羅性：関連するレコードが漏れなく作成されていること
• データの正確性：プロパティの値が正確に入力されていること
• 関連付けの完全性：他のオブジェクトとの関連付けが正しく設定されていること
• 時系列データの蓄積：経時変化を追跡できるデータが蓄積されていること

カスタムオブジェクトの設計段階で、将来のAI活用を見据えたデータ構造にしておくことで、AI活用の準備が整います。具体的には、構造化されたフィールドタイプ（ドロップダウン、数値、日付）を選択すること、時系列データが蓄積される設計にすること、関連付けを通じたデータの横断的な分析が可能な構造にすることが重要です。

まとめ

HubSpotカスタムオブジェクトの設計判断は、CRMの設計品質を大きく左右する重要な意思決定です。本記事で解説した内容を整理すると、以下のポイントに集約されます。

1. 判断フレームワーク：5つの基準（独立したエンティティか、1対多のレコードが発生するか、独自のプロパティ群が必要か、レポート対象か、他オブジェクトとの関連付けが必要か）で、カスタムオブジェクトの必要性を判断する
2. 「作らない」判断の重要性：プロパティの追加、パイプラインの分離、プロパティグループの整理、関連付けラベルの活用で代替できないかを先に検討する
3. 失敗パターンの回避：標準機能の確認不足、オペレーション設計の欠如、関連付け設計の不備、プロパティの詰め込みすぎ、命名規則の不在を避ける
4. 成功パターンの適用：MRR管理の「請求」、契約ライフサイクル管理の「契約」、納品管理の「プロジェクト」など、業務要件に合致したカスタムオブジェクトを適切に設計する
5. 運用設計をセットで行う：データ入力のオペレーション、定期的な棚卸し、プロパティの追加・削除ルールを事前に定めておく

カスタムオブジェクトは、HubSpotのデータ構造を自社の業務に最適化するための強力な手段です。しかし、その力を正しく発揮させるためには、「なぜ作るのか」の判断と「どう運用するのか」の設計を、作成前に丁寧に行うことが不可欠です。本記事の判断フレームワークと設計パターンを活用し、自社に最適なカスタムオブジェクト設計を実現してください。

よくある質問（FAQ）

Q. カスタムオブジェクトはHubSpotのどのプランで利用できますか？

A. カスタムオブジェクトは、HubSpotのEnterprise プランで利用可能です。Professional プラン以下ではカスタムオブジェクトを作成できないため、Enterprise プランへのアップグレードが必要になります。なお、作成可能なカスタムオブジェクトの数はプランや契約内容によって異なりますので、事前にHubSpotの仕様を確認しましょう。カスタムオブジェクトが必要な業務要件がある場合は、プラン選定の段階で考慮に入れることが重要です。

Q. 一度作成したカスタムオブジェクトを削除することはできますか？

A. HubSpotではカスタムオブジェクトの削除は可能ですが、削除するとそのオブジェクトに紐づくすべてのレコード、プロパティ、関連付け、ワークフロー、レポートも影響を受けます。削除は慎重に行う必要があり、事前にデータのバックアップを取ることを推奨します。また、削除ではなく「使わないオブジェクトを非活性化する」という運用上の対処で済む場合もありますので、まずは非活性化を検討しましょう。設計段階で「本当に必要か」を慎重に判断することが、こうした事態を防ぐ最善策です。

Q. カスタムオブジェクトとカスタムプロパティの使い分けがわかりません。判断のポイントは？

A. 最もシンプルな判断基準は「1対多のデータが発生するかどうか」です。1つの親レコードに対してデータが1つしか存在しない場合（例：会社の「契約ステータス」）はカスタムプロパティで十分です。一方、1つの親レコードに対して同種のデータが複数発生する場合（例：1つの会社に複数の「契約」）はカスタムオブジェクトが適切です。迷った場合は、本記事で紹介した5つの判断基準に照らし合わせて検討してください。3つ以上該当すればカスタムオブジェクト、2つ以下であればカスタムプロパティで対応するのが目安です。

Q. カスタムオブジェクトのレコード数に上限はありますか？

A. HubSpotのカスタムオブジェクトには、契約プランに応じたレコード数の上限があります。大量のトランザクションデータ（例：日次の利用ログ、アクセス履歴など）をカスタムオブジェクトに格納する場合は、レコード数の上限に達する可能性があるため注意が必要です。大量データの管理が必要な場合は、HubSpot外のデータウェアハウスやBIツールとの連携を検討し、HubSpotには集約・サマリーレベルのデータのみを格納する設計が効果的です。「すべてのデータをHubSpotに入れる」のではなく、「CRMとして必要なデータをHubSpotに入れる」という考え方が重要です。

Q. APIを使わずにカスタムオブジェクトのレコードを一括登録する方法はありますか？

A. HubSpotでは、CSVファイルによるインポート機能を使ってカスタムオブジェクトのレコードを一括登録できます。インポート時には、オブジェクトの一意キー（表示名プロパティなど）を指定し、関連付けを設定することも可能です。ただし、関連付けの設定にはインポートファイルの構成を適切に設計する必要があります。具体的には、カスタムオブジェクトのデータと、関連付け先のオブジェクトの一意キー（会社のドメインやコンタクトのメールアドレスなど）を同じファイルに含める形式が一般的です。大量データの初期投入時には、インポート前にテスト用の少量データで動作確認を行うことを推奨します。

関連記事

• CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けの設計思想（データベース設計の3つの構成要素と5つの設計原則はこちら）
• CRMデータクレンジング実践ガイド｜データ品質を維持する方法（カスタムオブジェクトのデータ品質維持にも役立つ実践手法はこちら）
• パイプライン設計ガイド｜ステージ設計と運用の最適化（取引パイプラインの分離による代替手法の詳細はこちら）