MQL・SQLとは｜違いと基準の決め方、ナーチャリングの進め方

MQLは、マーケティング部門が「関心が高まった」と判断して営業へ渡せる状態にしたリードで、SQLは、営業部門が「商談として追うべき」と判断したリードです。どちらも、お客様の購買意欲の段階に名前を付けて、マーケティングと営業の役割と引き渡しの基準をはっきりさせるための言葉です。商談を増やすには、MQLの数を増やすだけでなく、MQLをSQLへ育てる仕組み（リードナーチャリング）と、その基準を営業と合意しておくことが分かれ目になります。

この記事では、MQL・SQLの定義、営業と合意する基準の作り方、スコアリング、ナーチャリングの手段、CRMでの管理方法をまとめます。Nexlyは、広告・サイトでのリード獲得から、SalesforceやkintoneなどのCRMの設計、メールやフォームの自動化までを一緒に組む立場で、「誰を、どの時点で、誰が追うか」を決める作業にたびたび関わります。その実務の順に書きます。例の数字は仮定です。

MQL・SQLとは？リードの段階に名前を付ける理由

リードは、自社に接点を持った見込み客のことです。問い合わせ、資料請求、セミナー参加、メルマガ登録など、きっかけはさまざまで、購買意欲もまちまちです。すべてのリードを同じように営業が追うと、まだ検討前の人に電話して嫌がられたり、本当に買いたい人への対応が遅れたりします。そこで、購買意欲の段階に名前を付け、段階ごとに担当と対応を変えます。

Salesforceの解説では、MQLは「マーケティングがコミュニケーションを担当すべき見込み顧客」、SQLは「営業部門が商談化に向けてアプローチすべき見込み顧客」と説明されています。購買意欲が一定の水準に達したリードを営業へ渡し、営業が追うと判断した時点でSQLになる、という流れです。

この呼び名や段階の数は、会社ごとに決めて構いません。MQLとSQLの定義は、会社や使うツールによって違いがあります。たとえばHubSpotの公式ヘルプでは、ライフサイクルステージとして、Subscriber、Lead、Marketing Qualified Lead（MQL）、Sales Qualified Lead（SQL）、Opportunity、Customer、Evangelistの順に並べています。MQLは「マーケティングチームが営業チームに引き継げる状態と判断した連絡先または会社」、SQLは「営業チームが見込み顧客と判断した連絡先または会社」と説明されています。同じ「SQL」でも、ツールの定義と自社の定義が一致するとは限りません。

このように、言葉の定義はツールや会社ごとに違います。同じ「SQL」でも、営業が追うと判断した状態を指す場合もあれば、商談として登録された状態を指す場合もあります。自社ではどの状態をMQL・SQLと呼ぶのかを、先に文章で決めておくことが必要です。他社の記事の数字や、ツールの標準のレポートを見るときも、その定義が自社と同じかを確かめます。

営業と合意する基準の決め方：MQLとSQLの定義書

MQL・SQLの運用でうまくいかなくなる原因のひとつは、基準がマーケティングと営業で食い違っていることです。マーケティングは「資料請求したのだから見込みがある」と渡し、営業は「まだ検討前で話にならない」と返す。この往復が続くと、渡されたリードが放置され、せっかく集めた見込み客が離れます。Salesforceの解説でも、営業が引き合いによるSQLを優先し、マーケティングから渡されたリードを後回しにしがちなことが、よくある課題として挙げられています。

基準は、次のような一枚にまとめて、両部門で合意します。

段階	定義（仮定の例）	判定する人	次にやること
リード	連絡先が分かる接点がある（資料請求、メルマガ登録、セミナー参加など）	システムで自動	ナーチャリングの配信対象にする
MQL	スコアが基準点以上、または価格ページの閲覧など強い関心の行動が複数ある	マーケティング（スコアで自動判定）	営業に通知し、インサイドセールスが確認する
SQL	課題・時期・予算・決裁の見通しのうち、複数が確認できている。またはデモや相談の希望がある	営業またはインサイドセールス	商談を設定する
商談	商談日程が決まり、案件としてCRMに登録された	営業	提案・見積もり

