HubSpotで見積書を作ってみたものの、そのまま取引先に出せなかった、という相談を受けることがあります。金額も明細も正しいのに、宛名に「御中」が付かない、消費税の内訳が日本の様式と違う、適格請求書発行事業者の登録番号を書く場所がない、社印が押されていない。経理や法務から差し戻され、結局Excelのひな形に戻ってしまう。これは機能が足りないのではなく、標準設定が日本の商習慣を前提にしていないことから生じます。

本記事では、HubSpotの見積ツールを日本のBtoB取引で通用する形に整えるための設計を、宛名・敬称、消費税の内税／外税表示、インボイス制度の登録番号、有効期限、社印・角印、押印なし運用、見積番号の採番という7つの論点に分けて扱います。見積の作成手順そのものはHubSpotでの見積もり作成、製品管理方法を解説で扱っているため、本記事は「作れる状態から、出せる状態にする」工程に絞ります。

なぜHubSpotの見積書はそのままでは日本の商習慣に合わないのか？

HubSpotの見積テンプレートは、北米のBtoB取引を基準に組み立てられています。発行日・有効期限・通貨・PO番号をヘッダーに置き、明細と合計を示し、最後に電子署名で受諾を取る。この流れ自体は日本でも通用しますが、日本の見積書が慣習として備えている要素のいくつかが、標準のモジュール構成には含まれていません。

日本の見積書に慣習として求められる要素は何か？

日本のBtoB取引で差し戻しの原因になりやすいのは、法令上の必須要件ではなく慣習として期待されている項目です。受け取る側の購買部門や経理部門は、社内の検収フローに乗せるためにこれらを前提にした様式を求めます。何が法令で、何が慣習かを分けておかないと、テンプレートの改修がいつまでも終わりません。

HubSpotの標準モジュールはどこまでカバーしているのか？

見積テンプレートは、ヘッダー、当事者（Parties）、サマリー、明細、条件（Terms）、支払い、受諾の各モジュールで構成されます。ヘッダーモジュールでは、見積リファレンス・発行日・有効期限・通貨・PO番号の表示とラベルをそれぞれ編集でき、各項目は個別に非表示にできます。つまりラベル名は自由に変えられるため、「Quote reference」を「見積番号」、「Issue date」を「発行日」と置き換える作業は、テンプレート側で完結します。

一方で、明細テーブルに表示できる列は最大7列までです。列に収まらないプロパティは明細の下に行形式で表示する設計になっているため、日本の見積書でよく使われる「品名／数量／単位／単価／金額／備考」を全部列に並べると枠が足りません。どの情報を列に置き、どれを行に落とすかは、テンプレート設計の最初に決める必要があります。

まず確認すべき「自社がどちらの見積ツールを使っているか」とは？

日本向けの整備に入る前に、必ず確認しておくことがあります。HubSpotには現在、見積ツールが2系統あり、どちらを使っているかでカスタマイズの自由度がまったく違います。ここを確認せずにテンプレートを作り始めると、作ったものが移行できないという事態になります。

レガシー見積と現行の見積は何が違うのか？

現行の見積はRevenue Hub ProfessionalまたはEnterpriseで利用でき、見積の作成にはRevenue Hubシートが必要です。レガシー見積は新規ユーザーには提供されておらず、Sales Hubのアカウントで継続利用されている形です。

日本向けテンプレートの観点で効いてくるのは、カスタマイズ方式の違いです。レガシー見積はCMSのカスタムテーマとしてテンプレート全体をコードで書けるのに対し、現行の見積はモジュール単位でのカスタマイズになります。帳票そのものを自社の様式に寄せたい場合、レガシー側のほうが自由度は高く、現行側は公式ナレッジベース（Create custom modules to use on quote templates）にあるカスタムモジュールで不足分を補う形になります。

加えて、レガシー見積のテンプレートは現行の見積に引き継げません。移行する場合はテンプレートを作り直す前提で工数を見てください。私たちが移行を伴う案件で見積テンプレートの設計を行うときは、この作り直しを独立したタスクとして切り出し、既存の帳票レイアウトを先に紙で確定させてから着手しています。

自社がどちらを使えるかはどう判定するか？

Revenue Hub ProfessionalまたはEnterpriseのアカウントであれば、現行の見積を使います。それ以外のアカウントでは、2025年9月3日という基準日との関係で利用可否が決まります。Sales Hubのアカウントは同日以降も従来の見積を継続利用でき、同日以降に作成されたアカウント、または同日以降にSales Hubを追加したアカウントでは従来の見積を使えません。

