期末の営業会議で、値引き率の一覧が配られる。同じ製品が顧客によって15%引き、22%引き、30%引きで売られている。理由を確認すると、それぞれに事情がある。競合対抗、長期契約、代理店経由。どれも間違っていません。しかし、この状態では「標準価格」という概念が実質的に存在していません。

もう一つの問題は受注後です。署名された見積はPDFになり、共有ドライブに保管される。契約期間と更新日はExcelの台帳に転記される。転記漏れが起きれば更新の機会を逃し、途中で契約内容が変わればどちらが最新か分からなくなります。

HubSpotの価格表（Price Books）と契約オブジェクトは、この2つの問題に対応する機能です。本記事では、HubSpot CPQと契約オブジェクトの公式ドキュメントに基づき、何を設定すれば価格の統制と契約の可視化が成立するのかを整理します。

価格表（Price Books）とは何か？

価格表は、同じ製品に対して複数の価格体系を持たせる仕組みです。製品ライブラリに登録した商材に対し、用途別の価格セットを定義します。

公式ドキュメントが挙げている用途は、紹介料金、パートナー価格、地域別価格です。いずれも「同じ製品だが、売り先や経路によって価格が違う」という状況に対応します。営業チームが販売プロセスの中で正しい製品と価格を使えるようにすることが目的とされています。

なぜ値引き率の管理では足りないのか？

ここが理解の分かれ目です。多くの組織は、標準価格を1つ持ち、値引き率で調整しています。この方式には構造的な問題があります。

値引きは「例外」として記録されるため、なぜその価格になったのかが残りません。30%引きが競合対抗だったのか代理店経由だったのかは、担当者の記憶か商談メモの中にしかありません。半年後に同じ顧客から追加発注が来たとき、どの価格を提示すべきかを判断できません。

価格表は、この「なぜ」を価格体系そのものに埋め込みます。代理店価格という価格表から見積を作れば、値引きの理由は記録に残ります。集計の際も、代理店経由の売上と直販の売上を価格体系で分離できます。値引き率の分布を眺めるより、経路別の利益率を見るほうが経営判断に使えます。

階段式・段階的な価格設定はどう扱うのか？

公式ドキュメントには、製品ライブラリが複数の価格設定モデルに対応しており、定額制、階段式、段階的料金のほか価格表も利用できると記載されています。

この2つは混同されやすい概念です。階段式は「100個までは単価A、101個以上は単価B」のように、超過分だけ単価が変わる方式です。段階的料金は「100個までなら全体が単価A、101個以上なら全体が単価B」のように、該当する段階の単価が全量に適用される方式です。ライセンス販売や従量課金の商材では、どちらを採用しているかで請求額が変わります。設定前に自社の商習慣がどちらかを確定させてください。

CPQの承認フローは何を統制するのか？

価格表を用意しても、そこから外れる見積が承認なしに出せる状態では統制になりません。承認フローがその役割を担います。

公式ドキュメントによれば、高度な承認はRevenue Hub Enterpriseで実装できます。値引き、金額、契約期間などの見積プロパティに基づいてルールを設定でき、承認者の順序も制御できます。

この「承認者の順序」が大企業では効きます。値引き率が一定を超えたら部門長、さらに超えたら本部長、契約期間が3年を超えたら法務——という多段の統制は、Excelの申請書とメールでは運用が破綻します。承認履歴が見積レコードに残ることも、内部監査への説明で重要です。

ProfessionalとEnterpriseの差はどこにあるのか？

選定の判断材料になるため、境界を明示します。CPQ自体はRevenue Hub Professional以上で利用できます。差が出るのは承認の高度化と電子署名の件数です。

4行目が実質的な分岐点です。承認が単一階層で済む組織はProfessionalで足ります。承認者が複数階層にわたり、条件によって経路が変わる組織ではEnterpriseが要件になります。5行目の署名件数も、月間の契約件数が多い組織では上限に当たります。エディション全体の比較はHubSpot Revenue Hubとは？旧Commerce Hubとの違いと料金で解説しています。

見積のAI生成と閲覧追跡は何に効くのか？

CPQには価格統制以外の機能も含まれます。実務での効きどころが分かりにくいため、2点だけ補足します。

