SQL（Sales Qualified Lead）とは？マーケティングと営業の架け橋となるリード評価を徹底解説

「リードはあるが、営業が手をつけてくれない」
「営業にパスしても商談にならない」
「本当に買う気のある顧客をどう見極めるかが難しい」

BtoBマーケティングにおいて、リードの“質”を見極めることはかつてないほど重要になっています。そこで、リード評価プロセスの中核を担うのが「SQL（Sales Qualified Lead）」という概念です。

SQLとは、営業部門が「商談の見込みがある」と判断した見込み顧客を指します。つまり、マーケティングから渡されたMQL（Marketing Qualified Lead）の中から、インサイドセールスや営業が“実際に商談化できる”と確信したリードのことです。

このコラムでは、SQLの定義から、MQLとの違い、評価基準、判定の手順、営業連携のポイント、成果を上げた実例、よくある課題とその解決策までを、体系的に解説していきます。

【課題別に整理したアプローチ方法の資料を公開中！】
B2Bマーケティングのプロセスガイドを詳しく見る＞

• SQLとは何か？その定義と役割
• MQLとの違いとSQLの位置づけ
• SQL判定の判断基準（BANT／CHAMP／自社指標）
• SQLを生むプロセスとインサイドセールスの役割
• SQL後の営業アクションと商談最適化
• 成功事例：SQLを正しく定義して営業成果が変わった企業
• よくある失敗と“商談になるSQL”のつくり方
• まとめ：SQLは“営業が動ける情報”である

SQLとは何か？その定義と役割

SQL（Sales Qualified Lead）とは、「営業活動によって商談化が現実的と判断されたリード」のことを意味します。

一般的には以下のような状態を指します。

• インサイドセールスまたは営業による初回ヒアリングが完了している
• 導入に向けたニーズや課題感が確認されている
• 社内の意思決定プロセスや予算の有無について仮説が持てている
• 次回アクション（提案、訪問、デモなど）の日程が確定している

マーケティング活動で獲得・育成されたMQLをさらに精査し、“営業の時間を使うに足るかどうか”を判断する最終関門とも言えるのがSQLです。

MQLとの違いとSQLの位置づけ

SQLという言葉が登場する文脈では、必ずといっていいほど比較されるのがMQL（Marketing Qualified Lead）です。両者はリードの質や状態を示すフェーズの違いであり、役割と評価基準が明確に分かれています。

MQL：マーケティング部門が評価した“育成済みリード”

• 主に行動履歴（資料DL、セミナー参加、ページ閲覧など）や属性（企業規模、役職など）に基づいて判定
• スコアリングやセグメント設計により、MAツール上で自動化されていることが多い
• 顧客の検討フェーズが“初期～中期”であるケースが多い

SQL：営業またはインサイドセールスが評価した“商談可能リード”

• ヒアリングを通じて、課題、予算感、導入検討状況などが明らかになった状態
• 実際に提案のテーブルに乗せることを見据えた“アクション可能な相手”
• 顧客の検討フェーズが“中期～後期”に進んでいる状態

比較項目	MQL	SQL
評価主体	マーケティング	営業／インサイドセールス
判断材料	行動・属性・スコア	ヒアリング・会話内容・意向確認
状態	興味・情報収集中	導入検討・社内相談中
商談化の見込み	低〜中程度	中〜高程度
次のアクション	営業と接点を持つ	提案・見積もり・導入相談など

SQLは“提案活動が開始できる状態”であり、単なる反応の良いリードではなく、営業リソースを割くべき対象であるという判断のもとに設定されます。

SQL判定の判断基準（BANT／CHAMP／自社指標）

SQLを定義する際に用いられる代表的なフレームワークには、以下のようなものがあります。

BANT（バント）

Salesforceをはじめ、古くから営業プロセスで使われてきた代表的な商談評価フレーム。

• B：Budget（予算）
• A：Authority（決裁権）
• N：Need（課題）
• T：Timeframe（導入時期）

すべてが揃っていれば理想的ですが、現代の複雑な意思決定では完全に網羅されるケースが少ないため、柔軟に運用する必要があります。

CHAMP（チャンプ）

より顧客視点・関係性重視で設計されたフレームワーク。

• CH：Challenges（課題）
• A：Authority（決裁権）
• M：Money（費用感）
• P：Prioritization（導入優先度）

BANTよりも「顧客の事情を読み解く」ことに重点を置いており、インサイドセールスとの親和性が高いとされます。

自社独自の判定基準

現場では、上記の枠組みを参考にしつつ、以下のような“自社商材に特化したSQL基準”を設けるケースも多くあります。

• 製造業で従業員100名以上、課題は属人化、初回面談で導入時期の明言あり
• 過去に失注したが、再DLと再訪問あり＋課題感が継続している
• ウェビナー参加後、価格やサポート体制の質問があり、競合比較フェーズに突入している

SQLは「MQLと営業のあいだ」ではなく、「商談のはじまりの定義」です。だからこそ、全社で基準を統一し、納得性のある運用が必要です。

SQLを生むプロセスとインサイドセールスの役割

SQLは“偶然できあがる”ものではありません。MQLの状態から、顧客とのコミュニケーションを通じて段階的に“商談化に足るかどうか”を見極め、必要な情報を整理した上で営業に引き渡す――このプロセスの要となるのが、インサイドセールスです。

MQL→SQLの移行は「ヒアリングと選別」がカギ

多くの企業では、MQLの定義（例：スコア80点以上）に達したリードをインサイドセールスが一次対応し、以下のような情報をヒアリングしてSQLへの昇格可否を判断します。

