MQLとSQLの違いとは？定義の決め方で迷わない基礎知識

商談会議で「このリードはMQLですか、SQLですか」と議論が止まり、次の打ち手が決まらない場面は少なくありません。
マーケは「十分に温まったリードだ」と主張し、営業は「まだ案件としては弱い」と感じているなど、同じリードを見ていても評価が食い違うことがよくあります。
その背景には、MQLとSQLの意味や違い、自社に合った定義が曖昧なまま運用されていることが多いです。

MQLとSQLの基本を整理してリードの状態をそろえる

MQLとSQLの違いを理解する前に、それぞれの用語の意味と前提をそろしておくことが重要です。
ここが曖昧なままだと、どれだけ会議で議論しても「言葉の定義の違い」だけで時間を使ってしまいます。
まずは一般的な考え方を押さえたうえで、自社向けにどう調整するかを考えていきます。

MQLとSQLの用語の意味と前提を整理する

MQLは「Marketing Qualified Lead」の略で、マーケティング活動によって創出された質の高い見込み顧客を指す用語として使われます。
多くの場合、資料請求やセミナー参加、ホワイトペーパーのダウンロードなど、一定以上の関心を示したリードがMQLとみなされます（出典：Adobe公式サイト) (アドビビジネス)

一方SQLは「Sales Qualified Lead」の略で、営業活動を通じて商談化の見込みが現実的だと判断されたリードを指すことが一般的です（出典：マクロミル公式サイト) (マクロミル)
インサイドセールスや営業がヒアリングを行い、ニーズや予算、決裁プロセスなどを確認したうえで「商談として追う価値がある」と判断された状態だとイメージすると分かりやすくなります。

実務では「MQL＝マーケ側で一次的に絞り込んだリード」「SQL＝営業が案件として追うことを決めたリード」と、大まかに段階を分ける考え方が多いです。
ただし、どこまでをMQLと呼び、どこからをSQLとするかは、企業や商材によって変わる点に注意が必要です。

MQLの特徴とマーケティングでの役割

MQLは、数あるリードの中から「ある程度の確度がありそうだ」とマーケが判断した層です。
例えば、複数回のWebサイト訪問に加えて料金ページの閲覧や、製品カタログのダウンロードなど、興味関心が高い行動を取っているケースが典型です。

BtoBマーケの現場では「名刺はたくさん集まるが、どこまでを営業に渡すべきか分からない」という声がよく聞かれます。
このとき、MQLの基準がなければ、まだ温まっていないリードまで大量に営業に渡してしまい「質が低い」と不満を招きがちです。

MQLを定義し運用する狙いは、マーケが「ある程度育ったリードだけを営業に渡す」ラインを明確にすることにあります。
判断基準としては、ダウンロード・セミナー参加・メールの開封率・Web行動などの行動データと、企業規模・業種・役職などの属性データをどう組み合わせるかがポイントです。

SQLの特徴と営業プロセスでの役割

SQLは、MQLの中から営業部門が「商談化可能」と判断したリードです。
一般的には、初回ヒアリングで課題感や導入意向が確認でき、予算や検討時期の目安も見えてきた状態がSQLに相当すると説明されることが多いです（出典：マクロミル公式サイト) (マクロミル)

営業側から見ると、SQLは限られた時間を投下する対象を絞り込むためのフィルターの役割を持ちます。
「とりあえず訪問してみる」のではなく、SQLとして条件を満たしたリードに集中することで、商談化率や受注率の向上を狙うことができます。

実務では、SQLの定義が曖昧な場合「マーケから来たリードを受け取ったが、本当に追うべきか判断しづらい」という状態になりやすいです。
そこで、営業プロセスの中で「どのタイミングでSQLと呼ぶか」を事前に整理し、SFAやCRM上のステージと紐づけておくことが重要になります。

リードファネルの中でMQLとSQLはどの位置にあるか

多くの企業が採用するリードファネルでは、上から順に「リード（名刺）→MQL→SQL→商談→受注」という流れで表現されます。
MQLはまだ検討段階のリード、SQLは購入意思がより明確になり営業接点が濃くなったリードとして区別されます（出典：Salesforce公式サイト) (Salesforce)

