MQL判定基準の完全ガイド｜スコアリング設計とSLA構築の実践手順

MQL（Marketing Qualified Lead）とは？定義と役割

MQL（Marketing Qualified Lead）とは、マーケティング活動を通じて獲得したリードのうち、属性と行動の両面から評価して「営業に引き渡すに値する」と判断された見込み顧客のことです。

特に重要なのは、すべてのリードがMQLになるわけではない点です。マーケティング部門が評価主体になり、属性（誰か）と行動（何をしたか）の2軸で判断します。

MQLを正確に定義しないまま運用している企業では、営業部門に「量は多いが質が低い」と判断されるリストが流れ続け、部門間の信頼が損なわれます。その背景には、「誰が・どの状態のリードを・どの基準で営業に渡すか」という合意が整っていないことがあります。

具体的には、MQLとは「ICP（Ideal Customer Profile：理想顧客像）に近い属性を持ち、かつ購買意欲を示す行動スコアが閾値を超えたリード」として定義します。この定義を営業部門と共同で設計することが、部門対立を解消する出発点になります。

マーケティングリードとMQLの違いとは何か？

マーケティングリードとは、広告・SEO・展示会などを通じて獲得した連絡先情報を持つすべての見込み顧客を指します。MQLはその中から、一定の基準を満たした「選別済みリード」です。すべてのマーケティングリードがMQLになるわけではなく、多くのBtoBマーケティング領域のベンチマークではおおよそ10〜20%前後と報告されていますが、業種・チャネル構成によって変動するため、自社データで継続的に確認することが重要です。

高スコアのMQLは「ホットリード」として営業が優先対応すべき対象になります。ホットリードの定義と優先接触の仕組みについては、別記事で詳しく解説しています。

MQL・MAL・SAL・SQLの4段階と各フェーズの役割

BtoBマーケティング領域のリード管理は、MAL・MQL・SAL・SQLの4段階で整理するとより精緻な運用が可能です。多くの記事がこの4段階を扱っていませんが、実務では段階の混同が部門間の摩擦を生む原因になります。

弊社にご相談をいただく多くの企業では、MQLをSQLと同一視したまま運用しているケースが非常に多く見られます。

MQLが「マーケの出口」であるのに対し、SQLは「営業の入口」です。この2つを混同すると、渡したリードへの対応責任が曖昧になり、フォローの遅れや放置が発生します。SALというバッファを設けることで、「受け取った・対応する意思がある」という営業側のコミットを明示できます。

MQLとSQLの決定的な違い｜「誰が認定するか」が分岐点

MQLとSQLの最大の違いは、「どの部門が・何の情報をもとに・認定するか」という評価構造にあります。MQLはマーケが行動データと属性で評価し、SQLは営業がヒアリングにより判断します。両者は評価手段も評価主体も異なる別の概念です。

SQLだけに頼ると商談機会を損失する理由

引き合いや紹介で獲得したSQLは確度が高い一方、「待ちの営業」に依存した体制では新規市場への展開が難しくなります。

弊社が支援してきた企業の多くが「テレアポと紹介が頭打ちになった」タイミングでMAツール（マーケティングオートメーション）を導入しています。MAを活用してMQLを体系的に創出することで、自社でパイプラインをコントロールできるからです。SQLだけに頼る体制は、市場環境が変化した瞬間に売上が先細りになるリスクを内包しています。

MQL判定基準の設計方法｜属性×行動の2軸スコアリング

MQL判定基準の設計は、リードスコアリングの全体設計と切り離せません。スコアリングの仕組みそのものを理解したうえで、MQLという「出口」に向けてどのようにスコアを実装するかを考えることが、設計精度を高めるうえで重要です。

属性と行動の重み付けの根拠については、BtoBスコアリングの設計と運用も合わせて参照すると理解が深まります。

押さえるべきは、「属性（ファームグラフィック）」と「行動（インテント）」という2つの軸でリードを多角的に評価することです。どちらか一方だけでは精度が出ません。属性が高くても行動がなければ、相手は自社に関心を持っていない可能性があります。行動が多くても属性がターゲット外なら、営業効率は改善しません。

