HubSpotを「顧客名簿」で終わらせない：AI前提で組み直す3層アーキテクチャ

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

• HubSpot導入済の中小企業で「単なる顧客名簿」化が起きる3つの構造的原因
• データモデル層・自動化層・運用役割層の3層アーキテクチャの全体像
• AI（議事録要約・スコアリング・下書き生成）をHubSpotのどのオブジェクトに、どの順番で組み込むかの優先順位
• 3ヶ月でアーキテクチャを構築するMonth別ロードマップと、揃うもの／揃わないもの
• Salesforce移行とHubSpot継続強化を、事業規模と営業組織人数で判断する軸

対象読者

• 中小企業のセールスマネージャー・CRO候補・事業責任者
• HubSpotをStarterまたはProfessionalで1〜2年運用しているが、商談化・受注の構造が見えていない事業責任者
• SDR/AEの優先順位付けが経験値依存になっており、スコアリング再設計が必要だと感じているセールス統括
• 営業組織が10〜30名規模になり、Salesforce移行とHubSpot継続強化のどちらに張るか判断保留中の経営者
• B02（セールス基盤構築・3ヶ月）の発注前に、外部パートナーが提示する設計の「型」を頭に入れておきたい意思決定者

目次

1. HubSpot導入済の中小企業で起きる「3つの崩れ方」
2. 3層アーキテクチャの全体像：データモデル層 / 自動化層 / 運用役割層
3. データモデル層：Contact / Company / Deal / Custom Object をどう設計するか
4. 自動化層：Workflow と AI機能の役割分担
5. 運用役割層：SDR / AE / CS / RevOps の境界をHubSpot上でどう敷くか
6. AI組み込みの優先順位：3ヶ月で着手すべき3シナリオ
7. 3ヶ月構築ロードマップ：Month 1〜3で揃うものと揃わないもの
8. Salesforce / 自社開発との比較判断軸：中小企業で残る選択肢
9. 発注前の30分セルフチェック：自社のアーキテクチャ成熟度マップ

1. HubSpot導入済の中小企業で起きる「3つの崩れ方」

中小企業がHubSpotを1〜2年運用した結果、「単なる顧客名簿」に劣化するパターンは経験的に3類型に分かれる。問題はHubSpot自体ではなく、データモデル・自動化・運用役割の3層が揃わないまま機能を増やしたことに起因する。3層のどこか1層が崩れると、AIをどれだけ乗せても3〜6ヶ月で形骸化する。

第一の崩れ方は「データモデル放置型」である。導入時のベンダーが用意した標準プロパティのまま運用を始め、自社の商談プロセスに固有の項目（業種別の意思決定者像、案件規模、リードソース別の温度感）が定義されていない。Deal Stageは現場が勝手に追加・改名し、半年後にはステージ定義の解釈が営業担当ごとにズレている。結果、レポートを開いても受注見込みが読めず、Deal Stageの数字が経営判断に使えない。

第二の崩れ方は「自動化バラマキ型」である。Workflowが30本、40本と作られているが、それぞれが個別タスクのために設計され、全体としての設計図がない。誰がいつ何のために作ったWorkflowか分からなくなり、停止して良いのか動かして良いのか判断がつかない状態が積み上がる。AIで議事録要約を乗せようとしても、どのDealに紐づけてどのプロパティに書き戻すかの設計が前段で抜けているため、要約データが孤立する。

第三の崩れ方は「役割空洞化型」である。SDR・AE・CSの役割定義は社内ドキュメントに書かれているが、HubSpot上のビュー・パイプライン・通知トリガーには反映されていない。新人が入ってもHubSpotを開いて「自分が今日触るレコードはこれだ」と分からない。経験豊富なAEが個別にビューを作って回しているが、本人が抜けるとそのビューごと消える。多くの場合、役割定義はドキュメントではなくHubSpot上の実装で初めて運用に乗る、という前提が抜けている。

3つの崩れ方は独立して起きるのではなく、連鎖する。データモデルが崩れていると自動化の設計図が描けず、自動化が無秩序だと役割定義をHubSpot上に実装できない。逆に言えば、3層を順序立てて揃え直すと、AIを乗せる土台が一気に整う。本ホワイトペーパーが示す3層アーキテクチャは、この崩れの構造に対応した設計図である。

