中小企業のためのHubSpot入門：プラン選定・契約条件・初期構成・運用立ち上げを順序立てて握る意思決定ガイド

このホワイトペーパーで分かること

• HubSpotのHub構成と4プラン階層（Free／Starter／Professional／Enterprise）の関係を、自社の業務範囲と人数から「最初に握る範囲」として絞り込める
• プラン選定を「価格表との対応」ではなく「人数 × 成熟度 × 適用範囲」の3軸で意思決定するフレーム
• 契約前にベンダーと握るべき5項目（移行性／データ整合／カスタム項目方針／ユーザー権限／解約条件）の言語化
• 初期構成の最小セット（プロパティ・ステージ・ワークフロー1本・レポート3本）の決め方
• 営業・マーケ・CSの組み合わせ運用を、兼任前提の小組織で崩れない形に設計する手順
• AI機能（Breeze）に手を出す前にやるべき3つの土台と、その後のシリーズへの接続点

対象読者

• BtoB SaaS／製造業（生産財・部材・FA機器の代理店営業）／人材紹介・人材派遣／IT受託・SIer／業務系プロフェッショナルサービス／不動産（法人向け仲介）／印刷・パッケージ／士業／卸売・商社の中小企業で、商談サイクルが2週間〜6ヶ月の事業者
• 従業員30〜200名規模（重点は50〜150名）。営業組織3〜20名、マーケ担当0〜3名、情シス0〜1名で兼務が前提の組織
• 経営者、営業責任者、営業企画責任者、マーケ責任者、情シス兼務責任者。CRM／SFAは未導入か、HubSpot Freeや他社無料CRM、または試用版で1〜6ヶ月運用中
• 「Free／Starter／Professional／Enterpriseの違いと、Hubごとの役割が頭に入っていない」「試用版を入れたが初期セットアップで止まっている」「フルセット見積りに判断保留中」「契約条件と解約条件が不安」「Breezeに手を出すタイミングが分からない」のいずれかに該当する層

このWPの結論（Executive Summary）

課題と緊急性

HubSpotは中小企業のCRM／SFA選定で最有力候補の一つだが、初期判断の段階で詰まる事例が頻発している。プラン選定、契約条件、最小構成、運用立ち上げの4つを順序立てて握る前に契約してしまう失敗パターンが繰り返されている。

中小企業庁「2023年版 中小企業白書」では、SFA／CRMを導入した中小企業のうち「導入効果を実感している」と回答した企業は約3割にとどまる（出典：中小企業庁「2023年版 中小企業白書」第2部・デジタル化）。導入から数年経過すると形骸化が進む傾向も繰り返し報告されている。

具体的な失敗パターンは3類型に分かれる。フルセット契約後に7割の機能が眠る過大投資、Free版で止まり成長機会を逃す過小投資、年間契約だけが進んで運用は立ち上がらない契約後放置である。

一方でHubSpotは2024年以降、AI機能（Breeze）やHub構成の再編で複雑化している。未設計のまま乗せると初期判断のコストはさらに増す。

アプローチ

本WPはHubSpot導入の最初の判断を4段階に分解する。プラン選定、契約条件、初期構成、運用立ち上げである。各段階の論点と判断軸を整理する。

プラン選定は「人数 × 成熟度 × 適用範囲」の3軸で決める。契約条件は移行性／データ整合／カスタム項目方針／ユーザー権限／解約条件の5項目を稟議の言葉で握る。

初期構成は最小セット（プロパティ・ステージ・ワークフロー1本・レポート3本）に絞る。運用立ち上げは兼任前提で「日次・週次・月次の入力動線」を設計する。AI機能（Breeze）は後続フェーズに位置付け、本WPでは土台論に集中する。

主要発見

1. HubSpot導入が止まる最大原因は、プラン選定や予算でも機能比較でもなく「初期判断を順序立てて握る前に契約してしまう」設計順序の誤りである
2. プラン選定の3軸のうち、中小企業で最も誤りやすいのは「適用範囲」。最初に握るのはSales Hubのみで十分なケースが多いが、Marketing Hubを同時に契約して使い切れない事例が頻発する
3. 契約前に握るべき5項目のうち稟議で最も価値が高いのは「移行性」と「解約条件」。契約後に変更できない一方、見積書・案内資料には明記されないため、ベンダーへの別途確認が必須
4. 初期構成で重要なのはプロパティ数の最小化。「使うかもしれない」項目を全部入れると現場の入力負担で立ち上がらない。プロパティは「日次／週次／月次」のいずれで使うかで取捨選択する
5. AI機能（Breeze）は土台が立っていない状態で乗せると効果が出ない。プロパティ・ステージ・ワークフローが運用に乗ってから、後続フェーズの検討対象として位置付ける方が合理的

目次

1. HubSpotを選ぶ前に詰まる3パターン — 過大投資／過小投資／契約後放置
2. HubSpotの全体像 — Hub構成と4プラン階層の関係
3. プラン選びの意思決定フレーム — 人数 × 成熟度 × 適用範囲
4. 契約前に握るべき5項目 — 移行性／データ整合／カスタム項目方針／ユーザー権限／解約条件
5. 初期構成の最小セット — プロパティ／ステージ／ワークフロー1本／レポート3本
6. 営業／マーケ／CSの組み合わせ運用 — 兼任前提の小組織でどう回すか
7. AI機能（Breeze）に手を出す前にやるべき3つの土台
8. 失敗事例 — プラン格上げ依存／無理な全社展開／自社カスタムへの拘り
9. 段階導入と「使い続ける」設計 — Phase 1 案件管理 → Phase 2 自動化 → Phase 3 連携拡張
10. 稟議用1ページサマリー — 経営層向け
11. 次のステップ — 自社のHubSpot初期判断を4段階で握る

---

1. HubSpotを選ぶ前に詰まる3パターン — 過大投資／過小投資／契約後放置

