HubSpotの年次カンファレンス「UNBOUND 2026」より、セッション「HubSpot CPQ in the UNreal World」の様子をレポートします。記事の前半ではセッション内容を整理し、後半では株式会社100の解説として、日本企業が実務にどう取り入れるべきかの実践ポイントをまとめます。

この記事のポイント

• CPQの3つの土台と拡張の鉄則：「価格表」「UI拡張」「ルールエンジン」の標準機能を土台とし、4つの基準をすべて満たす箇所にだけ最小限の独自拡張を足します。
• 複雑な構成と多拠点契約の実装：10万品目から適合部品を絞る構成ツールや、50店舗の多拠点契約を拠点別の継続課金へ分割して標準管理へ戻す実例が紹介されました。
• 日本企業での実践ステップ：Excel見積書の再現を目指して独自開発に踏み切る前に標準機能の範囲を見極め、「選ばせない入力設計」と価格整理から段階的に進めます。

出典：株式会社100作成のセッションまとめ資料

セッション情報

※本記事のセッション内容は、株式会社100がまとめたものです。「株式会社100の解説」は当社の見解に基づきます。

セッションの内容は、以下のまとめ資料（PDF）でもご覧いただけます。 まとめ資料を開く（PDF）

なぜ現実の見積もりは標準機能だけでは難しいのか？

見積書を出す前後の「製品構成・価格の判断」や、受注後の「契約変更・多拠点課金」に難しさが集中しているためです。

本セッションでは、HubSpotのEthan Kopit 氏、Imaging Business Machines, LLC（以下、IBML）のTiffany Cavegn 氏、1406 ConsultingのRich Walsh 氏が登壇し、Revenue HubとCPQ（製品構成・価格設定・見積もり作成の仕組み）の実践的な活用法を語りました。

売り手側の複雑さの例として、Cavegn 氏はIBMLの事業を挙げました。同社は高速文書スキャナー、AIソフト、保守、導入支援、スキャン代行を扱っており、販売形態も「一括購入」「継続サービス」「SaaS」「年額保守」「文書1件ごとの従量課金」の5通りが存在します。商談途中での方式変更や、1案件の明細が1,200件を超えることも珍しくありません。

買い手側の複雑さの例として、Walsh 氏は小売グループへ冷凍設備と遠隔監視ソフトを販売する事例を挙げました。契約の署名は本社1社ですが、実際の課金対象は導入月や更新条件が異なる50の店舗であり、契約途中の店舗追加も発生します。標準の見積もり機能では「数量50」を1本の継続課金として扱ってしまうため、拠点別の管理が破綻してしまいます。

標準エンジンと拡張レイヤーをどう使い分けるのか？

「4つの問い」で独自の仕組みが必要かを見極め、標準の土台に最小限の拡張だけを載せるのが鉄則です。

Walsh 氏は、標準エンジンを土台に拡張を組み合わせる設計思想を示し、開発前に「何を作らないか」を決めるための4つの問いを提示しました。

• 請求単位： 請求対象は、署名する顧客よりも小さい単位か？（例：本社1社が署名し、複数拠点で利用・課金するなど）
• 契約の混在： 同じ取引内に「12カ月固定」と「期限のない継続課金」など、異なる契約形態が混在するか？
• 事前計算： 営業担当者は見積もりを作る前に、表計算ソフトや頭の中で保守料などを計算しているか？
• 途中変更： 署名後も、製品追加や価格改定、解約、拠点追加などを契約途中で変更できるか？

出典：株式会社100作成のセッションまとめ資料

Walsh 氏は「これら4つすべてに当てはまるときだけ、独自の拡張を作るべきだ」と強調します。 IBMLもHubSpotチームと6カ月間伴走し、自社の要件がRevenue Hubの標準機能でどこまで扱えるかを徹底的に検証しました。そのうえで、不足する部分だけにUI拡張（画面に独自機能を加える仕組み）や見積もりテンプレートの独自モジュール、カスタムオブジェクト、ワークフローを載せ、最終的な出力結果は「標準の見積もりや契約レコード」に戻す設計をとっています。

HubSpotのCPQを支える土台には何があるのか？

条件付きの「価格表」、画面を制御する「UI拡張」、AIで記述できる「ルールエンジン」の3つが中核です。

Kopit 氏は、見積もりテンプレートの調整に加え、「誰にいくらで売るか」「どう構成させるか」「何を禁止するか」を担う3つの土台について説明しました。

