「Commerce Hubの契約を更新しようとしたら、見積書の製品名がRevenue Hubに変わっていた」——2026年6月以降、こうした問い合わせが増えています。社内稟議に添付した資料の製品名と、HubSpotから届いた見積書の製品名が一致しない。情報システム部門からは「これは別製品の追加購入なのか」と確認が入る。DX推進の責任者にとって、この種の説明コストは軽視できません。

結論から言えば、Revenue Hubは新規に追加された別製品ではなく、Commerce Hubの後継です。ただし「名前が変わっただけ」でもありません。HubSpot公式のRevenue Hub製品ページのFAQには、次のように明記されています。「Revenue Hub is the evolution of Commerce Hub. Commerce Hub was HubSpot's home for billing and payments. Revenue Hub expands that into the full revenue process」——請求と決済の置き場だったものを、収益プロセス全体に広げた、という説明です。

本記事では、この「拡張」が実務上どこに効くのかを、公式ページとナレッジベースの記載に基づいて整理します。あわせて、既存のCommerce Hubユーザーが実際に手を動かす必要がある箇所と、まったく不要な箇所を切り分けます。

Revenue Hubとは何か？Commerce Hubから何が変わったのか？

まず押さえるべきは、この変更が「請求ツールのリブランド」ではなく「CRMが扱う業務範囲の拡張」だという点です。Commerce Hubは2023年の登場以来、見積の後工程——請求書、支払いリンク、サブスクリプション課金——を担当する製品でした。取引が成立した後の処理を、外部の請求システムに渡さずHubSpot内で完結させることが主眼です。

Revenue Hubはこの範囲を前工程に伸ばしました。製品ページが掲げるメッセージは「Quote, bill, and collect — all through HubSpot」です。見積（Quote）から請求（bill）、回収（collect）までを一つの流れとして扱う、いわゆるQuote-to-Cashの領域が製品の輪郭になりました。

名称変更だけなのか、それとも製品範囲の拡張なのか？

両方です。この二重性が混乱の原因になっています。整理すると、Commerce Hubで提供されていた機能は一つも失われていません。請求書、支払いリンク、サブスクリプション、Stripe連携は継続します。一方で、CPQ・契約オブジェクト・価格表といった要素が製品の中核として位置づけ直されました。

つまり、既存ユーザーから見れば「使っている機能はそのまま、使える範囲が広がった」という変化です。新しい製品を買い直す必要はありません。

なぜ「Commerce」から「Revenue」へ言葉が変わったのか？

言葉の選択には設計思想が表れます。Commerce（商取引）は、一件の取引が成立し、代金が支払われ、そこで完結する単位を指します。Revenue（収益）は、契約の更新・アップセル・契約変更を含む、時間軸を持った関係を指します。

この違いは、サブスクリプション型やリカーリング型のビジネスに移行しようとしている企業にとって本質的です。中期経営計画で「モノ売りからコト売りへ」「サービス化」を掲げた製造業の場合、売上の計上単位が「出荷」から「契約期間」に変わります。このとき、見積・契約・請求・入金が別々のシステムに分かれていると、契約変更が起きるたびに手作業の突合が発生します。私たちが製造業のCRM導入を支援する際も、サービス化の進捗を数字で追えるかどうかは、受注後の契約変更をCRM上のレコードとして持てているかで決まっています。Revenue Hubが担うのは、この受注後の領域です。

Revenue HubとCommerce Hubの機能はどこが違うのか？

次に、実際の機能差を確認します。ここで注目すべきは機能名の一覧そのものよりも、「どの業務が社外システムから社内CRMに移るか」という点です。移る業務が多いほど、初期の設計負荷は上がりますが、データの分断は減ります。

表の各行を上から下へ読むと、変化の方向が見えます。追加されたのは「取引が成立する前」と「成立した後の継続的な関係」の両端です。中央部分——請求と決済——は変わっていません。既存ユーザーの運用が壊れないのは、この構造のためです。

見積からCPQへ：価格ルールと値引きガードレールは何を解決するか？

CPQはConfigure, Price, Quoteの略で、製品構成・価格決定・見積作成を一連のルールとして扱う仕組みです。公式ページは「Build quotes, apply pricing rules, and add discount guardrails」と説明しています。