HubSpot導入が止まる最大原因は、プラン選定や予算でも機能比較でもない。初期判断を順序立てて握る前に契約してしまう設計順序の誤りである。

中小企業の現場で詰まる症状は3つの類型に集約できる。過大投資、過小投資、契約後放置である。いずれも順序の崩れが構造的な原因になっている。

1.1 過大投資 — フルセット契約後に7割の機能が眠る

過大投資の典型は、ベンダーから提案されたフルセット見積りをそのまま契約してしまうパターンである。Sales HubとMarketing Hubを同時にProfessional階層で契約し、複数シートを揃え、Content HubやData Hubも一括で乗せる構造になる。

契約直後は「全部使えるから安心」という空気になる。しかし半年後、運用に乗っているのはSales Hubの基本機能とDeal Pipelineだけ、というケースが頻発する。

Marketing Hubのワークフロー、Service Hubのチケット、Content Hubのブログ機能は、運用設計が固まっていないと立ち上がらない。年間契約だけが進み、機能の7割が眠ったまま更新時期を迎える。

中小企業の規模では、HubSpotの全機能を同時に運用する人的余力はほぼない。最初に握る範囲を絞らずにフルセット契約すると、過大投資が構造的に固定される。

1.2 過小投資 — Free版で止まり成長機会を逃す

過小投資はFree版で止まる現象である。HubSpot Freeは無料CRMとして十分な機能を持つため、最初の半年は「これで足りる」という感覚で運用が回る。

しかし営業組織が10名を超えたあたりから、ステージ管理・自動化・レポートの限界が露呈する。Free版ではDeal Pipelineは1本まで、ワークフロー自動化は基本機能のみ、レポートはテンプレート範囲に限られる。

成長段階で有償プランへの移行判断が必要になるが、ここで「とりあえずFreeで続ける」を選び続けると、組織成長の機会損失が発生する。商談数が増えても可視化されず、マネージャーレビューが回らず、属人化したまま規模だけ大きくなる。

過小投資は「コストを抑える」発想で始まるが、結果として営業生産性の停滞というコストを払うことになる。

1.3 契約後放置 — 年間契約だけが進み運用が立ち上がらない

契約後放置は3類型の中で最も深刻な失敗である。Starter以上の有償プランを契約したものの、初期セットアップで止まり、3〜6ヶ月放置されたまま月額負担だけが発生する状態である。

放置の引き金は決まったパターンを取る。導入時に「誰がプロパティを設計するか」「Deal Pipelineをどう作るか」が決まらない。担当者は本業に追われ、ベンダー初期設定のまま運用開始日を迎える。

開始後も入力ルールが明文化されないため、現場は「何を入れればいいか分からない」状態になる。マネージャーは督促を繰り返すが、督促のたびに入力品質が下がる。最終的に誰もHubSpotを開かない状態に落ち着く。

契約は年間で進行しているため、解約も再導入もコストが高い。「とりあえず来期まで様子を見る」という判断が積み重なり、運用は立ち上がらないまま更新を迎える。

1.4 3類型に共通する構造原因

3類型は症状が違うが、構造原因は同じである。プラン選定、契約条件、初期構成、運用立ち上げの4段階を順序立てて握る前に契約してしまっている。

過大投資はプラン選定の段階で判断軸を持たないまま提案を受け入れている。過小投資はプラン選定で「とりあえずFree」を選び、運用設計の論点を握っていない。契約後放置は契約は済んでも初期構成の意思決定がされていない。

設計順序を直すと、3類型は構造的に予防できる。本WPはこの設計順序を4段階に分解し、各段階の意思決定論点と判断軸を整理する。

---

2. HubSpotの全体像 — Hub構成と4プラン階層の関係

HubSpotの全体像はHub構成と4プラン階層のマトリクスで把握する。中小企業が最初に握るのは1〜2 Hubに絞り、4階層はStarterまたはProfessionalから入るのが標準である。フルセット契約は機能の重複と過大投資を招く。

2026年5月時点でHubSpotは「Smart CRM」と呼ばれる統合契約データベースを土台に、その上に複数のHub（製品モジュール）が乗る構造になっている。

各HubはFree／Starter／Professional／Enterpriseの4階層を持つ（出典：HubSpot公式「Product & Services Catalog」2026年版 / HubSpot Pricing Page）。

2.1 5つの主要Hubの役割

中小企業が選定対象とする主要Hubは5つに整理できる。Sales Hub、Marketing Hub、Service Hub、Content Hub、Data Hubである。それぞれの役割を1行で把握できると、自社にどのHubが必要かの初期判断が立てやすい。

上記の他にCommerce Hub（EC・決済関連）が存在するが、中小企業のBtoB事業では選定対象から外れることが多い。本WPでは主要5 Hubに絞って論じる。

2.2 4プラン階層の構造

4プラン階層はFree、Starter、Professional、Enterpriseの順で機能とユーザー数が拡張される。階層が1つ上がるごとに、自動化機能、レポート機能、カスタマイズ機能の上限が大きく緩む。

中小企業の重点はSales Hub StarterまたはProfessionalである。最初からEnterpriseを選ぶケースは稀で、組織成長に合わせて段階的に階層を上げるのが標準的な進め方になる。

2.3 最初に握るHubは1〜2に絞る

中小企業が最初に握るべきHubは1〜2に絞るのが原則である。営業組織が動いている事業ならSales Hub単独から入る。マーケ施策が先行している事業ならSales HubとMarketing Hubの2つに絞る。

3 Hub以上を同時に立ち上げると、運用設計の論点が指数関数的に増える。プロパティ設計、ステージ定義、ワークフロー、レポート、権限設計のそれぞれをHub間で整合させる必要が出てくる。中小企業の人的余力ではほぼ崩れる。

Service HubやContent Hub、Data Hubは、Sales Hubの運用が安定してから順次追加する。最初の1年はSales Hubに集中投資し、土台を固めるのが定石である。