見分けがつかない場合は、エディタの画面構成で判断できます。レガシー見積はタブ切り替え型、現行の見積は1ページのドラッグ＆ドロップ型です。シートの割り当てによって見えるツールも変わり、Revenue Hubシートを割り当てられると従来のテンプレートにアクセスできなくなる場合があります。Revenue Hub ProfessionalおよびEnterpriseでコアシートを割り当てられたユーザーは、見積の閲覧はできるが作成・編集はできません。シート設計と見積運用は連動させて決めてください。

宛名と敬称はどのレコードから決まるのか？

日本の見積書で最初に目に入るのは宛名です。ここが「株式会社◯◯」のままだと、受け取った側はまず「御中が抜けている」と指摘します。HubSpotの宛名はテンプレート側で固定するものではなく、取引やコンタクトのレコードから引かれるため、どこを直すべきかを押さえておく必要があります。

買い手情報はどこから引かれるのか？

当事者モジュールの売手側は見積の作成者のユーザープロフィールから自動で入り、売手の会社情報はアカウントの会社情報から入ります。買い手側は関連付けられた取引から、または見積の作成過程で追加します。請求先（Bill to）は見積作成時に指定し、連絡先・会社・住所・Tax IDを表示できます。

ここで重要なのは、買い手が受諾時に会社情報や住所を更新できる設定がある点です。見積作成時に会社が追加されていなかった場合、買い手は会社名と住所を入力でき、既に会社が追加されていた場合は住所のみ編集できます。さらに、買い手が受諾時に住所を更新すると、HubSpot側の会社レコードが更新されます。見積の宛名変更がCRMのマスタに波及するため、この設定を有効にするかどうかは、データガバナンスの観点から決めてください。SSOT（信頼できる唯一の情報源）とはで整理した考え方がそのまま当てはまります。

「御中」「様」をどう出し分けるか？

敬称を自動で付け分ける設定について、HubSpotの公式ドキュメントに記載は確認できませんでした。実務では次のいずれかで対応します。第一に、会社名プロパティとは別に「宛名表示用」のカスタムプロパティを作り、そこに敬称まで含めた文字列を入れてテンプレートのパーソナライズトークンで差し込む方法。第二に、当事者モジュールの見出し（Heading）とラベルを「御中」の体裁に寄せ、会社名の直後に敬称が並ぶように配置する方法です。

前者を選ぶ場合、プロパティの作り方そのものが運用品質を決めます。プロパティには前後の空白を禁止する、文字数の上限を設けるといった入力規則を設定できるため、HubSpotプロパティーとはと併せて設計してください。

消費税の内税・外税表示はどう設計するか？

日本の見積書でもっとも揉めるのが税の表示です。税抜小計・消費税額・税込合計の三段を求められることが多く、軽減税率の対象がある場合は税率ごとの内訳も必要になります。HubSpotは税率を自由に定義できるため、設計の自由度は十分にあります。問題は、どこで定義してどこに表示するかです。

税率はどこに登録するのか？

税率はアカウント設定の税率ライブラリに登録します。設定の「収益 > 税」から税率を作成し、内部名と買い手に見せる名称を別々に設定できます。税率は小数点以下4桁まで指定でき、0%の税率も設定できます。既定の税率を1つ指定しておけば、明細を追加したときに自動で選択されます。

日本の運用では、この内部名と表示名の分離が効きます。内部名を「JP_CT_10」のような検索しやすい文字列にし、表示名を「消費税（10%）」にしておくと、レポートでの集計とお客さま向け表示を両立できます。軽減税率対象がある業種では「消費税（軽減8%）」を別に登録し、非課税・対象外の明細には0%の税率を割り当てて、合計欄に税率ごとの内訳が出る状態を作ります。

注意点として、税率は作成後に削除できず、非アクティブにするしかありません。命名規則を決めずに作り始めると、使われない税率が永久に残ります。私たちが税率ライブラリを設計するときは、先に内部名の規則（国コード＋税目＋税率）を決めてから登録を始めています。

端数処理は見積の時点で揃えるべきか？

揃えておくべきです。適格請求書に記載すべき消費税額等に1円未満の端数が生じる場合、一の適格請求書につき税率ごとに1回の端数処理を行う必要があります（タックスアンサー No.6371）。切上げ・切捨て・四捨五入のいずれを採るかは任意ですが、個々の商品ごとに端数処理をして合計する方法は認められていません。

