Kintoneの帳票（見積書・請求書）をHubSpotで再現する方法｜UI拡張×PDF生成の実装ガイド

Kintoneのプリントクリエイター等で作り込んだ見積書・請求書フォーマットは、HubSpotの「プロジェクト開発」機能（UI拡張）を使えば、CRMカードから直接PDFとして再現できます。 標準の見積もり機能では対応しきれない自由なレイアウトも、開発によって作り込むことが可能です。ただし、日本語PDFの生成には固有の実装ノウハウが必要で、ここでつまずくケースが少なくありません。

「kintoneのプリントクリエイターで何年もかけて作り込んだ見積書・請求書のフォーマットがある。角印の位置、明細欄のレイアウト、備考欄の定型文——これを手放してまでCRMを乗り換える価値があるのか」——kintoneからHubSpotへの移行を検討する企業様から、こうした声をよく聞きます。

データの移行よりも、「今と同じ見た目の帳票が出せなくなるのでは」という不安のほうが、移行の意思決定を鈍らせる要因になっているケースを実務でよく見かけます。実はこの不安は、正しい実装方法さえ理解していれば解消できるものです。

本記事では、なぜkintoneの帳票が移行のボトルネックになるのか、HubSpotのプロジェクト開発機能でどう解決するのか、そして実装時に直面する日本語PDF生成の落とし穴を、StartLinkの開発知見に基づいて解説します。kintoneとHubSpotの連携設計全体については「kintone × HubSpot連携ガイド」もあわせてご覧ください。

この記事でわかること

• Kintone帳票が移行のボトルネックになる理由 — 標準の見積もり機能で対応しきれないケースを整理します
• HubSpotのプロジェクト開発（UI拡張）による解決の全体像 — CRMカード×サーバーレス関数×PDF生成ライブラリの構成を解説します
• 日本語PDF生成でつまずく4つの実装地雷 — フォント埋め込み・サブセット化・画像埋め込み・レンダリング検証の対処方針を紹介します
• 導入までの進め方と向かないケース — スモールスタートの判断基準と、カスタム開発に踏み切るべきでないケースを正直に解説します

Kintoneの帳票を維持したまま移行できるか判断したい、開発担当者・情報システム部門の方に特に参考になる内容です。

なぜKintoneの帳票が移行のボトルネックになるのか

帳票プラグインの独自フォーマット

kintoneでは「プリントクリエイター」をはじめとする帳票プラグインを使い、自社の見積書・請求書・納品書フォーマットを作り込んでいる企業様が多くいらっしゃいます。角印の位置、ヘッダーのロゴ配置、明細欄の列構成、備考欄の定型文——これらは一度作り込むと、営業担当者が日々の業務で当たり前に使うようになり、社内標準として定着します。

この「作り込んだフォーマット」の存在が、CRM移行の意思決定を鈍らせる大きな要因になっています。移行プロジェクトを進める中で、データ移行の設計はある程度目処が立っても、帳票の見た目だけは最後まで方針が決まらない、という状況になりがちです。

HubSpot標準見積で対応しきれないケース

HubSpotには標準で見積もり作成機能が備わっており、取引の商品項目（Line Item）から見積書を生成できます。多くの企業様にはこの標準機能で十分ですが、以下のようなケースでは対応が難しくなります。

• 角印・実印など画像を厳密な位置に重ねて表示する必要がある
• 明細欄のレイアウトが独自仕様（複数階層の小計、特殊な単位表記など）になっている
• 既存の紙帳票・PDFフォーマットをそのまま踏襲する必要がある
• 発行条件や表示分岐が複雑で、標準の見積もり画面のUIでは表現しきれない

こうしたケースでは、標準機能をそのまま使うのではなく、HubSpotの開発機能を使って自社専用の帳票出力の仕組みを構築するという選択肢が出てきます。

プラグイン機能とHubSpot標準の対応可否比較

解決策の全体像—プロジェクト開発でCRMカード×PDF生成

UI拡張（プロジェクト開発）とは何か