実務で効くのは「guardrails（ガードレール）」の部分です。従来、値引き率の上限は営業部門のルールブックに書かれていて、遵守は個人の記憶に依存していました。期末になると、承認を取らないままの値引きが混入します。ガードレールは、この統制をツール側に持たせる機能です。1,000名規模の営業組織で「ソリューション営業への転換」を掲げている場合、価格の一貫性は転換の前提条件になります。値引きが属人的なままでは、提案内容ではなく価格で決まる商談から抜け出せません。

見積作成そのものの手順は、公式ナレッジベースの見積作成ガイドに記載があります。

契約（Contracts）という新しいオブジェクトは何を解決するか？

公式ページは契約について「Turn signed quotes into structured contract records automatically」と説明しています。署名された見積を、構造化された契約レコードに自動変換する、という意味です。

この一文の重要性は、契約書がどこに保管されているかを思い出すと分かります。多くの企業では、署名済みPDFが共有ドライブか法務部のフォルダにあり、契約期間・更新日・自動更新条項はExcelの管理台帳に転記されています。転記漏れが起きると更新の機会を逃し、条件変更の履歴は追えなくなります。契約がCRM上のレコードになれば、更新日を起点としたワークフローが組め、取引・請求・顧客レコードとの関連づけが保たれます。

電子署名は公式ページによればProfessionalで1ユーザーあたり月25件、Enterpriseで月50件が含まれます。署名件数が多い組織では、この上限が実質的なエディション選定の基準になります。

請求・決済・サブスクリプションは何が変わらないのか？

変わらない部分を明示しておくことは、社内説明において重要です。稟議で最も嫌われるのは「何が壊れるか分からない変更」だからです。

請求書の発行、支払いリンク、サブスクリプション課金、Stripe接続は、いずれも従来どおり動作します。決済手段はクレジットカード、ACH、定期支払い、支払いリンクに対応し、決済基盤はHubSpot Payments（米国・英国・カナダ）またはStripeを利用します。日本国内で運用する場合、HubSpot Paymentsの提供地域に日本が含まれない点は設計上の制約になるため、Stripeまたは既存の決済・会計システムとの連携が前提になります。決済の設定手順と請求書の作成・管理は、それぞれ公式ナレッジベースに記載があります。

また、Stripe・QuickBooks・Xeroといった既存の収益系ツールからデータを取り込む「External revenue integrations」も提供されています。全面移行ではなく、既存の会計システムを残したまま収益データをCRM側に集約する、という選択肢が用意されている点は、基幹システムの入れ替えが容易でない大企業にとって実務的です。

Revenue Hubの料金体系はどうなっているのか？

料金を見るときは、月額単価そのものより「どのエディションから何が使えるか」を先に確認してください。Revenue Hubは無料版でも請求書と決済が使えるため、単価表だけを見ると割高に見えますが、実際の判断材料は機能の境界線にあります。

境界線は明確です。「請求と決済だけ」ならFreeで足ります。「見積の統制と契約管理」を求めた瞬間にProfessional以上が必要になります。そしてEnterpriseとの差は、承認フローの高度化と署名件数の上限という、いずれも組織規模に比例する項目です。承認者が複数階層にわたる企業では、Enterpriseの見積承認が要件になる可能性が高くなります。

Revenue SeatとCore Seatはどう使い分けるのか？

Revenue Hubを検討する際に見落とされやすいのが、シートの種類による権限差です。公式ナレッジベースのシート解説によれば、Revenue Seatは有料シートで、ProfessionalまたはEnterpriseでのみ提供され、Revenue Hubの全機能にアクセスできます。

一方、Core Seatの保有者はRevenue Hubにおいて見積を「閲覧」できますが、作成・編集はできません。ここを誤解したまま人数を積算すると、稟議後に「見積を作れる人が足りない」という事態になります。誰が見積を作り、誰が承認し、誰が閲覧するだけなのか——この3分類を先に確定させてから、シート数を算出してください。シート制の全体像はHubSpotのシートとは？コアシートとビューオンリーの違いと選び方で詳しく解説しています。

