MQLとSQLの違いとは？マーケと営業の引き渡し基準を整理

「マーケティングでは有望リードだと思って営業へ渡したのに、ほとんど追ってもらえない」「営業からは“まだ早いリードばかり”と言われる」「MQL数は増えているのに、商談や受注が増えている実感がない」。

BtoB企業では、リード獲得施策を増やすほど、このようなマーケティングと営業のすれ違いが起こることがあります。

この問題を整理するときに押さえておきたいのが、MQLとSQLの違いです。

結論から言うと、MQLはマーケティングが一定の条件を満たしたと判断した見込み客、SQLは営業が確認したうえで具体的に追う対象と判断した見込み客です。

ただし、MQLとSQLは全国共通の固定基準がある用語ではありません。「資料をダウンロードしたらMQL」「スコアが50点ならSQL」と一律に決められるものではなく、自社の商材、ターゲット、営業体制に合わせて定義します。

インティメート・マージャーが関わった過去のセミナーでも、マーケティング側には「営業が獲得リードを追ってくれない」、営業側には「マーケティングから来るリードの質が低い」という認識差があることが課題として整理されてきました。

MQLとSQLを分ける目的は、見込み客へラベルを付けることではありません。

マーケティングと営業が「誰を渡すのか」「何を営業が確認するのか」「まだ商談段階ではなかった場合にどう戻すのか」を共通ルールにすることが重要です。

MQLとSQLの違いとは？

MQLとSQLの違いを簡潔に整理すると、次のようになります。

比較項目	MQL	SQL
正式名称	Marketing Qualified Lead	Sales Qualified Lead
主な判断主体	マーケティング	営業・インサイドセールス
意味	マーケティング上の条件を満たした見込み客	営業が具体的に追う価値があると判断した見込み客
主な判断材料	企業属性、役職、Web行動、資料DL、ウェビナー、スコア等	課題、対象適合、検討状況、時期、関係者、営業上の障壁等
主なアクション	営業確認、個別育成、情報追加	商談化、個別提案、案件形成
判断方法	データ・ルールを中心に判定しやすい	顧客との会話・営業確認を含めて判断

つまり、

MQL＝マーケティング側から見て「営業が確認する理由がある」

そして、

SQL＝営業側から見て「具体的に追う理由が確認できた」

という違いです。

MQLとは？マーケティングが一定条件を満たしたと判断したリード

MQLとは、Marketing Qualified Leadの略です。

マーケティング活動によって獲得・育成した見込み客のうち、自社で定めた一定の条件を満たしたリードを指します。

例えば、MQLを判定する材料として、

• 対象業種に該当している
• 対象企業規模に合っている
• ターゲット部署・役職に近い
• 関連資料をダウンロードした
• ウェビナーへ参加した
• サービス関連ページを複数閲覧した
• 一定のリードスコアへ到達した
• 特定テーマへの関心が確認できた

などがあります。

ただし、資料を一つダウンロードしたという理由だけで、営業活動を強く求めているとは限りません。

そのため、MQLを「購買意欲が高い人」と断定するのではなく、マーケティングが収集できる情報から見て、次の確認へ進める価値がある状態と考えると実務へ落とし込みやすくなります。

SQLとは？営業が具体的に追う対象と判断したリード

SQLとは、Sales Qualified Leadの略です。

MQLなどの見込み客に対して営業・インサイドセールスが接触し、課題や検討状況などを確認したうえで、具体的な営業活動を進める価値があると判断した状態です。

例えば、営業では次のような情報を確認します。

• 現在どのような課題を持っているか
• 自社の商品・サービスで支援できる範囲か
• なぜ現在情報収集しているのか
• 導入・見直しを検討する時期はいつか
• 社内では誰が関係するのか
• 現在利用している方法・サービスはあるか
• 導入を進める際の障壁は何か

予算、決裁権、必要性、導入時期などを確認するフレームワークもありますが、すべての企業で同じ確認項目にする必要はありません。