2. 3層アーキテクチャの全体像：データモデル層 / 自動化層 / 運用役割層

HubSpot×AIの標準アーキテクチャは、データモデル層・自動化層・運用役割層の3層で構成される。AIはこのアーキテクチャの最上層に乗る単独機能ではなく、3層それぞれに分散して組み込むのが標準型である。3層は前提関係を持ち、下層が崩れると上層は機能しない。

各層の責務と、AIの組み込み先を整理する。

第1層のデータモデル層は、Contact・Company・Deal・Ticket・Custom Objectの設計と、各オブジェクトのプロパティ定義、Deal Pipelineのステージ設計、Association Labels（オブジェクト間の関係種別）の運用ルールを含む。この層は、自社の商談プロセスをHubSpot上に正しく写像する「土台のかたち」を定義する責務を持つ。AIスコアリング・要約の精度はこの層の整備度で決まる。

第2層の自動化層は、Workflow・Sequences・Lead Scoring・Breeze（HubSpot標準のAI機能群）・外部LLM API（Claude、ChatGPT等）連携で構成される。この層では「決定論的な動き」（ルーティング・通知・ステージ遷移）と「確率論的な判断」（要約・分類・下書き生成）を切り分けて実装する。両者を混在させると、Workflowが複雑化しメンテナンス不能になる。

第3層の運用役割層は、SDR・AE・CSのビュー、パイプライン、通知設定、SLA、ダッシュボードで構成される。この層が、データモデルと自動化を「現場が日々開く画面」に落とし込む。役割定義のドキュメントが画面に反映されて初めて、新人もベテランも同じ動きをする。

3層は順序立てて整備する。データモデル層が固まっていない状態で自動化を増やすと、後でデータモデルを直したとき自動化が連鎖崩壊する。多くの場合、中小企業がHubSpotで詰まる根本原因は、この順序を飛ばしたことにある。

3. データモデル層：Contact / Company / Deal / Custom Object をどう設計するか

データモデル層の設計品質が、3層アーキテクチャ全体の上限を決める。中小企業で頻出する不全は、(a) プロパティの未定義、(b) Custom Objectの濫用、(c) Deal Stageの現場任せ、の3つに集約される。AIスコアリングや要約の精度を上げたければ、AIを乗せる前にこの3点を直す。

頻出する不全パターンと、中小企業での標準的な対処を表で整理する。

Contactには、中小企業向けの商談で最低限必要な項目として「役職」「決裁権限の有無」「主担当か推進担当か」「最終接点日」「リードソースの初回／最終」が入る。Companyには「年商レンジ」「従業員数レンジ」「業種コード（自社のセグメント定義）」「ターゲットスコア」が入る。Dealには「案件規模レンジ」「想定受注時期（月次粒度）」「失注理由（選択肢の定型化）」「競合先」「主要意思決定者のContact ID」が入る。これらが揃って初めて、AIスコアリングのモデル学習にも、議事録要約の文脈にも、使える素材になる。

Custom Objectの判断軸として実務的に効くのは「このエンティティは独自のライフサイクルを持つか」である。物件・商品・契約は独自のライフサイクル（在庫推移、更新サイクル）を持つためCustom Objectが向く。一方、提案資料や見積書はDealに紐づくドキュメントであり、Custom Objectを切るよりもDeal上の関連レコードまたは外部ストレージ連携で扱う方が、データモデルがシンプルに保てる。経験的に、Custom Object数は3〜5個以内に収めると、中小企業の運用負荷で破綻しない。

Deal Pipelineは事業単位・取引タイプ単位で分ける。新規受注と既存顧客の追加販売を同じPipelineに入れると、Forecastと営業活動の優先順位が混線する。中小企業では、新規Pipeline／既存追加販売Pipeline／更新Pipelineの3本立て、または事業セグメント別の2〜3本が標準的な落とし所になる。

4. 自動化層：Workflow と AI機能の役割分担

