CPQシステム開発の進め方/やり方/流れや方法/手法/工程/手順

CPQシステム開発は、営業担当者が商品を選び、構成可否と価格を確認し、承認済みの見積書を作成できる状態を段階的に作る取り組みです。成功のポイントは画面を先に作ることではなく、商品マスタ、価格ルール、値引き権限、CRM・ERPとの連携範囲を先に決めることです。

本記事では、CPQシステム開発の進め方を、要件整理、製品・方式の選定、設計開発、テスト、稼働、定着の6フェーズに分けて解説します。費用相場、見積書で確認すべき項目、実見積を使ったテスト方法、導入後のチェックリストまで、システムSIを検討する担当者が社内説明やRFP作成に使える形でまとめます。

▼全体ガイドの記事
・CPQシステム開発の完全ガイド

CPQシステムとは何ですか？全体像をつかむ

CPQは、Configure（商品・サービスの構成）、Price（価格計算）、Quote（見積作成）の頭文字です。単なる見積書作成ツールではなく、販売できる組み合わせだけを選ばせ、顧客別価格や数量割引、値引き上限、承認経路を適用し、受注や請求につなげる営業基盤と考えると、開発範囲を判断しやすくなります。

標準的な範囲は、商品カタログ、品目属性、オプション、BOM、価格表、通貨、顧客別単価、数量割引、原価・粗利、値引き承認、帳票生成です。さらに、CRMから商談を受け取り、CPQで見積を作り、承認後に受注・契約・請求へ渡すQuote-to-Cash（Q2C）まで含める場合があります。保守契約やサブスクリプションでは、更新、増減、分割、途中変更の扱いも要件になります。

自社の範囲を決めるときは、「見積を早く作りたい」という要望を、商品選択、構成チェック、価格計算、例外承認、帳票、受注連携、請求連携という業務シナリオに分解します。例えばSIサービスであれば、ライセンス、導入支援、保守、追加開発を一つの案件で組み合わせるため、商品マスタだけでなく、契約期間、作業量、要員単価、納品条件をどこで管理するかを明確にする必要があります。

Excelを使っていること自体が、すぐにCPQ開発を始める理由になるわけではありません。ただし、担当者ごとに価格や値引き判断が異なる、見積の差し戻しが多い、新商品やオプションの追加で計算式が壊れる、営業から受注・請求へ二重入力している、といった状態なら、属人運用のコストが見えにくくなっています。導入前に直近の実見積を10件から20件程度集め、作成時間、差し戻し理由、例外価格、連携先を記録すると、システム化の優先順位を説明しやすくなります。

反対に、商品数が少なく、価格計算が単純で、見積件数も少ない場合は、CRMの標準見積機能やテンプレートの整備で足りる可能性があります。営業人数だけで決めず、商材の複雑度、営業人数、既存CRM・ERPの資産、見積から請求までをどこまで一体化するかという4軸で判断します。

CPQシステム開発の進め方を6フェーズで解説

CPQシステムは、要件定義書を作って終わりではありません。商品や価格のルールを業務部門が説明できる状態にし、標準機能で成立するかを検証し、実際の見積を使って受入れ、稼働後にマスタを更新できる状態まで含めて開発と考えます。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の順で進めます。

最初に、営業、営業企画、商品企画、経理、情報システム、受注・請求の担当者を集め、現行の見積プロセスを可視化します。ヒアリングでは「何が欲しいですか」と聞くより、過去の実案件を一緒に追いながら、どの商品を選び、どの条件で追加品を付け、誰が値引きを承認し、受注後に何を転記しているかを確認します。

要件整理の成果物は、業務フロー、商品カタログ一覧、価格表と改定ルール、構成可否ルール、値引き承認表、帳票サンプル、連携項目一覧、権限表です。特に「例外価格を誰が、どの条件で許可するか」を曖昧にしないことが重要です。商品数、構成ルール数、価格表の種類、連携先、拠点数、同時利用者数を数え、後の見積比較で同じ条件を使えるようにします。

