MQL・SQLの定義と設計方法｜マーケ・営業連携を最適化する実践ガイド

MQLとSQLの定義：まず言葉の意味を正確に押さえる

このセクションでは、MQLとSQLそれぞれの定義と、混同されやすい関連用語との違いを整理します。

MQL（Marketing Qualified Lead）とは、マーケティング活動によって獲得・育成されたリードのうち、一定の基準を満たし「営業に引き渡す価値がある」と判断された見込み客のことです。資料ダウンロード、セミナー参加、ウェブサイトの特定ページ閲覧など、購買意欲や課題意識を示す行動を取ったリードが該当します。

SQL（Sales Qualified Lead）とは、営業チームがMQLを受け取り、実際に商談化できると判断したリードです。予算・権限・ニーズ・タイムライン（いわゆるBANTフレームワーク）を確認し、今まさに提案フェーズに進むべき状態にあると営業が認定したものを指します。

混同されやすいのが「リード」「見込み客」「プロスペクト」という言葉です。一般的な整理として、リードは接点を持った全員、MQLは行動・属性で絞り込んだ上質層、SQLは営業が価値を確認した層、という流れで捉えると実務で迷いにくくなります。

なお、MQLとSQLの定義は業界・企業規模・営業モデルによって大きく異なります。SaaS企業でフリートライアルを提供している場合、トライアル開始そのものをMQLの基準にすることもあります。正解は一つではなく、自社の営業プロセスと照合しながら設計する必要があります。

MQL・SQLの違いを軸で整理する

このセクションでは、MQLとSQLを「評価主体」「評価基準」「次のアクション」の3軸で比較します。

MQLとSQLは連続するステージですが、評価の主体とロジックが異なります。以下の表で主要な違いを整理します。

重要なのは、MQLはあくまで「マーケティングの視点からの推薦」であり、SQLへの昇格は営業側の判断によるという点です。この責任分岐を明確にしておくことで、リードの質をめぐる組織間の摩擦を大幅に減らせます。

MQL・SQL設計の手順：5ステップで定義を作る

このセクションでは、実務で使えるMQL・SQL設計の具体的な手順を5ステップで解説します。

ステップ1：理想の顧客像（ICP）を言語化する

MQLの基準を設計する前に、「誰が最も良い顧客か」を定義する必要があります。ICP（Ideal Customer Profile）とは、自社サービスで最も成果を出せる顧客の属性プロファイルです。業種・従業員規模・意思決定構造・抱えている課題などを具体的に記述します。ICPが曖昧なままスコアリングを設計すると、「数字は高いが実際は受注しにくいリード」を大量に生み出す罠にはまります。

ステップ2：フィットスコアとエンゲージメントスコアを分離する

MQLの評価軸は大きく二つに分けられます。一つは「フィットスコア」——ICPとの一致度を表す属性評価です。業種、職種、企業規模、役職などがここに入ります。もう一つは「エンゲージメントスコア」——行動の熱量を表す評価です。資料ダウンロード、メール開封、特定ページの複数回訪問、セミナー参加などが対象になります。この二つを掛け合わせることで、「自社に合っていて、かつ今動いている」リードを精度高く特定できます。

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

フィットスコアとエンゲージメントスコアに点数を割り振り、合計が一定値を超えたらMQLと見なすルールを作ります。閾値の設定は最初から完璧である必要はありません。過去の受注データを遡って「どのスコア帯のリードが実際に受注につながったか」を検証し、閾値を調整していく運用が現実的です。

ステップ4：営業と合意した「SQL化の基準」を定義する

MQLを受け取った営業が、どの条件を満たせばSQLと見なすかを明文化します。ここで使われるのがBANTフレームワークです。ただし、BANTをすべて満たさないとSQLにならないとすると、引き渡しが遅すぎて機会損失になるケースもあります。自社の営業スタイルに合わせて「最低限Needsが確認できていること」など柔軟に設定することを推奨します。

ステップ5：SLA（サービスレベル合意）を定める