例えば、ある企業向けツールのケースでは、展示会で獲得したリードがまず全体の「リード」となります。
その後、ウェビナー参加やナーチャリングメールへの反応が良い企業がMQLになり、商談アポイントに同意した企業がSQLとして扱われる、というイメージです。

現場では「MQLからSQLへの転換率」「SQLから受注への転換率」といった指標がよく使われます。
これらの数字を追うことで、どの段階で歩留まりが発生しているのかを把握しやすくなります。
ただし、ファネルの構造や呼び方は企業ごとに少しずつ異なるため、自社での定義とステージ設計を最初に言語化しておくことが欠かせません。

MQLとSQLの違いと定義の決め方を実務目線で考える

ここからは、MQLとSQLの違いをどのように整理し、自社に合った定義をどう決めるかを見ていきます。
一般的な説明だけではなく、実務で判断に迷いやすいポイントや、マーケと営業の合意形成のコツもあわせて押さえておくと運用しやすくなります。

MQLとSQLの結論整理：どんな違いがあるのか

結論から整理すると、MQLとSQLの主な違いは「誰が」「どこまで」リードを評価したかという点にあります。
MQLは主にマーケがデジタル行動や属性情報をもとに判定した段階、SQLは営業が直接の会話やヒアリングを通じて商談性を確認した段階です。

もう一つの違いは、リードの「温まり具合」です。
MQLは「興味関心は高いが、まだ情報収集中の可能性もある」状態であるのに対して、SQLは「具体的な検討プロジェクトの一環として情報を求めている」ことが多い段階です。

例えば次のようなイメージです。
「MQL：ホワイトペーパーをダウンロードし、自社課題に近いと感じている情報収集中の担当者」。
「SQL：課題感と予算が社内で共有され、導入検討のために具体的な提案や見積もりを求めている担当者」。

このように、MQLとSQLは優劣ではなくリードの状態の違いを表すものだと理解しておくと、社内でのコミュニケーションがスムーズになります。

自社でMQLとSQLを区別する判断基準の作り方

判断基準を決めるときの出発点は、「自社の営業プロセスが現状どうなっているか」を把握することです。
商談化までの典型パターンを洗い出し、どのタイミングで案件としての確度が上がっているのかを整理すると、MQLとSQLの境界が見えやすくなります。

実務では、次のような軸でMQLとSQLの条件を決めるケースが多いです。

• 行動指標（例：資料DL回数、セミナー参加、料金ページ閲覧など）
• 属性指標（例：業種、売上規模、従業員数、担当者の役職など）
• 意向・ニーズ（例：課題の明確さ、導入時期の目安、予算の有無など）

判断基準を考える際のポイントは、**「再現性があるか」「SFAやMAのデータで判定できるか」**という観点です。
担当者ごとの感覚ではなく、誰が見ても同じ基準でMQL・SQLを判定できる状態を目指します。

例えば「料金ページを3回以上閲覧し、資料をDLしたBtoB企業」はMQL、「初回商談で課題と導入時期の目安が確認できた企業」はSQL、といった形で条件を数値や項目として表現すると運用しやすくなります。

マーケと営業が合意するための定義設計プロセス

MQLとSQLの定義は、マーケだけでも、営業だけでも決めるとうまく機能しません。
実務では「マーケはリード数を増やしたい」「営業は質を高めたい」といった、評価軸の違いがよく見られます。

そこで、次のようなステップで定義設計を進めると合意しやすくなります。

1. 現状の商談化率・受注率・リード数の推移を共有する
2. 過去の受注案件を振り返り、共通する属性や行動を洗い出す
3. 「理想的なMQL像」「理想的なSQL像」を営業・マーケ双方で言語化する
4. 実務で判定可能な条件に落とし込み、MAやSFAの項目に反映する
5. 一定期間運用し、数字と現場の感覚の両方から見直す

このプロセスの中で、どの指標をどの優先度で見るかを決めておくことが判断基準として重要です。
例えば、高単価商材なら企業規模や役職を重視し、低単価のサブスクリプションなら行動ボリュームを重視するなど、商材特性に合った基準が必要になります。

