BtoBビジネスにおいて、リードの「量」ではなく「質」が問われる時代になりました。マーケティング部門が大量のリードを獲得しても、営業部門から「商談につながらない」と不満が出る、こうした課題の根本にあるのが、SQL(Sales Qualified Lead)の定義と運用です。
SQLを正しく理解し、MQLとの違いや判断基準を明確にすることで、営業とマーケティングの連携が強化され、商談化率・受注率の向上が期待できます。本記事では、SQLの基本的な定義から、判断基準の設計方法、MQLからの移行プロセス、営業との連携方法まで、JAPAN AIが網羅的に解説します。
\ ChatGPTもClaudeもGeminiも使える! /
SQLとは?
SQL(Sales Qualified Lead)とは、営業部門が「商談化の見込みがある」と判断した見込み顧客のことです。日本語では「営業適格リード」と訳されることもあります。
BtoBマーケティング・営業プロセスにおいて、SQLはリードが最終的に商談・受注へと進むかどうかを判断する重要な分岐点に位置づけられます。マーケティング活動で獲得・育成されたリード(MQL)の中から、営業が直接アプローチする価値があると判断されたものがSQLです。
SQLは単なるリードの分類ラベルではありません。営業部門が「このリードに対して営業リソースを投下する価値がある」と判断した見込み顧客を指します。そのため、SQLの定義が曖昧なままだと、営業は優先度の低いリードに時間を費やし、本来注力すべき商談機会を逃してしまいます。
SQLが重視される理由
SQLが重視される背景には、リードの「量」から「質」への転換が求められていることがあります。
デジタルマーケティングの普及により、企業が獲得できるリードの数は増加しました。しかし、すべてのリードが商談化するわけではありません。営業リソースには限りがあるため、受注確度の高いリードを見極め、優先的にアプローチすることが不可欠です。
SQLを明確に定義・運用することで、以下の効果が期待できます。
- 営業リソースの最適配分:受注確度の高いリードに営業活動を集中できる
- 商談化率の向上:質の高いリードにアプローチすることで、商談から受注への転換率が上がる
- 営業活動の効率化:無駄な訪問・提案が減り、営業一人あたりの生産性が向上する
MQLとSQLの違い
SQLを正しく理解するためには、MQL(Marketing Qualified Lead)との違いを明確にすることが重要です。両者はリードの成熟度を示す指標ですが、判断する主体と基準が異なります。
| 項目 | MQL | SQL |
|---|---|---|
| 正式名称 | Marketing Qualified Lead | Sales Qualified Lead |
| 判断主体 | マーケティング部門 | 営業部門 |
| 判断基準 | Webサイトの行動履歴、資料DL、セミナー参加など | BANT条件、商談化の見込み、購買意思の確認 |
| リードの段階 | 購買意欲が一定水準に達した見込み顧客 | 営業が商談化可能と判断した見込み顧客 |
| 次のアクション | 営業部門への引き渡し | 商談・提案の実施 |
MQLとSQLは対立する概念ではなく、リードが成熟していく過程の異なるステージを表しています。マーケティングがMQLを創出し、営業がSQLとして受け取るという一連の流れを組織全体で設計することが、BtoBマーケティングの成果を最大化するうえで欠かせません。
MQLの定義
MQL(Marketing Qualified Lead)とは、マーケティング活動を通じて獲得・育成され、購買意欲が一定水準に達したリードのことです。具体的には、以下のような行動をとったリードがMQLとして判定されるケースが一般的です。
- ホワイトペーパーや資料のダウンロード
- ウェビナーやセミナーへの参加
- 製品ページの複数回閲覧
- 問い合わせフォームからの情報入力
- メールマガジンへの継続的なエンゲージメント
MQLはあくまでマーケティング活動の中で「興味・関心が高い」と判断されたリードであり、営業が商談化可能と判断したSQLとは異なります。MQLの段階では、まだ予算や導入時期が明確でないケースも多く、営業に引き渡す前段階の位置づけです。
TQL・SGL・SALとの違い
SQLやMQL以外にも、リードの分類には複数の用語が存在します。混同しやすいため、それぞれの定義を整理しておきましょう。
- TQL(Teleprospecting Qualified Lead):テレマーケティングやインサイドセールスによる電話接触を通じて、商談化の可能性があると判断されたリード
- SGL(Sales Generated Lead):営業担当者自身が独自に開拓・獲得したリード。マーケティング経由ではなく、営業活動から直接生まれたもの
- SAL(Sales Accepted Lead):マーケティングから引き渡されたMQLを、営業部門が「受け入れた」と確認したリード。MQL → SAL → SQLという流れでSQLの前段階として扱われることが多いが、SiriusDecisions社のデマンドウォーターフォールモデルでは、SALはSGL(Sales Generated Lead)と並んでSQLを構成する要素として定義されている。企業によって位置づけが異なるため、自社のプロセスに合わせて定義することが重要
また、SQLの次段階として、Opportunity(商談化が確定した案件)やSQO(Sales Qualified Opportunity)として管理する企業もあります。さらに、営業支援会社のセレブリックスが提唱するSOL(Sales Opportunity Lead)という概念も注目されています。
SOLは、顧客の「購買タイミング(いつ検討するか)」と「購買理由(なぜ検討するか)」が明確になったリードを指し、SQLよりさらに受注に近い状態のリードとして位置づけられます。ただし、SOLはセレブリックス社発の用語であり、業界標準として広く定着しているわけではありません。用語や定義は企業ごとに異なるため、自社のリード管理プロセスにおいてどの分類を採用するかは、営業組織の規模やプロセスの複雑さに応じて検討してください。
なぜSQLが重要なのか
SQLを明確に定義し運用することは、営業組織の成果に直結します。SQLが重要である2つの理由を解説します。
営業活動の効率化と生産性向上
SQLを活用する最大のメリットは、営業リソースの最適配分です。
SQLが定義されていない組織では、営業担当者がすべてのリードに均等に対応しようとするため、受注確度の低いリードにも多くの時間を費やしてしまいます。結果として、本来注力すべき有望な商談に十分な時間を割けず、営業全体の生産性が低下します。
SQLを明確にすることで、営業担当者は「今アプローチすべきリード」を迷わず判断でき、無駄打ちが減少します。限られた営業リソースを受注確度の高い商談に集中させることで、一人あたりの売上貢献度が向上します。
マーケティングと営業の連携強化
SQLの定義は、マーケティングと営業の「共通言語」としても機能します。
多くのBtoB企業で、マーケティング部門と営業部門の間には「リードの質」に関する認識のズレが存在します。マーケティングは「十分に育成したリードを渡している」と考える一方、営業は「商談につながらないリードばかりだ」と感じる、こうした部門間の衝突は、SQLの定義が共有されていないことが原因であるケースが少なくありません。
SQLの判断基準を両部門で合意し、明文化することで、リードの引き渡しがスムーズになり、部門間の信頼関係が構築されます。
SQL判定の判断基準
SQLかどうかを判定するためには、明確な基準が必要です。属人的な判断に頼ると、担当者によってSQLの質にばらつきが生じ、営業成果が安定しません。SQL判定の代表的なフレームワークと自社基準の設計方法を解説します。
BANT条件を活用したSQL判定
BANT条件は、SQLの判定で最も広く使われているフレームワークです。以下の4つの要素でリードの商談化可能性を評価します。
| 要素 | 意味 | 確認ポイント |
|---|---|---|
| Budget(予算) | 導入に必要な予算が確保されているか | 予算規模、予算取得の時期、決裁プロセス |
| Authority(決裁権) | 意思決定者または影響力のある人物か | 役職、決裁フロー、キーパーソンの有無 |
| Need(ニーズ) | 自社の商品・サービスで解決できる課題があるか | 現状の課題、導入目的、期待する効果 |
| Timeline(導入時期) | 具体的な導入スケジュールがあるか | 検討開始時期、導入希望時期、競合検討状況 |
4つの条件すべてを満たすリードが理想的なSQLですが、実務では初回接触の段階ですべてを確認することは難しい場合もあります。まずはNeed(ニーズ)とTimeline(導入時期)を優先的に確認し、段階的にBudgetとAuthorityを把握していくアプローチが現実的です。
自社独自の判定基準
BANTは汎用的なフレームワークですが、自社の商材やターゲット、営業プロセスに合わせた独自の判定基準を設計することも重要です。独自基準を設計する際のポイントは以下の通りです。
- 属性スコア:企業規模、業種、役職、地域など、ターゲット顧客の属性情報に基づくスコアリング
- 行動スコア:Webサイトの閲覧ページ数、資料ダウンロード回数、セミナー参加回数など、リードの行動履歴に基づくスコアリング
- エンゲージメントスコア:メール開封率、クリック率、返信率など、コミュニケーションへの反応度合い
これらのスコアを組み合わせて閾値を設定し、一定のスコアに達したリードをMQLとして営業に引き渡すルールを設計します。営業側がMQLを受け取った後、BANT条件や直接のヒアリングを通じてSQL化の判断を行う流れが一般的です。CHAMP(Challenges・Authority・Money・Prioritization)など、BANT以外のフレームワークを活用することも有効です。
なお、判定基準は一度設計して終わりではなく、商談化率や受注率のデータを定期的に分析し、基準の精度を継続的に改善していくことが求められます。
MQLからSQLへの移行方法
MQLをSQLに育成・移行させるためには、体系的なプロセスが必要です。ここでは、リードナーチャリング、スコアリング、インサイドセールスの3つの観点から、MQLからSQLへの移行方法を解説します。
リードナーチャリング
リードナーチャリングとは、見込み顧客の購買意欲を段階的に高めていく施策です。MQLの段階では、まだ導入の具体的な検討に至っていないリードも多いため、継続的な情報提供を通じて関心を高め、SQLへの移行を促します。
代表的なナーチャリング施策には以下があります。
- メールマーケティング:リードの関心領域に合わせたコンテンツを定期配信し、エンゲージメントを維持する
- コンテンツマーケティング:導入事例、ホワイトペーパー、比較資料など、検討段階に応じたコンテンツを提供する
- セミナー・ウェビナー:製品デモや業界動向の解説を通じて、リードの理解度と関心度を高める
- 定期的なフォローアップ:電話やメールでの定期的な接触により、リードの状況変化をキャッチする
ナーチャリング施策を効果的に実行するためには、MA(マーケティングオートメーション)ツールの活用が有効です。リードの行動履歴に基づいた自動配信やシナリオ設計により、効率的かつパーソナライズされたナーチャリングが実現できます。
リードスコアリングの活用
リードスコアリングは、リードの行動や属性に点数を付与し、SQL判定の客観的な基準とする手法です。スコアリング設計のポイントは以下の通りです。
- 行動スコア:Webサイト訪問(+5点)、資料ダウンロード(+10点)、セミナー参加(+15点)、問い合わせ(+20点)など、行動の重要度に応じて点数を設定
- 属性スコア:ターゲット業種(+10点)、決裁者レベルの役職(+15点)、従業員数1,000名以上(+10点)など、理想的な顧客像に近いほど高得点
- エンゲージメントスコア:メール開封率、クリック率、返信率などのコミュニケーション反応度
これらのスコアの合計が一定の閾値(例:50点)に達したリードをMQLとして営業に引き渡し、営業側のヒアリングやBANT確認を経てSQLへ移行させるルールを設計します。閾値は、過去の商談化データを分析して最適な水準を見極めることが重要です。
インサイドセールスの戦略的活用
MQLからSQLへの移行において、インサイドセールスは極めて重要な役割を果たします。
インサイドセールスは、マーケティングが創出したMQLに対して電話やメールで直接コンタクトし、リードの課題やニーズ、導入時期、予算感などをヒアリングします。このヒアリングを通じて、SQL基準を満たすかどうかを見極め、基準を満たしたリードをフィールドセールスに引き渡します。
インサイドセールスがMQL→SQL移行で担う主な役割は以下の通りです。
- リードの選別(クオリフィケーション):BANT条件や自社基準に基づき、リードの商談化可能性を判断する
- 情報の補完:マーケティングデータだけでは把握できない、リードの具体的な課題や検討状況を直接ヒアリングする
- タイミングの見極め:「今すぐ商談すべきリード」と「もう少しナーチャリングが必要なリード」を仕分ける
インサイドセールスの活動を効率化するためには、SFA/CRMにリードの行動履歴やBANT情報が正確に記録されていることが前提です。しかし、営業担当者による手入力では情報の抜け漏れや入力遅延が発生しがちです。
こうした課題に対して、JAPAN AI SALESのようなAIエージェントを活用すれば、商談内容の自動議事録化やSFA/CRMへの自動入力により、インサイドセールスが必要な情報にすぐアクセスできる環境を整備できます。検知した最新のBANT情報もSFA/CRMに自動更新されるため、リードの最新状況を常に把握したうえで、適切なタイミングでのアプローチが可能です。