この段階で商品マスタの責任者と更新頻度も決めます。営業が自由に商品名を追加する運用では、同じ商品の重複、古い価格、販売終了品の混入が起こります。商品コード、販売単位、税区分、原価、適用期間、後継品、関連オプションを最低限そろえ、未確定項目は「後で決める」ではなく、決定期限と担当者を台帳に残します。

選定では、SaaS・クラウドCPQ、CRM・ERP内蔵型、パッケージ拡張、フルスクラッチを同じ表で比較します。商材の組み合わせが複雑でも、標準機能で商品構成、価格計算、承認、帳票が成立するなら、まずSaaSやパッケージを検討します。既存CRMの利用定着やデータモデルを生かせる場合は、CRM内蔵型が有力になります。

比較表には、商品ルールの表現力、顧客別価格と数量割引、複数通貨・税、契約更新、API、帳票、権限、監査ログ、データ返却、サポート、ライセンスの課金単位を入れます。デモでは一般的な見積を見せてもらうだけでなく、自社の実見積を匿名化して、複数オプション、保守期間、値引き承認、在庫や請求への連携まで再現してもらいます。営業資料の「柔軟に対応できます」ではなく、設定で可能か、追加開発が必要か、運用で回避するのかを記録します。

Salesforceは2025年7月に日本でRevenue Cloudの提供を開始し、商品カタログ、価格管理、CPQ、契約、注文、請求を共通データモデルで扱う方向を示しています。価格は公式発表時点で24,000円（税別）/ユーザー/月です（出典: Salesforce Japan「Revenue Cloud」日本提供開始、2025年7月1日）。同発表では、パナソニックEWネットワークスが営業活動と見積管理を単一プラットフォームで実現する活用プロジェクトを進め、将来的なAIエージェント活用も見据えていると紹介されています。一方、Oracle CPQは製品構成、価格設定、見積、承認、受注を扱い、Oracle SalesやERPとの連携を想定しています（出典: 日本オラクル「Oracle CPQ Cloud」）。製品名の知名度だけでなく、既存基盤との接続と自社ルールの適合性で評価します。

設計では、画面一覧やAPI一覧より先に、CPQの正解データがどこにあるかを決めます。商品・価格・顧客・契約・組織・権限のマスタごとに、登録者、承認者、更新タイミング、適用開始日、履歴の残し方を定義します。価格改定の予約、過去見積の再現、販売終了品の更新契約など、時間の経過を伴うシナリオを設計に含めることが大切です。

次に、標準設定で実現する機能、追加開発する機能、業務を変更して対応する機能を分類します。自社独自の原価計算や見積ロジックが競争力そのものならスクラッチや拡張の価値がありますが、帳票の細かな見た目だけを理由にコア機能を作り込むと、将来の製品更新に追随しにくくなります。RFPには各機能の実現方法と、追加費用・納期・保守影響を明記してもらいます。

連携設計では、CRMから商談番号・顧客・担当者を受け、CPQから見積明細・合計・承認状態を返し、受注確定後にERPや請求システムへ渡す流れを決めます。連携失敗時の再送、重複登録、価格の不一致、通貨や税の丸め、API停止時の手入力も設計対象です。顧客情報、価格・原価、契約情報を扱うため、最小権限、MFAまたはSSO、職務分掌、監査ログ、暗号化、バックアップ、データ保持・削除、委託先管理も非機能要件に入れます。

CPQのテストでは、画面が表示されるかだけを確認してはいけません。正常系として単純な商品、オプション付き商品、保守付き契約を試し、異常系として互換性のない組み合わせ、販売終了品、期限切れ価格、値引き上限超過、承認者不在、通貨不一致、API失敗を試します。結果として、金額、粗利、税、帳票、承認履歴、連携先の値が一致するかを確認します。

テストデータは架空の1件だけでなく、過去の実見積を匿名化して使います。例えば、標準案件、複数拠点案件、代理店価格の案件、個別値引きの案件、更新・増額の案件を用意し、営業、管理職、経理、受注担当がそれぞれ受入れます。価格計算では、定価、原価、利益率、値上げ率、数量割引、丸めの扱いを検証します。Microsoft LearnのDynamics 365 Salesでも、商品カタログ、価格表、原価、利益率、数量変更による割引が価格計算に影響すると説明されています。出典はMicrosoft Learn「営業案件、見積もり、受注、および請求書レコードの価格計算」（2025年8月22日更新）です。

