LASSIC Media らしくメディア
CPQ(構成見積)システムの選び方｜製品構成と価格ルール
LASSIC IT事業部｜元請（プライムベンダー）として基幹・業務システムの開発・運用を受託
この記事のポイント
- CPQ(構成見積)システムは、複雑な製品の構成(Configure)・価格算定(Price)・見積書生成(Quote)を一気通貫で扱う仕組みです。単に見積書を作って保存する道具とは目的が異なります。
- 汎用の見積管理システムとの大きな違いは、選択肢・機能・制約といった「製品構成ルール」で妥当な組合せだけを許す仕組みを備える点にあります。製造業やBtoB SaaSなど構成が複雑な商材ほど価値が高まります。
- 選び方の軸は、構成ルールの表現力・価格と承認の柔軟性・既存CRM/ERPとの連携・内製移管のしやすさなど。外注時はこれらを具体的に確認します。
目次
CPQ(構成見積)システムとは、製品構成・価格・見積書を一気通貫で扱う仕組み
CPQ(構成見積)システムとは、製品の構成(Configure)、価格の算定(Price)、見積書の生成(Quote)という一連の流れを一気通貫で扱う仕組みを指します。頭文字を取ってCPQと呼ばれます。OracleはCPQについて、商談から見積、受注までのプロセス全体を効率化するものと位置づけ、製品選択・構成・価格・見積・受注・承認ワークフローといった機能を挙げています*2。単に見積書を作って保存する道具ではなく、「どの組合せなら販売できるのか」を製品ルールで担保しながら、価格と見積書までつなぐ点に特徴があります。
この図のとおり、CPQは製品選択から承認・受注までを一本の流れとして扱います。複雑な構成品を売る現場では、この流れのどこかが人手頼みになりがちです。選択肢が多く、オプション同士に依存関係や排他条件があり、価格に段階的な割引や承認が絡む——こうした商材ほど、担当者の経験に品質が左右されてしまうでしょう。
たとえば製造業の受注生産品や、BtoB SaaSの「プラン＋オプション＋数量」のように、組合せが数百から数千通りに及ぶ商材を思い浮かべてください。表計算ソフトで見積を作っていると、選べない組合せを選んでしまったり、割引の上限を超えたまま提出してしまったりといった事故が起こりがちです。CPQはこうした誤りをルールで未然に防ぎ、正しい構成と価格だけが見積書に載るようにする仕組みだと整理できます。次章から、その中身を3つの柱に分けて見ていきましょう。
CPQを支える3つの柱——Configure・Price・Quoteの中身
CPQという名前は、Configure(構成)・Price(価格)・Quote(見積)の頭文字です。この3つはそれぞれ別の役割を担い、順につながって初めて価値を生みます。ここでは公式ドキュメントをもとに、各柱が具体的に何をするのかを整理します。
Configure(構成)——選択肢・機能・制約で妥当な組合せを保証する
最初の柱は、製品をどう組み立てるかを制御するConfigureです。Salesforce CPQの開発者向けドキュメントによれば、製品モデル(ProductModel)は選択肢(options)、機能(features)、構成属性(configuration attributes)、制約(constraints)といった要素で構成されています*1。これらを使い、選んではいけない組合せをあらかじめ排除できる点がConfigureの本質です。
妥当性の検証には専用の仕組みが用意されています。Salesforce CPQの構成検証(Configuration Validator)は、選択・検証・アラートといった製品ルールと、構成時に適用される価格ルールを入力された構成に対して実行します*1。人手でチェックリストを照合するのではなく、ルールが自動で「この組合せは成立するか」を判定してくれるわけです。
製品を束ねる単位としてはバンドル(bundle)が使われます。Microsoftは製品バンドルを「単一のユニットとして販売される製品の集まり」と定義しており、各製品を必須か任意かで指定できると説明しています*4。任意に設定した製品は、外して販売することも可能です*4。なお同社のバンドルには、製品ファミリーやキット、別のバンドルは入れられないという制約もあります*4。こうした「何と何を一緒に売れるか」の定義こそ、Configureが引き受ける領域だと言えるでしょう。
Price(価格)——価格ルール・割引・承認で正しい金額を出す
2つ目の柱は、構成した製品にいくらの値を付けるかを決めるPriceです。Microsoftは見積の価格計算について、製品カタログ・価格表・明細・価格ルール・割引・税といった要素に依存すると説明しています*3。ここでいう価格ルールは、数量に応じた割引や顧客ごとの価格、契約条件などに基づいて金額を決める仕組みを指します*3。
割引の設定はさらに細かく制御できます。Microsoftの割引リストでは、割引の種類として価格に対する割合(Percentage)か固定額(Amount)を選べます*5。数量帯ごとの割引も設定でき、開始数量と終了数量を指定して、その範囲に入ったときだけ割引を効かせる、といった段階設定が可能です*5。手作業では抜けやすいこうした条件を、ルールとして一元管理できる点がPriceの強みです。
複雑な取引では、値引きの妥当性を人が承認する場面も出てきます。Oracleは、CPQが扱う機能に承認ワークフロー(approval workflows)を含めています*2。一定の割引率を超えたら上長の承認を挟む、といった統制をシステム側に組み込めるため、現場の裁量と会社の統制を両立させやすくなります。
Quote(見積)——見積書の生成・承認・CRM連携
3つ目の柱は、確定した構成と価格を顧客向けの見積書に落とし込むQuoteです。Microsoftは見積について「潜在顧客が関心を持つ製品の価格情報を含むもの」と述べ、顧客が受け入れると受注(オーダー)になると説明しています*3。見積は下書きとして作成し、送付できる状態になったら有効化し、受注や失注に応じて締める、というライフサイクルで管理されます*3。
できあがった見積書は、そのまま顧客に届けられます。MicrosoftはPDFへの書き出しやメールでの送付に対応していると案内しています*3。さらにOracleが挙げるように、CPQは見積から受注、承認までを一連のプロセスとして扱うため、商談情報とのつながりも保たれます*2。見積書を作って終わりではなく、受注データとして後工程へ引き継げる点がQuoteの役割です。
汎用の見積管理システムとの違い——「製品構成ルール」の有無
ここまで読んで、「それは見積管理システムと何が違うのか」と感じた方もいるでしょう。両者はよく混同されますが、担う役割の重心が異なります。この違いを理解しておくことが、システム選定の出発点になります。
見積管理システムは「見積書を作って管理する」仕組み
汎用の見積管理システムは、見積書の作成・保存・履歴管理を主眼に置いた仕組みです。品目を選んで単価と数量を入れ、割引を差し引いて金額を出し、PDFにして保管する——この一連の事務を効率化することに主眼があります。既存の見積管理系の記事でも触れているとおり、扱う商材が比較的シンプルで、組合せの妥当性を人がすぐ判断できる場合には、この仕組みで十分なことも多いでしょう。
CPQは「構成ルールに沿って正しい見積だけを作る」仕組み
一方でCPQは、見積書を作る手前にある「製品構成ルール」を核に持ちます。前章で見たとおり、選択肢・機能・制約で妥当な組合せを縛り、選択・検証・アラートのルールで自動的に成立可否を判定します*1。つまりCPQは、見積を「管理する」より前に、そもそも成立しない構成や価格を作らせないことに価値を置いているわけです。複雑構成品では、この差が見積の品質を大きく左右します。
両者の違いを整理すると、次の表のようになります。
| 観点 | 汎用の見積管理システム | CPQ(構成見積)システム |
|---|---|---|
| 主眼 | 見積書の作成・保存・履歴管理 | 構成ルールに沿った構成・価格・見積 |
| 製品構成 | 品目を手作業で選ぶ | 選択肢・機能・制約で妥当な組合せを保証*1 |
| 妥当性チェック | 主に人手で確認 | 選択・検証・アラートのルールで自動判定*1 |
| 価格・割引 | 単価×数量と割引の計算 | 価格ルール・数量帯割引・承認で統制*3*5 |
| 向いている領域 | 構成が単純な汎用商材 | 複雑構成品（製造業・BtoB SaaS等） |
この表からわかるとおり、両者は優劣ではなく適材適所の関係にあります。扱う商材の複雑さと、見積で起きているミスの中身を見極めたうえで、どちらの仕組みが自社の課題に合うのかを判断することが大切です。
CPQシステムの選び方——5つの判断軸
CPQを導入・開発すると決めた後に問われるのが、どんな軸で製品や開発方針を選ぶかという点です。見た目の機能一覧だけで比べると、運用に入ってから自社商材を表現しきれないと気づくことも少なくありません。ここでは選定の勘所を5つの軸に整理します。
1. 構成ルールの表現力（依存・排他・必須）
まず確認したいのは、自社商材の構成ルールをどこまで表現できるかです。オプション同士の依存関係や排他条件、必須項目などを、選択肢・機能・制約として定義できるかが要になります*1。バンドルの必須／任意の切り替えのように、束ね方を柔軟に設定できるかも見ておきたい点です*4。ここが弱いと、結局は人手のチェックが残ってしまいます。
2. 価格と割引・承認の柔軟性
次に、価格の付け方をどこまで細かく制御できるかを確かめます。価格ルール・割引・税といった要素を組み合わせて金額を出せること*3、割合と固定額の両方の割引や数量帯ごとの段階割引を扱えること*5が目安になるでしょう。加えて、割引率に応じた承認ワークフローを組み込めるか*2も、統制を担保するうえで重要です。
3. 既存CRM/ERP・基幹システムとの連携
三つ目は、既存の業務システムとどうつなぐかです。CPQは商談から受注までを扱うため*2、顧客情報を持つCRMや、原価・在庫を持つ基幹システムとの連携が前提になる場面が多くあります。取り込み方式か直接参照かによって、性能や運用負荷も変わってくる点に注意が必要です。自社の既存構成を踏まえた接続設計を描けるかどうかを見極めましょう。
4. 見積書テンプレートと出力（PDF・電子承認）
四つ目は、最終成果物である見積書の出力です。自社の書式でPDFを生成できるか、メール送付や電子的な承認まで一連の流れで扱えるかを確認します*3。見積が受注データへ引き継がれる設計になっていれば*2、再入力の手間や転記ミスを抑えられます。表側の見た目だけでなく、後工程へのつながりまで含めて評価することが肝心です。
5. 内製移管とメンテナンス性
最後は、導入後に自社で育てていけるかという観点です。製品ルールや価格ルールは、商品改定のたびに手を入れる必要があります。ルールの定義がドキュメント化され、特定の担当者しか触れない属人的な作りになっていないかを確認しておくと、長期の運用で助かるでしょう。手段を先に決めるのではなく、これら5つの軸で要件を言語化してから選ぶ順序が、後戻りのコストを抑えます。
外注先に確認したい4つのポイント
CPQの構築を外部パートナーに委託する場合、標準機能のデモだけで判断すると、運用開始後につまずくことがあります。委託先の選定では、次の4点を具体的にすり合わせておくとよいでしょう。
1. 自社商材の構成ルールを表現できるか
最初に確かめたいのは、自社の複雑な構成ルールを委託先が表現しきれるかです。オプションの依存・排他・必須といった条件を、選択肢・機能・制約としてどう落とし込むのか、具体的な設計例を示してもらいましょう*1。自社の代表的な受注パターンをいくつか渡し、それをルールで再現できるかを検証してもらうと、力量を見極めやすくなります。
2. 価格・割引・承認フローの作り込み範囲
次に、価格まわりのどこまでを作り込めるかを確認します。数量帯割引や顧客別価格、割引率に応じた承認の分岐などを、自社の商習慣に合わせて実装できるかがポイントです*3*5。承認ワークフローの設計範囲*2もあわせて詰めておくと、稟議のプロセスをそのままシステムに乗せやすくなります。
3. 既存システムとの連携方式
三つ目は、既存のCRMや基幹システムとの接続です。どの情報をどちらが正とし、どの方式で連携するのかを、契約前に図で示してもらうと認識のずれを防げます。自社の既存構成を踏まえた接続設計を提案できるかが、選定の分かれ目になるでしょう。連携の作り込みは工数に直結するため、範囲を早めに合意しておくことが欠かせません。
4. 内製移管のしやすさ
四つ目は、将来的に自社で運用を引き取れるかという観点です。製品ルールや価格ルールの定義がドキュメント化されているか、権限や承認の設計が整理されているかを確認しておきます。属人的な作りだと委託先への依存が続き、商品改定のたびに追加費用が発生しかねません。運用フェーズの体制まで含めて、契約前に話し合っておきたい点です。
まとめ：CPQ(構成見積)システムの選び方で押さえる3つの判断軸
本稿では、CPQ(構成見積)システムの中身と選び方を、各社の公式ドキュメントをもとに整理してきました。要点は3つに集約できます。第一に、CPQは製品の構成(Configure)・価格(Price)・見積(Quote)を一気通貫で扱う仕組みで、選択肢・機能・制約による製品ルールを核に持ちます*1*2。第二に、汎用の見積管理システムが見積書の作成・管理を主眼とするのに対し、CPQは成立しない構成や価格を作らせないことに価値を置く点で役割が異なります*3*4。第三に、選定では構成ルールの表現力・価格と承認の柔軟性・既存システムとの連携・内製移管のしやすさが判断軸となり、これらを言語化してから手段を選ぶ順序が実務的です*1*5。
よくある質問
CPQシステムと見積管理システムは何が違うのですか。
見積管理システムは、見積書の作成・保存・履歴管理を主眼にした仕組みです。これに対してCPQは、選択肢・機能・制約による製品構成ルールを核に持ち、選択・検証・アラートのルールで成立可否を自動判定します*1。成立しない構成や価格をそもそも作らせない点が、両者の大きな違いです。
自社の商材は構成が単純ですが、それでもCPQは必要ですか。
構成がシンプルで、組合せの妥当性を人がすぐ判断できるなら、汎用の見積管理システムで足りる場合も少なくありません。CPQが向くのは、オプションの依存・排他が多く、価格に段階的な割引や承認が絡む複雑構成品です*1*2。まずは見積で実際に起きているミスの中身を確認し、そのうえで判断することをおすすめします。
Configure・Price・Quoteのうち、まずどこから整えるべきですか。
多くの場合、土台となる製品構成(Configure)から整えると進めやすくなります。選択肢・機能・制約で妥当な組合せを定義し*1、そのうえに価格ルールや割引*3*5、見積書生成*3を積み上げる流れです。ただし自社で最も事故が起きている工程がどこかによって、着手の優先順位は変わります。
既存のCRMやERPと連携できますか。
CPQは商談から受注までを扱うため、顧客情報を持つCRMや原価・在庫を持つ基幹システムとの連携が前提になる場面が多くあります*2。取り込み方式か直接参照かによって性能や運用負荷が変わるため、どの情報をどちらが正とするかを設計段階で明確にしておくことが重要です。
開発を外注する際、契約前に何を確認すべきですか。
自社商材の構成ルールを表現しきれるか、価格・割引・承認フローをどこまで作り込めるか、既存システムとの連携方式、そして将来の内製移管のしやすさを確認します*1*2。代表的な受注パターンを渡して再現してもらうと、委託先の力量を見極めやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Salesforce「CPQ Configuration API」（Salesforce CPQ Developer Guide、Salesforce Developers）（https://developer.salesforce.com/docs/revenue/cpq-developer-guide/guide/cpq-api-config-parent.html ）
- *2 出典：Oracle「Oracle Configure, Price, Quote – Get Started」（Oracle Help Center）（https://docs.oracle.com/en/cloud/saas/configure-price-quote/）
- *3 出典：Microsoft「Create or edit quotes in Dynamics 365 Sales」（Microsoft Learn）（https://learn.microsoft.com/en-us/dynamics365/sales/create-edit-quote-sales）
- *4 出典：Microsoft「Set up product bundles to sell multiple items」（Microsoft Learn）（https://learn.microsoft.com/en-us/dynamics365/sales/create-product-bundles-sell-multiple-items-together）
- *5 出典：Microsoft「Set up discount lists (Dynamics 365 Sales)」（Microsoft Learn）（https://learn.microsoft.com/en-us/dynamics365/sales/set-up-discount-list）
