MQL vs SQL：違いとそれぞれの定義方法

MQL vs SQLはB2B GTMで最も議論される定義のひとつであり、ほとんどの議論は2つの用語が正式に合意されたことがないから発生します。マーケティングと営業がリードの品質で争っているなら、解決策はCRMの衛生管理の改善や新しいスコアリングツールではありません。両チームが署名する共有された書面による定義です。

MQLとは

マーケティング有望リード（MQL）とは、マーケティングが合意した明示的な関心閾値を超えたリードですが、まだ営業準備完了ではありません。閾値は通常、バイヤー適合シグナル（企業規模、業種、役職）と行動シグナル（ページ訪問、コンテンツダウンロード、ウェビナー参加）の組み合わせであり、合わせて実際の意図を示唆します。

SQLとは

営業有望リード（SQL）とは、営業担当者がレビューして追求する価値のある実際の見込み客として承認したリードです。担当者がリードに確認されたニーズ、意思決定の権限、そして購入の現実的なタイミングがあると考えることを意味します。重要なキーワードは「承認した」です：SQLは単なるスコアではなく、人間の判断による決定です。

一目でわかるMQL vs SQL

重要な事実

重要な事実：MQL vs SQL

• LinkedInの2024年B2Bマーケティングベンチマークによると、B2B企業全体でMQLのSQLへのコンバージョン率は平均25〜30%であり、上位四分位のチームは35〜40%を達成しています。（LinkedIn、2024年）
• ForresterのB2B Revenue Waterfallは、MQL-SAL-SQLの引き継ぎフローで最も引用されるフレームワークであり、SALステージが重要な承認・却下ゲートとなっています。（Forrester、2023年）
• Gartnerの2024年CSO調査では、リード定義に関する営業・マーケティングの連携が、パイプラインコンバージョン率を改善するための最も影響力の高いレバーであると報告されています。（Gartner、2024年）

リードライフサイクル：MQLとSQLの位置づけ

リードライフサイクルステージは通常7つのステージを経ます。MQLとSQLがそのファネルのどこに位置するかを理解することで、両チームが何を担当するかを把握できます。

• 訪問者 -- ウェブサイトやコンテンツに訪れるが、身元が特定されていない人。
• リード -- コンタクト情報を共有した訪問者（フォーム送信、イベント登録など）。
• MQL -- 合意された関心と適合閾値を超えたリード；マーケティングが営業に渡す。
• SAL（営業承認済みリード） -- 担当者がレビューして確認したリード。SALステージは引き継ぎの受領証です：担当者はまだ取り組んでいませんが、取り組む価値があると確認しています。
• SQL -- 担当者がディスカバリーコールまたは構造化された基準（BANT、MEDDICなど）でクオリファイして、実際の見込み客として承認したリード。
• 商談 -- 定義された案件を持つSQL：予算確認済み、次のステップ合意済み、パイプラインステージ設定済み。
• 顧客 -- 受注した案件。

MQLとSQLの間のギャップは、ほとんどのパイプラインの漏れが発生する場所です。SALステージがないと、問題がリード品質（マーケティング）か担当者のフォローアップ（営業）かがわかりません。

MQLの定義方法

両チームが尊重するMQL定義はマーケティングが押し付けるのではなく、共同で構築する必要があります。以下は5ステップのアプローチです：

ステップ1：2〜3つのバイヤー適合シグナルを選ぶ

理想的顧客プロファイル（ICP）を説明するファーモグラフィックまたはデモグラフィック属性を選択します。一般的な選択肢：企業収益範囲、従業員数、業種縦型、役職またはシニアリティ、地域。スコアリングを読みやすくするために3つまでに制限します。

ステップ2：2〜3つのインテントシグナルを選ぶ

インテントシグナルは積極的な関心を示す行動イベントです。受動的な消費ではなく、実際の購買意図に結びついたイベントを選択します。強いシグナル：価格ページの訪問、デモの予約、7日間で3件以上の製品ページ閲覧、ファネルの底部のアセットのダウンロード。弱いシグナル：ニュースレターを開いた、ホームページを1度訪問した。

ステップ3：スコアの閾値を設定する

適合シグナルとインテントシグナルにポイント値を割り当て、MQLステータスをトリガーする最低スコアを設定します。一般的なモデル：適合スコア（0〜50ポイント）＋行動スコア（0〜50ポイント）＝100ポイント合計；60点以上でMQL。本番稼働前に3ヶ月分の過去データで閾値を検証します。リードの20%以上をMQLとしてフラグ立てるなら、設定が緩すぎます。

ステップ4：営業とSLAに合意する

