BANTとは｜4条件の意味・ヒアリング手法・IS運用・SQL判定基準を体系的に解説

「商談を設定しても受注につながらない」「インサイドセールスからフィールドセールスへの引き渡し基準が曖昧で、商談の質にばらつきがある」「MQLとSQLの定義を全部門で合意したいが、何を基準にすればよいかわからない」——こうした課題を抱えるBtoB企業の営業・マーケティング責任者は少なくありません。

BANT（バント）は、こうしたリード判定の基準を体系化するフレームワークです。Budget（予算）・Authority（決裁権）・Needs（必要性）・Timeline（導入時期）の4条件でリードの商談化見込みを判定し、営業リソースの集中とファネル全体の効率化を実現します。

本記事では、BANTの定義と各条件の詳細から、具体的なヒアリング質問例、インサイドセールスでの運用方法、MQL/SQL判定基準への組み込み方、拡張フレームワーク（BANT-CH・MEDDIC）との使い分け、日本企業での活用の注意点まで体系的に解説します。

BANTとは

BANT（バント）とは、BtoB営業において見込み顧客（リード）の商談化見込みを判定するためのフレームワークです。以下の4つの条件の頭文字を取っています。

BANTは1960年代にIBMが法人営業の案件管理手法として提唱したフレームワークで、60年以上にわたりBtoB営業の基本ツールとして使われ続けています。現代のインサイドセールスやMA（マーケティングオートメーション）を活用した営業プロセスにおいても、MQLからSQLへの昇格基準としてBANTの考え方は不可欠です。

BANT各条件の詳細とヒアリング手法

4つの条件それぞれについて、確認すべき内容と実践的なヒアリング質問例を解説します。

B：Budget（予算）

顧客が自社サービスの導入に対して予算を確保しているか、または確保する見込みがあるかを確認します。予算の有無は商談のスピードと実現可能性に直結します。

確認すべきポイント：

• 今期または来期の予算に本件の導入費用が計上されているか
• 概算の予算規模感（「数十万円」「数百万円」「1,000万円以上」等の粒度）
• 予算が未確保の場合、新規予算の申請・承認プロセスはあるか

ヒアリング質問例：

• 「本件に関して、今期の予算枠はすでに確保されていますか？」
• 「ご予算の規模感として、月額○万円〜○万円のレンジは検討の範囲に入りますか？」
• 「予算の確保にあたって、社内で必要な手続き（稟議等）はございますか？」

注意点：SaaS商材やサブスクリプションモデルの場合、ROI（投資対効果）が明確であれば、事前予算が未確保でも新規予算申請で承認されるケースがあります。「予算がない＝見込みなし」と即断せず、予算確保の可能性まで確認することが重要です。

A：Authority（決裁権）

商談の相手が最終的な購買意思決定を行う権限を持っているか、決裁プロセスがどうなっているかを確認します。

確認すべきポイント：

• 商談相手の役職と決裁範囲（金額ライン）
• 最終決裁者は誰か（個人決裁か、合議制か）
• 稟議が必要な場合、承認フロー（何名・何段階・想定期間）
• 導入に影響を与えるキーパーソン（推進者・慎重派）の有無

ヒアリング質問例：

• 「本件のご導入を最終的にご判断されるのは、どなたになりますか？」
• 「社内の承認プロセスとして、稟議や役員会議への付議は必要でしょうか？」
• 「ご検討にあたって、他にお声がけされている部門やご担当者はいらっしゃいますか？」

注意点：日本企業では稟議制度や合議制が一般的です。「決裁者＝役職者」とは限らず、実務担当者が事実上の推進者（チャンピオン）として導入を主導するケースが多くあります。決裁権者だけでなく、稟議を起案する担当者との関係構築も重要です。

N：Needs（必要性）

顧客が抱えている課題やニーズが自社サービスで解決可能かを確認します。4条件の中で最も本質的な項目であり、ここが不明確な商談は他の条件が揃っていても受注に至りにくい傾向があります。

確認すべきポイント：

• 顧客が現在抱えている具体的な業務課題
• 課題の緊急度と重要度（「今すぐ解決したい」か「いずれ対応したい」か）
• 現在の業務プロセスや既存ツールの課題点
• 自社サービスが解決できる課題との一致度

