リード獲得のMQL・SQL定義を整理する

リード獲得の全体像とMQL/SQLの位置づけ

「リード獲得」は、フォーム送信や名刺交換で“連絡先が手に入る”だけの話ではありません。経営や事業責任者が見たいのは、受注につながる確度を高めながら、営業とマーケティングの投資配分を最適化できる状態です。そのために必要なのが、リードを段階で区切り、次のアクションを決める「定義」です。

ここで押さえる用語は3つです。
MQL＝マーケティング部門が一定条件で有望と判定したリード。
SQL＝営業が商談化に進めると判定したリード。
KPI＝目標達成度を測る主要指標。

BtoBで検討期間が長い商材ほど、問い合わせ直後に商談化しないケースが多く、「今すぐ客」と「将来客」が混在します。定義がないまま運用すると、マーケティングは件数を追い、営業は温度感の低いリードに疲弊しやすくなります。定義は、部門間の約束事であり、投資判断の前提でもあります。

もう一歩だけ踏み込むと、定義は「売上を作るまでの見える化」に直結します。パイプライン＝受注見込みの案件を金額と確度で管理する考え方。経営判断では、このパイプラインが増えているのか、どの段階で詰まっているのかが重要です。MQL/SQLの線引きが曖昧だと、パイプラインが増えているのか、単に連絡先が増えているだけなのかが判別できません。

まずは全体像を1枚に落とすのが近道です。下記は一例ですが、各段階ごとに「判定基準」「担当」「次アクション」をセットで持つと、現場の迷いが減ります。

区分	判定基準例	主担当	次アクション
リード	接点獲得（資料ダウンロード、展示会、広告など）	マーケティング	ナーチャリング、再訪促進
MQL	属性が狙いに合い、行動が一定以上（例：料金ページ閲覧、導入事例閲覧）	マーケティング	営業連携の準備、追加情報の回収
SQL	ニーズが明確で、時期や決裁条件が一定以上	営業	初回接触、課題ヒアリング、商談化判定
商談	担当者と課題・要件が整理され、提案プロセスに入った	営業	提案、検討支援、関係者調整
受注	契約合意に至った	営業＋導入支援担当	導入支援、活用定着

ナーチャリング＝見込み客に継続的に情報を届け、検討度を高める活動。BtoBでは、ナーチャリングの設計が弱いと「リードはあるのに商談が増えない」状態になりやすいです。

ポイントは「段階名」ではなく「次のアクションが変わる境界」を作ることです。境界が曖昧だと、担当者の属人的判断が増え、月ごとに数字の意味が変わってしまいます。逆に境界が明確なら、SEOで集めるべき検索意図、用意すべきコンテンツ、フォームで聞くべき項目、営業の追い方まで一貫して設計できます。
SEO＝検索結果からの自然流入を増やす取り組み。
コンテンツ＝検討に必要な情報を文章・資料・動画などで提供するもの。
フォーム＝問い合わせや資料請求などの入力画面。

定義が揃わないと起きる機会損失

定義が揃わない組織で起きる問題は、単なる“連携ミス”ではありません。機会損失は、だいたい次の3つのズレとして現れます。

基準のズレ

マーケティングは「関心がありそう」をMQLと見なし、営業は「今すぐ検討」をSQLだと考える。このズレがあると、営業は「追っても進まないリードが多い」と感じ、マーケティングは「送っているのに商談にならない」と感じます。どちらも正しく、基準が言語化されていないだけです。

タイミングのズレ

営業が追うべき瞬間は、検討が始まった時点とは限りません。BtoBでは、社内稟議や比較検討が進む前に、情報収集を深める期間が長く続きます。稟議＝社内で決裁を得るための申請プロセス。マーケティングが“熟してから渡す”運用に寄りすぎると、競合に先に接点を取られやすくなります。一方、早すぎる連携はノイズになります。ここを調整するのがMQLとSQLの境界です。

計測のズレ

