MQLとSQLの違いとは？｜リードの質を営業と合意する

「とにかくリードの数を増やせば、あとは営業が何とかしてくれる」——BtoBマーケティングの現場に根強く残る考え方ですが、これは誤解です。営業に渡す段階で「質」の認識が部門間でずれていると、リードは増えるほどフォローされずに放置され、マーケと営業の不信感だけが積み上がります。鍵になるのが、マーケティング部門が認定するMQLと、営業部門が認定するSQLという2つの区分です。リードの質を部門間で定義し、合意し、回し続ける仕組みこそが、リードの数を売上に変える土台になります。本記事では、MQLとSQLの定義の違いから、基準を合意するプロセス、SLA（サービスレベル合意）の作り方、却下されたリードの再活用までを、運用として定着させる視点で解説します。

MQLとSQLの定義——「誰が認定するか」が違う

MQL（Marketing Qualified Lead）は、マーケティング部門が「購買の見込みが一定水準に達した」と認定したリードです。資料のダウンロード、セミナーへの参加、料金ページの閲覧といった行動や、業種・規模・役職などの属性を根拠に、マーケティングが設定した基準を満たした見込み客を指します。日本語では「マーケティング認定リード」と訳されます。

一方のSQL（Sales Qualified Lead）は、営業部門が「商談として追うべきだ」と認定したリードです。インサイドセールスや営業担当がヒアリングを行い、予算・決裁権・必要性・導入時期といった条件を確認したうえで、受注につながる可能性が高いと営業自身が判断した状態を指します。つまり両者の違いはリードの優劣ではなく、「誰が・何を根拠に認定したか」の違いです。

観点	MQL	SQL
認定する部門	マーケティング部門	営業部門
主な判断材料	行動履歴と属性（スコアリング）	ヒアリングで確認した予算・決裁権・必要性・時期
リードの状態	興味・関心が高まっている	商談化の条件がそろいつつある
次のアクション	営業への引き渡し	商談・提案活動

この整理を共有するだけでも、「リード」という言葉で別々のものを想像していたことに、両部門が気づけるはずです。言葉の解像度を上げることが、連携の第一歩になります。なお、MQLの手前や後ろにさらに細かい区分を設ける会社もありますが、まずはMQLとSQLの2つ、そして次章で触れるSALを加えた3区分で管理を始めれば十分です。

なぜ「良いリード」の認識はずれるのか

認識のずれには構造的な原因が3つあります。第一に、「質の高いリード」の定義が部門ごとに暗黙のままであること。マーケは「資料をダウンロードした企業」を見込みありと考え、営業は「今期中に予算を使う企業」を見込みありと考える。どちらも間違っていませんが、基準がすり合っていません。

第二に、評価指標の時間軸の違いです。マーケティングは今月のリード件数やMQL数で評価され、営業は今期の受注金額で評価される。同じリードを、短期の件数で見る側と、受注までの確度で見る側が別々に評価しているため、良し悪しの感覚が一致しないのは当然です。第三に、引き渡したリードがその後どうなったかの共有が乏しく、互いの判断を検証する材料がないことです。

この状態で件数だけをKPIにすると、事態は悪化します。マーケには薄いリードでも数を積むインセンティブが働き、営業のフォロー体力は有限なので、リードは配られたまま放置される。「数を増やしたのに商談が増えない」という典型的な悪循環は、こうして生まれます。営業側にも「そもそもリードの質が低いから受注が伸びない」という反論が固定化し、責任の押し付け合いから抜け出せなくなります。

MQLからSQLへ——間にSALという検問所を置く

リードが商談に至る流れは、リード獲得→ナーチャリング（育成）→MQL認定→営業への引き渡し→SQL認定→商談、と段階を踏みます。このとき、引き渡しの直後にSAL（Sales Accepted Lead）という中間段階を置く設計が広く使われています。SALは、営業が「このリードに対応する」と受け取りに合意した段階を指します。

SALを挟む目的は、引き渡したリードの放置を防ぐことです。営業は受け取るか却下するかを一定期間内に判断するルールにし、却下するなら理由を残す。これで「渡したのに追われていない」「そんなリードは受け取っていない」という不毛な水掛け論がなくなります。