属性スコア（ファームグラフィック）の設計

属性スコアとは、そのリードが「自社にとって顧客になりやすい属性を持っているか」を数値化したものです。設計の起点はICP（Ideal Customer Profile）の定義です。

具体的には、過去の受注顧客の共通属性を分析し、業種・企業規模・役職・所在地などの要素に点数を割り当てます。以下は弊社が支援先と設計する際によく使うテンプレート（一部）です。

行動スコア（インテント）の設計と優先度の考え方

行動スコアとは、リードが「どれだけ購買意欲を示す行動を取っているか」を数値化したものです。購買プロセスの後半に近い行動ほど、高いスコアを付与します。

ネガティブスコアリングの重要性

MQL判定の精度を高めるうえで、多くの記事が軽視しがちな要素がネガティブスコアリングです。これは「営業が対応すべきでないリードを除外する」ための仕組みで、属性・行動の加点と同時に設計する必要があります。

ネガティブスコアリングを設定しないと、競合他社の社員や学生など、転換可能性がゼロに近いリードが混入し、営業の対応工数が無駄になります。以下はよく使われる設定例です。

閾値（しきい値）の決め方｜感覚ではなく受注データから逆算する

「合計スコアが何点以上でMQLと判定するか」という閾値の設定は、MQL判定基準の設計において最も重要な意思決定です。

初期設定の閾値が絶対に正解ということはありません。過去の受注データが少ない段階では、まず仮設定で運用を開始し、3ヶ月後に見直すことをお勧めします。

その際の進め方は次のとおりです。

1. まず受注顧客が商談化した直前のスコアを調べます。
2. 次にそのスコアの中央値を初期閾値とします。
3. 運用後にMQL→SQL転換率が10%を大きく下回る場合は閾値を引き上げます。

弊社の支援事例では、Salesforceに蓄積された受注データを統計解析し、「受注顧客の70%が商談化7日前に価格ページを閲覧し、かつ導入事例をダウンロードしていた」という行動パターンが判明したケースがあります。

この事実をもとに各行動のスコアを設計し、閾値を受注顧客の中央値に合わせた結果、MQL→SQL転換率が大幅に向上しました。感覚的なスコア設計では「なぜこの点数なのか」を営業に説明できませんが、受注データからの逆算であれば「過去の成約顧客がこのスコアだったから」と実際に受注につながった企業名などを含め、根拠を示すことができます。これが営業の信頼を得る最短経路です。

MAツール別 MQL判定の自動化設定

MAツールを活用することで、MQL判定を手動で行う必要がなくなり、スコアが閾値を超えた瞬間に自動通知や担当に割り当てられます。スコアリングルールの設定・閾値到達時のオートメーション設定・CRMへの自動連携、この3つを組み合わせることで自動化できます。

Account Engagement（旧Pardot）でのMQL判定の自動化

Account Engagement（旧Pardot）は、Salesforceとのネイティブ連携が強みのMAツールです。MQL判定の自動化は以下の手順で設定します。

1. まずスコアリングルールで属性スコアと行動スコアを設定します。
2. 次にオートメーションルールを作成し、
3. 「プロスペクトのスコアが閾値以上かつグレードがB以上」をトリガーとして設定します。

アクションとして「Salesforceの特定キューに担当割り当て」「営業にToDoを自動作成」「メール通知を送信」を設定します。弊社ではMarketing Cloud Account Engagement Specialistの資格を持つ担当者がAccount Engagementの設定支援を行っており、スコアリングとオートメーションの連携設計に関する実務ノウハウを蓄積しています。

HubSpotでのMQL判定の自動化

HubSpotはリードスコアリング機能とワークフローを組み合わせてMQL判定を自動化します。

コンタクトプロパティのリードスコアリング機能で属性・行動ごとにスコアを設定し、ワークフローのトリガーに「リードスコアが閾値以上」を設定します。アクションとして「ライフサイクルステージをMQLに変更」「コンタクトオーナーにタスクを割り当て」「Slackまたはメールで営業に通知」を設定します。

