Kintoneの複数アプリをHubSpotオブジェクトに再設計する方法｜関連付けはカバー率を実測してから設計する

kintoneの複数アプリをHubSpotへ移行する際は、まず「1テーブル（kintoneアプリ）=1オブジェクト（HubSpot）」でそのまま移行し、アプリ間の横断マッピングは次フェーズに切り分けます。関連付け（アソシエーション）は表示用の関連レコード一覧ではなく実キーで張り、事前にカバー率を実測してから設計するのが失敗しない進め方です。

「案件管理、顧客管理、活動履歴、候補者管理……気づいたらkintoneのアプリが10個近くに増えていて、どこから手をつければいいか分からない」——複数アプリで運用しているkintone環境をHubSpotへ移行しようとすると、こうした声をよく聞きます。

アプリが多い環境ほど、移行設計を最初から完璧に組もうとして手が止まりがちです。実際には、全アプリの関連付けを一度に厳密設計するよりも、まず「1テーブル=1オブジェクト」でデータを移し切ってしまい、アプリをまたぐ複雑なリレーションは動きながら詰めていく方が、結果的にプロジェクトは早く進みます。

本記事では、複数のkintoneアプリをHubSpotの標準オブジェクトへどう振り分けるか、関連付けの精度をどう見積もるか、フィールド型変換や重複名寄せの実務まで、実際の移行案件で確立した設計手順を解説します。kintoneのデータをAPIで全件エクスポートする実務手順、移行のCSVインポート手順は「kintoneからHubSpotへの移行ガイド」で解説していますので、あわせてご参照ください。

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

この記事でわかること

複数のkintoneアプリを運用しており、HubSpotへの移行でオブジェクト設計から手が止まっている情報システム担当者・経営者の方に向けた内容です。最後まで読むと、以下が具体的に分かります。

• 複数のkintoneアプリをHubSpotの標準オブジェクトにどう振り分けるか（案件管理→取引、顧客管理→コンタクト等）
• 横断マッピングを「次フェーズ」に切り分けるべき理由と、その判断基準
• 関連付け（アソシエーション）の精度を、勘ではなく実測カバー率で設計する方法
• ドロップダウン・サブテーブル・氏名フィールドなど、型変換でつまずきやすい箇所の実務対応
• 重複コンタクトの名寄せと、再実行に強い「冪等な」移行元シートの設計方法

再設計の基本原則

1テーブル=1オブジェクトで止めない

kintoneは1つの業務ごとに自由にアプリ（テーブル）を作れるノーコードプラットフォームです。案件管理、顧客管理、活動履歴、候補者管理と、業務が増えるたびにアプリが増殖し、気づけば10個近くのアプリが並行稼働している——というのは珍しい状態ではありません。

このアプリ群をHubSpotに移す際、最初にぶつかる壁が「このアプリはHubSpotのどのオブジェクトに対応させるべきか」という設計判断です。ここで全アプリの関連付けまで含めて一度に厳密に設計しようとすると、検討すべき組み合わせが指数関数的に増え、プロジェクトが着手前から止まってしまいます。

移行を止めないための大原則は、まず「1テーブル(kintoneアプリ)=1オブジェクト(HubSpot)」でそのまま移行することです。オブジェクト横断のマッピング（あるアプリのサブテーブルから別オブジェクトのレコードを起こす、といった複雑な変換）は初回の判断対象から外し、次フェーズに切り分けます。

この考え方は、今枝がHubSpot導入支援で一貫して伝えている「スモールスタートで始め、段階的に拡張する」という設計哲学とも重なります。いきなり理想形を作り切ろうとせず、まず動く状態を作ってから精度を上げていく方が、結果的に定着率も高くなります。

典型的なアプリ→オブジェクト対応

人材紹介業をはじめとした複数の移行案件で確立した、アプリの役割とHubSpotオブジェクトの対応関係を一般化すると、次のようになります。

顧客リストアプリと候補者アプリのように、役割が違っても対応先のHubSpotオブジェクトが同じ（どちらもコンタクト）になるケースは頻出します。この場合、両アプリから同一人物のレコードが重複して流入することが多く、後述する名寄せ設計が結構ポイントになってきます。

横断マッピングを「次フェーズ」に切り分ける判断

一度に全部設計すると止まる理由