さらに、段階を分けると転換率が測れるようになります。MQLからSALへの転換率が低ければ定義がずれている、SALからSQLへの転換率が低ければフォローの品質かリードの鮮度に問題がある、というように、どの段階で詰まっているかをデータで特定できることが、段階を分ける実務上の最大の価値です。

MQLの基準を作る——属性と行動の2軸で採点する

MQLの認定には、スコアリングと呼ばれる採点方式がよく使われます。軸は2つ。企業規模・業種・役職といった属性（その会社が顧客になり得るか）と、資料ダウンロード・料金ページ閲覧・セミナー参加といった行動（今どれくらい関心が高いか）です。属性が合っていても行動がなければ時期尚早、行動が活発でも属性が外れていれば対象外、と2軸で見ます。

点数のつけ方は、たとえばターゲット業種に+10点、決裁層の役職に+15点、料金ページの閲覧に+8点、デモやセミナーの参加に+10〜20点といった形で加点し、合計が基準点を超えたらMQLとする設計が一般的です。競合他社からのアクセスや長期間の無反応には減点（ネガティブスコア）を設定し、見かけの点数だけが積み上がるのを防ぎます。

注意したいのは、最初から精緻に作り込みすぎないことです。点数は過去の受注データから置いた仮説であり、正解は運用の中でしか分かりません。近年は細かな加点方式ではなく、「デモ申し込みなど特定のトリガー行動があれば即MQL」とみなすシンプルな運用も広がっています。自社のリード数と体制に合った複雑さを選んでください。

SQLの基準を作る——BANTを営業の共通言語にする

SQL側の基準づくりで広く使われるのが、BANTという確認フレームです。Budget（予算）・Authority（決裁権）・Needs（必要性）・Timeframe（導入時期）の頭文字で、ヒアリングでこの4点を確認し、商談化の判断材料にします。営業の経験則を、部門の共通言語に置き換えるための道具です。

実務のポイントは、4条件がすべてそろうのを待たないことです。初回接点でBANTが完全にそろうリードはまれで、待っていたら商談機会を逃します。「必要性と導入時期が確認できれば商談化する」「予算は商談の中で作りにいく」など、自社なりの閾値を営業部門内で統一することが目的です。判断が人によってばらつくなら、それはまだ基準になっていません。

あわせて、確認した内容をSFAや管理シートに同じ項目で記録する型を作ります。判断の理由が残っていれば、あとから「どんなリードがSQLになりやすいか」を振り返る一次データになり、MQL基準の見直しにもつながります。

インサイドセールスの役割——MQLとSQLの橋渡し

MQLからSQLへの橋渡しを担う実行部隊が、インサイドセールスです。マーケティングから引き渡されたMQLに電話やメールでコンタクトし、BANTの項目をヒアリングして、商談化の条件がそろったリードだけを営業（フィールドセールス）に引き継ぎます。分業が進んだBtoB組織では、SALの受け取り判断とSQL認定の実務は、この部隊が担うことが多くなっています。

インサイドセールスを置く利点は、判断の一貫性です。営業担当が各自の感覚でリードを選り好みする状態と比べて、同じチームが同じ基準でヒアリングするため、SQL認定のばらつきが小さくなります。ヒアリング結果が同じ形式で記録されるので、定義を見直すためのデータも運用の中で自然に蓄積されていきます。

専任チームを作れない規模の会社でも、役割としてのインサイドセールスは設計できます。たとえば「MQLへの初回コンタクトは営業アシスタントが48時間以内に行い、ヒアリング項目を埋めてから担当営業に渡す」と決めるだけでも、引き渡しの品質は大きく変わります。人を増やす前に、役割と期限を決めることが先です。

定義合意の進め方——両部門で決める4つのステップ

定義づくりで最初に守るべき原則は、マーケティング単独で決めないことです。営業が参加していない定義は、どれだけ精巧でも「マーケが勝手に決めた基準」として扱われ、運用に乗りません。次の4ステップで、両部門の共同作業として進めます。

初版は仮説で構いません。完璧な定義を目指して会議を重ねるより、粗くても合意した初版で運用を始め、データで直していくほうが、結果として早く精度が上がります。

