MQLやSQLという言葉は、BtoBマーケティングや営業の現場ではすでに当たり前のように使われています。
しかし実際には、「MQLは増えているのに商談につながらない」「営業からリードの質が低いと言われる」といった悩みを抱えている企業は少なくありません。
その原因は、用語の理解不足ではなく、MQLとSQLを“どう設計しているか”にあります。
本記事では、MQLとSQLの基本を整理したうえで、なぜ現場で機能しなくなるのかを実務目線で解説します。
Contents
MQLとSQLとは？混同されやすい基本の考え方
MQLとは何か｜マーケティング視点での役割
MQL（Marketing Qualified Lead）とは、マーケティング部門が「営業に検討してほしい」と判断した見込み顧客を指します。
資料請求、セミナー参加、サイト閲覧などの行動データや属性情報をもとに、一定の条件を満たしたリードがMQLとして扱われます。
重要なのは、MQL＝受注確度が高いリードではないという点です。
MQLはあくまで「営業が次のアクションを取る価値がある状態」に整理されたリードであり、マーケティング活動の中間地点にあたります。
SQLとは何か｜営業視点での役割
SQL（Sales Qualified Lead）とは、営業部門が「商談として進める」と判断した見込み顧客です。
ヒアリングや初回接触を通じて、課題の有無や導入時期、決裁体制などが確認され、営業リソースを投下する価値があると判断された状態を指します。
SQLは、マーケティング基準ではなく、営業の意思決定によって初めて成立する点が特徴です。
そのため、MQLとSQLは同じ評価軸で並べて扱うものではありません。
MQLとSQLの違いが分からなくなる理由
定義はあるのに現場で使われない理由
多くの企業では、MAツールやCRM上にMQL・SQLの定義が設定されています。
それにもかかわらず、定義があっても現場では使われていません。
理由は、定義が“運用のための言葉”になっていないからです。
「スコアが◯点以上だからMQL」「営業がステータスを変更したらSQL」といった形式的なルールだけが先行し、
なぜその基準なのか、何を判断してほしいのかが共有されていないケースが多く見られます。
営業とマーケで評価軸がズレる原因
マーケティングは「条件を満たしたかどうか」でリードを評価します。
一方、営業は「受注につながる可能性があるか」でリードを見ています。
この評価軸の違いを前提に設計されていないと、
- マーケは「条件は満たしている」
- 営業は「商談にならない」
というすれ違いが起こります。
MQLとSQLの混乱は、部門間の認識ズレがそのまま表面化した結果とも言えます。
MQLとSQLは「定義」ではなく「設計」の問題
MQLはゴールではなく営業判断のスタート地点
MQLをKPIとして追いすぎると、MQLを作ること自体が目的化してしまいます。
本来MQLは、営業判断をスムーズにするための「整理された入口」にすぎません。
「このリードは、どんな課題を持っていそうか」
「次に営業が何を確認すべきか」
こうした情報が揃って初めて、MQLは意味を持ちます。
SQLは成果ではなく営業が時間を使う意思決定
SQLは「成果」や「ゴール」と誤解されがちですが、実際には営業が時間を投下するかどうかの意思決定です。
SQL化されたからといって、受注が約束されるわけではありません。
重要なのは、SQLが営業の判断として納得感を持って付けられているかどうかです。
この前提が欠けると、SQLは単なるステータス変更になってしまいます。
よくあるMQL・SQL設計の失敗パターン
スコアだけでMQLを決めている
行動スコアだけでMQLを判断すると、温度感や背景が見えないリードが量産されます。
スコアはあくまで判断材料の一つであり、それだけで営業判断を代替することはできません。
MQL数をKPIにしてしまっている
MQL数を成果指標にすると、質より量を優先する運用になりがちです。
結果として、営業にとって使えないリードが増え、部門間の不信感につながります。
営業の判断基準がブラックボックス化している
営業側が「これは商談にならない」と判断しても、その理由が共有されないケースは多くあります。
この状態では、マーケティングは改善のしようがありません。
SQL化・非SQL化の理由を言語化し、共有する設計が不可欠です。
MQLからSQLにつなげるための設計ポイント
MQLとSQLの役割を言語化する
まず必要なのは、「言葉の定義」ではなく「判断の翻訳」です。
「MQLとは何か」「SQLとは何か」を定義文として書くのではなく、
- MQLは営業に何を判断してほしい状態なのか
- SQLはどんな意思決定が行われた結果なのか
を明確にします。
この整理がないまま数値やルールを決めても、現場では機能しません。
営業と合意すべき判断ラインとは
MQLからSQLへの移行は、マーケティングが決めるものではありません。
営業が「この条件なら商談として進められる」と納得できるラインを合意することが重要です。
ここでのポイントは、完璧な基準を作ろうとしないことです。
まずは
- この状態なら一度話を聞いてもいい
- この情報が揃っていれば初回接触できる
といった最低ラインを共有することから始めます。
数値と行動情報をどう組み合わせるか
スコアリング自体が悪いわけではありません。
重要なのは、数値だけで判断しない設計にすることです。
例えば
- スコア（行動量・頻度）
- 行動内容（どの資料を見たか、どのテーマに反応したか）
- 属性情報（業種・役職・企業規模）
を組み合わせて、「なぜMQLなのか」が説明できる状態を作ります。
これにより、営業は次のアクションを具体的にイメージできます。
MQL・SQL設計を改善すると何が変わるのか
営業とマーケの会話が変わる
設計が整理されると、会話の内容が
「このリードはダメ」「質が低い」
といった感情論から、
「この条件だとSQLになりにくい」「この情報が足りない」
という建設的な議論に変わります。
MQLとSQLが、責任の押し付け合いではなく、改善のための共通言語になります。
リード評価が感覚から共通言語になる
属人的な判断が減り、誰が見ても同じ基準で話せる状態になります。
結果として
- リードの優先順位が明確になる
- 営業の初動が早くなる
- マーケ施策の改善点が見えやすくなる
といった効果が生まれます。
よくある質問（FAQ）
MQLとSQLの基準は業界で決まっている？
決まっていません。
MQL・SQLは業界共通の正解がある指標ではなく、自社の営業プロセスに合わせて設計するものです。
他社事例は参考になりますが、そのまま流用してもうまくいかないケースがほとんどです。
MAツールがあれば自動で解決できる？
解決できません。
MAツールは設計を実行・管理するための手段であり、設計そのものを代替するものではありません。
MQL・SQLの考え方が曖昧なままツールを導入しても、混乱が増えるだけです。
まとめ
MQLとSQLの問題は、用語の理解不足ではありません。
営業とマーケの役割分担と判断基準をどう設計しているかがすべてです。
MQLをゴールにせず、SQLを成果と誤解せず、
両者を「営業成果につなげるための通過点」として整理することが重要です。
設計を見直すことで、リード管理は数字合わせから、成果を生む仕組みに変わります。
こうした設計は、言語化するだけでなく、日々の運用の中でブレずに管理できる仕組みがあってこそ、初めて定着します。
MQLとSQLの設計から見直すなら、サスケ
MQLとSQLの設計を見直すうえで重要なのは、
案件化前の見込み顧客をどう評価し、どう次のアクションにつなげるかを可視化できることです。
クラウドサービス サスケは、商談前のリード管理に特化したAI搭載のSFA/CRM/MAツールとして、
見込み顧客の行動や温度感を一元管理し、営業判断につなげる仕組みを支援します。
「MQLはあるがSQLにつながらない」
「営業が判断しやすいリード管理に変えたい」
そう感じている企業にとって、設計を実行に落とすための選択肢の一つになります。
投稿者
- サスケ(saaske)マーケティングブログは、新規営業支援ツール「クラウドサービス サスケ」のオウンドメディアです。筆者はサスケのマーケティング担当です。SFA、CRM、MA、テレアポ、展示会フォローなど、営業支援のSaaSツールにまつわる基礎知識や実践方法などをお伝えしていきます。