同じ言葉を使っていても、計測のルールが違うと数字が合いません。たとえば「商談」のカウントが、初回打ち合わせなのか、提案依頼なのか、見積提出なのかで、KPIの意味が変わります。数字が合わない状態は、改善の議論が進まない状態と同義です。

ズレの兆候は、データにも表れます。転換率＝ある段階から次の段階へ進む割合。MQL→SQLの転換率が極端に低いなら「基準が緩い」か「営業が追えていない」可能性があります。逆に転換率が高すぎる場合は「MQLが実質SQLになっていて、マーケティング施策の学びが得られにくい」可能性があります。ここは良し悪しではなく、定義と運用の整合が取れているかを見ます。

この3つのズレは、Webにも連鎖します。SEOで集める検索キーワード、導線で推す資料、フォームで聞く質問、営業の架電基準がバラバラになるためです。言い換えると、定義はWeb戦略の設計図でもあります。
導線＝サイト内で次の行動へ導くリンクや構成。

MQLの定義を作る手順

MQLは「営業へ渡す前の見込み」を示しますが、作り方を誤ると“件数は増えるのに売上に寄与しない”状態になりがちです。手順はシンプルに、上から下へ落とします。

1. 目的を数字で言い換える

売上や成長目標を、商談数・受注数・平均単価などの要素に分解します。ここでいう分解は、目標を達成するために増やすべき量を特定する作業です。分解が曖昧だと、MQLの基準も曖昧になります。

2. 「狙う企業」と「狙う状況」を言語化する

ターゲットは“業種”だけでは不足です。従業員規模、導入体制、既存の仕組み、課題の深さなど、成約しやすい条件を言葉にします。ペルソナ＝意思決定に関わる人物像を、役割と関心事で整理したもの。

3. 判定基準を3種類に分ける

MQLの基準は、混ぜると破綻しやすいので分けて考えます。
属性：企業規模、業種、役職などのプロフィール情報。
行動：閲覧ページ、資料ダウンロード、セミナー参加などの行動履歴。
ニーズ：課題・時期・予算感など、本人の言葉で得られる情報。

4. スコアリングは“運用できる粒度”に留める

スコアリング＝行動や属性に点数を付け、一定点を超えたらMQLとする運用。精緻さより、継続して回せることが重要です。最初から項目を増やしすぎると、入力漏れや集計ミスが増え、定義が形骸化します。

5. MQLの「次アクション」を先に決める

MQLにした瞬間に何をするかが決まっていないと、定義は机上の空論になります。たとえば「営業へ連携する」のか、「メールで事例を届けて再訪を促す」のか、「ウェビナーへ誘導する」のかで、必要なコンテンツと計測が変わります。ウェビナー＝オンラインで行うセミナー。MQLは“判定”と“運用”がセットです。

6. まずは仮置きし、見直しの型を作る

BtoBの現場では、最初から完璧な定義を作るより、仮置きして運用しながら磨くほうが早く進みます。SLA＝部門間で「どの条件なら渡すか」「渡したらどれくらいで追うか」などを合意した約束。SLAを文章にしておくと、担当者が変わっても運用が崩れにくくなります。

SQLの定義と営業への引き渡し条件

SQLは「営業が動けば前に進む条件が揃った」と判断できる状態にします。SQLを厳しすぎる条件にすると機会を逃し、緩すぎる条件にすると営業の稼働がノイズで埋まります。経営目線では「営業が追う順番が合理的になっているか」「追った結果が数字で振り返れるか」の2点が重要です。

SQLは“商談化判定”の前提を明文化する

BtoBで検討期間が長い商材の場合、SQLは「予算確定・稟議開始」まで待たない設計も現実的です。稟議＝社内で決裁を得るための申請プロセス。代わりに、次の観点を揃えるとブレにくくなります。

対象企業として合っている（業種・規模・導入環境など）
課題が具体的（現状の困りごと、改善したい指標が言語化されている）
前に進む意思がある（比較検討を始める、関係者に共有する等の行動が見える）
接触できる（担当者が特定され、連絡手段がある）