リード対応時間のSLAのないMQLはデータベース内の単なる数字です。営業は定義された時間枠（通常インバウンドには24時間、アウトバウンド支援には48時間）内にすべてのMQLをレビューすることを約束する必要があります。マーケティングはMQL却下にフラグを立て、リードスコアリングを改善するためにフィードバックを使用することを約束する必要があります。

ステップ5：月次でレビューする

リードスコアリングモデルは古くなります。バイヤーの行動が変わり、ICPが進化し、キャンペーンが変化します。マーケティングと営業がソース、セグメント、スコアリングバンド別にMQLからSQLへのコンバージョン率を比較する月次レビューサイクルを構築します。感覚ではなくデータに基づいて閾値を調整します。

例： AcmeSaaSはMQLを次のように定義します：ICP適合スコアが60以上（企業従業員50〜500人、SaaSまたはテック業種、VP以上の役職）かつ少なくとも1つ：デモを予約、7日間で価格ページを2回閲覧、またはROI計算機をダウンロード。

SQLの定義方法

SQL定義は、案件を開く前に適用する一貫したゲートを営業に与えます。これがなければ、すべての担当者が異なるクオリフィケーションを行い、パイプラインカバレッジは無意味になります。

ステップ1：クオリフィケーションフレームワークを選ぶ（BANT、MEDDICなど）

リード評価フレームワーク（BANT（Budget、Authority、Need、Timeline）やMEDDIC（Metrics、Economic Buyer、Decision Criteria、Decision Process、Identify Pain、Champion））は担当者に一貫したチェックリストを提供します。1つを選んでトレーニングします。BANTは単純なトランザクション営業に適しています。MEDDICは複数の関係者が結果に影響するような複雑なエンタープライズ案件に適しています。

ステップ2：最低適合基準を決める

すべてのBANTの条件をチェックする必要はありませんが、いくつかは必須です。決定します：リードがSQLとしてクオリファイするために必要な最低ICP適合は何か？典型的な最低基準：一定の下限を超える従業員数、商談規模をカバーする予算範囲、連絡先内の意思決定者または強い影響者。

ステップ3：最低関心基準を決める

関心はクオリファイドリードをクオリファイドな見込み客から分けるものです。ICPに適合するがアクティブなニーズのないリードは、案件を開く価値はありません。最低関心基準には次のものが含まれる場合があります：ディスカバリーで特定のペインポイントを認めた、ソリューションに関連するプロジェクトまたはイニシアティブがある、次の2四半期以内の意思決定タイムラインがある。

ステップ4：却下理由を文書化する

却下されたすべてのSALには、構造化された却下理由が必要です。一般的なカテゴリー：予算なし、権限レベルが不正、アクティブなニーズなし、タイミングが悪い、すでに競合他社と契約中。このデータはマーケティングにフィードバックされ、リードナーチャリングプログラムとICPターゲティングを改善します。

ステップ5：アプローチの24時間SLAを設定する

リードがSQLステータスに達したら、カウントが始まります。対応スピードがコンバージョン率を大きく左右します。24時間SLAをCRMワークフローに組み込み、担当者が自動リマインダーを受け取り、マネージャーがコンプライアンスを監視できるようにします。

MQLからSQLへのコンバージョン：良い率とは

MQLからSQLへの率は、マーケティングがクオリファイしたリードのうち、営業が実際に承認する割合を測定します。

MQLからSQLへの率 = 生成されたSQL / 営業に渡されたMQL

B2B SaaSの業界ベンチマーク：

• 上位四分位： 35〜40%
• 中央値： 25〜30%
• 平均以下： 15%未満

率が15%を下回る場合、最も一般的な原因は次のとおりです：MQL閾値が低すぎる、キャンペーンのICPターゲティングが不十分、または営業からマーケティングへの却下フィードバックループがない。40%を超える場合は、MQLのバーが厳しすぎてリードを過少送信していないか確認します。

低いMQLからSQLへの率は、ほぼ常に共有された問題です。マーケティングが品質よりも量を重視している可能性があります。しかし営業もリードを選り好みしているか、一貫性のない基準を適用している可能性があります。診断する唯一の方法は、理由別に却下を追跡して共同でレビューすることです。

よくあるMQL・SQLの失敗

