MQLとSQLの違いとは？認定部門・SALを挟む引き渡し設計

MQL（Marketing Qualified Lead）とSQL（Sales Qualified Lead）は、どちらも見込み客を指す言葉です。両者を分けるのは見込み度の高さそのものではありません。どの部門が、何を根拠に、どういう合意をしたかという一点です。ここを取り違えると、マーケティング部門がMQLの件数を積み上げても営業部門は着手せず、両部門の数字が噛み合わないまま歩留まりだけが落ちていきます。この記事では両者の対比表から始め、間に挟まるSAL（Sales Accepted Lead）の役割、HubSpotとSalesforceでの実装差、そして提唱元であるForrester（旧SiriusDecisions）がこの枠組み自体をどう作り替えたかまでを扱います。

まとめ

• MQLはマーケティング部門が「営業へ渡してよい」と認めた段階、SQLは営業部門が「追う価値がある」と認めた段階です。認定する主体が違います。
• 同じ見込み客が、同じ日にMQLでもSQLでもありえます。段階は人の属性ではなく、部門間の合意の状態を表すためです。
• MQLとSQLを直結させず、営業が受領を認めるSALを間に挟みます。SALが無いと、脱落したリードが「営業が着手しなかった」のか「着手したが見込みが無かった」のか判別できません。
• 定義はツールが決めてくれません。HubSpotは標準のライフサイクルステージ8種にMQLとSQLを持ちますが、Salesforceの標準リードステータス4値にはどちらも入っていません。
• 提唱元は2017年に買い手の単位を個人から購買グループへ移し、Forresterは現在も公式ガイドで「MQLを超えよ」と書いています。部門をまたいで3人以上が関わる購買では、MQL件数をマーケティング部門の評価指標に据えた設計が実態と合わなくなります。

MQLとSQLの違いを分ける「誰が認定するか」という基準

MQLとSQLは、リードの温度を2段階に分けたラベルではありません。認定する部門が違うラベルです。主要な観点を並べると差がはっきりします。

この表で最も効く行は「答えている問い」です。MQLは引き渡しの可否を答え、SQLは追跡の価値を答えます。問いが違うので、片方が真でもう片方が偽という状態は矛盾ではありません。営業に渡す価値はあったが追う価値は無かった、という判定は日常的に起こりえます。

MQL＝マーケティング部門が営業へ渡してよいと認めた段階

HubSpotは製品ドキュメントで、MQLを「マーケティングチームにより営業チームへの引き渡しが可能と判断されたコンタクトまたは会社」と定義しています。ここでいうコンタクトはHubSpot CRMのレコード種別で、個人か法人かという区別ではありません。判定に使うのは、業種・従業員規模・役職といった属性情報と、資料請求やセミナー参加などの行動情報です。

目を引くのは、このステージ定義に受注確度への言及が無い点です。定義が答えているのは営業リソースを割く価値があるかどうかであって、受注できるかどうかではありません。ただしHubSpotはMQLの解説記事では「他のリードより顧客になる可能性が高いと判断したリード」とも説明しており、確度の考え方を排しているわけではありません。属性と行動をどう重み付けしてMQLの線を引くかはMQLの判定基準とは？属性・行動スコアで決めるリード選定の基準と設計手順で、スコア設計そのものはリードスコアリングとは？その基本的な概要と役割についてで扱っています。

SQL＝営業部門が追う価値があると認めた段階

同じくHubSpotの定義では、SQLは「営業チームにより可能性のある見込み客と判断されたコンタクトまたは会社」です。判断材料は営業担当者が実際に会話して得た情報に移ります。予算の有無、決裁の経路、導入したい時期、解決したい課題といった、いわゆるBANT系のヒアリング項目がここに入ります。