SQLの判定の目安としてよく使われる枠組みに、BANTがあります。予算（Budget）、決裁権（Authority）、必要性（Needs）、導入時期（Timeframe）の4つで、これらが確認できているかを見ます。ただし、4つ全てを初回の電話で聞き出す必要はありません。会社によって、必要性と時期だけでSQLとする、といった緩めの基準も使われます。商材の単価や検討期間で、基準の厳しさは変わります。

基準を決めるときに、営業と確認しておく3つのこと

• 営業が「今すぐ話したい」と思うリードの特徴は何か。過去の受注顧客が、受注前にどんな行動をしていたかをCRMとWebの記録から見直します。
• 営業が追えるリードの数は、1人あたり週に何件までか。基準を緩めてMQLを増やしても、営業が追えなければ意味がありません。
• 渡したあとのフィードバックを、どう返すか。「連絡がつかない」「検討時期が先」「競合に決定済み」など、理由を選択肢で記録できるようにします。

この3つを決めておくと、基準の見直しがしやすくなります。基準は最初から完璧にはならず、3か月ごとに受注データと照らして調整するものと考えておきます。

定義書を運用に乗せる：最初の1か月でやること

定義書ができたら、すぐにCRMの項目と通知の設定に移します。最初の1か月は、次の順で進めると、運用が軌道に乗りやすいです。

1. 第1週：直近3〜6か月のリードを、定義に当てはめて仕分ける。MQL、SQL、商談になったリードの数を数える
2. 第2週：営業と一緒に、仕分け結果を確認する。「これはSQLではない」という違和感を集めて、定義を直す
3. 第3週：CRMに、状態・日付・理由の項目を追加し、入力ルールを営業に説明する
4. 第4週：新しいリードから運用を開始し、週に一度、15分で件数と放置されたリードを確認する

過去のリードで試す工程を入れておくと、定義が現実と合うかを、本番の前に確かめられます。過去のデータが少ない場合は、直近のリードで試すだけでも、営業との認識のずれが見えます。

スコアリング：属性と行動に点数を付けて、MQLを自動で判定する

スコアリングは、リードの属性と行動に点数を付けて合計し、関心度を数字で見る方法です。Salesforceの解説でも、属性（役職、業種、企業規模）と行動（ページの閲覧、資料のダウンロード、メールのクリックなど）の点数を合計してMQLを判定する方法が紹介されています。

種類	項目の例	点数（仮定の例）
属性	決裁に関わる役職	＋15
属性	自社が想定する規模・業種に合う	＋10
行動	価格・料金ページの閲覧	＋10
行動	資料のダウンロード	＋15
行動	事例の閲覧・ダウンロード	＋15
行動	メールのリンククリック	＋3
行動	問い合わせ、デモ・相談の希望	＋30
減点	想定外の業種、個人メールのみ、競合の可能性	−10〜−20

この点数は仮定の例で、自社の数字は、過去に受注した顧客の行動を見て決めます。Salesforceの解説でも、閾値は最初は仮の値で始め、受注顧客のデータや運用結果を見ながら調整するのが望ましいとされています。閾値が高すぎるとMQLが減りすぎ、低すぎると質の低いリードが営業に回ります。

もうひとつ、古い行動の点数を、時間とともに減らす設計も入れておきます。3か月前に資料をダウンロードしただけの人が、点数が残り続けてMQLのままになると、今の関心度とずれます。Salesforceの解説でも、時間経過でスコアを減衰させる例（3か月前の行動のスコアを半分にする）が挙げられています。減点の仕組みがない場合は、定期的に「直近の行動がないリード」を見直す運用で代わりにします。

スコアリングを始める前のステップとして、まずは点数を付けずに、「受注した顧客の過去の行動を見る」ところから始めてもかまいません。CRMに記録された問い合わせ元、見たページ、受けたメールのクリックを、受注した顧客と受注しなかった顧客で並べるだけで、基準のヒントが見えます。

スコアに頼りすぎない：スコアが高くても追わないリード

スコアが基準を超えていても、営業が追わないほうがよいリードもあります。たとえば、競合の社員や同業者、学生、求職者が、情報収集で資料をダウンロードした場合です。点数は高くても、商談にはなりません。メールアドレスのドメインや、フォームの会社名、職種の欄で、除外する条件を入れておきます。除外条件は、営業が「これは商談にならなかった」と感じたリードの共通点を集めて、少しずつ追加します。

