マーケティング部門が獲得したリードがなかなか商談につながらない、営業部門からは「渡されるリードの質が低い」と指摘される。BtoBマーケティングの現場では、こうした部門間の認識のズレに頭を悩ませる担当者が少なくありません。
その解決の鍵となるのが、MQLとSQLという二つのリード分類です。両者は単なる横文字ではなく、マーケティングと営業をつなぐ共通の判断基準として機能します。MQLとSQLを正しく設計・運用することで、商談機会の取りこぼしを防ぎ、限られた営業リソースを最も成約に近いリードへ集中させることが可能になります。
本記事では、MQLとSQLの定義、関連するリード分類用語、設計方法、MQLからSQLへ引き上げるナーチャリング手法、そして運用でつまずきやすい課題までを実務目線で解説します。マーケと営業の連携を強化したい担当者は、ぜひ最後までご一読ください。
目次
BtoBマーケティングの現場で頻出するMQLとSQLは、リードの状態を区分するための分類用語です。両者の違いを正しく押さえることで、マーケティングと営業の役割分担が明確になり、商談化までの道筋を組み立てやすくなります。
ここではMQLとSQLそれぞれの定義と、両者の違いを比較して整理します。
MQLとは、マーケティング部門が獲得・育成したうえで、商談化の見込みがあると判断したリードを指す用語です。
| 項目 | 内容 |
| 正式名称 | Marketing Qualified Lead |
| 担当部門 | マーケティング部門 |
| 判断基準 | 行動データのスコアリング |
| 行動例 | ホワイトペーパーのダウンロード、ウェビナー参加、料金ページの複数回閲覧 |
| 位置づけ | 購買検討の入口に立った見込み顧客 |
スコアリングと呼ばれる手法を用い、各行動に点数を付与して合計値が一定の閾値を超えたリードをMQLと位置づけるのが一般的です。MQLは、まだ営業が直接アプローチする段階ではなく、マーケティング側で育成中のリードという位置づけになります。インサイドセールスへ引き継ぐ前の段階に該当し、購買検討の入口に立った見込み顧客と理解しておくとよいでしょう。
SQLとは、営業部門が直接アプローチして商談化すべきと判断したリードを指す用語です。
| 項目 | 内容 |
| 正式名称 | Sales Qualified Lead |
| 担当部門 | 営業部門(インサイドセールス・フィールドセールス) |
| 判断基準 | BANT条件のヒアリング |
| BANT条件 | 予算(Budget)、決裁権(Authority)、ニーズ(Need)、導入時期(Timeframe) |
| 位置づけ | 商談化の準備が整ったホットリード |
これらの情報がインサイドセールスや営業のヒアリングを通じて確認され、商談化の確度が十分に高いと判断されたリードがSQLとして扱われます。SQLは、すでに商談化の準備が整い、フィールドセールスのクロージング対象となるホットリードです。MQLよりも一段階成熟した状態にあるリードと整理しておくと、運用時の判断がぶれにくくなります。
MQLとSQLという分類が広く使われる背景には、BtoB企業に共通する組織的な課題があります。マーケティングと営業がそれぞれ独立して動くことで、商談機会が取りこぼされたり、対立が生まれたりするケースが少なくありません。
ここでは、なぜMQLとSQLを明確に区分する必要があるのかを解説します。
部門間の認識のズレは、商談機会の損失に直結します。マーケティング部門は「リードを多く獲得した」と評価する一方、営業部門は「商談につながらないリードばかり」と感じる現象は、多くの企業で発生しています。
このズレの原因の多くは、両部門が「有望なリード」の定義を共有していないことにあります。マーケはホワイトペーパーDLを成果と捉えても、営業からすれば情報収集だけのリードはアプローチ対象外という判断になりがちです。結果として、せっかく獲得したリードが営業フォローを受けないまま放置され、競合に商談機会を奪われる事態を招きます。
MQLとSQLという共通用語を組織に導入することで、こうしたズレを構造的に解消できます。基準が言語化されれば、両部門で同じリードを見て同じ判断ができるようになり、機会損失の防止につながります。
MQLとSQLは、マーケと営業の間に立つ「共通言語」として機能します。部門ごとに別々の指標で評価するのではなく、同じ物差しでリードの成熟度を測れることが、両者の連携を円滑にする土台となります。
例えば、マーケが「MQLを月間で一定件数供給する」、営業が「MQLからSQLへの転換率を一定以上に保つ」といった形で目標を接続すれば、両部門が同じリードの動きを追えるようになります。マーケから引き継いだリードの行方が営業側でブラックボックス化することがなくなり、フィードバックループが回り始める仕組みを作れるのです。
また、共通言語があると、引き継ぎの際に「なぜこのリードは商談化しなかったのか」という会話が生まれやすくなります。原因が定量・定性の両面で把握できれば、リードの育成プロセスや営業のアプローチを改善する材料となり、組織全体の受注力が底上げされていきます。
MQLとSQLを定義し運用に組み込むことには、組織にとって複数のメリットがあります。営業効率の改善だけにとどまらず、マーケティング投資の評価や中長期的な売上機会の最大化にもつながる重要な仕組みです。ここでは主要なメリットを観点ごとに整理します。
MQLとSQLを設計する第一のメリットは、営業リソースを優先度順に投下できる点にあります。営業担当者の時間は有限であり、すべてのリードに同じ熱量で対応するのは現実的ではありません。
SQLとして定義した条件を満たすリードに対し、フィールドセールスのリソースを集中投下すれば、商談化率と受注率の双方を高められます。一方、まだ育成段階にあるMQLにはマーケティングオートメーションやインサイドセールスが対応し、購買意欲が高まったタイミングで営業に引き継ぐ運用が可能になります。
このような役割分担を組み立てることで、組織全体の営業生産性が向上します。営業が「すぐ売れるリード」に集中し、マーケが「将来の商談候補」を温めるという両輪体制が整い、機会損失を抑えながら受注規模を拡大できるようになります。
MQLとSQLを定義することで、マーケティング施策の貢献度が定量的に可視化できます。従来のマーケティング評価では、リード獲得数やWebサイトのPV数など、商談・受注から離れた指標で施策を測ることが多くありました。
MQLとSQLを導入すると、施策ごとに以下のような指標を追跡できるようになります。
例えばホワイトペーパーAは資料DL数が多いがSQL転換率が低い、ウェビナーBは参加者数こそ少ないが受注率が高いといった具合に、施策の質を比較評価する基盤が整います。
定量的な評価軸が揃えば、マーケティング予算の配分判断も精緻になります。費用対効果の高い施策へリソースを再配分する意思決定が、感覚ではなくデータに基づいて行えるようになるのです。
MQLとSQLを設計する第三のメリットは、中長期的な売上機会の最大化につながる点です。短期的な受注だけでなく、現時点では検討段階に至っていない見込み顧客の育成までを射程に入れたリード管理が可能になります。
検討段階の浅いリードを切り捨てるのではなく、MQLとして継続的にナーチャリングする体制を整えれば、半年後・一年後に予算化された際の第一想起企業として選ばれる確率が高まります。BtoBの購買サイクルは長期化する傾向にあるため、見込み客との関係性を絶やさない仕組みが事業成長の基盤となります。
また、MQLからSQLへ昇格する過程をデータとして蓄積していけば、自社にとって受注に至りやすいリードの典型像が見えてきます。この知見を新規リード獲得の施策設計に還元することで、マーケティング活動全体の精度が継続的に向上していきます。
MQLとSQLの効果を引き出すには、自社の事業特性に合わせた設計が欠かせません。他社の定義をそのまま流用しても運用には乗りにくく、現場で形骸化するリスクがあります。
ここでは、MQLとSQLを実務に落とし込む四つのステップを順に解説します。
設計の出発点は、自社にとっての「リード」と「商談化」の定義を整理することです。この前提が曖昧なまま先に進むと、MQL・SQLの基準が現場の実態と噛み合わない事態を招きます。
まずは過去に受注した顧客のデータを分析し、共通項を洗い出します。業界、企業規模、部署、役職、検討期間、初回接点の経路といった属性情報に加え、どのようなコンテンツに反応していたか、どのチャネル経由で問い合わせに至ったかといった行動データもあわせて確認しましょう。受注顧客の典型像を把握できれば、MQLとSQLそれぞれの輪郭が見えてきます。
あわせて、マーケと営業の双方が現場で「有望」と感じるリードの特徴をヒアリングし、暗黙知を言語化します。両部門の認識をすり合わせる対話のプロセス自体が、後続のステップで揺らがない設計を生む土台となります。
MQLは行動データを点数化するスコアリングで設計するのが一般的です。リードがとった行動ごとに点数を付与し、合計が閾値を超えた段階でMQLとして抽出する仕組みを組み立てます。
スコアリングの対象となる行動例は次のとおりです。
| 行動カテゴリ | 行動例 | スコア配分の考え方 |
| Webサイト行動 | 料金ページ閲覧、事例ページ閲覧、再訪問 | 購買意欲の表れとして高めに配分 |
| コンテンツ接触 | ホワイトペーパーDL、ブログ閲覧 | 関心の入口として中程度に配分 |
| イベント参加 | ウェビナー参加、展示会名刺交換 | 関与度に応じて配分 |
| 属性情報 | 業界、従業員規模、役職 | 自社のターゲット適合度で加点 |
スコアの初期値は仮置きで構わず、運用しながら受注実績と突き合わせて調整することが重要です。スコアリングは設計して終わりではなく、データを見ながら継続的にチューニングすることで精度が高まる仕組みである点を押さえておきましょう。
SQLは行動データだけでなく、ヒアリングを通じて確認するBANT条件で判断します。BANTはBudget(予算)、Authority(決裁権)、Need(ニーズ)、Timeframe(導入時期)の頭文字を取ったフレームワークで、商談化の確度を判断する標準的な指標として広く活用されています。
BANT条件の運用例は以下の通りです。
| 項目 | 運用例 |
| Budget(予算) | 導入予算が確保されている、もしくは予算化の見込みがある |
| Authority(決裁権) | 決裁権者または決裁プロセスの中心人物と接触できている |
| Need(ニーズ) | 解決したい課題が言語化されており、自社サービスで対応可能 |
| Timeframe(導入時期) | 導入検討時期が一定期間内に設定されている |
すべての条件を完全に満たすことを求めると基準が厳しくなりすぎ、SQLの絶対数が足りなくなる懸念があります。事業フェーズや営業リソースに応じて、何項目以上の充足でSQLとするかをチームで合意することが現場運用のコツです。
設計したMQL・SQLを機能させる最後のカギは、両部門での運用ルール合意にあります。基準を作っても、現場の運用が伴わなければ絵に描いた餅で終わります。
合意しておきたい主要なルールには次のようなものがあります。
特に重要なのは、引き継ぎから初回コンタクトまでの時間です。リードに最初に接触した企業が選ばれやすいというデータも示されており、対応スピードが受注率を左右します。マーケと営業が共通のSLA(Service Level Agreement)として運用ルールを文書化し、定例会で進捗を確認する体制を整えましょう。
MQLを獲得しても、自然にSQLへ昇格するわけではありません。リードの購買意欲を段階的に高めるナーチャリング(育成)の仕組みが必要です。
ここではMQLからSQLへ引き上げるための代表的な手法を、コンテンツ・配信・イベント・インサイドセールスの観点から解説します。
MQLの興味度を高める基本は、検討段階に応じたコンテンツの提供です。リードがどの段階にあるかを意識し、それぞれの関心に沿った情報を届けることで、購買検討を前進させられます。
コンテンツの設計は、認知段階・比較検討段階・意思決定段階の三層で考えるとシンプルです。認知段階では業界課題を整理した記事やホワイトペーパー、比較検討段階では自社サービスと競合の比較資料や導入事例、意思決定段階では費用対効果を試算できるシミュレーターや料金表が有効に機能します。
加えて、コンテンツは単発で消費されて終わるものではありません。リードが過去にどの資料を読み、どのウェビナーに参加したかといった履歴を蓄積し、次に提供すべきコンテンツを最適化する運用が、ナーチャリング成果を左右します。
リードナーチャリングについては以下の記事で詳しく解説しているので、ぜひ参考にしてみてください。
参考：リードナーチャリングとは？重要性や具体的な手法、成果を出すコツを解説
MAツールは、ナーチャリングを仕組み化するうえで欠かせない存在です。マーケティングオートメーションを活用すれば、リードの行動に応じてコンテンツやメールを自動配信できる体制を構築できます。
MAの主な活用シーンとしては、特定ページを閲覧したリードへ関連資料を自動送信する行動トリガー配信、ホワイトペーパーのダウンロードから一定期間後にフォローメールを配信するステップメール、リードの行動に応じてスコアが自動で加減されMQL閾値を超えた段階で通知が飛ぶスコアリング自動更新、件名や本文・配信時間を変えて反応率を比較する配信ABテストなどが挙げられます。
MAを導入する際の注意点は、ツール導入そのものを目的化しないことです。配信シナリオの設計とコンテンツの質が伴わなければ、MAは単なる配信ツールに終わります。シナリオ設計に時間を投じ、リードの検討段階に寄り添ったストーリーを組み立てることが成果を生む土台となります。
ウェビナーやセミナーは、MQLの購買意欲を一気に引き上げる強力な施策です。コンテンツ閲覧やメール開封といった受動的な接触に比べ、ウェビナー参加は能動性が高く、関心の濃さを示すシグナルとして機能します。
効果を出しやすいウェビナーの企画例として、業界課題を切り口にした基調講演型、自社サービスのデモを中心にした製品紹介型、既存顧客に登壇してもらう事例共有型などが挙げられます。テーマと対象リードを明確にして設計すれば、参加者のなかから商談意欲の高いリードを抽出しやすくなります。
ウェビナー終了後のフォロー設計も重要です。参加者を「質問が多かった層」「最後まで視聴した層」「途中離脱した層」などに分類し、それぞれの濃度に応じたフォローシナリオを用意することで、SQLへの昇格率が大きく変わります。
セミナーやウェビナーについては以下の記事で詳しく解説しているので、ぜひ参考にしてみてください。
参考：セミナーでのリードは獲得できる！おすすめの業種や獲得率、事例を紹介
参考：ウェビナーでリードは獲得できる！成果を最大化するコツや事例を解説
インサイドセールスは、MQLからSQLへ引き上げる最終工程を担う重要な役割です。MAやウェビナーで関心が高まったリードに対し、電話やオンライン面談を通じて購買検討の実態をヒアリングし、商談化の可否を判断します。
重視すべきは、BANT条件を機械的に確認するのではなく、相手の課題に深く踏み込んで対話することです。マニュアル通りのトークではリードが心を閉ざしてしまうため、業界知識と顧客理解を備えた担当者が、潜在ニーズまで引き出すヒアリングを行う必要があります。
加えて、初回接触のスピードが歩留まりを大きく左右します。MQL発生から5分以内に架電したケースの商談化率は圧倒的に高く、時間が経過するほど商談化率は下がる傾向にあります。MA通知から即時架電できる体制づくりが、ナーチャリング成果を最大化するポイントです。
自社内で即時架電体制と業界知識を兼ね備えたインサイドセールス組織を立ち上げるのが難しい場合は、月10万円から始められるカリトルくんのような営業代行の活用も選択肢に入ります。
インサイドセールスについては以下の記事で詳しく解説しているので、ぜひ参考にしてみてください。
参考：インサイドセールスとは？導入するメリットや成功のポイントを紹介
MQLとSQLを設計しても、運用フェーズで複数の壁にぶつかる企業は少なくありません。定義の揺らぎ、基準の硬直化、フィードバックの不在といった課題は、放置すると仕組み全体が形骸化してしまいます。
ここでは現場で頻発する三つの課題と、その対処法を解説します。
最も頻出する課題が、MQLとSQLの定義そのものが部門間で揃っていないという問題です。設計時には合意したつもりでも、運用が始まると現場の解釈にずれが生じ、いつの間にか別物になっているケースが見られます。
例えばマーケ側は「ホワイトペーパーをDLしたリードは全員MQL」と捉えているのに対し、営業側は「役職が部長以上で従業員規模が一定以上の企業のみがMQLとして意味がある」と考えているような状況です。こうしたズレは、引き継ぎ時の摩擦や「使えないリードばかり渡される」という不満につながります。
対処法は、定義を文書化したうえで定期的にレビューする運用を組み込むことです。月次や四半期で受注実績と突き合わせ、現実に即した形で定義を更新する仕組みがあれば、現場の感覚と運用基準が乖離する事態を防げます。
SQL基準を厳しく設計しすぎると、商談機会そのものが失われる問題が発生します。「決裁権者であること」「導入予算が今期中に確定していること」など、すべての条件を完全に満たすリードだけをSQLとする運用では、絶対数が足りずに営業活動が停滞します。
商談化の条件として、決裁権者のみ、商談時間が長時間確保できるリードのみ、初回アポで予算を捻出し即決できるリードのみといった厳しい条件を初期から課すと、アポの量が増えず結果として商談に至らないケースが多くなります。基準を緩和し、より多くの商談機会を獲得できるよう工夫することが重要です。
特に施策の立ち上げ初期は、量を確保しながら受注に至るパターンを見つけ、その共通項を基準に反映していく姿勢が求められます。最初から完璧な基準を作ろうとせず、運用しながら学習していく前提で設計しましょう。
営業に引き継いだリードのその後がマーケに共有されない、いわゆる「フィードバック断絶」も大きな課題です。営業側で商談化したのか、商談化しなかった場合は何が原因だったのかという情報が戻らなければ、マーケは施策を改善する材料を持てません。
この課題を解消するには、フィードバックを営業の業務フローに組み込むことが有効です。商談ステータスの更新ルール、失注時の理由入力、月次の振り返り会議といった形で、リードのその後を可視化する仕組みを整えましょう。CRMやSFAツールを活用し、マーケと営業が同じデータを見られる環境を作ることも効果的です。
加えて、商談の録音データや一次情報を共有する文化づくりも重要です。実際の顧客の反応や担当者の話し方といった文字や伝聞では伝わらない情報を、リアルタイムに近いタイミングで把握できれば、より精度と鮮度の高い改善サイクルが回ります。
MQLとSQLは、マーケティングと営業をつなぐ共通言語として、BtoB企業のリード管理に不可欠な分類です。MQLは行動データに基づく育成中の見込み顧客、SQLはBANT条件を満たした商談準備の整ったリードと位置づけられ、両者を明確に区分することで部門間の認識のズレや商談機会の取りこぼしを防げます。
設計にあたっては、自社のリード定義を整理し、MQLのスコアリング条件とSQLのBANT基準を組み立て、運用ルールをマーケと営業で合意する四つのステップが基本形です。さらにMQLからSQLへ昇格させるためには、コンテンツマーケティング、MA配信、ウェビナー、インサイドセールスといった施策を段階的に組み合わせるナーチャリング設計が成果を左右します。
運用後も定義の食い違いや基準の硬直化、フィードバック断絶といった課題は発生しがちですが、文書化と定期レビュー、CRMでのデータ共有、商談一次情報のフィードバックを徹底すれば、仕組みは継続的に改善していきます。MQLとSQLという共通言語を軸に、マーケと営業の連携を強化し、中長期的な売上機会の最大化を実現していきましょう。
MQLからSQLへの引き上げを担うインサイドセールスを外部の伴走で強化したいなら、月10万円から始められるカリトルくんが有力な選択肢です。即時架電・BANTヒアリング・録音データの全件共有まで対応していますので、まずは無料相談からお気軽にご検討ください。
