MQL と SQL の違いとは？ - BtoB SaaS のリード管理・引き渡し基準
MQL とは何か、 SQL との違いを判定主体・判断材料・次のアクションの3軸で整理し、 BtoB SaaS におけるスコアリング設計や引き渡しルール、少人数でも回せる運用法まで解説する。
MQL （ Marketing Qualified Lead ）とは、マーケティング部門が自社の顧客像への適合性と行動シグナルをもとに、営業やインサイドセールスへ引き渡す価値があると判断した見込み顧客である。一方 SQL （ Sales Qualified Lead ）は、営業側がヒアリングを通じて商談化の対象と判断したリードを指す。両者の違いは「誰が・何を根拠に・次に何をするか」の3軸で整理でき、ここを曖昧にするとマーケティングと営業の間で摩擦が起きやすい。
MQL とは何か
MQL の正式名称と日本語の意味
MQL は Marketing Qualified Lead の略で、日本語では「マーケティング適格リード」と訳されることが多い。マーケティング部門が「営業チームへの引き渡しが可能」と判断したコンタクトや会社を指す（HubSpot ライフサイクルステージ）。
注意すべき点がある。 MQL は商談が確定した状態ではない。あくまで営業へ引き渡す"候補"であり、引き渡し後に営業が対象外と判断する場合も、ナーチャリングへ戻す場合もある。「 MQL ＝受注確度が高い」と捉えると、営業との期待値がずれる原因になる。
リード（見込み顧客）と MQL は何が違うのか
リードとは、自社と何らかの接点を持った見込み顧客全般を指す。展示会で名刺を交換した相手、 Web フォームからメールアドレスを入力した人、すべてがリードである。 MQL は、そのリード群の中から属性と行動をもとにふるいにかけた結果、営業への引き渡し候補として残ったリードだ。
BtoB SaaS では、たとえば料金ページの複数回閲覧、ホワイトペーパーのダウンロード、ウェビナー参加、導入事例ページの閲覧といった行動が MQL 判定のシグナルになりやすい。ただし行動だけでなく、企業規模や業種、役職といった属性がターゲットと合致しているかも含めて評価するのが一般的である。
リード獲得の全体設計については「リードジェネレーションとは？ BtoB SaaS におけるリード獲得の全体設計」で詳しく整理している。
SQL とは何か
SQL は Sales Qualified Lead の略である。営業またはインサイドセールスが、ヒアリングを通じて「商談化に向けて具体的に対応する価値がある」と判断したリードを指す（HubSpot ライフサイクルステージ）。
では、 SQL は必ず MQL を経由して生まれるのだろうか。実はそうとは限らない。顧客からの直接の問い合わせやデモ依頼、営業部門が独自に開拓した SGL （ Sales Generated Lead ）から SQL になるケースもある（Adobe インサイドセールス用語解説）。
MQL と SQL は単純な上下関係ではなく、それぞれ異なる判定プロセスを経て認定されるステータスである。 MQL はマーケティング起点の入口、 SQL は営業判断の入口と捉えるほうが実態に近い。
MQL と SQL の違いを比較表で整理する
「 SQL のほうが購買意欲が高い」という説明だけでは、日々の運用基準にならない。以下の4軸で比較すると、判定の責任者と次のアクションが明確になる。
判定主体と判断材料を分けずに運用すると、マーケティングが「関心が高い」と思って渡したリードを営業が「まだ商談にならない」と戻す摩擦が起きやすい。あらかじめ合意しておくことで、そのすれ違いを防げる（Salesforce MQL と SQL の違い）。
MQL と SQL の違いは「誰が、何を根拠に、次に何をするか」で定義するものであり、気持ちや熱量の度合いで分けるものではない。
BtoB SaaS のリードファネル全体像
リードが受注に至るまでの一般的なファネルは、以下のようなステージで構成される。
- Lead ── 接点を持った見込み顧客
- MQL ── マーケティングが引き渡し候補と判定
- SAL （ Sales Accepted Lead ） ── 営業が受け取り、対応価値を認めた状態
- SQL ── 営業がヒアリングを経て商談化対象と判定
- Opportunity （商談） ── 具体的な提案・見積もりが進行中
- Closed Won （受注） ── 契約締結
すべての企業が SAL や TQL （ Teleprospecting Qualified Lead ）を独立したステージとして設けているわけではない。 HubSpot のライフサイクルステージでは Subscriber 、 Lead 、 MQL 、 SQL 、 Opportunity 、 Customer といった区分が用意されているものの、自社の組織構成に合わせて取捨選択するものである（HubSpot ライフサイクルステージ）。
ステージ名を揃えること自体が目的ではなく、「誰がどの段階で何を判断し、次に誰が動くか」を社内で共有できていることが重要だ。
BtoB SaaS のマーケティング戦略全体からファネルを俯瞰したい場合は「BtoB SaaS マーケティングとは？戦略設計から少人数運用まで実務ガイド」を参照されたい。
MQL の判定基準をどう設計するか
属性スコアと行動スコアを組み合わせる
MQL の判定は、属性スコア（ Fit ）と行動スコア（ Engagement ）の掛け合わせで行うのが基本である。 HubSpot のリードスコアリング機能でも、適合スコアとエンゲージメントスコアの両面から複合スコアを作成できる（HubSpot リードスコアリング）。
属性スコアの例としては、企業規模・業種・役職・所在地が ICP （ Ideal Customer Profile ）に合致しているかどうかがある。行動スコアの例としては、料金ページの閲覧回数、ホワイトペーパーのダウンロード、ウェビナーへの参加、導入事例の複数閲覧などが挙げられる。
行動スコアが高くても、属性がターゲットから外れていれば商談化の確率は低い。逆に属性が合致していても、サイトを一度訪問しただけでは関心の深さが読めない。片方だけで判定すると、営業へ渡した後の差し戻しが増える。
資料ダウンロードやセミナー参加者はすべて MQL か
素朴な疑問が浮かぶだろう。「ホワイトペーパーをダウンロードした人は全員 MQL にしていいのか？」
答えは否である。属性が合致しない場合や、単発の接触にとどまる場合は、 MQL とせずナーチャリング対象に留める判断もある。たとえば、競合企業の担当者による情報収集、学生のレポート目的、対象外業種の個人事業主などは、行動スコアだけ見れば高くても属性スコアが低い。
BtoB SaaS ではセールス主導型とプロダクト主導型（ PLG ）で重視するシグナルも異なる。セールス主導型ではデモ依頼や見積もり依頼が MQL の強いシグナルになる一方、 PLG ではトライアル開始後のログイン頻度、特定機能の利用、席数の増加といったプロダクト内行動が PQL （ Product Qualified Lead ）として重視される場合がある。自社の営業モデルに合ったシグナル設計が不可欠だ。
SQL の判定基準と営業への引き渡しルール
SQL にする前に営業が確認すること
SQL の判定では、営業またはインサイドセールスがヒアリングを通じて以下の要素を確認する。
- 課題の明確さ ── 現状の問題を本人が言語化できるか
- 自社サービスとの適合性 ── その課題を自社で解決できる根拠があるか
- 導入時期 ── 具体的な検討スケジュールがあるか
- 予算感 ── 予算の確保状況や想定額が見えているか
- 決裁プロセス ── 誰が決裁者で、どのような承認フローがあるか
これらは BANT （ Budget ・ Authority ・ Need ・ Timeline ）フレームワークと重なる部分が多い。ただし BtoB SaaS では初期費用が小さく月額課金で始まるケースも多いため、4項目すべてが揃わなければ SQL にできないと機械的に運用するのは現実的ではない。課題と導入時期が明確であれば、予算の詳細は商談の中で詰めるという判断もある。
具体的にはどんな会話が SQL への切り替え判断になるのか。たとえば、インサイドセールスが MQL に初回架電した際、「来期の予算申請に向けて3社比較中で、9月末までにベンダーを絞りたい」という発言が出た場合は、課題・導入時期・比較検討の進行が一度に確認できるため SQL に進める根拠になる。一方、「情報収集段階で、まだ社内で課題を整理中」という返答であれば、ナーチャリングに戻してメールやコンテンツで関係を維持するのが妥当だ。
このように、 SQL の判定は「行動データの変化」ではなく「会話で確認できた事実の変化」に基づく点が MQL との決定的な違いである。
引き渡し時に共有すべき情報と SLA の考え方
MQL を営業へ引き渡す際、最低限共有すべき情報は以下である。
- リードの属性情報（企業名・規模・業種・役職）
- 行動履歴（閲覧ページ・ DL コンテンツ・参加イベント）
- 流入経路
- スコアと MQL 判定理由
SLA （ Service Level Agreement ）としてマーケティングと営業の間で合意しておくべき事項には、引き渡し条件、初回対応の期限、フォロー結果の記録方法、差し戻しルールがある。 Salesforce のページでは「引き渡し後24時間以内の初回コンタクト」が SLA の項目例として挙げられている（Salesforce MQL と SQL の違い）。ただしこれは業界共通の正解ではなく、自社の商材単価や営業体制に合わせて合意すべき数字である。
SLA の肝は、数字そのものよりも「決めて・守って・振り返る」サイクルを回すことにある。
少人数チームでも回せる簡易運用のポイント
MA ツールや専任インサイドセールスチームがなくても、 MQL と SQL を分けて管理する意味はある。まずは以下の4分類から始めるのが現実的だ。
- MQL ── 属性・行動が基準を満たし、営業対応の候補
- SQL ── ヒアリングを経て商談化を進めるリード
- 保留 ── 条件を満たさないが将来可能性がある
- 対象外 ── ターゲット外、競合、既存顧客の重複など
CRM やスプレッドシートに「判定理由」「次の担当者」「対応期限」の3列を追加するだけでも、管理の精度は変わる。 HubSpot の解説でも、日本企業では営業部門が新規開拓から一貫して担当する場合があり、組織編成に合わせて MQL と SQL の扱いを調整すべきとされている（HubSpot MQL 運用）。
マーケティングと営業を同じ人が兼ねている環境でも、ステージを分けて記録する効果はある。月次や四半期で「どのステージにリードが滞留しているか」「差し戻しの理由は何か」を集計すれば、 MQL の判定基準を調整する材料が手に入る。振り返りのない基準は形骸化する。
MQL ・ SQL の成果を測る KPI
MQL 数だけを追いかけると、営業が対応しきれないリードや対象外リードが膨らむリスクがある。以下の指標を組み合わせて、商談・受注までの貢献を可視化すべきだ。
業界共通のベンチマークとして信頼できる転換率データは確認できていない。商材単価、営業サイクルの長さ、ターゲット企業規模によって大きく変動するためだ。まずは自社のデータで基準値を作り、四半期ごとに改善するアプローチが堅実である。
よくある質問（ FAQ ）
MQL と SQL の一番の違いは何か？
判定主体が異なる。 MQL はマーケティング部門が属性・行動シグナルで判定し、 SQL は営業またはインサイドセールスがヒアリングをもとに判定する。
SAL （ Sales Accepted Lead ）とは何か？
営業が MQL を受け取り、対応する価値があると認めた状態を指す。すべての企業が SAL ステージを設けているわけではなく、組織構成に応じて採用を判断する。
無料トライアル登録者は MQL か、 SQL か？
一概には決められない。プロダクト主導型（ PLG ）ではトライアル中の利用状況をもとに PQL （ Product Qualified Lead ）として扱い、セールス主導型ではトライアル登録自体を MQL とみなす場合がある。自社の営業モデルに合わせて定義する。
MQL が SQL に進まない場合はどうするか？
ナーチャリングへ戻す、保留にする、対象外として除外するの3パターンが基本である。差し戻し理由を記録し、 MQL の判定基準を定期的に見直すことで、引き渡しの精度は上がっていく。
インサイドセールスがいない場合でも MQL と SQL を分ける必要はあるか？
分けることを推奨する。兼任体制でもステージを記録しておけば、どの段階でリードが停滞しているかを可視化でき、改善の糸口が見える。