日本での価格と併売条件はどうなっているのか？

日本語の価格ページには、Sales Hubとの併売条件が掲示されています。HubSpot日本語版のセールス価格ページには、2026年8月31日時点で次の記載があります。「Sales Hubをご購入いただくと、年間契約であればRevenue Hub Professionalを月額￥6,840／シート（通常月額￥11,400／シート）、またはEnterpriseを月額￥11,760／シート（通常月額￥16,800／シート）でご利用いただけます。新規のSales HubおよびRevenue Hubのお客さま限定です」

この条件は新規顧客限定であり、期間や内容が変更される可能性があります。実際の見積は必ず営業担当者に確認してください。なお、HubSpot全体の料金体系については【2026年最新版】HubSpot料金プラン解説にまとめています。

既存のCommerce Hubユーザーは何をすべきか？

移行作業の有無を切り分けます。システム側で必要な作業と、社内の情報整備として必要な作業は、性質が異なります。前者はほぼ発生せず、後者は確実に発生します。

システム側の移行作業は発生するのか？

データ移行やアカウントの切り替え作業は発生しません。既存の見積・請求書・サブスクリプション・決済連携はそのまま稼働します。ユーザーの操作画面上も、製品名の表記が変わる以外に破壊的な変更は案内されていません。

ただし、追加された機能——CPQの価格ルール、契約オブジェクト、価格表——は、有効化して設計しなければ使われません。導入済みだからといって自動的に恩恵があるわけではない点は、社内の期待値調整として明示しておくべきです。

社内ドキュメントの表記更新をどう進めるか？

ここが実務上の本丸です。製品名の改称は、単なる表記の問題では終わりません。放置すると具体的な実害が出ます。

第一に、社内マニュアル・研修資料・稟議テンプレートに旧称が残ると、新任担当者が旧称で検索し、公式ドキュメントにたどり着けません。第二に、ナレッジベース記事に旧称が残っている場合、顧客対応エージェントがその記事を根拠に回答するため、廃止済みの名称で顧客に案内する事態が起こります。AIエージェントを運用している組織ほど、名称の統一は運用品質に直結します。

なお、HubSpotでは同時期に他の改称も進んでいます。Operations HubはData Hubへ、Breeze AgentsはAgent Hubへと名称が変わりました。旧称のまま残っている資料を洗い出す際は、これらもあわせて確認してください。Data HubについてはHubSpot Data Hub（旧Operations Hub）とは？、Agent HubについてはHubSpot Agent Hubとは？旧Breeze Agentsとの違いと料金で整理しています。

なぜ「収益プロセスをCRMに載せる」ことが経営課題なのか？

ここまでは製品仕様の話でした。最後に、この変更が経営レベルでどう効くのかを述べます。ツールの機能追加としてではなく、収益プロセスの統制という観点から見る必要があります。

見積から入金までの分断は何を引き起こすか？

典型的な分断はこうです。見積はExcelで作られ、承認はメールで回り、契約書は共有ドライブに置かれ、請求は基幹システムで発行され、入金消込は経理が別のファイルで管理する。それぞれの工程は正しく動いていますが、全体を通した数字は誰も即答できません。

この状態で「パイプラインの可視化」を掲げても、可視化できるのは商談までです。受注後の契約変更・追加発注・更新は視界の外に出ます。サービス化を進める企業ほど、収益の大半が受注後に発生するため、この盲点は大きくなります。Revenue Hubが統合しようとしているのは、まさにこの受注後の領域です。

AIエージェントを動かす前提としてのSSOTはなぜ必要か？

もう一つの論点はAIです。HubSpotは2026年7月にAgent HubとAgent Builderをパブリックベータで公開し、CRM上で自律的に動くエージェントの基盤を整えました。Revenue Hubにも、延滞請求の督促を代行するRevenue agentが近日ベータとして案内されています。

ただし、エージェントは参照できるデータ以上のことはできません。契約情報がCRMの外にあれば、契約に基づく判断は下せません。「AIを使いたい」という要望が経営から降りてきたとき、実際に必要なのは、AIが読める形でデータを一箇所に置くこと——単一の情報源（SSOT）の整備です。Revenue Hubの導入判断は、AI活用の前提整備という文脈で捉えたほうが、社内の合意を得やすくなります。

