本記事のポイント
「資料をダウンロードしただけの人まで営業に渡ってしまう」「スコアはあるのに、営業が信用していない」。humbulls が支援するなかで、リードスコアリングについてよく聞く悩みです。原因はデータ不足ではなく、MQL の定義より先に点数を付けていることにあります。
本記事では、Fit 40 点・Behavior 60 点の初期モデルを作り、HubSpot または Apps Script に実装するまでの型を解説します。特別な統計スキルは不要で、過去データと巻末の AI 実行キットがあれば、最初の配点表は 1 時間で作れます。
「料金ページを見たから 10 点、メールを開いたから 2 点。合計 50 点なら MQL でいいですか」。配点会議は、このように個別の行動から始まりがちです。
リードスコアリングとは、見込み客の属性と行動に点数を付け、営業が追う順番を揃える仕組みです。HubSpot の現行ツールでは、属性を見る Fit score、行動を見る Engagement score、両方を合わせる Combined score の 3 種類があります。
点数を付ける前に、「誰が、何をしたら営業へ渡すか」を 1 文にしてください。
たとえば、MQL を次のように定義します。
対象業界・従業員 50 名以上の企業に所属し、過去 30 日以内に料金ページを閲覧したか、相談フォームを送信した担当者
この 1 文には、Fit の条件が 2 つ、Behavior の条件が 1 つ入っています。先に定義があれば、点数は条件の重みを表すだけになります。MQL と SQL の境界がまだ言葉になっていない場合は、先に MQL と SQL の違いと定義 を決めてください。
よくある失敗は、100 点満点の表を先に作り、後から「50 点以上を MQL と呼ぶ」と決めることです。これでは高得点の理由と営業が追う理由が一致しません。MQL の文章を作り、その条件を点数へ翻訳する順番なら、営業にも説明できます。
→ MQL 定義から初期配点へ変換する作業は、巻末の 実行キット① で進められます。
「会社規模を重くするか、問い合わせを重くするかで議論が終わらない」。同じ 100 点の中で属性と行動を混ぜると、配点の根拠が見えなくなります。
最初は Fit 40 点、Behavior 60 点に分けると整理しやすくなります。HubSpot の既定スコア上限も 100 点で、Combined score では合計・Fit・Engagement の 3 つのプロパティを持てます。
以下は BtoB サービスを想定した初期モデル例です。HubSpot の公式推奨配点ではありません。
| Fit (最大 40 点) | 点数 | Behavior (最大 60 点) | 点数 |
|---|---|---|---|
| 対象業界に一致 | 10 | 相談・デモフォーム送信 | 25 |
| 従業員規模が対象範囲 | 10 | 料金ページを 30 日以内に閲覧 | 15 |
| 部門・役職が購買関与者 | 10 | 導入事例または料金資料を DL | 10 |
| 対象地域に所在 | 5 | ウェビナーに参加 | 5 |
| 利用中ツールが連携対象 | 5 | メール内リンクをクリック | 5 |
| 合計 | 40 | 合計 | 60 |
Behavior を 60 点にしたのは、行動が営業の優先順位へ直結しやすいからです。一方で Fit を 0 点にすると、対象外企業が資料を何度も見ただけで上位へ来ます。40 点を残すことで、「関心は高いが対象外」と「対象企業で関心も高い」を分けられます。
加点だけではなく、対象外を下げる減点も置きます。採用応募・競合・ベンダー営業は -30 点、メール配信停止は -10 点、といった形です。HubSpot も positive / negative points の両方に対応しています。
よくある失敗は、メール開封やページ閲覧を無制限に加点することです。同じ人が 10 回見ただけで点数が膨らみます。項目ごとの上限を決め、問い合わせや商談予約のような強い行動へ点数を寄せてください。
「合計 65 点なのに、営業が見ると対象外企業だった」。合計点だけを条件にすると、こうした逆転が起きます。
初期モデルでは、次の 3 条件をすべて満たしたときだけ MQL とします。
| リード | Fit | Behavior | 合計 | 判定 |
|---|---|---|---|---|
| A: 対象企業 + 相談フォーム | 30 | 35 | 65 | MQL |
| B: 対象外 + 行動多数 | 10 | 55 | 65 | 保留 |
| C: 対象企業 + 行動少数 | 35 | 15 | 50 | ナーチャリング |
| D: Fit・行動とも低い | 15 | 20 | 35 | 対象外 |
MQL は 50 点の人ではなく、Fit 20 点・Behavior 30 点・合計 50 点をすべて超えた人です。
この数値も初期値です。自社の平均単価、営業人数、月間リード数で変わります。
大事なのは、合計点だけで判定しないことです。
HubSpot の Combined score にある A1〜C3 の区分も、Fit と Engagement を別々に見る同じ考え方です。
よくある失敗は、MQL 件数を増やすために合計閾値だけを 50 から 40 へ下げることです。件数は増えても、低 Fit のリードが混ざれば営業の受け取り率は下がります。調整するときは Fit・Behavior・合計のどこが詰まっているかを分けて見ます。
→ 3 条件を含む初期配点表は、巻末の 実行キット① で作れます。
「配点に根拠が必要なのは分かる。でも分析担当者はいない」。ここで AI を使います。
必要なのは、過去の転換・未転換リードを同じ列で並べた表です。列は会社規模、業界、役職、流入元、主要ページ閲覧、フォーム送信、最終ステージなど。氏名・メールアドレスは分析に不要なので外します。
1 時間の使い方は次の通りです。
| 時間 | 作業 | 出力 |
|---|---|---|
| 0〜10 分 | MQL 定義と候補項目を渡す | Fit / Behavior の列分類 |
| 10〜25 分 | 転換・未転換データを整える | 欠損・表記ゆれの一覧 |
| 25〜45 分 | 両群の差を比較する | 転換群に偏る項目の候補 |
| 45〜60 分 | 40 / 60 点へ配分する | 初期配点表と根拠 |
AI に任せるのは、差の整理と配点案の作成までです。「この項目なら必ず転換する」と予測させる作業ではありません。件数が少ない場合は、根拠欄に「データ不足」と書かせ、担当者の仮説と分けます。
HubSpot の AI score は Marketing Hub Enterprise 限定で、最低 50 件、内訳は転換 25 件・未転換 25 件が必要です。この数字は AI score の利用条件であり、手動モデルの品質保証ラインではありません。50 件に満たないチームは、仮説モデルとして始めて 90 日の運用データで補います。
よくある失敗は、AI に点数だけを出させることです。「対象業界 +10」の横に、転換群と未転換群の件数差、採用理由、見直し条件まで出させます。根拠が読めない点数は、営業との会議で残りません。
→ 匿名化した表から配点根拠まで出す指示は、巻末の 実行キット① にまとめています。
「モデルはできた。でも今のプランではスコアリング画面が見つからない」。HubSpot の標準スコアは Marketing Hub Professional / Enterprise、または Sales Hub Professional / Enterprise が対象です。
プランによって実装を分けます。
| 環境 | 実装方法 | 更新 |
|---|---|---|
| HubSpot Professional / Enterprise | Combined score に property group と event group を設定 | HubSpot が履歴を含めて再計算 |
| HubSpot Starter | Sheets で Fit / Behavior / Total を計算し、Apps Script でカスタムプロパティへ書き戻す | time-driven trigger で日次更新 |
Professional 以上では、最初に 5〜10 件の既知リードを Test record で確認し、その後 Preview distribution で全体分布を見ます。上位 5% しか MQL にならない、または半数が MQL になるなら、ワークフローへつなぐ前に閾値を戻します。
Starter では lead_fit_score、lead_behavior_score、lead_total_score の 3 プロパティを作り、Sheets 側で計算します。
→ 日次同期は HubSpot を Apps Script で Sheets に同期 の構成をそのまま使えます。
Apps Script の time-driven trigger は自動実行できますが、指定時刻ぴったりではなく一定の時間帯で動きます。失敗時は作成者へ通知されるため、運用担当のアカウントで作成し、実行ログを月 1 回確認してください。
配点は 90 日間固定しません。次の順で補正します。
| 時点 | 見る数字 | 変更範囲 |
|---|---|---|
| 30 日 | MQL 件数・営業受け取り率 | 明らかな対象外条件の減点だけ追加 |
| 60 日 | MQL→SQL 転換・差し戻し理由 | Fit / Behavior の最低点を調整 |
| 90 日 | SQL→商談・受注との関係 | 各項目の配点と合計閾値を見直す |
行動の鮮度が落ちる項目には減衰を入れます。HubSpot は 1・3・6・12 ヶ月の間隔を選べるため、初期モデルではページ閲覧やメール反応を 3 ヶ月で減衰させ、相談フォームや商談予約は別ルールに分けます。
よくある失敗は、配点変更と営業フロー変更を同じ日に行うことです。原因が分からなくなるので、1 回の見直しで動かすのは配点・閾値・運用のどれか 1 つにします。自動通知や担当者割り当ては HubSpot ワークフロー活用例 を参考に、分布確認の後で接続してください。
→ 実装仕様書は巻末の 実行キット②、90 日の補正は 実行キット③ で進められます。
リードスコアリングは、細かな配点テクニックではなく、営業へ渡す理由を揃える仕組みです。MQL を 1 文で定義し、Fit 40 点・Behavior 60 点の初期モデルへ翻訳し、合計 50 点だけでなく Fit 20 点・Behavior 30 点も満たすようにします。ここまで決めれば、過去データの整理と配点案は AI で 1 時間に圧縮できます。
実装後の仕事は、30 / 60 / 90 日で営業の受け取りと商談化を見ながら補正することです。
リードを育てる前段の設計は リードナーチャリングの 5 ステップ、実装テンプレを含む全体像は BtoB マーケ AI 活用ガイド にまとめています。
まずはキット①へ過去データを貼り、初期配点表を作るところから始めてみてください。
本文の判断と実装を、そのまま AI で実行するためのキット集です。プロンプトは Claude (ブラウザ版で可) にコピペすれば動きます。
種別: 判断キット 使うもの: Claude (ブラウザ版で可。表が大きい場合は Claude Code) 事前に用意するもの: 転換・未転換リードを同じ列で並べた CSV または表。氏名・メールアドレスは削除し、会社規模 / 業界 / 役職 / 流入元 / 主要行動 / 最終ステージを残します。データがなければ、営業とマーケの会議メモでも始められます。
プロンプト:
リードスコアリングの初期配点表を作ってください。
【MQL の定義】
対象業界・従業員 50 名以上の企業に所属し、過去 30 日以内に
料金ページを閲覧したか、相談フォームを送信した担当者(記入例)
【過去データ】
(匿名化した CSV または表を貼り付ける。データがなければ
営業とマーケの会議メモを貼り付ける)
【分類・配点基準(必ずこの基準に従うこと)】
- 会社・担当者の属性は Fit、閲覧・送信・参加などの行動は Behavior
- 初期上限は Fit 40 点 / Behavior 60 点 / 合計 100 点
- MQL は Fit 20 点以上 AND Behavior 30 点以上 AND 合計 50 点以上
- 強い行動(相談・デモ・商談予約)を、弱い行動(開封・単純閲覧)より重くする
- 採用応募・競合・ベンダー営業・配信停止は減点候補にする
- データから差を確認できない項目は「データ不足」と書き、推測値と分ける
【出力】
1. Fit 配点表(項目 / 条件 / 点数 / 根拠 / 見直し条件)
2. Behavior 配点表(同じ列)
3. 減点表
4. MQL 閾値を満たす例 2 件、満たさない例 2 件
5. 営業と合意が必要な未確定事項
出力の確認ポイント:
うまくいかないとき:
種別: 実装キット 使うもの: Claude Code。HubSpot MCP がなければ、プロパティ一覧の CSV または画面スクショを入力にします 事前に用意するもの: キット①の配点表、契約中の HubSpot Hub とプラン、スコアに使う既存プロパティ一覧。
プロンプト:
次の配点表を HubSpot に実装する仕様書を作ってください。
【契約環境】
- Hub: Marketing Hub Starter(記入例。正式プランを書く)
- 更新頻度: 毎日 1 回(記入例)
- 配点表: (キット①の結果を貼り付ける)
【実装分岐(必ずこの基準に従うこと)】
A. Professional / Enterprise で標準 Lead Scoring が使える
→ Combined score、property group、event group、threshold を設計
B. Starter で標準 Lead Scoring が使えない
→ Google Sheets + Apps Script で計算し、lead_fit_score /
lead_behavior_score / lead_total_score の 3 property へ日次反映
【安全条件】
- 最初は既知の 5〜10 records だけで計算結果を確認する
- 全体分布の確認前に営業通知・担当者自動割り当てへ接続しない
- 同一行動の無制限加点を禁止し、項目ごとの上限を持たせる
- token / private app key はコードへ直書きしない
【出力】
1. 採用する実装分岐と理由
2. property / group / rule の一覧
3. テスト用 5 records と期待点数
4. 日次更新フロー
5. 公開前チェックとロールバック手順
出力の確認ポイント:
うまくいかないとき:
種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: MQL 一覧と、その後の営業受け取り / 差し戻し / SQL / 商談 / 受注の結果。件数だけでも動きます。
プロンプト:
リードスコアリングの補正案を作ってください。
【現在のルール】
- Fit 最低点: 20(記入例)
- Behavior 最低点: 30(記入例)
- 合計最低点: 50(記入例)
- 現在の配点表: (貼り付ける)
【運用結果】
(MQL / 営業受け取り / 差し戻し理由 / SQL / 商談 / 受注の表を貼る)
【補正基準(必ずこの順で判定すること)】
1. 対象外が混じる → 減点条件または Fit 最低点を見直す
2. 対象企業だが温度が低い → Behavior 最低点を見直す
3. 相談・商談予約が過小評価 → 強い行動の点数を見直す
4. 古い閲覧だけで高得点 → 1 / 3 / 6 / 12 ヶ月の減衰を検討する
5. 1 回の見直しで動かすのは配点・閾値・運用のどれか 1 種類だけ
【出力】
- 現状診断(データで言えること / 言えないことを分ける)
- 変更候補を優先順に最大 3 件
- 変更前後の判定例
- 次の 30 日に追う数字
- 変更を見送る条件
出力の確認ポイント:
うまくいかないとき: