MQLとSQLの違い|基準とリード受け渡しのベストプラクティス

2026年5月1日

著者: 与謝秀作
MQLとSQLの違い|基準とリード受け渡しのベストプラクティス

BtoBマーケティングや営業の現場で頻出するキーワードが「MQL」と「SQL」です。両者の違いを正しく理解し、明確な基準でリードを受け渡すことができれば、商談化率や成約率は大きく改善します。一方で、MQLとSQLの定義が曖昧なまま運用していると、「マーケが渡したリードを営業が放置する」「営業が『質が低い』と不満を言う」といった部門間の対立が起きがちです。

本記事では、MQLとSQLの違い、判定基準の設計方法、そしてマーケティングから営業へリードを受け渡す(ハンドオフする)際のベストプラクティスを解説します。

MQLとは?マーケティング適格リードの定義

MQLの意味

MQL(Marketing Qualified Lead)とは、マーケティング活動によって獲得・育成されたリードのうち、「営業がアプローチする価値がある」とマーケティング部門が判断したリードを指します。日本語では「マーケティング適格リード」「マーケティング有望リード」などと訳されます。

単なる名刺データやメルマガ登録者と区別されるのが特徴で、関心度・行動・属性が一定の閾値を超えたリードだけがMQLに分類されます。

MQLになる条件の例

MQLとして判定する基準は企業ごとに異なりますが、一般的には以下のような行動データと属性データを組み合わせて評価します。

  • ホワイトペーパーや事例資料を複数回ダウンロードした
  • 料金ページや製品比較ページなど購買意欲の高いページを閲覧した
  • メールマガジンを継続的に開封・クリックしている
  • ウェビナーやセミナーに参加した
  • 役職・企業規模・業種がターゲットペルソナに合致している

これらの指標をスコアリング(リードスコア)で数値化し、合計が一定の閾値を超えたリードをMQLとして扱うのが一般的な運用です。

SQLとは?営業適格リードの定義

SQLの意味

SQL(Sales Qualified Lead)とは、MQLの中でもさらに「具体的な商談化が見込める」と営業部門が判断したリードを指します。日本語では「営業適格リード」「営業有望リード」と訳されます。

ここで注意したいのは、データベース言語の「SQL(Structured Query Language)」と略称が同じ点です。マーケティング文脈と技術文脈ではまったく別物なので、社内コミュニケーションでは「セールス・クオリファイド・リード」と読み分けたり、文脈を補足したりすると混乱を防げます。

SQLになる条件の例(BANT)

SQLの判定では、商談化見込みを構造的に評価する「BANT」というフレームワークがよく用いられます。

  • Budget(予算):導入予算の見通しがある
  • Authority(決裁権):意思決定者または決裁関与者と接点がある
  • Need(ニーズ):解決すべき課題が明確に把握できている
  • Timeline(導入時期):3〜6ヶ月以内に導入意向がある

BANTのうち複数項目が満たされ、かつ自社のソリューションが課題に合致しているリードがSQLとして営業の商談パイプラインに乗ります。

MQLとSQLの違いを比較で整理

MQLとSQLは、リードがファネルのどの段階にあるかを示す指標です。担当部門・評価軸・KPIが異なるため、それぞれの違いを項目ごとに整理しておきましょう。

担当部門の違い

  • MQL:マーケティング部門が育成・判定する
  • SQL:営業部門(多くの場合インサイドセールス)が判定する

評価軸の違い

  • MQL:関心度・行動データ・属性スコア
  • SQL:BANT・課題解像度・商談化の見込み

ファネル上の位置の違い

  • MQL:リード育成の最終段階。ナーチャリングを経て「営業に渡せる温度」になった状態
  • SQL:商談直前。インサイドセールスのヒアリングを経て、フィールドセールスに引き継ぐ手前

主要KPIの違い

  • MQL:MQL獲得数、MQL→SQL転換率、コンテンツ別CV率
  • SQL:商談化率、平均商談単価、受注率、初回応答時間

つまりMQLは「興味・関心が高まったリード」、SQLは「商談・購買の準備が整ったリード」と整理できます。両者を区別することで、マーケと営業がそれぞれの責任範囲で改善活動に集中できます。

MQLからSQLへの基準設計のポイント

1. 営業とマーケで定義を合意する

最も重要なのは、MQL・SQLの定義を営業とマーケティングで共通言語化することです。両部門が別々の定義で動くと、リードの引き継ぎ時に必ず摩擦が起きます。具体的には、定例会議でリードの実例をレビューし、「これはMQLか」「なぜSQLにならなかったのか」を擦り合わせる場を設けましょう。

2. スコアリングは行動と属性の両軸で

リードスコアリングを設計するときは、属性スコア(業種・規模・役職など)と行動スコア(資料DL・ページ閲覧・メール開封など)の両方を評価します。属性が合致していても行動がなければ確度は低く、逆に行動が活発でもターゲット外であれば商談化しません。両軸の合算で閾値を設けることで、ノイズを減らせます。