• 品質より量を追う。 指標を達成するためにMQL数を水増しすると、SQLの率が悪く見え、マーケティングリードへの営業の信頼が損なわれます。
• MQLレビューのSLAがない。 数日間レビューされずに放置されたMQLは意図を失います。デモを予約して72時間何も連絡がなかったリードはすでに他に移っています。
• 却下フィードバックループがない。 営業がMQLを理由コード付きで却下できなければ、マーケティングには改善するシグナルがありません。フィードバックループこそがリード管理を単方向のコンベアではなくシステムにするものです。
• 共有ダッシュボードがない。 マーケティングはMQL量を監視します。営業はパイプラインを監視します。MQLからSQLから商談までを示す共有ビューなしには、どちらのチームも全体像を見られません。
• 更新されないスコアリング。 1年目に構築されたスコアリングモデルは1年目のバイヤー行動を反映しています。それ以来手を触れていなければ、ほぼ確実に間違っています。
• SALステージをスキップする。 正式な承認・却下の引き継ぎがないと、パイプラインの問題がリード品質の問題か営業実行の問題かが判断できません。

マーケティングと営業が定義に整合する方法

共有されたMQL・SQLの定義に至ることは、一度きりのミーティングではありません。継続的な業務リズムです。実際に機能するものを示します：

1. 週次の引き継ぎレビュー。 マーケティングと営業が前週のMQLからSQLへのコンバージョン、却下、却下理由をレビューする30分の定例ミーティング。責任追及ではなくデータに集中します。
2. 共有ダッシュボード。 両チームが同じファネルビューを見られるべきです：作成されたMQL、承認されたSAL、開かれたSQL、作成された商談、受注。リードがどこで落ちているかを発見するために使用します。
3. 対応時間のSLA。 MQL対応SLAをCRMワークフローに書き込みます。時間枠を逃した担当者のエスカレーションアラートを構築します。コンプライアンスを営業オペレーションの指標として追跡します。
4. 共同の却下分類。 マーケティングと営業が事前に却下理由コードに合意します。これにより担当者が「適合しない」のような漠然とした理由を使うことを防ぎます。マーケティングが何も行動できないような曖昧な理由は避けます。
5. 四半期ごとの再スコアリング。 四半期ごとに、スコアリングバンドとICPセグメント別にMQLからSQLへの率を確認します。実際にコンバートしているものを反映するために閾値を調整します。これによりスコアリングが時間とともに正確に保たれます。

よくある質問

MQLとSQLの違いは何ですか？

MQLは、マーケティングが合意された関心と適合閾値を満たすとフラグを立てたリードです。SQLは、営業がレビューし、クオリファイして、実際の見込み客として承認したリードです。MQLは自動化されたスコアリングに基づいています。SQLは担当者による人間の判断による決定です。

良いMQLからSQLへのコンバージョン率とは？

B2B SaaSの場合、中央値は25〜30%です。上位四分位のチームは35〜40%を達成します。15%を下回る場合は通常、MQL閾値が緩すぎる、ICPターゲティングが弱い、またはマーケティングへの却下フィードバックがないことを意味します。40%を超える場合は、MQLのバーが厳しすぎて営業へのリード送信が不足している可能性があります。

SALとは何ですか？どのように位置づけられますか？

SAL（営業承認済みリード）はMQLとSQLの間のステージです。担当者がMQLを受け取ったとき、レビューして承認（SAL）するか、理由コード付きで却下します。SALステージにより引き継ぎが監査可能になり、リード品質の問題と営業実行の問題が分離されます。これがないと、マーケティングと営業はコンバージョンの失敗を診断するための共有データを持てません。

MQLは誰が担当し、SQLは誰が担当しますか？

マーケティングがMQLを担当します：閾値を定義し、スコアリングを実行し、MQL量とMQLからSQLへの率に責任を持ちます。営業がSQLを担当します：担当者は（合意されたフレームワーク内で）クオリフィケーション基準を設定し、インバウンドMQLをレビューし、SQLから商談へのコンバージョンに責任を持ちます。引き継ぎSLAの共有所有権はRevOpsまたは週次の整合ミーティングを運営する人に属します。

SQLはどのように商談と異なりますか？

SQLは、営業が承認したクオリファイドリードです。商談は、定義されたステージ、期待される価値、次のステップを持つCRMに開かれた案件です。SQLは担当者が予算を確認して正式な案件レコードを開いたときに商談になります。すべてのSQLが商談になるわけではありません：一部は案件が開かれる前にディスカバリー中に失格になります。

---

MQLとSQLが緩く定義されたままである限り、マーケティングと営業の引き継ぎは摩擦を生み続けます。両方の定義を明確にすることは、レベニューチームが取れる最も影響力の高い動きのひとつです。共有された定義、SLA、却下の分類、週次レビューサイクル：それがシステム全体です。そこから始めると、責任のなすりつけはほぼ自然に終わります。