合意した定義書は、営業会議とマーケ定例の両方で同じ資料として配り、双方の新任メンバーのオンボーディングにも使います。定義書が「マーケの文書」ではなく「両部門の文書」として扱われているかどうかが、定着度のバロメーターになります。

SLAに落とし込む——お互いの約束を文書にする

SLA（Service Level Agreement）は、もともとITサービスの品質保証で使われる言葉ですが、マーケと営業の間では「互いに何をどの水準で提供するか」の合意文書を指します。マーケ側は月間のMQL供給件数と、引き渡し時の必須情報（会社名・担当者・スコアの内訳・行動履歴など）を約束し、営業側は初回対応までの期限、一定期間内のアプローチ回数、SAL・SQLの判断と理由の記録を約束します。期限や件数は「24営業時間以内に初回コンタクト」「月20件以上」のように、誰が読んでも同じ解釈になる表現で書きます。曖昧さが残った項目は、達成の判定でまた揉める火種になります。

SLAの効果を示すデータもあります。米HubSpot社の調査では、有効なSLAが存在する企業は、そうでない企業と比べて前年からROIが向上する可能性が34%高かったと報告されています。約束が数値になっていれば、達成状況の確認がそのまま部門間定例の議題になり、連携が続く仕組みとして機能します。

特に重要なのが営業側の初回対応期限です。リードの温度は問い合わせや資料請求の直後がもっとも高く、時間が経つほど接続は難しくなります。リードの質は、定義だけでなく対応スピードによっても決まる——この認識を共有できるかが、SLAが紙切れになるかどうかの分かれ目です。

却下理由の記録——営業の不満をデータに変える

SLA運用の心臓部が、営業がMQLを却下するときの理由記録です。「連絡がつかない」「ターゲット外」「ニーズが確認できない」「時期尚早」「競合・情報収集目的」など、5つ前後の選択式にしておくと、営業の入力負担を抑えながら、集計できるデータになります。選択肢は四半期レビューで見直し、実態に合わない項目は入れ替えます。

月次で却下理由の分布を見ると、定義のどこに穴があるかが見えてきます。ターゲット外が多ければ属性条件の設定を、時期尚早が多ければ行動スコアの基準点を疑う、という具合に、却下理由の分布は定義を見直すための一次データになります。

この仕組みの副産物として、部門間の会話の質が変わります。「マーケのリードは質が低い」という感覚の応酬が、「先月の却下は4割がターゲット外だったので、対象業種の条件を絞りましょう」という集計データに基づく建設的な議論に置き換わるのです。

却下されたリードはナーチャリングへ戻す

却下は、リードの廃棄ではありません。特に「時期尚早」「予算が未確保」で却下されたリードは、課題自体は存在しているため、時間が状況を変える可能性が高い層です。ライフサイクルのステータスをリードに戻し、メルマガ・セミナー案内・事例コンテンツといったナーチャリング施策に再投入します。これがリードのリサイクルです。

リサイクルの精度を上げるコツは、却下理由や失注理由ごとにシナリオを変えることです。時期尚早なら一定期間後に再スコアリングの対象へ、ニーズ不明なら課題に気づいてもらう啓発コンテンツへ、と振り分けます。一度接点のあったリードは関心の傾向がすでに分かっているぶん、新規獲得よりも効率よくアプローチできるのが特長です。たとえば「予算が来期に見送られた」リードには、相手の予算策定期から逆算して2〜3カ月前に費用対効果の資料を届ける、といった時間差の設計もできます。

運用は担当者の記憶に頼らず、ステータスと再アプローチの条件（例：却下から90日後にスコアを再評価する）をツールやシートのルールとして固定します。獲得済みのリードを使い切る循環まで作って、はじめてリードの母集団が資産と呼べるものになります。

基準は劣化する——四半期レビューで回し続ける

定義とSLAは、作った瞬間から古び始めます。商材や価格が変われば理想の顧客像が変わり、市場環境が変われば行動の意味が変わり、営業体制が変われば対応できる件数が変わるからです。決めて終わりの基準は、おおむね1年で実態と乖離します。