逆に、スコアが基準に届いていなくても、営業が直接声をかけるべきリードもあります。展示会で名刺交換して、その場で具体的な相談があった場合や、既存のお客様の紹介で来た場合などです。この場合は、スコアに関わらず、営業に直接渡す例外のルートを用意しておきます。スコアは判断の補助で、全てをスコアだけで決めるものではありません。

リードナーチャリングの手段：6つの方法と使い分け

リードナーチャリングは、獲得したリードに段階的に関わり、購買意欲を高めていく活動です。Salesforceの解説では、メールマーケティング、コンテンツマーケティング、SNS運用、ウェビナー・セミナー、スコアリング、インサイドセールスの6つが施策として挙げられています。

手段	向く段階	使いどころ	注意点
メール（ステップメール、メルマガ）	リード全般	資料請求後の継続した接点。属性や行動で内容を分ける	配信停止の導線と、頻度の管理が必要
コンテンツ（記事、事例、ホワイトペーパー）	検討の前半	課題の整理、他社の進め方の理解を助ける	検討の段階に合ったものを用意する
セミナー・ウェビナー	検討の中盤	専門性の提示と、双方向のやりとり	参加後の追客まで設計に入れる
SNS	検討の前	日常的な接点と、自社メディアへの誘導	直接の商談化は起きにくく、時間がかかる
インサイドセールス（電話・オンライン）	MQLからSQLへ	課題や時期を聞き取り、商談の可否を判断する	断られた理由を記録し、基準に反映する

メール配信で守ること：特定電子メール法

ナーチャリングでメールを送る場合は、「特定電子メールの送信の適正化等に関する法律」（特定電子メール法）に沿う必要があります。総務省の資料では、広告・宣伝メールは、あらかじめ送信に同意した人にだけ送るオプトイン方式が原則とされ、同意のない人への送信は原則禁止と説明されています。取引関係にある人への送信や、名刺などで自分のメールアドレスを知らせた人への送信など、同意なしで送れる例外もあります。

あわせて、送信者の氏名または名称、受信を拒否するための連絡先（メールアドレスやURL）、送信者の住所、苦情や問い合わせを受け付ける連絡先を表示する義務があります。同意を得たことを示す記録（時期と方法など）は、そのアドレスへ最後に広告宣伝メールを送った日から1か月、保存する必要があります。同意があっても、受信拒否の通知を受けたあとは送信できません。資料請求のフォームには、「資料のお届けに加えて、関連する情報をメールでご案内します」といった同意の文言とチェックの欄を設け、いつ誰が同意したかをCRMに残しておきます。具体的な要件や例外の範囲は、総務省の最新の資料で確認してください。通信販売などの広告メールには、特定商取引法も関わります。

ステップメールの組み方（仮定の例）

資料請求をした人に送るステップメールを例に、組み方を示します。内容は、相手の検討の進み方に合わせ、売り込みではなく、判断に役立つ情報を中心にします。

1. 即時：お礼と資料の案内。次に読むと良いページを1つ添える
2. 3日後：資料の補足として、導入の進め方や、よくある質問をまとめた記事を案内する
3. 7日後：近い課題を持つお客様の事例を案内する
4. 14日後：個別相談の案内。相談で扱える内容を具体的に書く

途中で価格ページを見る、事例をダウンロードする、といった強い関心の行動があった場合は、配信の順番を待たず、インサイドセールスに通知して、早めに連絡する分岐を入れます。メールが全員に同じタイミングで届くのではなく、行動に合わせて動く形にすると、ナーチャリングの効果が出やすくなります。配信は、本人が許可した範囲で行い、いつでも配信停止できるリンクを入れます。

配信内容を分ける軸：検討の段階と関心の領域

ナーチャリングのメールを、全員に同じ内容で送ると、関心の薄い情報が届いて、配信停止につながります。分ける軸は二つあります。ひとつは検討の段階（情報収集中か、比較中か、導入を決めかけているか）、もうひとつは関心の領域（どの商品、どの課題に関心があるか）です。

検討の段階は、見たページや、ダウンロードした資料の種類で推測できます。用語の解説記事を読んでいるなら情報収集中、料金や事例を見ているなら比較中、相談や見積もりのページを開いたなら導入に近い、という具合です。関心の領域は、資料請求のフォームで選んだ項目や、閲覧したページのカテゴリーから分かります。この二つを掛け合わせて、3〜4通りの配信パターンを用意すると、どの内容にどんな反応があったかを比べられるようになります。