HubSpotはUIが直感的で設定しやすい一方、スコアリングの柔軟性は相対的に低めで、単一スコアプロパティを中心とした設計となるため、複数スコアの多軸管理が必要な場合はAccount EngagementやMarketoのほうが適しています。自社の要件と照らし合わせて選定してください。

MarketoでのMQL判定の自動化

Marketoはエンタープライズ向けに広く採用されているMAツールで、スコアリングの柔軟性が高く複数スコアの管理にも対応しています。

スマートキャンペーンのトリガーを使い、属性変化・Web行動・メール反応ごとにスコア加算を設定します。スコアが閾値に達したタイミングでトリガーし、リードオーナーへの通知・CRMへの同期・セールスアラートメールを自動実行します。ネガティブスコアは「スコア変更」キャンペーンで別途管理し、定期的な減衰処理も設定しておきます。

Marketoはカスタマイズ性が高い分、設計の複雑さも増します。弊社の支援現場では、初期設定が複雑になりすぎて運用担当者が触れなくなるケースを複数見ており、シンプルさを保つ設計が継続運用には重要です。

MQL創出の3ステップ｜獲得・育成・選別のプロセス設計

MQLは単発のアクションで生まれるものではなく、獲得・育成・選別という3段階のプロセスを経て創出されます。ICPに合致したリードを獲得し、スコアが積み上がるナーチャリングを設計し、閾値到達と同時に自動で引き渡しが完了する体制を作ることが、このプロセスのポイントです。

Step.1：リードジェネレーション（ICPに合致した層の獲得）

リードジェネレーションとは、将来MQLになりうる潜在顧客の情報を獲得する活動のことです。重要なのは「数を集める」ことではなく、「ICPに近い層から集める」ことです。

具体的には、Web広告のターゲティングをICP属性に絞る、展示会では役職や企業規模でリストを事前に精査する、SEOでは購買検討層が検索するKWに注力するといった施策が有効です。獲得段階でICPに近い層を入口に絞ることで、その後のナーチャリングとスコアリングの効率が大幅に改善します。

Step.2：リードナーチャリング（スコアを積み上げる育成設計）

リードナーチャリングとは、獲得したリードに継続的に価値提供を行い、購買意欲とスコアを高めていく活動のことです。

具体的には、資料ダウンロード後のステップメール、閲覧ページに連動したコンテンツレコメンド、セミナーへの定期招待などを組み合わせます。このプロセスで各行動が行動スコアとして積み上がり、閾値に近づいていきます。ナーチャリングの設計なしにスコアリングだけ設定しても、リードは閾値に到達しません。

Step.3：リードクオリフィケーション（閾値超えの自動抽出と引き渡し）

リードクオリフィケーションとは、育成したリードの中から、MQLの基準を満たしたものを自動で特定し、営業に引き渡す工程のことです。

MAツールのオートメーションが閾値到達を検知し、CRMに自動連携・担当割り当て・通知送信まで実行します。この「選別と引き渡し」を自動化することで、マーケティング担当者がリストを手動で精査する工数を削減できます。

MQLを営業に引き渡した後の具体的なトスアップ設計については、マーケから営業へのトスアップ設計を解説した別記事も参照ください。

SLA（マーケと営業の引き継ぎルール）の設計

SLA（Service Level Agreement）とは、MQLの引き渡し基準・対応責任・フィードバック方法を両部門が合意した文書のことです。

SLAがなければMQLは形骸化します。弊社の支援経験からいうと、MQL基準を設計しても営業に使われない企業の多くがSLAを持っていません。マーケ側が渡したリードに対して営業が対応しない場合、その原因が「基準のズレ」なのか「対応工数の問題」なのかを判別する手段がなく、改善サイクルが回らなくなります。

SLAに盛り込むべき6つの必須項目

SLAに含めるべき項目は以下の6点です。

1. 両部門が合意した共通KPI目標（MQL数・MQL→SQL転換率・パイプライン金額）
2. MQLの定義の明文化（スコアモデル・閾値・除外条件）
3. 引き渡しプロセスとMAからCRMへの連携フロー
4. 営業のフォローアップ義務（MQL受領後24時間以内の初回コンタクトなど）
5. フィードバックの仕組み（失格理由のCRM記録方法）
6. 定期レビュー会議のスケジュールと議題設計