CRM／SFAの設計原則（データモデル・ステージ定義・運用設計の3層）については姉妹WP「CRM／SFAは設計を間違えると『データの墓場』になる」で扱っている。本WPはHubSpot固有の意思決定論点に集中する。

---

3. プラン選びの意思決定フレーム — 人数 × 成熟度 × 適用範囲

プラン選定は「価格表との対応」ではなく「人数 × 成熟度 × 適用範囲」の3軸で意思決定する。3軸のうち中小企業が最も誤りやすいのは適用範囲である。

ベンダー営業からの提案は機能比較表が中心になりやすい。しかし機能の有無だけで決めると、組織の人数や成熟度と噛み合わないプランを契約しやすくなる。3軸で組み立てると、自社にとって過剰な階層と不足な階層が判別できる。

3.1 人数軸 — 営業・マーケ・CSの利用者数で見る

人数軸は営業・マーケ・CSを合わせた利用者数で考える。10名以下、10〜30名、30名超の3階層で粗く区切ると判断しやすい。

10名以下の組織はSales Hub Starterで土台が十分に立つ。Professional階層の高度な自動化やカスタムレポートは、現場の入力品質が安定する前は使い切れない。

10〜30名の組織はSales Hub Professionalが選択肢に入り始める。複数Pipelineが必要になったり、マネージャー単位でのレポート閲覧範囲を分けたい要件が出てきたら、Professional階層の価値が立ち上がる。

30名超の組織は事業部や担当チームでの分割管理が必要になり、Professional以上が標準になる。Enterpriseは事業部複数・権限階層複数・カスタムオブジェクトを本格運用する段階で検討する。

3.2 成熟度軸 — CRM／SFA経験の有無で見る

成熟度軸はCRM／SFAの運用経験を意味する。未経験、無料ツール経験あり、有償CRM経験ありの3階層で区切る。

未経験組織はSalesforceやHubSpotの有償プランをいきなり契約しても運用に乗らないことが多い。Free版またはStarterで「データを入れる文化」「ステージを動かす文化」を半年〜1年かけて作るのが先である。

無料ツール経験ありの組織は、Free版の限界に当たって有償移行を検討するタイミングが訪れる。Starterからの移行が標準で、Pipelineが複数必要・ワークフローを増やしたい段階でProfessionalを検討する。

有償CRM経験ありの組織は、他社CRMからの移行ケースが多い。Salesforce／Zoho／kintoneから移行する場合は、データモデルと運用ルールが既に確立されているため、Professionalから入れる組織が多い。

3.3 適用範囲軸 — どのHubから入るか

適用範囲軸は最も誤りやすい。「全部使うかもしれないからフルセット」と判断すると、過大投資のパターンに確実にはまる。

最初に握る範囲は次の4類型で整理できる。Sales Hubのみ、Sales Hub + Marketing Hub、Sales Hub + Service Hub、フルセットの4つである。中小企業の標準はSales Hubのみで、マーケ施策が先行している事業に限ってMarketing Hubを同時に握る判断がある。

Sales Hub + Service Hubの組み合わせは、サブスクリプション型ビジネス（SaaS・継続契約モデル）で顧客対応とエクスパンションを統合管理したい段階で選ぶ。立ち上げ期から組むケースは稀で、Sales Hub運用が安定した後の追加が標準になる。

フルセット契約は、中小企業の段階では推奨しない。3 Hub以上の同時運用は人的余力を超え、結果として過大投資パターンに収束する。

3.4 3軸の組み合わせで意思決定する

3軸の組み合わせで実際の意思決定を進める。例えば営業10名・無料ツール経験あり・Sales Hub単独で握る場合は、Sales Hub Starterが標準解になる。

営業25名・有償CRM経験あり・Sales Hub + Marketing Hubを適用範囲とする場合は、Sales Hub Professional + Marketing Hub Starterの組み合わせが現実的になる。Marketing Hubを最初からProfessionalで取ると、ナーチャリング設計が未着手のまま機能だけ揃って眠るリスクが高い。

3軸の整理を稟議書の冒頭に書くと、経営層への説明が機能比較表ではなく組織判断の言葉になる。意思決定者がHubSpotを「ツール購入」ではなく「営業基盤構築」として捉え直せる起点になる。

---

4. 契約前に握るべき5項目 — 移行性／データ整合／カスタム項目方針／ユーザー権限／解約条件

契約前に握るべき5項目のうち稟議で最も価値が高いのは「移行性」と「解約条件」である。これらは契約後に変更できない一方、見積書や案内資料には明記されないため、ベンダーへの別途確認が必須になる。

5項目はベンダーとの口頭合意ではなく、文書（メール記録・契約書別紙）で握る。担当営業の異動や代理店経由の契約では、口頭合意が引き継がれずに消えるケースが頻発する。

4.1 移行性 — データ移行の範囲

移行性は既存データの移行範囲とコストに直結する。Excelやスプレッドシートで管理していた商談台帳、他社CRMの履歴データ、メール履歴のいずれも移行検討対象に入る。

標準的なオブジェクト（Contact／Company／Deal）はCSVインポートで移行できる。ただしカスタム項目は事前にHubSpot側でプロパティを設計してからのインポートになる。設計が未着手のまま移行を始めると、データの型ズレで再投入が必要になる。

他社CRMからの移行は、APIまたは認定パートナーの移行ツールを利用するケースが標準になる。HubSpotの認定パートナー経由で移行する場合、移行設計と実施に複数ヶ月を見込む。コストはパートナー側の見積りとなり、HubSpot本体の契約費用とは別になる。

メール履歴の移行は、Gmail／Outlook連携の標準機能でカバーできる範囲と、過去履歴の一括移行で別途対応が必要な範囲が分かれる。立ち上げ時点でどこまで遡って移行するかをベンダーと握る。

4.2 データ整合 — オブジェクト関係の設計

データ整合はContact／Company／Deal／Ticketの関係設計を意味する。HubSpotは標準で1 Contactが複数Companyに所属できる多対多関係を許容するが、設定で制御する必要がある。

