HubSpot を導入して最初に取り組むべきは、営業が日常的に使いたくなる CRM の設計だ。オブジェクト構造の理解・ライフサイクルステージの定義・プロパティ設計・データインポートの品質——この章で扱う「地盤工事」の出来が、その後の Sales Hub 活用の成否をほぼ決定する。
HubSpot CRM の基本単位はオブジェクト（Object）だ。営業活動で扱うほぼすべての情報は、4つの標準オブジェクトとその関連付けで表現できる。この構造を正確に理解することが、CRM 設計の出発点になる。
| オブジェクト | 何を記録するか | よくある誤用 |
|---|---|---|
| コンタクト | 担当者個人の情報・行動履歴（メール開封・フォーム入力・ページ訪問） | 会社情報をコンタクトに入力してしまう。会社レコードと紐づけずに放置する |
| 会社 | 法人単位の情報・アカウントレベルのエンゲージメント・売上・従業員規模 | コンタクトと会社を別々に管理して紐づけない。同一企業の重複レコードを放置する |
| 商談（Deal） | 具体的な商談案件・金額・クローズ予定日・ステージ | 1社に複数の会話があっても1つの商談にまとめてしまう。商談と会社を紐づけない |
| タスク / アクティビティ | 架電メモ・ミーティング議事録・メール・フォローアップ予定 | 外部ツール（メモ帳・スプレッドシート）に活動記録を残してCRMに入力しない |
Sales Hub Enterprise ではカスタムオブジェクトを作成できる。たとえば「プロジェクト」「製品インスタンス」「パートナー」など、標準4オブジェクトでは表現できないビジネス固有の概念をCRMに組み込める。標準オブジェクトと同様に関連付け・ワークフロー・レポートが利用可能だ。ただしカスタムオブジェクトは設計が複雑になりがちなため、「本当に標準オブジェクトでは表現できないか」を十分に検討してから導入しよう。
「1つの実体は1つのオブジェクトに記録する」——これがCRM設計の基本だ。「田中さん（コンタクト）は株式会社ABC（会社）のマーケティング部長で、2026年Q1の新規導入案件（商談）を担当している」という情報は、それぞれ別のオブジェクトレコードに記録し、関連付けで結ぶ。1つのレコードに全部詰め込まない。
ライフサイクルステージ（Lifecycle Stage）は、コンタクトが「見知らぬ人」から「顧客」「リピーター」へと変化するプロセスを7段階で表現する CRM の根幹設定だ。これを正しく設計・運用することで、マーケティングと営業が「今このリードはどのフェーズにいるか」を共通言語で話せるようになる。
ライフサイクル設計で最も重要かつ最も揉める箇所が MQL（Marketing Qualified Lead） と SQL（Sales Qualified Lead） の定義だ。曖昧なままにすると「マーケが渡したリードは質が低い」「営業がちゃんとフォローしていない」という水掛け論になる。
| MQL（マーケ判定済みリード） | SQL（営業判定済みリード） | |
|---|---|---|
| 定義 | マーケティング活動への反応度が閾値を超え、営業にパスする価値があるとマーケが判断したリード | 営業担当者がヒアリングした結果、商談化に値すると判断したリード |
| 判定者 | マーケティングチーム（＋スコアリングシステム） | 営業担当者（初回コール・メール後に判断） |
| 判定基準の例 | リードスコア80点以上 ＋ 価格ページ訪問 ＋ ICP 業種・規模に合致 | 予算あり ＋ 導入権限あり ＋ 課題が明確 ＋ 6ヶ月以内に導入意向 |
| HubSpot での 更新方法 |
ワークフローで自動更新（スコア閾値到達時） | 営業担当者が初回コール後に手動更新（またはコール結果ワークフロー） |
| 更新タイミング | 即時（スコア到達と同時に通知） | 初回アプローチから48時間以内に判定・更新 |
ライフサイクルステージと混同しやすいのがリードステータスだ。ライフサイクルステージは「大きな旅のどこにいるか」を表し、リードステータスは「営業担当者の現在の対応状況」を表す。たとえばライフサイクルが SQL であっても、リードステータスは「未着手 / 連絡試みた / 接続済み / 不適格 / 再育成中」と細分化できる。
HubSpot のライフサイクルステージはデフォルトで後退（ダウングレード）を自動的には行わない設計になっている。一度 Customer になったコンタクトを Lead に戻すことは通常しない。ただし MQL → Lead への差し戻し（営業が「このリードは不適格」と判断した場合）は、リードステータスで管理するのが正しい設計だ。ライフサイクルとリードステータスを混同しないようにしよう。
HubSpot では標準プロパティ（デフォルトで用意されているフィールド）に加えて、ビジネス固有の情報を記録するためのカスタムプロパティを自由に作成できる。ただし「作れるから作る」はアンチパターンだ。プロパティが増えすぎると入力率が下がり・レポートが複雑になり・CRM のメンテナンスコストが増大する。
① 似た意味のプロパティを複数作る（「リードソース」「集客経路」「流入チャネル」が全部ある状態）→ 入力が分散してレポートが不正確になる。② 自由記入テキスト型を多用する→ 表記ゆれが発生してフィルタ・集計が機能しなくなる。可能な限りドロップダウン・チェックボックスを使う。③ 「いつか使うかも」で作る→ 未使用プロパティが溜まり、入力フォームが肥大化して入力率が下がる。「今すぐ使うか」を基準に作成する。
B2B 営業では「1社に複数の担当者がいる」「持株会社の傘下に複数の子会社がある」という構造が頻繁に現れる。HubSpot ではこれを会社の親子関係（Parent-Child）とコンタクトの複数会社関連付けで表現できる。
親会社レコードを見ると、紐づく全子会社のコンタクト・商談・アクティビティを集約して確認できる。グループ全体への営業活動（ABM）を管理する際に特に威力を発揮する。2026年1月のアップデートで、子会社コンタクトのフォーム入力も親会社タイムラインに表示されるようになり、アカウント全体のエンゲージメントが一目でわかるようになった。
エンタープライズ商談では「意思決定者だけにアプローチすれば済む」時代は終わった。最新の B2B 購買調査では、平均 6〜10 名が購買判断に関与すると言われている。HubSpot ではコンタクトにバイイングロール（Buying Role）プロパティを設定することで、誰が何の役割を持つかを管理できる。
| バイイングロール | 役割の説明 | 対応アプローチ |
|---|---|---|
| Decision Maker （意思決定者） |
最終的な購買承認権限を持つ。予算執行者。CxO・部門長が多い | ROI・ビジネスインパクトを経営言語で伝える。関係構築に最も注力する |
| Budget Holder （予算保持者） |
予算の出所を管理する。Decision Maker と同一の場合もある | コスト削減・投資対効果の数字を明示する |
| Champion （推進者） |
社内で導入を推進する担当者。窓口になることが多い | 社内説得に使えるデモ資料・ケーススタディを提供する |
| End User （実際の利用者） |
ツールを日常的に使う現場担当者。使いやすさ・機能性を重視 | ハンズオンデモ・トレーニング計画を提示する |
| Blocker （ブロッカー） |
導入に否定的・消極的な人。情シス・法務・競合ツールの担当者など | 懸念点を早期に特定し、セキュリティ・コンプライアンス資料で対処する |
商談レコードの「コンタクト」セクションに、その商談に関与する全コンタクトを紐づけ、それぞれのバイイングロールを設定しておこう。「Decision Maker がまだ特定されていない商談」はリスク案件として AI が自動フラグを立てる（Conversation-powered Deal Risks）。パイプラインレビューで「商談ごとに意思決定者は確認できているか」を確認する習慣が、受注率向上につながる。
既存の名刺データ・スプレッドシート・旧 CRM から HubSpot へデータを移行する際、インポート前の準備が9割だ。準備なしにインポートすると、重複・表記ゆれ・紐づきなしのレコードが大量発生し、後のクリーンアップに膨大な工数がかかる。
| チェック項目 | 具体的な確認内容 | 対処法 |
|---|---|---|
| メールアドレスの重複 | 同じメールアドレスが複数行に存在しないか | Excel の「重複削除」機能で統合。最新情報を残す |
| 表記ゆれ | 「株式会社ABC」「㈱ABC」「ABC株式会社」が混在していないか | 会社名を統一表記に統一してから HubSpot でドメインで紐づけ |
| 必須フィールドの欠落 | メールアドレスなし・会社名なしのレコードが含まれていないか | 最低限「姓名 ＋ メールアドレス」または「姓名 ＋ 電話番号」は必須 |
| カラム名のマッピング | CSV のヘッダーが HubSpot プロパティに対応しているか | インポート画面でマッピングする前にヘッダーを英語に変えておくと確実 |
| 日付フォーマット | 日付が HubSpot 形式（YYYY/MM/DD）になっているか | Excel で日付列のフォーマットを統一してから CSV 出力する |
HubSpot はメールアドレスをユニークキーとして使い、同じメールアドレスのコンタクトが存在する場合は自動的に検知する。Breeze Intelligence を利用すれば、メール以外の情報（名前・会社・電話番号の類似性）でも重複候補を自動識別してくれる。
コンタクトレコード画面の「アクション → 重複を管理」から手動マージができる。マージ後はどちらのプロパティを「生き残らせるか」を選択できる。月次メンテナンスで「重複コンタクトレポート」を確認し、定期的にクリーンアップする習慣をつけよう。
インポート時に「既存コンタクトと一致した場合は更新する」「新規作成する」のどちらかを選択できる。基本は「更新」を選択することで、既存レコードに新情報が追記され、重複が発生しない設計にする。
HubSpot はメールドメインで会社を自動紐づけする機能がある（設定で有効化）。例えば「@abc.co.jp」ドメインのコンタクトが登録されると、自動的に「abc.co.jp」ドメインの会社レコードに紐づけられる。会社の重複を防ぐ効果的な仕組みだ。
①コンタクトと会社が正しく紐づいているか（会社名またはドメインが一致していないと自動紐づけされない）→ コンタクト一覧の「会社名」カラムが空欄でないか確認。②ライフサイクルステージが正しく設定されているか→ 「旧 CRM で営業中だったリード」が「Lead」ではなく「SQL」や「Opportunity」で入ってきているか確認。③担当者（HubSpot Owner）が割り当てられているか→ オーナー未設定のコンタクト・商談はワークフロー・通知が動かないため最優先で確認する。
コンタクト（個人）・会社（法人）・商談（案件）・タスク（行動）は別々に記録し、関連付けで結ぶ。1つのレコードに詰め込まない設計が CRM 品質の基本。
ライフサイクルステージの設計の核心は MQL と SQL の定義。「どんな条件で営業にパスするか」を数値基準で決め、両チームが合意した文書として残す。
ドロップダウン・チェックボックスを活用して表記ゆれを防ぐ。自由記入テキストは最小限に。似た意味のプロパティを複数作らない。年次で棚卸しする。
B2B 商談では平均 6〜10 名が購買に関与する。Decision Maker・Champion・Blocker の役割を商談レコードに記録することで、AI によるリスク検知が機能する。
重複・表記ゆれ・必須フィールド欠落を事前に解消してからインポートする。テスト10件で動作確認後に本番実行。インポート時は「更新」を選択して重複を防ぐ。
HubSpot のメールドメイン自動紐づけ機能を有効化することで、コンタクトが追加されるたびに会社レコードへの関連付けが自動化される。手動作業を大幅に削減できる。