です。

特に④の「24時間以内の初回コンタクト」は、数値として明文化することが重要です。「できる範囲で対応する」という曖昧な合意ではなく、具体的な時間基準を定めることで、対応漏れの追跡とフォローアップが可能になります。

SLA策定を社内で合意させる進め方

SLA策定で最もつまずくのは、「マーケ主導で設計して営業に提示する」という進め方です。完璧な設計より、まず簡易版のSLAを両部門で共創し、運用しながら改善する姿勢が定着を早めます。

まず営業側のリアルな声を聞くヒアリングセッションを設け、「どんなリードなら今すぐ動けるか」を言語化させます。その条件をMQL基準に反映し、初回SLAを作成します。スモールスタートで運用を始め、月次レビューで基準を調整していく進め方が、現場の信頼を得るうえで効果的です。

MQLを受け取った後のSAL・SQLへの移行フロー全体の設計については、MQL→SQL連携フローの全体設計を解説した別記事で詳しく解説しています。

MQLパフォーマンスの測定KPIと業界ベンチマーク

MQLの施策は設計して終わりではなく、指標を定期的に測定して改善を繰り返すことで精度が高まります。MQL→SQL転換率が最重要指標であり、業界ベンチマークと比較することで自社の改善点を特定できます。

最重要指標「MQL→SQL転換率」の計算方法と業界平均

MQL→SQL転換率とは、マーケが創出したMQLのうち営業がSQLと認定した割合のことで、式は「SQL化件数 ÷ MQL総数 × 100（%）」で計算します。

以下のベンチマーク数値は各種BtoBマーケティングレポートからの集計値です。あくまでも一般的なレンジであり、インバウンド中心・アウトバウンド中心などチャネル構成によって上下するため、自社の状況と照らし合わせて参照してください。

弊社が支援した企業の傾向では、受注データから逆算してスコアリングを設計した企業は、感覚的にスコアを設定した企業と比較して転換率が大幅に高い傾向があります。単にツールを入れただけで感覚的なスコアを設定している状態では、ベンチマーク数値を大きく下回るケースも見られます。

転換率が低い場合に見直すべき3つのチェックポイント

MQL→SQL転換率がベンチマーク以下の場合は、以下の順番で確認することをお勧めします。

まず閾値が低すぎないかを確認します。スコアが低いままMQLと判定されているリードが混在していないか確認し、閾値を引き上げることでMQL数は減るが質が向上します。

次に営業のフォロー遅延を確認します。MQL受領から初回コンタクトまでの平均日数を確認してください。弊社の支援では、受領から3日以上経過しているケースで転換率が著しく低下する傾向があります。

最後にICPとのズレを確認します。SQL化したリードとしていないリードの属性を比較し、ICP定義が現実の受注顧客とズレていないか検証します。

よくある失敗パターンと改善策

MQL判定基準を設計しても機能しない企業には、共通の失敗パターンがあります。マーケ部門だけで定義すると営業に信頼されない、量をKPIにすると質が下がる、フィードバックを仕組み化しないと改善が止まる。この3つが繰り返し見られます。

失敗例1：マーケ部門だけでMQLを定義している

マーケティング部門が単独でMQL基準を設計し、営業に提示するパターンです。営業側は「この基準は合わない」と感じても指摘しにくく、渡されたリードを放置するケースが多くなります。

改善策は、設計段階から営業部門を巻き込むことです。「今すぐ対応したいリードの条件を教えてください」というヒアリングを実施し、その回答をMQL基準に組み込みます。MQL基準は「マーケが設計して営業に渡すもの」ではなく、「両部門が共同で決めるもの」という位置づけにすることが重要です。

失敗例2：MQL数だけをKPIに設定している

MQLの「数」だけをマーケKPIに設定した場合、担当者は閾値を下げてでも数を達成しようとします。結果として質の低いリードが増え、営業が対応率を下げるという悪循環が発生します。