3. スコアの定期見直し

スコアリングは作って終わりではありません。受注したリードのスコアと失注したリードのスコアを比較し、四半期ごとに項目や閾値を調整します。商品リニューアルや市場環境の変化で「効くシグナル」が変わるため、最低でも半期に一度の見直しを推奨します。

リード受け渡しのベストプラクティス

SLA(サービスレベル合意)を文書化する

マーケと営業の間で「リード受け渡しの約束事」を文書化します。たとえば次のような項目です。

  • マーケは月◯件のMQLを供給する
  • 営業はMQL受領後◯時間以内に初回コンタクトする
  • 営業は◯営業日以内に「SQL/対象外」を判定し、理由をCRMに記入する
  • 対象外と判定されたリードはマーケのナーチャリングに戻す

SLAは数字で書くことが重要です。「迅速に対応する」では運用できません。具体的な閾値と責任分界点を明文化することで、属人的な対応のばらつきを防げます。

CRM/MAでステータスを統一する

リードのステータス管理は、MAツール(HubSpot、Marketo、Pardotなど)とCRM(Salesforceなど)で連携させます。手動転記が発生すると更新漏れや二重入力が起き、必ず受け渡し品質が劣化します。連携設計のポイントは、(1) リードのステータス値を両ツールで揃える、(2) 受け渡しトリガーを自動化する、(3) フィードバックフィールドを必須化する、の3点です。

フィードバックループを回す

営業からマーケへのフィードバックを仕組み化します。SQL化されなかった理由、商談化したMQLの共通点、失注理由などを定期的にマーケへ共有することで、ターゲット像とコンテンツ設計の精度が上がります。月次でMQL定例を開催し、好事例と要改善事例を双方向に共有する運用が理想的です。

段階的なステータスを設けるのも有効

近年は「MQL → SAL(Sales Accepted Lead)→ SQL → Opportunity」と細分化したファネルを採用する企業も増えています。SALは「営業が受け取りを承諾したリード」というステータスで、マーケの責任範囲(受け渡しまで)と営業の責任範囲(承諾以降)の境界を明確にできます。受け渡し時のロスを可視化したい場合に有効です。

よくある失敗パターンと改善策

失敗1:MQLの基準が低すぎる

KPIをMQL数だけで設定すると、マーケはとにかく数を作ろうとして基準が緩み、営業の不満が増します。改善策はシンプルで、MQL→SQL転換率や受注率まで含めて評価指標に組み込むこと。マーケのKPIを「量」だけでなく「質」と「最終貢献」で見るよう設計を見直しましょう。

失敗2:受け渡し後の追跡がない

「渡したら終わり」にせず、各リードの最終ステータス(受注・失注・対象外)まで追跡する仕組みを整えます。これがないと改善のサイクルが回りません。CRM上で「マーケ起点リードのパイプラインビュー」を作成し、月次でレビューするのがおすすめです。

失敗3:営業の初動が遅い

リードは時間の経過とともに確度が落ちます。問い合わせから数分以内に連絡したリードと、数十分後に連絡したリードでは商談化率に大きな差がつくことが多くの調査で示されています。インサイドセールスを置く、自動アサイン機能を使う、リード受信時のSlack通知を設定するなど、初動を早める仕組みが必要です。

MQL/SQL運用で見るべき主要KPI

MQL/SQLの運用を健全に保つために、最低限ダッシュボードに載せておきたい指標を整理します。

  • MQL獲得数:マーケが供給したリード数
  • MQL→SQL転換率:受け渡しの質を測る最重要指標
  • SQL→商談化率:営業の判定精度
  • 商談→受注率:最終的なROIに直結
  • 平均初回応答時間:SLA遵守状況
  • ソース別MQL/SQL転換率:チャネル投資判断

これらを定例で可視化し、各部門のオーナーシップを明確にします。指標が共有されていれば、議論が「印象論」から「数値ベース」に変わります。

まとめ|MQLとSQLは部門間の共通言語

MQLとSQLは、リードを「マーケから営業へ」スムーズに渡すための共通言語です。重要なポイントを再掲します。

  1. MQLは「興味・関心が高まったリード」、SQLは「商談・購買の準備が整ったリード」
  2. 判定基準は営業とマーケで合意し、行動と属性の両軸でスコアリングする
  3. SLAを文書化し、応答時間や判定期限を数値で約束する
  4. CRMとMAを連携してステータスを統一し、フィードバックループを回す
  5. MQL数だけでなく、転換率・受注率まで含めて評価する

定義と運用を整えることで、リード獲得から受注までのファネルの目詰まりが解消され、マーケティング投資のROIは確実に改善します。まずは自社のMQL/SQL定義を一枚のドキュメントにまとめ、営業マネージャーと一緒にレビューするところから始めてみてください。

関連記事