出典：株式会社100作成のセッションまとめ資料

1つ目の「価格表」は、製品ライブラリから代理店、地域・国、顧客階層、業界別の価格を作成し、リストと同様のフィルター条件で自動割り当てする機能です。一回払い、継続課金、段階価格、複数通貨に対応しており、今後はバンドル販売、期間で単価が変わる価格、計算式による価格設定も追加される予定です。

2つ目の「UI拡張」は、管理者が営業画面を柔軟に制御できる共通機能です。既定の明細表の代わりに、質問に答えるだけで明細が組まれるガイド型の販売画面や、価格計算機を作成できます。科学機器の販売を想定した実演では、Claudeを用いて構築した画面上で用途など7つの質問に答えると、推奨明細の下書きが自動生成される様子が披露されました。

3つ目の「ルールエンジン」は、利益率や値引き制限、製品構成の条件、契約期間や支払条件を制御する仕組みです。専用の記述言語が必要ですが、HubSpotのAI機能を使って自然言語から生成・修正できるため、管理者の学習負担を大幅に減らせます。実演では、特定機器を含む初回見積もりで「保守契約または現地設置のいずれかを必須とし、満たさない場合は見積もりの公開をブロックする」例や、「変更見積もりではロボットに保守を付けない」といった制御例が示されました。

導入企業は複雑な見積もりと多拠点契約をどう実装したのか？

「迷わせない入力・構成の仕組み」と「拠点別の分割処理」だけを独自に足し、標準の契約管理へ戻す実装を行っています。

Cavegn 氏は、IBMLが定番の移設見積もりを約90秒で作成する実演を行いました。その核となるのは「営業担当者に選ばせないこと」です。 取引作成フォームの条件分岐で必要項目だけを表示し、事業部門を選ぶと法人格と通貨が自動で決まります。請求先・初回配送先・最終設置先の3種類の住所はワークフローで取引レコードに集約し、パーソナライズトークンで見積書へ流し込みます。定番の3つのSKU（品目の管理番号）はテンプレートに事前構成されており、担当者は署名者を選んで確認するだけで顧客へ共有できます。

またIBMLは、約10万点の品目（営業が扱うのは約4,000 SKU）から適合部品を絞り込む「構成ツール」を、テンプレートの独自モジュールとカスタムコードで構築しました。これにより、25〜30明細の見積もりや複数機種の比較見積もりを迅速に作成できます。保守の付け忘れを防ぐため、既定で2つの保守明細を自動追加し、保守料は「明細合計×サービス水準別の料率」で自動計算され、送信時に取引明細へ追加されます。

出典：株式会社100作成のセッションまとめ資料

続いてWalsh 氏は、「本社1社が署名し、50店舗へ導入する」冷凍設備企業向けの実装例を紹介しました。1店舗あたり初期費用12,500ドル・月額425ドルという想定で、独自に拡張したのは「取引画面上の3段階の見積もり作成UI」と「受注時に拠点別の継続課金へ分割する仕組み」の2点だけです。

拠点と製品を選ぶと数量が拠点数に連動し、「12カ月固定」と「期限のない継続課金」は2本の見積もりに自動分割されます。受注後は各拠点が個別の継続課金レコードを持ち、本社レコードに全体の収益が集計されます。契約分割や日割り計算、更新、解約、請求といった後続処理はすべてHubSpotの標準機能に戻すことで、「入社初日の新人でも、20年目のベテランと同じ見積もりを出せる仕組み」を実現しました。

出典：株式会社100作成のセッションまとめ資料

株式会社100の解説：日本企業はHubSpotでどう実践すべきか？

ここからは株式会社100の見解として、日本企業が自社の見積もり業務を改善する際のステップを解説します。（※各機能を導入する際は、ご契約中のHubSpotプランで利用可能かを事前にご確認ください）

1. 独自開発の前に「4つの問い」で標準機能の範囲を見極める

日本企業では、既存のExcel見積書のレイアウトや複雑な商習慣をそのままシステム上で再現しようとして、カスタマイズが肥大化しがちです。まずはセッションで示された「4つの問い」を用い、標準機能で対応できる範囲を切り分けることから始めましょう。単一拠点のシンプルな取引は標準のテンプレートとワークフローで自動化し、どうしても標準では扱えない「多拠点課金」や「複雑な構成計算」だけをUI拡張やカスタムオブジェクトで補う設計が有効です。

2. 「選ばせない入力設計」と「価格表」で営業の属人化を防ぐ