自動化層を設計するとき、よくある誤りは「自動化＝Workflow、AI＝Breeze」と直訳的に分けることである。実務で効く分担軸は「決定論 vs 確率論」、つまり「ルールが書き切れる動き」と「ルールが書き切れない判断」のどちらに属するかである。決定論はWorkflow・Sequences・Lead Scoringが担い、確率論はBreeze・外部LLM API連携が担う。

具体的な切り分けの例を表で示す。

決定論側の自動化（Workflow・Sequences）は、ルールが明示できて結果が再現的であることが前提である。リードソース別ルーティング、SLAタイマー、フォロー漏れリマインドは、入力が同じなら出力も同じになる動きであり、Workflowの定義通りに動くことに価値がある。

確率論側の自動化（Breeze・外部LLM API）は、入力が同じでも出力に揺らぎがあることを前提に組む。議事録要約・メール下書き・失注理由分類は、AIが生成した結果を人が必ず一度見て確定する「ヒューマン・イン・ザ・ループ」を組み込まないと、誤った要約や見当外れの分類が下流に流れる。AIの出力を直接Workflowのトリガーに使うと、誤判定がそのまま自動化を駆動して傷口を広げる。

Breezeと外部LLM APIの使い分けは、(a) HubSpot内のデータで完結する処理はBreezeを優先（連携コストが低い）、(b) 自社固有の文脈（業界用語、過去提案資料、社内ナレッジ）を踏まえた生成は外部LLM API（Claude / ChatGPT API等）連携でカスタム実装、という軸で判断する。中小企業では、まずBreeze側で済む範囲を最大化し、外部LLM API連携は Month 3以降に必要性が確定してから着手する順序が現実的である。

5. 運用役割層：SDR / AE / CS / RevOps の境界をHubSpot上でどう敷くか

運用役割層は、SDR・AE・CSの境界をHubSpot上のビュー・パイプライン・自動化トリガーで実装する層である。役割定義のドキュメントだけでは運用に乗らない、というのが本層の核心命題である。組織論レベルの役割再定義は既存ホワイトペーパー「AI時代の営業組織の作り方」で扱っているため、本章ではHubSpot上の実装レベルに踏み込む。

実装レベルで具体的に何を作るかを、役割別に整理する。

SDRは「未接触リード」「初回SLA違反間近」「再アプローチ対象（前回接触から60日経過）」の3ビューを最初に整備する。これらのビューを開けば、その日触るレコードが優先順位順に並ぶ状態にしておく。新人SDRが入った初日でも、ベテランと同じビューを開いて同じ順序で動ける状態が、運用役割層の到達点である。

AEは「今週クローズ候補」「Stage停滞14日超」「失注理由未記入」を持つ。Stage停滞ビューは、Deal Stageが14日以上動いていないものを自動抽出する設計にする。失注理由未記入ビューは、CloseLostしたDealのうち失注理由プロパティが空のものを表示し、月次Forecast会議の前に必ず潰す運用にする。

CSは「契約更新60日前」「ヘルススコア低下」「アップセル候補」の3ビューが基本。中小企業では、CSが独立部署として存在しないケースも多いが、その場合でもCS用のビュー設計はAEとは分けて作る。AEのビューに更新管理を混ぜると、新規と既存の優先順位が混線する。

RevOpsは中小企業では専任を置きにくく、セールスマネージャーやマーケ責任者が兼務するのが現実解になる。兼務であっても「Pipeline全体俯瞰」「Forecast精度ダッシュボード」「データ品質チェック」の3ビューを月次で見る役割を1人に集約する。データ品質が見られていない組織は、3〜6ヶ月で必ず再びデータモデル層が崩れる。

6. AI組み込みの優先順位：3ヶ月で着手すべき3シナリオ

AIをHubSpotに組み込む際、最初の3ヶ月で着手するシナリオは3つに絞る。「議事録要約のDeal紐付け」「リードスコアリング再設計」「メール下書き生成」である。3シナリオの選定根拠は、(a) HubSpot上の既存オブジェクトに差し込み点が明確、(b) Month 2〜3で本番投入可能、(c) 効果が現場の体感として測れる、の3条件を同時に満たすことにある。