ヒアリング質問例：

• 「現在の業務で最も課題に感じていらっしゃる点はどこですか？」
• 「その課題が解決されない場合、業務にどのような影響がありますか？」
• 「今回のご検討のきっかけとなった出来事や背景があれば教えてください」

▶ あわせて読みたい：SPIN話法とは｜4つの質問ステップ・営業での活用法・実践例

T：Timeline（導入時期）

具体的な導入時期や検討スケジュールが定まっているかを確認します。導入時期が明確なリードほど商談化の確度が高く、営業リソースの優先配分の判断基準になります。

確認すべきポイント：

• 導入の希望時期（「今四半期中」「来期から」「時期未定」等）
• 検討〜導入までのスケジュール感
• 導入時期に影響する外部要因（年度予算のサイクル、法改正、既存契約の更新時期等）

ヒアリング質問例：

• 「ご導入の時期として、いつ頃を想定されていますか？」
• 「他のサービスとも比較検討中でしょうか？比較検討のスケジュール感を教えてください」
• 「導入時期に影響する社内の事情（予算サイクル、既存契約の満了時期等）はございますか？」

注意点：「時期未定」のリードを即座に対象外とするのではなく、リードナーチャリングの対象として中長期的にフォローする設計が重要です。リードナーチャリングの設計方法について詳しく知りたい場合はリードナーチャリングとは｜意味・手法・KPI設計からIS連携・外注判断まで体系的に解説をご参照ください。

BANTをインサイドセールスで運用する方法

BANTは、The Model型営業分業体制においてインサイドセールス（IS）がリードを精査し、フィールドセールス（FS）に引き渡すSQL判定基準として機能します。

MQL→SQL判定基準へのBANT組み込み

マーケティングがスコアリングで選別したMQL（Marketing Qualified Lead）を、インサイドセールスがBANT条件で精査し、SQL（Sales Qualified Lead）に昇格させてFSに引き渡す——これがThe Modelにおける標準的なリードの流れです。

どのパターンを採用するかは、フィールドセールスとインサイドセールスの三者合意で決定してください。定義を曖昧にしたまま運用を開始すると、ISが設定した商談をFSが「質が低い」と感じる不一致が発生します。

The Model型分業モデルの全体像について詳しく知りたい場合はThe Model型分業モデルとは｜4部門の役割・KPI設計・ツール基盤・導入判断を体系的に解説をご参照ください。

CRM/SFAでのBANT管理

BANT情報はCRM/SFA上でリードごとに構造化して記録し、チーム全体で共有します。

• BANT専用フィールドの設計：CRM上にB/A/N/Tそれぞれの入力フィールド（選択式またはテキスト）を作成し、ヒアリング結果を標準化して記録する
• BANT充足度のスコア化：各条件を「確認済み（2点）」「概要確認（1点）」「未確認（0点）」の3段階で採点し、合計スコアでSQL判定を行う方法が実務的です
• FS引き渡し時の情報共有：BANT情報に加えて、ヒアリング時の顧客発言メモやCTI通話録音のリンクをCRM上で共有し、FSが商談準備に活用できる状態にする

CRMツールの選定について詳しく知りたい場合はCRMとは｜主要サービス比較・費用相場・活用法を解説を、SFAツールについて詳しく知りたい場合はSFAとは｜主要機能・サービス比較・費用相場を解説をご参照ください。

SDR・BDRでのBANT活用の違い

SDR・BDR代行サービスの比較について詳しく知りたい場合はSDR・BDR代行を徹底比較｜費用相場・KPI設計・失敗しない選び方をご参照ください。

BANT-CH・MEDDIC——拡張フレームワークと使い分け

BANTを基本としつつ、より精密なリード判定が必要な場合に活用される拡張フレームワークを紹介します。

BANT-CH（バントシーエイチ）

BANTにCompetitor（競合）とHuman Resources（人的資源）の2条件を追加したフレームワークです。

BANT-CHは、SaaS・ITサービスのように導入後の運用体制が成果に大きく影響する商材で特に有効です。

MEDDIC / MEDDPICC（メディック / メディピック）