重要なのは、自社で商談を進めるために最低限確認したい情報を営業・マーケティング双方で決めておくことです。

MQLとSQLは「温度感」だけで分けない

MQLを「少し温かいリード」、SQLを「熱いリード」と説明する場合があります。

初学者には分かりやすい表現ですが、実務ではそれだけでは判断基準が曖昧になります。

例えば、資料を3回ダウンロードしていても、対象外業種なら営業優先度は高くないかもしれません。

一方、コンテンツ閲覧履歴がほとんどなくても、問い合わせフォームから具体的な相談が入れば、営業がすぐ確認した方がよい場合があります。

そのためMQL・SQLは、

• 誰が判断した状態なのか
• 何を根拠に判断したのか
• 次に誰が何をする状態なのか

で分けます。

リードからMQL、SQLへ進む流れ

段階	状態	主な担当	次の判断
Lead	自社と何らかの接点ができた	マーケティング	育成・評価するか
MQL	マーケティング上の条件を満たした	マーケティング＋IS	営業確認するか
SQL	営業が追う価値を確認した	IS・営業	商談・案件形成へ進めるか
Opportunity	具体的な案件として管理する	営業	提案・契約へ進めるか

実際の営業組織では、インサイドセールスがMQLを確認し、フィールドセールスへ渡すケースもあります。

その場合、

マーケティング → MQL → インサイドセールス → SQL → フィールドセールス

という流れになります。

一方、営業組織が小さければマーケティングから直接営業へ引き渡すこともあります。

重要なのはステージ名称そのものではなく、各ステージで誰が何を判断するのかが決まっていることです。

MQLの基準は「Fit」と「行動」を分けて考える

MQL基準を作るときは、企業・人物の適合度と、現在の行動・関心を分けると整理しやすくなります。

評価軸	確認すること	例
Fit	自社の対象顧客に合うか	業種、企業規模、部署、役職、利用条件
Engagement	自社へどのような反応をしているか	資料DL、Web閲覧、ウェビナー、メール反応
Recency	その行動がどれくらい最近か	直近閲覧、直近資料DL、最近の再訪
Interest	何のテーマへ関心があるか	課題テーマ、インテント情報

例えば、

Fitが高い＋関連テーマへの行動が複数ある＋最近の行動である

といった条件からMQL候補を作ります。

リードスコアリングを利用する場合も、最終的にはこのような複数の情報を一定のルールへ変換していると考えると分かりやすいでしょう。

問い合わせやデモ依頼はMQLスコアを待つ必要がない

MQL条件を設計すると、「何点になったら営業へ渡すか」に意識が向きやすくなります。

しかし、すべての見込み客をスコアで判定する必要はありません。

例えば、

• 具体的な問い合わせ
• 相談希望
• デモ依頼
• 見積依頼
• 営業担当者への返信

など、顧客側から明確な意思表示がある場合は、通常のMQLスコアとは別に営業確認へ進めるルールを設定できます。

もちろん、営業対象外の問い合わせなどもあるため、問い合わせが入っただけでSQLと断定する必要はありません。

明確な意思表示は速やかに確認し、その後に営業側でSQLに該当するか判断するという順番です。

MQLからSQLへ進めるときに営業が確認したいこと

マーケティングが確認できるのは、主に属性と行動です。

一方、営業が顧客との会話で確認できる情報があります。

確認項目	確認する内容
課題	現在何に困っているのか
背景	なぜ今そのテーマを調べているのか
Fit	自社の商品で実際に支援できるか
優先度	他の課題と比較して重要なのか
時期	いつまでに検討・改善したいか
関係者	利用者・推進者・責任者・決裁者は誰か
障壁	予算、社内体制、技術、法務等で何が障壁になるか
次の行動	商談、資料共有、再連絡、育成のどれが適切か

すべての項目が分からなければSQLにしてはいけない、という意味ではありません。

自社の営業プロセスで「これだけは確認できれば次へ進められる」という最低条件を決めます。