JAPAN AI SALES
JAPAN AI SALESは、「商談は増えているのに、SFA/CRMが更新されない」という事態を防止する、営業部門向けのAIエージェントです。高精度AI議事録・メール連携・BANT情報の自動更新の3つの特徴で、数クリックの承認だけで営業活動が記録されます。
SQL後の営業アクションと商談最適化
SQLと判定されたリードに対して、営業がどのようにアプローチするかは、受注率を左右する重要なポイントです。SQLの判定がゴールではなく、その後の営業アクションの質が成果を決定します。
SQLに対する効果的なアプローチ方法
SQL化したリードに対しては、画一的な営業トークではなく、リードごとにパーソナライズされたアプローチが求められます。効果的なアプローチのポイントは以下の通りです。
- リードの課題に基づいた提案:MQLからSQLへの移行過程で蓄積された情報(行動履歴、ヒアリング内容、BANT情報)を活用し、リード固有の課題に対する解決策を提案する
- 業種・規模に合わせたカスタマイズ:同業他社の導入事例や、リードの企業規模に適した導入プランを提示する
- 商談初期で確認すべき3つのポイント:リードが認識している課題の優先順位、意思決定プロセスと関与者、競合製品の検討状況
これらの情報を商談前に整理しておくことで、初回商談の質が格段に向上します。
SQLからクロージングまでの営業プロセス最適化
SQLから受注までの営業プロセスを最適化するためには、属人化を防ぎ、組織全体で再現可能な仕組みを構築することが重要です。プロセス最適化のポイントは以下の通りです。
- 営業パスの設計:SQL→初回商談→課題深掘り→提案→見積もり→クロージングという標準的なパスを定義し、各ステージでの必要アクションを明確化する
- ステージ管理の可視化:SFA/CRMを活用して、各案件が今どのステージにあるかをリアルタイムで把握できるようにする
- ナレッジの共有:成功した商談のパターンや、失注した案件の原因分析を組織内で共有し、営業力の底上げを図る
営業プロセスの可視化と標準化において課題となるのが、SFA/CRMへの入力負荷です。商談後の議事録作成や活動履歴の記録に時間を取られ、本来の営業活動に集中できないという声は少なくありません。
SQL運用の精度を高めるなら「JAPAN AI SALES」
SQLの運用を成功させるには、商談情報の正確な記録と、営業プロセス全体の可視化が欠かせません。JAPAN AI SALESは、SFA/CRM自動入力機能とAI議事録機能により、商談後の記録作業を大幅に削減します。商談内容が自動的にSFA/CRMに反映されるため、営業担当者は入力作業に時間を費やすことなく、次の商談準備や顧客対応に集中できます。また、メール連携機能により、顧客とのやりとりも自動的に活動履歴として記録されるため、営業活動のブラックボックス化を防ぎ、マネージャーによる適切なコーチングや案件管理が可能です。

