MQLとSQLの違いとは？定義・測り方・営業連携のベストプラクティス

BtoBマーケティングの現場では、「MQL（Marketing Qualified Lead）」と「SQL（Sales Qualified Lead）」という言葉が頻繁に登場します。しかし、その定義や測り方が社内で統一されていないと、こんな課題に直面しがちです。

・マーケティングは「良質なリードを渡している」と思っているのに、営業は「案件につながらない」と感じている
・インサイドセールスや営業がMQLを追うスピードが遅く、商談化の機会を逃してしまう
・KPIが噛み合わず、成果の責任所在が不明確になる

つまり、MQLとSQLの「境界線」を曖昧にしたままでは、せっかく獲得したリードが成果に結びつかず、マーケ・営業双方の不満や不信感を生むリスクがあります。

本記事では、

・MQLとSQLの正しい定義
・実務で使える測り方の指標
・営業と連携してリードを成果につなげるベストプラクティス

を体系的に解説します。

これを読めば、自社のリードプロセスを整理し、マーケティングと営業の歩調を揃えるための実践的なヒントが得られるはずです。

MQLとSQLの基本定義

まずは、マーケティングと営業の間で混乱しやすい MQL（Marketing Qualified Lead）と SQL（Sales Qualified Lead）の定義を整理しましょう。

MQLとSQLの違い（定義・判定基準・役割の比較）
項目	MQL（Marketing Qualified Lead）	SQL（Sales Qualified Lead）
担当	マーケティングが判定	営業（またはIS→営業）が判定
状態	将来有望な見込み顧客（育成段階）	商談化可能なリード（接点確度高）
判定基準	属性＋行動スコア（DL/ウェビナー/複数ページ閲覧など）	BANT（予算・決裁権・ニーズ・時期）、BANT-CH
役割	ナーチャリング対象（ISへ引き渡し）	商談対象（FSがアクション）

MQL（Marketing Qualified Lead）とは

MQLとは、マーケティング活動を通じて獲得したリードの中で、一定の基準を満たし「将来的に顧客になる可能性が高い」と判断された見込み顧客を指します。

・例：ホワイトペーパーをダウンロードした、ウェビナーに参加した、複数ページを閲覧した、など

ポイントは「まだ営業が直接アプローチする段階ではないが、関心度の高さが数値や行動で可視化されている状態」です。

SQL（Sales Qualified Lead）とは

SQLとは、MQLの中から営業担当が「具体的な商談化が可能」と判断したリードを指します。

・例：予算が確保されている、導入検討時期が明確、決裁者と接点がある、具体的な課題を抱えているなど

ポイントは「営業がアプローチすれば商談に進む可能性が高い状態」です。

両者の違いを整理すると、

・MQL = マーケ基準で「育成対象」
・SQL = 営業基準で「商談対象」

つまり、MQLは「見込みあり」とマーケが判断したリードであり、SQLは「商談可能」と営業が認めたリードです。この境界線を明確化することで、マーケティングと営業が同じKPIに基づいて連携できるようになります。

MQLとSQLの違いを理解する重要性

MQLとSQLの定義を理解するだけでは十分ではありません。両者の違いを明確に共有できているかどうかが、組織の成果に直結します。

定義が曖昧なまま起こりがちな課題

・マーケと営業のすれ違い
マーケは「有望なリードを渡した」と考えているのに、営業は「温度感が低い」と判断して追わない。

・リード対応の遅延
営業が優先度を判断できず、せっかくのリードを放置。結果、競合に先を越される。

・KPIのズレ
マーケは「MQL数」を追い、営業は「商談数」を追う。共通指標がないため成果責任が分断される。

違いを理解することのメリット

・マーケと営業の足並みが揃う
→ どの基準を満たせば営業に渡すのかが明確になり、無駄な摩擦が減る。

・リード対応がスピーディーに
→ 「SQLの定義」を共有することで、営業が即アプローチできる状態を作れる。

・パイプライン全体の精度が高まる
→ MQLとSQLを明確に分けることで、コンバージョン率や歩留まりを正しく測定できる。

MQLとSQLの違いを全社で統一することは、単なるマーケ用語の整理ではなく、リードを成果に変えるための基盤整備です。この境界線を明確にして初めて、マーケと営業が「同じゴール」を見ながら動けるようになります。