MQLが生成されてから営業がコンタクトするまでの時間、SQLになった後の対応期限、コンバージョン率の目標値などをSLAとして文書化します。これにより「渡したのに動いていない」という摩擦を可視化・管理できます。SLAは一度決めたら終わりではなく、四半期ごとに見直す仕組みを組み込むことが重要です。

スコアリング設計の実践：点数の付け方と運用のコツ

このセクションでは、リードスコアリングの具体的な点数設計と、運用で起きやすい問題への対処方法を解説します。

スコアリングで見落とされがちな点が「ネガティブスコア」と「スコアの減衰」です。ネガティブスコアとは、ICPから外れる属性（競合他社の社員、学生、個人メールなど）に対してスコアを下げる仕組みです。これがないと、属性的に受注見込みのないリードが高スコアに積み上がってしまいます。

スコアの減衰（ディケイ）とは、一定期間行動がなかったリードのスコアを時間経過に応じて引き下げるルールです。半年前にセミナーに参加したが以降まったく動いていないリードを高スコアのまま放置すると、営業が古い温度感のリードを追いかけることになります。多くのMAツール（HubSpot、Marketoなど）がこの機能を標準で提供しています。

スコアリングを機能させるためのデータ整備

スコアリングは、入力データの質に直接依存します。フォームで取得した業種・役職が自由入力で統一されていなければ、フィットスコアの計算が正確にできません。設計段階で「どのデータをどのフォームで取得するか」「CRMへの連携はどう行うか」を合わせて整備することが必要です。

マーケティング・営業の連携設計：ハンドオフをスムーズにする仕組み

このセクションでは、MQLからSQLへの引き渡しプロセスの設計と、組織間の摩擦を減らすための仕組みを解説します。

MQL・SQLの定義がどれだけ精緻でも、引き渡しのプロセスが属人的だと機能しません。「誰が、いつ、何を、どうやって渡すか」を仕組みとして設計することが重要です。

ハンドオフの基本設計

MQLが生成された際、マーケティングがCRMまたはMAツール上でリードステータスを更新し、担当営業またはSDRに通知が届く仕組みを作ります。この通知には、リードの行動履歴・スコア・所属企業・想定ニーズの概要を含めることが推奨されます。営業が何も知らずにコールすると、「なぜ急に連絡が来たのか」とリードに不審感を持たせてしまいます。

フィードバックループの設計

SQLに昇格しなかったMQL（営業がリジェクトしたリード）について、その理由を記録するフィールドをCRMに作ることが重要です。リジェクト理由の分類（予算なし・タイミング不一致・役職が違う・そもそもニーズがないなど）を蓄積することで、MQLの定義自体を改善するデータが得られます。このフィードバックループを持たない組織では、マーケティングは同じ精度のMQLを出し続け、営業は同じ不満を持ち続けることになります。

月次のアライメントミーティング

マーケティングと営業が月に一度、以下の数字を確認するミーティングを設けることが推奨されます。

• 当月MQL数・前月比
• MQL→SQL転換率
• SQL→商談化率
• リジェクト理由の内訳
• スコアリングの閾値変更の要否

数字を共通言語にすることで、感情的な対立ではなく事実ベースの改善議論ができます。

よくある失敗パターンと回避策：定義設計の落とし穴

このセクションでは、MQL・SQL設計でありがちな失敗とその根本原因、具体的な回避策を解説します。

MQLとSQLの設計は、一度作れば終わりではありません。多くの組織が同じパターンで躓いています。

失敗パターン1：MQL定義をマーケティングだけで決める

マーケティング側が単独でMQLの基準を設計し、営業に「このリードを渡します」と通知するケースです。営業の視点から「この属性のリードは商談化しにくい」という現場知識が反映されないため、営業側の納得感が低く、MQLが使われないまま積み上がります。設計の初期段階から営業・SDRを巻き込み、共同で基準を作ることが不可欠です。

失敗パターン2：スコアリングのメンテナンスを怠る

最初に設計したスコアリングをそのまま1年以上放置するケースです。市場環境・製品・ターゲット企業の変化に伴い、「受注につながる行動」は変わります。少なくとも四半期ごとに受注データとスコア分布を突き合わせ、スコアの重みを調整することが必要です。