受入れ基準は「大きな問題がない」ではなく、見積作成、承認、帳票、連携の各シナリオで合格条件を数値化します。たとえば、必須項目の未入力を登録できないこと、承認前の見積を外部送信できないこと、確定価格の変更履歴が残ること、連携エラーを担当者が検知できることを明文化します。

本番稼働では、全社一斉導入よりも、商材や営業部門を絞ったパイロットが向いています。商品マスタの整備度が高く、業務ルールを標準化しやすい部門で先に使い、見積作成時間、差し戻し率、値引き承認時間、エラー件数を計測します。そこで発生した例外を、システムの不具合、マスタ不足、業務ルール未決定、教育不足に分類してから、対象範囲を広げます。

移行では、現行の顧客、商品、価格表、契約、過去見積のどこまでを取り込むかを決めます。過去見積をすべて移行すると、古い商品や価格が混入する場合があります。参照用に保管するデータと、今後の更新・追加見積に使うデータを分け、移行前後の件数、金額、必須項目、重複を照合します。切り戻し条件、問い合わせ窓口、障害時の手入力手順も稼働判定に含めます。

稼働後に利用率が伸びない原因は、操作方法よりも、商品や価格が現場の実情に合っていないことが多いです。営業が勝手にExcelへ戻らないよう、商品追加・価格改定・例外価格・承認ルート変更の申請窓口とSLAを決めます。月次でマスタ変更を審査し、誰がいつ何を変更したかを監査できる状態にします。

KPIは、見積作成時間、見積差し戻し率、値引き承認時間、見積エラー率、粗利率、受注率、商品マスタ更新リードタイムを設定します。導入前の基準値と導入後の値を同じ条件で比較し、単にログイン数を増やすことを目的にしません。月次レビューで、使われていない機能、承認が滞る条件、例外が増えた商品を確認し、ルールと教育を更新します。

AIを使う場合も、定着フェーズで段階的に導入します。見積要約、類似案件検索、商品候補提示、異常な値引きの検知から始め、価格や原価をAIに自動確定させるのは避けます。正解データ、ルールの版管理、監査ログ、人による承認、顧客情報を外部サービスへ渡す範囲を先に決めることで、誤提案をそのまま営業へ流すリスクを抑えられます。

CPQシステム開発の費用相場とコストの内訳

CPQの費用は、ライセンス、初期設定、商品・価格ルールの整備、画面や帳票の拡張、CRM・ERP連携、データ移行、テスト、教育、保守に分けて考えます。2026年時点の予算取りでは、CPQ単体の国内公開見積が限られるため、以下は営業・CRM業務システムの相場に、CPQ特有のカタログ、価格ルール、承認、基幹連携を加味した目安として扱います。製品の定価や、すべての企業に当てはまる固定料金ではありません。

SaaSの標準設定で、商品数が少なくCRM連携がない場合は、初期費用100万〜500万円、期間1〜3か月が一つの目安です。クラウドCPQの標準機能に軽微な拡張、承認、帳票、CRM連携を加える場合は、500万〜1,500万円、3〜6か月程度が目安になります。価格ルールや帳票の数、テスト件数、教育範囲で変動するため、金額だけでなく含まれる作業を確認します。

製造業やSI向けに、ERP・在庫・請求連携、BOM、原価・粗利、複数通貨を含める場合は、1,500万〜5,000万円、6〜12か月程度が目安です。多拠点・多法人で独自のQ2Cや基幹刷新まで伴うと、5,000万円〜数億円、1〜3年規模になる場合があります。フルスクラッチは3,000万円〜2億円超、12〜24か月という広いレンジで見積もられることがありますが、これは独自UI、独自計算、非機能要件、将来改修の範囲で大きく変わります。いずれもリサーチノートとNotebookLM Q&Aをもとにした予算検討上のレンジであり、発注前に自社条件で再見積が必要です。