代理店経由販売を持つ事業では、契約先（代理店）と真の顧客（エンドユーザー）の分離方針を立ち上げ時に決める。後から構造を変えると過去Dealの紐付け直しが発生し、レポートの整合が崩れる。

サブスクリプション型ビジネスでは、Dealと契約の関係を整理する。初回受注のDealと更新のDeal、エクスパンションのDealをどう記録するかで、更新率・LTVの可視化が変わる。HubSpot側の標準推奨を聞いた上で、自社のKPI構造に合わせて意思決定する。

4.3 カスタム項目方針 — 標準で進めるかカスタムを増やすか

カスタム項目方針は、標準プロパティで進めるかカスタムプロパティを追加するかの判断軸である。立ち上げ初期はカスタム5項目以内に絞るのが現実解になる。

「使うかもしれない」項目を全部追加すると、現場の入力負担が増え運用が立ち上がらない。カスタム項目は「経営会議で意思決定に使う／週次レポートで使う／日次オペレーションで使う」のいずれかに該当する場合のみ追加する。

カスタムオブジェクトはProfessional階層以上でのみ利用できる。Starter階層では標準オブジェクト（Contact／Company／Deal／Ticket）のみで運用設計する必要がある。

4.4 ユーザー権限 — 誰が何を見られるか

ユーザー権限は階層によって設定可能な粒度が変わる。Starter階層は基本的な権限のみで、事業部単位や担当者単位での閲覧制限はProfessional以上で利用できる。

中小企業の規模では、立ち上げ初期は全員が全データを見られる設計で問題が起きにくい。営業組織が30名を超え、事業部や担当チームでデータの閲覧範囲を分けたい段階でProfessionalへの移行を検討する。

代理店や外部パートナーをHubSpotに招くケースでは、権限設計が重要になる。外部パートナーが自社の全Dealを見られる設計はリスクが高いため、初期段階から権限分離を見込む必要がある。

4.5 解約条件 — 中途解約とデータ持ち出し

解約条件は中途解約の経過措置とデータ持ち出しの2点を握る。HubSpotは年間契約が標準で、中途解約は原則として日割り精算が効かない構造になっている。

解約予告のタイミングも重要である。契約書に記載された予告期日までに通知しないと、自動更新で次年度の契約が成立する。導入時点で解約予告のタイミングと連絡経路を確認しておく。

データ持ち出しはCSVエクスポートで標準オブジェクトを抽出できる。カスタムオブジェクトやワークフロー定義の出力範囲は階層と契約により異なるため、契約前に確認する。データ整合性を保ったまま他社CRMに移行できるとは限らない点も認識しておく。

---

5. 初期構成の最小セット — プロパティ／ステージ／ワークフロー1本／レポート3本

初期構成で重要なのはプロパティ数の最小化である。「使うかもしれない」項目を全部入れると現場の入力負担で立ち上がらない。プロパティは「日次オペレーションで使う／週次レポートで使う／月次経営会議で使う」のいずれかに該当するものだけに絞る。

中小企業の典型失敗は両極端に分かれる。ベンダー初期設定のまま運用開始する受け身パターンと、カスタムプロパティを30個以上追加する過剰設計パターンである。どちらも運用が立ち上がらない。

5.1 プロパティ — 最小15〜20項目に絞る

プロパティは標準項目10〜15個とカスタム項目5個以内の合計15〜20項目に絞る。中小企業の立ち上げ初期はこの粒度で十分に運用が回る。

標準項目は次のような構成になる。Contact側で氏名・メール・電話・役職・会社名、Company側で業種・規模・所在地、Deal側で案件名・規模・ステージ・受注予定日・確度・担当者。これだけで月次の経営会議レポートは作れる。

カスタム項目を追加するかどうかは、「経営会議で意思決定に使うか／週次マネージャーレビューで使うか／日次の営業活動で使うか」の3分類で判定する。例えば「商談温度感」「次回アクション期日」「決裁ルート」のような項目は日次で使うため追加する価値がある。

一方、「初回接触経路」「資料DL履歴」「過去訪問回数」のような項目は、立ち上げ初期は経営会議で見ない。半年〜1年運用してから追加判断する。

5.2 Deal Pipeline — 5ステージに絞り出口条件を明文化

Deal Pipelineは5ステージ程度に絞る。一般的な構成は「リード／案件化／提案／受注／契約」または「商談化／一次提案／本格提案／クロージング／受注」のいずれかになる。

ベンダー初期設定の「Appointment Scheduled／Qualified to Buy／Presentation Scheduled／Decision Maker Bought-In／Contract Sent／Closed Won／Closed Lost」をそのまま使うのは推奨しない。日本の中小企業のBtoB商談プロセスとは粒度が合わない。

各ステージの「出口条件」を明文化することが最重要である。リードから案件化への移動条件は「初回ヒアリング完了かつ予算規模が判明」、提案から受注への移動条件は「内示書または発注書面が出ている」のように、客観的に判定できる基準で書く。

出口条件が「担当者の感触」で決まると、ステージ別の歩留まりが算出不能になる。意思決定者ごとの判定がバラけ、経営会議でのパイプラインレビューが信用できなくなる。

5.3 ワークフロー — 最初は1本だけ動かす

ワークフロー（自動化）は最初の1本だけに絞る。代表的なのは「新規問い合わせフォーム受領時に担当者へ通知」のシンプルな自動化である。

ワークフローは便利な機能だが、最初から複数本動かすと運用上の事故が起きやすい。重複通知、誤った対象への配信、停止漏れによる古い情報の継続送信などである。

1本目が安定して動き、現場が「ワークフローは便利だ」という感覚を持った段階で、2本目を追加する。2本目は「商談ステージ移動時にマネージャーへ通知」「受注時にCSへ自動引き継ぎ」のいずれかが標準的な選択になる。