見直しの型としては、四半期ごとに、段階別の転換率（MQL→SAL→SQL→商談→受注）、却下理由の分布、SLAの達成状況（供給件数・対応期限）の3点セットを両部門で確認します。変更するのは一度に1〜2箇所まで。基準点も属性条件も一気に変えると、次の四半期にどの変更が効いたのか分からなくなります。レビューは30〜60分の定例で十分で、資料づくりに凝る必要はありません。転換率と却下理由の一覧を画面共有し、数字から議論を始める形にすれば、準備の負担なく続けられます。

定義書にはバージョン番号と変更理由を残しておきます。改定の履歴が残っていれば、担当者が交代しても「なぜこの基準なのか」という文脈ごと引き継げるため、運用の属人化を防げます。

AIで定義文書とスコア設計のたたき台を作る

定義合意が進まない現場に共通するのは、「最初の紙がない」ことです。何もない状態で会議を開くと、各自の経験談で議論が発散します。ここで生成AIを使い、自社の商材・ターゲット・過去の受注傾向を渡して定義書の草案を作らせ、会議を「ゼロから考える場」から「たたき台を直す場」に変えます。

あなたはBtoBマーケティングと営業の連携を支援するコンサルタントです。
以下の情報から、リード管理の定義書のたたき台を作ってください。
・商材：（例：製造業向け生産管理システム、年間契約200万円〜）
・ターゲット：（例：従業員100名以上の製造業、生産技術部門と情報システム部門）
・過去の受注傾向：（例：展示会とセミナー経由が多い、初回接点から受注まで平均6カ月）
出力してほしいもの：
1. MQL判定条件の案（属性・行動スコアの項目と点数の仮案、基準点）
2. 営業がSQLと判断するためのヒアリング項目案（BANTベース）
3. 却下理由の選択肢案（5つ前後）
4. 月次・四半期で確認すべき指標の一覧
数値はすべて仮案と明記し、社内で検証すべき論点も添えてください。

出てきた草案はそのまま採用せず、過去の受注データと突き合わせ、営業が実際に使う言葉に直します。AIが担うのは平均的な骨格づくりまでで、自社の数字と営業の実感を織り込む工程は人にしかできません。それでも、白紙から始める場合と比べて、合意までの時間は大きく縮められます。定義書のドラフトだけでなく、営業向けの説明資料や却下理由の入力ガイドといった周辺文書も、同じ材料から短時間でそろえられます。

AI予測スコアリングの位置づけと使える条件

スコアリング自体をAIに任せる選択肢もあります。主要なMAツールやCRMには、過去の成約・失注データから受注確度を推定する予測スコアリング機能が搭載されており、人手で点数を設計する代わりに、データからパターンを学習させる方式です。担当者の思い込みが入りにくいのが利点です。

ただし前提条件があります。学習の元になる成約・失注の実績データが十分にないと、精度の出ないモデルになります。導入を検討する際は、自社に蓄積された案件データの量と質を先に確認してください。実績がまだ少ない段階では、ルールベースのスコアリングを回してデータを貯めるほうが先です。必要なデータ量の目安は提供各社の解説でも幅がありますが、成約・失注それぞれ100件前後の実績が一つのラインとして挙げられることがあります。

また、予測スコアは「なぜこのリードが高得点なのか」が見えにくくなりがちです。営業が根拠を納得できないスコアは、結局使われません。ルールベースと併用し、スコアの根拠を説明できる状態を保つことが、部門間の信頼を守る条件になります。

運用が形骸化する典型パターン

定義とSLAを整えても、運用が続かない会社には共通のパターンがあります。始める前に、失敗の型を確認しておきましょう。

• 定義を作って共有しただけ：対応期限・却下理由の記録・見直しの場という運用ルールを決めていない
• マーケ単独で基準を決め、営業側に「自分たちの約束」という当事者意識がない
• 却下されたリードの行き先がなく、そのまま放置されて母集団が痩せていく
• 一度決めた基準を何年も見直さず、市場や商材の変化と静かにずれていく

共通するのは、合意した「あと」の仕組みがないことです。定義書は完成がゴールではなく、運用の開始点にすぎません。レビューの場と担当者をあらかじめカレンダーに固定してしまうのが、形骸化へのもっとも簡単な対策です。

