sue@blog ~ /posts/lead-scoring-methods
$ cd ../
$ cat post.metadata

リードスコアリング完全ガイド
7つの手法と実装パターン

date: 2026-04-05 GTM Engineer Lead Scoring Automation AI
リードスコアリングとは、見込み顧客に対して属性情報と行動データに基づくスコアを付与し、商談化の確度を数値化する手法だ。営業が「全リードに均等に時間を使う」非効率を排除し、高確度のリードに集中するための仕組みであり、GTMエンジニアのコア業務の一つである。本記事では7つのスコアリング手法を比較し、SQLから機械学習、LLMまで実装コード付きで解説する。

7つのスコアリング手法 — 全体マップ

$ cat scoring-overview.md

リードスコアリングには大きく7つの手法がある。精度・導入コスト・データ要件がそれぞれ異なるため、自社のフェーズに合った手法を選ぶことが重要だ。

# 手法 精度 導入コスト データ要件 推奨フェーズ
1 ルールベース(ポイント制) CRMデータのみ 全フェーズ / 初期導入
2 Fit x Interest マトリクス 中〜高 属性+行動データ マーケ組織が成熟
3 BANT スコアリング ヒアリング情報 アウトバウンド主体
4 行動検知型(トリガーベース) 中〜高 行動ログ Webトラフィックが多い
5 予測スコアリング(機械学習) 受注/失注1,000件+ データ蓄積あり
6 LLMベーススコアリング ICP定義+リード情報 ICP頻繁変更
7 PLGスコアリング 中〜高 プロダクト利用データ PLGモデル企業

以下、各手法を詳細に解説する。計算ロジック、配点表、実装コードを含む。


手法1 — ルールベース(ポイント制)スコアリング

$ cat method-1-rule-based.md

最も基本的かつ広く使われている手法だ。リードの属性と行動に対してポイントを割り当て、合計点で優先度を判定する。計算ロジックは以下の通り。

計算式

総合スコア = Σ(属性スコア) + Σ(行動スコア) - Σ(減点スコア)

属性スコア(Firmographic)

属性 条件 スコア
従業員規模500人以上+15
100〜499人+10
50〜99人+5
役職部長以上(Director+)+15
課長・マネージャー+10
担当者+5
業種ターゲット業種+10
準ターゲット業種+5
所在地主要都市圏(東京・大阪・名古屋)+5

行動スコア(Behavioral)

行動 スコア 根拠
セミナー参加+30時間投資=高い関心
価格ページ閲覧+20予算検討の兆候
資料ダウンロード+20社内共有の可能性
事例ページ閲覧+15導入検討段階
問い合わせフォーム送信+25直接的なアクション
メール開封+5低関与だが継続的関心
メールリンククリック+10開封より高い関心

減点スコア(Negative)

条件 スコア 理由
競合ドメインのメール-1000競合調査。営業対象外
個人メール(gmail等)-10B2Bターゲット外の可能性
採用ページ閲覧-10求職者の可能性
30日間無活動-15関心の低下
メール配信停止-20接触拒否のシグナル

リード分類閾値

分類 スコア範囲 アクション
ホット70〜100即日架電。営業が直接対応
ウォーム40〜69ナーチャリング継続。セミナー招待・事例送付
コールド0〜39メール配信のみ。四半期ごとに再評価
SQLルールベーススコアリングの実装
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 x Interest マトリクス

$ cat method-2-fit-interest.md

ルールベースを発展させた2軸評価モデルだ。Fit(適合度)は「その企業がターゲットか」、Interest(関心度)は「その企業が興味を示しているか」を独立して評価する。

2軸4象限

Interest 高 | D: 低Fit | A: 高Fit 高Interest| 高Interest ─ 様子見 ─|─ 即アプローチ ─ ─────────────┼─────────────── Fit ─ 放置 ── |─ 育成対象 ── C: 低Fit | B: 高Fit 低Interest| 低Interest | Interest 低

統合スコア計算式

LQS(Lead Qualification Score)

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以上)となり、営業に即時引き渡しとなる。


手法3 — BANT スコアリング

$ cat method-3-bant.md

BANTはBudget(予算)Authority(決裁権)Need(必要性)Timeline(導入時期)の4軸でリードを評価するフレームワークだ。IBMが1960年代に開発し、今なお日本のB2B営業組織で最も浸透している。特にアウトバウンド主体の営業で威力を発揮する。

