--- title: "リードクオリフィケーションとは？選別基準の作り方と却下・失格の設計" url: "https://www.issoh.co.jp/column/details/7029/" published: 2025-05-30 updated: 2026-10-20 categories: ["マーケティング"] publisher: "株式会社一創" --- # リードクオリフィケーションとは？選別基準の作り方と却下・失格の設計 リードクオリフィケーションは、集めた見込み顧客のうち今どれを営業に渡すかを決める工程です。ところが多くの現場では「スコアが一定点を超えたら渡す」という一行のルールだけが決まっていて、渡した後に営業が受け取りを拒んだときの扱いも、接触してみて脈が無かったときの扱いも決まっていません。選別の精度はここで落ちます。この記事では工程上の位置づけから、選別基準を作る手順、却下と失格の切り分け、MAツールで自動化するときの前提条件までを整理します。 ## まとめ：リードクオリフィケーションの要点 - リードクオリフィケーションは、獲得（リードジェネレーション）と育成（リードナーチャリング）の後段に置く選別工程で、判定の主体はマーケティング側にあります。 - 選別基準は「ターゲット市場の定義 → 属性・行動シグナル → 対話での確認項目 → 閾値と運用ルール」の順で作ります。閾値から決めると、基準が件数目標に合わせて動きます。 - 営業が受け取りを拒む「却下（reject）」と、接触したうえで見送る「失格（disqualify）」は別物です。旧SiriusDecisionsは却下理由を procedural・clerical・definitional の3系統に整理しています。 - MAツールのスコアリング自動化には前提条件があります。HubSpotのAIリードスコアは Marketing Hub Enterprise 限定で、コンバージョン済み25件・未コンバージョン25件の計50件が最低サンプルです。 - 閾値を上げても受注確度が高まるとは限らず、有望なリードを除外すると商談機会を失います。基準を厳しくする前に、却下理由の内訳を確認してください。 ## リードクオリフィケーションの定義と工程上の位置 リードクオリフィケーションとは、獲得済みのリードが営業に引き渡す条件を満たしているかを判定し、満たすものだけを選び出す工程を指します。英語の qualify は「資格を与える・条件を満たすと認める」という意味で、判定そのものが工程の名前になっています。選別された結果のリードは[クオリファイドリード](https://www.issoh.co.jp/column/details/7250/)と呼ばれ、工程を指す語と結果を指す語は区別して使います。 ### リードジェネレーション・リードナーチャリングとの役割分担 3つの工程は目的が違います。[リードジェネレーション](https://www.issoh.co.jp/column/details/7032/)は接点を作って連絡先を得る段階、リードナーチャリングは関心度を引き上げる段階、リードクオリフィケーションは引き上がったかどうかを判定する段階です。判定だけを取り出して工程名にしている点が特徴で、ここで基準を満たさなかったリードのうち、対象顧客に合い、検討時期が早いものは育成側へ戻します。戻す先が用意されていない運用は、判定を厳しくするほどリードを失います。 工程を段数で管理するモデルとしては、旧SiriusDecisionsの[デマンドウォーターフォール](/column/details/7294/)が広く使われています。獲得から受注までを段に分け、段と段の間で必ず誰かが受け渡しの可否を判断する構造になっています。 ### クオリファイドリード・MQL・SQLとの関係 判定の主体が変わると呼び名が変わります。マーケティングが判定したものが[MQL（Marketing Qualified Lead）](https://www.issoh.co.jp/column/details/5160/)、営業が受け取って商談化の見込みありと認めたものが[SQL（Sales Qualified Lead）](/column/details/7250/)です。本記事では、リードクオリフィケーションのうちMQLとして営業へ引き渡す工程を中心に扱います。営業側の適格性確認も含む用法があるため、自社で各段階の責任範囲を合意してください。MQL・SQL・PQLといった分類そのものの違いは[クオリファイドリードの解説記事](https://www.issoh.co.jp/column/details/7250/)で整理しています。 ## 選別基準を作る4段階の手順 基準づくりは順番が結果を左右します。スコアの配点から着手すると、点数が先にあって「何点なら渡すか」を後から会議で決めることになり、期末の件数不足のたびに閾値が動きます。次の順で固定してください。 ### 1\. ターゲット市場の定義と営業部門との合意 業種・従業員規模・部署・役職など、自社の対象顧客の条件を文章にします。Adobe Marketo Engageの設計ガイドは、直近の受注案件の属性分析と営業への聞き取りを挙げています。この定義が無いと、後段の判定はすべて「熱量が高いかどうか」だけになり、売れない相手の熱量を拾い続けます。定義は営業側と合意し、合意した日付を残してください。製品ラインが増えたときに見直す起点になります。 ### 2\. 属性・行動シグナルの選定 属性は企業規模や役職といった顧客側の特性、行動は資料請求やセミナー参加といった活動の履歴です。属性はフォームでの申告だけでなく、営業が商談で確認した情報からも埋まります。Adobe Marketo Engage の設計ガイドも、引き渡し判定は「behavioral scoring、demographic scoring、またはその両方の最低限で決められる」と記しています。片方だけで運用すること自体は否定されていませんが、属性だけだと今買う理由が見えず、行動だけだと買えない相手を拾います。 ### 3\. BANT・MEDDICによる対話項目の整理 記録に残らない情報は、インサイドセールスや営業が会話で確かめます。よく使われるBANTについて、IBMの製品ドキュメントは「Budget, Authority, Need and Timeline (BANT)」と4要素を明記しています。より項目の細かいMEDDICは、提供元のMEDDICCによれば1996年にPTC社内でDick Dunkel氏がJack Napoli氏と共に考案したもので、Metrics、Economic Buyer、Decision Criteria、Decision Process、Identify Pain、Championの6要素で構成されます。 ここで立場を明確にしておきます。BANTが機能するかどうかは、獲得経路でも接触回数でもなく、相手の検討がどこまで具体化しているかで決まります。Salesforceの解説も、この枠組みは既に自社と取引したいと考えているリードを主に扱う場合に検討するものとしたうえで、そうでない相手には押しが強く自社都合に寄って見えると注意しています。資料を1本ダウンロードした段階の相手に予算を尋ね、「未定」と返ってきたことだけを根拠に落とすと、育成すれば取れた相手を落とします。項目数の多いMEDDICは、高単価で決裁者が多い案件の進行管理に向きます。 ### 4\. 引き渡し閾値と運用ルールの設定 1から3が固まって初めて、何点以上を渡すか、何日で判定するかを決めます。配点そのものの設計は[リードスコアリング](/column/details/5160/)と[配点・減点の設計](/column/details/5160/)の領域なので、ここでは引き渡し後の対応期限・担当者・差し戻し先まで合意します。Adobe Marketo Engageの設計ガイドも、データが蓄積するたびにスコアと閾値を見直すよう説明しています。閾値を動かすときは、動かした理由と日付を残します。 ## 却下と失格の切り分けと理由コードの設計 選別を「渡す・渡さない」の二値だけで管理すると、差し戻しの原因が分かりません。営業へ渡した後の判断と理由も記録してください。旧SiriusDecisionsは、渡した後に起きる差し戻しを2種類に分けて設計するよう求めています。 ### 却下（reject）は営業が接触する前の差し戻し MQLとして渡したものを営業が受け取らない判断が却下です。SiriusDecisionsの記事「Marketing Qualified Leads: Reasons for Rejection」（2013年1月8日・Jay Famico氏）は、却下してよい理由を procedural（ルーティングの誤り）、clerical（レコードの不備や不正確さ）、definitional（対象市場・活動・リードレベルの閾値を満たさない）の3系統に整理しています。実際に使う選択肢としては、担当の手が空いていない、連絡先情報の欠落、割り当て先の誤り、データの不正確、既に別案件で接触中、MQL定義を満たさない、その他、が挙げられています。 同記事は「その他」の扱いにも触れており、導入初期は受け皿として置き、数か月運用して共通項が見つかれば新しい分類を作り、その後は段階的に廃止するという運用を示しています。理由の選択肢を増やしすぎると営業が選ばなくなるため、数は絞るよう明記されています。 ### 失格（disqualify）は接触した後の判断 営業が対応対象として受け入れたリードをSAL（Sales Accepted Lead）と呼びます。営業が接触を試み、そのうえで見送る判断が、この節で扱う失格です。Forresterの記事「Sales Accepted Leads: Disqualification Reasons」（2012年12月18日）は「disqualification can only occur after qualification attempts have been made」と述べ、接触の試行前に失格を付けることを明確に否定しています。示されている理由は、接触不能、データ不正確、関心や必要性が無い、予算が無い、要件が合わない、購入時期がX か月より先、決裁権が無い、その他の8種です。 この8種のうち予算・決裁権・必要性・時期の4つは、BANTの4要素と裏表の関係にあります。つまりBANTは「満たすものを選ぶ基準」であると同時に「満たさない理由を記録する分類」としても機能します。同記事は、マーケティング側が再育成を起動できない値を選択肢に入れてはならないとも述べています。落ちた理由が「予算が無い」なのか「時期が先」なのかで、次に打つ施策は変わるためです。 | 観点 | 却下（reject） | 失格（disqualify） | | ----- | --------------------- | --------------------- | | 判定の時点 | 営業が接触する前 | 接触を試みた後 | | 対象の段 | MQLからSALへ | SALからSQLへ | | 主な理由 | ルーティング誤り・レコード不備・定義不適合 | 接触不能・予算無し・時期尚早・要件不一致 | | 次の打ち手 | 割り当て直し・データ補完・定義の見直し | 理由に応じて再育成・データ補正・対象外管理 | 差し戻しの受け口を[インサイドセールス](https://www.issoh.co.jp/column/details/15250/)に置くか営業に置くかは組織によりますが、どちらにせよ理由コードを必須入力にしないと記録が残らず、翌期も同じ基準のまま運用が続きます。 ## MAツールとCRMで自動化するときの前提条件 「MAツールを導入すれば選別が自動化できる」という説明は、条件を落としています。スコアリング機能には利用プランの条件があり、一部のAIスコアには学習用データ件数の条件もあります。 ### HubSpotの利用条件とAdobe Marketo EngageのMQL定義 HubSpotのリードスコアはプロパティ値とイベント行動に点数を付ける仕組みで、利用できるのは Marketing Hub Professional／Enterprise と Sales Hub Professional／Enterprise です。AIが評価基準と点数を提案するAIリードスコアはさらに条件が狭く、Marketing Hub Enterprise 専用で、スコア生成にはコンバージョン済み25件と未コンバージョン25件を含む最低50件のコンタクトが必要と公式ヘルプに記載されています。導入直後でデータが貯まっていないうちは、ルールベースで運用することになります。 Adobe Marketo Engage は用語集で、MQLを「ナーチャリングを経て、営業組織へ引き渡してフォローアップするに足る行動と特性を示した個人」と定義しています。この用語集はMQLの考え方を示していますが、何をもって成功基準（success criteria）とするかは自社で決める前提になっています。MAツールの機能と運用体制を踏まえて、定義づくりを外注しないでください。 ### Salesforce Einstein Lead Scoringのモデル別利用条件 Salesforceの Einstein Lead Scoring は、過去にコンバージョンしたリードとカスタム項目、活動データから変換パターンを学習します。独自の予測モデルを作るには、直近200日間に作成されたリードが1,000件以上、そのうち取引先と取引先責任者へ変換されたリードが120件以上必要です。この件数に届かない間もスコアは付きますが、それは多数の利用企業の匿名データから作られたグローバルモデルによるもので、自社データが貯まった時点で成績の良いほうへ切り替わります。提供形態は Performance Edition と Unlimited Edition に含まれ、Enterprise Edition では追加費用がかかります。件数が少ないうちに出るスコアは自社の購買傾向を反映していないため、前節の理由コードと商談化の実績を突き合わせて妥当性を確かめてから運用に載せてください。 ## 過剰選別で商談を減らす失敗パターン 選別は厳しくするほど良い、という前提は誤りです。閾値を上げても実際の受注確度が高まるとは限りません。有望なリードまで除外していないか、MQL件数・商談化率・受注数を併せて確認してください。とくに次の3つは、基準を触る前に疑ってください。 第一に、件数目標に合わせて閾値を動かす運用です。期末に件数が足りないから閾値を下げ、翌期に質が悪いと言われて上げる。この往復を繰り返すと、営業側は渡されたMQLを信用しなくなり、理由コードの入力もやめます。基準を動かす条件（たとえばターゲット市場の定義が変わったとき）を先に決めておけば、目標未達は基準ではなく施策側で解決する話になります。 第二に、育成へ戻す経路を作らないまま落とすことです。失格理由が「購入時期がX か月より先」であれば、その時期に再接触するタスクが自動で立つのが本来の設計です。戻り先が無ければ、落としたリードはそのまま死蔵します。 第三に、判定をツールの既定ステータス名に任せることです。CRMの既定値である「Qualified」と、自社で合意したMQLの定義は別物です。既定値をそのまま使うと、営業とマーケティングが同じ画面を見ながら違う意味で話すことになります。 ## 選別の質を測る指標と見直しの順序 営業への引き渡し、受け入れ後の判定、商談化の順に確認します。例えば、却下率は引き渡したMQL、失格率と商談化率は受け入れたSALを分母とし、同じ対象集団と追跡期間で集計します。却下理由が情報不足や割り当て誤りに偏っているなら、基準を触る前に入力フォームの必須項目と割り当てルールを直すほうが速く効きます。失格理由が予算や時期に偏っているなら、育成期間や獲得チャネルに加え、営業への引き渡し時期と失格判定の基準を確認してください。商談化率だけを見ていると、この2つの区別がつきません。 費用側の指標としては、MQL1件あたりの獲得コストを見るCPMQLがあります。ただしCPMQLは選別を緩めれば下がる指標なので、却下率とセットで見ないと改善したように見えるだけになります。 ## よくある質問 ### リードクオリフィケーションとは何ですか？ 獲得済みの見込み顧客が営業に引き渡す条件を満たしているかを判定し、満たすものを選び出す工程です。判定の主体はマーケティング側にあり、選び出された結果がMQLと呼ばれます。 ### リードナーチャリングとの違いは何ですか？ リードナーチャリングは関心度を引き上げる施策、リードクオリフィケーションは引き上がったかを判定する工程です。判定理由を記録し、対象顧客に合うものの検討時期が早いリードはナーチャリングへ戻します。 ### リードクオリフィケーションは誰が行いますか？ 基準づくりと一次判定はマーケティング部門、接触して確かめる部分はインサイドセールスまたは営業が担うのが一般的です。ただし基準は両部門で合意しないと、渡した先で却下が積み上がります。 ### BANTはインバウンドで獲得したリードにも使えますか？ 使えます。ただし判断材料になるのは、相手の検討が具体化している場合です。情報収集の段階では予算も導入時期も未定のことが多く、その回答だけを根拠に失格にしないでください。初期段階は属性と行動のシグナルで判定し、BANTは検討が進んだ相手に当てます。 ### MAツールが無いとリードクオリフィケーションはできませんか？ できます。HubSpotのAIリードスコアはコンバージョン済み25件を含む50件、Salesforce の Einstein Lead Scoring は直近200日で1,000件以上のリードを前提としており、リード数だけで自動化の可否は決まりません。表計算とCRMの標準項目で理由コードを貯めることから始めるほうが実際的です。 ## 関連記事 - [クオリファイドリードとは？意味・MQL/SQL/PQLの違いと判定基準](https://www.issoh.co.jp/column/details/7250/) - [MQLの判定基準とは？属性・行動スコアで決めるリード選定の基準と設計手順](https://www.issoh.co.jp/column/details/5160/) - [SQL（Sales Qualified Lead）とは？営業へ引き渡す条件とSLAの決め方](/column/details/7250/) - [リードスコアリングとは？その基本的な概要と役割について](/column/details/5160/) - [リードジェネレーションとは何か？定義とマーケティングにおける役割](https://www.issoh.co.jp/column/details/7032/) - [リードナーチャリングとは？メリット・手法・進め方とメール配信で守る法令](https://www.issoh.co.jp/column/details/7033/) - [CPMQL（コストパーMQL）とは？計算式・CPL/CACとの違いと許容額の決め方](https://www.issoh.co.jp/column/details/7268/) --- 出典: [リードクオリフィケーションとは？選別基準の作り方と却下・失格の設計]()（株式会社一創）