なぜこの3シナリオに絞るのか、HubSpotオブジェクトへの差し込み点で整理する。議事録要約はDealとContactに紐付く確率論的処理であり、商談プロセスを止めずに走らせられる。リードスコアリングはContactのプロパティ更新で完結し、SDRのビューに即時反映される。メール下書き生成はContactタイムラインの新規メール作成画面に差し込まれ、AEの日常動作の中で使われる。3つとも、新規にダッシュボードを作ったり、現場の動線を変えたりすることなく、既存のオブジェクト・既存の画面に組み込める点が共通する。

シナリオ1の議事録要約は、Zoom/Google Meetの録画をBreezeまたは外部LLM API連携で要約し、参加者のContact ID／関連DealのID／会話内容から推定される次アクション候補を構造化テキストとしてDeal Noteに自動書き込みする設計になる。Month 2の中盤に試験運用、Month 3の前半に本番投入が現実的なタイムラインである。要約結果は人が一度確認してから確定する運用にし、AI出力をそのままWorkflowのトリガーには使わない。

シナリオ2のリードスコアリング再設計は、既存のスコアリングルール（行動ポイント加算）を残しつつ、AIによる「過去受注パターンとの類似度」を補助スコアとして並走させる。SDRのビューには「ルールスコア順」と「AI補助スコア順」の2軸を表示し、両者がズレるContactを優先確認対象にする運用にする。スコアの完全置き換えは、データ蓄積が3〜6ヶ月分必要なため、3ヶ月では並走運用の確立までを目指す。

シナリオ3のメール下書き生成は、Contactタイムラインから新規メールを作成する際、過去ログ・関連Dealのプロパティ・自社のメッセージング方針を踏まえた下書きを生成する。Breezeのコンテンツ生成機能で基本対応し、業界用語や自社固有表現の精度が必要な層には外部LLM API連携を追加する。AEが下書きを編集してから送信する運用を必ず挟み、自動送信は当面採用しない。

3シナリオに絞ることで、Month 2〜3の実装容量に収まり、現場の学習コストも吸収できる。シナリオを5つ、6つと並走させると、どれも中途半端になり、本番投入が4ヶ月目以降にずれ込む。経験的には、3シナリオで「現場が3つ全部使える状態」を作る方が、5シナリオで「半分が使われていない状態」を作るより、6ヶ月後の運用継続率が高い。

7. 3ヶ月構築ロードマップ：Month 1〜3で揃うものと揃わないもの

3ヶ月構築ロードマップは「セールス基盤構築」（B02・3ヶ月）の標準パッケージに対応する。Month 1はデータモデル再設計、Month 2はWorkflowとAIシナリオの実装、Month 3は運用役割層の実装とSOP整備、という大枠の流れで進む。3ヶ月の終了時点で揃うのは「設計・初期実装・運用引き渡し」までであり、リード倍増や受注額急増は4〜6ヶ月の経過観察を経て見える指標である。

Month 1の前半（第1〜2週）は、現状のHubSpotデータモデル監査と、自社の商談プロセスに合わせたデータモデル再設計に充てる。Contact・Company・Deal・Custom Objectのプロパティ追加・統廃合、Deal Pipelineの再設計、Association Labelsの定義、データクレンジング方針の確定がこの2週間の成果物である。後半（第3〜4週）は、再設計したデータモデルへの既存データ移行と、初期データの品質確認に入る。データクレンジングは3〜6ヶ月相当の手間が掛かることがあり、Month 1では「以降の自動化が回せる最低品質」までを目標にする。

Month 2は、Workflowの整理・新規設計と、AIシナリオ3本のうち議事録要約・リードスコアリング再設計の実装フェーズである。既存Workflowの棚卸しと統廃合、新規Workflowの設計、Lead Scoringルールの再設定、Breeze/外部LLM API連携の初期設定がここで進む。Month 2の終了時点で、議事録要約は試験運用、リードスコアリング再設計は新旧並走運用の開始まで到達するのが目安となる。