ワークフローを増やす際は、テスト環境（または最小範囲）での動作確認を経てから本番投入する。ProfessionalまたはEnterprise階層では複雑な分岐や条件付き自動化が可能になるが、Starter階層の範囲で十分に立ち上がる組織が多い。

5.4 レポート — 3本に絞る

初期レポートは3本に絞る。営業活動レポート、パイプラインレポート、月次受注レポートである。

営業活動レポートは「誰が・今週・何件の活動を記録したか」を可視化する。HubSpotの標準レポートで構成でき、マネージャーの週次レビューに直結する。

パイプラインレポートはステージ別の案件数・規模・確度を一覧する。経営会議での「来月の受注見通し」の議論で使う。確度の計算ロジックを月初に固定すると、月内の議論が安定する。

月次受注レポートは確定受注の規模・件数・受注源を集計する。標準レポートのテンプレートで作れる範囲に収め、複雑な分析は月次経営会議の場でスプレッドシートに切り出す判断もある。

3本以上のレポートを最初から設計すると、マネージャーが見るべきレポートが増え、結果としてどれも見られなくなる現象が起きやすい。レポートは増やすより絞る発想で運用を立ち上げる。

---

6. 営業／マーケ／CSの組み合わせ運用 — 兼任前提の小組織でどう回すか

兼任前提の小組織でHubSpotを運用に乗せる鍵は、「誰が入力するか」を業務動線の中に組み込むことである。独立した入力作業として扱うと現場は止まる。動線の中に「入力すると次の人に渡る」流れを作ると入力動機が生まれる。

中小企業の典型構成は営業10名・マーケ1〜2名・CS数名で、兼任が前提になる。営業企画責任者がマネージャーを兼ね、情シスはほぼ存在しないか別業務との兼任である。この前提でHubSpotを運用するには、Sales Hubを中心に置きながらマーケとCSの動線をつなぐ設計が必要になる。

6.1 リード受領 — マーケから営業への動線

リード受領はマーケから営業への動線の起点になる。問い合わせフォーム、資料DL、名刺取り込みのいずれもHubSpotにContact／Companyとして登録される設計にする。

マーケ担当が兼任の場合、Contact発生から営業への通知まで自動化しておく。最初の1本のワークフロー（章5.3）はこの通知に使うケースが多い。営業担当者がHubSpotを毎日開かなくても、新規Contact発生がメール通知で届く設計にする。

リード受領時点で「誰が一次対応するか」をワークフローで自動アサインする。事業部別、業種別、地域別のいずれかの基準で振り分ける設計が標準になる。アサインが固定担当者に偏ると属人化するため、ローテーション設計を組み込む組織もある。

6.2 商談ステージ更新 — 営業とマネージャーの動線

商談ステージ更新は営業とマネージャーの動線をつなぐ。営業がDealのステージを動かす操作を、マネージャーが日次または週次でレビューする流れを作る。

ステージ移動時の出口条件（章5.2）が明文化されていれば、マネージャーレビューは「出口条件を満たしているか」の客観チェックになる。担当者の感触ではなく、Deal内に記録された情報（提案書送付の有無、決裁者面談の有無、内示書面の有無）で判定する。

マネージャーが毎日HubSpotを開く運用は、組織規模30名を超えると現実的に維持できない。週次の定例ミーティングでパイプラインレポート（章5.4）を見る運用が標準で、その間の例外検知はワークフロー通知に任せる。

6.3 受注引き継ぎ — 営業からCSへの動線

受注引き継ぎは営業からCSへの動線である。受注ステージ移動時にCS担当へ自動通知する設計が、引き継ぎ漏れを防ぐ最初の一歩になる。

引き継ぎ情報はDealのメモ欄またはカスタムプロパティに記録する。標準項目では「契約条件」「顧客の懸念事項」「初回キックオフの希望時期」を残す。CSが受注後にDealを開いた時点で、営業の合意内容を再現できる粒度で書く。

CS組織が独立していない事業（営業がCSを兼任する事業）では、受注後のフォロー業務もSales HubのDealに紐付けて記録する設計になる。ステージを「受注」の後に「オンボーディング」「契約継続」を追加するか、別途Pipelineを切り分けるかは事業構造で決まる。

6.4 顧客対応ログ — CSから営業への動線

顧客対応ログはCSから営業への動線である。CSが対応したメール、電話、ミーティングの記録がContact／Companyに紐付くと、営業が更新案件を検討するタイミングで直近の対応状況が見える。

ここを動線として組み込むと、CSの入力動機が生まれる。「自分が記録したログが営業の更新案件提案に使われる」という相互利用の関係になる。独立した入力作業ではなく、業務動線の中の自然な記録になる。

逆に「CSは入力するが営業は見ない」「営業は入力するがCSは確認しない」という一方通行の構造になると、入力動機が消える。動線設計は双方向であることが運用継続の鍵になる。

6.5 兼任前提の運用設計の原則

兼任前提の運用設計には3つの原則がある。第一に、入力動線を業務動線に重ねる。独立した入力時間を作らない。第二に、入力したデータが他の人の業務インプットになる構造を作る。一方通行を避ける。第三に、ワークフローで通知を自動化し、ツールを開く頻度を最小化する。

情シスがほぼ存在しない、または別業務との兼任という中小企業の実情では、運用設計の複雑度を下げることが優先される。外部のベンダーやパートナーに運用設計を依存しすぎると、契約終了後に設計が維持できなくなるリスクが残る。

内製で設計レイヤーを握り、ベンダーやパートナーは構築と立ち上げ伴走に使う役割分担が、中小企業の規模では現実的な進め方になる。

---

7. AI機能（Breeze）に手を出す前にやるべき3つの土台

AI機能（Breeze）は土台が立っていない状態で乗せると効果が出ない。プロパティ・ステージ・ワークフローが運用に乗ってから、後続フェーズの検討対象として位置付ける方が合理的である。