• 現在抱えている業務上の課題は？
• 何が導入のきっかけになったか？
• 社内でどのように検討を進めるか？
• 検討時期と予算感は？
• 他社比較をしているか？

このやりとりによって「興味・関心」から「検討・選定」への移行度合いを確認し、SQLか否かを判断します。

インサイドセールスのミッションは“営業を加速させること”

SQL判定を通じて、営業は“すでに課題意識と関心がある相手”に集中できます。つまりインサイドセールスの存在意義は「営業の商談化率を最大化するためのフィルター」であり、「今アプローチすべき相手を整える前処理部隊」でもあります。
適切なSQLの判定と引き継ぎが行われていれば、営業は「次に話すべき内容」や「検討フェーズごとの打ち手」が明確になり、商談をスムーズに進めやすくなります。

SQL後の営業アクションと商談最適化

SQLとして営業にパスされたリードに対して、どのようなアクションを取るかも非常に重要です。最初の接触内容によって、その後の商談の“温度感”が大きく変わるからです。

商談初期で重視すべき3つのポイント

SQLから商談→受注までの“パス設計”

SQLが創出されただけでは、まだ成果とは言えません。商談の流れを「営業の型」として設計し、チーム全体で再現性を高めることで、営業成果が安定します。

• 商談初回で課題整理→事例提示→ニーズ整理
• 2回目で仮見積もりと社内調整の支援
• 3回目以降で稟議対策資料＋条件交渉

こうした「ステージとコンテンツの組み合わせ」によって、“SQLの質”がそのまま“受注率の高さ”に転換されるのです。

【課題別に整理したアプローチ方法の資料を公開中！】
B2Bマーケティングのプロセスガイドを詳しく見る＞

成功事例：SQLを正しく定義して営業成果が変わった企業

SQLの定義と運用が組織に与えるインパクトは大きく、単に「リードを渡すだけ」から「商談に変わるパスを設計する」活動へと進化させることができます。ここでは、実際にSQLを明確に定義・活用して営業成果を改善した企業の事例を紹介します。

事例①：SaaS企業A社 – 商談化率が18％→36％に

A社では、MQLから営業へのパスが曖昧で、営業が「とりあえず全件対応」していた。その結果、工数がかかる割に成果が出ず、営業とマーケの関係性も悪化していた。SQL定義を刷新し、インサイドセールスがBANTの簡易版を用いて予算・課題・導入時期の確認を行った上でのみ営業に引き渡す運用に変更。結果、SQLの数自体は減ったが、商談化率は18％から36％に向上。営業は“見込みのある相手”に集中できるようになり、月次受注数も改善。

事例②：IT企業B社 – スコアリング連動で営業スピードが1.5倍に

B社はMAでMQLスコアリングを導入していたが、SQLの判断は現場の経験に依存し属人化していた。スコアと行動条件（例：資料DL後に価格ページを閲覧＋ウェビナー参加）を基にSQL候補を自動抽出し、インサイドセールスが5分以内にコール。SLAで対応時間を24時間以内→6時間以内→5分以内と短縮していく中で、初回接触スピードが競合他社を上回り、商談獲得率が1.5倍に。営業からも「SQLは確かに温度が高い」と信頼が寄せられるように。

よくある失敗と“商談になるSQL”のつくり方

SQLを設定しても成果が出ない、営業が動かない――こうした課題の背景には、“定義・プロセス・期待値”のすれ違いがあることが多いです。以下はよくある失敗とその処方箋です。

MQLとSQLの違いがチームで共有されていない

SQLという名称だけが一人歩きし、インサイドセールスが「基準のない感覚」で営業にパスしてしまうと、営業は「SQLの質が低い」と受け取ってしまいます。

＜対策＞

• SLAや営業ガイドラインで「どの条件を満たしたらSQLか」を明文化
• 週次で“良いSQL／悪いSQL”の振り返りを行い、ナレッジを蓄積する

SQL後の営業アクションが属人化している

営業によって初回接触のやり方や提案フローが異なり、成果にばらつきが出る。

＜対策＞

• SQL→初回商談→受注までの“型”を共通設計（プレゼン資料やヒアリングテンプレート）
• CRMでの記録ルールを整備し、分析可能な体制を整える

“商談化ありき”の圧力で質が下がる

SQLのKPIを「件数」として追いすぎると、“まだ準備が整っていないリード”まで営業に回してしまい、逆に商談化率が下がる。

＜対策＞

• KPIは「SQL数」だけでなく「SQLからの商談化率」も併せて追う
• リード育成と営業アプローチの“中間”にあたるフェーズ（ISQL：Inside Sales Qualified Lead）などを設ける

まとめ：SQLは“営業が動ける情報”である

SQL（Sales Qualified Lead）とは、単なる「MQLの次のラベル」ではありません。それは、営業が動き出せるだけの“情報と確度がそろった状態”であり、組織としての「商談の起点」を示す定義です。

• ヒアリングによって「導入のリアリティ」が確認され
• 組織情報、検討時期、予算感がある程度見えており
• 次の提案アクションが具体的に決まっている

このようなSQLが多く創出される組織では、営業は「提案に集中」でき、マーケティングは「営業成果に貢献」できる仕組みが成立しています。SQLは、マーケティングと営業のあいだにある“見えない壁”を越えるための「共通の評価基準」であり、部門をまたいで成果をつくる“しくみ”です。

もし営業とマーケの間で「反応が悪い」「渡したのに追ってくれない」といった摩擦があるなら、今こそSQLの定義とプロセスを見直してみてください。それが、“営業が動き出せる組織”への第一歩になるはずです。

著者の紹介