Month 3は、運用役割層の実装と、メール下書き生成シナリオの追加、SOP（標準作業手順書）の整備、運用引き渡しに入る。SDR・AE・CSのビュー設計、Pipeline権限設定、通知・SLAルール、ダッシュボード構築がこの月の主要作業である。SOPには、各役割が日次・週次・月次で何を見るか、データ品質を誰が監視するか、AI出力が誤っていた場合のエスカレーション手順を含める。

3ヶ月終了時点で揃わないものを、別紙レベルで明示しておく。リード件数の倍増、受注額の前年同期比大幅増、AIシナリオの精度が現場経験者を超える状態、CS領域までを含む全社運用、Salesforce相当のカスタム開発機能、いずれもこの3ヶ月では揃わない。これらは4〜6ヶ月、領域によっては9〜12ヶ月の継続運用を経て見える成果である。3ヶ月の発注前に経営者・現場・パートナーで「揃わないもの」リストにサインしておく運用が、4ヶ月目以降の評価ズレを防ぐ。

8. Salesforce / 自社開発との比較判断軸：中小企業で残る選択肢

中小企業がHubSpotを継続強化するか、Salesforce移行を検討するか、自社開発に踏み込むかの判断は、製品比較ではなく「事業規模 × 営業組織人数 × データ複雑度」の3軸で行う。製品の優劣ではなく、自社の現在地と3年後の見通しに対する適合度の問題である。

3軸の判断基準を整理する。第一に営業組織人数。営業20名以下であれば、HubSpotのProfessional〜Enterpriseで実用上の機能不足は出にくい。30名を超えると、権限階層の細かさ・大規模ライセンス管理・複雑な承認フローへの要求が増え、Salesforceの土俵に近づく。第二にデータ複雑度。Dealと顧客の関係が1対1中心で、Custom Object数が3〜5個に収まるなら、HubSpotで十分にモデリングできる。多段階の親子関係、複数事業セグメントの統合管理、外部基幹システムとの密な連携が必須なら、Salesforceかカスタム開発の検討領域に入る。第三に事業成長角度。次の3年で事業規模が中堅企業帯まで一気に伸びる見通しが立っている場合、HubSpotで作った設計が早期に天井に当たるリスクを織り込む必要がある。

HubSpot継続強化が機能する条件を整理すると、(a) 営業20名以下、(b) Custom Object 3〜5個以内で済むデータ構造、(c) 次の3年で中堅企業帯までの一気拡大が見通しに入っていない、(d) マーケと営業の統合運用を重視、の4条件のうち3つ以上が当てはまる場合である。これらが揃っているとき、HubSpotの設計コストを早期に回収できる。一方、4条件のうち2つ以下しか当てはまらない場合は、Salesforce移行または独自開発の検討フェーズが現実的な選択肢として残る。

Salesforce移行を選ぶ場合、HubSpotで作ったデータモデルとWorkflowの大半を再設計するコストが発生する。経験的に、中小企業でSalesforce移行に踏み込んだ場合、初期構築費用と移行コストの合計はHubSpot継続強化の3〜5倍規模になりやすい。費用差を吸収できる事業成長見通しがあるかどうかが、移行判断の核心になる。自社開発（独自CRMの内製）は、エンジニア組織を社内に持つ事業会社でない限り、中小企業では運用負荷が現実的でないため、選択肢としての優先度は低い。

判断を保留する場合の中間解として、HubSpot継続強化で3ヶ月のアーキテクチャ構築を一度完了させ、その上で6〜12ヶ月運用しながらSalesforce移行の必要性を再評価する順序が成立する。3ヶ月の構築投資（B02）が将来の移行判断のときに無駄になるかというと、データモデル設計・運用役割定義・SOPはCRM製品を超えて移植できる資産であり、純粋な埋没コストにはならない。

9. 発注前の30分セルフチェック：自社のアーキテクチャ成熟度マップ

3ヶ月構築フェーズの発注前に、自社のアーキテクチャ成熟度を3層別に30分で棚卸しすると、構築の質が変わる。セルフチェックの目的は、自社のどの層から手を付けるかを発注前に見える化することと、ベンダーとの初回ミーティングで「うちはここから始めたい」と1分で説明できる状態を作ることである。