MQLからSQLにならなかったリードはどうする？

MQLを営業へ渡した結果、SQLにならないことは珍しくありません。

問題なのは、SQLにならなかったことではなく、

なぜSQLにならなかったのかがマーケティングへ戻らないことです。

例えば、次のように理由を共通化します。

SQL化しなかった理由	次の対応
情報収集段階	ナーチャリングへ戻す
導入時期が先	再確認時期を設定する
担当者が違う	適切な部署・人物を確認する
対象企業ではない	Fit条件を見直す
課題がない	育成または低優先へ戻す
別施策を優先	状況変化を継続観測する
既存案件と重複	既存営業担当へ統合する

「営業に戻された＝マーケティングの失敗」と扱うと、営業側も差し戻し理由を記録しなくなります。

MQL→SQLの転換結果は、MQL条件を改善するための重要なデータです。

MQLをSQLに見せようとすると営業・マーケティング連携が崩れる

マーケティング側のKPIがMQL数だけになると、MQL条件を広くして件数を増やしたくなる場合があります。

例えば、

• 資料を1回取得したらMQL
• ウェビナーへ申し込んだらMQL
• 一定ページ数を閲覧したらMQL

という条件にすれば、MQL数は増えます。

しかし営業側がその多くを「まだ追う段階ではない」と判断すれば、MQLという指標への信頼が下がります。

反対に、営業側がSQL基準を厳しくしすぎ、予算・時期・決裁者などが完全に確定するまでSQLにしない場合も、マーケティング側から見ると「営業がリードを育ててくれない」という不満につながります。

MQLとSQLは、どちらか一方の部門が自分たちに有利な基準を設定するための指標ではありません。

売上までのプロセスを分担するための共通言語として設計します。

MQLとSQLの引き渡しでは「データ」と「会話」を分ける

マーケティングから営業へ渡す情報では、確認できている事実と、そこから考えられる仮説を分けます。

区分	例
事実	対象業種、資料DL、ウェビナー参加、直近閲覧、過去問い合わせ
仮説	営業効率化に課題がある可能性、AI導入を検討している可能性
未確認	具体課題、導入時期、予算、決裁者、競合比較状況

営業へ、

「このリードは温度感が高いです」

とだけ伝えるより、

「対象企業条件に合致。直近で営業効率化資料を取得し、関連ウェビナーにも参加。過去商談なし。具体的な検討時期と現在の課題は未確認」

と渡した方が、営業側が何を確認すればよいか分かります。

MQL・SQLの引き渡しルールに入れたい項目

ルール	決めること
MQL条件	どのFit・行動・スコアを満たすか
即時確認条件	問い合わせ・相談等をどう扱うか
営業確認期限	MQL受領後いつまでに確認するか
必須引き渡し情報	企業、人物、行動、関心、過去接点等
SQL条件	営業が何を確認できればSQLとするか
差し戻し理由	情報収集、時期、対象外等をどう分類するか
再確認条件	いつ・どの変化があれば再度営業へ渡すか
責任者	各ステージの定義を誰が管理するか

このようなマーケティングと営業の役割・期限・条件に関する合意を、SLAとして整理する方法もあります。

ただし、「MQLは○時間以内に必ず電話する」と他社の基準をそのまま採用する必要はありません。

リード数、営業人数、商材単価、問い合わせ内容などに応じて、自社で現実的なルールを設定します。

MQLとSQLの間にSALを置く方法もある

MQLを営業へ渡した瞬間にSQLへ変えると、営業による確認前後の状態を区別しにくい場合があります。

そこで企業によっては、MQLとSQLの間にSALを置きます。

SALはSales Accepted Leadの略で、営業が「受領し、確認対象として受け入れた状態」を表す考え方です。

状態	意味
MQL	マーケティングが営業確認候補と判断
SAL	営業が受け取り、確認対象として受理
SQL	営業が確認し、具体的に追う対象と判断

必ずSALを導入する必要はありません。