見積段階でこの計算方法を請求書と揃えておかないと、見積と請求で合計金額が数円ずれます。金額の相違は検収で止まるため、見積テンプレートの合計欄の挙動を先に検証してください。なお売上税額の計算方法には、割戻し計算と積上げ計算の2つがあります（タックスアンサー No.6383）。原則となる割戻し計算は、税込金額の合計額に110分の100（軽減税率の対象は108分の100）を掛けた課税標準額に、7.8パーセント（軽減税率の対象は6.24パーセント）を掛けます。積上げ計算は、交付した適格請求書の写しに記載した税率ごとの消費税額等の合計額に100分の78を掛けます。経理が採っている方式を確認したうえで、見積の表示を合わせてください。

総額表示義務は見積書にもかかるのか？

BtoBの見積書については、総額表示義務の対象ではありません。総額表示義務が対象とするのは、事業者が消費者に対してあらかじめ価格を表示する場合です（タックスアンサー No.6902）。したがって、法人向けの見積書で税抜価格を主たる表示にすること自体は妨げられません。

ただし、消費税率引下げに伴う飲食料品の総額表示には特例が設けられています。税率や表示ルールは改定されうるため、テンプレートに税率の数字を文字列としてベタ書きしない設計にしてください。税率ライブラリの値とラベルを参照する形にしておけば、改定時の修正は1か所で済みます。本記事に記載した制度の内容は2026年10月23日時点のものであり、今後変更される可能性があります。

インボイス制度の登録番号は見積書のどこに載せるか？

登録番号は適格請求書の記載事項であり、見積書に書くことが法令で義務づけられているわけではありません。それでも実務で求められるのは、購買側が取引開始時に相手が適格請求書発行事業者かどうかを確認したいからです。見積段階で番号を開示しておくと、与信・購買・経理の確認工程がまとめて進みます。

適格請求書の記載事項のうち、見積書で前倒しすべきものは何か？

適格請求書の記載事項は、交付先である相手方の氏名または名称、売手の氏名または名称および登録番号、取引年月日、取引内容（軽減税率の対象品目である旨）、税率ごとの対価の総額および適用税率、税率ごとの消費税額等です。このうち取引年月日を除く項目は、見積書の時点でほぼ確定します。

HubSpotのテンプレートに落とすと、宛名は当事者モジュール、売手名と登録番号は当事者モジュールまたは条件モジュール、税率ごとの対価と消費税額は明細の合計欄、軽減税率対象である旨は明細の備考行で表現できます。請求書で必要になる項目を見積テンプレートに先に組み込んでおくと、請求段階での差し戻しが消えます。

売手の登録番号をテンプレートに固定するには？

売手側の登録番号は、取引ごとに変わるものではないため、テンプレートに固定するのが合理的です。売手の会社と連絡先はテンプレート単位で設定でき、テンプレートを使う全ての見積に同じ情報を載せられます。また条件モジュールはリッチテキストで、ソースコード編集によるHTMLの挿入にも対応しています。登録番号の記載はこのいずれかで固定します。

買い手側のTax IDは、見積に最大3つまで追加でき、買い手自身に更新を許可する設定もあります。売手のTax IDは請求書側で追加します。番号の体裁は、法人の場合は「T」に続く13桁の数字です。

買い手の登録番号を集めるべきか？

自社が買い手になる取引が多い場合は集める価値があります。ただし、見積オブジェクトのTax IDは見積に紐づく値であり、取引先マスタとしての管理には向きません。恒久的に保持するなら、会社オブジェクトにカスタムプロパティを作り、入力規則で桁数と文字種を縛るほうが運用が安定します。プロパティの入力規則についてはHubSpotプロパティーとはと、本サイトのプロパティ設計の記事を併せて参照してください。

有効期限と見積番号はどう運用するか？

有効期限と見積番号は、帳票上は小さな項目ですが、運用に乗せた途端に効いてきます。有効期限が空欄のまま出た見積は、半年後に「まだ有効ですよね」と言われます。見積番号が人によってバラバラだと、再発行の履歴が追えません。どちらもHubSpot側に受け皿があるため、ルールを決めて埋めるだけです。

有効期限の既定値はどこで設定するか？

レガシー見積では、アカウント全体の既定有効期間を日数で設定できます。この設定にはSales Hub ProfessionalまたはEnterpriseのサブスクリプションが必要で、設定を有効にした後に作成された見積に既定の有効期間が適用されます。

