MQLとSQLの違い｜基準とリード受け渡しのベストプラクティス
BtoBマーケティングや営業の現場で頻出するキーワードが「MQL」と「SQL」です。両者の違いを正しく理解し、明確な基準でリードを受け渡すことができれば、商談化率や成約率は大きく改善します。一方で、MQLとSQLの定義が曖昧なまま運用していると、「マーケが渡したリードを営業が放置する」「営業が『質が低い』と不満を言う」といった部門間の対立が起きがちです。
本記事では、MQLとSQLの違い、判定基準の設計方法、そしてマーケティングから営業へリードを受け渡す（ハンドオフする）際のベストプラクティスを解説します。
MQL（Marketing Qualified Lead）とは、マーケティング活動によって獲得・育成されたリードのうち、「営業がアプローチする価値がある」とマーケティング部門が判断したリードを指します。日本語では「マーケティング適格リード」「マーケティング有望リード」などと訳されます。
単なる名刺データやメルマガ登録者と区別されるのが特徴で、関心度・行動・属性が一定の閾値を超えたリードだけがMQLに分類されます。
MQLとして判定する基準は企業ごとに異なりますが、一般的には以下のような行動データと属性データを組み合わせて評価します。
これらの指標をスコアリング（リードスコア）で数値化し、合計が一定の閾値を超えたリードをMQLとして扱うのが一般的な運用です。
SQL（Sales Qualified Lead）とは、MQLの中でもさらに「具体的な商談化が見込める」と営業部門が判断したリードを指します。日本語では「営業適格リード」「営業有望リード」と訳されます。
ここで注意したいのは、データベース言語の「SQL（Structured Query Language）」と略称が同じ点です。マーケティング文脈と技術文脈ではまったく別物なので、社内コミュニケーションでは「セールス・クオリファイド・リード」と読み分けたり、文脈を補足したりすると混乱を防げます。
SQLの判定では、商談化見込みを構造的に評価する「BANT」というフレームワークがよく用いられます。
BANTのうち複数項目が満たされ、かつ自社のソリューションが課題に合致しているリードがSQLとして営業の商談パイプラインに乗ります。
MQLとSQLは、リードがファネルのどの段階にあるかを示す指標です。担当部門・評価軸・KPIが異なるため、それぞれの違いを項目ごとに整理しておきましょう。
つまりMQLは「興味・関心が高まったリード」、SQLは「商談・購買の準備が整ったリード」と整理できます。両者を区別することで、マーケと営業がそれぞれの責任範囲で改善活動に集中できます。
最も重要なのは、MQL・SQLの定義を営業とマーケティングで共通言語化することです。両部門が別々の定義で動くと、リードの引き継ぎ時に必ず摩擦が起きます。具体的には、定例会議でリードの実例をレビューし、「これはMQLか」「なぜSQLにならなかったのか」を擦り合わせる場を設けましょう。
リードスコアリングを設計するときは、属性スコア（業種・規模・役職など）と行動スコア（資料DL・ページ閲覧・メール開封など）の両方を評価します。属性が合致していても行動がなければ確度は低く、逆に行動が活発でもターゲット外であれば商談化しません。両軸の合算で閾値を設けることで、ノイズを減らせます。
スコアリングは作って終わりではありません。受注したリードのスコアと失注したリードのスコアを比較し、四半期ごとに項目や閾値を調整します。商品リニューアルや市場環境の変化で「効くシグナル」が変わるため、最低でも半期に一度の見直しを推奨します。
マーケと営業の間で「リード受け渡しの約束事」を文書化します。たとえば次のような項目です。
SLAは数字で書くことが重要です。「迅速に対応する」では運用できません。具体的な閾値と責任分界点を明文化することで、属人的な対応のばらつきを防げます。
リードのステータス管理は、MAツール（HubSpot、Marketo、Pardotなど）とCRM（Salesforceなど）で連携させます。手動転記が発生すると更新漏れや二重入力が起き、必ず受け渡し品質が劣化します。連携設計のポイントは、(1) リードのステータス値を両ツールで揃える、(2) 受け渡しトリガーを自動化する、(3) フィードバックフィールドを必須化する、の3点です。
営業からマーケへのフィードバックを仕組み化します。SQL化されなかった理由、商談化したMQLの共通点、失注理由などを定期的にマーケへ共有することで、ターゲット像とコンテンツ設計の精度が上がります。月次でMQL定例を開催し、好事例と要改善事例を双方向に共有する運用が理想的です。
近年は「MQL → SAL（Sales Accepted Lead）→ SQL → Opportunity」と細分化したファネルを採用する企業も増えています。SALは「営業が受け取りを承諾したリード」というステータスで、マーケの責任範囲（受け渡しまで）と営業の責任範囲（承諾以降）の境界を明確にできます。受け渡し時のロスを可視化したい場合に有効です。
KPIをMQL数だけで設定すると、マーケはとにかく数を作ろうとして基準が緩み、営業の不満が増します。改善策はシンプルで、MQL→SQL転換率や受注率まで含めて評価指標に組み込むこと。マーケのKPIを「量」だけでなく「質」と「最終貢献」で見るよう設計を見直しましょう。
「渡したら終わり」にせず、各リードの最終ステータス（受注・失注・対象外）まで追跡する仕組みを整えます。これがないと改善のサイクルが回りません。CRM上で「マーケ起点リードのパイプラインビュー」を作成し、月次でレビューするのがおすすめです。
リードは時間の経過とともに確度が落ちます。問い合わせから数分以内に連絡したリードと、数十分後に連絡したリードでは商談化率に大きな差がつくことが多くの調査で示されています。インサイドセールスを置く、自動アサイン機能を使う、リード受信時のSlack通知を設定するなど、初動を早める仕組みが必要です。
MQL／SQLの運用を健全に保つために、最低限ダッシュボードに載せておきたい指標を整理します。
これらを定例で可視化し、各部門のオーナーシップを明確にします。指標が共有されていれば、議論が「印象論」から「数値ベース」に変わります。
MQLとSQLは、リードを「マーケから営業へ」スムーズに渡すための共通言語です。重要なポイントを再掲します。
定義と運用を整えることで、リード獲得から受注までのファネルの目詰まりが解消され、マーケティング投資のROIは確実に改善します。まずは自社のMQL／SQL定義を一枚のドキュメントにまとめ、営業マネージャーと一緒にレビューするところから始めてみてください。
4P分析（Product・Price・Place・Promotion）の意味と各要素の考え方、5ステップでわかる書き方の手順、BtoB SaaS／D2C／飲食店の業界別テンプレート、4Cとの違い、よくある失敗と対策まで実務目線で解説します。
「ホットリード」「リードクオリフィケーション」で検索するBtoBマーケティング担当者・インサイドセールス・営業企画・経営層向けに、ホットリードの定義(購買意欲が高まり商談化・受注が見込める見込み顧客)、リードナーチャリング・リードクオリフィ...
「ナーチャリング」「リードナーチャリング」「リードナーチャリングとは」で検索するBtoBマーケティング担当者・営業企画・経営層向けに、リードナーチャリングの定義（見込み顧客育成の意味）と、リードジェネレーション・リードクオリフィケーションと...