失敗パターン3：量を優先してMQL基準を下げすぎる

MQL数のKPI達成のために閾値を下げ、質の低いリードを大量に営業に渡すケースです。短期的にはMQL数が増えますが、SQL転換率・商談化率が下がり、営業の信頼を失います。「MQL数」ではなく「MQL→SQL転換率」や「MQL起因の受注金額」をKPIの中心に置くことで、量より質の文化を作れます。

失敗パターン4：ナーチャリング設計なしにMQLを判定する

フォーム登録直後に1アクションでMQLと判定し、すぐに営業コールするケースです。まだ課題認識の初期段階にいるリードに対して営業がプッシュすると、離反を招くリスクがあります。MQLに至るまでのナーチャリングフロー（メールシーケンス・コンテンツ提供など）を設計し、温度感を高めてから引き渡す設計が重要です。

まとめ：MQL・SQL設計は「組織の合意形成」が本質

このセクションでは、記事全体の要点を整理し、次のアクションを提示します。

MQLとSQLの設計は、ツールや点数の話である以上に、マーケティングと営業が「どこで責任を持つか」を合意するプロセスです。以下に主要なポイントを整理します。

• MQLはマーケティングが行動・属性で判定した引き渡し候補、SQLは営業が商談化可能と判断したリード
• 設計はICP定義→スコア設計→閾値設定→SQL基準合意→SLA設定の5ステップで進める
• フィットスコアとエンゲージメントスコアを分けることで精度が上がる
• ネガティブスコアとスコア減衰を忘れると、古い・的外れなリードが積み上がる
• フィードバックループとアライメントミーティングで継続的に改善する
• MQL数ではなくMQL起因の受注金額をKPIにすることで、量より質の文化が生まれる

定義設計に「完成」はありません。市場・組織・製品が変わるたびに見直すべきものです。まず「今の定義を営業と言語化する」ところから始めることが、最も現実的な第一歩です。

communeでは、BtoBマーケティングにおけるリード管理・ナーチャリング・営業連携の設計支援を行っています。自社のMQL・SQL設計について相談したい方は、お気軽にお問い合わせください。

よくある質問（FAQ）

MQLとSQLは必ず両方定義しないといけませんか？

必須ではありませんが、マーケティングと営業が分業している組織では定義を分けることで責任の所在が明確になります。営業組織が小さくマーケも兼務している場合は、SQLのみの設計でシンプルに運用するケースもあります。自社の組織構造に合わせて判断してください。

スコアリングに使うツールは何がおすすめですか？

HubSpot、Marketo、Pardotなどが代表的なMAツールとしてBtoB企業に導入されています。ツール選定は機能だけでなく、既存CRMとの連携性・運用リソース・コストを総合的に判断することが重要です。特定ツールの優劣はビジネス要件によって変わるため、複数ツールのデモを実施して比較検討することを推奨します。

MQL→SQL転換率の目安はありますか？

業界・営業モデルによって大きく異なるため、一概に「この数字が正解」とは言えません。SiriusDecisions（現Forrester）などの調査では業界平均として参考値が示されることがありますが、まず自社の過去データを基準に設定し、改善の方向性を追うことが実務上は有効です。他社の数字を目標にするより、自社の前四半期比で見ることを推奨します。

BANTフレームワーク以外のSQL判定基準はありますか？

CHAMPERSやMEDDICなど、BANTを発展させた複数のフレームワークが存在します。CHAMPはChallenges（課題）・Authority（権限）・Money（予算）・Prioritization（優先度）を軸にしており、課題起点の営業に向いています。MEDDICはエンタープライズ向けの複雑な営業プロセスに対応しています。自社の営業スタイルと照合して選ぶことが重要です。

マーケティングの予算を正当化するためにMQL数を増やすべきですか？

推奨しません。MQL数の膨張は短期的に見栄えが良くなりますが、SQL転換率と商談化率の低下で営業の信頼を失い、長期的にはマーケティング予算の削減につながるリスクがあります。MQL起因の受注金額・パイプライン貢献額をKPIにすることで、マーケティングの貢献を正確かつ持続可能な形で示すことができます。