アプリが10個近くあると、理論上の関連付けパターンは数十通りになります。「案件と会社」「案件と担当コンタクト」「活動と案件」「候補者とマッチング」——これらすべての紐付けロジックを、移行着手前に完璧に決め切ろうとすると、設計会議だけで数週間を消費してしまいます。

移行プロジェクトが止まる最大の要因は、技術的な難しさよりも「決めきれずに議論が長引く」ことです。企業様によって業務プロセスは異なりますし、実際にデータを移してみないと見えてこない粒度の課題も多くあります。そのため、まずは各アプリを対応するHubSpotオブジェクトへそのまま移し切り、関連付けの精度はデータが入った後に測って詰めていくのが現実的な進め方です。

サブテーブルは今フェーズで判断しない

kintoneのテーブルフィールド（サブテーブル）は、1レコードの中に複数行のデータを持てる機能です。案件管理アプリの中に「見積明細テーブル」を持つようなケースが典型例です。

このサブテーブルをHubSpotでどう再現するか（別オブジェクトのレコードとして展開するか、要約列にまとめるか）は、実は初回移行で判断する必要がありません。まずは1テーブル=1オブジェクトの原則どおり親アプリを移行し、サブテーブルの展開方式は次フェーズの検討事項として明確に切り離しておくことで、初回移行のスコープが肥大化するのを防げます。

関連付けはカバー率を実測してから設計する

数値キーは100%移行可

kintoneのアプリ間リレーションは、画面上では「関連レコード一覧」という表示専用のテーブルとして見えていることが多くあります。しかしこの表示テーブルはレコードの値としては保持されておらず、エクスポートしても中身が出てきません。そのため、HubSpotの関連付け（アソシエーション）は、この表示用テーブルではなく実際にレコードが保持しているキー項目で再構築する必要があります。

ここで結構ミソになってくるのが、関連付けを設計する前に「そのキーがどれだけの精度で紐付くか」を実測しておくことです。案件管理アプリと取引先管理アプリが、双方に同じ数値キー（クライアントIDなど）を持っているケースでは、原則としてカバー率は100%になります。数値キーによる紐付けは、値の表記揺れや入力ミスの影響を受けにくいためです。

email・氏名頼みはカバー率=入力率

一方で、メールアドレスや氏名といった「人が手入力する」項目をキーにした紐付けは、事情が変わります。この場合のカバー率は、システムの限界ではなく、元データの入力率がそのまま反映されることになります。

実際の移行案件でカバー率を計測した例を一般化すると、次のようになります。

「案件↔担当コンタクト」のカバー率が28%というのは、決して珍しい数値ではありません。営業担当者が案件登録時に、担当者名だけ書いてメールアドレスまでは入力していない、といった運用が現場で常態化しているケースは多くあります。

この数値を見て「移行の仕組みに問題がある」と捉えるのは正確ではありません。数値の関連キーがあるアプリ間は完璧に移行できますが、メール・氏名頼みの箇所は元データの入力率がそのまま移行カバー率になるというのが実態です。これはシステムの限界ではなく運用の限界であり、正直にそのまま顧客・現場に共有することが、移行後の「なぜ紐付いていないのか」という混乱を防ぎます。

低カバー率は「会社単位まで」の判断も選択肢

カバー率が低いキーで無理に個人単位の関連付けを追い求めると、移行作業の工数だけが膨らみ、結果的に精度も上がりません。案件↔担当コンタクトのカバー率が28%程度にとどまる場合は、「個人単位の紐付けは無理に埋めず、会社単位の関連付けまでを移行の完成形とする」という判断も現実的な選択肢です。

残りの72%は、HubSpot移行後の運用の中で、案件が動くたびに担当コンタクトを都度紐付けていく形に切り替えれば、データは自然と充実していきます。移行時点で100%を目指さず、運用に乗せてから精度を上げていくという発想は、スモールスタートの考え方と地続きです。

フィールド型変換の実務

単一ドロップダウン→enum（選択肢はfields APIから移植）

kintoneの単一ドロップダウンフィールドは、HubSpotのenum（選択肢）プロパティに対応します。選択肢の内容は、kintoneのfields API（/k/v1/app/form/fields.json）から取得できる選択肢一覧をそのままHubSpot側のenumプロパティ作成時に移植すれば、手入力による転記ミスを避けられます。

姓名分割は確信度ガード付きで行う