MEDDICは、Metrics（導入効果の数値化）・Economic Buyer（経済的意思決定者）・Decision Criteria（選定基準）・Decision Process（意思決定プロセス）・Identify Pain（課題の特定）・Champion（社内推進者）の6要素で構成される、BANTより詳細なリード判定フレームワークです。MEDDPICCはさらにPaper Process（契約手続き）とCompetition（競合）を加えた8要素版です。

フレームワークの使い分け

最初からMEDDICを導入する必要はありません。まずBANTで基本的なリード判定の仕組みを構築し、商談サイクルや商材の複雑性に応じて段階的にBANT-CHやMEDDICに拡張するアプローチが現実的です。

日本企業でのBANT活用の注意点

BANTは欧米で生まれたフレームワークであり、日本の商習慣に合わせたアレンジが必要な場面があります。

稟議制度・合議制への対応

日本企業では購買意思決定が稟議制度や合議制で行われるケースが一般的です。「決裁権者＝商談相手」とは限らず、実務担当者→直属上司→部門長→役員会議という多段階の承認フローを経る場合があります。Authority（決裁権）の確認では、決裁者個人を特定するだけでなく、稟議承認フロー全体を把握することが重要です。

• 金額ラインごとの決裁権限（「500万円までは部長決裁」「1,000万円以上は役員会議」等）
• 稟議の起案者（実務担当者）が事実上のチャンピオン（推進者）であるケースが多い
• 稟議に必要な情報（ROI試算、競合比較資料、他社導入事例）を先回りして提供する

初回商談でのBANT確認の進め方

日本のBtoB商談では、初対面でいきなりBANTの4条件を質問すると相手に不信感を与える場合があります。特にBudget（予算）は直接的に聞きにくい項目です。

• Needs（課題）から入る：まず顧客の業務課題を丁寧にヒアリングし、信頼関係を構築する
• 自然な流れでB・A・Tを確認する：課題のヒアリングから「導入時期」→「社内の検討状況」→「予算感」の順に自然に掘り下げる
• 複数回のコンタクトで段階的に確認する：1回のヒアリングで4条件すべてを確認しようとせず、ISの架電やメールフォローの中で段階的に情報を収集する

「予算未確保」への対応

SaaS商材では「明確な予算枠がない＝見込みなし」とは限りません。ROIが明確であれば新規予算申請が承認されるケースがあるため、以下の対応が有効です。

• ROI試算シートを提供し、顧客が社内で予算を確保するための材料を提供する
• 無料トライアルやPoCを提案し、実績データで投資対効果を実証する
• 「予算は来期」のリードはナーチャリング対象として中長期フォローに回す

よくある失敗パターンと回避策

失敗1：BANT情報の収集が目的化する

• 何が起きるか：ISがBANTの4項目を「埋めること」に集中し、顧客との対話がチェックリスト型の尋問になる。顧客は不信感を持ち、本音を話さなくなる
• 構造的原因：BANTを「聞くべき質問リスト」として運用しており、顧客の課題理解のためのフレームワークとして活用できていない
• 回避策：BANTは「聞く順番」ではなく「確認すべき観点」として運用する。会話の自然な流れの中でBANT情報を収集し、「顧客理解の深さ」をKPIとして評価する

失敗2：SQL定義がISとFSで合意されていない

• 何が起きるか：ISは「日程確定」を商談としてカウントし、FSは「BANT確認済み」を商談と認識している。結果としてFSが「質の低い商談ばかり」と不満を持ち、部門間の信頼関係が悪化する
• 構造的原因：MQL→SQLの引き渡し基準（BANT条件の充足度合い）がISとFSで合意されていない
• 回避策：BANT条件のうち「どの項目を」「どの深さまで」確認すればSQLとするかを、ISとFSで事前に明文化する。四半期ごとにSQL定義をレビューし、受注率データに基づいて調整する

IS KPI設計とBANTの関係について詳しく知りたい場合はインサイドセールスのKPI設計完全ガイド｜指標選定・目標設定・運用改善まで解説をご参照ください。

失敗3：BANT不充足のリードを即座に切り捨てる

