結論から言うと、プロダクトレッドセールス（Product-Led Sales／PLS）とは「プロダクトの利用データを起点に、営業が動くタイミングと相手を決める営業のやり方」です。 資料請求やセミナー参加といったマーケティング施策への反応ではなく、実際に製品を使った行動の事実をもとに、誰にいつアプローチするかを判断します。PLG（Product-Led Growth）の営業版と説明されるのはこのためです。
この記事では、PLS の定義と MQL・PQL の違い、利用データから商談までの5ステップ、SaaS 営業の現場で何が変わるのかを数字入りの例で示し、つまずきやすい点まで整理します。あわせて、利用データのシグナルだけでは埋まらない「なぜ今この会社が動くべきか」をどう補うかを、営業支援 AI エージェント IntelligentSales（インテリジェントセールス） を開発する DeploAI の観点からまとめます。営業フレームワーク全体の地図は営業フレームワーク大全にあります。
この記事に出てくる社数・率・金額はすべて説明用の仮の値です。自社の数字に置き換えてお読みください。
プロダクトレッドセールスとは？——利用データを起点に営業が動く型
プロダクトレッドセールスは、プロダクトの利用データやシグナルを起点にセールスが動く営業モデルです。 無料プランやフリートライアルで製品に触れてもらい、その中で「価値を感じ始めた兆候」が出たアカウントに営業が接触します。
表記について: 日本語では「プロダクトリードセールス」、英語表記も Product-Lead Sales と書かれることがありますが、正しい英語表記は Product-Led Sales です。Led は Lead（導く）の過去分詞形で「導かれた」という意味。つまり原義は「プロダクトに導かれた営業」であり、見込み客を指す名詞の Lead（リード）とは別の単語（動詞 Lead）が変化した形です。本記事では正しい表記の Product-Led Sales で統一します。
PLG（Product-Led Growth）は、プロダクト自体を獲得・定着・拡大の主役に置く成長の考え方です。ただし現実には、PLG だけで完結する範囲には限りがあります。単価の大きい契約、全社展開、セキュリティ審査や稟議が伴う導入は、製品の中だけで完結しません。そこに営業が入るときの入り方を「利用データ起点」に定義したのが PLS です。
従来型との違いを整理すると次のようになります。
| 観点 | 従来型（マーケ/営業主導） | プロダクトレッドセールス |
|---|---|---|
| 起点になる情報 | 資料請求・セミナー参加・問い合わせ | トライアル利用状況・機能利用頻度・ユーザー招待数 |
| 見込み顧客の呼び方 | MQL（Marketing Qualified Lead） | PQL（Product Qualified Lead） |
| 判定の根拠 | 関心を示したか（言葉・反応） | 実際に使って価値に触れたか（行動） |
| 接触のタイミング | 興味を持った時点 | 価値を体験した直後 |
| 会話の入口 | 一般的な課題提起と製品紹介 | 目の前の利用実態の共有 |
PQL（Product Qualified Lead）は、製品の中での振る舞いをもとに「有償化・拡大の可能性が高い」と判断された見込み顧客を指します。 MQL が「関心の表明」を根拠にするのに対し、PQL は「行動の事実」を根拠にする。この違いが、PLS の実務上の中核です。
営業フレームワーク大全でも Product-Led Sales を「プロダクトの利用データを起点に営業する、PLG の営業版」として、アカウント戦略系のひとつに位置づけています。
なぜPLGだけでは足りず、営業が出ていく必要がある？
PLG は「使ってもらう」ところまでは強いが、「組織として買う」判断には別の力が要るからです。 個人やチーム単位のセルフサーブ契約なら製品の中で完結しますが、席数が増え金額が上がるほど、購買は個人の判断から組織の意思決定へ移ります。
SaaS の現場でよく起きるのは、次のような状況です。
- トライアルで現場の3人が気に入って使っている。しかし全社展開には情報システム部門の審査と部長決裁が必要で、そこから先に進まない。
- 部署単位で10席契約している。隣の部署も同じ課題を持っているが、社内で共有されていないので広がらない。
- 利用は活発なのに、契約更新の稟議で「で、いくら得したのか」を説明できる人が社内にいない。
これらはいずれも、製品の使い勝手の問題ではありません。社内の合意形成・投資判断・リスク審査という、プロダクトの外側にある障害です。ここを越える手伝いをするのが営業の仕事であり、PLS はその営業を「勘ではなく利用データの合図で動かす」ための設計だと言えます。
逆に言えば、PLS は営業を減らす仕組みではなく、営業を投じる先を絞り込む仕組みです。全件に架電するのではなく、製品の中ですでに価値に触れた相手を優先する。その意味で、獲得効率（LTV/CACの分母である CAC）を抑える打ち手でもあります。
PLSはどう進む？——利用データから商談までの5ステップ
PLS の流れは、利用データの収集からクロージングまでの5段階に整理できます。 各段階で「何を見て、次に何を決めるか」が変わります。
PQL判定あらかじめ決めた条件に合うアカウントを抽出する
PLSの5ステップ。難所は2と3——「使っている」から「今動くべき」への翻訳にある
ステップ1・2：どんな利用データをシグナルにする？
シグナルは「製品の価値に触れた瞬間」を表す行動に絞るのが原則です。 ログイン回数のように誰でも増える指標を並べても、優先順位はつきません。
一般に PQL の条件として使われる行動には、次のような型があります（どれを採るかは製品によって変わります）。
| シグナルの型 | 例 | 何を示すか |
|---|---|---|
| 到達 | 中核機能を初めて使い切った | 価値を一度は体験した |
| 反復 | 直近2週間に5日以上利用した | 業務に組み込まれ始めた |
| 拡散 | 同じドメインの同僚を3人以上招待した | チームに広がっている |
| 限界 | 無料枠の上限に近づいた | 有償プランの必要が生まれている |
| 組織 | 情シス・管理部門のドメインでアカウントが作られた | 審査・全社検討が始まった可能性 |
重要なのは、シグナルを「点」ではなく「組み合わせ」で見ることです。 たとえば「無料枠の上限に近い」だけなら値引き交渉になりやすいのに対し、「反復利用があり、かつ上限に近い」なら定着した上での拡大の話になります。同じ数値でも、意味が変わります。
ステップ3：スコアの高い順に架けるだけでは足りない
PQL のスコアが教えてくれるのは「見込みがありそうな順番」であって、「その会社が今なぜ動くべきか」ではありません。 ここを取り違えると、PLS は「精度の上がったリスト架電」で止まります。
利用データから読めるのは、あくまで製品の中の出来事です。予算がいつ決まるのか、競合を並行検討しているのか、決裁者が何を気にしているのか——これらはログの外にあります。ステップ3以降で必要なのは、行動の事実に、商談の文脈を重ねる作業です。
SaaS営業の現場でPLSはどう効く？——具体シナリオと試算
PLS の効果がもっとも分かりやすいのは、限られた営業リソースをどこに割くかという配分の問題です。 説明用の仮の値で試算してみます。
席あたり月額 2,000 円、14日間の無料トライアルがある業務系 SaaS を想定します。月間のトライアル開始が 1,000 社、営業（インサイドセールス）は 3 名。全件に接触する時間はありません。
| 進め方 | 接触対象 | 商談化 | 受注 |
|---|---|---|---|
| 全件を登録順に架電 | 300社（対応可能な上限） | 商談化率 8% → 24件 | 受注率 20% → 約5社 |
| PQL条件で絞って架電 | 80社（全体の8%） | 商談化率 40% → 32件 | 受注率 25% → 8社 |
いずれも説明用の仮の値ですが、構造として言えることがあります。接触数を 300 社から 80 社へ減らしているのに受注が増えているのは、接触の総量ではなく、接触の当たりやすさを変えているからです。「昨日まさにその機能を使い込んでいた会社」に電話するのと、「2週間前に登録しただけの会社」に電話するのでは、会話の入口がそもそも違います。
会話の入口の違いを、具体的に置いてみます。
従来型の入口 「先日はトライアルにご登録いただきありがとうございます。弊社のサービスは営業部門の業務効率化に貢献しておりまして……」
PQL起点の入口 「レポート自動出力の機能を、先週から繰り返しお使いいただいているようですね。今の無料枠だと月10件までなので、そろそろ足りなくなっている頃かと思うのですが、実際の運用ではどのくらいの件数を想定されていますか？」
後者は、製品紹介ではなく相手の業務の話から始まっています。これは売り手側が賢くなったからではなく、事実を握っているから成立する会話です。
そして、SaaS 営業がここから先に進むには、結局いつもの難所を越える必要があります。
- 機能比較の泥沼：「A社の製品にはこの機能がある」と並べられる。トライアルで実際に使った機能は分かっていても、競合が何を訴求してくるかは利用ログには出てきません。
- 稟議とROIの説明：50席で月10万円、年間120万円。この投資を通すために、情シスや管理部門が納得する形の説明資料が要ります。現場が気に入っているだけでは通りません。
- 決裁者の不在：トライアルを使っている担当者は決裁者ではないことがほとんどです。誰を巻き込むかの設計が必要になります。この観点はMEDDICやBANTのような資格フレームが扱ってきた領域です。
- 導入後の定着：席数を広げても使われなければ更新時に落ちます。受注の質が解約率を通じて事業指標に跳ね返る話はLTV/CACとはで扱っています。
PLSでつまずきやすいのはどこ？
PLS の失敗は、仕組みそのものよりも「シグナルの扱い方」で起きます。 よくある形を4つ挙げます。
- シグナルを増やしすぎる。条件を足すほど精度が上がる気がしますが、実際には該当社数が減り、なぜ選ばれたかの説明もできなくなります。まず2〜3個の単純な条件から始め、受注した会社に共通する行動を見て育てるほうが実務的です。
- スコアを信じすぎる。スコアは優先順位であって、勝てる根拠ではありません。高スコアなのに失注が続くなら、疑うべきはスコアではなく、接触してからの商談の進め方です。
- 通知が来た瞬間に売りに行く。価値を体験した直後は接触の好機ですが、そこで即座に見積もりを出すと、体験の続きではなく売り込みとして受け取られます。まず利用実態を確認し、困りごとを引き出す順番を崩さないことです。関連してSPIN営業の質問の型が参考になります。
- マーケ・製品・営業が別々の指標を見ている。PLS は3者の共同作業です。「トライアル数」「アクティブ率」「受注数」をそれぞれが独立に追うと、PQL の定義を誰も更新しなくなります。
もうひとつ、自社が PLS に向いているかの見極めも先にしておく必要があります。無料プランやトライアルがあり、利用ログを取得できることが前提条件です。試用なしで導入が決まる商材や、利用データがほとんど取れない商材では、この型は成立しません。その場合は、狙う企業を先に定めて攻めるABM（アカウントベースドマーケティング）のほうが噛み合います。
利用データだけでは分からないことをどう埋める？——IntelligentSalesの観点
PLS が教えてくれるのは「誰に、いつ声をかけるか」までであり、「その商談をどう勝つか」は別の問いです。 ここを埋めないと、精度の高いリストを持ったまま、商談の進め方は個人の力量任せという状態になります。
IntelligentSales は、SPIN・BANT・MEDDIC など複数のフレームワークから要素を抽出・体系化し、「あるべき営業の理想形」から逆算するバックキャスト型のアプローチをとる、プロアクティブ営業支援 AI エージェントです。中核にあるのは、商談前の準備を自律化することと、商談後すぐに分析して次の商談への行動を提案することの2つ。これは PLS の5ステップで言えば、まさにステップ4以降にあたります。
6つの専門AIのうち、PLS と組み合わせたときに効くのは次の4つです。
| 専門AI | 担当する局面 | PLSのどこを埋めるか |
|---|---|---|
| 競合分析 | 商談前の準備 | 過去商談での競合言及を整理し、次の商談に向けたカウンタープランを準備する。機能比較の土俵に引き込まれる前に、勝ち筋を組み立てて臨める |
| 顧客特性診断 | 商談前の準備 | 商談相手の行動特性タイプを見立て、響く伝え方・進め方を提示する。同じ利用実態でも、伝え方によって受け止められ方が変わる |
| SFRA（セールスフレーム分析） | 商談後 → 次商談 | 直近商談の発話を分析し、商談がどの段階で止まっているかを判定して、次に踏むべきステップと質問を提示する |
| BCA（心理・行動変容分析） | 商談後 → 次商談 | 商談記録から、顧客の関心が動いた箇所・離れた箇所を可視化する。製品はよく使われているのに話が進まないとき、どこで熱量が落ちたかを捉える材料になる |
構造として整理すると、プロダクトの利用データは「顧客が製品の中でどう振る舞ったか」を、商談の分析は「顧客が商談の中でどう反応したか」を教えてくれます。PLS はこの前者を営業の起点に据える考え方であり、後者を組織で扱えるようにするのが IntelligentSales の役割です。両方が揃うと、「よく使っている会社」を見つけるところから、「その会社の社内で話を通す」ところまでが一本の線でつながります。
なお SFRA は MEDDIC・SPIN といった資格系・プロセス系のフレームワークを土台に、BCA は心理・コミュニケーション系を土台にしています。機能の詳細はIntelligentSales の機能、営業支援 AI の選び方は営業支援AIの選び方をご覧ください。
まとめ
- プロダクトレッドセールス（PLS） は、プロダクトの利用データやシグナルを起点に、営業が動くタイミングと相手を決める営業モデル。PLG の営業版として位置づけられる。
- 判定の中心は PQL（Product Qualified Lead）。関心の表明ではなく、到達・反復・拡散・限界・組織といった行動の事実で見込みを測る。シグナルは点ではなく組み合わせで読む。
- PLS が答えるのは「誰に、いつ声をかけるか」まで。機能比較・稟議・決裁者の巻き込みといった商談の難所は、利用ログの外にある。ここは商談前の準備と商談後の分析で埋める必要がある。
- 自社に無料プランやトライアルがなく利用ログも取れない場合は、この型は成立しにくい。狙う企業を先に定める ABM など、別のアプローチを検討する。
トライアルは回っているのに商談化しない、商談には入れたのに社内で話が止まる——といった課題がある場合は、お問い合わせからお気軽にご相談ください。営業フレームワークの全体像は営業フレームワーク大全、SaaS 営業向けの商談設計はSPICEDとはにまとめています。