30分セルフチェックは3層それぞれに10分ずつ充てる。データモデル層の10分では、Deal Pipelineが何本あり、Stageが何個あり、各Stageに客観的なExit Criteriaが書かれているかを確認する。Contact・Company・Dealの主要プロパティ数と、Required Propertyの数を数える。Custom Objectの数と用途を一覧化する。この10分で「データモデルが商談プロセスを正しく写像しているか」の感触が掴める。

自動化層の10分では、稼働中のWorkflow数を数え、過去6ヶ月で誰が何のために作ったか説明できないWorkflowが何本あるかを確認する。Lead Scoringが運用されているか、最後にスコアリングルールを見直した時期を思い出す。Breezeまたは外部LLM API連携が現在どこで使われているかを書き出す。この10分で「自動化の見通しが効くか、無秩序に積み上がっているか」の判定がつく。

運用役割層の10分では、SDR・AE・CSの各担当者が日々HubSpotで開く主要ビューをヒアリングする。新人が入ったときに「最初に開くビュー」が固定されているか、ベテランが個人で作ったビューに依存していないかを確認する。Pipeline横断のForecast精度ダッシュボードと、データ品質チェックの責任者が誰かを書き出す。この10分で「役割定義がドキュメントだけで止まっているか、HubSpot上に実装されているか」が見える。

3層それぞれのチェック結果を「整備済／部分的／未着手」の3段階で評価し、未着手または部分的の層が複数あれば、その層がMonth 1〜3のどこに割り振られるかを発注前にベンダーと握る。経験的には、導入1〜2年の中小企業では、データモデル層が「部分的」、自動化層が「無秩序」、運用役割層が「未着手」というパターンが頻出する。この場合、Month 1の重点はデータモデル再設計、Month 2は自動化整理＋AI 2シナリオ、Month 3は運用役割実装＋メール下書きシナリオ、という標準ロードマップに自然に収まる。

30分セルフチェックを終えた経営者・セールス統括は、ベンダー初回ミーティングで「うちの3層成熟度はこう、Month 1〜3の重点はこう置きたい」と言える状態になる。この一言があるかどうかで、3ヶ月構築の最初の2週間が深まる度合いが変わる。発注後に同じ会話をすると、Month 1の前半が認識合わせに消える。

まとめ

• HubSpot導入済の中小企業で起きる「単なる顧客名簿」化は、データモデル・自動化・運用役割の3層が揃わないまま機能を増やしたことに起因する。3層を順序立てて揃え直すと、AIを乗せる土台が整う。
• AIはアーキテクチャの最上層に乗る単独機能ではなく、3層それぞれに分散して組み込むのが標準型である。Workflowは決定論、Breeze/外部LLM APIは確率論、という軸で分担する。
• 3ヶ月で着手するAIシナリオは「議事録要約のDeal紐付け」「リードスコアリング再設計」「メール下書き生成」の3本に絞る。シナリオを増やすと、本番投入が4ヶ月目以降にずれる。
• 3ヶ月で揃うのは「設計・初期実装・運用引き渡し」までであり、リード倍増や受注急増は4〜6ヶ月の経過観察を経て見える指標である。発注前に「揃わないもの」を明文化することが評価ズレを防ぐ。
• Salesforce移行とHubSpot継続強化は「営業組織人数・データ複雑度・事業成長角度」の3軸で判断する。中小企業・営業20名以下・データ構造がシンプルなら、HubSpot継続強化のROIが移行より高い局面が多い。

---

次のステップ: 3層アーキテクチャを3ヶ月で構築したい中小企業のセールス統括・経営者は、「セールス基盤構築」（B02・3ヶ月）で、HubSpotを中核としたAI連携のCRM/SFA基盤を設計・初期構築・運用引き渡しまで一気通貫で進められる。マーケ起点のリード獲得から仕組み化したい場合は、「マーケ基盤構築」（B03・3ヶ月）でMA / CRM連携とAIスコアリング基盤までの統合構築から入る選択肢もある。HubSpot導入そのものを判断保留中、または小規模なセールス組織の段階で診断から入りたい場合は、「業務診断パッケージ」（B01・1ヶ月）で営業・マーケ業務の棚卸しとAI自動化可能領域の優先度付けから始めることを推奨する。