BtoBマーケティングの現場で必ず出てくる用語が「MQL」と「SQL」です。リードをこの2つのステージで区別できていない組織では、「マーケが渡したリードを営業が放置する」「営業が『リードの質が低い』と不満を言う」といったすれ違いが起きがちです。本記事では、MQLとSQLの定義と違い、なぜ区別が重要なのか、基準の作り方5ステップ、引き渡し後の運用ノウハウまでを、BtoBの実務目線でわかりやすく解説します。

MQLとSQLとは？リードステージの基本と両者の違い

MQL（Marketing Qualified Lead）とは、マーケティング活動を通じて獲得したリードのうち、あらかじめ決めた基準を満たし、「営業部門へ引き渡す価値がある」と判定された見込み顧客のことです。一方、SQL（Sales Qualified Lead）とは、営業（またはインサイドセールス）がヒアリングなどを通じて「商談を進める価値がある」と認定したリードを指します。

つまり、同じ「見込み顧客」でも、評価する主体と確度が異なります。

• MQL：マーケティングが判定。「興味・関心が一定レベルを超えた」段階
• SQL：営業側が判定。「課題・予算・時期などから商談に値する」段階

MQLの判定には、属性条件（対象業種・企業規模・役職に当てはまるか）と行動条件（資料ダウンロード、ウェビナー参加、料金ページ閲覧、問い合わせなどの購買シグナル）の組み合わせがよく使われます。行動を点数化して判定する方法はリードスコアリングの解説記事で詳しく説明しています。

組織によってはこの間に「SAL（Sales Accepted Lead：営業がMQLを受領した段階）」を挟む場合もありますが、まずはMQLとSQLの2段階を明確にすることが出発点です。

MQLの手前には、獲得直後の「リード」、育成中の「ナーチャリング対象リード」が存在します。つまりMQL/SQLの設計は、リード獲得から受注までのファネル全体の設計の一部です。全体像を押さえたうえで、本記事では「マーケから営業への引き渡し」に絞って解説していきます。

なぜMQL/SQLの定義が重要か｜数字で見る「リードの取りこぼし」

MQLとSQLの定義が曖昧なまま運用すると、ファネルの途中でリードが大量にこぼれ落ちます。

海外のBtoB企業を対象とした調査（Implisit社・現Salesforce傘下の分析）では、獲得したリードのうち商談化に至るのは平均で約13%に過ぎないと報告されています。また、Harvard Business Reviewに掲載されたリード対応速度の調査では、問い合わせから1時間以内にコンタクトした企業は、それ以降に対応した企業と比べてキーパーソンと有意義な会話ができる確率が約7倍高いという結果が示されています。つまり、「誰に・いつ・どのリードを渡すか」の設計次第で、同じリード数でも商談化数は大きく変わるということです。

定義が曖昧な組織で起きがちな問題は次のとおりです。

• 営業が「質が低い」と感じたリードを放置し、対応スピードが落ちて商談化率が下がる
• マーケティングがMQL数だけをKPIに追い、質の低いリードを量産する
• 引き渡し基準がないため、失注・放置の原因分析ができず、改善サイクルが回らない
• ステージ別の転換率が計測できず、施策投資の判断を誤る

逆にいえば、MQL/SQLの定義を部門間の「共通言語」として文書化するだけで、商談化率（引き渡したリードが商談になる割合）の計測と改善が可能になります。商談化率の目安と改善方法は商談化率の解説記事を参考にしてください。

具体例でイメージする：MQLからSQLまでの流れ

たとえばITツールを販売するBtoB企業の場合、次のような流れになります。展示会で名刺交換したリード（この時点ではまだMQLではない）が、後日ウェビナーに参加し、料金ページを閲覧した時点でスコアがしきい値を超えMQLに昇格。インサイドセールスが1営業日以内に架電し、「導入検討の時期が半年以内」「決裁ルートが明確」と確認できたためSQLと認定し、フィールドセールスに商談を設定する——。このように、MQL/SQLは「リードを段階的に絞り込み、各段階で最適な部門が最適なアクションを取る」ための仕組みです。

MQL/SQL基準の作り方5ステップ（SLA設計）

基準づくりは、マーケティングと営業が合同で行うことが大前提です。片方の部門だけで決めた基準は、ほぼ確実に形骸化します。次の5ステップで進めましょう。

なお、5ステップすべてを一度に完璧に整える必要はありません。小さく決めて、運用データで磨き込むことを前提に進めてください。

ステップ1：受注顧客の共通項から「理想の顧客像」を定義する