Revenue Hubを導入すべき企業・見送るべき企業はどこで分かれるか？

公正に比較します。すべての企業に適しているわけではありません。判断を分けるのは、既存の基幹システムとの関係です。

右列に多く該当する場合、Revenue Hubの全面導入ではなく、見積・契約までをHubSpotで扱い、請求以降は既存システムに残す構成が現実的です。External revenue integrationsを使えば、請求と会計を既存システムに残したまま、収益データだけをCRM側へ集約できます。基幹システムの入れ替えを前提にしないため、私たちが大企業の導入を設計する際も、この構成を初期フェーズの標準案として提示しています。

なお、株式会社100はHubSpotのエリートパートナーとして、CRMの全社導入における部門間の利害調整や定着化の設計を数多く支援してきました。収益プロセスの再設計は、ツールの設定作業よりも、営業・経理・法務の業務分担を決め直す作業のほうが重くなります。この配分を見誤ると、システムは完成しても運用されません。

よくある質問

Commerce Hubの契約を継続していますが、追加費用は発生しますか？

公開されている情報の範囲では、名称変更に伴う追加費用は案内されていません。ただし、CPQや契約管理といった機能はProfessional以上の範囲であるため、現在Freeまたは下位の構成で利用している場合、新機能を使うにはエディションの変更が必要です。契約条件は個別に異なるため、正確な内容は営業担当者にご確認ください。

Revenue Hubだけを単体で契約できますか？

製品ページ上はエディション別の価格が提示されており、単体での検討は可能です。ただし日本語の価格ページに掲載されている割引条件はSales Hubとの併売が前提になっています。単体購入時の価格は営業担当者にご確認ください。

日本国内でHubSpot Paymentsは使えますか？

公式ページに記載されているHubSpot Paymentsの提供地域は米国・英国・カナダです。日本国内で決済まで完結させる場合は、Stripe連携または既存の決済手段との併用が前提になります。この点は導入設計の初期段階で確認しておく必要があります。

契約オブジェクトは既存の契約書管理システムを置き換えますか？

置き換えを前提とした設計にはなっていません。契約レコードは、契約の条件・期間・関連する取引をCRM上で参照可能にするものであり、契約書のバージョン管理やレビュー機能を備えた専用の契約管理システム（CLM）とは目的が異なります。法務部門が使うレビュー機能が必要な場合は、併用が現実的です。

Core Seatしか持っていない担当者は、見積の内容を確認できますか？

確認できます。公式ナレッジベースには、Core Seatの保有者はRevenue Hubの見積を閲覧できるが作成・編集はできない旨が記載されています。承認者が閲覧のみでよい運用であれば、承認者分のRevenue Seatは不要になる可能性があります。

すでに基幹システムで請求を行っています。二重管理になりませんか？

そのリスクはあります。回避するには、どちらを正とするかを先に決めてください。請求の正が基幹システムであれば、HubSpot側では請求データを参照専用として取り込み、発行は行わない構成にします。両方で発行できる状態を残したまま運用を始めると、必ず不整合が起きます。

社内資料の「Commerce Hub」表記は、いつまでに直すべきですか？

公開されている顧客向けコンテンツ（ナレッジベース記事、FAQ、ウェブサイト）を優先してください。AIエージェントや検索経由で顧客の目に触れる可能性があるためです。社内マニュアルは、次回の改訂タイミングでまとめて更新する運用で実務上は足ります。

Revenue agentはいつから使えますか？

公式ページ上は「近日ベータ提供」として案内されており、本記事執筆時点で一般提供の日程は公開されていません。導入計画にRevenue agentを前提として組み込むことは避け、提供開始後に評価する前提で計画してください。

本記事はHubSpot公式サイト・公式ナレッジベース・Product & Services Catalogの公開情報（2026年8月31日取得時点）に基づいて作成しています。価格・提供地域・エディション要件は変更される可能性があるため、契約判断の際は公式ドキュメントおよび営業担当者による最新の見積をご確認ください。