ENTRY TYPE · definition

CPQ (Configure, Price, Quote)

By Marius Bughiu Last updated 2026-07-07 RevOps

CPQ（Configure, Price, Quote）は、rep の販売意図を、顧客が署名できる正確で承認済みの見積もりに変えるソフトウェアです。3 つの仕事を順番にこなします。configure はどの製品・コンポーネント・アドオンをまとめて販売できるかを決め、price は price book、段階・数量ルール、割引承認を適用し、quote はブランド入りの明細と条件を含む文書を生成します。CPQ は CRM のオポチュニティと受注・請求システムの間に位置するため、rep が売ったものがそのまま財務が請求するものになり、途中にスプレッドシートが入りません。

CPQ は CRM ではなく、請求システムでもありません。CRM（Salesforce、HubSpot）はアカウントとオポチュニティを保持します。CPQ はそこから読み取り、完成した見積もりを書き戻しますが、顧客レコードを保持するわけではありません。請求・回収・収益認識は下流で起こり、CPQ は署名済みの見積もりを受注として引き渡します。CPQ は契約ライフサイクル管理（CLM）ツールでも電子署名ツールでもありませんが、大手のスイートは今やそれらを同梱しています。そして、すべての企業に必要なものでもありません。1 つか 2 つの SKU を定価で売るなら、CRM 内の見積もりテンプレートで用が足り、CPQ プラットフォームは純粋なコスト増です。

CPQ が quote-to-cash のどこに位置するか

quote-to-cash は、有望なオポチュニティから回収済みの収益までの連鎖です。configure → price → quote → 署名 → 受注 → 請求 → 支払い → 収益認識。CPQ は最初の 3 つのリンクを担います。署名の後はすべて請求・財務システムに属します。この境界が CPQ の痛みの大半の源です。きれいに構成できるのに、再入力なしでは請求へ引き渡せない見積もりは、営業側の半分を解決し、財務側の半分を壊れたまま残しています。

CPQ が独立したカテゴリーとして存在するのは、3 つのステップが結合しているからです。rep が提示する割引は承認マトリクスを守らねばならず、顧客が望む bundle は有効な構成でなければならず、見積もりの価格は請求へ流れる価格でなければなりません。これを Google Sheets と Slack の承認の間で手作業でやると、見積もりミス、マージンの漏れ、そして売られたものを読むのではなく解釈する財務チームが生まれます。

RevOps チームが実際に必要とするのはいつか

ほとんどのチームは CPQ から始めるべきではありません。見積もりがボトルネックになるまでは CRM の中で見積もりを作ります。その線を越えたことを示すシグナルは具体的です。

製品とルールの複雑さ。 販売する SKU がおよそ 10〜15 を超える、または製品に依存ルールがある（X は Y を要する、A は B と同梱できない）、または独自価格の bundle がある。
定価ではない価格。 rep が記憶で間違える、段階・数量・サブスクリプション・地域別の価格。
チャットに住む承認。 割引の可否が Slack やメールを経由し、どの見積もりが最終版かを誰も言えない。
下流の精度ギャップ。 財務が見積もりを請求へ再入力する、または売られたものと違うものを請求する。

これらのうち 2 つ以上に当てはまれば、CPQ は営業の創造性と収益の正確さの間のガバナンス層として元が取れます。1 つも当てはまらなければ、持っていない問題を解く 6 か月の導入です。

2026 年のベンダー地図

最大の変化は Salesforce にあります。単体の managed package である Salesforce CPQ（元は SteelBrick）は 2025 年 3 月 27 日に end-of-sale に達し、新規顧客はライセンスできません。既存顧客は更新を続け、サポートを受けられますが、新機能は出ず、Salesforce は end-of-life の日付を公表していません。後継は Revenue Cloud Advanced で、見積もりと構成を、請求も扱うより広い収益プラットフォームに統合します。レガシー CPQ 上の Salesforce-native チームは、更新ではなく移行の判断に直面します。

Salesforce の外では、DealHub がより速い導入を狙います。ベンダーとパートナーの報告では、レガシー Salesforce CPQ の 3〜6 か月に対し、go-live は 4〜8 週間で、価格帯はユーザーあたり月 60〜100 ドルです。Conga（旧 Apttus）は最も難しい価格シナリオに寄り、ユーザー単価は月 75〜100 ドル前後、導入は mid-market から enterprise 規模で 10 万〜40 万ドルの幅で動きます。PROS と Vendavo は、価格が絶えず動く事業向けの価格サイエンスで先行します。SMB には、専用 CPQ がコストに見合う前に、HubSpot の組み込み見積もりが下限をカバーします。

よくある落とし穴

価格戦略の問題を直すために CPQ を買う。 CPQ は価格ポリシーを施行しますが、発明はしません。定義されていない割引マトリクスの上に展開すれば、混沌を自動化することになります。

ガード: 先に price book と承認しきい値を書きます。CPQ の構成は最後のステップであり、戦略ではありません。

初回ビルドですべてのエッジケースをモデル化する。 あらゆる特殊な deal を符号化しようとするのが、CPQ プロジェクトが 3 か月から 9 か月へ滑る道筋です。

ガード: 標準ルールに従う 80% の deal を構成し、まれな構成は、量が自動化を正当化するまで手動の例外として扱います。

見積もり文書をゴールラインとして扱う。 再入力なしでは請求へ渡れない美しい見積もりは、見える問題を解決し、高くつく問題を残しています。

ガード: CPQ 契約に署名する前に、見積もり → 受注 → 請求の連携をマッピングします。go-live の後ではありません。