kintoneで運用してきた案件・顧客・会計データをSalesforceへ移行する——シンプルに見えて、いざ着手すると会計データの不整合や顧客の表記ゆれが次々発覚し、移行が止まってしまうケースは少なくありません。本記事では、移行前の整形・名寄せから、一括移行と段階移行（並行稼働中の双方向同期）の進め方、そして移行後の継続連携までを、開発なしで実現する手順として解説します。
01 kintone→Salesforce移行でつまずく点
kintoneは現場の運用に合わせてアプリを自由に設計できる分、アプリごとにフィールドの持ち方や入力ルールがバラバラになりがちです。長く運用してきたkintoneのデータをSalesforceへ移行しようとすると、この自由度の高さがそのまま移行の壁になります。
- 会計データの不整合：金額の桁区切り・税区分・勘定科目の表記が、アプリや入力者ごとに微妙に異なっている。
- 顧客データの表記ゆれ：同じ取引先が「株式会社◯◯」「（株）◯◯」など複数の名称で登録されており、Salesforce側で名寄せしないと重複作成されてしまう。
- IDの紐付けがない：kintoneのレコード番号とSalesforceのレコードIDを対応付ける仕組みがなく、移行後にどのレコードとどのレコードが対応するか追えなくなる。
こうした不整合は移行の直前になって発覚することが多く、手作業のCSV加工で乗り切ろうとすると膨大な工数がかかります。実際に、kintoneからSalesforceへ移行する際の会計データ整形でつまずき、そこを解決した移行時の整形課題を解決した事例もあります。移行は「データを流し込む作業」ではなく、先に整形の設計をする作業だと捉えるのが安全です。
02 移行前に整えるべきデータ（整形・名寄せ）
移行を始める前に、次の3点を整えておくと、後工程の手戻りを大きく減らせます。
顧客・取引先の名寄せ
表記ゆれのある顧客名を正規化し、Salesforce側の取引先と1対1で対応するキー（外部ID）を発行します。ここが曖昧なまま移行すると、以降のすべての連携で重複が発生します。
会計データの形式統一
金額・税区分・勘定科目のコード値を、Salesforce側のマスタに合わせて変換します。kintone側で自由入力になっていた項目は、変換テーブルを用意して機械的に揃えます。
項目マッピングの確定
kintoneのフィールドとSalesforceの標準・カスタム項目を1対1で対応付け、移行後も参照できるよう、双方のレコードを結びつける外部IDをSalesforce側に持たせます。
この整形・名寄せの工程は、移行プロジェクトの中で最も工数がかかり、かつ最も軽視されがちな部分です。ここを自動化できるかどうかで、移行全体の期間が大きく変わります。
03 移行の進め方｜一括移行と段階移行・並行稼働の同期
移行の進め方には大きく2つの方式があり、データ量や業務の止めやすさによって使い分けます。
| 方式 | 進め方 | 向いているケース |
|---|---|---|
| 一括移行（カットオーバー） | 整形済みのデータを一度にSalesforceへ投入し、以降はkintoneを使わない | データ量が少ない／業務を一時的に止められる |
| 段階移行（並行稼働） | 一定期間、kintoneとSalesforceを双方向に同期させながら並行稼働し、徐々にSalesforceへ業務を寄せていく | データ量が多い／業務を止められない／段階的に検証したい |
段階移行を選ぶ場合、並行稼働期間中は「どちらで入力しても、もう片方に反映される」状態を作る必要があります。これは前回の記事で解説したSalesforceとkintoneの双方向連携と同じ骨格――取得→変換→upsert――で実現できます。
ポイント：並行稼働中の二重登録を防ぐ
並行稼働期間中は、同じレコードがkintoneとSalesforceの双方で新規作成され、二重登録になるリスクがあります。移行時に発行した外部IDで必ず突合し、upsertで「あれば更新・なければ作成」に統一することが安定運用の鍵です。
04 Passworkでの実現方法とAgentic ETL
Passworkは、kintoneとSalesforceの双方のコネクタを備えたノーコードのデータ連携サービスです。整形・名寄せの変換ルールと、外部IDによるupsertをフローとして組めば、一括移行の初回投入も、段階移行中の並行同期も、同じ仕組みの上で扱えます。並行稼働期間はスケジュール実行で差分同期を回し、移行が完了したタイミングでフローの向きや頻度を変えるだけで、移行後の継続連携へそのまま移行できます。
さらにPassworkが目指すのは、こうした移行・連携の設計を業務の中で動く「Agentic ETL」――現場で動く、対話で操作する、AIが判断して実行するデータ統合――にしていくことです。移行の変換ルールをその都度エンジニアに依頼するのではなく、対話しながら組み上げていく世界を目指しています。考え方の全体像は「Agentic ETLとは？」をご覧ください。
提供元のPraztoはSalesforceやTableauなどの導入支援で350社超の実績があります。kintoneからの移行データの整形設計から、並行稼働中の同期の作り込み、移行後の継続連携まで、初期構築を1ヶ月のサポート付きで伴走できます。
05 業務での具体的な活用例
kintoneからSalesforceへの移行は、企業ごとに背景や進め方が異なります。ここでは、実際によくある3つのシナリオ——成長にともなうkintone卒業、部門統合・M&Aでのデータ一本化、Salesforce本格導入にともなう過去データの引き継ぎ——を例に、Passworkでの移行の進め方を具体的に見ていきます。
成長企業のkintone卒業：拠点拡大で手狭になったアプリからの段階移行
従業員50名から200名へ急成長したSaaS企業のケース。案件管理をkintoneで運用していたが、拠点拡大でアプリのカスタマイズが限界に達し、Salesforceへの移行を決断。Passworkで案件・顧客データを双方向同期し、営業現場はkintoneを使い続けながら3ヶ月かけて段階的にSalesforceへ切り替え、業務を止めずに移行を完了した。
部門統合・M&Aによるデータ一本化：バラバラなkintoneアプリの名寄せ
複数の営業部門をM&Aで統合したメーカーのケース。各部門が個別のkintoneアプリで顧客・案件データを管理しており、名称の表記ゆれや重複が多数存在していた。Passworkで表記ゆれを自動的に名寄せ・整形し、統合後のSalesforceへ一本化。部門ごとにバラバラだった顧客管理を、統合からわずか2ヶ月で一元化できた。
Salesforce本格導入：過去の顧客・案件履歴を欠損なく引き継ぐ
小規模にkintoneで顧客管理を始めていた企業が、事業拡大に伴いSalesforceを本格導入したケース。過去5年分の顧客対応履歴・商談履歴をkintoneに蓄積していたため、欠損なくSalesforceへ引き継ぐことが課題に。Passworkで全レコードを外部IDで紐付けて移行し、過去の商談経緯も参照できる状態でSalesforce運用を開始した。
06 まとめ：移行を「その場限りの作業」で終わらせない
kintoneからSalesforceへの移行の要点は、先に整形・名寄せを設計し、一括移行か段階移行かを見極め、段階移行なら外部IDによるupsertで並行稼働の整合性を保つこと。Passworkならこの一連の流れをノーコードのフローで表現でき、移行後もそのまま継続連携へつなげられます。まずは会計データや顧客データの棚卸しから、整形の設計に着手してみてください。
データ連携の自動化
で始めませんか？
SaaS・データソース・DWHをノーコードでつなぎ、AIが連携フローの構築を支援します。
｢何を・どの条件で・どこにつなぐか｣の設計から、専門のコンサルタントが無料でご相談承ります。
