MQLとSQLの違いとは？定義と受け渡し基準、TQL・SALも一覧表で

最終更新：2026年10月17日

MQLとSQLの違いは、誰が「この見込み客は次に進めてよい」と判断したかにあります。MQL（Marketing Qualified Lead）はマーケティング部門が「営業に渡してよい」と判断した見込み客で、SQL（Sales Qualified Lead）は営業部門が「商談として追う」と判断した見込み客です。ここでのSQLはデータベースの言語ではなく、BtoBマーケティングで見込み客（リード）の段階を表す言葉です。結論を先に書くと、二つの境目はスコアの点数で決まるものではありません。営業とマーケティングが先に交わした約束で決まります。この記事では、違いの一覧表とリードの段階表、SALやTQLとの関係、受け渡し基準の決め方、2026年時点の注意点までを書いていきます。

MQLとSQLの違い一覧──リードの段階表つき

MQLとは、マーケティング部門が属性と行動の記録から「営業が話す価値がありそう」と判断した見込み客です。SQLとは、営業部門が実際に接触して確かめ、「商談として追う」と決めた見込み客です。一文で言えば、MQLは「話す価値がありそうな人」、SQLは「話して確かめた人」です。

MQLとSQLは、リードが最初の接点から受注まで進む途中の二つの駅です。リードの温度が上がっていく順に段階を並べると、二つの位置がはっきりします。判定の例は説明のための架空の基準で、どこかの会社の実際の基準ではありません。

表を上から見ると、MQLまでは「記録から推測した段階」、SQLからは「会話で確かめた段階」に分かれます。いちばん揉めやすいのは、その切り替わりにあたるMQLとSQLのあいだです。推測を確認に変える手間を誰が引き受けるのかが決まっていないと、リードはこの駅で止まります。

MQLとは／SQLとは──デマンド・ウォーターフォールが広めた言葉

MQLとSQLは、米国の調査会社シリウスディシジョンズ（SiriusDecisions）が示した「デマンド・ウォーターフォール」というモデルで広まった言葉です。のちに同社を買収したフォレスター・リサーチ（Forrester Research）のブログ記事は、このモデルを2006年に最初に発表し、2012年の改訂版、2017年の「デマンド・ユニット・ウォーターフォール」へと広げてきたと書いています。

最初の版は5つの段階でできていました。マーケティングが集めた問い合わせの一部がMQLとして営業に渡り、営業がそれを受け入れ、確かめ、受注する、という流れです（フォレスターの解説記事）。日本では「問い合わせ→MQL→SAL→SQL→受注」の5段階として紹介されることが多く、上の段階表もこの順番に沿っています。

MQLやSQLの周りには、似た呼び名がいくつもあります。一緒に調べられることの多い言葉を中心に、意味と使われる場面を並べました。

TQLは、2012年の改訂版で、電話で見込み客と話す「テレプロスペクティング」の段階が加わったときに使われ始めた呼び名です（改訂版を紹介したカスタマーシンクの記事）。いまのインサイドセールスに近い役割で、予算・決裁権・必要性・時期の4つを確かめる「BANT」と呼ばれる項目が、ここでの判定によく使われます。

リードを集める段階の手法はリードジェネレーションとは？手法一覧とナーチャリングとの違いに、集めたリードを育ててMQLまで連れてくる段階の手法とスコアリングの考え方はリードナーチャリングとは？手法一覧とリードジェネレーションとの違いにまとめました。この記事は、その先の「受け渡し」に集中します。

混同されやすい理由と、間違えると起きること

MQLとSQLが混同されやすいのは、どちらも「質の高いリード」と訳せてしまい、しかも同じMAやCRMの画面に並んでいるからです。違いを曖昧にしたまま運用すると、二つの部署が同じ言葉で別のものを数え始めます。部門をまたぐ受け渡し全体の設計はTHE MODELとは？に書きました。

BtoBのマーケティングに関わっていた頃、マーケティングが報告するMQLの数と、営業が感じている「来ているリード」の数がまったく合わない場面を何度も見ました。どちらの数字も間違ってはいません。マーケティングはMAの設定でスコアが線を越えた人を数え、営業は自分が連絡して手応えのあった人を数えていた。同じMQLという言葉で、違う集合を数えていたわけです。実務で起きやすい混同を表にしました。

このずれは、部署どうしの仲の悪さとして表に出てきます。評価の数字が別々だと対立が起きる構造そのものは、マーケティングと営業の違いとは？部署・職種の役割と仲が悪い理由で書きました。MQLとSQLの定義をそろえることは、その対立をいちばん手前でほどく作業でもあります。

受け渡し基準の決め方──スコアより先に、営業との合意

MQLからSQLへの受け渡し基準は、スコアの点数を決める前に、営業と「どんな相手となら話したいか」を言葉で合意するところから始めます。点数はその言葉を機械で判定するための翻訳で、翻訳の元になる言葉がなければ、どこに線を引いても揉めます。

手順にすると、次の5つです。

• 過去に受注した顧客を並べ、最初の接点から受注までにどんな行動があったかを、営業と一緒に見る
• 「営業が話したい相手」の条件を、属性と行動に分けて一行ずつ書く
• その条件をMAのスコアに置き換え、MQLの線を決める
• 営業が受け取る期限と、SQLと判定する確認項目を決める
• 差し戻しの理由と戻し先を決め、月に一度、線と項目を見直す

