BtoBリード定義の作り方｜MQL・SQLで商談化基準を設計

BtoBリード定義の基本を知る：ビジネス成長における重要性

BtoBにおけるリード定義とは、将来的に顧客になり得る企業・担当者をどの条件で見込み顧客として扱うかを、マーケティング部門と営業部門で共通化した基準です。単にフォーム送信者や展示会で名刺交換した相手をすべて同じリードとして扱うと、営業が優先順位を判断できず、商談化率が下がります。リード定義の目的は、リード数を増やすことではなく、売上につながる見込み客を見極めることです。

BtoBでは検討期間が長く、意思決定者・利用部門・情報収集担当者が分かれるケースも多いため、個人の関心度だけでなく、企業属性や導入可能性まで含めて判断する必要があります。営業でのリードとは、単なる連絡先ではなく、課題・予算・導入時期・決裁関与度などを確認する前段階の見込み顧客情報です。リード獲得施策を増やす前に、どの状態をリードとして管理するかを明確にすることが、BtoBマーケティングの起点になります。

BtoBにおける「リード」とは何か？基本的な定義

BtoBにおけるリードとは、自社の商品・サービスに関心を示し、将来的に商談や受注につながる可能性がある企業または担当者の情報です。Webサイトからの資料ダウンロード、ウェビナー参加、展示会での名刺交換、問い合わせ、比較資料の閲覧などを通じて接点が生まれた相手が対象になります。

ただし、すべての接点を同じ温度感で扱うべきではありません。たとえば、課題解決の方法を調べている初期検討者と、導入製品を比較している担当者では、必要なコミュニケーションが異なります。BtoBのリード条件は、行動データだけでなく、企業規模・業種・部署・役職・利用予定時期などの属性データも組み合わせて設計します。

リードの種類を整理すると、社内の会話が具体化します。以下は、BtoB企業でよく使われるリード分類の例です。

リードの定義は？と社内で確認されたときに、上記のような分類表があると、マーケティング担当者と営業担当者が同じ前提で会話できます。定義がない状態では、リード獲得数だけが評価され、営業現場の負荷や商談化率が見落とされやすくなります。

「リード」と「顧客」の違い：商談化プロセスの理解

リードと顧客の違いは、契約・購入に至っているかどうかと、企業側が提供価値を実際に届けている段階かどうかにあります。リードは将来的に顧客になる可能性がある相手であり、顧客はすでに取引が成立し、サービス提供や継続関係が始まっている相手です。

BtoBでは、リードから顧客までの間に複数の段階があります。情報収集、課題認識、社内検討、比較、稟議、見積、契約という流れを経るため、リード獲得直後に受注するケースは多くありません。リードと顧客の違いは何ですか？という確認が必要になる背景には、マーケティング成果を「獲得数」だけで見てしまう組織課題があります。

たとえば、Web広告で100件の資料請求があっても、ターゲット外の企業が多ければ売上にはつながりません。一方、検索ボリュームが小さいキーワードから月10件しかリードが獲得できなくても、営業対象に合致し、商談化率が高ければ重要なチャネルになります。リードから顧客への転換を見据えることで、リード獲得施策の評価軸が「数」から「商談・受注への貢献」に変わります。

なぜBtoB企業にリード定義が不可欠なのか

BtoB企業にリード定義が不可欠な理由は、マーケティングと営業が同じ基準で見込み顧客を判断しなければ、商談化の再現性が作れないためです。営業が「質が低い」と感じるリードをマーケティングが「成果」として報告する状態では、部門間の信頼が崩れます。

現場で特に起こりやすい失敗は、営業が実際に体験したターゲット外の商談内容をマーケティングへ共有していないことです。たとえば、資料請求後に商談化したものの、実際には導入権限がない、予算規模が合わない、サービス対象外の業種だったという情報が戻らなければ、マーケティング側は同じ条件のリードを獲得し続けます。

次に多いのは、営業のフィードバックがマーケティング側で判断できない粒度になっていることです。「温度感が低い」「微妙だった」「質が悪い」といった表現だけでは、リード条件を修正できません。さらに、とにかくリードの数にこだわり、質を管理する仕組みがない企業では、営業が追うべき対象が増え続け、結果として重要な見込み顧客への対応が遅れます。

この問題を解消するには、MQLからSQLになる際に、リードの質を共通スコアで判断する仕組みが必要です。マーケティングと営業が別々の目線で管理すると、マーケティングにとって良いリードと営業にとって良いリードが分かれ、会社にとって良いリードが見えにくくなります。BtoBのリード定義は、部門別の評価基準ではなく、会社として売上につながる見込み客を定義する取り組みです。

