HubSpotでリードが商談になるまでを測るには、まず「商談になった日」をライフサイクルステージの「商談」に入った日とするか、取引の作成日とするかを決めます。そのうえで、リードになった月ごとに対象をまとめ、その後に商談へ進んだ割合と、進むまでにかかった日数を追います。ファネルレポートの数字を読む際は、途中の段階を飛ばしたコンタクトと、営業の更新漏れを分けて調べる必要があります。
HubSpotを使い続けてリードが蓄積されても、商談化率をそのまま施策の評価に使えるとは限りません。今月のリード数と今月の商談数では対象が違い、営業が商談を進めていてもステージが更新されていなければ、レポートには反映されないためです。
先にそろえたいのは、レポートの見た目ではなく、何を、誰を、いつまで追って数えるかです。ここがそろうと、数字が低い理由を「リードの質」「営業への引き渡し」「商談の進め方」「記録の不足」に分けて考えやすくなります。
測り始める前に、何を決めればよいか？
Step.1：「商談になった日」を決める
商談化を数える日付には、主に次の選択肢があります。
| 数える日付 | この定義で見たいこと | 先に調べること |
|---|---|---|
| ライフサイクルステージの「商談」に入った日 | リードが顧客になるまでの進み方 | 商談へ移す条件と更新方法がそろっているか |
| 取引を作成した日 | 取引として登録された時点までの進み方 | 取引を作成するタイミングと、コンタクトとの関連付けがそろっているか |
どちらを選んでも、社内で「商談」と呼んでいる状態と合っている必要があります。営業が初回の打ち合わせ前に取引を作る場合と、案件として進める判断をしたあとに作る場合では、取引の作成日が表す意味は異なります。
HubSpotでは、取引の設定でライフサイクルステージの同期をオンにすると、取引の作成時に関連するコンタクトと会社のステージが「商談」に、受注時に「顧客」に変わります。ただし、ステージを後ろへ戻す更新は行われません。すでに「顧客」のコンタクトに取引を作っても、「商談」には戻りません。
そのため、同期を使っているからといって、取引の作成日と商談ステージに入った日を無条件に同じものとして扱わないようにします。新規リードの商談化と、既存顧客の追加の取引は分けて集計したほうが、数字の意味が明確になります。
Step.2：コンタクト数と取引数を混ぜない
リードの商談化率を測るなら、分母と分子の単位をそろえます。
-
分母：対象となるリードのコンタクト数
-
分子：その対象のうち、商談になったコンタクト数
取引の作成日を使う場合も、リードの商談化率として見るなら「取引が作られた対象コンタクト」を数えます。取引の件数をそのまま分子にすると、コンタクト数を分母にした割合とは別の指標になります。
社内の集計ルールには、次のように残しておくと判断に迷いません。
> リードになった月ごとにコンタクトをまとめ、そのうち集計日までに商談になったコンタクトの割合を測る。商談になった日は、ライフサイクルステージの「商談」に入った日を使う。
取引の作成日を採用するなら、最後の一文を置き換えます。レポート名や集計表にも定義を添え、月によって数え方が変わらないようにします。
Step.3：ステージを移す条件と更新担当をそろえる
リード、MQL、SQL、商談の境目が担当者によって違うと、転換率が変わっても、その理由を読み取れません。
条件だけでなく、誰が、どのタイミングで記録するかまで決めます。
| 項目 | 決めておく内容 |
|---|---|
| リードになる条件 | どの接点を得た時点から測定対象にするか |
| MQLになる条件 | 営業へ渡す対象として、何を満たす必要があるか |
| SQLになる条件 | 営業がどの情報を得たら、次へ進めると判断するか |
| 商談になる条件 | どの状態を案件として数えるか |
| 更新担当 | 自動更新と手作業のどちらで、誰が記録するか |
| 次の段階に進まなかった場合 | 対象外、連絡がつかない、時期が合わないなどをどう残すか |
条件を変更した場合は、変更日も記録します。変更前後の転換率の差には、施策だけでなく、判定条件の違いが含まれるためです。
同じ月のリード数と商談数で割ると、なぜずれるのか？
分母と分子が別の集団になる
商談化率の式は、次のとおりです。
商談化率＝対象リードのうち商談になったコンタクト数÷対象リード数×100
注意したいのは、「対象リードのうち」という部分です。
今月の商談には、先月以前に獲得したリードが含まれます。一方、今月入ったリードには、これから営業が対応する人もいます。「今月の商談数÷今月のリード数」では、この異なる集団を割ることになります。
この計算が月ごとの活動量を見る参考になる場合はあっても、「今月獲得したリードの何％が商談になったか」への答えにはなりません。
リードになった月ごとに、その後を追う
リードの質や獲得施策を比べたいときは、リードになった月ごとに対象をまとめます。このように、同じ時期に入った対象をひとまとまりで追う考え方をコホートと呼びます。
例えば、説明用の架空の数字として、ある月にリードになったコンタクトが100件あり、その月末までに10件、翌月末までに累計20件が商談になったとします。この集団の商談化率は、その月末時点では10％、翌月末時点では20％です。翌月に商談になった分も、元のリードになった月にひも付けて扱います。
集計表には、少なくとも次の項目を置きます。
| 項目 | 記録する内容 |
|---|---|
| リードになった月 | どの月のリードを追っているか |
| 対象リード数 | その月にリードになったコンタクト数 |
| 商談化したコンタクト数 | 対象リードのうち、集計日までに商談になった数 |
| 商談化率 | 上記の件数から求めた割合 |
| 集計日 | いつまでの進捗を含めたか |
| 観察期間 | リードになってから、どれだけの期間を追ったか |
比較するときは、追った期間もそろえる
過去の月ほど、商談になるまでの時間が長く与えられています。直近の月と過去の月を同じ集計日に見て、直近の商談化率が低いだけで施策を評価するのは早計です。
比較するなら、「リードになった月の翌月末まで」など、追う期間をそろえます。まだその期間に達していない集団は、途中経過として扱います。
また、リードになった日が分からない既存データを、今月の新規リードに混ぜるのは避けます。過去分として別に扱うほうが、これから蓄積するデータとの違いを読み取りやすくなります。
HubSpotのどの項目とファネルレポートを使えばよいか？
ステージの名前より、移動した日付を使う
HubSpotの標準のライフサイクルステージは、購読者、リード、MQL、SQL、商談、顧客、エバンジェリスト、その他です。
現在のステージだけを見ると、「いま商談のコンタクト」は分かっても、「ある月のリードが、その後どこまで進んだか」は追い切れません。顧客まで進んだコンタクトも含めて経過を読むには、ステージに入った日付を使います。
ステージごとに作られるプロパティは、次のとおりです。
| プロパティ | 主な用途 |
|---|---|
| ［ステージ］に入った日（Date entered） | リードになった月や、次の段階へ進んだ時点を捉える |
| ［ステージ］を出た日（Date exited） | その段階を離れた時点を捉える |
| 直近の滞在時間（Latest time in） | 直近の滞在を調べる |
| 累計の滞在時間（Cumulative time in） | その段階にいた時間の合計を見る |
滞在時間のプロパティはProfessional以上で利用できます。
ファネルレポートでは、対象と通過条件を分けて考える
カスタムのファネルレポートは、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Revenue HubのProfessionalまたはEnterpriseで作成できます。
レポートを作る際は、画面上で段階を並べる前に、次の内容をメモしておきます。
-
対象は、いつリードになったコンタクトか
-
どの日付を商談化の日とするか
-
どの時点までの進捗を含めるか
-
すべての段階を通った経路を見たいのか、途中を飛ばした商談も含めたいのか
特に、期間を指定しただけで「その期間にリードになった人の、その後の進捗」が集計されているとは考えないようにします。分母となる対象と、実際に集計されたコンタクトを照らし合わせてから、数値を施策の評価に使います。
商談までの日数と、ステージの滞在時間を使い分ける
リードから商談までにかかった日数は、リードになった日と、採用した商談化の日付との差で求めます。MQLから商談までを見たいなら、起点をMQLに入った日に変えます。
一方、ステージの滞在時間は、その段階にどれだけいたかを見るための項目です。MQLの滞在時間と、MQLから商談までの所要日数は同じではありません。途中でSQLを経ているなら、その時間も商談までの所要日数に含まれます。
また、商談になったコンタクトだけで日数を見ると、まだ商談に進んでいないコンタクトが抜けます。次の情報を並べて読むと、短期間で進んだ一部だけを見て判断するのを避けられます。
-
商談になったコンタクトの所要日数
-
まだ商談になっていないコンタクトの件数
-
それらが現在いる段階と、そこにとどまっている時間
ファネルレポートの商談数が、営業の認識より少ないのはなぜか？
「すべての段階を通った」条件で、直行した商談が外れている
HubSpotのファネルレポートには、「すべての段階を通った」レコードを数える設定と、「いずれかの段階に入った」レコードを数える設定があります。
リード、MQL、SQL、商談を並べて「すべての段階を通った」条件にすると、MQLやSQLを飛ばして商談になったコンタクトは除外されます。
これは、商談がなかったのではなく、指定した経路を通っていなかったという違いです。
使い分けは、次のように考えます。
| 見たいこと | 集計時の考え方 |
|---|---|
| 定めた引き渡し手順が機能しているか | すべての段階を通った経路を追う |
| 獲得したリードが商談になった割合 | 段階を飛ばして商談になった対象も含める |
| 営業の商談数と差が出る理由 | 外れたコンタクトが、どの段階を飛ばしたか調べる |
「いずれかの段階に入った」設定へ変えるだけで、求めたい商談化率になるとは限りません。分母が同じリード集団のままか、分子がその集団に属する商談かを見ます。
全体の商談化率と、順に進んだ経路の転換率は、別の問いに答える数字です。 経路のレポートだけで全体の商談数を評価しないようにします。
営業の対応とHubSpotの記録に差がある
営業がすでに商談を進めていても、ライフサイクルステージがSQLのままなら、商談ステージを基準にした集計には入りません。
リードステータスの未更新も、引き渡し後の状況を読み違える原因になります。リードステータスは営業の対応状況を記録するコンタクトのプロパティで、新規、対応中、接続済み、対象外などを残せます。ただし、リードステータスを更新したことと、ライフサイクルステージを商談にしたことは分けて見ます。
営業の認識と数字が合わない場合は、商談として扱っているコンタクトを取り上げ、次を照らし合わせます。
-
ライフサイクルステージと、商談に入った日
-
取引の有無、作成日、コンタクトとの関連付け
-
リードステータスに残っている対応状況
-
営業が実際に把握している進捗
記録がないコンタクトを、すぐに「商談にならなかった」と分類しないことも必要です。「未対応」「対応したが商談に進まなかった」「対応したが記録がない」は、次に行うことが異なります。
データを集計に使う前に調べたい項目は、HubSpotのデータを分析に使う前に確かめることで整理しています。
件数が少なく、少数の変化が率に表れている
率を見るときは、分母と分子の件数も併記します。
例えば、架空の集計で対象リードが10件なら、商談が1件のときは10％、2件なら20％です。割合は倍になっていますが、増えた商談は1件です。
この違いだけで施策の良し悪しを判断せず、集計する期間を広げたり、個々の対応内容を読んだりします。獲得経路や担当者で細かく分けるほど件数は小さくなるため、全体でも差があるのかを先に見ます。
リードが次の段階に進まないときは、段階ごとに何を見直せばよいか？
リードが次の段階に進まないとは、ここでは、多くのリードがある段階にとどまり、次の段階に進まない状態を指します。どの段階で進まないかによって、見直す相手と内容が変わります。
リードからMQL：獲得対象と判定条件を分けて見る
リードからMQLへの転換率が低い場合は、まず「営業へ渡したい相手が少ない」のか、「対象には合っているが判定条件を満たさない」のかを分けます。
前者なら、流入経路やコンテンツが集めている会社・担当者と、自社が営業対象にしたい相手とのずれを調べます。後者なら、MQLの条件が、営業へ渡す判断として適切かを見ます。
転換率を上げるためだけにMQLの条件を緩めると、その先で営業が対象外と判断する件数が増えるおそれがあります。リードからMQLだけでなく、MQLからSQL、商談までの進み方も合わせて評価します。
条件の整理には、MQLの判定基準の決め方を参照してください。
MQLからSQL：対象の質より先に、対応されたかを調べる
MQLがSQLへ進まない場合、MQLの条件が合っていないとは限りません。営業に渡っていない、担当が曖昧、対応できる件数を超えている、対応結果が記録されていないといった可能性もあります。
次の順で見ると、条件の問題と対応の問題を分けやすくなります。
-
営業へ渡したあと、担当が割り当てられているか
-
担当者が対象を把握しているか
-
連絡したか、接続したかが記録されているか
-
接続できた相手を、どの理由でSQLにした、またはしなかったか
未対応が多いなら、MQL条件の変更より、引き渡し方法や対応量の調整を先に考えます。対応済みでも対象外が多いなら、マーケティングと営業で判定内容をすり合わせます。
引き渡し後の状況の見分け方は、HubSpotを使っているのにリードが営業に渡らないのはなぜかで詳しく扱っています。
SQLから商談：商談に進まなかった理由と、商談の数え方を見る
SQLから商談への転換率が低い場合は、まず本当に商談になっていないのかを調べます。営業が案件として進めていても、取引の作成やステージの更新が後になっていれば、数字には遅れて表れます。
記録に問題がなければ、SQLが商談に進まなかった理由を見ます。「商談にならなかった」という結果だけでは、次の対応を選べません。
-
課題や用途が、自社の提供内容と合わなかった
-
検討する時期がまだ先だった
-
必要な相手と接点を持てなかった
-
営業がSQLと判断した内容と、実際に聞けた内容に差があった
対象が合わないならSQLの条件を見直し、時期が先なら再度連絡する扱いを決めます。必要な情報が営業へ届いていないなら、引き渡す内容を見直します。
HubSpotに限らないリードから商談までの見方は、MAで集めたリードが商談にならないのはなぜかでも解説しています。
測定と成果の関連を、因果と混同しない
弊社がBtoB企業でマーケティング・営業に関わる480名を対象に実施した「MA活用実態調査（第0回）」では、MAを導入している企業の担当者134名のうち、MAが商談・売上に貢献していると答えた担当者（42名）では、ROIを定量的に測定していると答えた割合が54.8％、そうでない担当者（92名）では17.4％でした。
貢献していると答えた担当者のほうが、ROIを定量的に測定している割合が高い結果です。この結果は関連を示すものであり、測定すれば成果が上がるという因果関係を示すものではありません。
出典：株式会社Sells up「MA活用実態調査（第0回）」。調査主体：株式会社Sells up／調査ツール：Surveroid（2026年9月、回答者480名）。
商談化率も、測ること自体が目的ではありません。数字と個々の対応内容を照らし合わせ、どの段階の何を変えるかを選ぶために使います。
商談にならなかったMQLは、前のステージへ戻すべきか？
今回商談に進まなかったことと、MQLの条件を満たさないことを分ける
商談にならなかったという理由だけで、一律にリードへ戻す必要はありません。
MQLの条件は満たしているものの、検討時期が先だった場合と、そもそも営業対象に合っていなかった場合では扱いが異なります。
| 状況 | 扱い方の考え方 |
|---|---|
| 対象には合っているが、時期が合わない | MQLだった経過を残し、今回商談に進まなかった理由と次の対応を記録する |
| 連絡がついていない | 対象外と決めず、対応状況として管理する |
| 判定に誤りがあり、MQLの条件を満たしていなかった | ステージの修正を検討する |
| 再度MQLとして判定する運用にしたい | 戻す条件と、再度進んだときの集計ルールを先に決める |
リードステータスは営業の対応状況を残すために使い、ライフサイクルステージはマーケティングから営業への進み方を見るために使う、と役割を分けると整理しやすくなります。
戻す操作より先に、過去の数字の読み方を決める
標準の自動更新では、ライフサイクルステージは前にしか進みません。前のステージへ戻すには、手作業で値を消すか、ワークフローで前のステージを設定します。
ただし、戻しただけで「新しく獲得したリード」として扱うのは避けます。同じコンタクトの再判定と、新規リードの獲得が混ざるためです。
戻す運用を採用するなら、次の点を決めてから始めます。
-
新規リードの商談化と、再度対応する対象の商談化を分けるか
-
MQLになったコンタクトを数えるのか、MQLとして判定した機会を数えるのか
-
使う日付と滞在時間が、意図した経過を表しているか
運用を変える前に、対象コンタクトの記録とレポート上の扱いを照らし合わせます。見かけのステージを整えるためだけに戻すと、過去との比較が難しくなります。
測る仕組みを急がなくてよいのは、どんな場合か？
少ない案件を個別に追えている場合
商談が少なく、営業が個々の状況と商談に進まなかった理由を把握できているなら、細かなファネルレポートを作り込む優先度は高くありません。
まずは、対象リード、現在の段階、対応結果、次の対応を一覧で追います。率の上下より、どの相手に何が起きたかを読むほうが、見直す内容を選びやすい場合があります。
ステージの条件や更新方法がそろっていない場合
担当者によってMQLやSQLの意味が違う状態では、レポートを増やしても比較には使いにくいままです。
先に、商談化の定義、各段階へ移す条件、更新担当をそろえます。過去のすべてのデータを整え終えるまで待つのではなく、運用をそろえた日を記録し、それ以降のデータを分けて追う方法もあります。
分母と商談を結び付けられない場合
取引とコンタクトが関連付けられていない、リードになった時期が分からない、といった状態では、どのリードが商談になったのかを追えません。
この場合は、精密に見える転換率を出すより、集計対象に含められる範囲を明記します。数えられない対象を「商談にならなかった」と扱わず、データ不足として分けておきます。
仕組みを急がなくてよいことと、記録を後回しにすることは別です。これから入るリードの条件と更新方法をそろえておけば、比較に使えるデータを蓄積できます。
次の段階に進まないリードから、今日連絡する相手を選ぶには
LisCoreは、MAに蓄積されたデータを毎日解析し、その日にトスアップする相手を一覧にする自社開発のツールです。2026年11月2日からβ版を提供し、HubSpot Marketing Hubをお使いの企業さまを対象に10社限定で募集しています（募集は2027年3月末まで）。
デモを申し込む →まとめ
HubSpotのライフサイクルステージで商談化を測る際は、先に次の内容をそろえます。
-
商談化の日付を、商談ステージに入った日と取引の作成日のどちらにするか
-
リードと商談を、同じコンタクト集団で数えているか
-
リードになった月と、その後を追う期間がそろっているか
-
ファネルレポートで、段階を飛ばしたコンタクトが除外されていないか
-
営業の対応結果が、ステージやリードステータスに記録されているか
転換率が低いときは、施策を変える前に、対象の取り方と記録を調べます。そのうえで、リードからMQLなら獲得対象と判定条件、MQLからSQLなら引き渡しと対応状況、SQLから商談なら商談に進まなかった理由を見直します。
商談化率は、単独で成果を判定するための数字ではありません。件数、所要日数、次の段階に進んでいないリードの状況と合わせて読み、次に変える箇所を選ぶために使います。
よくある質問
商談化は、取引の作成日と商談ステージに入った日のどちらで数えればよいですか？
自社で商談とみなす状態に合うほうを選び、同じ定義で数え続けます。取引の作成タイミングが担当者によって違うなら、先に運用をそろえます。
ライフサイクルステージの同期を使っていても、すでに顧客のコンタクトは商談へ戻りません。新規リードの商談化と、既存顧客の追加の取引は分けて扱います。
今月の商談数を今月のリード数で割ってはいけませんか？
月ごとの活動量の参考にはなっても、今月獲得したリードの商談化率とは異なります。商談側に先月以前のリードが含まれ、今月のリード側には今後商談になる対象が残っているためです。
リードになった月ごとに対象をまとめ、その対象が一定の期間内にどこまで進んだかを追います。
ファネルレポートの商談数が取引の件数より少ないのはなぜですか？
コンタクト数と取引数という単位の違いに加え、段階を飛ばしたコンタクトの除外、ステージの未更新、集計対象や期間の違いが考えられます。
まず、営業が商談として把握している対象を取り上げ、レポートに含まれているか、外れているならどの条件によるものかを調べます。
商談にならなかったMQLは、リードに戻すべきですか？
今回商談に進まなかっただけなら、戻さずに対応状況や理由を残す方法があります。MQLの判定が誤っていた場合や、再判定する運用にする場合は、戻すことを検討します。
戻す場合も、新規リードと再度対応する対象を混ぜないように、集計の扱いを先に決めます。
商談化率の目安はありますか？
商材や獲得の経路によって大きく変わるため、一律の目安は示しにくい指標です。まずは自社のデータで、商談化の定義と観察期間をそろえ、過去の月や獲得経路ごとの違いを比べます。
件数が少ない区分では、率だけで判断せず、分母と分子、個々の対応結果も合わせて読みます。
