「標準オブジェクトのプロパティに無理やり詰め込んだ結果、取引レコードが100以上の項目で肥大化してしまった」「カスタムオブジェクトを作ったはいいが、誰も使っていない」「どこまでを標準で対応し、どこからカスタムオブジェクトを作るべきか判断がつかない」
HubSpotの導入支援を重ねる中で、カスタムオブジェクトに関するこうした相談を頻繁に受けます。そして、その多くに共通するのは、「作るべきか・作らないべきか」の判断基準が曖昧なまま設計を進めてしまったという問題です。
カスタムオブジェクトはHubSpotの柔軟性を大幅に高める強力な機能ですが、安易に追加すればCRM全体の複雑性が増し、運用コストが跳ね上がります。逆に、必要な場面でカスタムオブジェクトを使わず、標準オブジェクトに情報を詰め込み続ければ、データ構造が破綻します。
本記事では、多数のHubSpot導入案件から体系化したカスタムオブジェクトの設計判断フレームワークを提供します。「いつ作るべきか」「いつ作らないべきか」の判断基準、設計パターン、そして実務で遭遇する典型的な失敗パターンと成功パターンを具体的に解説します。CRMデータベース設計の基本については前回の記事で解説していますので、あわせてご参照ください。
HubSpotには、あらかじめ用意された標準オブジェクトとして「コンタクト」「会社」「取引」「チケット」の4つがあります。これらはBtoBビジネスの基本的なデータ構造をカバーしており、多くの企業はこの4つのオブジェクトで営業・マーケティング・カスタマーサポートの主要な業務データを管理できます。
しかし、すべてのビジネスがこの4つだけで完結するわけではありません。例えば、SaaS企業が月額課金の請求データを管理したい場合、取引オブジェクトでは「1回の商談＝1つの取引」という構造になっており、月次で発生する請求レコードを表現するには不十分です。同様に、不動産業で物件情報を管理したい場合や、人材紹介業で求人案件を管理したい場合も、標準オブジェクトだけでは業務データの全体像を表現できません。
カスタムオブジェクトは、こうした「標準オブジェクトでは表現できない独自のビジネスデータ」を、HubSpot内で独立したテーブルとして作成する機能です。カスタムオブジェクトを作成すると、標準オブジェクトと同様にプロパティ（データ項目）を自由に定義でき、他のオブジェクトとの関連付け（アソシエーション）も設定できます。レポートやワークフロー、ビューのフィルターなど、HubSpotのさまざまな機能でも活用できます。
カスタムオブジェクトの設計判断をする前に、標準オブジェクトとの本質的な違いを整理しておきましょう。
| 比較項目 | 標準オブジェクト | カスタムオブジェクト |
|---|---|---|
| 定義 | HubSpotに初期搭載されたテーブル | ユーザーが独自に作成するテーブル |
| HubSpot機能との連携 | すべての機能（ワークフロー、レポート、リスト、シーケンスなど）と完全連携 | 主要機能との連携は可能だが、一部機能に制約がある場合がある |
| プラン要件 | すべてのプランで利用可能 | Enterprise プランが必要 |
| 作成上限 | 変更不可（追加・削除できない） | プランに応じた上限あり |
| 設計自由度 | プロパティの追加は自由だが、オブジェクト自体の構造は固定 | オブジェクト名・構造・プロパティすべてを自由に定義できる |
| 運用負荷 | HubSpotのベストプラクティスに沿った運用が可能 | 設計・運用・保守すべてを自社で管理する必要がある |
この違いを理解した上で押さえるべき最も重要なポイントは、カスタムオブジェクトは「できること」を増やす一方で「管理すべきこと」も増やすということです。標準オブジェクトはHubSpotが設計・最適化したものであるため、アップデートによる機能拡張の恩恵を自然に受けられます。一方、カスタムオブジェクトは自社で設計した独自のデータ構造であるため、その設計の妥当性や運用の維持はすべて自社の責任となります。
カスタムオブジェクトの設計判断において、最も重要なのは「本当にカスタムオブジェクトが必要なのか」を見極めることです。多数の導入案件から体系化した、5つの判断基準を紹介します。5つすべてに該当する必要はありませんが、少なくとも3つ以上が該当する場合にカスタムオブジェクトの作成を検討すべきです。
管理したいデータが、既存のオブジェクトの「属性」ではなく、独立した管理単位（エンティティ）として存在するかどうかが、最初の判断基準です。
例えば、「顧客の業種」は会社オブジェクトの属性（プロパティ）であり、独立したエンティティではありません。一方、「契約」は会社や取引に紐づくものの、契約開始日・契約終了日・契約金額・契約ステータスなど独自のプロパティ群を持ち、独立したライフサイクルを持ちます。これは独立したエンティティといえます。
判断のポイントは、「そのデータを削除したとき、紐づく親オブジェクトの意味が失われるか」です。プロパティであれば、その値を削除しても親レコードの本質は変わりません。しかし、独立したエンティティであれば、それ自体が意味を持つ情報の集合体です。
1つの親レコード（例えば1つの会社や1つの取引）に対して、同種のデータが複数レコード発生するかどうかは、カスタムオブジェクトの必要性を判断する上で重要な基準です。
プロパティは1つのレコードに対して1つの値しか持てません。例えば、1社に対して複数の契約が存在する場合、会社オブジェクトに「契約1の金額」「契約2の金額」「契約3の金額」というプロパティを並べるのは明らかに不適切です。レコード数が固定でない以上、プロパティで表現することには限界があります。
このように、1対多の関係でデータが発生する場合は、カスタムオブジェクトとして独立させ、親オブジェクトとの関連付けで管理するのが正しい設計です。
管理したいデータが、5個以上の固有のプロパティを持つかどうかも判断基準になります。1つや2つのプロパティしか必要ないのであれば、親オブジェクトのプロパティとして追加すれば十分です。しかし、そのデータ固有のプロパティが5個以上ある場合、それは独立したオブジェクトとして管理すべきデータである可能性が高いといえます。
例えば、「請求」というデータには「請求日」「請求金額」「支払期日」「支払ステータス」「請求書番号」「税区分」「従量課金額」「固定費」など、取引オブジェクトのプロパティとは異質な多数の項目が必要になります。これだけのプロパティを取引オブジェクトに追加すると、取引本来の商談管理としての使いやすさが大きく損なわれます。
そのデータを「行」として集計・分析する必要があるかどうかも重要な基準です。HubSpotのレポート機能では、オブジェクトを軸にしたレポートを作成できますが、プロパティを軸にした集計には限界があります。
例えば、「月別の請求金額推移」「商材別のMRR内訳」「契約更新率」といったデータを軸にしたレポートが必要な場合、そのデータはカスタムオブジェクトとして独立させるべきです。プロパティのままでは、こうした集計レポートを作成することが困難になります。
管理したいデータが、複数のオブジェクトと関連付けを持つかどうかも判断のポイントです。例えば、「プロジェクト」というデータが、会社とも、コンタクトとも、取引とも関連付けが必要な場合、プロパティでは表現しきれません。
特に、多対多の関連付けが必要な場合は、カスタムオブジェクトとしての独立がほぼ必須になります。例えば、1つのプロジェクトに複数の取引が紐づき、1つの取引が複数のプロジェクトに紐づくという構造は、プロパティでは表現できません。
| 該当する基準の数 | 推奨判断 | 具体的なアクション |
|---|---|---|
| 0〜1個 | 作らない | 標準オブジェクトのプロパティで対応する |
| 2個 | 慎重に検討 | 代替案（プロパティの工夫、取引パイプラインの分離など）を先に検討する |
| 3〜4個 | 作成を推奨 | カスタムオブジェクトの設計に着手する |
| 5個すべて | 作成がほぼ必須 | カスタムオブジェクトなしでは業務要件を満たせない |
カスタムオブジェクトの判断において、「作らない」という判断は「作る」よりも重要です。安易にカスタムオブジェクトを追加すると、CRM全体の複雑性が増し、運用負荷が上がり、将来の変更コストが膨らみます。ここでは、カスタムオブジェクトを作らずに標準オブジェクトで対応すべきケースと、その具体的な方法を解説します。
管理したいデータが、既存オブジェクトの「属性」にあたるものであれば、プロパティの追加で十分です。例えば、会社の「契約ステータス」「導入済み製品」「担当営業」といった情報は、会社オブジェクトにカスタムプロパティを追加するだけで管理できます。
判断のポイントは、「そのデータは1つのレコードに対して1つの値しか持たないか」です。1対1の関係であれば、プロパティで十分対応できます。ただし、プロパティの追加であっても、項目の乱立を防ぐために命名規則の統一と利用目的の明確化は不可欠です。
「新規契約」と「アップセル」と「更新」で異なるプロセスを管理したい場合、カスタムオブジェクトを作る必要はありません。HubSpotの取引オブジェクトは複数のパイプラインを設定できるため、プロセスごとにパイプラインを分けることで対応できます。
例えば、「新規営業パイプライン」「既存顧客アップセルパイプライン」「契約更新パイプライン」を分けることで、それぞれ異なるステージ構成とプロパティ管理が可能になります。「取引の種類ごとに管理したい」という要件は、多くの場合パイプラインの分離で解決できます。
「取引に紐づく詳細情報が多くて管理しきれない」という課題は、プロパティグループの整理で解決できることがあります。HubSpotでは、プロパティをグループ分けして管理できるため、「商談基本情報」「見積情報」「契約条件」「導入情報」のようにグループを分けることで、見た目の整理と入力のしやすさを改善できます。
プロパティが増えること自体が問題なのではなく、整理されていないことが問題であるケースは少なくありません。カスタムオブジェクトの作成を検討する前に、まずプロパティの整理で解決できないかを考えましょう。
HubSpotでは、オブジェクト間の関連付けに「ラベル」を設定できます。例えば、コンタクトと取引の関連付けにおいて、「意思決定者」「技術担当」「窓口担当」のようにラベルをつけることで、同じ関連付けの中で役割を区別できます。
「関係者の役割ごとに管理したい」という要件は、カスタムオブジェクトではなく関連付けラベルの活用で対応できる場合があります。ラベルを使うことで、新たなオブジェクトを追加することなく、関係性の種類を表現できます。
多数のHubSpot導入案件から見えてきた、カスタムオブジェクト設計における典型的な失敗パターンを紹介します。これらは「やってはいけない」ではなく、「やる前に知っておくべき」注意事項です。
最も多い失敗は、HubSpotの標準機能を十分に理解しないまま、カスタムオブジェクトを作成してしまうケースです。例えば、「商品管理」のためにカスタムオブジェクトを作ったが、実はHubSpotの「商品（Products）」ライブラリと「商品項目（Line Items）」で対応できたというケースがあります。
同様に、「問い合わせの種類を分けて管理したい」ためにカスタムオブジェクトを作ったが、チケットオブジェクトの複数パイプラインで対応できたというケースも見られます。カスタムオブジェクトの検討を始める前に、HubSpotの標準機能で対応できないかを徹底的に確認することが必要です。
カスタムオブジェクトの「器」は作ったが、「誰が」「いつ」「どのように」データを入力するかのオペレーションを設計していないケースです。標準オブジェクトであれば、HubSpotのUIが入力導線を自然に誘導してくれますが、カスタムオブジェクトはそうした導線が薄くなります。
結果として、カスタムオブジェクトにデータが入力されず、空のテーブルだけが残るという事態に陥ります。カスタムオブジェクトを設計する際は、データ入力のオペレーション設計をセットで行うことが不可欠です。具体的には、入力タイミング（いつ作成するか）、入力責任者（誰が作成するか）、入力方法（手動か自動かAPI連携か）を明確にしましょう。
カスタムオブジェクト単体の設計はしたが、他のオブジェクトとの関連付けの設計が不十分なケースです。カスタムオブジェクトの価値は、それ単体ではなく、他のオブジェクトとの関連付けによって初めて発揮されます。
例えば、「契約」カスタムオブジェクトを作ったが、会社との関連付けしか設定せず、コンタクト（契約担当者）や取引（元になった商談）との関連付けを設計しなかった場合、「この契約の商談はどれだったか」「契約の担当者は誰か」が追跡できなくなります。関連付けの設計では、対象オブジェクト・カーディナリティ（1対多か多対多か）・関連付けラベルの3つを必ず定義しましょう。
カスタムオブジェクトの作成を決めた途端、「あれもこれも管理したい」とプロパティを大量に追加してしまう失敗です。これは標準オブジェクトでも発生する問題ですが、カスタムオブジェクトではさらに深刻になります。なぜなら、カスタムオブジェクトには標準オブジェクトのような「よく使われるプロパティ」のベンチマークが存在しないため、適正なプロパティ数の目安がないまま際限なく増える傾向があるからです。
カスタムオブジェクトのプロパティ設計でも、標準オブジェクトと同じ原則が適用されます。「そのプロパティは誰が、いつ、何のために入力するのか」を明確にできない項目は作らないという鉄則を守りましょう。初期リリース時は必要最小限のプロパティで開始し、運用の中で追加していくアプローチが効果的です。
カスタムオブジェクトの名称やプロパティの内部名（API名）に一貫性がなく、後から見て何を管理しているオブジェクトなのか識別しにくくなるケースです。特にAPI名は作成後の変更が困難なため、作成時の命名設計が非常に重要です。
推奨する命名規則は以下の通りです。
| 対象 | 命名規則 | 例 |
|---|---|---|
| オブジェクト名（表示名） | 日本語で業務上の名称を使う | 請求、契約、プロジェクト |
| オブジェクトAPI名 | 英語スネークケース、プレフィックスで自社を識別 | sl_billing, sl_contract, sl_project |
| プロパティ名（表示名） | 日本語でわかりやすい名称 | 請求金額、支払ステータス |
| プロパティ内部名 | 英語スネークケース、オブジェクト名をプレフィックス | billing_amount, billing_payment_status |
失敗パターンの裏返しとして、多数の導入案件から見えてきた成功パターンを紹介します。これらのパターンに共通するのは、「なぜカスタムオブジェクトが必要か」の理由が明確であり、運用設計がセットで行われているという点です。
SaaS企業や定額課金ビジネスにおいて、最も導入効果が高いカスタムオブジェクトの一つが「請求」オブジェクトです。取引（Deal）オブジェクトは「1回の商談＝1つの取引」という構造であるため、月次で発生する課金データの管理には適していません。
「請求」カスタムオブジェクトを設計する背景には、取引ベースでは対応できない細かい管理要件があります。具体的には、従量課金と固定費の区分管理、商材ごとの売上分類、事業形態別（月額・年額・スポット）の請求パターンの違いなどです。
| プロパティ名 | フィールドタイプ | 説明 |
|---|---|---|
| 請求年月 | 日付 | 対象月（例: 2026-01） |
| 請求金額（税抜） | 数値（通貨） | 当月の請求金額 |
| 固定費 | 数値（通貨） | 月額固定料金の部分 |
| 従量課金額 | 数値（通貨） | 使用量に応じた変動料金 |
| 商材分類 | ドロップダウン | 売上を分類するカテゴリ |
| 事業形態 | ドロップダウン | 月額 / 年額 / スポット |
| 支払ステータス | ドロップダウン | 未請求 / 請求済 / 入金済 |
| MRR区分 | ドロップダウン | New / Expansion / Contraction / Churn |
請求オブジェクトは、以下の関連付けで他のオブジェクトと接続します。
この設計により、会社レコードから「この会社の月次MRR推移」を確認でき、取引レコードから「この商談から発生している月次請求の合計」を確認できるようになります。MRRレポートでは、請求オブジェクトを軸にして「月別MRR推移」「商材別MRR内訳」「MRR区分別の推移（New/Expansion/Contraction/Churn）」などを作成できます。
「なぜ取引オブジェクトのプロパティで管理できないのか」という疑問に対して、明確に回答しておきます。取引オブジェクトで月次MRRを管理しようとすると、以下の問題が発生します。
BtoB企業で頻繁に設計されるもう一つのカスタムオブジェクトが「契約」オブジェクトです。取引（商談）と契約は密接に関連しますが、ライフサイクルが異なります。取引は「商談開始→受注/失注」で完結しますが、契約は「契約開始→運用中→更新/解約」という独自のライフサイクルを持ちます。
| プロパティ名 | フィールドタイプ | 説明 |
|---|---|---|
| 契約番号 | テキスト（単行） | 一意の契約識別番号 |
| 契約開始日 | 日付 | 契約の有効開始日 |
| 契約終了日 | 日付 | 契約の有効終了日 |
| 契約金額 | 数値（通貨） | 契約の総額 |
| 契約ステータス | ドロップダウン | 準備中 / 有効 / 更新待ち / 解約済 |
| 自動更新 | チェックボックス | 自動更新契約かどうか |
| 契約種別 | ドロップダウン | 新規 / 更新 / アップグレード |
契約オブジェクトの設計で特に重要なのは、「契約更新」のワークフローとの連動です。契約終了日の一定期間前（例: 90日前）にワークフローを起動し、更新の案内やカスタマーサクセスへのタスク割り当てを自動化することで、契約管理の実効性が大幅に高まります。
コンサルティング会社やSI企業など、受注後に「プロジェクト」として納品・実行フェーズがある業種では、「プロジェクト」カスタムオブジェクトが効果的です。
取引オブジェクトの受注ステージ以降に「納品中」「検収済」などのステージを追加する方法もありますが、プロジェクトの管理情報（進捗率、マイルストーン、アサインメンバー、工数実績など）が多い場合は、取引とは別に管理すべきデータ構造です。
この設計のポイントは、営業プロセス（取引）と納品プロセス（プロジェクト）を分離しつつ、関連付けで接続している点です。これにより、「この商談は受注後にどうなったか」を取引から追跡でき、「このプロジェクトはどの商談から来たか」をプロジェクトから逆引きできます。
カスタムオブジェクトの作成を決めた後の、具体的な設計ステップを解説します。
最初に行うべきは、カスタムオブジェクトで「何を」「なぜ」管理するかの要件定義です。以下の項目を明確にしましょう。
要件定義に基づき、具体的なデータモデルを設計します。ここでは3つの要素を決定します。
（1）プロパティ設計
必要なプロパティを洗い出し、各プロパティのフィールドタイプ、必須/任意の区分、デフォルト値を決定します。前述の通り、初期リリース時は必要最小限のプロパティに絞ることが重要です。目安として、初期プロパティは10個以内に収めることを推奨します。
（2）関連付け設計
他のオブジェクトとの関連付けを設計します。各関連付けについて、対象オブジェクト、カーディナリティ（1対多 or 多対多）、関連付けラベル（必要な場合）を定義します。
（3）表示名とAPI名の決定
オブジェクト名、プロパティ名のそれぞれについて、表示名（日本語）とAPI名（英語）を決定します。前述の命名規則に従い、一貫性のある命名にしましょう。
カスタムオブジェクトの設計で見落とされがちなのが、オペレーション（運用）の設計です。以下の項目を明確にしましょう。
| 設計項目 | 検討内容 | 具体例 |
|---|---|---|
| レコード作成方法 | 手動作成 / ワークフロー自動作成 / API連携 / インポート | 取引が受注クローズしたら、契約レコードを自動作成 |
| 入力責任者 | 誰がどのプロパティを入力するか | 基本情報は営業、実績データは経理 |
| 更新タイミング | どのタイミングでデータを更新するか | 請求レコードは毎月月初に作成 |
| 自動化ルール | ワークフローで自動化すべき処理は何か | 契約終了90日前に更新タスクを自動作成 |
| 権限設計 | 誰が閲覧・編集・削除できるか | 請求データは経理と管理者のみ編集可 |
設計が完了したら、本番環境に適用する前に十分なテストを行います。テストのポイントは以下の通りです。
特に重要なのはレポートテストです。カスタムオブジェクトを作成した目的の多くはレポーティングにあるため、想定したレポートが実際に作成可能かを必ず確認しましょう。レポートのデータソースとしてカスタムオブジェクトを選択し、必要なプロパティでフィルタリング・グルーピング・集計ができることを検証します。
テストが完了したら、段階的に展開します。一度にすべてのユーザーに展開するのではなく、パイロットチームで先行運用し、フィードバックを収集してから全体展開する方法が効果的です。
カスタムオブジェクトは、作成して終わりではありません。定期的な棚卸しによって、設計の妥当性と運用の健全性を維持する必要があります。四半期に一度を目安に、以下の項目を確認しましょう。
運用を進める中で、プロパティの追加要望が出てくるのは自然なことです。しかし、無秩序な追加はプロパティの乱立を招きます。以下のルールを設けることを推奨します。
カスタムオブジェクトのデータは、外部システムとの連携によってさらに価値が高まります。例えば、会計ソフトとの連携で請求データを自動同期したり、プロジェクト管理ツールとの連携でプロジェクトの進捗を自動更新したりすることが可能です。
外部連携を設計する際の注意点は以下の通りです。
CRMデータベース設計の基本で解説した5つの設計原則は、カスタムオブジェクトの設計にもそのまま適用されます。ここでは、各原則がカスタムオブジェクト設計においてどのように具体化されるかを整理します。
| 設計原則 | カスタムオブジェクト設計への適用 |
|---|---|
| 原則1: ビジネスプロセスから逆算する | カスタムオブジェクトが対応する業務プロセスを明確にし、そのプロセスの各ステップで必要なデータを特定する |
| 原則2: レポートで見たいKPIから設計する | カスタムオブジェクトを軸にしたレポート要件を先に定義し、そこから必要なプロパティと関連付けを逆算する |
| 原則3: 入力負荷を最小化する | カスタムオブジェクトの入力オペレーションを設計し、可能な限り自動化する。手動入力のプロパティは最小限に絞る |
| 原則4: データの一意性を保つ | カスタムオブジェクトにも一意キー（契約番号、請求番号など）を設定し、重複レコードの発生を防止する |
| 原則5: 拡張性を考慮する | 将来のプロパティ追加や関連付けの変更を見越した設計にする。命名規則を拡張に耐えるものにする |
カスタムオブジェクトを追加すると、CRM全体のデータ構造が複雑になります。この複雑性を管理するために、データモデル図（ER図）を作成し、すべてのオブジェクトとその関連付けを可視化しておくことを推奨します。
データモデル図には以下の情報を含めます。
このデータモデル図は、新しいメンバーへのオンボーディング、設計変更時の影響範囲の把握、外部システム連携の設計時に非常に役立ちます。
CRMにおけるAI活用が加速する中、カスタムオブジェクトのデータもAIの学習・推論対象になります。例えば、請求データを使った解約予測、契約データを使った更新確率の予測、プロジェクトデータを使ったリソース最適化などが可能になります。
AIが効果的に機能するためには、カスタムオブジェクトのデータ品質が高い必要があります。具体的には、以下の条件を満たすことが求められます。
カスタムオブジェクトの設計段階で、将来のAI活用を見据えたデータ構造にしておくことで、AI活用の準備が整います。具体的には、構造化されたフィールドタイプ（ドロップダウン、数値、日付）を選択すること、時系列データが蓄積される設計にすること、関連付けを通じたデータの横断的な分析が可能な構造にすることが重要です。
HubSpotカスタムオブジェクトの設計判断は、CRMの設計品質を大きく左右する重要な意思決定です。本記事で解説した内容を整理すると、以下のポイントに集約されます。
カスタムオブジェクトは、HubSpotのデータ構造を自社の業務に最適化するための強力な手段です。しかし、その力を正しく発揮させるためには、「なぜ作るのか」の判断と「どう運用するのか」の設計を、作成前に丁寧に行うことが不可欠です。本記事の判断フレームワークと設計パターンを活用し、自社に最適なカスタムオブジェクト設計を実現してください。
A. カスタムオブジェクトは、HubSpotのEnterprise プランで利用可能です。Professional プラン以下ではカスタムオブジェクトを作成できないため、Enterprise プランへのアップグレードが必要になります。なお、作成可能なカスタムオブジェクトの数はプランや契約内容によって異なりますので、事前にHubSpotの仕様を確認しましょう。カスタムオブジェクトが必要な業務要件がある場合は、プラン選定の段階で考慮に入れることが重要です。
A. HubSpotではカスタムオブジェクトの削除は可能ですが、削除するとそのオブジェクトに紐づくすべてのレコード、プロパティ、関連付け、ワークフロー、レポートも影響を受けます。削除は慎重に行う必要があり、事前にデータのバックアップを取ることを推奨します。また、削除ではなく「使わないオブジェクトを非活性化する」という運用上の対処で済む場合もありますので、まずは非活性化を検討しましょう。設計段階で「本当に必要か」を慎重に判断することが、こうした事態を防ぐ最善策です。
A. 最もシンプルな判断基準は「1対多のデータが発生するかどうか」です。1つの親レコードに対してデータが1つしか存在しない場合（例：会社の「契約ステータス」）はカスタムプロパティで十分です。一方、1つの親レコードに対して同種のデータが複数発生する場合（例：1つの会社に複数の「契約」）はカスタムオブジェクトが適切です。迷った場合は、本記事で紹介した5つの判断基準に照らし合わせて検討してください。3つ以上該当すればカスタムオブジェクト、2つ以下であればカスタムプロパティで対応するのが目安です。
A. HubSpotのカスタムオブジェクトには、契約プランに応じたレコード数の上限があります。大量のトランザクションデータ（例：日次の利用ログ、アクセス履歴など）をカスタムオブジェクトに格納する場合は、レコード数の上限に達する可能性があるため注意が必要です。大量データの管理が必要な場合は、HubSpot外のデータウェアハウスやBIツールとの連携を検討し、HubSpotには集約・サマリーレベルのデータのみを格納する設計が効果的です。「すべてのデータをHubSpotに入れる」のではなく、「CRMとして必要なデータをHubSpotに入れる」という考え方が重要です。
A. HubSpotでは、CSVファイルによるインポート機能を使ってカスタムオブジェクトのレコードを一括登録できます。インポート時には、オブジェクトの一意キー（表示名プロパティなど）を指定し、関連付けを設定することも可能です。ただし、関連付けの設定にはインポートファイルの構成を適切に設計する必要があります。具体的には、カスタムオブジェクトのデータと、関連付け先のオブジェクトの一意キー（会社のドメインやコンタクトのメールアドレスなど）を同じファイルに含める形式が一般的です。大量データの初期投入時には、インポート前にテスト用の少量データで動作確認を行うことを推奨します。