代理店や顧客ランク別の単価設定、必須保守の付け忘れなど、営業個人の記憶や手計算に頼る運用は多くの現場で課題となっています。まずは会社や取引のプロパティで顧客区分を明確に定義し、条件に応じて自動で「価格表」が割り当たる状態を作ることが先決です。さらにIBMLの事例のように、よく使う定番SKUや必須の保守明細を見積もりテンプレートに事前構成しておくことで、入力の手間とミスを同時に減らすことができます。

3. 値引きや構成の「暗黙のルール」を言語化し、ガードレールにする

日本の営業現場では、値引き上限の確認や付帯サービスの有無が「上長への口頭相談」や「承認時の差し戻し」によって担保されているケースが少なくありません。ルールエンジンを活用する際は、いきなりシステム設定に入るのではなく、まずは製品の依存関係や利益率の基準を「自然な日本語で書き出すこと」から始めましょう。整理した条件をもとにAI機能でルールを生成したり、ワークフローを組んだりすることで、見積もりを顧客へ公開する前にルール違反を自動で防ぐガードレールが構築できます。

よくある質問（FAQ）

Q1. 複雑な見積もり業務では、最初から独自の画面を開発すべきですか？

いいえ。Walsh 氏は「請求単位が契約単位より小さいか」「異なる契約形態が混在するか」「事前計算が必要か」「署名後に途中変更があるか」という4つの問いすべてに当てはまるときだけ拡張を作るべきだと述べています。まずは自社の契約プランで使える標準機能での対応を検証し、独自開発を最小限に絞る進め方を推奨します。

Q2. 品目数が多く、製品の組み合わせが複雑な場合でも対応できますか？

対応可能です。IBMLは、約10万点の品目から機種に合う部品だけを絞り込む構成ツールを構築し、さらに保守明細を自動計算して既定で追加する工夫で記載漏れを防いでいます。まずは主要製品と付帯サービスの依存関係を整理し、定番のSKUをテンプレートに事前構成するといった段階的なアプローチが有効です。

Q3. 専門的なプログラミング知識がなくても、見積もりのルールを設定できますか？

はい。Kopit 氏によると、ルールエンジンの専用記述言語はHubSpotのAI機能を使って自然言語（日常の言葉）から生成・修正できるため、管理者の学習負担を大幅に下げられます。システム設定の前に、営業部門と管理部門の間で「値引きの上限」や「必須構成の条件」を言葉で明確に書き出しておくことが成功のポイントです。

Q4. 本社が一括契約して複数店舗へ導入するような取引は、どう管理しますか？

Walsh 氏が示した実装例では、「3段階の見積もり作成画面」と「受注時に拠点別の継続課金へ分割する仕組み」の2点だけを独自に拡張しています。これにより、本社1社の署名で50店舗へ導入するような取引でも、拠点ごとの更新管理と本社での収益集計を両立させました。分割した後の契約管理や日割り計算、請求処理はすべてHubSpotの標準機能に戻す設計が鍵となります。

まとめ

本セッションでは、HubSpotのCPQにおいて「価格表」「UI拡張」「ルールエンジン」の3つを土台とし、必要な箇所にだけ最小限の拡張を足す設計思想と、IBMLおよび1406 Consultingの実践事例が示されました。適合部品を絞り込む構成ツールや、多拠点契約を拠点別の継続課金に分割して標準の契約管理へ戻す仕組み、そして営業に選ばせない入力設計や価格表の自動割り当ては、入力の手間やミス、属人化を防ぎつつ、複雑な価格や製品構成の見積もりを速く正確に作るうえで非常に有効です。まずは独自開発に踏み切る前に、4つの問いを用いて標準機能で対応できる範囲を見極め、顧客区分の定義や暗黙のルールの書き出しから段階的に始めてみてはいかがでしょうか。

株式会社100では、標準機能とUI拡張やカスタムオブジェクトの適切な切り分けから、価格表や見積もりテンプレートを用いた選ばせない入力設計、ルールエンジンによるガードレールの構築まで、日本企業の複雑な商習慣に合わせた見積もり業務の改善を一貫してご支援しています。「既存のExcel見積書や複雑な価格計算をどこまで標準機能で再現できるかわからない」「顧客ランク別の単価設定や値引き確認が営業個人に属人化しており、ミスや差し戻しを減らしたい」といったお悩みをお持ちの方は、ぜひお気軽にご相談ください。