kintoneからHubSpotへの移行 完全ガイド｜判断基準から手順・帳票・連携まで全体像を整理

kintoneからHubSpotへの移行は、単なるデータの引っ越しではなく「静的データの器」を「動く仕組み」に載せ替える設計プロジェクトです。 判断基準・5フェーズの全体像・CSV/API2つのデータ移行ルート・「1テーブル=1オブジェクト」原則での複数アプリ再設計・帳票代替・併用の選択肢まで、移行の全工程を一気通貫で整理します。

「kintoneでアプリを増やしすぎて、どこに何のデータがあるか分からなくなった」

「顧客管理アプリと案件管理アプリを手作業で転記していて、入力漏れが絶えない」

「営業とマーケティングを一体化したいけれど、kintoneだけでは自動化に限界を感じる」

——kintoneからHubSpotへの移行を検討する企業の多くが、こうした課題を抱えています。

kintoneは業務アプリを自由に作れるノーコードツールとして非常に優秀です。ただし、アプリの数が増えるにつれてデータが分断し、全体像が見えなくなっていくという構造的な弱点も持っています。HubSpotへの移行は、単にデータを引っ越すだけの作業ではなく、kintoneで静的に貯めてきたデータを、HubSpotの「動く仕組み」に載せ替える設計プロジェクトです。

本記事は、kintoneからHubSpotへの移行を検討・実行する担当者に向けた完全ガイド（ハブ記事）です。移行すべきかどうかの判断から、プロジェクト全体のフェーズ設計、データ移行の2つのルート、複数アプリの再設計、カスタム帳票の移行、そして「移行せず併用する」という選択肢まで、移行の全工程を一気通貫で整理します。各テーマの詳細な実務手順は、それぞれ専門記事にリンクしていますので、自社の検討フェーズに応じて読み進めてください。

本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。

この記事でわかること

• 判断基準: kintoneとHubSpotの構造的な違いと、移行すべきか併用すべきかを見極める判断軸。感覚論ではなく、両ツールの役割の違いから判断できるようになります。
• 移行プロジェクトの全体像: 「判断→設計→データ移行→帳票・連携→運用定着」の5フェーズと、各フェーズで何をすべきか。今どこに取り組んでいるかを見失わずに進められます。
• データ移行と複数アプリの再設計: CSVエクスポートとAPI連携という2つのルートの使い分け、「1テーブル=1オブジェクト」を原則とした複数アプリの再設計の考え方。
• 帳票・連携の代替設計: kintoneの帳票プラグインをHubSpot側でどう代替するか、全面移行せず併用する場合の最小連携の原則。
• 移行を止めないための実務チェックリスト: 冪等設計・段階移行という、プロジェクトを頓挫させないための実務上のポイント。

本記事は、kintoneからの移行を検討し始めたばかりの担当者から、複数アプリの移行を具体的に進めたい実務担当者まで、幅広い読者を対象としています。まずは全体像を掴み、詳細な実務手順は各節からリンクしている専門記事であわせてご確認ください。

kintoneからHubSpotへ移行すべきかの判断

移行プロジェクトを始める前に、まず「なぜkintoneのままでは限界を迎えつつあるのか」を整理しておくことが重要です。ここを曖昧にしたまま移行を進めると、単なるデータの引っ越しで終わってしまい、期待した効果が得られません。

kintoneは「静的データの器」、HubSpotは「動的〜静的まで統合するCRM」

kintoneは、サイボウズが提供するノーコード業務アプリ構築プラットフォームです。データベース・帳票・契約や申請の管理・現場の業務アプリまで、自由に作って柔軟に運用できる点が最大の強みです。

一方で、アプリが増えるほど「データが分断していく」「アプリ間の転記が手作業になる」という課題が顕在化します。顧客管理アプリと案件管理アプリが別々に存在し、両方に似たような顧客情報が入っていて、どちらが正なのか分からなくなる——という状態は、kintoneを長く使っている企業でよく見かける光景です。

HubSpotは、顧客接点データ（コンタクト・会社・取引・チケット）を核として、MA（マーケティングオートメーション）・SFA（営業支援）・CS（カスタマーサポート）・レポートまでを一体で提供するCRMプラットフォームです。パイプラインの可視化、ワークフローによる自動化、ダッシュボードでのレポーティングが標準機能として組み込まれています。

移行の勘所は「静的データを動く仕組みに載せ替える」こと