MQLの測り方｜基準と具体例

MQL（Marketing Qualified Lead）は「マーケティング視点で有望」と判断されたリードですが、その基準を明確にしないと営業との認識ギャップが生まれます。ここでは、実務で使えるMQL判定の軸を整理します。

属性情報（デモグラフィック）での基準

リードの「企業属性」や「担当者属性」を評価し、自社のターゲットと合致しているかを確認します。

・会社規模（例：従業員数200名以上）
・業種（例：IT・製造業など重点セグメント）
・部署・役職（例：人事部長、経営層）
・地域（例：首都圏、本社所在地が日本国内）

自社のICP（Ideal Customer Profile）に近いほど、MQLとして優先度が高まります。

行動情報（デジタルアクティビティ）での基準

オンライン上での行動データをスコア化し、関心度を測定します。

・資料ダウンロード（ホワイトペーパーDLなど）
・ウェビナー参加、展示会来場
・Webサイトでの複数ページ閲覧（例：価格ページ・導入事例ページ）
・メルマガの複数回開封、クリック

単発のアクションではなく「複数の接点を持っているか」がMQL判定のポイントです。

MQL測定における実務の工夫

・リードスコアリングモデルを導入し、「属性点数＋行動点数」で合計スコアが一定以上ならMQLとする
・SaaSやMAツールを活用し、自動でスコアリング・トラッキング
・営業現場の声を取り入れて定期的に基準を見直す

MQLは「誰か（属性）」と「何をしたか（行動）」の２軸で測ることが基本です。この基準をスコアリングとして仕組み化することで、営業に渡すリードの質を安定させられます。

SQLの測り方｜基準と具体例

SQL（Sales Qualified Lead）は、MQLの中でも「営業が商談化可能」と判断したリードを指します。ここでは、実務でよく使われる判定基準を整理します。

BANT・BANT-CHによる判定

SQL判定の代表的なフレームワークがBANTです。

・Budget（予算）: 導入に必要な予算が確保されているか
・Authority（決裁権）: 商談相手が意思決定権を持っているか、または決裁者と接点があるか
・Need（ニーズ）: 明確な課題・解決ニーズを抱えているか
・Timeline（導入時期）: 具体的な検討時期が決まっているか

さらに近年は、BANTに Challenge（課題）/Human factor（人の関与度）を加えた BANT-CH が用いられるケースもあります。
「なぜ導入を検討するのか」という背景課題や、組織内の人間関係も考慮することで、商談化の確度をより正しく見極められます。

商談化の基準

営業現場では、以下の状態が確認できたリードをSQLとして扱うケースが多いです。

・初回ヒアリングで課題が顕在化 → 「業務効率化のために新システムを導入したい」など
・予算感の確認が済んでいる → 「年間◯百万円までなら投資可能」など
・意思決定プロセスが明確 → 「来期の予算承認後に比較検討に入る予定」など
・次回アクションが確定 → 「次回は決裁者同席でデモを見る」など

ポイントは「営業が追うべきかどうか」を判断できる具体的な条件が揃っていることです。

SQL測定における実務の工夫

・インサイドセールスが一次判定 → BANT-CHの確認を担当し、営業に渡す
・SFA/CRMで判定基準を統一 → 「SQLに移行した理由」を入力必須にする
・営業との合意形成 → 定義を毎期見直し、SLA（サービスレベルアグリーメント）に明文化

SQLは「営業が今すぐ動くべきリード」です。BANTやBANT-CHといったフレームワークを基準にし、営業が納得する形で明確にルール化することで、リードから商談への歩留まりを改善できます。

MQLからSQLへの移行プロセス

MQLとSQLの定義を明確にしても、その間の「移行プロセス」が整理されていなければ、リードは途中で取りこぼされてしまいます。ここでは、実務で成果を出すための移行フローを解説します。

商談化フロー：

MQL判定（属性＋行動スコアが基準到達）

↓

IS一次接点（電話/メールで温度感確認・BANT/CHヒアリング）

↓

SQL昇格（基準充足→営業へ引き渡し）

↓

商談設定（FS合意・デモ/提案準備）

SLA例：MQL受領後 24時間以内にIS初回接点／SQL受領後 48時間以内にFS初回アクション
記録：全ステップをMA/SFA/CRMで自動連携・必須項目化（非SQL理由を選択式）