現場では「マーケがMQLを渡しても営業がフォローしてくれない」「営業が欲しいリード像をマーケが理解できていない」といった課題が多く聞かれます。
定義設計プロセス自体を、マーケと営業の対話の場として活用し、期待値のすり合わせを行うことが有効です。

MQLとSQLで起こりがちな誤解と注意点

MQLとSQLの運用でよくある誤解の一つは、「MQLの数が多ければ必ず売上も伸びる」という考え方です。
実際には、MQLの定義が甘いとSQLへの転換率が下がり、営業の負荷だけが増える結果になりがちです。

逆に、SQLの定義を厳しくしすぎると、商談のパイプラインが細くなり、短期的な数字は改善しても中長期の成長余地を削ってしまうことがあります。
量と質のバランスをどう取るかを、定義設計の段階から意識することが重要です。

また、「他社のMQL・SQL定義をそのまま真似すればよい」というのも危険な発想です。
業種、商材単価、営業体制、販売チャネルによって、最適な基準は大きく変わります。
あくまで一般的な解説は参考情報とし、自社の過去実績と営業プロセスを起点に定義を作ることが大切です。

例えば、インバウンド中心のSaaS企業と、フィールドセールス主体の製造業向け商材では、MQLとして見るべき行動や、SQLへ進めるために必要な情報のレベルがまったく異なります。
同じ「MQL」「SQL」という言葉でも、意味合いが変わりうることを前提に、社内でこまめに定義を確認する習慣を持つと安全です。

よくある質問

Q. 小規模組織でもMQLとSQLを分けるべきでしょうか。
人数が少ない組織でも、将来のスケールを見据えてシンプルなMQL・SQLの考え方を持っておくと、データの蓄積と改善がしやすくなります。
ただし、細かくステージを分けすぎると運用負荷が高まるため、最初は「リード」「MQL」「SQL」の3段階程度から始めるのが現実的です。

Q. MQLとSQLの定義はどのくらいの頻度で見直すべきですか。
商材や市場環境が変わるタイミングや、商談化率・受注率に大きな変化が出たタイミングで見直すケースが多いです。
少なくとも年に1回程度は、過去の受注案件と現在の定義がかみ合っているか、マーケと営業でレビューすることが望ましいといえます。

Q. MAツールやSFAがなくてもMQL・SQLを運用できますか。
専用ツールがない場合でも、スプレッドシートや簡易的なデータベースで「MQLになった理由」「SQLに昇格した理由」を記録することで、最低限の運用は可能です。
ただ、リード数が増えてくると人手での管理が難しくなるため、一定のボリュームに達した段階でツール導入を検討する企業が多く見られます。

Q. インサイドセールスがない場合、誰がSQLを判定すべきでしょうか。
インサイドセールスがいない場合は、フィールドセールスが一次対応とSQL判定を兼ねる形が一般的です。
この場合でも、ヒアリング項目とSQL判定条件をあらかじめ定義しておくことで、担当者ごとのばらつきを抑えることができます。

MQLとSQLの違いと定義の決め方についてのまとめ

・MQLはマーケ施策で生まれた有望な見込み顧客を指す
・SQLは営業が商談化の見込みありと判断したリード
・MQLは検討段階の興味関心レベルSQLは購入意欲段階
・自社定義を決める前に既存の営業プロセスを棚卸し
・理想の顧客像やターゲット市場を営業と共通認識にする
・行動指標と属性指標を組み合わせてMQL条件を設計する
・商談化率や受注率を見ながらSQL条件を微調整していく
・マーケと営業の合意プロセスを文書化し定期的に見直す
・リードスコアリングはシンプルに始めて運用で磨き込む
・部門間で「量か質か」の期待値をすり合わせておく
・MQLを放置すると機会損失が増えるため追客設計が重要
・SQLの定義が厳しすぎるとパイプラインが細くなりがち
・定義は業種や商材単価により最適解が変わると理解する
・指標だけでなく現場の感覚や商談メモも定期的に共有する
・MQLとSQLの違いを共有し全員が同じ地図で会話できる状態にする