MQL(マーケ判定リード)とは?8年運用してわかった『マーケ・営業責任分界点の正体』と運用の正解

『MQL』という言葉は、マーケティングやコンテンツビジネスの現場で頻繁に使われます。しかし、その正確な意味や設計の要点まで理解されているケースは多くありません。

株式会社Cameenです。本記事は当社の運用知見をもとに解説します。

BtoBマーケや高単価のオンライン教育、コンサル系の世界に入ると、MQLという言葉が当たり前のように飛び交います。「今月MQL何件取れた?」「MQLからの商談化率はいくつ?」「MQL定義を見直そう」、こういう会話がマーケと営業の定例で繰り返されます。

でも、いざ「MQLって具体的にどう定義してる?」「SQLとの境目はどこ?」「マーケ側が”はい渡しました”って言ってきたリード、なんでこんなに営業から塩対応されるの?」と聞かれると、答えに詰まる人がほとんどです。「見込み度が高いリード」という認識で止まって、MQLの本質的な役割まで言語化できている人は意外と少ない。こうした課題は、多くの事業者に共通します。

当社で運用してきた経験から見えてきたのは、MQLは単なる「見込み度判定」ではなく、「マーケと営業のあいだに引かれる責任分界点そのもの」だということ。MQL定義を明確にしないチームは、必ず「マーケは”渡した”と言うが、営業は”これは商談にならない”と言う」という不毛な押し付け合いを起こします。MQLは数を競う指標ではなく、責任の境界線を引くための運用ルールです。

もう1つ繰り返し見てきたのは、「MQLの数字だけ見て中身を見ない運用」が現場を疲弊させる事実。MQL月間500件、でも商談化率2%、こういう数字を出してしまうマーケチームは多いです。MQLは「件数」より「商談化率」のほうが本質。件数を追うほど、営業の信頼を失っていきます。

今回はその「今さら聞けないMQL」を、定義の建て付けから、マーケ・営業の責任分界設計、運用現場の本音まで一気に深掘りしていきます。読み終わる頃には、自社のMQL定義を紙に書き出して、営業に「これでいいか?」と擦り合わせができるレベルになっているはずです。

結論:MQLの核心は「見込み度」ではなく「マーケから営業への送り出し責任分界点」

MQLの本当の正体は、「マーケティング部門が事前に営業と合意したスコア・条件をクリアし、”今、営業がアプローチして良い”と判定された、送り出し責任が明示されたリード」のことです。リード単体の属性ではなく、マーケ・営業の合意の上に立つ「運用上の旗」です。

業界の体感として、MQL判定はスコアリング(行動・属性の点数化)と閾値設定の組み合わせで運用されます。例えば、資料DL3回 + 価格ページ閲覧 + 役職部長以上 + 従業員50名以上、こういう条件を満たしたリードをMQLと定義する。閾値はチームごとに異なり、唯一の正解はありません。

MQLより前の段階に「リード(Lead)」「ICP適合リード」「コンタクト」、後の段階に「SQL(営業有資格リード)」「商談」「受注」、こういう連続した送り出しフローがあります。MQLはこの中間に位置し、「マーケの責任が終わり、営業の責任が始まる」境界線です。

MQLの真の価値は数ではなく、「マーケと営業が同じ定義で同じものを見ている」状態にあります。良いMQL運用は「マーケ側が”これは渡せる”と判定したら、営業側が”わかった、アプローチする”と即動ける」関係を作る。お互いの責任が明確になり、押し付け合いが消える。これがMQL運用の本質的なリターンです。

なぜ「Marketing Qualified」と名付けられたのか

もう少し深く掘ります。なぜ「Marketing Qualified Lead」、つまり「マーケが資格認定したリード」と名付けられたのか。この命名には設計思想が込められています。

「Qualified」という英単語は、日本語で「資格を満たした」「条件をクリアした」という意味。単に「興味がある」「リードである」ではなく、事前に決めた基準を通過した、と明示する言葉です。誰が認定したのか、を頭に付けているのが特徴的で、Marketing Qualifiedは「マーケティング部門が認定責任を持つ」ことを宣言しています。