ステップ１：MQLの引き渡し

・マーケティングが定義基準を満たしたMQLをインサイドセールス（IS）へ引き渡す
・SFA/CRMに自動連携させ、抜け漏れなく引き継ぐ仕組みを整備することが重要

ステップ２：インサイドセールスによる一次確認

・ISがMQLに対して電話・メールでアプローチし、温度感を確認
・BANT（予算・決裁権・ニーズ・導入時期）やBANT-CHを基準に、SQL候補かどうかを判断
　→ このフェーズでの「ヒアリング力」が、SQL移行率を大きく左右します。

ステップ３：SQLへの昇格

・ISが基準を満たすと判断したリードをSQLとして営業に引き渡し
・この時点で「商談化の見込みあり」と営業が動ける状態に

ステップ４：営業承認と商談化

・フィールドセールスがSQLを受け取り、初回商談を設定
・SFA上で「SQL → 商談化」への移行を明確に管理

プロセスを成功させるポイント

・明確なSLA（サービスレベルアグリーメント）
MQLを渡してから営業が何時間以内に対応するかをルール化

・フィードバックループ
営業から「SQL基準に満たなかった」理由をIS/マーケへフィードバック

・自動化ツールの活用
MAやSFAを連携させ、移行漏れ・対応遅延を防ぐ

MQLからSQLへの移行は「マーケ → IS → 営業」の三段階が基本です。各フェーズで役割と基準を明確化し、SLAとツールを活用することで、リードの取りこぼしを防ぎ、商談化率を最大化できます。

営業との連携を成功させるベストプラクティス

MQLとSQLをいくら定義しても、実際に営業との連携が機能しなければ成果にはつながりません。ここでは、リードを商談化するための連携強化のベストプラクティスを紹介します。

SLA（Service Level Agreement）の設定

マーケティングと営業の間で「誰が・いつ・どこまでやるか」を合意するのがSLAです。

・マーケ → 月◯件のMQLを営業に渡す
・営業 → MQLを受け取ってから◯時間以内に初回アクションを行う
・IS → ヒアリング結果を必ずCRMに記録

SLAを数値で明文化することで、責任分担が曖昧にならず、両部門の信頼関係が強化されます。

フィードバックループの仕組み化

営業が「このMQLは質が低かった」と感じた場合、その理由をマーケに返す仕組みが必要です。

・CRMやSFAに「非SQL化理由」を入力必須にする
・月1回の定例でマーケ・IS・営業がリードの質を振り返る
・フィードバックをもとにスコアリングやターゲティングを改善

このサイクルを回すことで、MQLの質が年々改善し、歩留まり率も安定していきます。

共通KPIの設定

・マーケは「MQL数」だけでなく「MQL→SQL移行率」まで追う
・営業は「SQL数」だけでなく「SQL→受注率」まで可視化
・両部門が「パイプライン全体の成果」を共通のKPIとして持つことで、縦割り意識を防げる

ツール活用とデータ一元化

・MA（Marketing Automation）とSFA/CRMを連携
・MQL→SQL→商談→受注の流れを一気通貫で管理
・Slackやメール通知を活用し、リアルタイムで引き渡し状況を共有

営業との連携を成功させる鍵は、

① SLAでルールを明文化
② フィードバックループで改善を継続
③ 共通KPIで同じゴールを見る

の３つです。これにより、マーケと営業の「温度差」を解消し、リードを確実に商談へとつなげられます。

よくある課題と解決策

MQLとSQLを定義しても、実務では様々な課題が発生します。ここでは代表的な失敗パターンと、その解決策を整理します。

よくある課題と解決策（MQL/SQL運用の改善ポイント）
よくある課題	解決策
MQLの質が低い／営業から「温度感が低い」と指摘	属性＋行動のリードスコアリング導入／「どの行動＝何点」を明文化し合意形成
SQL移行が遅い／競合に先を越される	SLAで対応時間を明文化（IS/FS）／通知・自動割当で遅延防止
営業がMQLを追わない／優先度判断ができない	MQL→SQL基準の可視化／共通KPI（移行率）を営業評価に連動
マーケと営業で評価が分断（MQL数 vs 商談数）	パイプラインKPI（MQL→SQL→商談→受注）を共通化し月次レビュー