営業パーソンのお手元に、優秀な『AI社員』を。
商談のあとの”作業”、ゼロへ。
SFA/CRM入力を自動化する
AIエージェント
✓
高い精度のAI議事録が、商談を自動で記録・要約
✓
商談もメールも、AI社員がSFA/CRMへ自動入力
✓
商談前の企業調査から提案資料作成まで、AI社員が支援

SQLにかかわるよくある課題と解決策
SQLの運用において、多くの企業が直面する課題があります。ここでは代表的な3つの課題と、それぞれの解決策を解説します。
部門間の衝突・すれ違い
最も頻繁に発生する課題が、マーケティング部門と営業部門の間でリード評価がズレることです。
マーケティングは「スコアリングで基準を満たしたリードを渡している」と考える一方、営業は「実際に話してみると商談にならないリードが多い」と感じる、この衝突の根本原因は、MQLとSQLの定義がチーム間で共有されていないことにあります。
解決策として、以下の取り組みが有効です。
- MQLとSQLの判定基準を両部門で合意し、文書化する
- 定期的な合同ミーティングで、引き渡したリードの商談化率をレビューする
- 「差し戻しルール」を設ける(SQLとして受け取ったが基準を満たさないリードをMQLに戻す仕組み)
MQLからSQLへの移行に時間がかかる
MQLの育成に時間がかかり、SQLへの移行が遅延するという課題もよく見られます。ナーチャリング施策が効果を発揮するまでに数か月かかるケースも多く、営業部門から「リードが回ってこない」という不満が生じます。
解決策として、以下の取り組みが有効です。
- ナーチャリングシナリオを検討段階ごとに細分化し、各段階に最適なコンテンツを配信する
- スコアリングの閾値を定期的に見直し、過度に高い基準がボトルネックになっていないか確認する
- インサイドセールスによる能動的なアプローチで、ナーチャリングだけに頼らないSQL創出を並行して行う
SQLを優先してしまう問題
営業部門がSQLを優先するあまり、MQLへのフォローを後回しにしてしまう問題です。短期的には成果が出るように見えますが、中長期的にはパイプラインの枯渇を招きます。
解決策として、以下の取り組みが有効です。
- SQLだけでなく、MQLの育成状況もKPIとして設定し、営業とマーケティングの双方で管理する
- MQLからSQLへの移行率を定期的にモニタリングし、パイプラインの健全性を評価する
- インサイドセールスチームを設置し、MQLのフォローとSQL化を専任で担当させる
営業とマーケティングの連携強化
SQLを効果的に運用するためには、営業とマーケティングの連携を仕組みとして構築することが不可欠です。
CRM/SFAを活用した情報共有
営業とマーケティングの連携において、CRM/SFAは情報共有の基盤です。
CRM/SFAを活用した連携のポイントは以下の通りです。
- リードの行動履歴の一元管理:マーケティング活動で取得したリードの行動データ(Webサイト閲覧、資料ダウンロード、セミナー参加など)をCRM/SFAに集約し、営業がアプローチ前に確認できるようにする
- BANT情報の可視化:インサイドセールスや営業がヒアリングしたBANT情報をCRM/SFAに記録し、チーム全体で共有する
- ステージ管理の統一:リード→MQL→SQL→商談→受注という各ステージの定義と移行条件をCRM/SFA上で統一的に管理する
ただし、CRM/SFAの運用で最大の課題となるのが「入力の定着」です。営業担当者が多忙な中で正確な情報を入力し続けることは容易ではなく、データの鮮度や正確性が低下するリスクがあります。
JAPAN AI SALESは、この課題を根本から解決します。商談内容の自動議事録化、メール連携による活動履歴の自動記録、検知した最新のBANT情報のSFA/CRMへの自動更新により、営業担当者が手入力する負担を大幅に削減できます。入力作業の自動化により、CRM/SFAのデータが常に最新の状態に保たれ、マーケティングと営業の情報共有がスムーズになります。
定期的な振り返りと改善
SQLの運用は、一度設計して終わりではありません。営業とマーケティングが定期的に振り返り、改善を続けるPDCAサイクルの構築が重要です。
振り返りで確認すべきポイントは以下の通りです。
- SQL判定基準の妥当性:SQLとして引き渡したリードの商談化率・受注率を分析し、判定基準が適切かどうかを検証する
- MQL→SQL移行率の推移:移行率が低下している場合、ナーチャリング施策やスコアリング基準に問題がないか確認する
- 差し戻し率の分析:営業からマーケティングに差し戻されたリードの傾向を分析し、MQLの判定基準を改善する
- 受注までのリードタイムの変化:SQL判定から受注までの期間を追跡し、プロセスのボトルネックを特定する
これらの振り返りを月次または四半期ごとに実施し、両部門で改善アクションを合意することで、SQLの運用精度が継続的に向上します。
SQLに関してよくある質問
SQLの判定基準は業界ごとに異なりますか?
SQLの判定基準は、業界・商材・営業プロセスによって異なります。たとえば、SaaS企業ではトライアル申込みや特定機能ページの閲覧がSQL判定の重要な指標になる一方、製造業では予算確保のタイミングや設備投資計画との連動が重視されます。BANT条件をベースにしつつ、自社の過去の商談化パターンを分析して独自の基準を設計しましょう。また、市場環境や自社の営業戦略の変化に合わせて、判定基準を定期的に見直すことも忘れないようにしてください。
SQLの数を増やすにはどうすればよいですか?
SQLの数を増やすためには、3つのアプローチが効果的です。1つ目は、MQLの質を高めるナーチャリング施策の強化です。リードの検討段階に合わせたコンテンツ配信やセミナー開催により、購買意欲を段階的に高めます。2つ目は、インサイドセールスによるヒアリング精度の向上です。リードの課題やニーズを正確に把握し、適切なタイミングでSQLに移行させます。3つ目は、営業とマーケティングの定義合意・SLA整備です。両部門でSQL基準を共有し、引き渡しルールを明文化することで、移行の停滞を防ぎます。量を追い求めるのではなく、質を重視した創出が持続的な成果につながります。
MAツールがあればSQLの管理は自動化できますか?
MAツールはスコアリングやナーチャリングの自動化に有効ですが、SQLの管理を完全に自動化できるわけではありません。MAツールが得意なのは、リードの行動データに基づくスコアリングの自動計算や、シナリオに沿ったメール配信の自動化です。一方、SQLの判定基準の設計や、営業とマーケティング間の合意形成、判定基準の定期的な見直しは、ツールだけでは解決できません。MAツールは「設計された運用ルールを実行・管理する手段」であり、運用設計そのものが前提です。ツール導入と合わせて、SQL判定の運用フローを整備しましょう。
SQLを正しく定義して営業成果を最大化しよう
本記事では、SQL(Sales Qualified Lead)の定義から、MQLとの違い、判断基準の設計方法、MQLからSQLへの移行プロセス、営業との連携方法まで、体系的に解説しました。
ポイントを改めて整理すると、以下の通りです。
- SQLとは、営業部門が「商談化の見込みがある」と判断した見込み顧客のこと
- MQLとの違いは、判断主体(マーケティング vs 営業)と判断基準(行動データ vs 商談化可能性)にある
- SQL判定の判断基準は、BANT条件をベースに自社独自の基準を設計し、定期的に見直すことが重要
- MQLからSQLへの移行には、ナーチャリング・スコアリング・インサイドセールスの3つの施策を組み合わせる
- 営業とマーケティングの連携は、CRM/SFAを基盤とした情報共有と、定期的な振り返りで強化する
SQLの運用を成功させるためには、定義の明確化、部門間の合意形成、そしてデータに基づく継続的な改善が欠かせません。
まずは自社のSQL定義を見直し、営業とマーケティングの間でリードの引き渡し基準を合意することから始めてみてください。CRM/SFAへの情報入力が課題になっている場合は、JAPAN AI SALESのようなAIエージェントの活用も検討してみましょう。SFA/CRMへの自動入力や商談の自動議事録化により、営業担当者の入力負荷を削減しながら、正確なデータに基づくSQL運用が実現できます。
JAPAN AIとは
JAPAN AIは、法人向けの国産生成AIプラットフォームです。AIチャット・議事録・エージェントなどのすぐ使える標準機能から、自社専用AIアプリのノーコード開発まで、全部門のAI活用をひとつの基盤で支えます。ジーニーグループのこれまでのDX・AX支援実績をもとに、ツールの提供にとどまらず、活用テーマの設計から現場での定着・成果創出まで専門チームが伴走します。
JAPAN AIの機能・活用事例・料金体系がわかるサービス紹介資料を無料でお送りします。
▼資料イメージ
- JAPAN AIでできること(AIチャット/議事録/エージェント/アプリ開発 ほか)
- ChatGPTなど汎用AIツールとの違い
- 業種・部門別の活用シーンと導入事例
- 導入から定着までの支援体制
- 料金体系とセキュリティ・ガバナンス対応
▼簡単1分!JAPAN AIの資料請求