HubSpotの「プロジェクト開発」（UI拡張、UI Extensions）とは、Reactベースのコードでレコード画面に独自のCRMカードを追加し、CRMデータと連動した独自機能を組み込める開発の仕組みです。取引・会社・コンタクトなど各レコードの画面に、標準機能にはないボタンや表示を追加できます。

構成要素（Reactベースのカード＋サーバーレス関数＋PDF生成ライブラリ）

CRMカードから帳票PDFを出力する仕組みは、大きく3つの要素で構成されます。

この3要素がセットで動くことで、「CRMカードのボタンを押すと、その場で自社フォーマットのPDFがダウンロードできる」という体験を実現します。

取引の商品項目（Line Item）起点のデータフロー

帳票の元データは、取引に紐づく商品項目（Line Item）です。品目名・数量・単価・金額といった明細情報に加え、取引プロパティ（宛先の会社名・担当者名・発行日など）を組み合わせて、PDFのテンプレートに流し込みます。

ここで重要なのは、「HubSpot上で運用しているデータ構造は変えずに、出力の見た目だけを自社仕様にする」という考え方です。商品項目の入力ルールやプロパティ設計自体は標準的なCRM運用のままにしておき、PDF生成のロジック側で表示上の体裁を整える設計にすると、後々の保守がしやすくなります。

実装の勘所—日本語PDF生成の地雷

サーバーレス関数上でPDFを生成する際によく使われるのが、pdf-libのようなオープンソースのPDF生成ライブラリです。英数字だけの帳票であれば大きくつまずくことは少ないのですが、日本語の帳票を生成しようとすると、いくつかの実装上の地雷にぶつかります。ここでは、実際の開発で直面した代表的な4つの落とし穴を紹介します。

フォント埋め込みの罠

日本語PDFを生成する際は、和文フォントをファイルに埋め込む必要があります。HubSpotのサーバー環境にはOSの日本語フォントがインストールされていないため、フォント自体をコードの実行環境に持ち込まなければなりません。

ここでよく起きるのが、「和文フォント1本で数字も含めてすべて描画する」と、半角のはずの数字（0〜9）まで全角幅で描画されてしまい、見積金額の桁がやたらとスカスカに間延びして、明細欄の枠からはみ出すという問題です。

対処の考え方としては、1つの文字列の中でASCII文字（数字・英字・記号）は欧文フォント、日本語（漢字・ひらがな・カタカナ）は和文フォントというように、文字種ごとにフォントを出し分けて描画するのが実務上のポイントです。文字列を1文字ずつ判定し、どちらのフォントで描画するかを切り替えるロジックを組む必要があります。

サブセット化の罠

フォントファイルをそのままPDFに埋め込むとファイルサイズが数MB〜10MB程度まで膨らむため、使用する文字だけを抽出する「サブセット化」という軽量化手法がよく使われます。ところが、このサブセット化処理とCJK（中日韓）フォントの組み合わせでは、文字のマッピングテーブルが壊れてしまい、日本語文字が丸ごと消失したり文字化けしたりするケースがあります。

この問題への対処は主に2つの方向性があります。1つは、サブセット化をせず全文字を埋め込む方法です。ファイルサイズは増えますが、確実に描画されます。もう1つは、軽量かつ完全収録型の和文フォントを選定し、サブセット化の不具合が出にくい構成にする方法です。帳票の発行頻度・保存容量の制約を踏まえて、どちらを取るか判断することがポイントになってきます。

角印・ロゴなど画像の埋め込み

角印やロゴといった画像要素は、PDF内に透過PNGとして埋め込むのが実務上の定番です。既存の紙帳票やPDFから角印の画像を抽出し、背景を透過処理した上でコード内に埋め込み、指定座標に重ねて描画します。

角印の位置は、見積書のレイアウト全体の中でミリ単位の調整が必要になることが多く、座標指定の微調整を繰り返しながら詰めていく作業になります。

レンダリング検証の重要性

