MQLとSQLの定義をどう決めるか：件数目標より先に合意すべきこと

この記事の要約

MQLとSQLの定義がなぜ営業とマーケの間で食い違い続けるのか。その根本原因は、多くの組織が「月間MQL件数○件」といった件数目標を先に決め、定義そのものを後から数字に合わせて帳尻合わせしているという、進め方の順序にあります。

本記事では、CROとCMOが件数目標の議論に入る前に握っておくべき3つの論点、すなわち「関心」の判断根拠を行動データと属性データのどちらに置くか、SQL化の例外をどこまで許容するか、そして定義の改訂権限を誰が持つかを整理します。さらに、行動データの棚卸しから例外ルールの明文化まで、実務で使える5ステップの合意形成フレームワークと、営業からの疑問を定義改訂につなげるフィードバックの仕組みも提示します。

読み終える頃には、自社のMQL/SQL運用がなぜ形骸化していたのかが言語化でき、次の会議で件数ではなく「基準の中身」から議論を始めるための具体的な進め方が手に入ります。

この記事でわかること

• MQLとSQLの定義が営業とマーケでずれる構造的な原因
• 件数目標を決める前に合意すべき3つの論点(判断根拠・例外・改訂権限)
• 行動データの棚卸しから始める5ステップの定義合意フレームワーク
• 件数目標を先に決めることで起きる具体的な弊害
• 定義合意後にMQL/SQL関連KPIをどう設計するか

はじめに

四半期の営業会議で、営業部長から「マーケから来るリードの質が悪い」と言われ、マーケティング責任者は「定義通りの基準は満たしている」と反論する。こうしたやり取りに、心当たりはないでしょうか。双方の言い分はどちらも間違っていないケースがほとんどです。問題は個人の力量ではなく、MQL・SQLという言葉の中身を、件数目標を決める前に丁寧に合意していなかったことにあります。

基準を巡る不毛な押し付け合いは、放置すればするほど営業とマーケの信頼関係そのものを蝕んでいきます。本記事では、この順序のズレをどう解消し、営業とマーケが同じ基準で会話できる状態をどう作るかを、具体的な手順とともに解説します。

MQLとSQLの定義がずれる、本当の理由

結論から言うと、MQLとSQLの定義が営業とマーケで噛み合わない最大の原因は、「件数目標」を先に決めてから定義を後付けしていることにあります。四半期のリード獲得目標や商談化目標が先に経営会議で承認され、その数字を成立させるために逆算でMQLの基準が緩められる、あるいはSQLの基準が現場ごとに解釈される。

これが繰り返されると、マーケティングは「基準を満たしたリードを渡している」と主張し、営業は「これは全然“熱い”リードじゃない」と突き返す、という不毛なやり取りが半年ごとに再発します。

「リード」の解釈がチームごとに違う

そもそもMQL(Marketing Qualified Lead)とSQL(Sales Qualified Lead)という言葉自体、業界標準の厳密な定義があるわけではありません。ホワイトペーパーをダウンロードした人をMQLと呼ぶ会社もあれば、複数回のサイト訪問とメール開封を組み合わせたスコアで判定する会社もあります。CROやCMOの立場からすると、この言葉の抽象度の高さが、部門間の「解釈の余白」を生んでいる点をまず認識する必要があります。

スコアリングだけでは合意にならない

MAツール(マーケティングオートメーション)のリードスコアリング機能を導入すれば定義問題が解決する、と考えるのは早計です。スコアリングは「どの行動に何点を割り振るか」という設計そのものが合意の産物であり、設計を決める議論を飛ばしてツールに数字を出させても、営業側が納得する理由にはなりません。

点数という客観的に見える指標が、実は最も主観的な設計判断の集合体である、という点は見落とされがちです。

例えば、デマンドジェネレーション担当は「ウェビナー参加」に高い点数を割り振りたがりますが、フィールドセールスからすれば「ウェビナーに出ただけの人」がSQLとして送られてくることに強い違和感を持ちます。

逆に営業側は「問い合わせフォームからの直接相談」を最重視しますが、この行動は母数が少なく、件数目標を追うマーケティング側からすると重視しづらい指標になります。どちらの言い分にも一理あり、点数設計の議論を避けて通ることはできません。

定義を決める前に合意すべき3つの論点

件数目標の前に握るべきなのは、以下の3つの論点です。この順番を守らないと、どれだけ精緻なスコアリングモデルを作っても運用段階で崩れます。

誰が「関心」を判断するのか：行動データか属性データか