ただし、

「営業がそもそもMQLを見たのか」

と、

「見た結果、SQLではなかったのか」

を分けたい企業では有効です。

MQL・SQL基準はリードスコアだけで決めない

リードスコアリングはMQL判定を効率化する方法の一つです。

例えば、

• 対象企業条件
• 対象部署
• 資料DL
• サービスページ閲覧
• ウェビナー参加
• 直近行動

などを数値化し、一定点数を超えた対象をMQL候補とすることができます。

しかし、スコアは判断の入口です。

スコアが高い＝SQLではありません。

SQLでは営業が実際の課題、状況、タイミング、関係者などを確認します。

リードスコアリングそのものについては、関連記事で評価項目・閾値・減衰・営業フィードバックまで詳しく整理すると、MQL・SQL記事との役割を分けやすくなります。

インテントデータはMQL・SQL判断をどう補完する？

自社のWeb行動や資料DLだけでは、その企業が自社外でどのようなテーマを情報収集しているのか見えない場合があります。

そこで、法人単位の興味関心などを示すインテントデータを補助情報として使う方法があります。

例えば、

• Fitが高い
• 過去に資料DLしている
• しばらく行動がなかった
• 最近、関連テーマへの関心が再び高まった

という場合、再度営業確認する候補にできます。

ただし、インテントが高いからSQLになるわけではありません。

インテントは「確認する理由」を増やす情報、SQLは営業が確認した結果と分けて考えます。

MQL・SQLを設計する7ステップ

MQL・SQLを使う目的を決める

部門間の引き渡し、商談品質改善、対応漏れ削減など、何を改善したいのかを決めます。

受注・有効商談から逆算する

過去に良い商談・受注につながった企業の属性、流入経路、行動、課題を確認します。

MQL条件を決める

Fit、行動、スコア、直近性、即時確認条件を定義します。

営業へ渡す情報を決める

企業・人物・行動・関心・過去接点・仮説・未確認事項を整理します。

SQL条件を決める

営業がどの情報を確認したら具体的な営業対象とするか決めます。

差し戻し理由を標準化する

情報収集、時期、対象外、担当者違いなどを共通項目にします。

結果を見ながら定義を更新する

MQL→SQL→商談→受注の結果から、MQL条件・SQL条件を見直します。

MQL・SQLで見るべきKPI

KPI	分かること
Lead→MQL率	マーケティング施策からどの程度対象候補が生まれたか
MQL数	マーケティングが営業確認候補として創出した量
MQL営業確認率	営業が実際にMQLを確認しているか
MQL→SQL率	マーケティング基準と営業判断がどの程度合っているか
SQL化しない理由	Fit・タイミング・情報不足等の問題が分かる
SQL→商談・案件率	SQL定義が案件形成と結び付いているか
案件→受注率	上流の「質」が最終成果までつながっているか
ステージ滞留時間	MQL・SQLで見込み客が止まっていないか

MQL数だけ増えても、MQL→SQL率やSQL以降の成果が悪化していれば、MQL条件を広げすぎている可能性があります。

逆にMQL数が非常に少なく、営業リソースが余っているなら、MQL基準が厳しすぎる可能性もあります。

MQL・SQLの良し悪しは、件数単体ではなくステージ間の流れで評価します。

インサイドセールスの成果指標については、インサイドセールスのKPI設計｜リード数より見るべき商談化・顧客体験指標でも整理しています。

MQL・SQL運用でよくある失敗

MQLを資料ダウンロードと同義にする

資料取得だけではFitや現在の検討状況までは分かりません。企業条件や他の行動も確認します。

MQL数だけをマーケティングKPIにする

件数を増やすために条件が緩くなる可能性があります。SQL・案件・受注まで確認します。

営業がMQLを見たか分からない

受領、確認、SQL化、差し戻しをCRM等で分けて管理します。

SQLの条件が営業担当者ごとに違う

最低限確認する課題、時期、Fitなどを共通化します。