これに対応する形でSQL(Sales Qualified Lead)が存在します。SQLは「営業部門が認定責任を持つ」リードのこと。マーケがMQLとして渡し、営業がそれを受けて自分の目で確認し、「これは商談化できる」と判定したものがSQLになります。Qualifiedの前に部門名が付くことで、責任所在が明確になる構造です。

MQL/SQLの概念は、2000年代に米国のSiriusDecisions(現Forrester SiriusDecisions)が「Demand Waterfall」というフレームワークの中で整理したのが普及の起点です。それまで「リード(Lead)」「プロスペクト(Prospect)」「機会(Opportunity)」、こういう用語が混在していたものを、「誰が責任を持つか」の軸で再整理した功績は大きいです。

日本では、2010年以降のBtoBマーケ・SaaS市場の拡大と共にMQLという言葉が一般化しました。HubSpot、Marketo、Salesforce Pardot、こういうマーケティングオートメーションツールが日本に上陸し、MQL設定の機能が標準化されたことで、現場の運用語として定着しました。今では高単価BtoBや高単価オンライン教育、コンサル系の世界でほぼ共通言語です。

業界の体感として、MQL定義は「会社の戦略フェーズ」と「営業組織の成熟度」で大きく変わります。創業初期は「資料DL=MQL」というシンプルな定義で十分機能する。組織が拡大するとスコアリングが複雑化し、行動スコア×属性スコアの掛け合わせで判定する設計になっていく。MQL定義は固定ではなく、半年〜1年で見直す前提の運用ルールです。

近年は、MQL定義に「Intent Data(意図データ)」を組み込む動きが進んでいます。Bombora、6sense、こうしたツールを使って、自社サイト外での検索行動・競合サイト閲覧などをMQL判定に活用する設計です。MQLの定義は、技術進化と共にどんどん精緻化されている領域でもあります。

MQL判定の現場で何が起きているか

MQL判定の現場では、リード1件1件の頭の中、そして判定する側の頭の中で、こういうことが起きています。5段階で整理します。

ステージ1:認知の入口(リード化)

見込み客がブログ記事を読む、広告経由でLPに着地する、メルマガに登録する、こういう接点でリード化します。この段階では「軽い興味」レベル。営業されたい気持ちはまだなく、情報収集している段階です。

リード側の頭の中は「ちょっと面白そうだから資料を見てみよう」「無料セミナーなら参加しても良い」「自社で使えるか検討するために情報を集めたい」、この程度の温度感。MQLにはまだ程遠いステージです。

ステージ2:関心の深まり(行動の累積)

リードが資料を複数回DLする、価格ページを閲覧する、導入事例を読み込む、ウェビナーに参加する、こういう行動が累積していきます。マーケティングオートメーションツールがこの行動を全部スコアリングします。

リード側の頭の中は「これ、自社で使えるかも」「他のツールと比較したいから事例を見たい」「価格感を把握しておきたい」、こういう検討モードに入ります。まだ営業されたいわけではないが、情報の濃度が上がっていく段階です。

ステージ3:MQL判定の閾値到達

スコアリングの合計値が、事前に設定したMQL閾値(例:100点)を超えた瞬間、マーケティングオートメーションツールが自動的にMQLフラグを立てます。判定の裏側では、行動スコア(価格ページ閲覧=20点・資料DL=10点等)と属性スコア(役職部長=15点・従業員50名以上=10点等)が合算されます。

マーケ担当の頭の中は「閾値超えた、これは”営業に渡せる”。営業との合意の通り、Salesforceに送ろう」。スコアリングの中身を1件ずつ目視確認することはなく、運用ルールが正しく組まれていれば自動化フローで送り出されます。

ステージ4:営業への送り出しと初動アプローチ

MQLフラグが立つと、CRMに自動連携され、営業に通知が飛びます。良い運用なら、MQL発生から24時間以内に営業の初動アプローチが入ります。これより遅いと、リード側の「今、見てた」温度感が冷めてしまうからです。

営業側の頭の中は「マーケから来たMQL、属性と行動履歴を確認して、コンタクトの取り方を決めよう」。電話か、メールか、ABM経由か、リードの属性と行動履歴で初動の手段が変わります。リードが価格ページ閲覧履歴ありなら直接電話、ウェビナー参加だけなら丁寧なメール、こういう判断です。