1つは見積の生成です。公式ドキュメントには、取引情報に基づいてAIが見積を生成する機能が記載されています。テンプレートは自社仕様にカスタマイズでき、電子署名・クリック承認・印刷署名から受諾方法を選べます。効果が出るのは、見積の作成件数が多く、かつ構成が定型的な商流です。1件あたり数十分の作業が短縮されるため、月間数十件を出す組織では実働時間に表れます。

もう1つは買い手のエンゲージメント追跡です。見積が閲覧されたか、ダウンロードされたか、印刷されたかを記録できます。この情報が効くのは追客のタイミング判断です。「送ったが反応がない」と「開いてもいない」は、取るべき行動が違います。前者は条件の再検討、後者は担当者に届いているかの確認です。従来はこの区別ができず、一律のリマインドを送っていました。

契約オブジェクトは何を解決するのか？

契約オブジェクトは、確定した収益の単一の記録として機能します。公式ドキュメントは、取引全体を通じて一回限りおよび継続的な製品・収益指標・変更を記録する対象として位置づけています。

ここで重要なのは、契約が「見積の控え」ではないという点です。見積は提案時点のスナップショットですが、契約は期間中に変化します。増額、ダウングレード、更新。この変化を追跡できる器として設計されています。

契約はどうやって作られるのか？

作成経路は2つあります。設定で「承認された見積から自動的に契約を作成する」を有効にしている場合、見積が承認された時点で自動生成されます。もしくは手動で作成することもできます。

自動生成を有効にするかどうかは、運用設計の判断です。有効にすると漏れがなくなる一方、承認された見積すべてが契約レコードになります。試算用の見積や、内示だけで実際には契約に至らないケースが多い商流では、不要なレコードが増えます。運用開始前に、見積の承認をどの意味で使っているかを確認してください。

取引・見積・請求書・サブスクリプションとの関係はどうなるのか？

オブジェクトが5つ登場するため、役割の整理が必要です。公式ドキュメントの記載に沿って並べます。

この5層構造で押さえるべきは、取引と契約が別物であることです。取引は「受注できるかどうか」を追う器であり、受注した時点で役割を終えます。契約は受注した後の期間を通じて生き続けます。従来のCRMで受注後の情報が抜け落ちていたのは、取引だけで管理していたためです。

契約の途中変更と更新はどう扱うのか？

ここが契約オブジェクトの本題です。公式ドキュメントには、変更管理と更新管理の仕組みが記載されています。

途中の変更——拡大、アップグレード、ダウングレード——は「変更見積」を通じて管理します。契約の更新は「更新見積」で処理し、承認されると新しい契約が自動的に作成されます。設定を有効にすると、途中変更が日割りベースで按分計算されます。

この按分計算の扱いは、経理部門との合意が必要な項目です。日割り計算のルールが自社の会計処理と一致しているかを、運用開始前に確認してください。ツール側の計算結果をそのまま請求に使うのか、参考値として使って請求は基幹システムで行うのか。この切り分けを曖昧にすると、二重管理が始まります。

契約レコードで何が見えるようになるのか？

可視化される項目は、経営が見たい指標とほぼ一致します。公式ドキュメントが挙げているのは、ステータス、総契約価値（TCV）、年間契約価値、月間および年間経常収益（MRR／ARR）、請求詳細、更新日、そして関連するコンタクト・企業・取引・請求書・見積などのレコードです。

MRR／ARRがレコード単位で持たれることの意味は大きいです。従来、これらの指標は経営企画がExcelで集計していました。契約レコードに持たせれば、レポートで即座に集計でき、更新日を起点としたワークフローも組めます。RevOpsの指標設計において、この受注後の可視化が最も抜けやすい領域です。詳しくはRevOpsとは？日本の大企業で機能させる組織設計と実装手順で解説しています。

法務が管理する契約書とは何が違うのか？

ここは必ず確認される論点です。公式ドキュメントには、契約は法的契約書に置き換わるものではなく、カスタムプロパティで法的文書を参照できる旨が明記されています。

つまり、契約オブジェクトは収益管理の器であり、契約書のバージョン管理やレビュー機能を備えた契約管理システム（CLM）ではありません。法務部門が使うレビュー・締結・保管の機能が必要な場合は、専用システムとの併用になります。