MQLとの決定的な差は、判定の根拠が推定から確認へ変わることです。MQLの段階では「この行動をとった人は確度が高いはずだ」という統計的な推定に頼りますが、SQLの段階では本人に聞いて確かめます。だから同じ見込み客が、マーケティング部門の目にはMQLとして映り、営業部門の目にはSQLに至らない存在として映る事態が起こりえます。営業側から見た合格条件と引き渡しの取り決めはSQL（Sales Qualified Lead）とは？営業へ引き渡す条件とSLAの決め方にまとめています。

MQLとSQLの間に置くSAL（Sales Accepted Lead）の役割

MQLとSQLの違いを理解しても、引き渡しは動きません。実務では両者の間にもう一段、SAL（Sales Accepted Lead）を置きます。SALはリードの質を評価する段階ではなく、責任の所在が移ったことを記録する段階です。

初代デマンドウォーターフォールの5段階に見るSALの位置

SALという段階は、調査会社SiriusDecisionsが2006年に公開した初代デマンドウォーターフォールに由来します。Forresterが公開している解説では、初代の工程はこう説明されています。マーケティングが問い合わせを創出し、その一部を営業へ送る準備ができたリード（MQL）として指定する。営業はそのリードを受け取り（SAL）、購買の準備ができているかを見極めて（SQL）、受注する。問い合わせから受注までの5段階です。

ここで営業が行う「受け取る」と「見極める」が別の段階として分かれている点が、MQLとSQLの理解の要になります。前半のMQLまではマーケティング部門が持ち、SAL以降は営業部門が持ちます。なお、MQLの手前にMAL（Marketing Accepted Lead）を置く運用も見かけますが、これはMAツールの運用側で作り込まれた段階で、提唱元のモデルには含まれません。段階の切り分け全般はリードクオリフィケーションとは？定義とその役割について解説とクオリファイドリード（Qualified Lead）とは何かをわかりやすく解説で整理しています。

SALを省いた組織で歩留まりの原因が特定できなくなる仕組み

SALを省いてMQLからSQLへ直結させると、数字がひとつ足りなくなります。たとえばMQLが100件でSQLが20件なら、残る80件がどこで消えたのかを説明する手がかりがありません。営業が着手しなかったのか、着手したうえで見込みなしと判断したのか。前者ならマーケティング部門と営業部門で定義がずれており、後者なら定義は合っていてリードの質そのものに問題があります。打ち手はまったく違うのに、集計上は同じ「SQLにならなかったMQL」に見えます。

SALを挟むと、80件がMQLとSALの間で落ちたのか、SALとSQLの間で落ちたのかが分かれます。段階をひとつ増やす手間の見返りは、この切り分けができることです。あわせて、SQLに至らなかった理由のうち「時期尚早」のものだけをマーケティング部門へ戻す経路も用意します。戻したリードは再度育成の対象に入り、条件を満たせばもう一度MQLとして上がってきます。段階は一方通行ではなく、循環させて初めて機能します。育成と選別の打ち手そのものはデマンドジェネレーション（デマジェン・デマジェネ）とは何か？基礎から徹底解説で扱っています。

MQLとSQLのツール実装差（HubSpotの標準ステージとSalesforceの標準リードステータス）

MQLとSQLを運用に載せる段になると、多くの担当者がツールの標準機能に頼ろうとします。主要ツールでも、MQLとSQLが標準で用意されているとは限りません。

HubSpotのライフサイクルステージ8種に組み込まれたMQLとSQL

HubSpotのライフサイクルステージは既定値を8つ持ちます。順序を持つ7段階がSubscriber、Lead、Marketing Qualified Lead、Sales Qualified Lead、Opportunity、Customer、Evangelistで、そのどれにも当てはまらない場合の受け皿としてOtherが加わる構成です。MQLとSQLが標準の選択肢として最初から並んでいるため、追加設定なしで段階を記録できます。SQLの内側の細分ステージは、別に用意された「リードステータス」プロパティーで管理する設計です。

ただし用意されているのはラベルだけです。前掲の定義は「営業チームへの引き渡しが可能と判断された」までしか述べておらず、何をもって可能と見なすかは各社が決めます。既定のステージは編集も削除もでき、独自ステージの追加もできます。ステージが標準で存在することと、定義が決まっていることは別の話です。