ステージ5:SQL転換または差し戻し

営業が実際にコンタクトを取り、ヒアリングした上で、「これは商談化できる」と判定したらSQLに昇格、「まだ早い」と判定したらマーケに差し戻し、「ICPから外れる」と判定したらクローズ、こういう判定が入ります。MQL→SQL転換率がマーケ品質の最重要指標です。

営業側の頭の中は「マーケが渡してきたが、ヒアリングの結果、課題感が弱い。もう少しナーチャリングしてから再度送ってほしい」「課題感も予算感も明確、これはSQLに進める」、こういう生の判定が走ります。MQLは送り出しの旗、SQLは商談確度の旗、というふうに役割が分かれます。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

結婚相談所のお見合いセッティングに置き換えてみます。あなたが結婚相談所の会員で、運営側があなたに「こちらの方、お見合いしませんか?」と紹介してくる場面を想像してください。

運営側はあなたのプロフィール、希望条件、過去のお見合い履歴を把握しています。同時に、相手側のプロフィール、希望条件、過去履歴も把握している。両者の条件を突き合わせて「これはマッチする可能性が高い」と判断した時点で、紹介が走ります。これがMQL判定とほぼ同じ構造です。

運営側が「とにかく紹介の数を増やせ」という運用にすると何が起きるか。マッチ度の低いお見合いが大量に走り、あなたも相手も時間を浪費し、最終的に「この相談所、紹介がいい加減」という不信感が積み上がります。会員(あなた)側は紹介を受けるたびに労力を払うので、ハズレ紹介が続くと「次の紹介は受けたくない」になる。

これ、まんまMQLとマーケ・営業の関係です。マーケが「MQLの件数」だけ追い始めると、低品質MQLを大量に営業に渡してしまう。営業はそれを1件1件捌くので、ハズレが続くと「マーケから来るMQL、もう触りたくない」になります。マーケ・営業の関係が壊れる典型パターンです。

逆に、結婚相談所が「紹介の精度を最重要視」する運用に切り替えると、紹介件数は減るが1件あたりのマッチ度が上がり、会員からの信頼が回復する。同じことがMQL運用でも起きます。件数より精度、これがMQL運用の鉄則です。

もう1つ、結婚相談所のたとえで重要なのが「紹介する側と紹介される側の合意」です。事前に「こういう条件を満たした方を紹介します」「こういう方は紹介しません」という擦り合わせが終わっていれば、後の苦情は出ません。MQL運用も同じで、マーケと営業のあいだで「こういう条件を満たしたらMQLとして送ります」「こういう条件は送りません」という事前合意があれば、運用が滑らかに回ります。

事前合意なしに紹介を始めると、紹介された側(営業)は「なんでこんなのを紹介してくるんだ」とフラストレーションが溜まる。MQL運用がうまくいかないチームは、ほぼ全部「マーケと営業のあいだの事前合意が曖昧」という共通原因を抱えています。

MQL設計の4要素と組み立て方

4要素の組み立てで重要なのは、最初から完璧を狙わないこと。最初は粗い設計でも構わないので、3ヶ月運用して結果を見て、配点と閾値を見直すのが王道です。最初から100点満点の設計を作ろうとすると、運用が始まらないまま設計議論で時間が溶けます。「動かしながら直す」のがMQL設計の鉄則です。

もう1つの設計の肝は、配点を「全行動を網羅する」より「重要行動に偏らせる」こと。価格ページ閲覧・無料トライアル登録・導入事例DL、こういう「購入検討の核心行動」に高配点を集中させ、それ以外の軽い行動は低配点にする。網羅型のスコア設計は、結局ノイズが多くなって判定精度が落ちます。

MQL運用で機能しない典型3パターン

当社で運用してきた経験と、業界の事例観察で見えてくる、MQL運用が機能しない典型パターンはこの3つに集約されます。

当社で運用してわかった本音

株式会社Cameenでマーケ・営業の責任分界設計を運用してきて、わかった本音をお伝えします。マーケと営業のあいだの線引きは、教科書通りにはいかない領域です。