MQLとSQLの違いを理解する：商談化基準設計の土台

MQLとSQLの違いは、マーケティングが営業接続候補と判断した段階か、営業が商談化可能と判断した段階かにあります。BtoBマーケティングでは、MQLとSQLを分けずに運用すると、営業へ渡すタイミングが早すぎたり遅すぎたりして、商談機会を逃します。MQLとSQLの違いを明確にすることは、リード獲得から商談創出までのボトルネックを把握するための前提です。

重要なのは、MQLとSQLを「部署ごとの所有物」として分けるのではなく、同じ顧客プロセスの連続した状態として扱うことです。マーケティングは、どの経路で獲得したリードが商談化しやすいかを理解する必要があります。営業は、質の良いリードだけを待つのではなく、顧客になり得る見込み客の質を上げるために、接触結果をマーケティングへ戻す必要があります。

MQL（Marketing Qualified Lead）とは？

MQLとは、マーケティング活動によって獲得・育成されたリードのうち、営業接続を検討できる状態に達した見込み顧客です。具体的には、ターゲット業種に合致している、複数回コンテンツに接触している、サービスページや料金ページを閲覧している、比較資料をダウンロードしている、といった条件を満たしたリードが該当します。

MQLは「すぐに商談化する相手」とは限りません。MQLは、営業が接触すべき可能性がある相手をマーケティング側で選別した段階です。したがって、MQLの条件を厳しくしすぎると営業に渡る件数が少なくなり、緩くしすぎると営業工数が圧迫されます。

経営層から「営業に渡すべきMQLの基準が厳しすぎて、リード不足に陥るのではないか」と懸念されることがあります。この場合の回答は、MQL基準はリード数を減らすためではなく、マーケティング施策の戦略判断に必要な基準だということです。リード数が多くてもMQLが少ない施策は、必ずしも良い施策とは評価できません。一方で、MQLがよく取れる施策は費用が高かったり、母数が少なかったりするため、量と質のバランスを判断するために合意基準が必要です。

SQL（Sales Qualified Lead）とは？

SQLとは、営業が接触・確認した結果、商談化に進める可能性が高いと判断した見込み顧客です。SQLでは、マーケティング上の興味関心だけでなく、課題の具体性、導入時期、予算感、決裁関与度、競合比較状況などが重視されます。

営業でのリードとは、接触先リストではなく、提案可能性を確認するための入口です。営業がヒアリングした内容から、相手の課題が自社サービスで解決できるか、提案タイミングが適切か、商談として扱うべきかを判断します。SQLは、営業担当者が「提案機会として管理すべき」と判断した段階と考えると分かりやすくなります。

SQLの基準が曖昧だと、商談化数が営業担当者の主観に左右されます。ある担当者は初回面談の約束だけでSQLとし、別の担当者は予算確認まで完了しないとSQLにしない場合、レポート上のSQL数は比較できません。SQLの定義を明文化することで、営業活動の進捗とマーケティング貢献度を正しく測定できます。

MQLとSQLの違いを明確にする重要性

MQLとSQLの違いを明確にする重要性は、リードの受け渡し基準と責任範囲を可視化できる点にあります。MQLはマーケティングが育成・選別した営業接続候補、SQLは営業が商談可能性を確認した見込み顧客です。

以下の表は、MQLとSQLの違いを実務で整理するための比較です。社内でMQL SQL 違いを確認する際は、名称よりも判断主体と移行条件をそろえることが重要です。

この違いをあいまいにしたままKPIを設定すると、マーケティングはMQL数を増やし、営業はSQL化しない理由を個別に判断するだけになります。部門間でMQLとSQLの接続点を合意していない状態では、リード獲得施策の改善点が見えません。営業連携記事の下層テーマとしてリード定義を設計する場合も、まずMQLとSQLの接続基準から固めるべきです。

BtoBリードの質を高めるMQL・SQLの具体的な定義方法

BtoBリードの質を高めるには、属性条件・行動条件・除外条件・営業確認条件を組み合わせて、MQLとSQLの定義を段階的に設計します。リード獲得施策を増やしても、条件が曖昧なままでは、営業が追うべき相手は明確になりません。BtoBでリードを獲得する施策は、SEO、ホワイトペーパー、ウェビナー、展示会、広告、比較サイトなど多様ですが、獲得後の基準がなければ施策ごとの良し悪しを判断できません。