ここが結構ミソになってくる部分ですが、kintoneからHubSpotへの移行は、単なるデータ移設プロジェクトではありません。kintoneで静的に貯めていたデータを、HubSpotのワークフロー・レポート・ライフサイクルステージという「動く仕組み」に載せ替えることこそが、移行の本質的な価値です。

そのため、移行プロジェクトには必ず「パイプラインの再設計」「ステージの統廃合」「そもそもHubSpot上で持つ必要のないデータの仕分け」という設計判断が伴います。ここを飛ばしてkintoneのアプリ構造をそのままHubSpotに複製しても、工数削減にはつながりません。むしろ使わないプロパティが乱立し、SFAあるあるの「項目が多すぎて誰も使わない」状態を再現してしまいます。

kintoneとHubSpotの機能面での詳しい比較は「HubSpot vs kintone｜機能・料金・向いている企業を徹底比較」で解説していますので、判断材料としてあわせてご確認ください。

移行プロジェクトの全体像（5フェーズ）

kintoneからHubSpotへの移行は、大きく5つのフェーズに分解できます。全体像を先に把握しておくことで、今どこに取り組んでいるのかを見失わずに進められます。

全てを一気に進めようとすると、必ずどこかで工数が肥大化します。StartLinkが実際の移行支援で重視しているのは、まず重要度の高いアプリ（顧客管理・案件管理など）から着手し、効果を確認しながら段階的に対象を広げていくアプローチです。これはStartLinkがHubSpot導入全般で一貫して推奨している「スモールスタート」の考え方でもあり、kintone移行のような複雑なプロジェクトほど有効に働きます。

データ移行の2つのルート

kintoneのデータをどう抽出し、HubSpotへ投入するかには、大きく2つのルートがあります。自社のkintone構成の複雑さに応じて選んでください。

CSVルート（小規模・単純構成向け）

kintoneのアプリ数が少なく、アプリ間のリレーションもシンプルな場合は、CSVエクスポート→HubSpotインポートのルートで十分対応できます。kintoneの画面から対象アプリのレコードをCSV形式でエクスポートし、HubSpotのインポート機能でコンタクト・会社・取引などのオブジェクトに投入します。

顧客管理アプリを中心とした基本的な移行手順は「kintoneからHubSpotへの移行ガイド｜顧客管理・案件管理の移行手順とデータ設計」で詳しく解説しています。まずはこちらから着手いただくのがおすすめです。

APIルート（複数アプリ・選択肢定義を保全したい場合）

一方、kintoneのアプリ数が多い、ドロップダウンの選択肢定義を正確に引き継ぎたい、定期的に差分だけ再エクスポートしたい——といったケースでは、kintone REST APIを使ったデータ抽出が現実的な選択肢になります。

APIルートで実務上まず躓きやすいのが認証方式です。kintone REST APIの認証には大きく3形式があり、取り違えると保護リソースへアクセスできないエラーで時間を溶かしてしまいます。

複数アプリを横断してデータを取得する場合、アプリごとにトークンを発行するより、閲覧権限を持つアカウントのログインID・パスワードで認証する方式の方が圧倒的に効率的です。全レコードの取得はページング処理が必要になり、フィールドの型やドロップダウンの選択肢はフィールド定義APIで丸ごと取得できます。ただし「関連レコード一覧」は表示専用でエクスポートに含まれないなど、いくつかの落とし穴も存在します。

これらのAPI認証の実務詳細・全レコード取得のページング手順・フィールド定義の活用方法については「Kintone REST APIでデータを全件エクスポートする手順」で具体的な手順とサンプルコードを紹介していますので、複数アプリを扱う場合はあわせてご確認ください。

複数アプリの再設計

kintoneの運用が長くなっている企業ほど、案件管理・顧客管理・活動履歴・候補者管理など、複数のアプリが横断的に存在しています。これらをHubSpotに移行する際、最初につまずきやすいのが「アプリとオブジェクトの対応関係をどう設計するか」です。

大原則:「1テーブル=1オブジェクト」からスタートする

StartLinkが実際の移行支援で用いている大原則は、まず「1テーブル（kintoneアプリ）=1オブジェクト（HubSpot）」でそのまま移行することです。サブテーブルから別オブジェクトを新たに起こすような、オブジェクトを横断するマッピング設計は、初回移行では判断を保留し、次フェーズに切り分けます。