PDF生成のコードが完成したら、実際に出力したファイルを目視で確認する検証工程が欠かせません。ここで結構ミソになってくるのが、「どのPDFビューアを検証の正典とするか」という点です。PDFレンダラーによって表示の癖が異なり、あるビューアでは警告が出るのに別のビューアでは全く問題なく表示される、というケースが少なくありません。

実務では、macOSに標準搭載されているプレビュー相当の表示機能を検証の基準として使うのが確実です。特定のレンダラー固有の警告に振り回されて開発が止まってしまうより、実際に顧客が目にする一般的な閲覧環境での見え方を優先して判断することが、実務を前に進めるコツです。

地雷と対処方針まとめ

導入までの進め方・投資対効果

まず標準機能で切り分ける（スモールスタート発想）

すべての帳票をいきなりカスタム開発する必要はありません。まずはHubSpot標準の見積もり機能で、どこまで自社の要件をカバーできるかを切り分けることが最初のステップです。標準機能で十分対応できる帳票と、独自レイアウトが必須で開発が必要な帳票を仕分けし、後者だけを開発対象に絞り込むと、投資規模を最小限に抑えられます。

カスタム開発に踏み切る判断基準

カスタム開発に踏み切るかどうかの判断基準は、大きく3つです。

• 既存フォーマットの再現が業務上必須か（取引先との慣習・契約書式として固定されているか）
• 発行頻度が高く、手作業での体裁調整コストが継続的に発生しているか
• 標準機能のカスタマイズ範囲（テンプレート選択・項目の表示切替など）で許容できる差か

この3点を照らし合わせ、「標準機能では明確に業務が回らない」と判断できた帳票だけをカスタム開発の対象にすることを推奨します。

手作業コスト削減・自社ブランド帳票維持という投資効果

CRMカードからワンクリックで自社フォーマットの帳票が出力できるようになると、見積書・請求書作成にかかっていた手作業（Excelでの体裁調整、PDF変換、ファイル管理）が削減されます。加えて、長年使ってきた自社ブランドの帳票フォーマットを維持したまま基幹システムをHubSpotに一本化できる点も、実務上の価値が大きい部分です。

これは単なるコストではなく、日々の営業事務工数を削減しながらCRMデータと帳票発行を一元管理する仕組みへの投資と捉えるのが妥当です。開発規模に応じて投資対効果は変わるため、対象帳票を絞り込んだ上で検討することが重要になってきます。移行プロジェクト全体の進め方は「kintoneからHubSpotへの移行完全ガイド」で解説しています。

移行時の注意点・向かないケース

全ての帳票をカスタム開発する必要はない

繰り返しになりますが、社内で使うすべての帳票をカスタム化する必要はありません。発行頻度が低い帳票や、標準機能のテンプレートで十分な体裁が保てる帳票は、無理にカスタム開発の対象にせず、標準機能をそのまま使うほうが合理的です。

開発・保守体制が必要という正直な限界

UI拡張によるPDF生成は開発が必要な仕組みであり、導入して終わりではありません。HubSpotの仕様変更やライブラリのアップデートに応じて保守が必要になりますし、帳票フォーマットの変更依頼が発生した際にもコードの改修が伴います。社内に開発リソースがない場合は、外部の開発パートナーとの継続的な関係を前提に検討する必要があります。

自社の業務に合わせた設計が重要

帳票の構成は企業によって大きく異なります。月次の請求書だけを対象にすればよいケースもあれば、見積書・注文請書・納品書と複数の帳票を連動させる必要があるケースもあります。「自社の業務フローに合わせて対象範囲を設計する」という考え方は、CRM設計全般に共通する原則であり、帳票のカスタム開発でも例外ではありません。

freee連携という選択肢との比較

帳票をfreee側で発行する使い分け

帳票発行の選択肢は、HubSpotのUI拡張によるカスタムPDF生成だけではありません。すでにfreee会計を使っている企業様であれば、StartLinkが開発した連携アプリ「Sync for freee」を使い、HubSpotの取引情報からfreee側で見積書・請求書を発行するという選択肢もあります。