署名方法によって、有効期限の挙動も変わります。署名もオンライン支払いもない場合は有効期限日に失効します。オンライン支払いを有効にして署名がない場合、支払いが有効期限より前に受領されれば失効せず、見積は支払いから1年間アクセスできます。購入者の電子署名のみを必要とする場合、期限までに署名されれば失効せず、署名日から1年間有効です。購入者と連署者の双方の署名が必要な場合、購入者が期限前に署名しても連署者が期限までに署名しなければ失効します。「期限切れ」の定義が署名方法で変わる点は、営業に周知しておかないと事故になります。

見積番号の採番はどう設計するか？

見積オブジェクトには、見積番号のプロパティ（hs_quote_number）が用意されています。一方で、自社の採番ルール（年度＋部門コード＋連番など）で自動採番する機能について、公式ドキュメントに記載は確認できませんでした。

そのため実務では、採番をワークフローのカスタムコードや外部システムに寄せるか、採番そのものをやめて見積のレコードID（hs_object_id）を正本の識別子にするかの二択になります。私たちが設計する際は、既存の基幹システムが採番している場合はそちらを正とし、HubSpot側は表示用に受け取るだけの構成にしています。採番の主体を二重に持たせないことが、再発行時の混乱を避ける唯一の方法です。

社印・角印と押印なし運用はどちらを選ぶか？

日本の見積書に角印が押されているのは、様式として定着しているからです。一方で、HubSpotの受諾フローは電子署名または署名なしの受諾を前提に設計されています。両者をどう折り合わせるかは、法的な意味を踏まえて決める論点です。

押印には法的にどのような意味があるのか？

内閣府・法務省・経済産業省が連名で公表した押印についてのＱ＆Ａに、整理された見解が示されています。押印についてのＱ＆Ａ（PDF）の問1では、私法上、契約は当事者の意思の合致により成立し、書面の作成およびその書面への押印は、特段の定めがある場合を除き必要な要件とされていないと述べられています。

問2では、民事訴訟法第228条第4項に「私文書は、本人の署名又は押印があるときは、真正に成立したものと推定する」という規定があり、本人の押印があれば、その私文書は本人が作成したものであることが推定されると説明されています。つまり押印の実務上の価値は、契約の有効性ではなく、裁判になったときの証明の負担軽減にあります。見積書は契約書そのものではないため、この観点で見ると押印を外す判断は取りやすくなります。

押印を外す場合、何を証拠として残すか？

同Q&Aの問6には、文書の成立の真正を証明する手段として、継続的な取引関係がある場合は取引先とのメールのメールアドレス・本文・日時等の送受信記録の保存が挙げられ、請求書・納品書・検収書・領収書・確認書等はこのような保存のみでも文書の成立の真正が認められる重要な一事情になり得ると示されています。新規の取引では契約締結前段階の本人確認情報の記録・保存、電子署名や電子認証サービスの活用が挙げられています。

HubSpotはこの要件に素直に対応できます。見積の送信日時、初回送信日、最終送信日、閲覧回数、最終閲覧日といった値は、プロパティとして保持されます。電子署名を使う場合の署名日や署名完了数も同様です。押印を外す代わりに、送信と閲覧と受諾の記録を残すという置き換えが成立します。社内の法務に説明する際は、Q&Aの問6を根拠として提示してください。

どうしても印影が必要な場合の実装は？

印影を画像として差し込む専用モジュールについて、公式ドキュメントに記載は確認できませんでした。現行の見積では、リッチテキストの「Content section」モジュールを追加し、ソースコード編集でHTMLを記述できます。レガシー見積では、CMSのカスタムテーマとしてテンプレート全体をコード化できるため、より自由に配置できます。

印影画像をテンプレートに固定する場合、ブランド設定との優先順位に注意してください。テンプレート単位で設定したロゴと色は、見積のブランディング設定とアカウントのブランディング設定の双方を上書きします。複数ブランドで帳票を出し分ける場合は、ブランドごとにテンプレートを分けるほうが管理が単純になります。

日本向けテンプレートを作る手順はどうなるか？

ここまでの論点を実装順に並べ替えます。順番を間違えると手戻りが出ます。特に税率ライブラリとプロパティは、テンプレートより先に固めてください。テンプレートは後から直せますが、税率は削除できず、プロパティの内部名は後から変更できません。

運用に乗せるために決めておくルールは何か？