HubSpotのAI機能は2024年以降「Breeze」のブランドで統合された。Breeze Copilot（チャットアシスタント）、Breeze Agents（自律エージェント）、Breeze Intelligence（データエンリッチメント）などの機能群として提供されている（出典：HubSpot公式「Breeze AI」紹介ページ 2026年版）。

これらは魅力的な機能だが、土台がないと機能を引き出せない。

7.1 土台1 — プロパティ整備

AIスコアリングや予測機能の精度は、プロパティの整備度と入力品質で決まる。プロパティが空欄だらけのDealに対してAIが「次のアクション」を提案しても、推定の根拠が薄く有用な提案にならない。

例えばBreezeが「このDealは確度70%」と判定するためには、過去の類似Dealのデータが十分な品質で蓄積されている必要がある。立ち上げ初期の数十件のDealでAIスコアリングを動かしても、学習データ不足で予測が安定しない。

プロパティ整備の指標は2つある。第一に入力率（必須プロパティの空欄率）、第二に値の品質（フリーテキストではなく選択式になっているか）である。両方が高水準で安定してから、AI機能を乗せる順序が現実的になる。

7.2 土台2 — ステージ定義

AIサマリやAIによる商談状況の要約は、ステージ定義の粒度に依存する。「リード」「商談中」「受注」の3段階だけで運用している組織に対してAIがサマリを生成しても、ステージ間の差分が大きすぎて要約の粒度が荒くなる。

ステージ定義が5段階に分かれ、各ステージの出口条件が明文化されていれば、AIは「現在ステージにとどまっている期間」「次ステージへの移動可能性」を客観的な情報として要約に組み込める。

ステージ定義の精度は、Deal IntelligenceやForecasting機能の精度にも直結する。AIの判定材料はステージとそこに紐付くプロパティ・活動データであり、ステージが粗いとAIの出力も粗くなる。

7.3 土台3 — ワークフロー運用

AIが提案するアクションを受け取る動線が必要である。Breezeが「この顧客に再アプローチすべき」と提案しても、ワークフロー運用がない組織には受け皿がない。

ワークフローが運用に乗っている組織では、AI提案を「タスク自動生成」「担当者への通知」「次のステージへの移動候補」として動線に流せる。AIを「便利な機能」ではなく「業務動線の中の判断補助」として機能させるには、ワークフローの受け皿が前提になる。

立ち上げ初期はワークフロー1本（章5.3）から始め、半年〜1年かけて3〜5本に増やす。この段階を経てから、AI機能の検討が現実的になる。

7.4 本WPの位置付けと後続WPへの接続

本WPはHubSpotの初期判断（プラン選定／契約条件／初期構成／運用立ち上げ）に集中するため、AI機能の詳細仕様には立ち入らない。Breezeの個別機能（Copilot／Agents／Intelligence）の使い方、HubSpot×外部AI連携の標準アーキテクチャ、AI機能のROI算定などは別WPの主題になる。

本WPの3つの土台が立ち、Sales Hubが日次運用に乗った段階で、姉妹WP「HubSpot×AI標準アーキテクチャ」を次の一歩として参照いただきたい。土台が立った後のAI連携設計、Breezeと外部LLMの役割分担、AIエージェント運用などを扱っている。

---

8. 失敗事例 — プラン格上げ依存／無理な全社展開／自社カスタムへの拘り

HubSpot導入の失敗は「ツールの限界」ではなく「順序の崩れ」が原因である。プラン格上げ、全社展開、カスタム化のいずれも、運用が固まる前に手を出すと崩れる。

中小企業の現場で繰り返される失敗を3類型に整理する。各類型は構造原因が異なるが、共通するのは「目の前の問題をプラン・範囲・カスタムの拡張で解こうとする」発想である。

8.1 プラン格上げ依存 — 階層上げで解決すると思い込む

プラン格上げ依存は、運用課題が出るたびに上位階層への移行で解決しようとするパターンである。Starterでレポートが足りない、Professionalで権限が足りない、Enterpriseでカスタムが足りないという順序で階層を上げていく。

しかし運用課題の本質はプロパティ設計・ステージ定義・運用動線にあることが多い。階層を上げても基礎設計の問題は解決しない。Professionalにしてカスタムレポート機能が増えても、データの入力品質が低いままなら使えるレポートは作れない。

予防策はシンプルである。プラン格上げの判断は「機能不足の証拠」を集めてから行う。「Starterで本当に作れないレポート」が3本以上具体的に挙がるまでは、現状階層で運用改善する。改善余地があるうちに階層を上げると、改善されないまま負担額だけ増える。

回復策としては、一度Professionalに上げた組織でも、運用改善を進めれば次年度Starterへの戻しを検討できる。HubSpotは年単位で階層変更が可能なため、過大投資に気づいた時点での見直しは有効である。

8.2 無理な全社展開 — Sales Hub未安定でMarketing／Service同時投入

無理な全社展開は、Sales Hubの運用がまだ安定していない段階でMarketing HubやService Hubを同時展開するパターンである。経営層が「HubSpotを全社で使う」方針を出し、現場の準備が整わないまま3 Hub以上が同時稼働する。

結果として、現場の入力負担が雪だるま式に増える。営業はDeal入力、マーケはCampaign設計、CSはTicket管理を同時に求められる。それぞれの整備度が浅く、レポートも信用できず、最終的にどのHubも放置される。

予防策は段階導入である。Sales Hubが日次運用に乗り、マネージャーレビューが回り始めてから、Marketing HubまたはService Hubを追加する。各Hubの立ち上げに半年〜1年を見込み、同時並行は避ける。

回復策としては、複数Hubの同時運用で破綻している組織は、いったんSales Hub以外を「事実上の停止」にして、Sales Hubに集中する判断もある。年間契約は継続するが、運用工数を一点集中で立て直し、その後にMarketing／Serviceを再起動する順序になる。

8.3 自社カスタムへの拘り — 標準では合わないと主張してカスタム追加