「意思」は曖昧になりやすいので、サイト行動も材料にします。たとえば料金ページ、導入事例、機能比較、セキュリティ関連ページなどの閲覧は、検討が進んでいるサインになりやすいです。セキュリティは、BtoBでは終盤で確認されやすい要素なので、早めに情報を出しておくと無駄な往復が減ります。

引き渡し条件はSFA/CRMの項目に落とす

SFA＝営業活動（架電、商談、提案など）を記録・可視化する仕組み。CRM＝顧客情報と接点履歴を一元管理する仕組み。SQLの条件は、運用で迷わないようにSFA/CRMの項目として持つのが基本です。

最小構成としては、次の3つがあると判定と振り返りが回ります。

企業情報：業種、従業員規模、拠点、利用中の関連ツール等
ニーズ情報：課題、検討背景、想定スケジュール、関係者
接点情報：流入チャネル（SEO、広告、展示会等）、閲覧履歴、過去の接触履歴

ここで注意したいのが、SQLを「営業が受け取った」瞬間にするのか、「営業が確認して合格にした」瞬間にするのかです。前者は件数が増えやすく、後者は精度が上がりやすい。どちらが良いかは、KPIと運用負荷のバランスで決めます。

営業側の受け入れ条件もセットで決める

SLA＝部門間で引き渡し条件や対応期限を合意して文章化した約束。マーケがSQLを作っても、営業が追うルールがなければ成果につながりません。たとえば「SQL連携後、初回接触は何営業日以内」「接触できない場合の再接触回数」「不成立時はマーケへ戻す条件」を決めます。
リサイクル＝営業で不成立だった見込み客を、マーケ側で育成に戻す運用。リサイクル条件を言語化すると、営業は捨てにくくなり、マーケは次に渡す材料が増えます。

KPI設計と計測の前提

KPIは、受注から逆算して階段状に置くと意思決定が早くなります。受注に近い指標ほど変動は小さく、上流ほど変動は大きい。経営判断では「何が原因で増減したか」を説明できる設計が重要です。

目的からKPIを分解する

KPIが増えても受注が増えない場合、指標が“結果とつながっていない”可能性があります。まずは目的→上位指標→中位指標→下位指標の順で整理します。

目的	上位指標	中位指標	下位指標
受注増	受注件数・受注金額	商談数・受注率	SQL数・商談化率
パイプライン増	パイプライン金額	商談単価・案件数	SQL単価・チャネル別SQL
営業生産性	営業工数あたり受注	初回接触率・提案率	初回接触までの時間
マーケ効率	獲得単価（CPL/CPA）	MQL単価・SQL単価	流入別CVR・フォーム完了率

CPL＝リード獲得あたりのコスト、CPA＝成果獲得あたりのコスト、CVR＝訪問から成果行動に至る割合。指標は一気に増やすより、意思決定に使う順に“少数精鋭”で始めるほうが運用が安定します。

計測の前提は「単位」と「重複」を揃える

KPIが揃わない原因の多くは、計測の単位がズレていることです。たとえば「1人が複数回フォーム送信したら何件か」「同一企業の複数担当者は何件か」。BtoBでは企業単位で見たい場面が多いので、会社名・ドメインで名寄せする設計が効きます。名寄せ＝同一人物・同一企業をまとめて扱う処理。

UTM＝流入元を判別するためにURLへ付与するパラメータ。広告やメルマガ、SNSなどチャネルが多いほどUTMの運用ルールが重要になります。入力ルールがないと、同じ施策が別名で記録され、チャネル比較ができなくなります。

最低限のレポートで“詰まり”を特定する

毎週見るべきは、MQL→SQL→商談→受注のどこが詰まっているかです。詰まりが見えれば、打ち手は自然に絞れます。たとえばMQLが多いのにSQLが増えないなら、MQL基準か営業対応のどちらか。SQLは増えたのに商談が増えないなら、初回接触の質と速度。受注率が落ちたなら、提案内容か競合状況です。