形骸化の兆候は数字に出ます。却下理由の「その他」比率が増える、SALの判断期限超過が常態化する、レビューが2回連続で流れる——このどれかが起きたら、仕組みが実態と合わなくなったサインとして扱い、次のレビューで運用ルール自体を議題にします。

少人数の会社でも回せる軽量運用

ここまでの仕組みは、MAツールがなくても始められます。スプレッドシートにリードの一覧を作り、MQL条件に該当するか、引き渡した日付、営業の判断と却下理由の列を足すだけで、骨格は成立します。月に1回、30分の両部門ミーティングで転換率と却下理由を眺めるところから始めれば十分です。仕組みの本体はツールではなく、定義と記録と振り返りの習慣です。

順番として避けたいのは、運用が固まる前にツールを導入することです。手動で回らない仕組みは、自動化しても回りません。手動で3カ月回して、残った型だけを自動化すると、ツール選定の要件も自然に明確になります。

• 最初から精緻なスコアリングを目指さない。項目5つ程度の仮説から始める
• リード件数が月に数十件程度までなら、スコア計算より全件レビューのほうが早くて正確なことも多い
• 定義書は1枚に収める。長い文書は読まれず、読まれない文書は必ず形骸化する
• ツールの導入は、手動運用で「何を自動化したいか」が言えるようになってから検討する

よくある質問

MQLとSQLはどちらを重視すべきですか？

どちらか一方ではなく、段階別の転換率とセットで見ることが重要です。MQL件数だけを追うと薄いリードが増え、SQL件数だけを追うと母集団づくりが軽視されます。MQL→SQL→商談→受注の流れ全体を1つのダッシュボードで両部門が共有すると、部門ごとの部分最適を防げます。件数の目標も、MQLは営業が対応しきれる範囲とセットで決めると、量と質の綱引きが起きにくくなります。

スコアの点数は何を根拠に決めればよいですか？

過去の受注案件の共通点が最良の根拠です。受注した顧客がたどった行動（資料請求・セミナー参加・料金ページ閲覧など）に高い点を置き、受注と関係の薄い行動の点は下げます。データが少ないうちは仮置きで構いません。点数の正しさよりも、四半期ごとに見直す運用が続くことのほうが、長期的な精度に効きます。

営業が定義づくりに協力してくれないときは？

営業側のメリットから提案するのが近道です。定義とSLAは、追わなくてよいリードを明確にし、却下する権利を公式に認める仕組みでもあります。「質の低いリードへの義理のフォローがなくなり、確度の高いリードに時間を集中できる」という負担減の文脈で持ちかけると、協力を得やすくなります。一度協力が得られたら、リード対応に使う時間が減ったという実感を数字で返すことで、協力が習慣に変わります。

リードが月に数件しかなくても分ける意味はありますか？

件数が少ないうちは、全件を営業が見る運用でも回ります。ただし、却下理由の記録だけは最初から残す価値があります。リードが増えて基準が必要になったとき、蓄積された却下理由がそのまま定義づくりの元データになるからです。記録の習慣は、規模が小さいうちのほうが作りやすいものです。

MQLは増えているのに受注が増えません。どこを見るべきですか？

段階別の転換率を順に見て、最初に大きく落ちる場所を特定します。MQL→SALで落ちるなら定義のずれ、SAL→SQLで落ちるなら対応スピードかヒアリングの質、SQL→受注で落ちるなら商談の進め方や競合状況が疑わしい、というように、落ちる場所ごとに打ち手が変わります。全体の受注数だけを眺めていても、原因は特定できません。

まとめ

MQLとSQLの違いは、リードの優劣ではなく「マーケティングが認定したか、営業が認定したか」の違いです。もめる原因は定義の不在にあり、解決策は、過去データに基づく定義の合意、件数と対応期限を数値で約束するSLA、却下理由の記録とリードのリサイクル、そして四半期ごとの見直しという運用の輪にあります。AIは定義文書やスコア設計のたたき台づくりで合意までの時間を縮めてくれますが、最後に決めるのは両部門の人です。リードの質は、定義した瞬間ではなく、回し続ける運用の中で作られるもの。まずは営業との30分の定例を設定し、先月のリードがその後どうなったかを一緒に眺めるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。