実務では、いきなり完璧なスコアリングを作るより、まず商談化しやすいリードの共通点を整理することが有効です。過去の受注案件と失注案件を比較し、業種、企業規模、部署、役職、閲覧ページ、ダウンロード資料、問い合わせ内容などを見ます。そのうえで、MQL条件とSQL条件を表に落とし込み、HubSpotなどのCRM・MA上で運用できる形に変換します。

項目	MQLの基準例	SQLの基準例	補足/注意点
属性条件	ターゲット業種・企業規模に合致、役職が部長以上	決裁権限者または影響力のある役職、導入部門の担当者	企業リストやCRMデータと連携し自動判定を推奨
行動条件	特定の製品ページを複数回閲覧、料金ページ閲覧、比較資料DL、ウェビナー参加	営業担当者との面談で具体的な課題を共有、デモ依頼、個別相談	行動スコアリングを活用し、閾値を超えたらMQL化
除外条件	競合企業、学生、個人事業主、既存顧客のサポート問い合わせ	予算・時期が合わない、導入意欲が低い、サービス対象外	定期的に除外リストを見直し、営業工数の無駄を削減
営業確認条件	（MQL段階では営業確認は不要、マーケティングが選別）	課題の具体性、予算の有無、導入時期の確認、決裁プロセスの把握	営業がヒアリングシートに基づき判断し、CRMに記録
判断主体	マーケティング部門	営業部門	部門間の合意形成が最も重要

BtoBの主なリード獲得施策と特徴

BtoBのリード獲得施策は、短期で件数を増やす施策と、中長期で質の高い接点を作る施策に分けて考えます。重要なのは、どの施策が優れているかではなく、自社の商材単価、検討期間、営業体制、ターゲット企業の情報収集行動に合った組み合わせを作ることです。各施策で獲得したリードは、流入経路ごとにMQL率、SQL率、商談化率を比較し、定義の見直しに反映します。

SEOは、課題が顕在化する前の見込み顧客と接点を作れる一方、記事閲覧だけでは検討度を判断しにくい施策です。そのため、記事テーマを「課題認知」「比較検討」「導入判断」に分け、資料DLやサービスページ閲覧と組み合わせてMQL条件を作ります。ウェビナーは、アンケートで導入時期や課題を聞けるため、MQL化の判断材料を集めやすい施策です。展示会は名刺数が増えやすい反面、情報収集のみの来場者も多いため、会話メモや関心カテゴリをCRMに残すことが欠かせません。

広告は短期でリード数を増やしやすい施策ですが、ターゲティングやLP訴求がずれると対象外リードも増えます。比較サイトは検討度が高いリードを獲得できる可能性がありますが、同時に競合にも問い合わせていることが多いため、営業対応のスピードと差別化情報が重要です。リード獲得施策は単体で評価せず、獲得後にMQL・SQL・商談・受注へどれだけ進んだかで判断します。

MQLの具体的な条件設定：行動・属性データの活用

MQLの条件設定では、ターゲット属性に合致していることと、購買検討に近い行動を取っていることを組み合わせます。属性だけで判断すると、まだ情報収集段階の相手を営業へ渡してしまい、行動だけで判断すると、ターゲット外の相手をMQL化してしまいます。

以下は、BtoB企業がMQL条件を設計する際に使いやすい項目です。リード条件をBtoB向けに整理する場合、加点条件だけでなく除外条件も同時に決めることが重要です。

MQLの条件は、リード獲得施策の評価にも使えます。たとえば、月間100件のリードを生む施策でもMQL率が5％であれば、営業接続の観点では改善が必要です。一方、月間20件のリードでもMQL率が50％で、商談化率も高ければ、投資を増やす価値があります。リード獲得のBtoB施策は、CV数だけでなくMQL率とSQL率をセットで見るべきです。

SQLの具体的な条件設定：商談移行に必要な基準

SQLの条件設定では、営業が商談として扱うべき根拠を、ヒアリング情報と行動情報の両面から定義します。SQLは営業判断を含むため、スコアだけで自動的に確定させるのではなく、営業確認項目を設けることが重要です。

SQL条件の代表例は、課題が明確であること、導入時期が一定範囲内であること、予算または予算化の可能性があること、決裁者または推進者との接点があることです。BANTやMEDDICなどの営業フレームワークを使う企業もありますが、最初から複雑にしすぎると入力が定着しません。まずは「商談に進める最低条件」を3〜5項目に絞ります。