ライセンス費の例として、Salesforce Japanの公式発表にあるRevenue Cloudの24,000円（税別）/ユーザー/月を30ユーザーで契約する場合、ライセンスだけで月72万円、年864万円（税別）です。ここに契約条件、対象ユーザー、導入支援、Success Plan、連携開発、帳票、データ整備が加わるため、ライセンス額をそのまま導入予算と見なしてはいけません。価格表は契約時点で変わる可能性があるため、見積有効期限と値上げ条件も確認します。

初期費用で見落とされやすいのは、商品マスタのクレンジング、価格表の統合、既存Excelの棚卸し、過去データ移行、承認者の整理、帳票の印刷・PDF要件、APIの認証、教育資料の作成です。これらを「ユーザー側で準備する」として無料扱いにすると、社内工数や稼働遅延が予算に現れません。RFPでは、発注先作業と自社作業を分け、それぞれの担当者数と期限を記載します。

NotebookLM Q&Aで整理された配分の目安は、要件定義10〜15%、設計25〜35%、開発30〜40%、テスト15〜20%、移行・教育5〜10%です（出典: リサーチノート「CPQシステム」、営業・CRM・MAドメイン横断Q&A）。実際の提案では、商品マスタ整備や連携テストが大きい案件ほど、設計・テスト・移行の比率が高くなります。開発費だけを削るのではなく、稼働後に自社で更新できる管理機能と教育へ予算を残します。

ランニング費は、SaaSライセンス、APIや連携基盤、帳票・電子契約、保守、商品マスタ更新、問い合わせ対応に分けます。スクラッチや大規模カスタマイズでは、初期開発費の年10〜20%程度を保守予算として確保する考え方があります。機能追加だけでなく、税率・通貨・価格改定、OSやブラウザ変更、脆弱性対応、バックアップと障害復旧を含むかを契約書で確認します。

CPQシステムの見積を取る際のポイント

CPQの見積比較で重要なのは、総額の安さではなく、同じ業務範囲を同じ前提で比べることです。商品数や価格ルール数を伝えずに「CPQを導入したい」とだけ依頼すると、標準設定だけの見積と、連携や移行を含む見積が並び、後から追加費用が発生します。実見積とチェックリストを渡し、標準、拡張、運用回避の境界を明示してもらいます。

RFPには、対象部門、営業人数、同時利用者数、商品・オプション数、構成ルール数、価格表の種類、通貨・税、顧客別価格、割引、原価・粗利、承認段階、帳票、契約更新、データ移行、CRM・ERP・在庫・請求・電子契約との連携先を記載します。特に連携では、APIの有無だけでなく、どの項目をどのタイミングで、どちらを正として送るかを明示します。

非機能要件として、利用可能時間、障害時の復旧目標、バックアップ、監査ログ、SSO・MFA、権限分離、データの保管場所、海外移転、委託先、データ返却、サポート時間を入れます。顧客・担当者情報や価格・原価情報を扱うため、個人情報保護と営業秘密の両方を考慮します。決済情報まで接続する場合は、経済産業省の「クレジットカード・セキュリティガイドライン」など、対象業務に関係する最新の指針も確認します。

提案比較では、まず自社の実見積を使ったデモを評価します。商品構成の誤りを防げるか、価格と原価の計算根拠を確認できるか、値引き上限を超えたときに承認へ回るか、帳票とCRMの金額が一致するか、受注・請求へ二重入力なしで渡せるかを見ます。担当者が変わっても運用できるよう、設定変更の手順、権限、テスト方法、履歴管理まで説明を受けます。

次に、見積の内訳を要件定義、設計、設定、開発、連携、移行、テスト、教育、保守に分け、含むものと含まないものを確認します。追加変更の単価、前提が変わったときの再見積条件、検収基準、瑕疵対応、SLA、価格改定、ライセンス更新、契約終了時のデータ返却も比較対象です。導入後に商品マスタを誰が更新するかが提案書に書かれていなければ、定着支援の範囲を質問します。