kintoneでは「氏名」を1フィールドで管理しているケースが多く見られます。この状態のままHubSpotに移行すると、標準プロパティのlastname（姓）・firstname（名）が空になり、コンタクトの一覧画面が名前ではなくメールアドレス表示になってしまいます。

サブテーブルは1セルJSON→別オブジェクト展開 or 要約列

kintoneのサブテーブル（テーブルフィールド）は、CSVやAPIで取得すると1つのセルにJSON形式で複数行分のデータがまとめて格納されます。HubSpotにはこの構造をそのまま受け取る仕組みがないため、次のいずれかで再現します。

• 別オブジェクトのレコードとして展開：サブテーブルの各行を、カスタムオブジェクト（Enterpriseプラン以上）や商品ライン（Line Items）のレコードとして親レコードに関連付けます。検索性・レポート活用を重視する場合はこちらが基本です
• 要約列に落とす：単純な備考的なテーブルであれば、複数行テキストプロパティに要約して集約する方法もあります。ただし個別行での検索・集計はできなくなります

前述のとおり、この判断は初回移行の必須事項ではありません。まずは親アプリの1テーブル=1オブジェクト移行を完了させ、サブテーブルの展開方式は次フェーズで詳細設計するのが、プロジェクトを止めないコツです。

重複・名寄せとHubSpotレコードIDの書き戻し設計

emailをキーに名寄せし、新規作成でなく更新に切替

顧客リストアプリと候補者アプリのように、複数のkintoneアプリが同じHubSpotオブジェクト（コンタクト）に対応する場合、同一人物のレコードが重複して流入する問題が起きます。この重複は、メールアドレスをキーに名寄せして解消します。

具体的には、あるアプリのレコードを移行する際、既にHubSpot側に同じメールアドレスのコンタクトが存在するかを検索APIで確認し、存在すれば「新規作成」ではなく「既存レコードへの更新」に切り替えます。この判定を都度手作業で行うのは現実的ではないため、仕組みとして自動化しておくことが結構重要です。

移行元シートに「HubSpotレコードID」列と「移行ステータス」列を持たせる

移行を1回のバッチ処理で完璧に終わらせようとする必要はありません。むしろ複数アプリ・大量レコードの移行では、途中でエラーが起きて中断し、再実行することが前提になります。

そのために、移行元のデータシート（エクスポートしたkintoneデータ）には、次の2列を必ず持たせます。

この2列を持たせておくことで、移行スクリプトを何度実行しても「移行済み」の行は二重に作成されない、いわゆる冪等（べきとう）な設計になります。移行プロジェクトは初回で完璧に終わることの方が稀なので、再実行に強い仕組みを最初から組み込んでおくと、後の手戻りが大きく減ります。

HubSpot側投入時のAPI実務注意点

複数アプリ・大量レコードをAPI経由でHubSpotに投入する際、見落としやすい実務上の注意点を整理します。

検索APIの429エラーとリトライ設計

名寄せ判定のために検索APIを大量に呼び出すと、レート制限による429エラーが発生します。エラー発生時に処理を止めるのではなく、指数バックオフ（待機時間を段階的に伸ばす）でリトライし、一定回数失敗したら「エラー」ステータスとして前述の移行ステータス列に記録し、後でまとめて再処理する設計にしておくと安定します。

batch作成直後は検索反映に十数秒のラグがある

HubSpotのbatch作成APIでレコードを大量に登録した直後、そのレコードを検索APIで検索してもすぐには結果に出てこないことがあります。反映まで十数秒のラグがあるためで、これを考慮せずに「作成直後の検索」を前提に処理を組むと、実際には存在するレコードを重複作成してしまう事故につながります。作成と検索の間には数十秒の待機を挟むか、作成時に払い出されたレコードIDをその場で受け取って保持する設計にするのが安全です。

アクティビティ移行は冪等キー用カスタムプロパティを全件付与

活動履歴アプリのレコードをHubSpotのアクティビティ（ミーティング・コール・メモ等）として移行する際は、それぞれに「kintone活動ID」のようなカスタムプロパティを冪等キーとして全件付与しておきます。アクティビティは標準では一意キーを持たないため、これがないと再実行時に重複登録を検知できません。

Eメール活動のPOSTには専用スコープが別途必要

活動履歴の中でもEメールログをアクティビティとして登録する場合、通常のCRM書き込みスコープとは別に、Eメール活動専用のスコープ（sales-email-read等）が必要になります。事前にプライベートアプリの権限設定を確認しておかないと、他のアクティビティ種別は問題なく登録できるのにEメールだけ401エラーになる、という個別対応が発生します。