高(25点) 中(15点) 低(5点)
Budget 予算確保済み / 稟議通過 予算枠あり / 上申予定 予算未定 / 情報収集段階
Authority 最終決裁者と直接会話 決裁者に影響力あり 担当者レベル / 決裁者不明
Need 明確な課題あり / 失注リスクが言語化 課題認識あり / 比較検討中 課題不明確 / 「とりあえず話を聞きたい」
Timeline 3ヶ月以内に導入予定 半年以内に検討 時期未定 / 来期以降

合計100点満点。60点以上で営業アプローチ対象。BANTの強みは、営業がヒアリング中にスコアを即座に判定できる点だ。CRMのカスタムフィールドに各軸のスコアを入力し、合計が自動計算される設計にすれば、営業担当のスコアリング作業は30秒で終わる。

日本のB2Bとの相性

BANTは日本の稟議文化と相性が良い。「Budget = 稟議が通っているか」「Authority = 誰のハンコが必要か」「Timeline = いつの予算で処理するか」は、日本の営業が日常的に確認している項目そのものだ。ただし、BANTは「リードが教えてくれた情報」に依存するため、虚偽申告や過剰見積もりのリスクがある点に注意が必要。


手法4 — 行動検知型(トリガーベース)

$ cat method-4-trigger-based.md

ポイントの合計ではなく、特定の行動パターンの検出をトリガーにして営業アクションを起動する手法だ。スコアが徐々に上がるのを待つのではなく、「この行動をしたら即座に対応」という設計思想。

主要トリガーパターン

トリガー 検知条件 アクション
価格ページ集中閲覧 価格ページを7日間で3回以上閲覧 営業に即時Slack通知。15分以内に架電
深掘りセッション 1セッションで5ページ以上閲覧 + 滞在10分超 パーソナライズドメール自動送信
再訪問 資料DL後72時間以内にサイト再訪問 ISR(インサイドセールス)が架電

日本のMA(マーケティングオートメーション)ツール「ferret One」はこの手法を採用している。ポイント加算方式ではなく、「特定の行動シーケンスを検知したら通知」というイベント駆動型の設計だ。ルールベーススコアリングと組み合わせることで、「スコアは低いがホットなシグナルを出したリード」を見逃さなくなる。

ルールベースとの併用パターン

ルールベースで全リードにベーススコアを付与しつつ、トリガーベースで「今まさに検討している」リードを即座に検知する。スコア40点(ウォーム)のリードでも、価格ページ3回閲覧のトリガーが発火すれば、即座にホット扱いに昇格する。


手法5 — 予測スコアリング(機械学習)

$ cat method-5-predictive.md

過去の受注・失注データを機械学習モデルに学習させ、新規リードのコンバージョン確率を予測する手法だ。人間がルールを定義するのではなく、データからパターンを自動抽出する

scikit-learn ロジスティック回帰

Pythonロジスティック回帰による予測スコアリング
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}")

XGBoost + SMOTE + SHAP

PythonXGBoostによる高精度予測スコアリング
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併用で中) やや遅い カテゴリ変数が多い(業種、地域等)

CRMプラットフォームの予測スコアリング

HubSpot Predictive Lead Scoring(Enterprise以上)は、顧客100件+非顧客1,000件のデータがあれば自動的にモデルを構築する。特徴量の選択からモデルの更新まで完全自動だが、ブラックボックスであるため「なぜこのスコアなのか」の説明が難しい。

Salesforce Einstein Lead Scoringは10日ごとにモデルを自動リフレッシュする。Einsteinの強みは、Salesforceエコシステム内のあらゆるデータ(メール、電話ログ、活動履歴)を特徴量として利用できる点だ。ただしSalesforce Enterprise Edition以上が必要で、導入コストが高い。


手法6 — LLMベーススコアリング

$ cat method-6-llm.md

ICP(理想顧客像)を自然言語で定義し、LLMに各リードの適合度を評価させるアプローチだ。ルールベースのif文の塊をメンテナンスする代わりに、ICPの記述を書き換えるだけでスコアリングロジックが変わる

PythonLLMベーススコアリング
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程度だ。精度とメンテナンス性を考慮すれば、十分に投資対効果がある。


手法7 — PLGスコアリング(Product-Led Growth)

$ cat method-7-plg.md

PLG(Product-Led Growth)モデルの企業では、プロダクトの利用データがスコアリングの最も強力なシグナルになる。フリートライアルやフリーミアムの利用状況から、有料化・アップセルの確度を予測する。