第一の論点は、「関心」の判断根拠を行動ベースにするか属性ベースにするかです。例えば、資料請求という行動は関心の強さを示しますが、その人物が決裁権を持つ役職かどうかは属性データでしか分かりません。行動データだけで基準を作ると「無関係な部署の担当者が資料請求しただけ」のケースを拾ってしまい、属性データだけで基準を作ると「本当に検討フェーズに入っている個人」を見逃します。

合意しておくべき問いは、次の3つです。

• 行動と属性、どちらを一次条件にするか
• 一次条件を満たさない場合の例外的な繰り上げルールを設けるか
• ICP(理想的な顧客像)との合致度をスコアにどう反映するか

SQL化の「例外」をどこまで許容するか

第二の論点は例外の扱いです。定義通りにMQLの基準を満たしていなくても、インサイドセールスが電話で明確な検討ニーズを確認できた場合はSQLに昇格させてよいのか。逆に、スコア上はMQL基準を満たしていても、営業が架電した結果「情報収集段階に過ぎない」と判断した場合は差し戻せるのか。ここを事前に合意していない組織では、営業担当者ごとに判断基準がばらつき、同じ属性のリードが人によってSQLになったりならなかったりします。

定義を「誰が」更新する権限を持つか

第三の論点は、定義の改訂権限です。市場環境や商材が変われば、MQL・SQLの基準は当然見直しが必要になります。しかし「誰が」「どのタイミングで」その改訂を提案し、承認するのかが決まっていないと、営業部長が個別に基準を緩めたり、マーケティング側が知らないうちに条件を追加したりといった、非公式な変更が積み重なっていきます。CROとCMOが共同オーナーとなり、四半期に一度など定期的な見直しの場を持つことが、この問題を防ぐ最もシンプルな方法です。

MQL/SQL定義フレームワーク：合意形成の手順

ここまでの3つの論点を、実務でどう合意に落とし込むか。以下の手順で進めると、部門間の対立を最小化しながら定義を固められます。

ステップ	主担当	成果物
1. 行動データの棚卸し	マーケティング	過去半年〜1年の行動ログ一覧
2. 商談化した案件の逆引き分析	RevOps／セールスオペレーション	商談化リードの共通行動パターン
3. シグナルの組み合わせ定義	マーケティング＋営業リーダー	MQL/SQL基準の草案
4. 例外ルールの明文化	CRO・CMO	例外承認フロー
5. 運用テストと修正	現場全員	4〜6週間のトライアル結果

このステップを一気に進めようとすると、必ずどこかで議論が止まります。特にステップ3の「シグナルの組み合わせ定義」は、マーケティングと営業リーダーの双方が過去のデータを持ち寄る形で進めないと、感覚論の応酬になりがちです。合意形成の会議体では、以下のようなチェックリストを使って議論の抜け漏れを確認しておくと、後戻りを防げます。

• 行動データは直近何日間のものを有効とみなすか合意したか
• ICPと合致しないリードのMQL昇格を認めるか合意したか
• 例外承認の権限者と記録方法を明文化したか
• 定義の見直し時期をカレンダーに組み込んだか

ステップ1：行動データの棚卸しから始める

いきなり基準値を議論するのではなく、まず過去に実際に受注、あるいは少なくとも商談化に至った案件が、どのような行動履歴を辿っていたかを棚卸しします。例えば、資料請求後に価格ページを2回以上閲覧していた、導入事例を複数本読んでいた、といった行動の共通パターンを洗い出す作業です。この段階では「基準を決める」のではなく、「事実を集める」ことに徹するのがポイントです。

ステップ2：閾値ではなく「シグナルの組み合わせ」で定義する

行動データが集まったら、単一の閾値(スコア〇点以上、といった一次元の線引き)ではなく、複数シグナルの組み合わせで定義することをお勧めします。具体的には、「価格ページ閲覧」×「従業員規模がICP範囲内」×「直近30日以内の接触」といった複合条件です。単一閾値は説明がしやすい反面、境界線上のケースで営業とマーケの解釈が割れやすいという弱点があります。組み合わせ条件にしておくと、「なぜこのリードがMQLなのか」を営業側にも具体的に説明できます。

ステップ3：例外ルールを先に文書化しておく

前述の通り、例外は必ず発生します。だからこそ、例外が起きてから場当たり的に判断するのではなく、事前に「誰の承認があれば例外的にSQL化してよいか」「例外を適用した件数は誰がモニタリングするか」を文書化しておく必要があります。この文書がないまま運用を始めると、数か月後には例外が例外でなくなり、定義そのものが形骸化します。

MQLとSQLを顧客段階全体の中で定義する考え方は、次の記事で確認できます。

顧客段階の設計：リードから顧客までの定義をそろえる方法