典型的なアプリとオブジェクトの対応関係は次のとおりです。

移行の初回に「全部を完璧に設計してから動かす」のを目指すと、いつまで経っても移行が始まりません。まず基本の対応関係で動かし、業務上どうしても必要な横断マッピングだけを後から個別に検討する方が、プロジェクトを止めずに進められます。

関連付けは「実キー」で張る。事前にカバー率を実測する

アプリ間の関連付け（アソシエーション）は、kintoneの表示用テーブルではなく、実際のキー項目（数値ID・メールアドレスなど）で再構築する必要があります。ここで重要なのは、キーごとにどれだけの割合でデータが紐づくか、移行前に実測しておくことです。

一般化した例として、実際の移行プロジェクトでは次のようなカバー率の差が確認されています。

この結果から得られる教訓はシンプルです。数値の関連キーがあるアプリ間は完璧に移行できますが、メールアドレスや氏名頼みの関連付けは、元データの入力率がそのまま移行カバー率になります。「どこまで紐づくか」を事前に実測してから設計に着手しないと、移行後に「思ったより関連付けが張られていない」という事態を招きます。

複数アプリの横断データを、実際にどうHubSpotオブジェクトへマッピング設計していくかの詳細な手順は「Kintone複数アプリをHubSpotオブジェクトへ再設計する方法」で解説しています。アプリ数が多い企業は、この記事とあわせて設計を進めてください。

カスタム帳票の移行

kintoneでは、帳票プラグインやプリントクリエイターを使って見積書・請求書・作業報告書などの帳票を出力している企業が多くあります。これらの帳票機能は、移行時に見落とされがちですが、業務上は非常に重要な機能です。

HubSpot側での代替方法は主に2つあります。1つは、HubSpotのUI拡張（CRMカード）で帳票出力の仕組みを構築する方法です。取引レコードの商品項目（Line Item）からPDFを生成し、CRMカード上のボタンで出力する構成が実現できます。もう1つは、会計ソフト側で帳票を発行する選択肢です。StartLinkでは、Sync for freeeのような会計連携を通じて、HubSpotの取引情報からfreee側で見積書・請求書を発行する運用も提案しています。

どちらを選ぶかは、帳票のフォーマットの複雑さや、既存の会計フローとの整合性によって変わってきます。プリントクリエイターで作り込んだ複雑な帳票をそのままHubSpot側で再現したい場合はUI拡張、会計処理との一体化を優先したい場合はfreee連携、という切り分けが実務上の目安です。

UI拡張によるPDF帳票の具体的な実装方法（日本語フォントの扱いを含む）は「Kintoneの帳票をHubSpotのPDF出力に置き換える方法」で詳しく解説しています。

移行せず併用する選択肢

ここまで移行を前提に解説してきましたが、全てのケースでkintoneを完全にやめる必要があるわけではありません。kintoneが得意とする社内業務アプリ・申請承認フローはそのまま残し、HubSpotとは必要最小限のデータだけを連携する「併用」も現実的な選択肢です。

最小連携の原則

併用する場合に重要なのが「最小連携の原則」です。計算プロパティ（集計値）は連携の同期先にできない、あるいはしづらいという制約があります。連携するなら、業務判断に必要な最小限のキー項目だけを同期し、集計やレポートは各ツール側でそれぞれ保持するのが安全です。

双方向で全項目を同期しようとすると、計算プロパティの扱いや型の不一致で連携が壊れやすくなります。「kintoneは社内業務、HubSpotは顧客接点」という役割分担を明確にし、両者をつなぐキー項目だけを最小限連携する設計の方が、長期的に運用しやすくなります。

kintoneと HubSpotを併用する際の連携制約・最小連携の実装パターンは「kintone × HubSpot 連携設計｜業務アプリとCRMの使い分け」で詳しく整理しています。全面移行に踏み切る前に、まず併用から始めたいという企業は、こちらもあわせてご確認ください。

移行の実務チェックリスト

最後に、移行プロジェクトを止めずに進めるための実務上のポイントを整理します。

冪等設計 — 再実行に強いデータの持ち方

移行元のエクスポートデータには、「HubSpotレコードID」列と「移行ステータス」列（未移行/移行中/移行済/エラー/対象外）を必ず持たせてください。HubSpotへの投入後、発行されたレコードIDをこの列に書き戻しておくことで、後からPATCHによる上書き更新が可能になります。