自社カスタムへの拘りは、「自社の業務はHubSpot標準では合わない」と主張してカスタムプロパティやカスタムオブジェクトを大量追加するパターンである。プロパティ数が50を超え、カスタムオブジェクトが3〜5個になる組織もある。

この設計はベンダー標準の機能と相性が悪い。標準レポートはカスタム項目を反映できないことが多く、自動化機能も標準オブジェクトを前提に設計されている。カスタムを増やすほど、HubSpot本来の強みが使えなくなる。

予防策は「業務をHubSpot標準に合わせる発想」である。標準項目で表現できる業務は標準項目で表現する。標準と異なる業務プロセスがあれば、業務側を見直すか、HubSpotの外で管理する判断もある。

回復策として、カスタムを増やしすぎた組織は、半年単位でのカスタム棚卸しが有効である。「実際に入力されている」「実際にレポートで使われている」項目のみを残し、それ以外は段階的に削除する。データ削除の判断は経営層レベルでの合意が必要なため、稟議材料として整理してから進める。

8.4 3類型に共通する予防策 — 運用が固まる前に拡張しない

3類型に共通する予防策は「運用が固まる前に拡張しない」というシンプルな原則である。プラン格上げ、全社展開、カスタム追加のいずれも、現状運用の安定が前提になる。

運用が固まったかどうかの判定基準は3つある。第一に必須プロパティの入力率が一定水準以上で安定しているか、第二にステージ移動の出口条件が現場で共有されているか、第三にマネージャーが週次レポートを「信用できる数字」として扱っているか。

3つすべてが満たされてから拡張判断に入る。途中で拡張すると、土台の問題が拡張後の問題として顕在化し、回復コストが大きくなる。

---

9. 段階導入と「使い続ける」設計 — Phase 1 案件管理 → Phase 2 自動化 → Phase 3 連携拡張

段階導入の本質は「機能の積み上げ順序」である。Phase 1の案件管理が日次運用に乗っていない状態で自動化や連携拡張に進むと、入力負担が雪だるま式に増えて崩れる。

「使い続ける」設計とは、機能を増やす前に各Phaseの定着を確認する設計を指す。中小企業のAX進め方として、段階導入は組織規模（営業3〜20名）に合わせた粒度が必要になる。大企業前提の段階論をそのまま当てると、各Phaseの期間が過剰になる。

9.1 Phase 1 — 案件管理を日次運用に乗せる

Phase 1の目標は案件管理を日次運用に乗せることである。プロパティ設計、ステージ定義、最低限のレポート3本が稼働し、営業担当が日次でDealを更新する状態を作る。

Phase 1の完了判定は3つの基準で見る。第一にDealの必須プロパティ入力率（例：商談温度感、次回アクション期日）が安定して90%超で推移している。第二にステージ移動の出口条件が現場で言語化されている。第三にマネージャー週次レビューがレポートで完結している。

Phase 1の完了に要する期間は、組織規模と既存運用の整備度で変わる。営業10名規模で既存スプレッドシート運用がある組織なら、立ち上げから運用安定まで複数ヶ月を見込む。固定期間で「いつまでに完了」と置くと、無理な前倒しでPhase 2に進んで崩れる。

9.2 Phase 2 — 自動化を段階的に追加する

Phase 2の目標は自動化の段階的追加である。Phase 1で立ち上げた1本のワークフローに加え、2〜3本のワークフローを追加する。

代表的な追加ワークフローは次の通り。商談ステージ移動時のマネージャー通知、受注時のCS自動引き継ぎ、停滞案件（一定期間以上動きがないDeal）の担当者通知である。それぞれが業務動線の中に組み込まれることが前提になる。

Phase 2で重要なのは「ワークフローのテスト・本番投入・運用安定」のサイクルを1本ずつ回すことである。複数本を同時に投入すると、動作不具合の原因切り分けが困難になり、トラブル時の停止判断が遅れる。

Phase 2完了の判定基準は、ワークフローによる通知や自動アクションが「業務にとって有用」と現場が認識している状態である。「通知が多すぎて無視している」「タスク自動生成が形骸化している」という症状が出ているなら、Phase 3には進まずPhase 2を整える。

9.3 Phase 3 — 連携拡張とAI機能の検討

Phase 3の目標は連携拡張とAI機能の検討である。外部ツール連携（メール、カレンダー、会計）、Marketing Hub／Service Hubの追加、AI機能（Breeze）の検討開始がここに含まれる。

Phase 3の段階で、IT人材不足の中小企業ならではの選択肢が明確になる。情シスがほぼ存在しない組織でも、Phase 1・2で土台が固まっていれば、外部ベンダーやパートナーへの依存を最小化したまま拡張できる。

Marketing Hubを追加する場合は、リード獲得ジャーニーとSales Hubのリード受領動線を再設計する。Service Hubを追加する場合は、CS業務とSales Hubの受注引き継ぎ動線を再設計する。いずれもPhase 1の動線が土台となる。

AI機能（Breeze）の検討は章7で論じた通り、3つの土台が立ってから進める。Phase 3はAI機能を「乗せ始める」段階であり、フル展開はさらに次のフェーズになる。

9.4 各Phaseの「次に進む判断基準」を明文化する

各Phaseの「次に進む判断基準」を明文化することが、段階導入の成否を決める。判断基準が曖昧だと、現場の「もう次に進みたい」という感覚で前倒しが起き、土台が固まらないまま拡張に入る。

判断基準は経営層と現場マネージャーで合意したものを社内文書として残す。例えば「Phase 1完了基準：プロパティ入力率90%が2ヶ月連続、マネージャー週次レビューが4回連続でレポート完結」のように、数値と期間で書く。

中小企業のAX進め方として、各Phaseの完了判定を内製で握ることが重要になる。ベンダーやパートナーが「Phase 1は完了です」と言っても、自社の運用基準で判定し直す。外部の進捗報告ではなく、社内の使い続けられる状態を判定軸にする。