freee側での帳票発行は、会計処理と帳票発行を一体で管理したい場合や、経理担当者が請求書の発行・入金管理まで一貫して行いたい場合に適しています。一方、営業担当者がCRM画面から離れずにその場で見積書を出したい、独自レイアウトを細部までコントロールしたいという場合は、本記事で紹介したUI拡張によるカスタムPDF生成のほうが適しています。どちらが正解ということではなく、経理体制と営業の運用スタイルに応じて使い分けるのが実務的な判断です。

まとめ

kintoneの帳票プラグインで作り込んだフォーマットは、HubSpotの「プロジェクト開発」（UI拡張）を使えばCRMカードから再現できます。本記事の要点を以下にまとめます。

• kintoneの帳票プラグインで作り込んだ見積書・請求書フォーマットは、HubSpotのプロジェクト開発（UI拡張）を使えばCRMカードから再現できる
• 構成要素はReactベースのCRMカード＋サーバーレス関数＋PDF生成ライブラリの3点セットで、取引の商品項目を起点にデータを流し込む
• 日本語PDF生成では、フォントの文字種混在描画・サブセット化・画像埋め込み・レンダリング検証という4つの地雷に注意が必要
• すべての帳票をカスタム化する必要はなく、標準機能との切り分けから始めるスモールスタートが現実的
• freee会計を使っている場合は、Sync for freeeによるfreee側発行という選択肢もあわせて検討する価値がある

まず着手すべきは、現在kintoneで使っている帳票フォーマットを一覧化し、標準機能で代替できるものとカスタム開発が必要なものを仕分けることです。すべてを一気に開発対象にするのではなく、業務上どうしても必要な帳票だけに絞り込むことが、投資対効果を最大化する最初の一歩になります。

「今の帳票フォーマットを維持したままHubSpotに移行できるか判断したい」という場合は、ぜひStartLinkにご相談ください。貴社の帳票要件を踏まえた実装方針を、開発会社としての知見からご提案します。

関連記事: kintone × HubSpot連携ガイド / kintoneからHubSpotへの移行完全ガイド / HubSpotとfreee会計/請求書の連携方法2選

よくある質問（FAQ）

Q1. HubSpot標準の見積書機能とUI拡張PDFはどう選び分ければよいか

まず標準の見積もり機能を試し、テンプレートのカスタマイズ範囲で自社の帳票要件を満たせるかを確認してください。それでも角印の厳密な位置指定や独自の明細レイアウトが再現できない場合に、UI拡張によるカスタムPDF生成を検討するという順番が現実的です。全帳票をいきなり開発対象にするのではなく、標準機能で足りない部分だけを切り分けることが判断の分かれ目になります。

Q2. Kintoneの既存フォーマットをそのまま再現できるか

多くの場合、レイアウト・角印位置・明細構成を含めてほぼ同等の見た目を再現できます。ただし、kintoneの帳票プラグイン特有の機能（条件によるレイアウト自動切替など）を使い込んでいる場合は、その挙動をコードで作り込む開発工数が発生します。再現度と開発コストはトレードオフになるため、どこまで忠実に再現する必要があるかを事前に整理しておくとスムーズです。

Q3. 検討〜構築にどれくらいの期間がかかるか

対象帳票の複雑さによって幅がありますが、要件整理・デザイン確認・実装・検証を含めると、シンプルな帳票1種類であれば比較的短期間、複数帳票や複雑な明細構成を含む場合はそれ以上の期間を見込むのが現実的です。日本語フォントまわりの検証には一定の時間がかかるため、スケジュールには余裕を持たせることを推奨します。

Q4. 請求書も同じ仕組みで発行できるか

可能です。見積書と同様に、取引の商品項目や請求関連プロパティを元データとして、同じPDF生成の仕組みで請求書テンプレートを出力できます。見積書・請求書・注文請書など複数帳票を扱う場合は、共通のPDF生成基盤を作った上で、帳票ごとにテンプレートだけを切り替える設計にすると保守性が高まります。