PLGスコアリング要素

行動 スコア シグナル
フリートライアル開始 +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 + Sales-Led のハイブリッド

PLGスコアリングは他の手法と排他的ではない。フリートライアル開始時にルールベースで属性スコアを付与し、プロダクト利用データでPLGスコアを加算し、合計スコアで営業アプローチのタイミングを判断する「ハイブリッドモデル」が現実的だ。


スコア減衰(Score Decay)の設計

$ cat score-decay.md

スコアリング設計で最も見落とされがちな要素がスコア減衰だ。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
Pythonスコア減衰の実装
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スクリプトで実装したほうが保守性が高い。


よくある失敗パターン

$ cat anti-patterns.md

スコアリングの導入は比較的簡単だが、運用で失敗するケースが多い。以下の7つのアンチパターンに注意すること。

  1. データ品質の無視 — CRMに重複レコード、欠損値、古いデータが放置されたままスコアリングを導入する。ゴミデータにスコアを付けても、出力もゴミだ。スコアリング導入前にデータクレンジングを必ず実施する
  2. 過度な複雑化 — 初期段階で50項目の配点表を設計する。運用に入ると誰もメンテナンスできなくなる。最初は10項目以内で始め、四半期ごとに項目を見直す
  3. 静的モデルの放置 — 一度作ったスコアリングモデルを半年以上更新しない。市場環境もICPも変化する。最低でも四半期に1回はモデルの精度を検証し、配点を調整する
  4. 営業不参加の設計 — マーケティングチームだけでスコアリングを設計する。営業が「このスコア、信用できない」と感じた時点で破綻する。設計段階から営業チームを巻き込み、閾値と配点を共同で決定する
  5. 一律モデルの適用 — エンタープライズとSMBを同じモデルで評価する。購買プロセスが根本的に異なるため、セグメント別にスコアリングモデルを分ける必要がある
  6. 減衰の未設定 — スコアが一方的に加算されるだけで減衰しない。2年前にセミナーに参加しただけのリードがホットリストに残り続け、営業の優先度判断が崩壊する
  7. 購買委員会の無視 — 日本のB2B購買はチェンピオン(推進者)だけでは決まらない。稟議・合議で複数の意思決定者が関与する。コンタクト単位ではなく、アカウント単位でのスコアリング(同一企業からの複数コンタクトのスコアを集約)を検討する

メンテナンス頻度の推奨

タイミング 実施内容
月次 スコア分布の確認。ホット/ウォーム/コールドの比率が偏っていないか検証
四半期 受注/失注データとスコアの相関分析。配点ルールの調整。閾値の見直し
即時 ICPの変更時(ターゲット業種の追加/除外)。新しいマーケティングチャネル開設時

どの手法を選ぶか — 判定フローチャート

$ cat decision-flowchart.md

自社の状況に合った手法を選ぶための判定フローを示す。

Q1: リード数は月100件以上あるか? ├── No → ルールベース(手法1) で十分。まず始めることが重要 └── Yes → Q2へ Q2: 営業はアウトバウンド主体か? ├── Yes → BANT(手法3) + ルールベースの併用 └── No → Q3へ Q3: PLGモデル(フリートライアル/フリーミアム)があるか? ├── Yes → PLGスコアリング(手法7) + ルールベース └── No → Q4へ Q4: 受注/失注データが1,000件以上蓄積されているか? ├── Yes → 予測スコアリング(手法5) └── No → Q5へ Q5: ICPが頻繁に変わる、または非構造データが多いか? ├── Yes → LLMベース(手法6) └── No → Fit x Interest(手法2) + トリガーベース(手法4)

どのルートを選んでも、ルールベース(手法1)は必ず土台として残る。他の手法はルールベースを「置き換える」のではなく「補強する」ものだ。段階的に導入し、データが蓄積されたらより高度な手法に移行する。


まとめ

$ cat summary.md

リードスコアリングはGTMエンジニアリングの根幹をなす技術だ。7つの手法はそれぞれ適用場面が異なるが、すべてに共通する原則は以下の3つ。

  1. 営業と共同設計する — マーケだけで作ったスコアリングは使われない
  2. 小さく始めて改善する — 初期は10項目以内のルールベースで十分
  3. 定期的に検証する — スコアと受注実績の相関を四半期ごとに確認する
関連記事

Related Posts

$ _