SQL条件で避けたいのは、営業担当者が「なんとなく良さそう」と感じた案件だけをSQLにすることです。主観を完全に排除する必要はありませんが、判断基準が記録されなければ改善できません。営業の肌感覚をデータに変換することが、SQL設計の実務上の価値です。

MQLからSQLへの移行基準とリードスコアリングの活用

MQLからSQLへの移行基準は、スコアが一定以上に達し、かつ営業確認で商談化の可能性が認められた状態として設計します。スコアリングは便利ですが、点数だけで営業に渡すと、特定行動の過大評価や過小評価によってMQLが過剰または過少になります。

以下は、BtoB企業で使いやすいリードスコアリング表の例です。実際には商材単価、営業工数、検討期間、ターゲット属性に合わせて調整します。

HubSpotでリードスコアリングを設定する場合は、コンタクトプロパティに「リードステータス」「MQL判定日」「SQL判定日」「ターゲット適合度」「検討フェーズ」などを用意し、アクティブリストでMQL候補を抽出します。その後、ワークフローで営業担当者へ通知し、営業が接触結果を入力することでSQL化の判断を残します。

想定される失敗例として、メール開封に高い点数を付けすぎたケースがあります。たとえば、メール開封を+15点、サービス資料DLを+10点に設定すると、実際には比較検討していないリードが複数回の開封だけでMQL化します。この場合、営業に渡る件数は増えますが、通電率や商談化率は下がります。修正方法は、メール開封を+1〜+2点程度の補助指標に下げ、料金ページ閲覧、事例閲覧、サービス資料DL、問い合わせなど商談に近い行動の重みを上げることです。

逆に、問い合わせや料金ページ閲覧の点数が低すぎると、明らかに検討度が高いリードがMQLに上がらないことがあります。⚠️ 注意：スコアリングは一度設定して終わりではなく、MQL数、SQL数、商談化率、失注理由を見ながら毎月調整する必要があります。

マーケティングと営業の連携強化：リードパスの最適化

マーケティングと営業の連携を強化するには、MQLからSQLへ移行する条件、対応期限、フィードバック項目をSLAとして明文化する必要があります。リードパスとは、リード獲得後に、どの条件で、誰が、いつ、どの情報をもとに次の対応へ進めるかを定めた流れです。BtoBでは、ナーチャリング、インサイドセールス、フィールドセールスが分かれることも多いため、リードパスが曖昧だと対応漏れや重複連絡が発生します。

2026年現在、AI検索を起点に顧客が自ら課題整理や比較検討を進めるケースが増えています。ChatGPTやGeminiなどで情報収集した見込み客は、問い合わせ前に比較軸を持っていることもあります。その一方で、インサイドセールスの通電率や従来型ナーチャリングの効果が薄くなっている可能性もあり、MQLやSQLをしっかり定めて、顧客になり得る見込み客に集中する重要性が高まっています。

SLA（Service Level Agreement）による部門間連携の確立

SLAとは、マーケティングと営業の間で、リードの受け渡し条件や対応ルールを合意した社内取り決めです。BtoBのリード管理では、MQLを営業へ渡した後の対応期限、接触回数、SQL化条件、差し戻し条件をSLAに含めます。

SLAがない場合、マーケティングはMQLを渡したつもりでも、営業が対応しないまま時間が経過することがあります。逆に、営業が対応した結果を入力しなければ、マーケティングはどの施策が商談化につながったのかを把握できません。SLAは、部門間の責任追及ではなく、リードを顧客化するための共通運用ルールです。

実務で使いやすいSLA項目は以下の通りです。

HubSpotでは、MQL化したコンタクトをアクティブリストで抽出し、ワークフローで担当者へタスク作成や通知を行えます。SLAをツールに落とす際は、通知だけでなく、未対応リードをダッシュボードで見える化することが重要です。

SLAを運用に定着させるには、合意内容を作って終わりにせず、未対応時のエスカレーション、差し戻し後のナーチャリング戻し、定例での改善判断まで決めておきます。たとえば、MQL化から1営業日以内に初回接触、3営業日以内に接触結果入力、5営業日以上未対応なら営業責任者へ通知する、といったルールです。対応期限を設定することで、温度感の高いリードを放置するリスクを減らせます。

