MQLの定義は自社で決める｜HubSpotとDynamics 365の公開文書で読む

MQL（Marketing Qualified Lead）に、業界で共通の定義はありません。ツールの中にあるのは既定値としての説明文で、そこに書かれているのは「誰が判断するか」までです。どの行動や属性をもって営業へ渡すのかは空欄のまま渡されます。だから「MQLの定義」を検索して出てくる他社の条件をそのまま写しても、自社では動きません。

この記事では、広く使われている2つのツールの公開ドキュメントを読みます。HubSpotのナレッジベースにあるライフサイクルステージの説明と、Microsoftが公開しているDynamics 365 Salesの営業プロセスの説明です。どちらも社外の誰でも読める文書で、段階の名前、段階が動く向き、段階を進めたときに実際に起きることが書かれています。確認日は2026年10月21日です。

読む順序は3つです。既定の説明文がどこまでを決めているか。段階が動く向きという仕様が、定義の書き方をどう縛るか。そして、同じ「引き渡し」という言葉が、2つの文書でまったく違うものを指していること。最後に、自社の定義書に書く項目と、どちらの文書にも書かれていない項目を分けます。リードを集める手段そのものはリード獲得の方法の側で扱っています。

既定の定義が決めているのは、判断する人だけ

HubSpotのナレッジベースは、連絡先と会社に付けるライフサイクルステージとして8つの段階を順番に並べ、1つずつ説明文を添えています。説明文の要点と、そこで「判断する」と書かれている主体を並べます。

段階（原文の表記）	説明文の要点	判断するとされている主体
Subscriber	ブログやニュースレターの登録で、続報を受け取ることに同意した連絡先	本人の申し込み
Lead	購読の登録より先の行動で、サイト上などで転換した連絡先・会社	本人の行動
Marketing Qualified Lead	営業チームへ渡せる状態だと、マーケティングチームが判断した相手	マーケティング
Sales Qualified Lead	見込み客になりうると営業チームが判断した相手	営業
Opportunity	取引（deal）に紐づいている相手	データの状態
Customer	成立した取引が1件以上ある相手	データの状態
Evangelist	自社を推薦してくれた顧客	記載なし
Other	上のどれにも当てはまらない相手	－

MQLの説明は「a contact or company that your marketing team has qualified as ready for the sales team」です。SQLは「a contact or company that your sales team has qualified as a potential customer」で、この段階の下位の区分は Lead Status というプロパティに持つと書かれています。

2つを並べると分かるのは、違いが判断する部署だけで書かれていることです。何回サイトを見たら、どの役職なら、どの業種なら渡せるのか。そうした条件は1つも書かれていません。書かれていないのは手抜きではなく、条件が会社ごとに違うからです。つまりこの説明文は、空欄のある書式として配られています。埋めるのは利用する側です。

一方、Opportunity と Customer の2段階だけは性質が違います。取引に紐づいているか、成立した取引が1件以上あるかというデータの状態で決まる段階で、人の判断が入りません。自社の定義を書くとき、人が決める段階とデータで決まる段階を混ぜないほうがよいのは、この並びを見ると分かります。混ぜると、会議で「この相手はOpportunityか」を議論することになります。

段階は前へしか動かない。この仕様が定義の書き方を縛る

もう1つのナレッジベースのページには、段階を自動で動かす設定が並んでいます。取引が作成されたとき、取引が受注で終わったとき、リードが紐づけられたとき。それぞれを個別に有効にできます。あわせて、連絡先の段階を、紐づいている主たる会社の段階に合わせる同期の設定もあります。

ここで重要なのは、同じページに書かれている制約です。これらの設定は段階の値を後ろへ戻さないと明記されています。Customer になっている連絡先は、新しい取引が作られても Opportunity へ下がりません。会社の段階が前の段階へ変わっても、すでに先へ進んでいる連絡先は引きずられません。同期の向きも一方向で、会社の変更は連絡先へ伝わりますが、連絡先の変更は会社へ伝わりません。