改善策は、MQL数とMQL→SQL転換率を両方KPIに設定することです。転換率のKPIを持つことで、マーケティング担当者は「数より質」を意識した設計に自然に向かいます。

失敗例3：フィードバックが仕組み化されていない

MQLを渡した後に「温度感が低い」となったリードに対して、どのような点が定義とずれていたのかが記録されず、改善に活かされないパターンです。営業がCRMに理由を入力しない運用が続くと、マーケ側は何が問題なのかを把握できず、同じ基準で同じ質のMQLを渡し続けます。

改善策は、SLAにフィードバック方法を明文化することです。CRMのステータスに「予算不足」「時期尚早」「役職不適合」「競合選定」などの選択肢を設け、営業が1クリックで記録できる設計にします。月次レビューではこのデータを集計し、MQL基準の見直しに活用します。

まとめ

本記事で解説したMQL判定基準の設計について、要点を整理します。

• MQL（Marketing Qualified Lead）とは、属性と行動の2軸スコアリングで評価し、営業に引き渡すに値すると判断された見込み顧客のことです。
• MQLの判定基準は属性スコア（ICPとの合致度）と行動スコア（購買意欲の強度）を組み合わせ、受注データから逆算した閾値で設計することが最も精度が高い方法です。
• ネガティブスコアリングは競合ドメインや無活動リードを除外するために必須の設計要素であり、加点設計と同時に組み込む必要があります。
• SLA（マーケと営業の引き継ぎルール）は、MQLを機能させるための合意文書であり、共通KPI・対応義務・フィードバック方法の3点を必ず含める必要があります。
• MQL→SQL転換率はMQL施策の最重要指標であり、ベンチマークはあくまで目安として参照しつつ、自社の過去データとの比較で継続的に改善することが重要です。

よくある質問（FAQ）

MQLとSQLの定義の違いは何ですか？

MQL（Marketing Qualified Lead）はマーケティング部門が属性と行動スコアをもとに「営業に渡す価値がある」と判断したリードです。SQL（Sales Qualified Lead）は営業部門がヒアリングにより「商談化できる」と判断したリードです。評価主体と判断材料がそれぞれ異なります。

MQL率とは何ですか？どう計算しますか？

MQL率とは、獲得したリード全体に対してMQLとなった割合のことです。計算式は「MQL数 ÷ リード総数 × 100（%）」で求めます。多くのBtoBマーケティング領域のベンチマークではおおよそ10〜20%前後と報告されていますが、業種・チャネルによって変動します。目安値として参照しつつ、自社の過去3〜6ヶ月の実データから算出した値を継続的に監視することが重要です。

MQLとMALの違いは何ですか？

MAL（Marketing Accepted Lead）はマーケティング部門が接触・育成対象として受け入れたリードを指し、MQLの前段階に当たります。MALはすべての獲得リードのうちスパムや明らかな除外対象を除いたものです。MALを育成した結果、閾値を超えたものがMQLになります。

MQL獲得とはどういう意味ですか？

MQL獲得とは、マーケティング活動を通じて、MQLの判定基準（属性×行動スコアの閾値）を満たしたリードを新たに創出することです。広告・SEO・展示会・ウェビナーなどで獲得したリードをナーチャリングで育成し、スコアが閾値に達した状態にすることを指します。

MQLの判定基準はどう決めればよいですか？

まず過去の受注顧客の属性（業種・規模・役職）と商談化直前の行動履歴を分析し、共通パターンを抽出します。そのパターンに基づいてスコアを設計し、受注顧客の中央値スコアを初期閾値に設定します。初期設定は仮置きで問題なく、3ヶ月の運用後にMQL→SQL転換率を確認して調整するアプローチが実務では最も機能します。

スコアリングを設定したのにMQLが営業に活用されない場合はどうすればよいですか？

最も多い原因は、スコアリング設計に営業が関与していないことです。「なぜこのスコアなのか」を営業が理解していないと、渡されたリードへの信頼が生まれません。まずSLAを設計し、MQL基準の根拠となった受注データを営業と共有することから始めることをお勧めします。