過去の受注案件を分析し、業種・企業規模・部門・役職・抱えていた課題の共通項を洗い出します。ここで定義した顧客像が、属性条件のベースになります。

ステップ2：属性条件と行動条件をスコアリングで数値化する

「対象業種で従業員100名以上なら+20点」「料金ページ閲覧は+10点」のように、属性と行動を点数化し、「合計○点以上でMQL」というしきい値を仮決めします。最初から精緻にする必要はなく、運用しながら調整する前提で始めます。

ステップ3：マーケ・営業合同でMQL基準に合意する（SLA）

MQLの定義、引き渡し方法、営業側の対応期限（例：MQLには1営業日以内に初回コンタクト）を、部門間の合意事項（SLA：Service Level Agreement）として文書化します。「マーケは質を保証する、営業は速度を保証する」という相互の約束にすることがポイントです。

ステップ4：引き渡しフローと差し戻しルールを決める

CRM/SFA上でのステータス変更ルール、担当割り当ての方法、「商談に値しない」と判断した場合の差し戻し（リサイクル）理由の記録方法を決めます。差し戻されたリードはリードナーチャリングのシナリオに戻して育成を続けます。

ステップ5：月次で転換率を見ながら基準を見直す

MQL数、MQL→SQL転換率、SQL→受注率を月次でレビューし、しきい値や条件を調整します。転換率が低すぎればMQL基準が緩すぎ、MQL数が少なすぎれば厳しすぎるサインです。

引き渡し後の運用ノウハウと形骸化を防ぐチェックリスト

基準を作って終わりではなく、日々の運用で機能させることが重要です。実務でのポイントを4つ紹介します。

初回対応のスピードを最優先する

前述の調査が示すとおり、リード対応は速度が命です。MQLへの初回コンタクトは「当日中」を目標にし、SLAで定めた期限をダッシュボードで可視化しましょう。インサイドセールス部門を置く場合の体制設計はインサイドセールスの解説記事で詳しく解説しています。

差し戻し理由を資産化する

「なぜ商談化しなかったか」（予算なし、時期尚早、対象外業種など）を記録し、月次でマーケティングにフィードバックします。この情報がMQL基準の精度を上げる最良の材料になります。

MQLの「数」ではなく「その後」で評価する

マーケティングをMQL数だけで評価すると、質の低下を招きます。MQL→商談化率、商談→受注率、最終的な受注金額まで含めてファネル全体で評価する仕組みにしましょう。

ツール上でステージを一元管理する

MQL/SQLのステージ管理は、スプレッドシートでも始められますが、リード数が月数十件を超えるならMAツールとCRM/SFAでの一元管理が現実的です。重要なのは、ツール上のステージ名と、SLAで合意した定義を完全に一致させることです。「ツールにはステージがあるが、現場は独自の感覚で運用している」状態が、形骸化の最も典型的なパターンです。ステージ変更の履歴が残るように設定しておくと、後からファネル分析を行う際のデータ基盤にもなります。

四半期ごとに定義を再点検する

商材・ターゲット・市場環境が変われば、適切なMQL基準も変わります。四半期に一度はマーケ・営業合同で定義とSLAを見直す場を設定してください。

よくある質問（FAQ）

Q. MQLの基準は最初からスコアリングで作るべきですか？
リード数が少ないうちは、スコアリングよりも「問い合わせ・資料請求・ウェビナー参加のいずれか＋対象企業条件」のようなシンプルなルールで十分です。月間リード数が増え、営業が全件対応できなくなった段階が、スコアリング導入の目安です。

Q. MQLからSQLへの転換率はどのくらいが目安ですか？
商材単価・リードソース・基準の厳しさによって大きく変わるため、一律の「正解値」はありません。まずは自社の現状値を計測し、前四半期比で改善していく相対評価で運用するのが実務的です。転換率が極端に低い場合は、リードの質よりも先に「対応スピード」と「基準の合意状況」を疑ってください。

まとめると、MQLとSQLは「マーケが渡す価値ありと判定したリード」と「営業が商談に値すると認定したリード」であり、両者の基準を部門間のSLAとして合意・運用することが、リードの取りこぼしを防ぎ商談数を最大化する土台になります。

Semuis株式会社では、BtoB企業のリード獲得からMQL/SQL設計、インサイドセールスの立ち上げまで、マーケティングと営業をつなぐ仕組みづくりを支援しています。「リードはあるのに商談が増えない」とお悩みの方は、お気軽にお問い合わせください。