RevOps・マーケ担当者向けに、リードからMQL・SQL・商談・顧客までの定義を部門間でそろえる方法を、5段階モデルと実装手順で解説します。

fordit.jp

2026.09.28

件数目標を後回しにすべき理由

冒頭で述べた通り、多くの組織がつまずくのは、この定義プロセスより先に「月間MQL件数◯件」「SQL転換率◯%」といった数値目標を確定させてしまうことです。

目標が先だと、定義がその数字に合わせて歪む

数値目標が先に決まっていると、定義を作る側には無意識のバイアスがかかります。目標件数に届きそうにない月には基準を緩め、逆に基準を厳しくすると営業からのクレームが減るとなれば、目標達成が苦しくなっても基準を戻さない、といった調整が起こりがちです。

これは担当者の能力や誠実さの問題ではなく、目標と定義が同じ会議体で同時に決まってしまう構造そのものの問題です。

「質」の合意なしに目標を追うと何が起きるか

例えば、MQL件数を前年比150%に引き上げるという目標だけが先行した結果、行動データの基準を大幅に緩和し、件数は達成したもののSQL転換率が半減した、というケースは珍しくありません。この場合、経営会議の場では「マーケが目標を達成した」という報告と、「営業の商談化率が悪化した」という報告が、あたかも別々の問題であるかのように扱われてしまいます。

しかし根本原因は同じで、定義の合意より件数目標を優先した結果です。CROとCMOが数字を見る前に、まず「基準の中身」を確認する習慣を持つことが、この構造的なズレを防ぐ第一歩になります。

定義合意後にKPIをどう設計するか

定義とその運用ルールが固まって初めて、件数目標やKPIの設計に進むべきです。

MQL→SQL転換率は「基準の健全性」を測る指標として使う

MQL数そのものを追うのではなく、MQLからSQLへの転換率を継続的にモニタリングすることをお勧めします。転換率が急に下がった場合、それは営業の対応力の問題である可能性もありますが、多くの場合はMQLの基準が緩みすぎているサインです。

逆に転換率が高すぎる場合は、基準が厳しすぎて機会損失を生んでいる可能性があります。転換率は営業を評価するための数字ではなく、定義そのものの健全性を測る温度計として扱うのが適切です。

営業が「これはSQLじゃない」と言えるフィードバックルートを作る

最後に、運用面で見落とされがちなのがフィードバックの経路です。営業担当者が「渡されたリードの質がおかしい」と感じたとき、それを個人の愚痴として終わらせず、定義改訂のプロセスに正式に接続できる仕組みが必要です。

例えば、SFA(営業支援システム)上でSQLを差し戻す際に理由コードを選択させ、そのデータを月次でマーケティングとRevOpsが確認する、といった仕組みです。この地道な接続がない限り、どれだけ精緻な定義を作っても、現場の実感とのズレは是正されないまま蓄積していきます。

目標からリード数・商談数を逆算する際の前提整理は、次の記事を参照してください。

売上目標から必要なリード・商談・受注を逆算する売上モデルの作り方

売上目標から必要な受注数・商談数・リード数を逆算する計算式を、仮想例で解説します。売上・受注・商談・リードの定義、期間とコホート、責任者をそろえ、CEO・CROが部門共通の行動KPIを試算するための実務手順を紹介します。

fordit.jp

2026.08.13

まとめ

MQLとSQLの定義が揉め続ける組織の多くは、件数目標を先に決め、定義を後から数字に合わせて調整するという順序で運用してきました。この順序を逆転させ、「関心」の判断根拠・例外の扱い・改訂権限という3つの論点を先に合意し、行動データの棚卸しから始まる5ステップで定義を固める。

この地道な手順を踏んだ組織だけが、件数目標を追いながらも営業とマーケの信頼関係を保つことができます。まずは次回の定例会議で、件数の話に入る前に「基準の中身」を議題に上げることから始めてみてください。

Q&A

専門用語解説

• MQL(Marketing Qualified Lead)：マーケティング活動を通じて一定の関心・条件を満たしたと判断されたリード
• SQL(Sales Qualified Lead)：営業がアプローチする価値があると判断した、商談化見込みの高いリード
• MA(マーケティングオートメーション)：見込み客の行動データを収集し、スコアリングや配信を自動化するツール
• ICP(理想的な顧客像)：自社の商品・サービスと最も相性が良く、成果につながりやすい顧客の属性像
• SFA(営業支援システム)：商談の進捗管理や顧客情報の記録を営業チームが行うためのシステム
• RevOps(レベニューオペレーション)：マーケティング・営業・カスタマーサクセスの収益プロセスを横断的に統括する機能
• 商談化率：マーケティングが供給したリードのうち、実際に商談として成立した割合