B3. 汎用CRM（Hubspot等）の限界

Hubspot や Salesforce ── 汎用 CRM顧客管理システムは、直販を前提に設計された道具です。コンタクト（個人）と会社（企業）と商談（Deal商談・案件）を中心軸に置き、その周辺にメールや活動ログを紐付ける、というデータモデルが世界標準になっています。

この設計は直販には極めて優秀です。けれど、パートナーセールスに当てはめると、必要な構造の半分以上を持っていない、という事実が浮かび上がります。

業界登壇者が認める、汎用ツール運用の限界

SmartHR の清水氏は、業界の代表的なベンダーでありながら、運用の限界を率直に語っています。

我々もずっとそれ（スプレッドシート）でやってきて、ここ最近だと生成AIを使い始めています。パートナーさんの情報を貯める箱を作って、得られた情報をなるべく蓄積して、AIに分析させて、『このフェーズでこういうアプローチをしているけどうまくいかない、どうしたらいいか』みたいなことを聞く。いかに情報を貯めていくかが大事で、スプシで情報を集めている方も多いと思うんですが、それが属人化して陳腐化していくというところがある。しっかりデータベースを作るということが非常に大事。

— 清水健太氏（株式会社SmartHR パートナービジネス事業本部第2アライアンス営業部部長）出典：パートナービジネスのTier階層・重要度ランク戦略と組織攻略のリアル ― スマートドライブ×SmartHR（partnersales.biz セミナーレポート）

このコメントには、いま業界が直面している現実が凝縮されています。「汎用ツール（スプシ・生成 AI）でやっている」、しかし「属人化して陳腐化する」、だから「しっかりデータベースを作ることが大事」 ── この三段論法が、汎用 CRM の限界をそのまま示しています。

CRM のデータモデル：直販前提の3軸

汎用 CRM の中核は、極めてシンプルな3軸です。

汎用CRM の主要オブジェクト

Contact（コンタクト） 個人の連絡先情報。氏名、メール、電話、役職
Company（会社） 企業の属性情報。業種、規模、所在地
Deal（商談） 金額、ステージ、見込み確度

この3軸は、直販で「企業に対して個人にアプローチして商談を作る」モデルには完璧にフィットします。けれど、パートナーセールスは 4層構造（ベンダー → パートナー企業 → 担当者 → エンドユーザー）で動くため、企業と個人の関係が二重になります。3軸モデルでは、この二重性をうまく表現できないのです。

パートナーセールスに必要な、より多くの軸

パートナーセールスを科学的に運用しようとすると、3軸では足りません。少なくとも以下の軸が必要になります。

パートナーセールスに必要な軸

パートナー（会社）× コンタクト 会社単位ではなく、社員ひとりひとりが観測対象
熟達度レベル このプロダクトを売る能力がどの段階か（未熟・実績あり・チャンピオン）
活動レベル 直近の接触頻度・反応速度・提案数
役割バッジ 決裁者／メインカウンターパート／チャンピオン／案件創出者などの役割識別
チームパワー パートナー組織内で、自社プロダクトを推せる勢力の強度

これらは汎用 CRM の標準スキーマには存在しません。Hubspot で言えば、すべて「カスタムプロパティ」として手で増やしていく必要があります。

「Property を手で増やす」では追いつかない理由

実際の現場が、何をどこまで「手で」運用しているのか。スマートドライブの高田氏が、その手触りを生々しく語っています。

これはめちゃくちゃアナログです。スプレッドシートに、同行させていただいた方の何年卒か、その人の同期はどこにいるのか、極端に言えばその人の趣味とか、いろんな情報を蓄積するようにしています。

— 高田亮介氏（株式会社スマートドライブパートナーグループ統括部長）出典：パートナービジネスのTier戦略と組織攻略のリアル ― スマートドライブ×SmartHR（partnersales.biz セミナーレポート）

年次・同期関係・趣味 ── これらは、汎用 CRM の標準項目には絶対に載っていません。にもかかわらず、業界の最前線では「めちゃくちゃアナログ」に手作業で蓄積されているのが現実です。

ここに「Property を手で増やす」アプローチの構造的限界があります。

手作業カスタマイズの3つの限界

属人化 誰が何のために作った Property なのか、引き継ぎ時に消える
陳腐化 運用の変化に Property 設計が追いつかず、形骸化する
業界知見が乗らない パートナーセールスの実務知見（Tier 設計・キーマン分類）はベストプラクティスとして組み込まれていないため、すべてゼロから設計するしかない

業界横断の事実 ── Salesforce / Hubspot は単独で完結しない

2025 年 10 月のパートナーセールス質問会では、複数社が同じ実態を口にしました。

うちはSalesforceとスプレッドシートです。Salesforceで案件を管理して、スプレッドシートで手数料を計算しています。

— A社（パートナーセールス質問会 in 関西登壇企業）出典：パートナーセールス質問会 in 関西（partnersales.biz セミナーレポート）

うちはSalesforceです。手数料率なども全部入れて自動計算しています。

— C社（パートナーセールス質問会 in 関西登壇企業）出典：パートナーセールス質問会 in 関西（partnersales.biz セミナーレポート）

Salesforce を入れていても、必ず外側にスプレッドシート運用が漏れ出している ── これは、汎用 CRM 単独ではパートナーセールスの構造を保持しきれない、という業界全体の証言と読めます。「専用の構造を持っていないから、結局スプシに逃がす」という構図です。

この構図そのものが、清水氏の言う「属人化して陳腐化する」の発生源です。スプシに逃げた瞬間、データはサイロ化し、組織知になりません。

この章の含意

汎用 CRM の限界は、機能不足ではなく データモデルの守備範囲 です。直販を前提に設計されたスキーマに、パートナーセールスの 4 層構造、熟達度、役割バッジ、関係性シグナルを押し込もうとすれば、Property の手作業増設に追われ、結果として「属人化して陳腐化」します。

では、汎用 CRM に Claude CodeAnthropic 純正のコーディング AI 環境のような汎用 AI を組み合わせれば足りるのか？ ── この問いに正面から向き合うのが、次章のテーマです。

語句

CRMシー・アール・エム: Customer Relationship Management。顧客との関係を一元管理するシステム。Salesforce や HubSpot が代表。コンタクト・案件・商談を扱うが、パートナー構造は持たない。
Claude Codeクロード・コード: Anthropic が公開する Claude を使ったコーディング用ハーネスの代表例。汎用コーディング領域に特化した agentic harness。
Tierティア: パートナーを重要度別に分類する区分（Tier 1 / 2 / 3 など）。重点パートナー設計の基本概念。
Dealディール: 営業上の取引機会・案件。CRM・SFA で管理される基本単位。