MQLとSQLの違いとは？BtoBで失敗しないリード定義
「MQL」と「SQL」という言葉は使っているのに、組織の中で定義がブレていませんか。マーケが渡したリードを営業が「使えない」と差し戻し、マーケは「営業がフォローしてくれない」と嘆く。BtoBの現場でよく見られるこの摩擦の根本原因は、MQL（Marketing Qualified Lead：マーケが営業に渡せると判断したリード）とSQL（Sales Qualified Lead：営業が受注確度ありと認めたリード）の定義と運用が揃っていないことにあります。本記事では両者の本質的な違い、ファネル全体像、業界平均値、組織的な定義不一致の要因、そして合意プロセスの設計方法までを、マーケ・営業責任者向けに体系的に整理します。
MQLとSQLの定義｜本質的な違いは「判定者」と「判定根拠」
MQLとSQLはどちらも「見込み客（リード）」を分類する用語ですが、決定的に違うのは「誰が」「何をもって」判定するかという点です。MQLはマーケティング部門がスコアや行動履歴を根拠に「営業に渡せる」と判断したリード、SQLは営業部門がヒアリングを通じて「受注確度がある」と認定したリードを指します。両者を混同したまま運用すると、引き渡し基準が曖昧になり、リードの放置や部門間の対立を招きます。
MQL（Marketing Qualified Lead）とは
MQLは、資料ダウンロード・ウェビナー参加・メール反応などのマーケティング施策を通じてナーチャリング（顧客育成）され、マーケティング部門が「営業に引き渡してよい」と判断したリードです。判定根拠はMA（マーケティングオートメーション）ツール上の属性スコアと行動スコアであり、人手の介在なくシステマティックに判定されることが特徴です（アドエビス）。
SQL（Sales Qualified Lead）とは
SQLは、MQL（または直接の問い合わせ）のうち、営業部門が初回ヒアリングを行い「受注確度が高い」と認めたリードです。BANT条件（Budget／Authority／Needs／Timeframe：予算・決裁権・ニーズ・導入時期）が見えはじめている状態が典型で、判定者は営業担当者本人になります（Salesforce）。
MQLとSQLの比較表
| 項目 | MQL | SQL | 出典 |
|---|---|---|---|
| 判定者 | マーケティング部門 | 営業部門 | アドビ |
| 判定根拠 | 属性スコア＋行動スコア | 営業ヒアリング（BANT等） | HubSpot |
| 状態 | 興味・関心が一定水準に到達 | ニーズ顕在化・予算/時期が見える | Salesforce |
| 運用責任 | MA上で自動昇格 | 初回ヒアリング後に手動認定 | アドエビス |
リードファネルの全体像｜Lead→MAL→MQL→SAL→SQL→Opportunity
MQLとSQLは、より大きなBtoBリードファネルの一部です。標準的にはLead（獲得）→MAL（Marketing Accepted Lead）→MQL→SAL（Sales Accepted Lead）→SQL→Opportunity（商談）→Closed Won（受注）という6〜7段階で捉えます。MQLとSQLの間に「SAL」を挟むのが海外のHubSpot文脈では標準で、ここの設計が抜けていると「マーケが渡したのに営業が受け取らない」状態が見えなくなります（BtoB Sales DX）。
MAL／SALを挟む意味
MALは「マーケ施策の対象として有効」とマーケが認めたリード（最低限の属性が揃っている状態）、SALは「営業が自分の活動対象として受領した」リードです。SALの段階で「情報が足りない」「ターゲット外」として差し戻しが発生します。SALを設けることで、マーケから営業への引き渡しが一方通行ではなく、双方向の合意プロセスとして可視化されます（シャノン）。
理想は「MQL≒SAL」
ファネル運用の理想状態は「MQL数≒SAL数」、つまりマーケが渡したリードがほぼそのまま営業に受け入れられている状態です。ここに乖離が出ているなら、MQLの基準が営業の感覚と合っていないサインです。MQLとSALの差分は、部門間摩擦の最初の起点になります（BtoB Sales DX）。
業界平均と転換率の目安｜MQL→SQLはどのくらい通るのか
MQL→SQLの転換率は、自社の運用が機能しているかを測る基本指標です。グローバルのベンチマーク値は次のとおりで、自社数値と照らし合わせる出発点として有用です（Growthspree 2026 Benchmarks）。
| セグメント | MQL→SQL転換率 | 出典 |
|---|---|---|
| 全業界平均 | 約13% | Growthspree |
| B2B SaaS平均 | 18〜22% | Growthspree |
| B2B SaaSトップ層 | 25〜35% | Growthspree |
| 行動ベースICPスコアリング採用 | 39〜40%（事例値） | Growthspree |
フォローアップ速度がすべてを決める
転換率を最も大きく左右するのは、リード鮮度＝フォローアップ速度です。MQLが発生してから24時間以内に営業がアプローチできた場合、転換率は53%まで上がる一方、24時間を超えると17%まで低下するという調査結果があります（Growthspree）。スコアリングの精緻化よりもまず、引き渡し速度のSLA（Service Level Agreement：部門間合意）を整えることが転換率改善の最短ルートです。
日本のベンチマーク値は限定的
日本のBtoBに限定した公的ベンチマーク数値は限定的なため、海外数値はあくまで「目安」として扱い、自社で四半期ごとに基準値（ベースライン）を作る運用が現実的です。重要なのは絶対値の比較ではなく、自社の前四半期との差分を追うことです。
プロレクトが見ている「MQLが商談化する企業の共通点」
プロレクトがBtoB企業のリード運用を支援する中で見えてきたのは、MQL→SQL転換率が高い企業ほど「スコアの精緻化」よりも「引き渡し直後のオペレーション」を磨いているという傾向です。具体的には、MQL発生をSlackやメールで営業担当者個人に即時通知する仕組み、初回コンタクトのトークスクリプトを営業・マーケ合同で作り込んでいる体制、そして差し戻し理由をCRMに必須入力させてマーケへ自動フィードバックする運用が共通しています。逆に、転換率が伸び悩む企業の多くは「MQLの定義を厳しくすれば質が上がる」と考えがちですが、実際はMQL発生後の数時間の対応で勝負が決まっているケースが大半です。
定義不一致が起きる組織的要因5層
MQL/SQLの定義がブレる根本原因は、個人のスキルではなく組織構造にあります。現場で発生する対立は、以下の5層が積み重なって生じます。
5つの組織的要因
- KPI構造の不一致：マーケはリード数（量）、営業は受注額（質）を追うため、追う数字の方向が逆を向く（sellsup）。
- フィードバックループの不在：差し戻しの理由が営業からマーケに戻らず、「使えないMQL」が量産され続ける（営業DX.jp）。
- 別レポートライン・別評価制度：マーケはCMO配下、営業はCRO配下で共通の上位指標を持たず、相互協力のインセンティブがない（innova）。
- 用語解釈のばらつき：同じ「MQL」でも、A社では「資料DL者全員」、B社では「スコア80点以上＋部長以上」と幅があり、議論が噛み合わない（Sansan）。
- リード品質に対する認識のすり合わせ不足：マーケは「資料DL＝検討意向あり」と捉え、営業は「資料DLは情報収集に過ぎず商談化しない」と捉えるなど、評価軸そのものが異なる（List Finder）。
典型的な対立の構図
これら5層が重なると、現場では次のような対立が定着します。マーケ側は「営業がMQLを放置している、フィードバックをくれない」と訴え、営業側は「マーケのリードは質が低い、無駄打ちが多い」と返す。どちらの主張も部分的には正しく、根本原因は「共通の判定基準とSLAの欠如」にあります（sellsup）。
プロレクトが現場で見ている「定義合意で詰まる場面の解きほぐし方」
プロレクトが多くのBtoB組織でMQL/SQL定義の合意プロセスを伴走してきた経験からお伝えすると、合意会議が詰まる場面はほぼ決まっています。「マーケが提示した属性条件に営業が首を縦に振らない」「営業の理想像を聞くと条件が厳しすぎてMQLが月10件も出ない」「過去の失注リードを見ると基準が当てはまらない」の3つです。これを解きほぐす実務的なコツは、議論の出発点を「定義」ではなく「過去6カ月で受注した10件のリード行動履歴」に置くことです。受注実績から逆算してMQL条件を可視化すると、両部門の主観論を排除できます。さらに、最初から完璧な基準を作ろうとせず、まず「3カ月運用してレビューする」というレビュー期間を合意項目に含めることで、心理的ハードルを下げられます。
合意プロセスとSLA共同設計｜マーケ単独定義は失敗する
定義不一致を解消する核は、SLA（Service Level Agreement：マーケと営業が互いの責任を明文化する合意書）を双方向で締結することです。マーケが営業に「月◯件のMQLを渡す」、営業がマーケに「受領後24時間以内に初回コンタクトする」といった定量的な約束を交わします（bizboost）。
合意プロセスの鉄則
進め方の鉄則は「営業のニーズを先にヒアリングする」ことです。「どんなリードなら今すぐ動けるか」を営業に言語化させてから、その内容をMQL基準に反映させます。マーケが単独で基準を決めて営業に提示する流れは、ほぼ確実に失敗します。HubSpot調査でも、マーケと営業がアラインしている企業はそうでない企業に比べ成約率・収益成長で優位という結果が出ています（HubSpot）。
定例レビューで「生もの」として運用する
合意したMQL定義は、一度決めて放置するものではなく、月次〜四半期で必ずレビューしましょう。最低限見るべき4指標は、受け取り率・差し戻し率・商談化率・差し戻し理由です。差し戻し理由をCRMに記録し、合同レビュー会で基準を更新するサイクルを回すことで、定義は「生もの」として進化します（ファネルAi）。
Smarketingという考え方
「マーケと営業を統合運用する『Smarketing』では、共有目標・共有データ・定例コミュニケーションの3点が必須」
HubSpot - The Power of Smarketing
HubSpotが提唱するSmarketing（Sales＋Marketing）は、両部門を別組織と捉えず、「商談化数」や「パイプライン金額」など共有できる上位KGI（重要目標達成指標）を設定して一体運用する思想です。RevOps（Revenue Operations：収益オペレーション統合）の発想とも重なり、現代BtoBの基本形になりつつあります。
本記事の執筆元について
本記事を執筆しているプロレクトは、BtoB企業のセールス・ナーチャリング設計とリード運用の伴走を専門としています。MQL/SQLの定義合意、SLA設計、MA・CRM・SFAのデータ統合、そして部門横断のレビュー運用まで、組織の中で「営業とマーケの言葉が噛み合う状態」を作り出すことを使命としています。
これまで支援してきた企業に共通するのは、「ツールを入れる」ことよりも「定義と運用を揃える」ことの方が圧倒的にインパクトが大きいという気づきでした。本記事で紹介したフレームや指標は、プロレクトの現場知見を凝縮したものです。自社の現状を整理したい、合意プロセスをどう始めればよいか相談したいというお悩みがあれば、まずは無料相談からお気軽にご利用ください。
まとめ｜定義を揃え、SLAで運用し、レビューで更新する
MQLとSQLの違いの本質は「判定者」と「判定根拠」の差にあり、MQLはマーケが属性・行動スコアで判定するリード、SQLは営業がヒアリングで認定するリードです。両者を機能させる鍵は、マーケ単独で定義しないこと、SLAで双方向の責任を明文化すること、そして月次のレビューで基準を更新し続けることに尽きます。
- MQLとSQLの違いは「判定者」と「判定根拠」。MQLはマーケがスコアで判定、SQLは営業がヒアリングで認定。
- ファネルはLead→MAL→MQL→SAL→SQL→Opportunityの6段階。理想はMQL≒SAL。
- MQL→SQL転換率の目安は全業界13%、B2B SaaS 18〜22%、トップ層25〜35%。
- フォローアップは24時間以内が分水嶺。53% vs 17%の差が出る。
- 定義不一致の組織的要因は5層（KPI不一致／フィードバック不在／別評価制度／用語解釈ばらつき／品質認識乖離）。
- 解決策はSLAの共同設計と定例レビュー。マーケ単独定義は失敗する。
自社のMQL/SQL定義を見直したい、営業とマーケの合意プロセスをどう始めればよいか相談したいという方は、プロレクトの無料相談をご活用ください。組織構造・KPI設計・SLA運用までを一気通貫で整理する伴走を行っています。