失敗例の一つは、営業現場を見ずに高機能な製品を先に決めることです。商品マスタが未整備のまま導入すると、誤った商品や価格を自動計算するだけになります。対策として、選定前に実見積を棚卸しし、最初のリリースで扱う商材と例外を絞ります。二つ目は、既存業務をすべてシステムへ詰め込むことです。例外を標準ルールにできるか、例外として承認するか、廃止できるかを業務責任者が判断します。

三つ目は、AIによる自動提案を初期リリースの中心に置くことです。価格・原価・契約条件の正解データがない段階では、AI導入よりマスタクレンジングとルールの版管理が先です。四つ目は、稼働日だけをゴールにすることです。問い合わせ窓口、マスタ更新、KPIレビュー、改善予算をあらかじめ決め、稼働後90日程度の伴走計画まで見積に含めると、現場がExcelへ戻るリスクを抑えられます。

CPQシステム開発でよくある質問（FAQ）

CPQシステム開発では、費用、期間、既存CRMとの関係、商品マスタの準備が特に多く質問されます。ここでは、計画段階で判断に使えるよう、結論を先に回答します。

標準設定中心なら100万〜500万円、クラウドCPQの標準＋軽微な拡張なら500万〜1,500万円、ERP・在庫・請求連携を含む本格導入なら1,500万〜5,000万円が予算検討の目安です。商品数、価格ルール、連携先、拠点、移行・教育の範囲で変わるため、製品ライセンスと導入・開発費を分けて見積もります。

標準設定で1〜3か月、軽微な拡張やCRM連携を含む場合で3〜6か月、ERP・在庫・請求連携を含む場合で6〜12か月程度が一つの目安です。要件決定、マスタ整備、連携先の仕様確定、受入れ担当者の確保が遅れると、開発会社の作業だけでは短縮できません。最初は対象商材や部門を絞り、パイロットで検証してから段階展開する方法が現実的です。

商品構成と価格計算が比較的単純で、見積から受注までを既存CRMで管理できるなら、標準機能やCRM拡張で十分な場合があります。一方、複雑なBOM、顧客別・代理店別価格、原価・粗利、サブスクリプション更新、ERPや請求との連携が必要なら、CRM内蔵型とCPQ専用製品を実見積で比較します。CRMを利用しているかどうかではなく、必要なルールとQ2Cの範囲で決めます。

開発の準備は始められますが、本番導入を急ぐと誤った価格や販売不可の組み合わせを登録するリスクがあります。まず代表的な商品、オプション、保守、価格表、値引き、適用期間を整理し、マスタ責任者と更新ルールを決めます。開発会社に丸投げせず、業務部門が正解データを承認し、テストで過去の実見積と照合できる体制を用意します。

まとめ：CPQシステム開発はルールと定着まで設計します

社内稟議やRFP提出前に、対象業務、商品・価格マスタの責任者、例外価格の承認者、連携先、受入れ担当者、稼働後のKPIが決まっているかを確認します。未決定の項目があれば、開発会社の見積に含めるのか、自社の準備作業として期限を置くのかを分けて記載します。

まずは直近の実見積を集め、商品構成、価格計算、値引き承認、帳票、受注連携の5項目に分けて現状を書き出します。その資料をもとに、標準設定で始める範囲と将来拡張する範囲を決め、複数社へ同じ条件で相談します。小さく検証してから広げることが、費用と現場負担を抑えながらCPQを定着させる近道です。

CPQシステム開発は、見積画面を作るだけのプロジェクトではありません。要件整理で実見積と業務ルールを棚卸しし、選定で商材の複雑度・営業人数・既存CRM・Q2Cの範囲を比較し、設計開発で標準・拡張・運用の境界を決めます。その後、構成・価格・承認・連携を一体でテストし、パイロット稼働を経て、商品マスタとKPIを運用に組み込みます。

費用は、SaaSやパッケージのライセンスだけでなく、商品・価格データ、連携、移行、テスト、教育、保守を含めて検討します。見積を依頼するときは、商品数、ルール数、連携先、帳票、権限、監査ログ、SLA、データ返却を前提に書き、同じ実見積で複数社を比較します。高機能な製品を導入することより、正しい価格を再現でき、現場と管理部門が更新を続けられる仕組みを作ることが成果につながります。

▼全体ガイドの記事
・CPQシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。