---

10. 稟議用1ページサマリー — 経営層向け

HubSpot導入の意思決定は、ツール購入の判断ではなく「営業オペレーションの土台構築」の経営判断である。稟議では「初期判断の4段階」を握ることが要点になる。

本章は経営層が10分で読める粒度で、HubSpot導入の稟議材料を整理する。A4縦1ページに収まる構成で、印刷して経営会議に持ち込める体裁にしている。

10.1 課題と緊急性

中小企業のCRM／SFA導入は、ツール選定や予算判断ではなく「初期判断の順序」が成否を決める局面に来ている。SFA／CRMを導入した中小企業のうち導入効果を実感している企業は約3割にとどまり（出典：中小企業庁「2023年版 中小企業白書」第2部・デジタル化）、残り7割は形骸化を経験している。

HubSpotは中小企業向けCRMの最有力候補だが、未設計のまま契約すると過大投資・過小投資・契約後放置の3類型に陥る。営業のExcel管理が限界に近づいた今、初期判断を順序立てて握る稟議材料が必要になっている。

10.2 打ち手

HubSpot導入の最初の判断を4段階に分解する。プラン選定、契約条件、初期構成、運用立ち上げである。各段階の意思決定論点を稟議で握ってから契約に進む。

プラン選定は「人数 × 成熟度 × 適用範囲」の3軸で決める。契約条件は5項目（移行性／データ整合／カスタム項目方針／ユーザー権限／解約条件）を文書で握る。初期構成は最小セットに絞る。運用立ち上げは兼任前提の動線設計で組む。

10.3 期待される変化（業務指標で示す）

10.4 類似規模の事例描写

事例1：年商10億のBtoB SaaS事業者で、営業組織8名・マーケ兼務1名の体制。Sales Hub Starterから入り、Phase 1の案件管理を半年かけて立ち上げた後、Phase 2の自動化2本を追加した。フルセット契約を提案されたが「適用範囲をSales Hubに絞る」判断で過大投資を回避できた。

事例2：年商18億の人材紹介会社で、営業組織15名・営業企画責任者1名の体制。カスタムプロパティを5項目以内に絞り、入力負担を抑えることでDeal入力率が安定した。代理店構造はなくシンプルな直販モデルだったため、データ整合の意思決定もシンプルに固められた。

10.5 次のアクション

稟議で議論すべき次のアクションは次の通り。第一に自社の「人数 × 成熟度 × 適用範囲」の3軸を社内で言語化する。第二に契約前の5項目をベンダー候補に文書で確認する。第三に初期構成の最小セットを担当者がたたき台で起こす。第四にPhase 1〜3の段階導入計画を社内合意する。

---

11. 次のステップ — 自社のHubSpot初期判断を4段階で握る

HubSpot導入の初期判断を4段階で握るセルフチェックから始めるのが、稟議準備の最短経路である。本WPで提示した論点を自社の言葉に翻訳する作業を、まず社内で進めていただきたい。

本WPの4段階（プラン選定／契約条件／初期構成／運用立ち上げ）のうち、自社の最初の判断ポイントを30分で見立てる「HubSpot初期判断セルフチェックシート」をWP巻末に別添している。自社の人数・成熟度・適用範囲を書き出し、契約前に握るべき5項目を一行ずつ確認し、初期構成の最小セットを自社業務にあてはめる構成になっている。

自社単独でのセルフチェックが難しい場合、FULLFACTでは営業オペレーションの棚卸しをHubSpot導入前の前提として実施する「業務診断パッケージ（B01・1ヶ月）」を提供している。営業領域に絞った診断レポートを納品し、初期判断の優先順位を客観評価する。

初期判断が固まり、構築フェーズに進む段階では「セールス基盤構築（B02・3ヶ月）」を中核に、HubSpotを土台とした営業オペレーション全体の設計・構築・運用立ち上げまで伴走する。

HubSpotの土台が立ち、AI連携フェーズに進む段階では、姉妹WP「HubSpot×AI標準アーキテクチャ」を次の一歩として参照いただきたい。Breezeと外部AIの役割分担、AIエージェント運用、Hub間の連携設計などを扱っている。

HubSpot導入以前に事業全体の構造から見直したい場合は「経営・事業診断（D01・1ヶ月）」が起点になる。事業構造・収益・組織・業務全体の診断から、HubSpotを位置付ける広い視点で意思決定を整理する。

---

まとめ

HubSpot導入の初期判断は、プラン選定／契約条件／初期構成／運用立ち上げの4段階で握る。各段階の意思決定論点を順序立てて整理することが、3類型の失敗（過大投資・過小投資・契約後放置）の予防につながる。

1. プラン選定は「人数 × 成熟度 × 適用範囲」の3軸で決める。最初に握るのはSales Hubのみで十分なケースが中小企業の標準である
2. 契約前に握るべき5項目（移行性／データ整合／カスタム項目方針／ユーザー権限／解約条件）は文書で確認する。移行性と解約条件は契約後に変更できないため特に重要である
3. 初期構成は最小セット（プロパティ15〜20項目／Deal Pipeline 5ステージ／ワークフロー1本／レポート3本）に絞る。「使うかもしれない」項目は採用しない
4. 運用立ち上げは兼任前提の動線設計で組む。入力作業を独立させず、業務動線の中に重ねる構造にする
5. AI機能（Breeze）は3つの土台（プロパティ・ステージ・ワークフロー）が立ってから検討する。Phase 3の段階での導入が現実的である

---

次のステップ：30分で完了する「HubSpot初期判断セルフチェック」を社内で実施し、自社の4段階の現在地を可視化することから始めていただきたい。営業オペレーションの棚卸しが必要な段階では「業務診断パッケージ（B01・1ヶ月）」、構築フェーズに進む段階では「セールス基盤構築（B02・3ヶ月）」、事業構造から見直す段階では「経営・事業診断（D01・1ヶ月）」が起点となる。