本音1:MQLは「数字」ではなく「マーケと営業の合意文書」そのもの

当社で運用していて一番効いた学びは、「MQLの実態は数字やスコアじゃなくて、マーケと営業のあいだに引いた合意文書そのもの」ということ。スコアリング設計より、その設計が「営業と本気で擦り合わせた結果か」のほうが圧倒的に重要です。

合意文書には「こういう条件を満たしたらMQLにする」「こういうリードは送らない」「営業はMQLが届いたら24時間以内に動く」「営業から差し戻されたMQLはマーケがナーチャリングを継続する」、こういう運用ルールが書かれます。この文書がチームに浸透している組織は、MQL運用が安定します。文書がない組織は、何度設計を直しても安定しません。

本音2:MQLの「差し戻し率」を見ると組織の健康度がわかる

MQLを送ったあと、営業から「これはSQLにならない」と差し戻される率が30%を超えていたら、組織が不健康な状態です。MQL定義が営業の現場感とズレている、または営業が「マーケの送るMQLは信用できない」という不信モードに入っている。

当社で運用しているKPIで一番見ているのは、MQL→SQL転換率と差し戻し理由の内訳です。差し戻しの内訳が「ICPから外れる」が多ければ属性スコア設計を見直す、「タイミングが早い」が多ければナーチャリング期間の追加、「課題感が弱い」が多ければ獲得チャネルの見直し、こういう運用判断を回します。差し戻し率は、組織の健康度を測る最重要指標です。

本音3:MQL設計は「半年で見直す」前提で組む

これは現場運用してきた中で一番痛感している本音ですが、MQL定義は半年〜1年で必ず見直しが必要です。市場が変わる、商材が変わる、営業組織が変わる、こういう変化があるたびに、過去のMQL定義は陳腐化します。完成形を作って固定しようとすると、運用が形骸化していきます。

具体的に、見直しのトリガーは5つ。(1)商材ラインナップが変わった、(2)主要獲得チャネルが変わった(広告比率の急増等)、(3)営業組織が拡大した、(4)ICPが変わった、(5)MQL→SQL転換率が前期比10ポイント以上下がった。1つでも該当したら、MQL定義の全面見直しを開始します。

見直しの場の作り方も重要で、「マーケ・営業・カスタマーサクセス」の3者が同じ会議に座って議論するのが理想です。マーケと営業だけだと「マーケが営業に合わせる」「営業がマーケに譲る」、こういう力関係に振られがちで、本質的な議論が進みません。カスタマーサクセスが「成約後にどうなっているか」のデータを持ってくることで、議論が立体的になります。MQL設計は3部門の合議で組むのが、長期視点での最適解です。

もう一つ、MQL運用の隠れた本音として、「MQLを廃止した先進事例も出てきている」点があります。米国のフルファネル型マーケ組織では、MQL/SQLの区別をなくして「アカウント単位の成熟度スコア」だけで運用するチームも増えています。MQLが向く組織と向かない組織がある、ということも頭に入れておくべきです。固定的に「MQLが必須」と思い込まず、自社の組織と商材に合うかを判断してください。

リード→MQL→SQL→商談→受注のSTEP

ここまで読んでくださった方、お疲れさまです。リード獲得から受注までの全体フローを5ステップで置いておきます。

MQLは、この長いフローの中間に位置する「マーケ→営業の引き渡しポイント」です。ここでの引き渡し品質が、後続の商談化率・受注率にすべて連鎖します。MQL設計を軽視すると、フロー全体が機能しなくなります。

よくある質問(FAQ)

まとめ

では、結局MQLとは、こういうことです。

• MQLの核心は「見込み度の高いリード」ではなく「マーケから営業への送り出し責任分界点」
• 本質は件数ではなく、マーケと営業の合意文書とその運用
• 4要素(行動スコア・属性スコア・チャネル品質・タイミング)を掛け合わせて設計し、半年で見直す

数字を追いかけるのではなく、マーケと営業の責任の境界線を引くこと。これがMQLの本来の役割です。導入を検討しているなら、自社のマーケ・営業の関係を整理するところから始めてみてください。