Webサイト導線とコンテンツ設計への落とし込み

MQL/SQLの定義は、Webサイトの導線とコンテンツに落とし込んで初めて“仕組み”になります。導線＝サイト内で次の行動へ導くリンクや構成。コンテンツ＝検討に必要な情報を文章・資料・動画などで提供するもの。

検討段階ごとにコンテンツの役割を分ける

検討の初期は「課題の言語化」と「選択肢の理解」が中心です。中期は「比較」と「社内説明」。終盤は「リスク確認」と「稟議資料」です。段階が違うのに同じ資料を出すと、MQLが増えてもSQLに進みにくくなります。
CTA＝次の行動を促すボタンや導線。CTAは“読み終わった人が次に知りたいこと”に合わせると、行動が増えます。

フォームは情報取得と離脱防止を両立させる

CV＝サイト上での成果行動（例：資料請求、デモ依頼）。フォーム項目を増やすと情報は取れますが、離脱も増えます。そこで「今すぐ営業対応が必要なSQL候補」と「育成で良いMQL候補」を分ける設計が有効です。具体的には、入口は短いフォームでハードルを下げ、追加ヒアリングはメールや初回接触で補う、という分業です。

運用タスクと費用増の要因を先に把握する

施策が増えるほど、定義更新・計測・コンテンツ更新の運用負荷が増えます。経営判断としては、運用を回す人員と外部支援の範囲を先に見積もることが重要です。

タスク	主担当	発生しやすい費用	管理ポイント
定義更新（MQL/SQL）	マーケ＋営業	会議・資料作成工数	変更履歴と適用日
計測設計・タグ管理	Web担当＋分析担当	実装・保守工数	計測漏れと重複
コンテンツ制作・更新	マーケ＋制作	制作費・編集工数	検索意図とCTA整合
フォーム・導線改善	Web担当	改修費・検証工数	離脱率と入力負荷
レポート運用	マーケ	集計工数	定義と単位の統一

ここまでを押さえると、SQLの質が上がり、KPIが揃い、Webの改善が“どこを触れば良いか”までつながります。

体制と運用フロー

定義を作っても、運用が回らなければ数字は安定しません。特に従業員10〜500名規模では、属人化＝特定の担当者しか分からない状態を避けつつスピードも落とさない設計が重要です。おすすめは「決める人」と「回す人」を分けることです。

決める人（承認）：事業責任者またはマーケ責任者（営業責任者も同席）
回す人（運用）：マーケ担当、Web担当、営業の推進役
支える人（実装・分析）：制作会社、計測担当、アクセス解析担当

運用の型は、次の3点を固定すると崩れにくくなります。
1つ目は会議体＝定例で集まって意思決定する場とルールの頻度と参加者。2つ目は見る指標（KPIの固定化）。3つ目は決定事項の記録（定義変更の履歴）です。

週次は“詰まり”の早期発見が目的です。MQL→SQL→商談の転換率に加え、「初回接触までの時間」「未接触の残件」を見ると、営業負荷の実態が見えます。月次は“仕組みの見直し”が目的で、チャネル別の質（SQL単価、商談化率、受注寄与）を見ながら投資配分と優先施策を決めます。受注寄与＝特定の施策やチャネルが受注にどれだけ関与したかを評価する考え方。

定義変更は「適用日」「変更点」「比較方法」をセットで残します。これがないと翌月の数字が良くても悪くても原因が追えず、意思決定が鈍ります。定義の議論は、感覚論ではなく“現実の営業プロセス”に沿って行うのがコツで、営業の動きが変わる境界だけを調整します。

リスクとトラブルの回避策

トラブルの多くは、定義そのものより「境界の運用」と「データ品質」で起きます。先に回避策を用意しておくと、部門間の不信が生まれにくくなります。