CRMでの管理：項目と状態の遷移を決める

MQL・SQLの運用は、CRMの項目の設計で決まります。紙の定義書があっても、CRMに入力する項目がなければ、運用は続きません。CRMとSFA、MAの役割の違いはCRM・SFA・MAの違いで整理しています。

項目	入れる値の例	目的
リードの状態	リード、MQL、SQL、商談中、受注、失注、保留	段階ごとの件数と転換率を数える
流入元	広告、検索、紹介、セミナー、展示会など	どこから来たリードが商談になったか見る
MQLになった日・SQLになった日	日付	段階ごとの所要日数を出す
次のアクションと期限	電話、メール、資料送付、日付	放置されたリードを防ぐ
失注・保留の理由	時期が先、予算が合わない、競合に決定、連絡不通など（選択式）	ナーチャリングと基準の見直しに使う

失注や保留の理由を、自由記述のままにしないことがポイントです。選択式にしておくと、「時期が先」の理由が多いなら、数か月後に再度連絡する仕組みが必要だと分かります。「予算が合わない」が多いなら、広告やサイトの段階で、費用の考え方を伝える必要があります。

見落とされやすいのが、「保留」の扱いです。今は買わないが将来買う可能性がある人を、失注にしてしまうと、情報が消えます。保留として残し、ナーチャリングの配信対象に戻し、一定の行動があれば再びMQLに上げる流れにしておきます。CRMの入力が定着しないときは、CRMが現場で使われない原因と立て直し方に、項目を絞って入力を続けやすくする方法を書いています。問い合わせの自動振り分けや、CRMへの自動登録を組む場合は、問い合わせ・メールの自動振り分けも参考になります。

引き渡しのルールと、営業からのフィードバック

MQLをSQLへつなぐ最後の関門が、マーケティングから営業への引き渡しです。ここで、渡す基準と同じくらい必要なのが、渡したあとのルールです。Salesforceの解説でも、部門間の引き渡しルール（SLA）として、引き渡しの基準、共有する情報、営業が初回に連絡する期限（例として、引き渡し後24時間以内）、結果のフィードバックの方法を定めることが推奨されています。

• 引き渡し時に共有する情報：流入元、見たページ、ダウンロードした資料、スコアの内訳、問い合わせの内容
• 初回の連絡の期限：自社の営業体制で守れる範囲で決める（例：翌営業日中）
• 結果の記録：連絡がついたか、SQLにするか、保留にするか、理由は何か、を入力する
• 見直しの会議：月に一度、MQLの質をマーケティングと営業が一緒に確認する

営業側が最初に連絡する期限は、リードの熱が冷める前に会うという意味もあります。問い合わせや資料請求から連絡までの時間が空くほど、相手の関心が薄れ、他社と先に話してしまう可能性が高まります。仕組みで通知を出し、期限を過ぎたらマネージャーにも知らせる、といった確認の仕組みを入れておくと、放置が減ります。

追う数字：段階ごとの転換率で、どこを直すかが決まる

運用を始めたら、段階ごとの数字を追います。見るのは、MQLの数、MQLからSQLになった割合、SQLから商談になった割合、商談から受注になった割合、各段階にかかった日数です。仮定の数字で、効果を試算します。

段階	現状（仮定）	ナーチャリング改善後（仮定）
月のMQL数	100件	100件
MQL→SQLの割合	25%（25件）	30%（30件）
SQL→商談の割合	60%（15件）	60%（18件）
商談→受注の割合	20%（3件）	20%（3.6件）

MQLの数を増やさなくても、MQLからSQLになる割合が5ポイント上がると、受注が月3件から3.6件へ、20%増えます。MQLを増やすために広告費を上げるより、すでにいるMQLを育てるほうが、費用が小さくて済む場合があります。ただし、この試算は他の割合が変わらないという仮定です。実際は、ナーチャリングで育った見込み客のほうが、受注率が上がることもありますし、基準を緩めたせいで下がることもあります。数字は毎月見て、どの段階が変わったかを確かめます。

段階ごとの数字を追うための指標の分解は、KPIツリーの作り方で書いています。段階ごとの数字の見方と、お客様の動きの関係を整理するには、カスタマージャーニーマップも合わせて使えます。

所要日数も見る：リードがどこで止まっているか