Salesforceの標準リードステータス4値に無いMQLとSQL

Salesforceのリードオブジェクトが持つ「Lead Status」も、標準では4値です。現行の組織に初期設定されるのは、既定値のOpen – Not Contacted、Working – Contacted、コンバート扱いのClosed – Converted、そしてClosed – Not Convertedです。Salesforce ClassicのヘルプではOpen、Contacted、Qualified、Unqualifiedという別の4値が既定として案内されており、参照した資料によって並びが変わります。どちらの組であっても、MQLとSQLは標準値に含まれていません。SalesforceでMQLとSQLを段階として管理するなら、この選択リストに値を追加するか、別途カスタム項目を作る必要があります。

この差は設計の順序に影響します。HubSpot中心の組織では既存ステージの意味を自社向けに定義し直す作業から始まり、Salesforce中心の組織では段階の設計そのものから始まります。どちらにしても、ツールを導入すれば定義が決まるという期待は成立しません。MAツール側の機能範囲はマーケティングオートメーション（MA）とは？仕組み・機能・料金と運用体制で確認できます。

提唱元Forresterがリード単位から購買グループ単位へ移した経緯

MQL、SAL、SQLという段階名の出どころは、前述のSiriusDecisionsのデマンドウォーターフォールです。そして提唱元は、このリード中心の枠組みを自ら手放しました。前提が動いているという事実は、上位の日本語解説記事ではほとんど扱われていません。

2006年の初代5段階から2012年再設計版までの粒度向上

初代の5段階に対し、2012年の再設計版はマーケティング認定の工程に段階を足しました。スコアの閾値に達したリードをAQL（Automation Qualified Lead）として切り出し、電話開拓の体制を持つ組織向けにTAL（Teleprospecting Accepted Lead）とTQL（Teleprospecting Qualified Lead）を置きます。あわせて、電話開拓や営業自身が創出した需要を追跡する段階も別系統で加わりました。ここまでは、段階を細かく割ってどこで止まっているかを見えるようにする方向の改良です。モデル本体の構造はデマンドウォーターフォールとは何か？基本概念とその重要性を解説で解説しています。

2017年デマンドユニットウォーターフォールで置き換わった買い手の定義

方向が変わったのは2017年5月17日です。ラスベガスで開かれたSiriusDecisions Summitで、Terry FlahertyとKerry Cunninghamがデマンドユニットウォーターフォールを発表しました。B2Bの購買判断はチーム、すなわち購買グループ（buying group）で下されるという前提に立ち、追跡の単位を個人からデマンドユニットへ移した版です。デマンドユニットは「組織が抱える課題に対応するために組成された購買グループ」と定義され、買い手・ニーズ・ソリューションの三者が合致して初めて成立します。

その後、Forresterは2019年1月3日にSiriusDecisionsの買収を2億4,500万ドルの現金で完了します。2021年5月4日には、デマンドユニットウォーターフォールを改称・拡張したB2B Revenue Waterfallを発表しました。この版で加わったのは更新・クロスセル・アップセルという既存顧客側の商談タイプで、購買グループ単位への転換自体は2017年に済んでいます。2021年の変更点は、対象範囲が新規顧客から既存顧客へ広がったことだと理解しておくと、年号の混同を避けられます。

発表時に公表されたVP兼グループリサーチディレクターMonica Behnckeのコメントは、この系譜の到達点を端的に述べています。「マーケティングと営業の新しい役割は、買い手が購買の道のりを前に進むのを助けることであり、リードをファネルやパイプラインに押し込むことではない」。同じ発表資料で示された2021年のForrester B2B Buying Studyでは、購買の80%超が複雑な購買シナリオに該当し、その中心をなす合意形成型では3人以上・2部門以上が関与するとされています。Forresterの現行の公式ガイドページも「マーケティング認定リード（MQL）を超えよ」と掲げ、リード中心のデマンドプロセスには限界があるという認識を前提に置いています。

