BtoB営業・マーケティングで頻出する用語「BANT」「MQL」「SQL」「SOL」。なんとなく使っているけれど、正確な定義と違い、使い分けを説明できますか？これらは"営業案件の質"を見極め、マーケと営業が共通言語でファネルを運用するための基本用語です。定義が曖昧なまま運用すると、「マーケが渡したリードを営業が放置」「BANTを取りきろうとして商談を逃す」といった機会損失が必ず発生します。本記事では、4つの用語の定義・違い・使い分けから、リードのファネル（MQL→SQL→SOL→商談→受注）、スコアリング設計、BANT各条件の確認方法、BANT-CHAMPなど派生フレーム、マーケと営業の定義合意（SLA）、運用の落とし穴と回避策、FAQまで——営業企画・マーケ責任者・営業責任者・インサイドセールス担当者必読の決定版用語ガイドとして徹底解説します。
BANT＝商談の有効性を測る4条件（予算・決裁権・ニーズ・時期）。MQL＝マーケが「営業に渡せる」と認定したリード。SQL＝営業が「商談に値する」と認定したリード。SOL＝購買タイミング・理由が明確になったリード。確度はMQL→SQL→SOLの順で高まります。成功の鍵は、これらの定義をマーケと営業が共同で決め、合意（SLA）すること。定義の共通言語化が、ファネル運用の精度を一気に上げます。
なぜBANT・MQL・SQL・SOLが重要なのか
BtoB営業では、すべてのリード（見込み客）が同じ価値を持つわけではありません。「とりあえず資料をダウンロードしただけの人」と「予算と決裁権を持ち、今すぐ導入を検討している人」を同じように扱えば、営業リソースは確実に枯渇します。そこで必要になるのが、リードの確度を共通の基準で測り、段階ごとに分類するという考え方です。
BANT・MQL・SQL・SOLは、まさにこの「リードの質を見極め、適切なタイミングで適切な部門が対応する」ための共通言語です。これらを正しく運用できると、マーケ・インサイドセールス・フィールドセールスの連携がスムーズになり、商談化率と受注率が大きく改善します。逆に定義が曖昧だと、部門間で「これは商談に値する／値しない」の認識がズレ、せっかくのリードが取りこぼされてしまうのです。
BANTとは｜商談の有効性を判断する4条件
BANT（バント）とは、見込み客が「買える状態にあるか」を見極めるための4つの条件の頭文字を取ったフレームワークです。もともとはIBMが提唱したとされ、BtoB営業のクオリフィケーション（選別）における世界標準として長年使われています。
- Budget（予算）：購買のための予算が確保されているか／確保できる見込みがあるか
- Authority（決裁権）：相手が意思決定できる立場か、または決裁者にアクセスできるか
- Need（ニーズ）：解決すべき明確な課題・必要性があるか
- Timing（時期）：購買・導入の時期が具体的に見えているか
各条件の確認方法（ヒアリングのコツ）
Budget（予算）：「今回のご予算感はどの程度をお考えですか？」「予算はすでに確保されていますか、これからですか？」。直接聞きづらい場合は、想定する投資規模や費用対効果の話から探ります。
Authority（決裁権）：「ご導入の際は、どなたが最終的にご判断されますか？」「稟議のプロセスを教えていただけますか？」。担当者が決裁者でなくても、決裁者へのルートを確認できれば前進です。
Need（ニーズ）：「現在、どのような課題をお感じですか？」「その課題を放置すると、どんな影響がありますか？」。課題の深さと緊急度を引き出すことが重要です。
Timing（時期）：「いつ頃までに解決したいとお考えですか？」「導入のきっかけになる出来事（更新時期・組織変更など）はありますか？」。時期が曖昧なら、ナーチャリング対象に回します。
MQL（Marketing Qualified Lead）とは
MQL（エムキューエル）とは、マーケティング部門が「営業に渡せる水準に達した」と認定したリードのことです。Marketing Qualified Lead の略で、まだ商談には至っていないものの、自社の商品・サービスに一定の関心を示している見込み客を指します。
MQLは通常、「行動条件」＋「企業属性条件」の組み合わせで定義します。たとえば「料金ページを3回以上閲覧」「ホワイトペーパーを2本以上ダウンロード」「ウェビナーに参加」といった行動スコアと、「従業員50名以上」「特定業種」「役職が課長以上」といった属性条件の両方を満たしたリードをMQLとする、という具合です。
MQLの定義例
| 条件タイプ | 例 | スコア |
|---|---|---|
| 行動（資料DL） | ホワイトペーパーDL | +10点 |
| 行動（料金閲覧） | 料金ページ閲覧 | +15点 |
| 行動（ウェビナー） | ウェビナー参加 | +20点 |
| 属性（役職） | 部長・役員クラス | +20点 |
| 属性（企業規模） | 従業員100名以上 | +15点 |
※合計スコアが一定の閾値（例：50点）を超えたリードをMQLとしてインサイドセールスに引き渡す、という運用が一般的です。
SQL（Sales Qualified Lead）とは
SQL（エスキューエル）とは、営業部門が「商談を進める価値がある」と認定したリードです。Sales Qualified Lead の略で、MQLからさらに一歩進み、BANT条件の一定数が確保されている状態を指します。
典型的な流れは、マーケが渡したMQLを、インサイドセールス（IS）がナーチャリング（育成）・ヒアリングし、BANTを確認したうえでSQLへ昇格させるというものです。SQLになった時点で、フィールドセールス（FS）が本格的な提案・商談に入ります。MQLとSQLの境界をどこに引くかが、営業効率を左右する重要な設計ポイントです。
SOL（Sales Opportunity Lead）とは
SOL（エスオーエル）とは、購買のタイミングと購買理由が明確になったリードを指します。Sales Opportunity Lead の略で、SQLよりさらに確度が高く、受注に最も近い段階のリードです。
「課題は明確（Need）」「予算もある（Budget）」だけでは、まだ"いつか買うかもしれない"状態に過ぎません。SOLは、そこに「なぜ今、買う必要があるのか（購買理由）」と「いつ買うのか（明確な時期）」が加わった状態。ここまで来れば、クロージングの精度は格段に上がります。SOLはRINGOパイプラインが中間KPIに据える独自の概念で、MQL→SQL→SOLと段階を踏むほどリードの精度が上がる設計になっています。
リードファネル全体像｜MQL→SQL→SOL→商談→受注
これらの用語は、バラバラに存在するのではなく、1本の「リードファネル（漏斗）」の各段階を表しています。リードは上から下へ、確度を高めながら絞り込まれていきます。
- リード（Lead）｜名刺交換・資料DLなどで獲得した見込み客全般。確度は未判定。
- MQL｜マーケが行動・属性スコアで「営業に渡せる」と認定。ISへ引き渡し。
- SQL｜ISがBANTを確認し「商談に値する」と認定。FSへ引き渡し。
- SOL｜購買理由と時期が明確化。受注に最も近い段階。
- 商談（Opportunity）｜FSが提案・見積もり・クロージングを実施。
- 受注（Won）｜契約成立。LTVを生む顧客へ。
用語の違い早見表
4つの用語の違いを一覧で整理しました。「誰が認定するか」「何を基準にするか」「次に渡す相手」で区別すると理解しやすくなります。
| 用語 | 意味 | 認定者 | 判定基準 | 次の担当 |
|---|---|---|---|---|
| BANT | 商談有効性の判断軸 | IS／営業 | 予算・決裁・ニーズ・時期 | —（判定フレーム） |
| MQL | マーケ認定リード | マーケティング | 行動＋属性スコア | インサイドセールス |
| SQL | 営業認定リード | IS／営業 | BANTの一定充足 | フィールドセールス |
| SOL | 受注機会リード | 営業 | 購買理由＋時期の明確化 | クロージング |
リードスコアリングの設計
MQLを機械的・客観的に判定するために使うのがリードスコアリングです。リードの行動と属性に点数を付け、合計が閾値を超えたらMQLとして自動的に営業（IS）へ引き渡します。MA（マーケティングオートメーション）ツールを使えば、この一連の流れを自動化できます。
スコアリング設計の3ステップ
- 属性スコアを定義する｜業種・企業規模・役職など、ICP（理想顧客像）に近いほど高得点に。
- 行動スコアを定義する｜料金ページ閲覧・資料DL・ウェビナー参加など、購買意欲の高い行動ほど高得点に。
- 閾値とスコア減衰を設定する｜MQL化の合計点を決め、一定期間アクションがないリードはスコアを下げる（減衰）。
BANTの派生フレーム｜CHAMP・MEDDIC・GPCTBA
BANTは強力ですが万能ではありません。商材や営業スタイルに合わせて、近年はさまざまな発展版・代替フレームが使われています。代表的なものを紹介します。
| フレーム | 構成要素 | 特徴 |
|---|---|---|
| BANT | 予算・決裁権・ニーズ・時期 | シンプルで汎用的。クオリフィケーションの基本。 |
| CHAMP | 課題・決裁権・予算・優先度 | 「課題（Challenge）」起点。顧客の悩みを最優先に。 |
| MEDDIC | 指標・決裁者・決裁基準・購買プロセス・課題・推進者 | 大型・複雑なエンタープライズ商談向けの精緻なフレーム。 |
| GPCTBA/C&I | 目標・計画・課題・時期・予算・決裁＋悪影響・好影響 | HubSpot提唱。インバウンド時代向けに拡張。 |
どれが優れているという話ではなく、自社の商材の複雑さ・検討期間・ターゲットに合わせて取捨選択するのが正解です。中小〜中堅向けの汎用商材ならBANT、エンタープライズの大型商談ならMEDDIC、課題解決提案型ならCHAMP、といった使い分けが目安になります。
マーケと営業の定義合意（SLA）
BANT・MQL・SQL・SOLを運用するうえで最も重要なのが、マーケティングと営業が定義を共有し、合意することです。これをSLA（Service Level Agreement／部門間の合意）と呼びます。
よくあるのが、「マーケはこれをMQLと呼んでいるが、営業はそれを商談に値しないと考えている」というズレ。この認識の不一致が、リードの放置・部門間の不信・機会損失を生みます。これを防ぐには、両部門で次の点を明文化して合意することが不可欠です。
- MQLの定義（行動スコア・属性条件・閾値）
- SQLへ昇格させる基準（BANTのどこまでを満たすか）
- SOLと判定する条件（購買理由・時期の明確化レベル）
- 各段階の引き渡しルール（誰が・いつ・どのツールで渡すか）
- 営業がリードに対応するまでの目標時間（リードレスポンスタイム）
- 定義を見直す頻度（四半期ごとなど）
運用の落とし穴と回避策
落とし穴①｜MQL/SQLの定義が部門間で合意されていない
マーケと営業で「営業に渡せる水準」の認識がズレ、リードが宙に浮く。回避策：SLAを締結し、定義を文書化して全員が同じ基準を共有する。
落とし穴②｜BANT条件をすべて取ろうとして商談が失われる
初回から4条件を聞き出そうとして相手が離脱。回避策：段階的にヒアリングし、まずNeed/Timingを優先。予算・決裁は関係構築の中で確認する。
落とし穴③｜スコアリングが古いまま放置されている
市場・商材が変わったのに配点が当時のままで、的外れなMQLが量産される。回避策：四半期ごとにスコアと閾値を見直し、転換率データで検証する。
落とし穴④｜MQLを即FSに渡してしまう
育成前のリードを営業に丸投げし、確度の低い商談でFSの時間が浪費される。回避策：間にISを置き、BANT確認・ナーチャリングを経てSQLに引き上げてから渡す。
落とし穴⑤｜引き渡し後の対応が遅い
MQL化から営業の初回接触まで時間がかかり、リードの熱が冷める。回避策：リードレスポンスタイムをKPI化し、可能な限り短時間で接触する。
よくある質問（FAQ）
まとめ｜定義の共通言語化がファネル運用の精度を上げる
BANT・MQL・SQL・SOLは、"営業案件の質"を定義し、マーケと営業が同じ基準でファネルを運用するための基本用語です。BANT＝商談有効性の4条件、MQL＝マーケ認定リード、SQL＝営業認定リード、SOL＝受注機会リード。確度はMQL→SQL→SOLの順で高まり、各段階の転換率を計測することで改善ポイントが見えてきます。最大の成功要因は、これらの定義をマーケと営業が共同で決め、SLAとして合意し、定期的に見直すこと。共通言語化が、ファネル運用の精度を一気に押し上げます。
RINGOパイプライン（林檎営業株式会社）は、MQL→SQL→SOLを中間KPIに据えた独自のパイプライン設計で、BtoB営業の入口から商談化までを一歩ずつ確実に積み上げます。リードクオリフィケーションの設計やKPIの定義にお悩みなら、まずは無料相談からお気軽にどうぞ。