MQLが増えすぎる問題：行動条件を“1つ追加”する（例：導入事例閲覧）など、段階的に絞る
SQLが増えない問題：営業の初回接触遅延を疑い、対応期限をSLAで固定する
数字が合わない問題：定義（何を1件と数えるか）と名寄せルールを統一する
データ欠損の問題：フォーム変更やサイト改修時に計測チェックを必須化する
営業が追わない問題：SQLの情報不足（課題・背景が薄い）を疑い、フォーム設計やヒアリング項目を見直す

特に注意が必要なのは「良いリードの定義」が、時間とともに変わることです。季節要因、商材の追加、営業体制の変化で、同じ条件でも成果が変わります。だからこそ、定義は固定資産ではなく運用資産として扱い、月次で微調整する前提を持つほうが安全です。

個人情報＝個人を特定できる情報。取り扱いは社内ルール（保管期間、閲覧権限、削除手順）を決め、ツール任せにしないことが重要です。BtoBは問い合わせ後に名刺交換やメールのやり取りが増えるため、運用ルールがないと、情報が散らばって引き継ぎが難しくなります。

費用と投資判断の考え方

費用は「初期」と「運用」に分けると見積もりやすくなります。初期は計測・導線・フォーム・管理項目の整備、運用はコンテンツ制作と改善サイクルが中心です。

初期に出やすい費用：計測設計、タグ実装、フォーム改修、各ページの役割整理、SFA/CRMの項目整備
運用で出やすい費用：記事や事例の制作、ホワイトペーパー更新、導線改善、レポート運用、営業資料の整備

ホワイトペーパー＝検討段階で必要な知見をまとめたダウンロード資料。
TCO＝導入後の運用費も含めた総コスト。ツール単体の価格だけでなく、入力・集計・会議の工数も含めて判断すると、後からの追加投資が減ります。外部支援を使う場合は、戦略（定義とKPI）・制作（コンテンツと導線）・分析（計測と改善）のどこを任せるかを分けて契約すると、成果物と責任範囲が明確になります。

投資判断では、まず“売上につながる分解式”を社内共通言語にします。
受注金額＝商談数×受注率×平均受注単価。
商談数＝SQL数×商談化率。
SQL数＝MQL数×MQL→SQL転換率。
この式で、どのレバーを上げるのが現実的かを決めます。たとえばSEOでリード母数を増やすのか、導線改善で転換率を上げるのか、営業の初回接触を早めて商談化率を上げるのかで、必要な費用と体制が変わります。ここが整理できると、経営会議での説明が通りやすくなります。

相談前に整理するチェックリスト

相談時に議論が速くなるのは、現状の数字とルールが揃っている場合です。最低限、次を整理しておくとWeb戦略と営業連携の設計が具体化します。

商材の平均受注単価、受注までの平均期間、主な意思決定者
現在のリード定義（ある場合）と、MQL/SQL/商談のカウント方法
直近3か月の流入チャネル別のリード数と、可能ならSQL・商談の数
Webサイトの主要導線（入口ページ、訴求ページ、フォームまでの経路）
使用中の管理ツール（SFA/CRM等）と、入力項目・運用ルール
営業の初回接触ルール（対応期限、手段、未接触時の扱い）
よく受注する業種・規模の傾向と、よく失注する理由の傾向
相談獲得に使っている主要コンテンツ（事例、料金、比較、ホワイトペーパー）

まとめ

MQLとSQLの定義は、部門間の合意を作るための言葉であり、Web戦略（SEO・コンテンツ・導線・計測）を一貫させるための設計図です。BtoBで検討期間が長いほど、件数よりも「どの段階を増やすか」を決め、運用で磨くことが成果につながります。
みやあじよでは、目的を具体化し、集客方法設計とUI/UX設計を同列に考えながら、問題解決としてWeb改善を進める方針を重視しています。UI/UX＝画面の使いやすさ（UI）と体験全体の良さ（UX）を設計すること。

リード獲得の全体像とMQL/SQLの位置づけ