戻せないという仕様は、定義の書き方に直接はね返ります。「とりあえずMQLにしておく」が成り立ちません。迷ったら進めておく運用にすると、翌月には戻せない記録が積み上がり、MQLの件数が実態より多い状態で固定されます。件数が増えること自体は問題ではありませんが、そこを分母にした転換率は使えなくなります。

したがって自社の定義書には、進める条件と同じ分量で戻すときの手順を書く必要があります。誰が値を消すのか、消した事実をどこに残すのか、消す前に営業の同意を取るのか。ツールの説明文はこの点に触れていません。触れていない部分が、運用でいちばん荒れます。

もう一方の文書では、引き渡しはデータの変換として書かれている

Microsoftが公開しているDynamics 365 Salesの説明は、組み立てが違います。営業プロセスを Qualify・Develop・Propose・Close・Fulfill の5段階として並べ、各段階は特定のレコード種別に対応すると書いています。段階はプロパティの値ではなく、扱うデータの種類そのものです。

Qualify の段落には、購入の意思と決裁の力があると確かめたうえでリードを Qualify する、と書かれています。そしてこの操作は、リードを商談（opportunity）へ変換します。別のページでは、変換のときに何が起きるかがさらに細かく説明されています。設定によって、取引先・連絡先・商談のレコードが自動で作られるか、画面でひとつずつ選んで作ることになります。似た取引先や連絡先がすでにあるときは重複検知の画面が出て、新しく作るか既存を使うかを選びます。複数の商談を作れる設定を有効にしている場合は、1件のリードから最大5件の商談を作れると書かれています。

細かいようで効いてくる記述が2つあります。1つは、商談が作られなかった場合でもリードの状態は Qualified になり、しかし業務プロセスの流れは次の段階へ進まない、という注記です。もう1つは、商談が紐づいているリードは Disqualify できないという制約です。取り下げたいなら商談の側を先に片づける必要があります。取り下げたリードは後から再開でき、添付やメモも残ります。

その概要ページには、リードの選別を担う機能の説明もあります。調査だけを行うモードと、調査に加えて相手とやり取りまで行うモードの2つが並び、後者は見込みの薄い相手を外し、強い関心を示している相手だけを営業へ渡す、と書かれています。渡す前に絞る工程が製品の機能として置かれているという点では、前半で読んだMQLの考え方と同じ場所を指しています。ただし「強い関心」をどう測るのかは、ここでも書かれていません。

同じ「引き渡し」が、2つの文書で別のものを指している

2つの文書を同じ表に置くと、言葉のずれが見えます。

見る点	HubSpotのライフサイクルステージ	Dynamics 365 Salesの営業プロセス
段階の持ち方	連絡先・会社が持つプロパティの値	段階ごとに対応するレコードの種類
前へ動くとき	取引の作成・受注、リードの紐づけで自動更新できる	Qualify などの操作を実行したとき
後ろへ動くとき	既定の自動更新では戻らない	商談が紐づいていると Disqualify できない
引き渡しで起きること	プロパティの値が変わる	取引先・連絡先・商談のレコードが作られる
下位の区分	SQL の下を Lead Status プロパティで持つ	商談側の業務プロセスの流れで持つ

左の列では、引き渡しは記録の更新です。値が変わるだけなので、間違えたときの損害は小さく見えますが、既定の自動更新では戻らないため、誤りは手作業でしか消せません。右の列では、引き渡しはレコードの生成です。取引先と連絡先と商談が作られ、重複の判断がその場で求められます。間違えたときに消すものが増えるぶん、渡す前の確認が重くなります。

この違いを押さえておくと、社内の会議で起きるすれ違いの原因が1つ減ります。「MQLを営業に渡す」と言ったとき、プロパティを変える話をしている人と、商談を立てる話をしている人が同席していることがあります。どちらの意味で使っているのかを先に決めるほうが、条件の議論より先です。CRMとSFAで扱う対象が違う話はCRMとSFAの違いにまとめています。