実務上の設計としては、契約レコードに法的文書の格納場所へのリンクを持たせる構成が現実的です。営業と経理は契約レコードで収益情報を見て、法務は文書管理システムで原本を管理する。両者をIDで紐づけておけば、監査時に追跡できます。この住み分けを最初に決めておかないと、「契約書はどこにあるのか」という問いに答えられない状態になります。

導入にはどのシートが必要なのか？

費用の積算で見落とされやすい点です。公式ナレッジベースによれば、契約の作成・編集にはRevenue Hubシートが必要です。

一方、コアシートの保有者はRevenue Hubの見積を閲覧できますが、作成・編集はできません。したがって、シート数の積算は次の3分類から始まります。見積・契約を作る人、承認する人、閲覧するだけの人。承認者が閲覧のみで足りる運用であれば、承認者分のRevenue Hubシートは不要になる可能性があります。

ただし高度な承認フローを使う場合、承認操作にどのシートが必要かは実際の権限設定に依存します。稟議前に営業担当者へ確認してください。シート制の全体像はHubSpotのシートとは？コアシートとビューオンリーの違いと選び方で整理しています。

価格表と契約オブジェクトを導入すべきか

公正に評価します。すべての商流に必要な機能ではありません。

右列に多く該当する場合、価格表と契約オブジェクトの導入効果は限定的です。その場合は見積の作成と送付までをHubSpotで扱い、契約管理は既存の運用に残す構成が現実的です。株式会社100が収益プロセスの設計を支援する際も、全機能の導入を前提にせず、どの区間をCRMに載せるかを先に決めています。載せる区間が広いほど設計負荷は上がり、データの分断は減ります。このトレードオフを経営が理解した状態で範囲を決めることが、プロジェクトの成否を分けます。

よくある質問

価格表はいくつまで作れますか？

公式ドキュメントに具体的な上限の記載は確認できませんでした。上限が設計に影響する場合は、Product & Services Catalogおよび営業担当者にご確認ください。

契約オブジェクトはSales Hubだけで使えますか？

使えません。Revenue Hub Professional以上が必要で、作成・編集にはRevenue Hubシートが必要とされています。

すでに使っている見積機能はどうなりますか？

Sales Hubの従来の見積とRevenue Hubの見積には違いがあり、公式ドキュメントに比較ページが用意されています。移行を検討する際は、この比較で現在使っている機能が新しい見積で維持されるかを確認してください。

承認された見積すべてを契約にすべきですか？

商流によります。自動生成を有効にすると漏れはなくなりますが、内示段階の見積が多い商流では不要なレコードが増えます。見積の承認を自社がどの意味で使っているかを確認してから決めてください。

日割り計算の結果をそのまま請求に使えますか？

自社の会計処理と一致するかを経理部門と確認してください。一致しない場合は、契約レコードの数値を参考値とし、請求は既存システムで行う構成が安全です。両方で発行できる状態を残すと不整合が起きます。

契約書の原本はどこに保管すればよいですか？

契約オブジェクトは法的契約書に置き換わるものではありません。原本は文書管理システムまたは契約管理システムに置き、契約レコードのカスタムプロパティから参照する構成が現実的です。

MRR・ARRは自動で計算されますか？

契約レコードで総契約価値、年間契約価値、月間および年間経常収益が確認できる旨が公式ドキュメントに記載されています。計算のロジックが自社の定義と一致するかは、実データで検証してください。同じARRという語でも、企業ごとに定義が異なります。

代理店経由の売上を分けて集計できますか？

価格表を経路別に分けておけば、どの価格体系から生成された見積かが記録に残ります。値引き率で管理する方式では、この分離は困難です。集計要件が明確な場合は、価格表の設計をその要件から逆算してください。

本記事はHubSpot公式ナレッジベースおよび製品ページの公開情報（2026年9月1日取得時点）に基づいて作成しています。価格は米国価格ページの表示であり、日本での実際の請求額は契約通貨・契約条件によって異なります。仕様・エディション要件は変更される可能性があるため、導入判断の際は公式ドキュメントおよび営業担当者による最新の見積をご確認ください。