SQLにならなかった理由を残さない

MQL条件を改善できなくなるため、差し戻し理由を選択式などで標準化します。

一度決めた基準を変更しない

商材、ターゲット、営業体制が変われば適切なMQL・SQL条件も変わります。

MQLとSQLを顧客の価値ランクとして扱う

今SQLではない顧客も、タイミングが変われば将来の重要顧客になる可能性があります。

MQL・SQLの実務チェックリスト

チェック項目	何を確認するか	不足している場合
MQLの定義	マーケ・営業双方が説明できるか	Fit・行動・直近性を明文化する
SQLの定義	営業担当者間で基準が揃っているか	最低限の確認項目を決める
即時確認	問い合わせ等をスコア待ちしていないか	別トリガーを設定する
引き渡し情報	企業名・点数だけになっていないか	行動・関心・仮説・未確認事項を付ける
営業確認	MQLを誰がいつ見るか決まっているか	担当・期限を設定する
差し戻し理由	SQLにならない理由を残しているか	理由コードを標準化する
再確認条件	時期が早いリードを放置していないか	再連絡・シグナル条件を設定する
MQL→SQL率	基準の整合性を測れているか	ライフサイクルを計測する
SQL以降	案件・受注まで追えているか	CRMでファネルを接続する
定義更新	営業結果から基準を変えているか	定期レビューを設定する

まとめ｜MQLとSQLの違いは「誰が何を確認したか」で考える

MQLとSQLの違いは、単純なリードの温度差ではありません。

MQL：マーケティングがデータや条件から営業確認候補と判断

↓

営業・インサイドセールスが現在の課題や状況を確認

↓

SQL：営業が具体的に追う対象と判断

という流れで考えます。

そして、SQLにならなかったMQLは「悪いリード」として捨てるのではありません。

情報収集段階なら育成へ戻し、時期が先なら再確認時期を設定し、対象外ならFit条件を改善します。

インティメート・マージャーが関わったセミナーでも、営業とマーケティングでは「リードの質」に関する認識がずれやすく、ターゲットリスト、顧客行動データ、リードスコアリング、成果分析を一つのプロセスとして扱う重要性が示されてきました。

MQLとSQLはマーケティングと営業を分断する境界線ではなく、顧客情報を次の判断へ引き継ぐための共通言語です。

MQLとSQLに関するよくある質問

MQLとは何ですか？

MQLはMarketing Qualified Leadの略です。マーケティングが企業属性やWeb行動、資料DL、ウェビナー参加、リードスコアなどから、一定の条件を満たしたと判断した見込み客を指します。

SQLとは何ですか？

SQLはSales Qualified Leadの略です。営業やインサイドセールスが顧客の課題、適合性、検討状況、時期などを確認し、具体的な営業活動を進める対象と判断した見込み客を指します。

MQLとSQLの一番大きな違いは何ですか？

判断主体と確認情報が異なります。MQLは主にマーケティングがデータやルールから判断し、SQLは営業が顧客との接点を通じて具体的な営業対象か確認します。

MQLは何点以上にすべきですか？

一律の正解はありません。過去の商談・受注データ、ターゲット企業条件、リード母数、営業人数などをもとに仮の閾値を作り、MQL→SQLや案件化の結果から調整します。

資料請求した人はMQLですか？

企業の定義次第です。資料請求をMQL条件の一つにすることはできますが、資料取得だけでは対象企業か、検討時期はいつかまでは分からないため、Fitや他の行動と組み合わせる方法があります。

MQLからSQLにならなかった場合はどうしますか？

理由に応じてナーチャリング、再確認、別担当者への変更、対象外処理などへ戻します。重要なのは、SQLにならなかった理由を記録してMQL条件の改善へ利用することです。

MQLとSQLの間にSALは必要ですか？

必須ではありません。営業がMQLを「受領した状態」と「営業対象として認定した状態」を分けて管理したい場合、Sales Accepted Leadという中間ステージを設ける方法があります。