自社の定義書に書く4つと、文書に無い4つ

ここまで読んだ5ページから、定義書に必要な項目と、文書が答えてくれない項目を分けられます。

空欄のうち、最初に手を付けられるのは判断の根拠です。根拠に使えるのは、自社が実際に記録できている行動と属性に限られます。資料のダウンロード、見積の依頼、価格ページの閲覧。どれを根拠にするかは、それが計測できていて、かつ流入元まで区別できているかで決まります。計測側の名前の付け方がばらばらだと、根拠にした行動が後から集計できません。計測の命名を文書にしている例はUTMパラメータの命名規則で読みました。

戻す手順については、ツールの仕様が決まっているので、決めるのは人の側だけです。値を消す権限を誰に持たせるか、消した履歴をどこに残すか、消す前に営業の確認を取るか。この3つを書いておかないと、戻す作業そのものが起きません。戻せない記録が増えると、MQLの件数は増え続け、そこから先の数字の意味が薄くなります。

引き渡しの実体については、渡す前に必ず埋める項目を決めます。会社名が空欄だと取引先を新規に作る選択ができない、という挙動が文書に書かれているため、どの項目が欠けていると引き渡し自体が成り立たないのかを先に洗い出せます。重複の扱いは、既存の相手とみなす基準と、その判断を誰がするかです。画面が出ることは文書に書かれていますが、どちらを選ぶべきかは書かれていません。

他社の定義をそのまま持ってくると外れるところ

最後に、輸入するときの注意を3つ挙げます。1つ目は、ツールに入っている8段階や5段階が業界の標準ではないことです。Microsoftの文書は、段階と用語は業種・販売戦略・商品・顧客の種類によって変わると明記しています。既定値はよくある形の1つで、自社の販売の形に合わなければ変えてよい、という前提で書かれています。

2つ目は、段階の数を増やすほど運用が丁寧になるわけではないことです。段階は、誰かがその値を更新しなければ動きません。更新の作業が増えれば、記録と実態のずれも増えます。前へしか動かない仕様とあわせて考えると、段階は少ないほど戻す作業も少なくなります。

3つ目は、定義を変えた日を記録しておくことです。しきい値や根拠を変えると、前後の件数は比べられなくなります。変えた日を残していないと、件数が動いた理由が施策なのか定義なのか分からなくなります。指標の定義をそろえて記録する手順はKPIレポートの作り方で扱っています。

なお、定義を決めれば成果が出るという話ではありません。定義は、同じ相手について同じ判断ができるようにするための道具です。効果は、根拠に選んだ行動が実際に購入につながっているかどうかと、その後の運用で決まります。

確認した範囲で分からなかったこと

今回読んだ5ページには、次の記載がありませんでした。埋めずに残します。スコアのしきい値、渡してから連絡するまでの時間の基準、MQLからSQLへの転換率の目標値、そして渡したリードを戻すときの判断者です。いずれも、ツールの側が決めるものではなく、利用する会社が決める前提になっています。

逆に、文書から確かに読み取れたのは次の点です。段階の説明文は判断する部署までしか決めていないこと。既定の自動更新では段階が後ろへ動かないこと。Qualify の操作は値の変更ではなくレコードの生成であること。商談が紐づいたリードは取り下げられないこと。この4つは、自社の定義書を書く前に押さえておく事実です。

始める順番としては、まず自社のツールがどちらの型なのかを確かめ、次に段階の数を決め、そのうえで判断の根拠と戻す手順を同じ文書に書きます。根拠を決めるのが最後なのは、記録できている行動が分かってからでないと、書いた条件が判定できないからです。マーケティングオートメーションとCRMの役割分担から整理したい場合はCRMとMAの違いが入口になります。

海外企業や海外のツールが公開している文書を読み解いた記事は海外マーケティングにまとめています。