SLAで特に重要なのは、マーケティングと営業の双方に責任範囲を持たせることです。マーケティングは、ターゲット外リードを過剰に営業へ渡さない責任があります。営業は、MQLへの対応結果を記録し、SQL化しなかった理由を戻す責任があります。SLAはリードの受け渡し表ではなく、リード定義を継続改善するための運用契約です。

リード情報の共有とフィードバック体制の構築

リード情報の共有では、営業が判断できる情報と、マーケティングが改善に使える情報を同じ場所に蓄積することが重要です。営業が見たいのは、どの資料をダウンロードしたか、どのページを見たか、どの課題に関心があるかです。マーケティングが見たいのは、なぜ商談化したか、なぜ商談化しなかったか、どの施策のリードが受注に近かったかです。

現場の失敗例として、営業が「ターゲットではなかった」と感じた商談内容をマーケティングへ共有していないケースがあります。たとえば、広告代理店向けサービスなのに、個人事業主や学生のダウンロードが多い場合、フォーム項目や広告配信条件を修正する必要があります。しかし営業の感覚が共有されなければ、同じリードが流入し続けます。

また、営業のフィードバックが「質が悪い」だけでは、マーケティング側は改善できません。最低限、対象外理由、課題の有無、導入時期、役職、競合比較の有無、次回接点の有無を記録する必要があります。情報共有と情報の認識合わせを同時に行うことで、リードの質を上げる改善サイクルが回ります。

リード定義の見直しプロジェクトでは、以下のような定例MTGアジェンダを使うと議論が進みます。

定例MTGは、営業への依頼事項を増やす場ではなく、会社として良いリードを定義し直す場です。営業は質の良いリードだけを追うのではなく、リードの質を上げていく視点を持つ必要があります。マーケティングは、自分たちが獲得したリードがどの経路をたどって商談化するのかを理解する必要があります。

リード育成（ナーチャリング）戦略とMQL/SQL定義の連動

ナーチャリング戦略は、MQLやSQLの定義と連動させることで、見込み顧客の検討度に応じた情報提供ができます。リード獲得直後の相手に営業連絡を急ぎすぎると、まだ課題が整理されていないため反応が悪くなります。一方、比較検討が進んでいる相手に一般的なノウハウ記事だけを送り続けると、商談機会を逃します。

BtoBのナーチャリングでは、検討フェーズ別にコンテンツを分けることが有効です。初期段階では課題整理や基礎知識、中期段階では選定基準や比較表、後期段階では導入事例や料金、ROI試算が有効です。リード獲得施策で集めた見込み顧客を、フェーズ別の情報提供でMQLへ育成し、SQL化に必要な行動や意思表示を促します。

具体的には、まずリードの流入経路とCV内容から仮の検討フェーズを付与し、次にメール、記事、ホワイトペーパー、ウェビナー、事例コンテンツを組み合わせて、次の行動へ進んでもらう導線を作ります。たとえば、基礎記事を読んだリードには課題整理チェックリストを案内し、チェックリストをダウンロードしたリードには選定基準ウェビナーを案内します。比較資料をダウンロードしたリードには、導入事例や費用対効果の資料を送り、営業接続のきっかけを作ります。

ナーチャリングの実践ステップは、①ペルソナと検討フェーズを定義する、②フェーズ別コンテンツを棚卸しする、③不足コンテンツを制作する、④メールやワークフローで配信する、⑤行動データをスコアに反映する、⑥営業フィードバックで改善する、という流れです。特にBtoBでは、1回のメール配信で商談化を狙うよりも、複数接点を通じて課題の明確化と社内検討を支援する設計が重要です。

テクロ株式会社のサービス資料では、近年のBtoBマーケティングにおいて、顧客がChatGPTやGeminiなどのAIを活用し、情報収集だけでなく課題整理や論点の明確化まで行うようになっていると整理しています。加えて、Gartnerは、AIチャットボットなどの影響により、2026年までに検索エンジンの検索ボリュームが25％減少すると予測しています^[1]。この環境では、ナーチャリングメールだけに頼らず、AI検索で参照されるFAQ、定義表、比較情報、導入事例も整備する必要があります。

HubSpotで実装する場合は、検討フェーズをプロパティとして持たせ、閲覧ページやDL資料に応じてフェーズを自動更新します。たとえば、基礎資料DLは「情報収集」、比較資料DLは「比較検討」、問い合わせは「商談希望」といった形です。そのうえで、各フェーズに応じたメール配信、営業通知、リスト更新をワークフローで自動化します。

