「リードは増えているのに営業が動かない」「渡したリードの質が低いと言われる」——こうした摩擦の多くは、MQL（Marketing Qualified Lead）の定義を曖昧なまま運用に乗せてしまったことに起因します。基準が言語化されていなければ、営業側には「マーケが勝手に決めた点数」としか映りません。
MQLとは、マーケティング部門が「営業がアプローチする価値がある」と判断したリードのことです。重要なのはスコアの計算式そのものではなく、その閾値を営業と合意し、引き渡し後のアクションまで含めて運用ルールとして固定できているかにあります。
本記事では、HubSpotでMQLを定義・設定するための手順を、2025年に刷新されたリードスコアリングツールの仕様に沿って解説します。MA導入直後の担当者と、旧スコアプロパティの廃止に伴って設定を組み直す必要が生じた担当者の双方を対象としています。
目次
MQLとは何か——定義と役割をおさらいする
MQLとSQLの違いは「誰が判断するか」にあります。この線引きを明文化することが、部門間の摩擦を減らす出発点です。
MQL（Marketing Qualified Lead）とは、マーケティング活動で獲得したリードのうち、一定の関心度と属性条件を満たし、営業がアプローチする価値があると判断されたリードを指します。リード全体に対するスクリーニング役を担う概念です。
BtoBのリードには、資料をダウンロードした直後の温度が低いリードから、価格ページを繰り返し閲覧している検討段階のリードまで、状態の異なる対象が混在しています。MQLはその中間フィルターとして機能し、「まだ早すぎる」リードを営業に流さないための仕組みです。
隣接する概念を整理すると、次のようになります。
- リード（Lead）：氏名・メールアドレスなどを取得したすべての接触者
- MQL：マーケティングが「営業に渡す価値あり」と判断したリード
- SQL（Sales Qualified Lead）：営業が「商談化できる」と判断したリード
- 商談（Opportunity）：提案・見積もりフェーズに入ったリード
MQLとSQLの違いは判断主体にあります。MQLはマーケティングが判断し、SQLは営業が判断します。両者の定義と境界の考え方はMQLとSQLの定義・設計方法で詳しく整理していますので、ファネル全体の設計から見直す場合はあわせてご覧ください。
MQLの定義を作る作業は、点数表を作る作業ではなく「営業が動く条件」を営業と一緒に決める作業です。ここを取り違えると、設定が完了しても運用が回りません。
MQLの定義はスコアリング・ワークフロー・レポートのすべてに波及します。関連する設定を一続きの流れとして把握したい場合は、HubSpot活用の全体像をあわせてご覧ください。
HubSpotにおけるMQL設定の全体構造
HubSpotでのMQL運用は「リードスコアリング」「ライフサイクルステージ」「ワークフロー」の3つを連動させて実現します。
それぞれの役割は次のとおりです。
- リードスコアリング：行動と属性に応じてポイントを自動付与し、スコアプロパティーに値を格納する機能
- ライフサイクルステージ：リード → MQL → SQL → 顧客 といった段階を管理するプロパティー
- ワークフロー：スコアが閾値を超えたときにライフサイクルステージを更新し、営業に通知する自動化ロジック
この3つを組み合わせることで、「スコアが一定値を超えたコンタクトを自動的にMQLへ昇格させ、担当営業に通知する」というフローが成立します。逆に言えば、スコアリングだけを設定してもMQLの運用にはなりません。ステージ更新と通知までを一本の流れとして設計する必要があります。
ライフサイクルステージには、登録読者・リード・MQL・SQL・商談・顧客・エバンジェリスト・その他といったデフォルトのステージが用意されており、MQLは標準の選択肢として最初から存在します。加えて現在は、設定画面からカスタムステージの追加やステージ順序の変更も可能になっているため、自社の商談プロセスに合わせて段階を増やす選択肢もあります。ただし段階を増やすほどレポートの解釈と運用ルールが複雑になるため、立ち上げ期はデフォルト構成のまま運用することをおすすめします。
MQL定義の設計：スコアリング基準をどう決めるか
スコアリングは「適合（属性）」と「エンゲージメント（行動）」の2軸で設計します。HubSpotの現行ツールもこの2軸を前提とした構造になっています。
MQL定義の核心は「どのリードを営業に渡すか」を数値化することです。判定に使う条件は大きく2種類に分かれます。
適合スコア（属性の条件）
企業規模・業種・役職・所在地といったプロパティー値から、自社のICP（理想顧客プロファイル）にどれだけ合致しているかを評価します。ICPが言語化されていないとこの軸は設計できないため、先にICPの設定方法を固めておくと設計が早く進みます。
エンゲージメントスコア（行動の条件）
ページ閲覧、フォーム送信、メール開封、ミーティング予約といった行動に対して点数を付与します。点数設計では、各行動の「購買意欲との相関の強さ」を相対的に反映させることが重要です。
| 軸 | 条件の例 | 点数の考え方 |
|---|---|---|
| エンゲージメント | 価格ページ・デモ申し込みページの閲覧 | 最も高く配点 |
| エンゲージメント | ウェビナー参加・事例ページ閲覧 | 中程度に配点 |
| エンゲージメント | メール開封（1回） | 最も低く配点 |
| 適合 | 従業員数・業種がICPに合致 | 高く配点 |
| 適合 | 役職がマネージャー以上 | 中程度に配点 |
| 適合 | 競合他社ドメイン・提供対象外エリア | 減点 |
点数の絶対値よりも、行動間の重み付けの相対関係が精度を左右します。「価格ページ閲覧がメール開封と同じ点数」という設計では、判定の解像度が落ちます。個々の条件の作り込み方や具体的な配点例はHubSpotリードスコアリングの設定方法で扱っているため、本記事ではMQL判定に必要な範囲に絞ります。
MQL閾値（スコアの合格ライン）の決め方
閾値は理論値ではなく、過去データから逆算するのが基本です。手順は次の3ステップです。
- 過去12ヶ月で商談化したリードのスコア分布を確認する
- 商談化率が明確に高くなるスコア帯を特定し、その下限を閾値の候補にする
- 設定後3ヶ月運用し、MQL→SQL転換率をモニタリングして調整する
過去データがない導入初期は、閾値を低めに置いて運用データを蓄積することを優先してください。初期精度にこだわりすぎると、判断材料そのものが集まりません。閾値の妥当性を測る指標についてはBtoBの商談化率の考え方もあわせて参考になります。
HubSpotでのMQL設定手順（ステップバイステップ）
スコアの作成からワークフローによる自動昇格、営業への通知までを順に設定します。スコアリング機能は2025年に刷新されているため、旧仕様の手順とは操作画面が異なります。
Step 1：リードスコアを作成する
現在のHubSpotでは、スコアリングは「マーケティング → リードスコアリング」の独立したツールとして提供されています。作成できるスコアはエンゲージメントスコア、適合スコア、両者を組み合わせた複合スコアの3タイプで、対象オブジェクトはコンタクト・会社・取引です。MQL判定に使うのは通常、コンタクトの複合スコアです。
設計上、押さえておくべき仕様は次の3点です。
- スコアグループと上限：条件はグループ単位で管理し、グループごとに上限ポイントを設定できます。認知段階のイベント群に上限をかけ、コンバージョン系イベント群に厚く配点する、といった重み付けが可能です
- スコア減衰：エンゲージメント系のグループでは、イベント発生からの経過時間に応じてスコアを自動的に減らす設定ができます。減衰間隔は1・3・6・12か月から選択でき、過去データにも遡及して適用されます
- しきい値ラベル：エンゲージメントスコアと適合スコアには高・中・低のラベル、複合スコアにはA1〜C3のラベルを設定できます。文字が適合度、数字がエンゲージメント度を表します
複合スコアのラベル体系は、MQL運用と特に相性が良い部分です。「適合度は高いが行動が伴わないC1相当のリード」と「行動は活発だが適合度が低いA3相当のリード」を、同じ総合点として扱わずに切り分けられるためです。
従来の「HubSpotスコア」プロパティーは2025年8月31日をもって廃止されています。旧仕様の手順を解説した情報を参照して設定しようとしても、該当する画面は存在しません。
Step 2：ライフサイクルステージの運用ルールを決める
ライフサイクルステージはコンタクトのプロパティーとして管理されます。運用設計上、最も影響が大きい仕様はデフォルトの自動更新がステージを次の段階に進める方向にのみ働く点です。SQLになったコンタクトを自動的にMQLへ戻すことは想定されていないため、失注後の再ナーチャリングをどう扱うかを事前に決めておく必要があります。
実務上の選択肢は2つです。ひとつは、ステージを戻さずに別プロパティー（例：再アプローチ対象フラグ）で管理する方法。もうひとつは、掘り起こし用のカスタムステージを追加して明示的に扱う方法です。レポートの整合性を優先するなら前者、営業とマーケの共通言語を優先するなら後者が向きます。休眠リードの扱い方は休眠リードの掘り起こし設計で別途整理しています。
Step 3：ワークフローでMQL昇格を自動化する
「自動化 → ワークフロー → 新規作成」から、スコアプロパティーを登録条件に使ってステージ更新を自動化します。基本形は次の構成です。
- 登録条件：スコアプロパティーの値が閾値以上、かつライフサイクルステージが「リード」である
- アクション①：ライフサイクルステージを「MQL」に更新
- アクション②：担当営業またはSlackチャンネルへ通知
- アクション③（任意）：担当者の自動アサイン
「ライフサイクルステージがリードである」という条件を必ず入れてください。これがないと、すでにSQLや商談まで進んだコンタクトが登録条件に合致し、意図しない挙動の原因になります。ワークフロー全体の設計思想についてはHubSpotワークフロー設計の基本を参照してください。
Step 4：営業への通知・引き渡しフローを設定する
MQL発生時の通知設計は、連携品質を直接左右します。ワークフロー内で設定できる主な通知手段は次のとおりです。
- HubSpot内通知（担当ユーザーへのタスク生成）
- メール通知（営業担当者のアドレスへ自動送信）
- Slack連携（専用チャンネルへの投稿）
通知内容には「コンタクト名・会社名・スコア・直近の行動」を含めます。特に最後の「何をしたからMQLになったか」が抜けると、営業は文脈のない状態で架電することになり、結果的に「質が低い」という評価につながります。営業側の受け取り方まで含めた設計はSales HubのBtoB活用で扱っています。
設定の順序や初期構築でつまずきやすい点はHubSpot初期設定チェックリストにまとめています。自社での設計に迷う段階であれば、MQL定義の設計についてご相談いただくことも可能です。
旧スコアプロパティーからの移行でMQL定義を作り直す手順
旧スコアの条件をそのまま新ツールに移し替えるのは得策ではありません。移行はMQL定義を再設計する機会として扱うべきです。
旧スコアプロパティーは2025年5月1日以降は新規作成不可、7月1日以降は編集不可となり、8月31日をもって廃止されました。すでに稼働していたアカウントでは、旧スコアを参照していたワークフローやリストが意図した動きをしなくなっている可能性があります。まず確認すべきは、MQL昇格ワークフローの登録条件がどのプロパティーを見ているかです。
新旧の設計思想の違いは次のとおりです。
| 観点 | 旧スコアプロパティー | 現行のリードスコアリング |
|---|---|---|
| 提供形態 | プロパティー設定内の機能 | 独立したツール |
| スコアの分割 | 1つのプロパティーに集約 | 適合／エンゲージメント／複合 |
| 配点の制御 | 条件ごとの加減点のみ | グループ単位の上限設定が可能 |
| 時間的減衰 | 個別のルール設計で代替 | 減衰機能を標準搭載 |
| 分類 | 数値のみ | しきい値ラベルで自動分類 |
移行時に推奨する進め方は3ステップです。第一に、旧スコアで「実際に商談化に効いていた条件」と「点数は入っていたが商談化と無相関だった条件」を分けます。第二に、後者を思い切って削り、前者だけで新スコアを組み直します。第三に、有効化する前にスコア分布をプレビューし、想定したボリュームのMQLが発生するかを確認します。
移行を単なる作業として処理すると、機能していなかった条件がそのまま新環境に持ち越されます。旧スコアが数年運用されていた組織ほど、この棚卸しの価値は大きくなります。
AIによるスコア作成はMarketing Hub Enterpriseのみの機能で、転換済み25件と未転換25件を含む最低50件のコンタクトが必要です。データ量が少ない段階では手動ルールでの設計を前提にしてください。
マーケとセールスのSLA：MQL定義を組織に定着させる
スコアリング設定だけでは運用は定着しません。MQLをめぐる両部門の合意をSLAとして文書化することが必要です。
SLA（Service Level Agreement）とは、マーケティングとセールスが互いに果たすべき責任を明文化した合意文書です。MQL運用において含めるべき項目は次のとおりです。
- MQLの定義：スコアリング条件と閾値の明記
- マーケの責任：月次のMQL供給数目標、条件の定期見直し
- セールスの責任：受け取り後のファーストアクション期限（例：24時間以内の初回コンタクト）
- SQL定義：営業がMQLをアクセプトする基準
- フィードバックサイクル：月次のMQL品質レビュー会議
スコアリング設定がどれほど精緻でも、受け取った営業が翌週まで動かなければ施策全体の効果は失われます。逆に、SLAでファーストアクション期限が定義されていれば、MQLの質に関する議論もデータに基づいて行えるようになります。部門間の連携設計そのものについてはマーケティングとセールスの連携の仕組み作りとインサイドセールスとの連携設計で詳しく扱っています。
SLA策定後は、「MQL発生件数」「MQL→SQL転換率」「ファーストアクションまでのリードタイム」をダッシュボードで定期モニタリングする体制を作ってください。可視化の設計方法はBtoBマーケのKPIダッシュボード設計を参考にできます。
MQL設定でよくある失敗と回避策
MQL設計でつまずくパターンは概ね決まっています。事前に把握しておくことで、設定後の修正コストを減らせます。
失敗①：行動スコアだけで設計してしまう
「資料を頻繁にダウンロードする人＝MQL」という設計は、適合度を無視しています。学生・求職者・競合の調査担当者も、行動だけなら高得点になり得ます。適合条件と組み合わせて、フィット度を必ず担保してください。
失敗②：スコアを設定して終わりにする
条件は「設定した時点が最適」ではありません。製品・ターゲット・市場の変化に伴い、有効な条件も変わります。少なくとも四半期に1度はMQL→SQL転換率を確認し、低下していれば条件を見直す運用にしてください。
失敗③：営業との合意なしにMQLを流し始める
基準を知らされていない営業がリードを受け取ると、「質が低い」という印象が先に定着し、以降の通知が無視されるようになります。一度そうなると回復には相当の時間がかかります。SLA策定と基準の説明は、運用開始前に必ず実施してください。
失敗④：減点条件を設定しない
競合ドメインからの接触者や、長期間エンゲージメントのないリードを除外しないと、MQLの中に不適切なリードが混入します。現行ツールでは条件ごとに加点と減点を選択でき、減点が上回ればスコアはマイナスにもなります。除外の設計はスコアリング精度の前提条件です。
ナーチャリング側の失敗パターンとあわせて確認したい場合はリードナーチャリングが失敗する理由もご覧ください。運用が回り始めない状態が続いているなら、現状の設定を前提にした改善のご相談も承っています。
HubSpotでのMQL定義・設定のまとめ
本記事のポイントを整理します。
- MQLは「マーケティングが営業に渡す価値があると判断したリード」であり、SQLとは判断主体が異なる
- HubSpotでのMQL運用は、リードスコアリング・ライフサイクルステージ・ワークフローの3点セットで成立する
- スコアリング機能は2025年に刷新されており、旧スコアプロパティーを前提とした手順はすでに機能しない
- 閾値は理論値ではなく、商談化データから逆算して決め、転換率で妥当性を検証する
- SLAで両部門の責任範囲を明文化しなければ、設定が完璧でも運用は定着しない
MQLの定義と設定は、施策の効果測定精度を高め、営業との連携品質を左右する基盤です。ファネル全体の中での位置づけを確認したい場合はBtoBファネル設計のやり方、判定後のレポーティングを設計したい場合はHubSpotレポート設計もあわせて参照してください。
無料相談受付中
MQLの定義が営業に受け入れられていない、と感じていませんか
スコアリング条件の再設計から、ライフサイクルステージの運用ルール、営業との引き渡しSLAの策定まで、実装レベルで伴走します。旧スコアからの移行が止まっているケースのご相談も承っています。
よくある質問（FAQ）
- HubSpotのMQL設定はどのプランから使えますか？
- ライフサイクルステージの手動管理およびワークフロー以外での運用は幅広いプランで可能ですが、リードスコアリングツールはMarketing HubまたはSales HubのProfessional・Enterpriseが対象です。AIによるスコア作成はMarketing Hub Enterpriseのみとなります。最新の提供条件はHubSpot公式のナレッジベースでご確認ください。
- MQLの閾値は何点に設定すればよいですか？
- 業種・商材・ターゲット規模によって最適値は異なるため、一律の推奨値はありません。重要なのは絶対値ではなく、設定後にMQL→SQL転換率で妥当性を検証することです。過去データがない場合は低めの閾値から始め、3ヶ月程度の運用データをもとに調整してください。
- 従来の「HubSpotスコア」で組んだ設定はどうなりますか？
- 旧スコアプロパティーは2025年8月31日に廃止され、更新されなくなっています。旧スコアを参照していたワークフローやリストは意図した動作をしなくなるため、現行のリードスコアリングツールで新たにスコアを作成し、登録条件を差し替える必要があります。移行は条件の棚卸しを兼ねて行うことをおすすめします。
- MQLとSQLの定義は誰が決めるべきですか？
- マーケティングとセールスの両部門が合意した上で決めることが前提です。マーケティング側だけで決めた定義は、営業側に「質が低い」と判断されるリスクが高くなります。SLA策定の場を設け、双方の基準をすり合わせてください。
- スコアを設定しても点数が更新されません。原因は何ですか？
- 条件に指定したプロパティーやイベントがそのコンタクトに紐付いていないケース、フィルター条件の論理設定が意図と異なっているケースが代表的です。同一プロパティーに複数条件を設定した場合はANDロジックとなり、すべてを満たさないとスコアが更新されない点にも注意してください。有効化前にレコードのテスト機能でスコアの内訳を確認すると切り分けが早くなります。