「MQLとSQLの違いがよく分からないまま、社内の会議で言葉だけが飛び交っている」「マーケティング部門が渡したリードを営業部門がフォローしてくれない」——BtoBマーケティングやインサイドセールスの現場では、こうした悩みが繰り返し起こります。原因の多くは、リードの定義が部門間で共有されていないことにあります。この記事では、MQLとSQLそれぞれの定義や判断基準の違い、MAL・SAL・TQLといった関連用語、MQLからSQLへつなげる具体的な方法、そして運用でつまずきやすい課題と解決のポイントまでを解説します。
MQLとは
MQL（Marketing Qualified Lead）の定義
MQLとは「Marketing Qualified Lead」の略で、日本語にすると「マーケティング部門が有望だと判断した見込み顧客」を指します。マーケティング活動によって獲得したリードのうち、一定の条件を満たし、営業部門に引き渡す価値があると評価された層がMQLです。
ここで重要なのは、獲得したリードすべてがMQLになるわけではないという点です。展示会で名刺交換した相手、資料をダウンロードしただけの担当者、メルマガに登録しただけの個人——これらは「リード」ではあってもMQLとは限りません。自社のターゲットに合致する企業・役職であること、購買につながりそうな行動が見られることといった条件をクリアして初めて、MQLとして扱われます。
MQLの判断には、一般的に次の2つの軸が使われます。
| 軸 | 内容 | 具体例 |
|---|---|---|
| 属性（デモグラフィック） | 企業や担当者そのものの情報 | 業種、従業員規模、売上規模、役職、部署、地域 |
| 行動（ビヘイビア） | サイト上や施策への反応 | 資料請求、料金ページの閲覧、ウェビナー参加、メール開封・クリック、複数回の再訪問 |
たとえば「従業員300名以上の製造業で、部長職以上の担当者が、料金ページと導入事例ページを閲覧した」といった条件を満たしたリードをMQLとする、という設計が考えられます。属性だけが合っていても興味がなければ商談にはつながらず、逆に行動が活発でも自社のターゲット企業から外れていれば受注可能性は低くなります。両方を組み合わせて評価する点が、MQL判定の基本的な考え方です。
MQLの主な獲得経路
MQLの元になるリードは、さまざまな施策から生まれます。代表的な獲得経路は次のとおりです。
- オウンドメディア・SEO記事：課題を検索している段階の潜在層と接点を持てる。資料ダウンロードやメルマガ登録に誘導する導線とセットで運用する
- ホワイトペーパー・お役立ち資料：ダウンロード時にフォーム入力を求めることで、企業名や役職といった属性情報を取得できる
- ウェビナー・セミナー：参加そのものが強い関心のシグナルになる。参加後アンケートでニーズや検討状況を聞ける
- Web広告（リスティング広告・ディスプレイ広告・SNS広告）：短期間でまとまった量のリードを獲得しやすい
- 展示会・カンファレンス：一度に大量の名刺を獲得できるが、温度感にばらつきが大きい
- 問い合わせフォーム・資料請求：ニーズが顕在化している可能性が高く、優先度の高い経路
これらの経路から集まったリードに対して、マーケティング部門がスコアリングやセグメントによって選別をかけ、条件を満たしたものをMQLとして営業部門やインサイドセールスへ引き渡します。逆にいえば、獲得経路が違えばリードの質も違うため、経路ごとにMQLへの転換率を計測しておくと、どの施策に投資すべきかの判断がしやすくなります。
SQLとは
SQL（Sales Qualified Lead）の定義
SQLとは「Sales Qualified Lead」の略で、営業部門が「商談を進める価値がある」と判断した見込み顧客を指します。データベースの問い合わせ言語であるSQL（Structured Query Language）とは全く別の用語なので、社内で会話する際は文脈に注意が必要です。
SQLの特徴は、ニーズが顕在化しており、購買意欲が高く、受注により近い位置にいることです。MQLが「マーケティング部門から見て有望」という段階であるのに対し、SQLは営業担当が実際にコンタクトを取り、ヒアリングを通じて確度を確かめた段階を指します。マーケティング部門の評価はあくまでWebサイト上の行動や登録情報という間接的なデータに基づくものですが、SQLの判断は会話によって得られた一次情報に基づきます。この情報の質の差が、両者の決定的な違いです。
SQLと判断されるまでのプロセス
MQLがSQLになるまでには、通常いくつかのステップを踏みます。
- MQLの引き渡し：マーケティング部門が条件を満たしたリードを営業部門・インサイドセールスへ渡す
- 初回アプローチ：電話やメールでコンタクトを取り、状況をヒアリングする
- ヒアリングによる確度判定：課題の有無、予算、決裁プロセス、検討時期などを確認する
- SQLとして認定：商談化できると判断されたリードを、案件としてパイプラインに登録する
この確度判定でよく用いられるのが「BANT条件」というフレームワークです。BANTは以下の4項目の頭文字を取ったものです。
| 項目 | 英語 | 確認する内容 | 質問例 |
|---|---|---|---|
| 予算 | Budget | 導入に充てられる予算があるか | 「この課題の解決に、どの程度の投資を想定されていますか」 |
| 決裁権 | Authority | 担当者が決裁者か、決裁ルートはどうなっているか | 「導入を進める場合、どなたの承認が必要になりますか」 |
| 必要性 | Needs | 解決したい課題が明確にあるか | 「現状、どのような点に困っていらっしゃいますか」 |
| 導入時期 | Time frame | いつまでに導入したいか | 「いつ頃からの稼働をお考えですか」 |
4項目すべてが揃っていれば確度は非常に高いといえますが、実務上はすべてが初回で明らかになるとは限りません。近年は「BANTだけでは購買プロセスの複雑化に対応しきれない」という指摘もあり、課題の深さや社内の推進体制を重視する考え方も広がっています。自社の商材や商談サイクルに合わせて、確認する項目を調整するのが現実的です。
MQLとSQLの違い
判断する部門の違い
MQLとSQLの最も分かりやすい違いは、誰が判断するかです。MQLはマーケティング部門が判断し、SQLは営業部門（またはインサイドセールス）が判断します。同じリードであっても、見ている情報と評価の目的が異なるため、判断が食い違うことも珍しくありません。
マーケティング部門は「量」の観点から、より多くの有望リードを創出することを目指します。一方、営業部門は「質」の観点から、限られた工数を確実に受注できそうな案件に集中させたいと考えます。この立場の違いを理解しておくと、部門間の摩擦の背景が見えてきます。
判断基準の違い（比較表）
MQLとSQLの違いを整理すると次のようになります。
| 比較項目 | MQL | SQL |
|---|---|---|
| 正式名称 | Marketing Qualified Lead | Sales Qualified Lead |
| 日本語での意味 | マーケティング部門が認定した見込み顧客 | 営業部門が認定した見込み顧客 |
| 判断する部門 | マーケティング部門 | 営業部門・インサイドセールス |
| 判断の材料 | 属性データ、Web行動履歴、スコアリング結果 | 会話によるヒアリング内容、BANT情報 |
| 購買意欲の段階 | 関心はあるが検討は初期〜中期 | ニーズが顕在化し、検討が具体化 |
| 受注までの距離 | 遠い〜中程度 | 近い |
| 主な次アクション | ナーチャリング、インサイドセールスによる架電 | 商談設定、提案、見積提示 |
| 代表的なKPI | MQL創出数、MQL単価、MQL→SQL転換率 | 商談化数、受注率、受注金額 |
| 使用する主なツール | MA（マーケティングオートメーション）ツール | SFA（営業支援システム）、CRM |
MQLとSQLは対立する概念ではなく、リードが受注に近づいていく過程における「段階」の違いです。MQLからSQLへ、そして商談・受注へと進むプロセス全体を可視化することで、どの段階で歩留まりが落ちているのかが分かり、改善すべき施策も明確になります。
なお、MQLからSQLへどれだけ転換したかを示すのが「MQL→SQL転換率」で、計算式は「SQLになった件数 ÷ MQL総数 × 100（%）」です。この数値は業界や商材、そもそものMQLの定義によって大きく変動するため、他社の数値を無理に目標として設定するより、自社で四半期ごとに実績を測定し、ベースラインを作ったうえで改善していく方が実践的です。
MQL・SQLと合わせて知っておきたい関連用語（MAL・SAL・TQLなど）
リードの成熟度を表す用語はMQLとSQLだけではありません。リードが獲得されてから受注に至るまでの流れを段階的にモデル化したものを「デマンドウォーターフォール」と呼び、その各段階に名前がついています。滝（ウォーターフォール）のように上から下へリードが絞り込まれていくイメージです。
| 用語 | 正式名称 | 意味 | 主な担当 |
|---|---|---|---|
| MAL | Marketing Accepted Lead | 重複やノイズを除去し、マーケティング活動の対象として受け入れたリード | マーケティング |
| MQL | Marketing Qualified Lead | 一定条件を満たし、営業に渡す価値があるとマーケティングが判断したリード | マーケティング |
| TQL | Teleprospecting Qualified Lead | 電話などのフォローを通じて、インサイドセールスが有望と判断したリード | インサイドセールス |
| SAL | Sales Accepted Lead | 営業部門がフォロー対象として受け入れたリード | 営業 |
| SQL | Sales Qualified Lead | 営業が商談化できると判断したリード | 営業 |
| PQL | Product Qualified Lead | 無料トライアルやフリーミアムでプロダクトを実際に使い、利用行動から有望と判断されたリード | プロダクト・営業 |
MALはデマンドウォーターフォールの最上流に位置づけられ、MQLへ育てる前段階として機能します。獲得したままの生のリストには重複や記入ミス、対象外の企業が混ざっているため、それらを整理して「これから育てていく母集団」として確定させる工程がMALにあたります。
SALは見落とされがちですが重要な段階です。マーケティングがMQLとして渡しても、営業側が「これは自社の対象外だ」と判断すれば差し戻されることがあります。SALは「営業が受け取ることに同意したリード」であり、ここを明示的に管理することで、部門間の押し付け合いを防げます。
PQLは、無料トライアルやフリーミアムモデルを持つSaaS企業でよく使われる指標です。広告やメールへの反応ではなく、プロダクトを実際に使った行動データ（利用頻度、招待したメンバー数、特定機能の使用回数など）をもとに判断するため、購買意欲の推定精度が高いとされています。プロダクトの体験そのものが購買の後押しになるため、営業の工数を抑えながら受注につなげやすい点が特長です。
すべての用語を自社に導入する必要はありません。組織の規模や商材、インサイドセールス部門の有無に応じて、必要な段階だけを定義すれば十分です。むしろ段階を細かく作りすぎると管理コストが上がり、形骸化する原因になります。
MQLからSQLへつなげる方法
MQLをSQLへと引き上げるプロセスは、大きく3つのステップに分けて考えると整理しやすくなります。
リードジェネレーション（見込み顧客の獲得）
まずは母数となるリードを獲得する段階です。ここで意識したいのは、単に数を追わないことです。ターゲットから外れたリードをいくら集めても、MQL・SQLへの転換にはつながらず、ナーチャリングの工数だけが増えていきます。
質の高いリードを集めるには、コンテンツの設計が鍵になります。汎用的な入門資料は幅広い層を集められる一方で温度感は低くなりがちです。逆に「導入事例集」「他社比較資料」「料金の考え方」といった検討段階に近いコンテンツは、獲得数は少なくても購買意欲の高い層を引き寄せます。両者をバランスよく用意し、どのコンテンツからのリードがSQLに転換しやすいかを継続的に分析することが、施策改善の土台になります。
リードナーチャリング（見込み顧客の育成）
獲得したリードのすべてが、すぐに購買を検討しているわけではありません。情報収集を始めたばかりの層や、社内の予算がつくのを待っている層が大半を占めます。こうしたリードに対して、有益な情報を継続的に届けて信頼関係を築き、購買意欲を高めていく活動がリードナーチャリングです。
具体的な施策としては、次のようなものが挙げられます。
- ステップメール／シナリオメール：資料ダウンロードから数日おきに、関連する情報を段階的に配信する
- メルマガ：定期的な接触で自社の存在を思い出してもらう
- オウンドメディアでの情報提供：課題解決に役立つ記事を発信し、再訪問を促す
- ウェビナー・勉強会の案内：まとまった時間の接触機会をつくり、関心度を測る
- インサイドセールスによる架電：メールでは分からない検討状況を直接ヒアリングする
- リターゲティング広告：一度接点を持ったリードに広告で再アプローチする
ナーチャリングで重要なのは、リードの状態に合わせて内容を出し分けることです。全員に同じメールを送るのではなく、業種・役職・過去の閲覧履歴などでセグメントを分け、それぞれに合った情報を届けることで反応率が上がります。
リードクオリフィケーション（見込み顧客の絞り込み）
ナーチャリングによって温まったリードの中から、営業がアプローチすべき対象を選び出す工程がリードクオリフィケーションです。ここでMQLが確定し、営業部門への引き渡しが行われます。
実務では、おおむね次のような手順で進めます。
- 業種・企業規模・役職などの条件でリードをセグメントする
- カスタマージャーニーを整理し、購買に近づく行動を洗い出す
- その行動をもとにシナリオを設計する
- 属性と行動にスコアを割り当て、スコアリングを設計する
- 基準スコアを超えたリードを営業担当へ引き渡す
- 引き渡し後の商談化率・受注率を分析し、基準を見直す
スコアリングの設計では、最初から完璧を目指さないことが大切です。「料金ページ閲覧＝20点」「ウェビナー参加＝15点」といった配点は、運用してみないと妥当性が分かりません。まず仮の基準で運用を始め、実際にどのスコア帯のリードが商談化したかを検証しながら調整していく進め方が現実的です。また、時間の経過とともにスコアを減点する「スコアの減衰」を組み込むと、半年前の行動で高得点が残り続けるといった不具合を防げます。
MQL・SQL運用でよくある課題
定義があいまいで部門間の認識がずれる
最も多い課題が、MQL・SQLの定義が明文化されていないケースです。マーケティング部門は「資料をダウンロードした人はMQL」と考え、営業部門は「予算と時期が決まっている人でなければ意味がない」と考えている——このような認識のずれがあると、リードを渡すたびに不満が生まれます。
「マーケが渡すリードの質が低い」「営業がリードをフォローしてくれない」という双方の不満は、多くのBtoB企業で共通して見られます。その根本原因は、リードの定義と引き渡し基準、フォローのプロセスが文書化されていないことにあります。感覚や暗黙の了解で運用している限り、この問題は解決しません。
MQLが放置され機会損失になる
せっかく創出したMQLが、営業側で対応されないまま放置されるケースも頻発します。営業担当は目の前の商談対応に追われており、新規のリードへの初回アプローチは後回しになりやすいためです。
初回接触までの時間は、転換率に大きく影響します。MQL発生から24時間以内にアプローチできた場合と、それを超えた場合とで転換率に数倍の差が出るという調査結果もあり、対応速度は最優先で改善すべきポイントといえます。リードは検討している間に他社と接触し、比較検討が進んでいきます。連絡が遅れるほど、自社が選択肢から外れる可能性は高まります。
商談化しやすいSQLだけが優先されてしまう
営業部門にとっては、すでに確度の高いSQLに時間を使う方が短期的な成果につながります。その結果、MQL段階のリードへのアプローチが軽視され、中長期的な案件の芽が育たなくなるという構造的な問題が起こります。
短期的な受注は確保できても、パイプラインの上流が細っていけば、数か月後・数年後の売上が先細りします。MQLへのフォローは「今すぐの成果にはならないが、将来の商談をつくる投資」であるという共通認識を、組織として持つことが必要です。
MQLとSQLの連携を強化するポイント
部門間で判定基準をすり合わせる
まず取り組むべきは、マーケティング部門・インサイドセールス・営業部門の三者が同じテーブルについて、MQLとSQLの定義を文章に落とし込むことです。「どのような属性・行動を満たしたらMQLとするのか」「MQLを受け取った営業は、どの条件を確認できたらSQLとするのか」を、誰が読んでも同じ判断ができるレベルまで具体化します。
このとき有効なのが、過去に受注した顧客のデータを遡って分析する方法です。受注に至った企業がどの経路から入り、どのコンテンツを閲覧し、どのようなヒアリング結果だったかを洗い出すと、机上の空論ではない実データに基づいた基準を設計できます。定義は一度決めて終わりではなく、四半期ごとなど定期的に見直す前提で運用しましょう。
MAツール・SFAでスコアリングを仕組み化する
判定基準を決めても、人力で運用していては属人化し、判断がぶれます。MAツールを活用してスコアリングを自動化し、基準を超えたリードが自動的に営業へ通知される仕組みを整えると、判断の一貫性と対応スピードの両方が改善します。
MAツールには一般的に、Webサイトの閲覧履歴の記録、メールの開封・クリック計測、独自ルールでのスコア加算、条件に合致したリードの抽出とアラート通知といった機能が備わっています。さらにSFAやCRMと連携させ、営業側の商談進捗や受注結果をマーケティング側にフィードバックできる状態にしておくと、「どのMQLが実際に受注したのか」が可視化され、スコアリング基準の精度を継続的に高められます。
ツール導入時に注意したいのは、最初から複雑な設計をしないことです。細かすぎるシナリオやスコアルールは運用負荷が高く、誰もメンテナンスできなくなります。まずは重要な指標に絞って運用を始め、データが溜まってから精緻化していく方が定着しやすくなります。
部門間のSLA（合意）を設ける
SLA（Service Level Agreement）とは、もともとITサービスの品質保証で使われる用語ですが、マーケティングと営業の連携においては「どのようなリードを、どれだけの量、いつまでに、どのようにフォローするか」を部門間で取り決めた合意を指します。
たとえば次のような内容を、双方の責任として明文化します。
| 部門 | 合意する内容の例 |
|---|---|
| マーケティング部門 | 月間◯件のMQLを創出する／定義した属性・行動条件を満たしたリードのみを引き渡す／リードの獲得経路と行動履歴を添えて渡す |
| 営業・インサイドセールス部門 | 引き渡しから◯営業日以内に初回アプローチする／◯回は接触を試みる／対応結果とSQL判定の理由をシステムに記録する |
SLAを機能させるには、双方向のフィードバックの流れをつくることが不可欠です。営業からマーケティングへ「このリードは対象外だった」「このコンテンツ経由のリードは反応が良い」といった情報が戻ってくる仕組みがあれば、MQLの定義そのものを改善していけます。定例のミーティングで転換率や対応状況を一緒に確認する場を設けるのも有効です。
また、最初から完璧なSLAを作ろうとして議論が長引くより、6割程度の完成度で運用を開始し、実データを見ながら改善していく方が成果につながりやすいとされています。動かしながら直していく姿勢が、部門間連携の定着には向いています。
まとめ
MQL（Marketing Qualified Lead）はマーケティング部門が属性と行動データをもとに有望と判断した見込み顧客、SQL（Sales Qualified Lead）は営業部門がヒアリングを通じて商談化できると判断した見込み顧客です。両者は対立する概念ではなく、リードが受注に近づいていく過程の段階の違いを表しています。
周辺にはMAL・SAL・TQL・PQLといった用語があり、これらはデマンドウォーターフォールとしてリードの成熟度を段階的に整理したものです。自社の組織体制に必要な段階だけを定義すれば十分で、細かく作りすぎるとかえって形骸化します。
MQLからSQLへつなげるには、リードジェネレーション・リードナーチャリング・リードクオリフィケーションの3ステップを設計し、スコアリングによって引き渡しの基準を明確にすることが基本です。運用上の課題としては、定義のあいまいさによる部門間の認識のずれ、MQLの放置による機会損失、確度の高いSQLだけが優先されて上流の案件が育たないことが挙げられます。
これらを解決する鍵は、部門間で判定基準を文書としてすり合わせること、MAツールやSFAでスコアリングと通知を仕組み化すること、そしてSLAという形で双方の役割と期限を合意することです。定義とプロセスを可視化し、実データをもとに継続的に見直していく運用が、マーケティングと営業の連携を成果につなげます。