• 何が起きるか：BANT条件が揃わないリードを「見込みなし」として放置した結果、中長期で商談化する可能性のあったリードが競合に流れる
• 構造的原因：BANTを「今すぐ商談化するかどうか」の判定にのみ使用しており、ナーチャリング→リサイクルの設計がない
• 回避策：BANT不充足のリードはマーケティングに戻し、ナーチャリング施策で中長期的にフォローする。CRM上でBANT充足度をステータス管理し、条件が揃った段階でISに再通知する仕組みを構築する

よくある質問（FAQ）

BANTの4条件すべてが揃わないとSQLにできませんか？

すべて揃う必要はありません。SQL定義は企業や商材によって異なります。「N（ニーズ）＋T（時期）が確認できていればSQL」とする標準型や、「N（ニーズ）＋他1条件以上」とする柔軟型もあります。自社の商材単価・営業サイクル・FSリソースに応じてISとFSで合意してください。

BANTはもう古い・時代遅れのフレームワークですか？

BANTの基本的な考え方は現在も有効です。ただし、SaaS普及に伴う購買行動の変化（予算が後付けで確保されるケース、決裁権が分散するケース等）に対応するため、BANT-CHやMEDDICなどの拡張フレームワークも検討してください。BANTが「時代遅れ」ではなく「BANTだけでは不十分な場合がある」という認識が正確です。

BANTの確認はインサイドセールスとフィールドセールスのどちらが行いますか？

The Model型の分業体制では、ISがBANTの初期確認を行い、SQL基準を満たしたリードをFSに引き渡すのが標準的です。FSは引き渡し後にBANT情報をさらに深掘りし、提案内容の精度を高めます。ISによるBANT確認の品質が、FS側の受注率に直結します。

BANTをCRM上でどう管理すればよいですか？

CRM上にB/A/N/Tそれぞれの入力フィールドを作成し、「確認済み」「概要確認」「未確認」の3段階で記録する方法が実務的です。4項目の充足度を合計スコア化し、閾値を超えたリードを自動でSQL候補としてフラグを立てる仕組みも有効です。Salesforce、HubSpot、Zoho CRMなどの主要CRMにはカスタムフィールドでBANT管理を構築できます。

営業代行（IS代行）にBANT精査を委託する際の注意点は？

委託先にBANT精査を依頼する場合、最も重要なのは「SQL定義（BANT条件の充足度合い）」を委託先と自社FSの三者で事前に合意することです。定義が曖昧なまま運用を開始すると、委託先がアポイント数を優先してBANT精査が不十分になるリスクがあります。また、BANT判定基準やトークスクリプトの設計・改善を継続的に行う体制を確認してください。

MAのスコアリングとBANTの関係は？

MA（マーケティングオートメーション）のスコアリングは、リードのWeb行動（ページ閲覧、資料DL、メール開封等）に基づくリードの温度感を数値化する仕組みです。一方、BANTはISが架電やメールで直接ヒアリングして確認する情報です。MAスコアリングでMQLを選別→ISがBANT確認でSQLに昇格という二段階の判定が標準的な運用です。MAツールの詳細はMAとは｜主要ツール比較・費用相場・活用法を解説をご参照ください。

まとめ

BANT（Budget・Authority・Needs・Timeline）は、BtoB営業においてリードの商談化見込みを判定するための基本フレームワークです。インサイドセールスがMQLをSQLに昇格させる判定基準として、The Model型営業分業体制の中核的な役割を担います。

BANTを自社の営業プロセスに組み込む際は、以下のポイントを整理して進めてください。

1. SQL定義をISとFSで合意する：BANT条件のうち「どの項目を」「どの深さまで」確認すればSQLとするかを明文化し、四半期ごとにレビューする
2. CRM上でBANTを構造化する：B/A/N/Tの各フィールドを設計し、充足度をスコア化して管理する
3. 日本の商習慣に合わせてアレンジする：稟議制度・合議制を前提に、Authorityは「決裁者個人」ではなく「承認フロー全体」を把握する
4. BANTを「聞くリスト」ではなく「確認する観点」として運用する：顧客との自然な対話の中で情報を収集し、顧客理解の深さを重視する
5. BANT不充足リードはナーチャリングで中長期フォローする：即座に切り捨てず、リサイクルの仕組みでリード資産を最大化する

まずは自社のSQL定義を明文化し、ISとFSの間でBANT判定基準を合意することから着手してください。