テンプレートを作っただけでは運用は安定しません。営業が自由にモジュールを表示・非表示にできる状態だと、同じ会社から様式の違う見積が出ます。テンプレート側でセクションの表示・非表示を設定でき、「Allow visibility changes on quotes」のチェックを外すと、見積作成時のモジュールの表示状態がテンプレートの設定に固定されます。モジュールのロックも同様に指定できます。

承認フローを併用する場合、現行の見積では標準承認と高度な承認が用意されており、高度な承認はRevenue Hub Enterpriseのみです。値引き率や金額に応じて承認者を変える運用は、HubSpot公式ナレッジベース（見積もりルールの設定）にある見積もりルールと組み合わせて設計します。価格表との関係はHubSpotの価格表と契約オブジェクトの設計をどう決めるかで整理しています。

請求までつなぐ場合は、請求書の作成とHubSpot CPQの仕様も併せて押さえておく必要があります。見積・契約・請求で同じ税率ライブラリを参照する構成にしておくと、金額の不一致が構造的に起きなくなります。各機能の提供条件はProduct and Services Catalogに定義されており、記載は変更される可能性があります。商談管理全体の流れはHubSpot Sales Hubの使い方、オブジェクト設計の判断軸はHubSpotカスタムオブジェクトの設計判断と作らない基準を参照してください。

よくある質問（FAQ）

日本向けの見積テンプレートを設計する過程で、実務で必ず出てくる論点をまとめます。

見積書に適格請求書発行事業者の登録番号を書かないと、取引できませんか？

法令上、登録番号の記載が求められるのは適格請求書であり、見積書ではありません。ただし購買側の社内規程で、取引開始時に登録番号の提示を求める運用を敷いている企業は多くあります。取引を止めないために、見積の条件欄に記載しておく運用を推奨します。

既存のExcelの見積様式をそのままHubSpotで再現できますか？

レガシー見積であれば、CMSのカスタムテーマとしてテンプレート全体をコード化できるため、再現度は高くなります。現行の見積はモジュール単位のカスタマイズが前提のため、罫線の位置まで含めた完全再現は想定されていません。様式の再現に固執するより、受け取る側が確認したい項目が揃っているかで判断するほうが、工数に見合います。

すでにレガシー見積でテンプレートを作り込んでいます。移行すべきですか？

Sales Hubのアカウントで現行の運用に支障がなければ、急いで移行する必要はありません。ただしテンプレートは引き継げないため、Revenue Hubの導入を検討する段階で、テンプレート再構築の工数を見積に織り込んでください。移行の是非は、階層型価格・価格表・高度な承認といった現行の見積だけの機能を使うかどうかで決まります。

消費税の端数処理をHubSpot側で切り捨てに固定できますか？

端数処理の方法を見積ツール側で明示的に選択する設定について、公式ドキュメントに記載は確認できませんでした。実際の挙動は、税率ライブラリの税率と明細の構成によって決まります。請求側の計算と一致するかどうかは、本番環境で代表的な取引パターンを数件通して検証してください。

押印をやめたいのですが、取引先が応じてくれません。

相手側の社内規程の問題であることが多いため、自社側の証跡設計を示したうえで交渉するのが現実的です。内閣府・法務省・経済産業省の押印についてのＱ＆Ａは、押印に代わる立証手段を具体的に列挙しているため、交渉資料としてそのまま使えます。当面は印影画像を載せた帳票を併用し、段階的に外していく進め方でも構いません。

見積の宛名を間違えて送ってしまいました。取り消せますか？

公開済みの見積は、従来の見積もり・現行の見積のいずれでも、取り消しと編集、アーカイブ、削除ができます。取り消した見積のURLは無効になります。再発行する際に見積番号を引き継ぐか新番にするかは、自社の採番ルールで先に決めておいてください。

多通貨の取引でも同じテンプレートを使えますか？

使えます。見積の通貨は関連する取引の通貨プロパティに一致し、ロケールを変更しても通貨の書式は変わりません。日付と住所の表示形式はロケールで変わるため、海外向けと国内向けでロケール設定を分けたテンプレートを用意する構成が扱いやすくなります。

見積の様式を変えたら、過去の見積も変わりますか？

変わりません。ロゴやブランディングを更新しても既存の見積は更新されず、現在の下書きと更新後に作成された見積のみが更新されます。テンプレートを非公開にしても、新規の見積が作成できなくなるだけで、既存の見積は影響を受けません。

本記事に記載したHubSpotの仕様および制度の内容は、2026年10月23日時点で各一次情報を確認したものです。HubSpotの機能・提供条件・上限値、および税制は変更される可能性があるため、実装前に必ず最新の一次情報をご確認ください。