この設計をしておくと、移行スクリプトを何度実行しても同じ結果になる「冪等」な状態を保てます。エラーで一部のレコードだけ失敗した場合も、ステータス列を見れば再実行すべき対象がすぐに分かり、二重登録のリスクも防げます。

段階移行 — 一気に全部でなく、重要アプリから

移行対象のアプリを洗い出したら、全てを一度に移行するのではなく、業務インパクトの大きいアプリから優先的に着手します。顧客管理・案件管理のような、営業活動に直結するアプリを最初に移行し、運用が安定してから周辺アプリへ対象を広げていくのが現実的です。

段階移行の考え方は、5フェーズの「設計」フェーズで洗い出した優先順位に沿って進めます。一度に全てを移行しようとすると、移行作業そのものが長期化し、途中でプロジェクトが停滞するリスクが高まります。少数精鋭のチームで移行を進める場合は特に、この段階的なアプローチが有効です。

まとめ

kintoneからHubSpotへの移行は、単なるデータの引っ越しではなく、静的に貯めてきたデータをHubSpotの動く仕組み（ワークフロー・レポート・ライフサイクルステージ）に載せ替える設計プロジェクトです。本記事で整理した要点を振り返ります。

• kintoneは「静的データの器」、HubSpotは「動的〜静的まで統合するCRM」という構造的な違いを理解した上で、移行すべきか併用すべきかを判断する
• 移行プロジェクトは「判断→設計→データ移行→帳票・連携→運用定着」の5フェーズで進める
• データ移行はアプリ数・複雑さに応じてCSVルートとAPIルートを使い分ける
• 複数アプリは「1テーブル=1オブジェクト」を原則に、関連付けは実キーのカバー率を実測してから設計する
• 帳票はUI拡張または会計連携（Sync for freee等）で代替でき、全面移行せず最小連携で併用する選択肢もある

最初の一歩としておすすめしたいのは、まず自社のkintoneアプリを一覧化し、業務インパクトの大きいアプリから「1テーブル=1オブジェクト」で移行対象を絞り込むことです。全てを一度に完璧に設計しようとせず、重要なアプリから段階的に動かしながら精度を上げていく方が、結果的にプロジェクトが前に進みます。

kintoneからHubSpotへの移行は、データ構造の再設計から帳票・連携の代替手段まで検討事項が多岐にわたります。導入支援を単なるコストではなく、業務効率化とデータ資産化によるROIのある投資として捉え、HubSpotゴールドパートナーのStartLinkでは、移行の判断段階から実際のデータ移行・運用定着まで一気通貫でご支援しています。自社の状況に合わせた移行計画を検討したい場合は、お気軽にご相談ください。

よくある質問

Q1: 移行にかかる期間の目安はどれくらいですか？

kintoneのアプリ数や、案件管理・顧客管理などの主要アプリのデータ量によって大きく変わります。単一アプリのCSV移行であれば数週間、複数アプリをAPI経由で移行し、関連付け設計や帳票代替まで含める場合は数ヶ月単位のプロジェクトになるのが一般的です。まず重要アプリから段階移行する方針であれば、初期の効果は早い段階で実感しやすくなります。

Q2: kintoneのデータは全部HubSpotに移すべきですか？

必ずしも全部を移す必要はありません。顧客接点に関わるデータ（顧客管理・案件管理・活動履歴など）はHubSpotへの移行が適していますが、社内固有の申請・承認フローや、kintoneでしか使わない業務アプリは、そのままkintoneに残して併用する選択肢も現実的です。移行対象を絞り込むことで、プロジェクトの負荷を抑えられます。

Q3: kintoneと併用することはできますか？

可能です。kintoneは社内業務アプリ、HubSpotは顧客接点データという役割分担を明確にし、業務判断に必要な最小限のキー項目だけを連携する「最小連携の原則」に沿って設計すれば、両者を無理なく併用できます。全項目を双方向で同期しようとすると計算プロパティなどで連携が壊れやすくなるため注意が必要です。

Q4: kintoneで使っていた帳票はどうなりますか？

kintoneの帳票プラグインやプリントクリエイターで出力していた見積書・請求書などは、HubSpotのUI拡張（CRMカード）による帳票出力機能で代替できます。また、会計処理との一体化を重視する場合は、Sync for freeeのような会計連携を通じて、会計ソフト側で帳票を発行する運用に切り替える選択肢もあります。