MQLの判定とSQLの判定では、同じ「属性」「行動」でも見るものが変わります。MQLは記録から読める範囲、SQLは会話で聞けた範囲です。

この合意を文書にしたものを、営業とマーケティングのSLA（サービスレベル・アグリーメント）と呼ぶ会社もあります。マーケティングは決めた基準を満たすMQLを渡し、営業は決めた期限内に連絡して、SQLにするか差し戻すかを記録する。お互いが何を約束するかを並べた一枚の紙です。

基準づくりでいちばん抜けやすいのは、差し戻しの扱いです。営業が「まだ早い」と判断したMQLは、失敗ではなく、時期が来ていないという情報です。差し戻しの理由を「時期が先」「決める人ではない」「対象外」のように選べる形にしておくと、マーケティングはその理由ごとに育て方を変えられます。MQLとSQLを指標として置くときは、最終的な受注数とその手前の移行率を分けて考えると話が整理されます。置き方の型はKPIとKGIの違いとは？KAI・OKRも含めて1枚の比較表でわかりやすく解説で書きました。

日本市場・2026年時点での注意点

2026年の日本でMQLとSQLを運用するときに押さえたいのは、社内の呼び名との二重化、買い手の調べ方の変化、そして「個人」から「会社」への単位の移動の三つです。どれも、海外の定義をそのまま輸入しただけでは噛み合わない点です。

一つ目は呼び名です。日本の営業現場には「ホットリード」「確度A」のような昔からの呼び名があり、MQLやSQLを導入しても古い呼び名が残って、同じ人が二つの名前で呼ばれることがあります。新しい言葉を足す前に、既存の呼び名と各段階の対応表を一枚つくっておくと、会議での行き違いが減ります。

二つ目は、買い手の調べ方です。2026年はAIの検索や要約で比較がかなり進んでから問い合わせが来るので、サイト上の行動の記録が少ないまま、いきなり具体的な相談が届くことが増えています。行動スコアの合計だけでMQLを判定していると、こうした検討の進んだ人が線を越えないまま放置されかねません。「料金や導入の相談」のように意図がはっきりした問い合わせは、スコアを待たずに営業の確認へ回す例外の道を用意しておくほうが確かです。

三つ目は単位です。シリウスディシジョンズは2017年に、測る単位を個人のリードから、同じ必要性のために動く購買グループ（デマンド・ユニット）へ移したモデルを発表しています。BtoBでは一人が決めるのではなく、複数の人が関わって決めます。同じ会社から別々の人が少しずつ資料を見ている場合、一人ずつのスコアでは線を越えなくても、会社として見れば検討が始まっていることがあります。人ごとのMQLとは別に、会社ごとに反応をまとめて見る目を持っておくと、取りこぼしが減ります。

MQLとSQLを分けるのは大きな組織のための仕組みに見えますが、一人で集客から商談までを担う小さな会社でも、考え方は同じように効きます。「記録から推測した段階」と「話して確かめた段階」を頭の中で分けておくだけで、連絡の順番と中身が変わるからです。

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

MQLとSQLは、結局同じ「質の高いリード」ではないですか？

どちらも見込みのある相手ですが、判断の材料と判断する部署が違います。MQLは記録から「話す価値がありそう」とマーケティングが推測した段階で、SQLは営業が会話で必要性や時期を確かめた段階です。同じものとして扱うと、推測の段階のリードに商談の期待がかかり、空振りが続いて両部署の信頼が崩れます。

SALやTQLとは何ですか？

SAL（Sales Accepted Lead）は、営業がMQLの受け取りを認めた段階で、SQLの手前に置かれます。TQL（Teleprospecting Qualified Lead）は、電話やメールで見込み客と話す担当が会話で確かめた見込み客で、インサイドセールスを置く会社で使われます。どちらも、MQLとSQLのあいだの受け渡しを細かく管理するための呼び名です。

MQLの基準はどう決めればいいですか？

先に営業と「どんな相手となら話したいか」を言葉で合意し、それを属性と行動の条件に分けてからスコアに置き換えます。過去に受注した顧客が受注までにどんな行動をしていたかを一緒に見ると、条件が具体的になります。決めた基準は月に一度、SQLになった人とならなかった人の差を見て直します。

MQLからSQLへの転換率の目安はどれくらいですか？

業界平均として引かれる数字はいくつかありますが、元の調査の方法までたどれるものは少なく、一次出典として使える目安は見当たりませんでした。MQLの定義が会社ごとに違うので、同じ転換率でも中身が比べられないという事情もあります。他社の数字より、自社の定義をそろえたうえで月ごとの変化を追うほうが判断に使えます。

おわりに──MQLとSQLを分けているのは、点数ではなく約束

MQLとSQLの違いは、リードの温度の違いに見えます。スコアが何点を越えたらMQL、営業が確かめたらSQL。表にすればそれだけの話です。でも、その温度計の目盛りを決めているのは、MAの設定画面ではなく、二つの部署が交わした約束です。約束のない目盛りは、どこに線を引いても揉めます。

MQLとSQLを分けているのは、点数ではなく約束。

受け渡しがうまくいかないと感じたら、スコアの線を動かす前に、営業と「どんな相手となら話したいか」を一行で書けるかを確かめてみてほしいと思います。その一行が書けたとき、MQLとSQLは数字の名前から、二つの部署の共通語に変わります。