リードスコアリングには大きく7つの手法がある。精度・導入コスト・データ要件がそれぞれ異なるため、自社のフェーズに合った手法を選ぶことが重要だ。
| # | 手法 | 精度 | 導入コスト | データ要件 | 推奨フェーズ |
|---|---|---|---|---|---|
| 1 | ルールベース(ポイント制) | 中 | 低 | CRMデータのみ | 全フェーズ / 初期導入 |
| 2 | Fit x Interest マトリクス | 中〜高 | 低 | 属性+行動データ | マーケ組織が成熟 |
| 3 | BANT スコアリング | 中 | 低 | ヒアリング情報 | アウトバウンド主体 |
| 4 | 行動検知型(トリガーベース) | 中〜高 | 中 | 行動ログ | Webトラフィックが多い |
| 5 | 予測スコアリング(機械学習) | 高 | 高 | 受注/失注1,000件+ | データ蓄積あり |
| 6 | LLMベーススコアリング | 高 | 中 | ICP定義+リード情報 | ICP頻繁変更 |
| 7 | PLGスコアリング | 高 | 中〜高 | プロダクト利用データ | PLGモデル企業 |
以下、各手法を詳細に解説する。計算ロジック、配点表、実装コードを含む。
最も基本的かつ広く使われている手法だ。リードの属性と行動に対してポイントを割り当て、合計点で優先度を判定する。計算ロジックは以下の通り。
総合スコア = Σ(属性スコア) + Σ(行動スコア) - Σ(減点スコア)
| 属性 | 条件 | スコア |
|---|---|---|
| 従業員規模 | 500人以上 | +15 |
| 100〜499人 | +10 | |
| 50〜99人 | +5 | |
| 役職 | 部長以上(Director+) | +15 |
| 課長・マネージャー | +10 | |
| 担当者 | +5 | |
| 業種 | ターゲット業種 | +10 |
| 準ターゲット業種 | +5 | |
| 所在地 | 主要都市圏(東京・大阪・名古屋) | +5 |
| 行動 | スコア | 根拠 |
|---|---|---|
| セミナー参加 | +30 | 時間投資=高い関心 |
| 価格ページ閲覧 | +20 | 予算検討の兆候 |
| 資料ダウンロード | +20 | 社内共有の可能性 |
| 事例ページ閲覧 | +15 | 導入検討段階 |
| 問い合わせフォーム送信 | +25 | 直接的なアクション |
| メール開封 | +5 | 低関与だが継続的関心 |
| メールリンククリック | +10 | 開封より高い関心 |
| 条件 | スコア | 理由 |
|---|---|---|
| 競合ドメインのメール | -1000 | 競合調査。営業対象外 |
| 個人メール(gmail等) | -10 | B2Bターゲット外の可能性 |
| 採用ページ閲覧 | -10 | 求職者の可能性 |
| 30日間無活動 | -15 | 関心の低下 |
| メール配信停止 | -20 | 接触拒否のシグナル |
| 分類 | スコア範囲 | アクション |
|---|---|---|
| ホット | 70〜100 | 即日架電。営業が直接対応 |
| ウォーム | 40〜69 | ナーチャリング継続。セミナー招待・事例送付 |
| コールド | 0〜39 | メール配信のみ。四半期ごとに再評価 |
SELECT
c.contact_id,
c.company_name,
c.email,
-- 属性スコア
CASE
WHEN c.employee_count >= 500 THEN 15
WHEN c.employee_count >= 100 THEN 10
WHEN c.employee_count >= 50 THEN 5
ELSE 0
END
+ CASE
WHEN c.job_title LIKE '%部長%' OR c.job_title LIKE '%Director%' THEN 15
WHEN c.job_title LIKE '%課長%' OR c.job_title LIKE '%Manager%' THEN 10
ELSE 5
END
+ CASE WHEN c.industry IN ('SaaS', 'IT', '製造業') THEN 10 ELSE 0 END
-- 行動スコア
+ COALESCE(e.seminar_count, 0) * 30
+ CASE WHEN e.pricing_page_views > 0 THEN 20 ELSE 0 END
+ COALESCE(e.downloads, 0) * 20
-- 減点スコア
- CASE WHEN c.email LIKE '%@competitor.com' THEN 1000 ELSE 0 END
- CASE WHEN c.email LIKE '%@gmail.com' THEN 10 ELSE 0 END
AS total_score
FROM contacts c
LEFT JOIN engagement_summary e ON c.contact_id = e.contact_id
WHERE c.lifecycle_stage = 'lead'
ORDER BY total_score DESC;
ルールベースを発展させた2軸評価モデルだ。Fit(適合度)は「その企業がターゲットか」、Interest(関心度)は「その企業が興味を示しているか」を独立して評価する。
LQS = (Engagement x 0.4) + (Fit x 0.3) + (Intent x 0.3)
数値例を示す。従業員300名のSaaS企業(Fit: 85)、セミナー参加+価格ページ閲覧(Engagement: 70)、競合比較記事を閲覧(Intent: 60)の場合:
LQS = (70 x 0.4) + (85 x 0.3) + (60 x 0.3) = 28.0 + 25.5 + 18.0 = 71.5
この場合、LQS 71.5はホット判定(70以上)となり、営業に即時引き渡しとなる。
BANTはBudget(予算)・Authority(決裁権)・Need(必要性)・Timeline(導入時期)の4軸でリードを評価するフレームワークだ。IBMが1960年代に開発し、今なお日本のB2B営業組織で最も浸透している。特にアウトバウンド主体の営業で威力を発揮する。
| 軸 | 高(25点) | 中(15点) | 低(5点) |
|---|---|---|---|
| Budget | 予算確保済み / 稟議通過 | 予算枠あり / 上申予定 | 予算未定 / 情報収集段階 |
| Authority | 最終決裁者と直接会話 | 決裁者に影響力あり | 担当者レベル / 決裁者不明 |
| Need | 明確な課題あり / 失注リスクが言語化 | 課題認識あり / 比較検討中 | 課題不明確 / 「とりあえず話を聞きたい」 |
| Timeline | 3ヶ月以内に導入予定 | 半年以内に検討 | 時期未定 / 来期以降 |
合計100点満点。60点以上で営業アプローチ対象。BANTの強みは、営業がヒアリング中にスコアを即座に判定できる点だ。CRMのカスタムフィールドに各軸のスコアを入力し、合計が自動計算される設計にすれば、営業担当のスコアリング作業は30秒で終わる。
BANTは日本の稟議文化と相性が良い。「Budget = 稟議が通っているか」「Authority = 誰のハンコが必要か」「Timeline = いつの予算で処理するか」は、日本の営業が日常的に確認している項目そのものだ。ただし、BANTは「リードが教えてくれた情報」に依存するため、虚偽申告や過剰見積もりのリスクがある点に注意が必要。
ポイントの合計ではなく、特定の行動パターンの検出をトリガーにして営業アクションを起動する手法だ。スコアが徐々に上がるのを待つのではなく、「この行動をしたら即座に対応」という設計思想。
| トリガー | 検知条件 | アクション |
|---|---|---|
| 価格ページ集中閲覧 | 価格ページを7日間で3回以上閲覧 | 営業に即時Slack通知。15分以内に架電 |
| 深掘りセッション | 1セッションで5ページ以上閲覧 + 滞在10分超 | パーソナライズドメール自動送信 |
| 再訪問 | 資料DL後72時間以内にサイト再訪問 | ISR(インサイドセールス)が架電 |
日本のMA(マーケティングオートメーション)ツール「ferret One」はこの手法を採用している。ポイント加算方式ではなく、「特定の行動シーケンスを検知したら通知」というイベント駆動型の設計だ。ルールベーススコアリングと組み合わせることで、「スコアは低いがホットなシグナルを出したリード」を見逃さなくなる。
ルールベースで全リードにベーススコアを付与しつつ、トリガーベースで「今まさに検討している」リードを即座に検知する。スコア40点(ウォーム)のリードでも、価格ページ3回閲覧のトリガーが発火すれば、即座にホット扱いに昇格する。
過去の受注・失注データを機械学習モデルに学習させ、新規リードのコンバージョン確率を予測する手法だ。人間がルールを定義するのではなく、データからパターンを自動抽出する。
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import StandardScaler
from sklearn.metrics import classification_report, roc_auc_score
# 特徴量設計: CRM + 行動データ
features = [
'employee_count', # 従業員数
'is_target_industry', # ターゲット業種フラグ
'job_title_level', # 役職レベル(1-5)
'page_views_total', # 総PV
'pricing_page_views', # 価格ページPV
'email_open_rate', # メール開封率
'days_since_last_visit', # 最終訪問からの日数
'content_downloads', # 資料DL数
'seminar_attendance', # セミナー参加回数
]
# データ準備
df = pd.read_csv('leads_with_outcomes.csv')
X = df[features]
y = df['converted'] # 1=受注, 0=失注
# 前処理
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)
X_train, X_test, y_train, y_test = train_test_split(
X_scaled, y, test_size=0.2, random_state=42, stratify=y
)
# 学習
model = LogisticRegression(class_weight='balanced')
model.fit(X_train, y_train)
# 評価
y_pred = model.predict(X_test)
y_proba = model.predict_proba(X_test)[:, 1]
print(classification_report(y_test, y_pred))
print(f"AUC-ROC: {roc_auc_score(y_test, y_proba):.3f}")
import xgboost as xgb
from imblearn.over_sampling import SMOTE
from sklearn.model_selection import GridSearchCV
import shap
# 不均衡データ対策: SMOTEでオーバーサンプリング
smote = SMOTE(random_state=42)
X_resampled, y_resampled = smote.fit_resample(X_train, y_train)
# ハイパーパラメータ探索
param_grid = {
'max_depth': [3, 5, 7],
'learning_rate': [0.01, 0.1, 0.3],
'n_estimators': [100, 300, 500],
'min_child_weight': [1, 3, 5],
}
grid = GridSearchCV(
xgb.XGBClassifier(eval_metric='logloss'),
param_grid,
cv=5,
scoring='roc_auc',
n_jobs=-1
)
grid.fit(X_resampled, y_resampled)
best_model = grid.best_estimator_
print(f"Best AUC: {grid.best_score_:.3f}")
# SHAP値で予測の根拠を可視化
explainer = shap.TreeExplainer(best_model)
shap_values = explainer.shap_values(X_test)
shap.summary_plot(shap_values, X_test, feature_names=features)
SHAP値は「なぜこのリードが高スコアなのか」を特徴量ごとに分解して説明する。営業に「このリードはスコア85です」と伝えるだけでなく、「従業員規模が大きく、価格ページを3回閲覧し、セミナーにも参加しているためです」と根拠を示せる。これが営業のスコアリングへの信頼を構築する。
| アルゴリズム | 精度 | 解釈性 | 学習速度 | 推奨ケース |
|---|---|---|---|---|
| ロジスティック回帰 | 中 | 高 | 速い | 初回導入。特徴量の寄与度を営業に説明したい |
| ランダムフォレスト | 高 | 中 | 普通 | 非線形パターンが多い。過学習を抑えたい |
| XGBoost | 最高 | 低(SHAP併用で中) | 普通 | 精度重視。データ1,000件以上ある |
| CatBoost | 最高 | 低(SHAP併用で中) | やや遅い | カテゴリ変数が多い(業種、地域等) |
HubSpot Predictive Lead Scoring(Enterprise以上)は、顧客100件+非顧客1,000件のデータがあれば自動的にモデルを構築する。特徴量の選択からモデルの更新まで完全自動だが、ブラックボックスであるため「なぜこのスコアなのか」の説明が難しい。
Salesforce Einstein Lead Scoringは10日ごとにモデルを自動リフレッシュする。Einsteinの強みは、Salesforceエコシステム内のあらゆるデータ(メール、電話ログ、活動履歴)を特徴量として利用できる点だ。ただしSalesforce Enterprise Edition以上が必要で、導入コストが高い。
ICP(理想顧客像)を自然言語で定義し、LLMに各リードの適合度を評価させるアプローチだ。ルールベースのif文の塊をメンテナンスする代わりに、ICPの記述を書き換えるだけでスコアリングロジックが変わる。
import anthropic
import json
client = anthropic.Anthropic()
icp_definition = """
理想顧客像(ICP):
- 従業員数 50-500名の B2B SaaS企業
- シリーズA以降の資金調達済み
- CRM(HubSpot or Salesforce)を導入済み
- 営業チームが5名以上
- 直近6ヶ月以内に営業関連の求人を出している
- 日本市場で事業展開中
"""
def score_lead(lead_data: dict) -> dict:
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=500,
messages=[{
"role": "user",
"content": f"""
以下のICP定義に対して、このリードの適合度を0-100で評価せよ。
スコアと理由をJSON形式で返せ。
ICP定義:
{icp_definition}
リード情報:
{json.dumps(lead_data, ensure_ascii=False)}
出力形式:
{{"score": 数値, "fit_reason": "適合理由", "risk": "懸念点", "next_action": "推奨アクション"}}
"""
}]
)
return json.loads(response.content[0].text)
# 使用例
lead = {
"company": "株式会社Example",
"employees": 120,
"industry": "B2B SaaS",
"funding": "Series B",
"crm": "HubSpot",
"sales_team_size": 8,
"recent_job_posts": ["セールスマネージャー", "ISR"]
}
result = score_lead(lead)
print(f"Score: {result['score']} - {result['next_action']}")
| 観点 | ルールベース | LLMベース |
|---|---|---|
| メンテナンス | 条件追加のたびにコード修正 | ICP定義テキストを書き換えるだけ |
| 柔軟性 | 構造化データのみ | 非構造データ(求人情報、ニュース等)も評価可能 |
| 再現性 | 完全に再現可能(決定論的) | 同一入力でも微差あり(temperature依存) |
| コスト | 計算コストほぼゼロ | 1リード約$0.002〜$0.01(モデルによる) |
| レイテンシ | ミリ秒 | 1〜3秒 |
コスト感として、Claude Sonnet 4.5でリード1件あたり約$0.003(入出力合計約1,000トークン)。月1,000件のリードを処理しても$3程度だ。精度とメンテナンス性を考慮すれば、十分に投資対効果がある。
PLG(Product-Led Growth)モデルの企業では、プロダクトの利用データがスコアリングの最も強力なシグナルになる。フリートライアルやフリーミアムの利用状況から、有料化・アップセルの確度を予測する。
| 行動 | スコア | シグナル |
|---|---|---|
| フリートライアル開始 | +20 | プロダクトへの関心 |
| コア機能3回以上使用 | +30 | Aha Momentに到達 |
| チームメンバー招待 | +40 | 組織内での展開意思 |
| 使用量80%超過(プラン上限) | +50 | アップグレードのニーズ |
| インテグレーション設定 | +25 | 既存ツールスタックへの組み込み |
| 7日連続ログイン | +35 | 習慣化 = 高いスイッチングコスト |
PLGスコアリングの鍵はPQL(Product-Qualified Lead)の定義だ。MQL(Marketing-Qualified Lead)が「マーケ施策に反応したリード」であるのに対し、PQLは「プロダクトを実際に使い、価値を体感したリード」を指す。Slack、Zoom、Notionなどの急成長SaaSはすべてPQLベースのスコアリングを採用している。
PLGスコアリングは他の手法と排他的ではない。フリートライアル開始時にルールベースで属性スコアを付与し、プロダクト利用データでPLGスコアを加算し、合計スコアで営業アプローチのタイミングを判断する「ハイブリッドモデル」が現実的だ。
スコアリング設計で最も見落とされがちな要素がスコア減衰だ。3ヶ月前にセミナーに参加したリードと、昨日参加したリードを同じスコアで扱うのは合理的ではない。時間の経過とともにスコアを自動的に下げる仕組みが必要だ。
Decayed Score = Original x (1 - rate)months
rate = 月次減衰率(例: 0.15 = 月15%減衰)
| 経過期間 | 減衰率 | 例: 元スコア80 |
|---|---|---|
| 0〜30日 | 減衰なし | 80 |
| 31〜60日 | -10% | 72 |
| 61〜90日 | -30% | 56 |
| 91〜180日 | -50% | 40 |
| 181〜365日 | -80% | 16 |
| 366日以上 | リセット | 0 |
from datetime import datetime, timedelta
def apply_decay(original_score: float, last_activity: datetime) -> float:
"""段階的減衰モデルでスコアを減衰させる"""
days_elapsed = (datetime.now() - last_activity).days
decay_rules = [
(30, 1.0), # 30日以内: 減衰なし
(60, 0.9), # 31-60日: -10%
(90, 0.7), # 61-90日: -30%
(180, 0.5), # 91-180日: -50%
(365, 0.2), # 181-365日: -80%
]
for threshold, multiplier in decay_rules:
if days_elapsed <= threshold:
return round(original_score * multiplier, 1)
return 0.0 # 365日超過: リセット
# バッチ処理: 全リードのスコアを日次で減衰適用
def batch_decay_scores(leads: list[dict]) -> list[dict]:
return [
{
**lead,
'decayed_score': apply_decay(
lead['score'],
lead['last_activity_at']
)
}
for lead in leads
]
減衰処理は日次バッチで実行するのが一般的だ。n8nやCronジョブで毎朝6時にスコアを再計算し、CRMに書き戻す。HubSpotのWorkflowでも減衰ロジックを組めるが、複雑な段階的減衰はPythonスクリプトで実装したほうが保守性が高い。
スコアリングの導入は比較的簡単だが、運用で失敗するケースが多い。以下の7つのアンチパターンに注意すること。
| タイミング | 実施内容 |
|---|---|
| 月次 | スコア分布の確認。ホット/ウォーム/コールドの比率が偏っていないか検証 |
| 四半期 | 受注/失注データとスコアの相関分析。配点ルールの調整。閾値の見直し |
| 即時 | ICPの変更時(ターゲット業種の追加/除外)。新しいマーケティングチャネル開設時 |
自社の状況に合った手法を選ぶための判定フローを示す。
どのルートを選んでも、ルールベース(手法1)は必ず土台として残る。他の手法はルールベースを「置き換える」のではなく「補強する」ものだ。段階的に導入し、データが蓄積されたらより高度な手法に移行する。
リードスコアリングはGTMエンジニアリングの根幹をなす技術だ。7つの手法はそれぞれ適用場面が異なるが、すべてに共通する原則は以下の3つ。