MQLとSQLの区別を残すべき組織と、指標から外すべき組織の分かれ目

では日本のB2B企業がMQLとSQLの区別を捨てるべきかというと、そうは考えません。分かれ目は購買の形です。

区別をそのまま残してよいのは、意思決定者が実質1人で、単価が低く、検討期間が短い商材です。中小企業向けのSaaSをインサイドセールスで売る形はここに当たります。購買グループという概念を持ち込んでも管理コストが増えるだけで、個人単位のMQLとSQLで運用できます。

見直すべきなのは、部門をまたいで3人以上が関与し、検討が数か月におよぶ商材です。この形では、同じ企業の別々の担当者が個別にMQLとして計上され、実態はひとつの購買検討なのに複数のリードとして数えられます。マーケティング部門のKPIをMQL件数に置いたままだと、この重複が成果として積み上がります。該当する場合は、MQLとSQLの段階自体は引き渡しの管理に残しつつ、評価指標をMQL件数から商談化した案件数へ移すべきです。段階を捨てるのではなく、段階を評価軸から外すという整理になります。

よくある質問

MQLとSQLはどちらが先の段階ですか？

MQLが先で、SQLが後です。マーケティング部門がMQLとして認定したリードを営業部門へ引き渡し、営業部門が対応対象として受け取った段階がSAL、追跡する価値があると判断した段階がSQLになります。ただし前後関係は組織が定めた運用上の順序であって、リードの状態が必ずこの順に進むわけではありません。展示会で名刺交換した相手がその場で商談化すれば、MQLを経ずに営業側の管理下に入ります。

MQLとSQLの違いは誰が決めるのですか？

マーケティング部門と営業部門が合意して決めます。MQLの条件をマーケティング部門だけで決めると、営業部門が受け取らないまま件数だけが積み上がります。決め方としては、過去に受注した案件が引き渡し時点で持っていた属性と行動を両部門で洗い出し、そこから逆算して条件を組む方法が実務的です。条件は固定せず、SQLへの転換率を見ながら定期的に見直します。

マーケティングのSQLはデータベースのSQLと同じですか？

まったくの別物です。マーケティングと営業の文脈で使うSQLはSales Qualified Lead（営業が認定した見込み客）の略で、データベースを操作するSQLはStructured Query Language（構造化問い合わせ言語）の略です。綴りが同じなので、MQLやリード、商談と並んで出てきたら前者、SELECT文やテーブルと並んで出てきたら後者と読み分けます。社内文書では初出時に括弧書きで正式名称を添えておくと取り違えを防ぎやすくなります。

MQLからSQLへの転換率に一般的な目安はありますか？

業界横断で通用する目安の数値はありません。転換率はMQLの条件をどこに引いたかで決まるためです。閾値を緩くすればMQL件数は増えて転換率は下がり、厳しくすれば逆になります。他社の数値と比べても自社の状態は分かりません。見るべきなのは自社の時系列で、閾値を変えていないのに転換率が下がったときは、リードの流入元か営業の対応速度のどちらかが変化したと考えて原因を探します。

MQLとSQLの区別は今でも必要ですか？

引き渡しを管理する枠組みとしては、今も必要です。どの部門がどこまで責任を持つかを明示できる仕組みは他にありません。一方で、MQLの件数をマーケティング部門の成果指標に据える設計は、部門をまたいで3人以上が関与する購買では実態と合わなくなります。提唱元も2017年に購買グループを単位とするモデルへ移りました。段階は運用に残し、評価指標は商談化した案件数へ寄せるのが現実的な落とし所です。

関連記事

• SQL（Sales Qualified Lead）とは？営業へ引き渡す条件とSLAの決め方
• MQLの判定基準とは？属性・行動スコアで決めるリード選定の基準と設計手順
• デマンドウォーターフォールとは何か？基本概念とその重要性を解説
• リードクオリフィケーションとは？定義とその役割について解説
• クオリファイドリード（Qualified Lead）とは何かをわかりやすく解説