リード定義の最適化による商談化率・顧客獲得率向上施策

リード定義の最適化は、商談化率と顧客獲得率を高めるために、MQL・SQL・商談・受注の各段階で基準と実績を見直す改善活動です。BtoBマーケティングでは、最初に決めた定義が半年後も最適とは限りません。市場環境、競合状況、AI検索経由の流入、広告チャネル、営業体制が変われば、リードの質も変化します。

テクロ株式会社は2016年以来BtoBマーケティング支援を行っており、主にオウンドメディア・コンテンツマーケティングを中心に、2026年現在はAI検索への対策としてLLMO対策も支援しています。支援現場では、PVやCVだけでなく、商談・受注まで見据えたKPI設計を重視しています。サービス概要資料でも「リードは質を重視」「商談化できるリードの創出を主に目指す」と明記されています^[2]。

定義見直しによるリード精度の向上と改善サイクル

リード精度を上げる改善サイクルは、定義、計測、評価、修正の4段階で運用します。まずMQLとSQLの条件を定義し、次に各リードの流入経路・行動・営業結果を計測します。その後、どの条件が商談化や受注につながったかを評価し、スコアや条件を修正します。

改善時に見るべき指標は、リード数だけではありません。MQL率、SQL率、商談化率、受注率、営業対応率、初回対応までの時間、差し戻し理由、失注理由をセットで確認します。たとえばMQL数が増えてもSQL率が下がっている場合、MQL条件が緩すぎる可能性があります。逆にSQL率は高いがMQL数が少なすぎる場合、条件が厳しすぎるか、リード獲得チャネルが不足している可能性があります。

AI検索時代には、従来の流入指標だけでは判断しにくい接点も増えています。テクロ株式会社のサービス概要資料では、AI経由の問い合わせが増えている例として、2026年3月時点でCVの25％がAI検索経由だったことが紹介されています^[2]。AI検索から流入するユーザーは、すでに比較軸を持っている場合があるため、MQL条件では流入元だけでなく、閲覧ページやDL資料の質を見る必要があります。

業種別・商材別にスコアリング要素を設計する際は、購買プロセスの長さと意思決定構造を反映します。以下は、BtoB企業で応用しやすいスコアリング要素の例です。

リード定義の見直しは、営業の負荷削減にもつながります。公開事例ではなく匿名化した支援ログに基づく参考例では、MQL/SQL基準の再設計後、営業が即時対応すべき月間リード数が420件から260件に減った一方、月間商談数は76件から81件に増えたケースがあります^[3]。これは、対象外や低温度のリードをナーチャリングに戻し、顧客になり得る見込み客に営業工数を集中した結果です。

MAツール・CRMを活用したリード管理と自動化

MAツール・CRMを活用すると、リード定義をプロパティ、リスト、スコア、ワークフロー、ダッシュボードとして実装できます。定義をドキュメントに書くだけでは運用されないため、日々の営業・マーケティング活動で自動的に反映される仕組みが必要です。

HubSpotでの実装例は、以下の流れで設計します。まず、コンタクトプロパティにリードステータス、ライフサイクルステージ、ターゲット適合度、検討フェーズ、SQL判定理由、差し戻し理由を作成します。次に、フォーム項目や行動履歴からスコアを計算し、一定条件を満たしたコンタクトをMQLリストへ自動追加します。

リード定義をHubSpotに落とす際の接続方法は、ドキュメント上の条件をそのままプロパティ・リスト・ワークフローに変換することです。たとえば「ターゲット業界かつサービス資料DLかつスコア60点以上」をMQL条件にするなら、業種プロパティ、資料DL履歴、スコアプロパティを条件にしたアクティブリストを作成します。そこから営業通知ワークフローを起動し、営業がSQL判定理由を入力することで、MQLからSQLへの移行履歴が残ります。

テクロ株式会社のHubSpot導入・活用設計では、CRM設計、パイプライン設計、ステータス／フェーズ設計、リード管理設計、KPI設計、MAフロー設計、営業フロー設計、ダッシュボード設計、データ整備ルール設計、定例MTG、改善ディレクションを支援範囲としています^[4]。単なる初期設定ではなく、マーケティングと営業をつなぐ運用設計まで含めることが特徴です。

一方で、ツール導入だけではリード定義は定着しません。入力項目が多すぎると営業が使わなくなり、スコア条件が複雑すぎるとマーケティング担当者が改善できなくなります。最初は最小限の項目で始め、商談化率と営業フィードバックを見ながら拡張することが現実的です。

