「マーケティングが渡したリードを営業が使ってくれない」「商談化率が低くてマーケの貢献が見えない」——こうした摩擦の多くは、MQLとSQLの定義が曖昧なまま運用されていることが原因です。
MQL・SQLの設計とは、単なるリードのラベル付けではなく、マーケティングと営業がどこで責任を分担し、どのタイミングでリードを引き渡すかという組織連携の設計そのものです。定義がずれたままでは、マーケは「たくさん渡した」と思い、営業は「使えるものが来ない」と感じる認識のズレが解消されません。
この記事では、MQL・SQL・SALの正確な定義から、自社に合った基準設計の5ステップ、スコアリングの作り方、よくある失敗パターンまで解説します。「定義を決める会議」を控えたBtoBマーケティング担当者・意思決定者に向けた内容です。
目次
MQLとSQLの定義：まず言葉の意味を正確に押さえる
MQLはマーケティングが「営業に渡す価値がある」と判定したリード、SQLは営業が「商談化できる」と判定したリードです。判定の主体が異なる点がすべての出発点になります。
MQL（Marketing Qualified Lead）とは、マーケティング活動によって獲得・育成されたリードのうち、一定の基準を満たし「営業に引き渡す価値がある」と判断された見込み客のことです。資料ダウンロード、セミナー参加、ウェブサイトの特定ページ閲覧など、購買意欲や課題意識を示す行動を取ったリードが該当します。
SQL（Sales Qualified Lead）とは、営業チームがリードの状態を直接確認し、実際に商談化できると判断したリードのことです。予算・決裁権・ニーズ・導入時期（いわゆるBANT）をヒアリングし、提案フェーズに進むべき状態にあると営業が認定したものを指します。
混同されやすいのが「リード」「見込み客」「プロスペクト」という言葉です。実務では、リードは接点を持った全員、MQLは行動・属性で絞り込んだ層、SQLは営業が価値を確認した層、という流れで捉えると迷いにくくなります。
なお、MQLとSQLの定義は業界・企業規模・営業モデルによって大きく異なります。SaaS企業でフリートライアルを提供している場合、トライアル開始そのものをMQLの基準にすることもあります。正解は一つではなく、自社の営業プロセスと照合しながら設計する必要があります。HubSpot上で具体的にMQLをどう定義・設定するかは、HubSpotでのMQL定義・設定方法で詳しく解説しています。
MQL・SQLの違いを3つの軸で整理する
MQLとSQLの違いは「評価主体」「評価基準」「次のアクション」の3軸で整理できます。MQLはマーケの推薦、SQLは営業の意思決定であり、この責任分岐を明確にすることが摩擦を減らす鍵です。
| 比較軸 | MQL | SQL |
|---|---|---|
| 評価主体 | マーケティングチーム | 営業チーム（SDR / インサイドセールスなど） |
| 主な評価基準 | 行動スコア・属性スコア（業種・職種・企業規模など） | BANT確認（予算・決裁権・ニーズ・導入時期） |
| 情報源 | MAツール・CRM上の行動ログ | 電話・メール・商談での直接ヒアリング |
| 次のアクション | 営業への引き渡し（ハンドオフ） | 商談設定・提案資料の作成 |
| 責任部門 | マーケティング | 営業 |
重要なのは、MQLはあくまで「マーケティングの視点からの推薦」であり、SQLへの昇格は営業側の判断によるという点です。この責任分岐を明文化しておくことで、リードの質をめぐる組織間の摩擦を大幅に減らせます。
SAL（Sales Accepted Lead）を挟むべきかの判断基準
SAL（Sales Accepted Lead）とは、マーケティングが引き渡したMQLを営業が「対応する」と受領確認したリードのことです。MQLとSQLの間に位置し、「渡した／受け取っていない」という水掛け論を防ぐ受領チェックポイントとして機能します。
ただし、すべての組織にSALが必要なわけではありません。判断基準はリードの流量と分業の度合いです。インサイドセールスとフィールドセールスが分業しており、月間のMQLが数百件規模で流れる組織では、受領ステータスがないと「対応漏れ」を検知できないため、SALを設けるべきです。分業体制の設計自体に課題がある場合は、インサイドセールスとマーケの連携の仕組み化もあわせて確認してください。
一方、営業が数名でマーケ担当が兼務しているような組織では、SALはステータス管理の手間を増やすだけになりがちです。この規模ではMQL→SQLの2段階で運用し、対応漏れは週次の目視チェックで補う方が現実的です。
ステージを増やすほど管理は精緻になりますが、更新されないステータスは存在しないのと同じです。運用リソースに対して段階数が多すぎないかを先に確認してください。
MQL・SQL設計の手順：5ステップで定義を作る
設計はICP定義→スコア分離→閾値設定→SQL基準合意→SLA設定の順で進めます。順番を守ることが重要で、特にICPを飛ばしてスコアリングから始めると精度が出ません。
ステップ1：理想の顧客像（ICP）を言語化する
MQLの基準を設計する前に、「誰が最も良い顧客か」を定義する必要があります。ICP（Ideal Customer Profile）とは、自社サービスで最も成果を出せる顧客の属性プロファイルのことです。業種・従業員規模・意思決定構造・抱えている課題などを具体的に記述します。ICPが曖昧なままスコアリングを設計すると、「数字は高いが実際は受注しにくいリード」を大量に生み出す罠にはまります。ICPの具体的な作り方はBtoBにおけるICP設定の方法で手順化しています。
ステップ2：フィットスコアとエンゲージメントスコアを分離する
MQLの評価軸は大きく二つに分けられます。一つは「フィットスコア」——ICPとの一致度を表す属性評価です。業種、職種、企業規模、役職などがここに入ります。もう一つは「エンゲージメントスコア」——行動の熱量を表す評価です。資料ダウンロード、メール開封、特定ページの複数回訪問、セミナー参加などが対象になります。この二つを掛け合わせることで、「自社に合っていて、かつ今動いている」リードを精度高く特定できます。
ステップ3：スコアの閾値を設定する
フィットスコアとエンゲージメントスコアに点数を割り振り、合計が一定値を超えたらMQLと見なすルールを作ります。閾値の設定は最初から完璧である必要はありません。過去の受注データを遡って「どのスコア帯のリードが実際に受注につながったか」を検証し、閾値を調整していく運用が現実的です。
ステップ4：営業と合意した「SQL化の基準」を定義する
MQLを受け取った営業が、どの条件を満たせばSQLと見なすかを明文化します。ここで使われるのがBANTフレームワークです。ただし、BANTをすべて満たさないとSQLにならないとすると、引き渡しが遅すぎて機会損失になるケースもあります。自社の営業スタイルに合わせて「最低限ニーズが確認できていること」など柔軟に設定することを推奨します。
ステップ5：SLA（サービスレベル合意）を定める
MQLが生成されてから営業がコンタクトするまでの時間、SQLになった後の対応期限、転換率の目標値などをSLAとして文書化します。これにより「渡したのに動いていない」という状態を可視化・管理できます。SLAは一度決めたら終わりではなく、四半期ごとに見直す仕組みを組み込むことが重要です。
この5ステップを自社だけで進めるのが難しい場合は、設計段階からの伴走支援も選択肢に入れてください。定義づくりは最初の合意形成が最も難易度が高い工程です。
スコアリング設計の実践：点数の付け方と運用のコツ
スコアリングの精度は「ネガティブスコア」と「スコア減衰」で決まります。加点ルールだけ作って引き算を忘れると、受注見込みのないリードが高スコアに積み上がります。
スコアリングで見落とされがちな点が「ネガティブスコア」と「スコアの減衰」です。ネガティブスコアとは、ICPから外れる属性（競合他社の社員、学生、個人メールなど）に対してスコアを下げる仕組みのことです。これがないと、属性的に受注見込みのないリードが高スコアに積み上がってしまいます。
スコアの減衰（ディケイ）とは、一定期間行動がなかったリードのスコアを時間経過に応じて引き下げるルールのことです。半年前にセミナーに参加したが以降まったく動いていないリードを高スコアのまま放置すると、営業が古い温度感のリードを追いかけることになります。多くのMAツール（HubSpot、Marketoなど）がこの機能を標準で提供しています。HubSpotでの具体的な設定手順はHubSpotリードスコアリングの設定方法で解説しています。
スコアリングを機能させるためのデータ整備
スコアリングは、入力データの質に直接依存します。フォームで取得した業種・役職が自由入力で統一されていなければ、フィットスコアの計算が正確にできません。設計段階で「どのデータをどのフォームで取得するか」「CRMへの連携はどう行うか」を合わせて整備することが必要です。
加点ルールよりも先に、ネガティブスコアと減衰ルールを決めてください。スコアリングの失敗の大半は「点を足す設計」ではなく「点を引く設計」の欠落から起きます。
マーケティング・営業の連携設計：ハンドオフをスムーズにする仕組み
ハンドオフは「通知の仕組み」「リジェクト理由の記録」「月次の数字レビュー」の3点をセットで設計します。定義がどれだけ精緻でも、引き渡しが属人的だと機能しません。
MQL・SQLの定義を作ったら、「誰が、いつ、何を、どうやって渡すか」を仕組みとして設計します。マーケと営業の連携全体の設計論はマーケティングと営業の連携を仕組み化する方法で扱っているため、ここではMQL・SQLに直結する3つの要素に絞ります。
ハンドオフの基本設計
MQLが生成された際、マーケティングがCRMまたはMAツール上でリードステータスを更新し、担当営業またはSDRに通知が届く仕組みを作ります。この通知には、リードの行動履歴・スコア・所属企業・想定ニーズの概要を含めることが推奨されます。営業が何も知らずにコールすると、「なぜ急に連絡が来たのか」とリードに不審感を持たせてしまいます。
フィードバックループの設計
SQLに昇格しなかったMQL（営業がリジェクトしたリード）について、その理由を記録するフィールドをCRMに作ることが重要です。リジェクト理由の分類（予算なし・タイミング不一致・役職が違う・そもそもニーズがないなど）を蓄積することで、MQLの定義自体を改善するデータが得られます。このフィードバックループを持たない組織では、マーケティングは同じ精度のMQLを出し続け、営業は同じ不満を持ち続けることになります。
月次のアライメントミーティング
マーケティングと営業が月に一度、以下の数字を確認するミーティングを設けることを推奨します。
- 当月MQL数・前月比
- MQL→SQL転換率
- SQL→商談化率
- リジェクト理由の内訳
- スコアリングの閾値変更の要否
数字を共通言語にすることで、感情的な対立ではなく事実ベースの改善議論ができます。追うべき指標の全体設計はBtoBマーケのKPI設計ガイドとあわせて確認してください。
よくある失敗パターンと回避策：定義設計の落とし穴
失敗の典型は「マーケ単独で決める」「メンテしない」「量を追って基準を下げる」「ナーチャリングなしで判定する」の4つです。いずれも設計時点で回避策を織り込めます。
失敗パターン1：MQL定義をマーケティングだけで決める
マーケティング側が単独でMQLの基準を設計し、営業に「このリードを渡します」と通知するケースです。営業の視点から「この属性のリードは商談化しにくい」という現場知識が反映されないため、営業側の納得感が低く、MQLが使われないまま積み上がります。設計の初期段階から営業・SDRを巻き込み、共同で基準を作ることが不可欠です。
失敗パターン2：スコアリングのメンテナンスを怠る
最初に設計したスコアリングをそのまま1年以上放置するケースです。市場環境・製品・ターゲット企業の変化に伴い、「受注につながる行動」は変わります。少なくとも四半期ごとに受注データとスコア分布を突き合わせ、スコアの重みを調整することが必要です。
失敗パターン3：量を優先してMQL基準を下げすぎる
MQL数のKPI達成のために閾値を下げ、質の低いリードを大量に営業に渡すケースです。短期的にはMQL数が増えますが、SQL転換率・商談化率が下がり、営業の信頼を失います。「MQL数」ではなく「MQL→SQL転換率」や「MQL起因の受注金額」をKPIの中心に置くことで、量より質の文化を作れます。
失敗パターン4：ナーチャリング設計なしにMQLを判定する
フォーム登録直後に1アクションでMQLと判定し、すぐに営業コールするケースです。まだ課題認識の初期段階にいるリードに対して営業がプッシュすると、離反を招くリスクがあります。MQLに至るまでのナーチャリングフロー（メールシーケンス・コンテンツ提供など）を設計し、温度感を高めてから引き渡すことが重要です。シナリオの具体的な組み方はBtoBリードナーチャリングのシナリオ設計で解説しています。
自社の運用がこれらの失敗パターンに当てはまっていないか診断したい場合は、現状の定義・スコアリングのレビューからの相談も可能です。
引き渡し基準が緩いと、営業から信用されなくなります。その先で何が起きるかはインサイドセールスが機能しない理由で扱っています。
まとめ：MQL・SQL設計は「組織の合意形成」が本質
MQL・SQL設計はツールや点数の話である以上に、マーケと営業が「どこで責任を持つか」を合意するプロセスです。
この記事の要点を整理します。
- MQLはマーケティングが行動・属性で判定した引き渡し候補、SQLは営業が商談化可能と判断したリード
- SALはMQLとSQLの間の受領チェックポイント。分業体制とリード流量に応じて要否を判断する
- 設計はICP定義→スコア分離→閾値設定→SQL基準合意→SLA設定の5ステップで進める
- ネガティブスコアとスコア減衰を忘れると、古い・的外れなリードが積み上がる
- フィードバックループとアライメントミーティングで継続的に改善する
- MQL数ではなくMQL起因の受注金額をKPIにすることで、量より質の文化が生まれる
定義設計に「完成」はありません。市場・組織・製品が変わるたびに見直すべきものです。まず「今の定義を営業と言語化する」ところから始めることが、最も現実的な第一歩です。
無料相談受付中
MQL・SQLの定義づくりを、営業との合意形成から支援します
「基準を作ったが営業が使ってくれない」「スコアリングを見直したいが判断軸がない」——そうした状況からの立て直しを、BtoBマーケの実務家が伴走支援します。現状の定義レビューだけでもお気軽にご相談ください。
よくある質問（FAQ）
- MQLとSQLは必ず両方定義しないといけませんか？
- 必須ではありません。マーケティングと営業が分業している組織では定義を分けることで責任の所在が明確になりますが、営業組織が小さくマーケも兼務している場合は、SQLのみの設計でシンプルに運用するケースもあります。自社の組織構造に合わせて判断してください。
- SALはどんな組織に必要ですか？
- インサイドセールスとフィールドセールスが分業しており、月間のMQLが数百件規模で流れる組織に必要です。受領ステータスがないと対応漏れを検知できないためです。逆に営業が数名の組織では管理コストが上回るため、MQL→SQLの2段階で十分です。
- スコアリングに使うツールは何がおすすめですか？
- HubSpot、Marketo、Pardotなどが代表的なMAツールとしてBtoB企業に導入されています。ツール選定は機能だけでなく、既存CRMとの連携性・運用リソース・コストを総合的に判断することが重要です。特定ツールの優劣はビジネス要件によって変わるため、複数ツールのデモを実施して比較検討することを推奨します。
- MQL→SQL転換率の目安はありますか？
- 業界・営業モデルによって大きく異なるため、一概に「この数字が正解」とは言えません。まず自社の過去データを基準に設定し、改善の方向性を追うことが実務上は有効です。他社の数字を目標にするより、自社の前四半期比で見ることを推奨します。
- マーケティングの予算を正当化するためにMQL数を増やすべきですか？
- 推奨しません。MQL数の膨張は短期的に見栄えが良くなりますが、SQL転換率と商談化率の低下で営業の信頼を失い、長期的にはマーケティング予算の削減につながるリスクがあります。MQL起因の受注金額・パイプライン貢献額をKPIにすることで、マーケティングの貢献を正確かつ持続可能な形で示すことができます。