まとめ

複数のkintoneアプリをHubSpotへ移行する際に押さえておきたい原則を整理します。

• 1テーブル=1オブジェクトでまず移行を止めない。横断的なマッピング（サブテーブル展開等）は次フェーズに明確に切り分ける
• 関連付けは表示用の関連レコード一覧ではなく実キーで張る。数値キーは高精度で紐付くが、メール・氏名頼みのキーはカバー率=元データの入力率になる
• カバー率が低い場合、無理に個人単位を追わず「会社単位まで」を移行時点の完成形とする判断も現実的
• 姓名分割・サブテーブル展開・重複名寄せは、確信度ガードや冪等な移行元シート設計によって、やり直しに強い形にしておく
• API投入時は429リトライ・検索反映ラグ・アクティビティの冪等キー・Eメール専用スコープといった実務上の落とし穴を事前に把握しておく

移行プロジェクトを止めないための最も重要なポイントは、「完璧な設計を最初に決め切ろうとしない」ことです。まずは1テーブル=1オブジェクトの原則で全アプリを移し、関連付けの精度はデータを実際に見ながら実測し、必要な箇所だけを深掘りしていく——この進め方であれば、アプリ数が多い環境でも移行を着実に前に進められます。

自社に最適な設計は、企業様の業務プロセスやアプリの使い方によって当然異なります。移行はコストではなく、データが一元管理され営業・マーケティングの動きが可視化される状態への投資と捉えていただくのがよいかと思います。HubSpotゴールドパートナーのStartLinkでは、kintoneの複数アプリ環境の棚卸しから、関連付けのカバー率実測、HubSpotオブジェクトへの再設計、API投入まで一気通貫で支援しています。移行設計にお悩みの際は、お気軽にご相談ください。

よくある質問（FAQ）

Q1: 全アプリを別オブジェクトにすべきですか？

必ずしも別オブジェクトにする必要はありません。まずは各kintoneアプリをHubSpotの標準オブジェクト（コンタクト・会社・取引・チケット）に対応させる「1テーブル=1オブジェクト」の原則で移行するのが基本です。標準オブジェクトでカバーできない業務特化型のアプリのみ、カスタムオブジェクト（Enterpriseプラン以上）の検討対象にします。

Q2: 関連付けが一部しか移行できない場合はどうしますか？

数値キーがなくメールアドレスや氏名でしか紐付けられない場合、カバー率が元データの入力率に依存するのは避けられません。カバー率が低いキーで個人単位まで無理に追わず、会社単位の関連付けまでを移行時点の完成形とし、残りは運用の中でデータを充実させていく方が現実的です。

Q3: サブテーブルは最初に展開すべきですか？

初回移行の必須事項ではありません。サブテーブルの展開方式（別オブジェクト化か要約列への集約か）を判断すると設計が複雑になり移行全体が止まりやすいため、まずは親アプリの移行を完了させ、サブテーブルの扱いは次フェーズの検討事項として切り分けることをおすすめします。

Q4: 中断・再実行しても大丈夫ですか？

移行元シートに「HubSpotレコードID」列と「移行ステータス」列（未移行／移行中／移行済／エラー／対象外）を持たせておけば、再実行時に移行済みレコードを検知でき、二重作成を防げます。大量データの移行では、1回で完璧に終わらせるより、こうした冪等な設計にしておく方が安全です。

CRM移行・データ設計のご相談はお気軽にどうぞ

複数のkintoneアプリをHubSpotへ再設計する作業は、オブジェクトへの振り分けだけでなく、関連付けのカバー率実測、フィールド型変換、重複名寄せまで含めて初めて移行が完了します。アプリ数が多い環境ほど、設計の切り分け方がプロジェクトの成否を左右します。

移行計画の策定やお見積もりについて、まずはお気軽にご相談ください。

お問い合わせはこちら

関連記事

• kintoneからHubSpotへの移行ガイド｜顧客管理・案件管理の移行手順とデータ設計
• HubSpot vs kintone比較｜CRM・案件管理・カスタマイズ性の違いを実務視点で検証
• kintone×HubSpot連携設計ガイド｜併用・双方向同期の考え方

この記事が属するカテゴリ

• HubSpot導入・活用 の記事一覧 →
• HubSpot の全記事 →
• ブログトップ →