【2026年最新事例】リード定義最適化による成功事例

リード定義を最適化した事例では、リード数だけでなく、MQLからSQL、商談、受注までの指標が改善します。ここでは、公開資料に掲載されている導入事例と、匿名化した支援ログから、リード定義の見直しが成果に与える影響を整理します。

株式会社アジャイルウェア様のプロジェクト管理ツール事例では、広告に頼ったWebマーケティングから新規リードを増やすため、オウンドメディア運用、サーバー変更時のサポート、ディレクトリ構造のサポート、CTAデザイン提案を実施しました。その結果、月間PV数は313から8.6万へ、月間資料DL数は1件から118件へ増加しています^[5]。このように、リード獲得の導線が整うと、MQL設計の対象となる母数を増やせます。

株式会社Scene Live様のクラウド型コールシステム事例では、お問い合わせが増えず、業界レポートのダウンロードしか発生せず商談にならない課題がありました。サイトのUI/UX改善、月間10本の記事ライティング、記事リライトを実施し、月間PV数は4000から6.5万へ、月間資料DL数は0件から10件へ増加しています^[5]。単なるPV増加ではなく、商談につながる導線へ改善した点が重要です。

株式会社ジェイアンドユー様の事例では、HubSpotの運用支援により営業の可視化に成功し、売上が前年より5％アップしたことが公開事例として紹介されています^[6]。また、別資料では同社に対し、拡販誌やPR誌の発刊部数減少、営業電話がつながらなくなっていた課題に対して、メディア立ち上げ、月間10本の記事ライティング、ホワイトペーパー作成を実施し、月間PV数1354から2.4万、月間資料DL数0件から24件へ改善した実績も示されています^[5]。

公開事例ではなく、個別企業名を伏せたHubSpot導入企業の匿名化支援ログに基づく参考例では、リード定義の見直し後、MQLからSQLへの転換率が18％から31％へ改善しました^[3]。Beforeでは、資料ダウンロードのみでMQL化していたため、営業が対応しても「情報収集のみ」「対象外」「時期未定」が多く、SQL化が進みませんでした。Afterでは、ターゲット属性、サービスページ閲覧、比較資料DL、導入時期の入力、営業差し戻し理由を組み合わせ、MQL条件を再設計しました。

この事例のポイントは、MQL基準を厳しくしたから成果が出たのではなく、マーケティングと営業が合意した基準に変えたことです。MQLの基準は、どちらか一方の部署だけで考えると失敗しやすくなります。経営層が懸念するリード不足についても、単純に基準を緩めるのではなく、MQLが取れる施策と、リード数を増やす施策のバランスを見て判断する必要があります。

リード定義を自社で見直す際は、以下のワークシート項目を使うと整理しやすくなります。これは実務で使える設計テンプレートとして、本記事向けに整理したものです。

ワークシート化する最大の目的は、議論を抽象論で終わらせないことです。「良いリード」「温度感が高い」といった言葉を、属性、行動、営業確認、数値に分解します。リード定義は資料ではなく、営業とマーケティングが毎月見直す運用ルールです。

まとめ：質の高いBtoBリード定義がビジネス成長の鍵

質の高いBtoBリード定義は、マーケティング施策と営業活動を売上に接続するための基盤です。リードとは将来的に顧客になり得る見込み顧客であり、顧客とは契約・購入に至った相手です。この違いを踏まえずに、リード獲得数だけを追うと、営業工数が増える一方で商談化率が伸びにくくなります。

MQLはマーケティングが営業接続候補と判断したリード、SQLは営業が商談化可能性を確認したリードです。MQLとSQLの違いを明確にし、属性条件、行動条件、除外条件、営業確認条件を組み合わせることで、リードパスが整います。特に2026年現在は、AI検索で顧客が自ら比較検討を進めるため、単純なナーチャリングや架電だけではなく、顧客になり得る見込み客を見極める設計が重要です。

HubSpotを活用する場合は、リード定義をプロパティ、リスト、スコアリング、ワークフロー、ダッシュボードに落とし込むことで、マーケティングと営業が同じデータを見ながら改善できます。定義を作って終わりにせず、MQL率、SQL率、商談化率、受注率、差し戻し理由を毎月確認し、スコア配分や条件を調整することが成果につながります。