割合だけでなく、各段階にかかった日数も見ます。たとえば、MQLになってからSQLになるまでの日数を、リードごとにCRMで出すと、半数のリードが何日以内に動いているかが分かります。日数が長いリードが多いなら、検討期間が長い商材か、営業の連絡が遅れているかのどちらかです。MQLになった日、営業が最初に連絡した日、SQLになった日の3つが記録されていれば、遅れがどこで起きているかを切り分けられます。

営業が最初に連絡するまでの日数が長いなら、通知の仕組みや担当の割り当てを見直します。連絡後にSQLになるまでが長いなら、ナーチャリングの内容や、基準の厳しさを見直します。数字が悪いと感じたとき、どの段階の誰の問題かを決めつけず、日数と割合で切り分けるところから始めます。

よくある失敗：MQL・SQLの運用が止まる6つの原因

• 基準が営業と合意されていない：マーケティングだけで決めた基準は、営業に使われません。基準は両部門で決めます。
• スコアを作ったまま調整しない：受注データと照らして、最初の3か月で閾値を見直します。
• MQLの数だけをマーケティングの成果にする：数を追うと質が下がります。SQLと受注までの割合も、成果として見ます。
• 渡したあとを追わない：営業のフィードバックが記録されないと、基準の改善ができません。
• 保留のリードを放置する：将来の見込み客が失われます。ナーチャリングの対象に戻します。
• 営業の追える数を超えて渡す：追えない量を渡すと、後回しにされて離れます。営業の人数に合わせて、基準の厳しさを調整します。

運用の出発点は、小さく始めることです。最初から全ての項目を整えようとせず、「MQLとSQLの定義を一枚に書く」「CRMに状態の項目を足す」「月に一度、営業と数字を見る」の3つから始めて、半年で整えていくほうが、現場に定着します。

よくある質問

Q. MQLとSQLの違いを、一言で言うと何ですか？

MQLはマーケティングが育成して営業に渡せる状態、SQLは営業が商談として追うと判断した状態です。誰が判断するかが違います。

Q. 小さな会社にもMQL・SQLの仕組みは必要ですか？

営業とマーケティングが同じ人なら、細かい区分は要りません。ただし、「今すぐ追うリード」と「しばらく育てるリード」を分ける考え方は、人数が少ないほど役に立ちます。CRMに状態の項目を1つ足すだけでも始められます。

Q. MAツールを入れないと、スコアリングはできませんか？

MAツールがあると自動化できますが、なくても始められます。スプレッドシートやCRMの項目で、資料請求、問い合わせ、価格ページの閲覧など、重要な行動の有無だけを手で記録する方法でも、基準の検討には使えます。

Q. インサイドセールスがいない場合は、誰が確認しますか？

営業担当が兼ねる、またはマーケティング担当が一次確認をする形があります。確認する人と、期限を決めておくことが前提です。人数が限られるなら、確認するリードの条件を厳しくして、数を絞ります。

Q. ナーチャリングの効果は、どう確かめればよいですか？

配信を受けたリードと受けなかったリードで、SQLになった割合を比べます。配信の開封率やクリック率だけでなく、商談化や受注につながったかを見ます。母数が少ないうちは、半年ほどの期間で見るのが現実的です。

まとめ：基準を営業と合意し、育てて渡す仕組みで商談を増やす

MQL・SQLは、リードの段階に名前を付けて、マーケティングと営業の役割を分けるための言葉です。数を追うより、営業と合意した基準で渡し、育てて、結果を基準に返す循環をつくることが、商談の増加につながります。

• MQL・SQLの定義は会社とツールで異なるので、自社の定義を一枚の定義書にして営業と合意する
• スコアリングは仮の閾値で始め、受注データを見て調整する。古い行動は減点する
• ナーチャリングは、メール、コンテンツ、セミナー、インサイドセールスを、検討の段階に合わせて使い分ける
• CRMに状態、流入元、日付、失注・保留の理由を入れ、保留はナーチャリングに戻す
• 渡した後の連絡期限とフィードバックを決め、段階ごとの転換率を毎月見る

関連記事

• マーケティングの上流設計とは｜広告を出す前に決める5つのこと
• 3C分析とは｜やり方・テンプレートと例、分析で終わらせない使い方
• STP分析とは｜セグメンテーション・ターゲティング・ポジショニングの手順と例