テクロ株式会社は2016年以来BtoBマーケティング支援を行っています。主にオウンドメディア・コンテンツマーケティングを中心に、昨今はAI検索への対策としてLLMO対策のご支援を行っています。リード定義をHubSpotのプロパティ・リスト・ワークフローへ落とし込み、MQL/SQL設計を実務で運用したい場合は、リード定義・MQL/SQL設計テンプレートを活用しながら、自社の営業プロセスに合わせて見直すことをおすすめします。

リード定義に関するFAQ

リード定義を実務に落とし込む際は、用語の理解だけでなく、どの条件で営業に渡すか、どのタイミングで見直すかまで決める必要があります。ここでは、BtoB企業でリード管理を始める際に確認されやすい論点を整理します。

リードは問い合わせだけを指しますか

リードは問い合わせだけではなく、資料ダウンロード、ウェビナー参加、展示会名刺、メルマガ登録、比較資料閲覧など、自社と接点を持った見込み顧客を含みます。ただし、問い合わせは検討度が高い傾向があるため、スコアリングでは高く評価するのが一般的です。

MQLの基準は厳しいほど良いですか

MQLの基準は厳しければ良いわけではなく、営業対応可能数、商談化率、施策別の獲得単価を見ながら決めるべきです。基準を厳しくすると営業効率は上がりやすい一方、営業に渡る件数が不足する可能性があります。マーケティングと営業の双方で合意し、毎月見直すことが重要です。

SQL化は自動判定できますか

SQL化は一部自動化できますが、最終判断には営業確認を含めるのが現実的です。スコアや行動履歴でSQL候補を抽出し、営業が課題、時期、関与度、次アクションを確認してSQL化する流れが安定します。

リード獲得施策の良し悪しは何で判断すべきですか

リード獲得施策は、CV数だけでなく、MQL率、SQL率、商談化率、受注率、CPAを組み合わせて判断します。月間リード数が多くても商談化しない施策は改善が必要です。一方、リード数が少なくても受注に近いチャネルは、重点投資の候補になります。

HubSpotで最初に作るべき項目は何ですか

最初に作るべき項目は、リードステータス、検討フェーズ、ターゲット適合度、MQL判定日、SQL判定日、差し戻し理由です。これらをプロパティとして管理し、アクティブリストとワークフローを組み合わせることで、営業対応とナーチャリングの分岐を作れます。

よくある質問

BtoBビジネスにおけるリードの定義とは何ですか？

BtoBにおけるリードとは、自社の商品・サービスに関心を示し、将来的に商談や受注につながる可能性がある企業や担当者の情報を指します。これは、マーケティング部門と営業部門で共通化した、見込み顧客として扱うための基準です。単なる連絡先ではなく、売上につながる見込み客を見極めるための重要な概念となります。

リードと顧客の主な違いは何ですか？

リードと顧客の主な違いは、契約・購入に至っているかどうかです。リードは将来的に顧客になる可能性がある見込み客を指しますが、顧客はすでに取引が成立し、サービスの提供や継続的な関係が始まっている相手を指します。BtoBでは、リードから顧客になるまでに情報収集から契約まで複数の段階を経ます。

営業におけるリードとは、どのような状態の顧客を指しますか？

営業におけるリードとは、単なる連絡先ではなく、課題・予算・導入時期・決裁関与度などの提案可能性を確認する前段階の見込み顧客情報を指します。これは営業が接触・確認した結果、商談化に進める可能性が高いと判断したSQL（Sales Qualified Lead）の状態に該当します。

MQLとSQLの違いは何ですか？

MQLとSQLの主な違いは、判断主体と見込み顧客の状態です。MQL（Marketing Qualified Lead）はマーケティングが育成・選別し、営業接続候補と判断したリードに対し、SQL（Sales Qualified Lead）は営業が接触・確認を経て商談化に進めると判断したリードを指します。この違いを明確にすることで、リードの受け渡し基準と責任範囲が可視化されます。

参考文献

1. 新_テクロのサービス資料_提案資料のまとめ_AI検索_LLMO_SEO対策 — テクロ株式会社（2026年）
2. リード定義・MQL/SQL設計に関する匿名化支援ログ — テクロ株式会社（2026年）
3. HubSpot導入／活用設計プラン — テクロ株式会社（2026年）
4. 導入事例・サービス概要資料 — テクロ株式会社（2026年）
5. 導入事例「【売上5%UP】HubSpotの運用支援で営業の可視化に成功。売上・利益率が前年より大幅アップした施策とは｜株式会社ジェイアンドユー様」 — テクロ株式会社（2026年）