Salesforce解約・移行時のデータ保全｜失敗しないエクスポート手順と「バックアップ」の落とし穴
1. Salesforceのデータエクスポートには「アーカイブ用」「移行用」「バックアップ用」の3つの目的があり、それぞれ最適なツールが異なる。
2. 標準のCSVエクスポートは「参照用」にはなるが、「完全復元用」としては不完全であり、リレーション（親子関係）やメタデータが欠落するリスクがある。
3. 2025年以降の仕様変更（Java 17必須化、ダウンロード制限など）により、従来の手順では失敗する可能性があるため、解約1ヶ月前からの計画的な準備が必須。
「コスト削減でSalesforceの契約を終了することになった」「HubSpotやKintoneなど別のCRMへの乗り換えが決まった」——そんな連絡を受けたシステム管理者や情シス担当者にとって、最も神経を使う作業が「データのエクスポート」ではないでしょうか。
長年にわたって蓄積してきた顧客情報、商談履歴、活動記録。これらは紛れもなく会社の「資産」です。しかし、いざエクスポートしようとすると、想像以上にハードルが高いことに気づかされます。「とりあえずCSVで全部出しておけばいいだろう」という軽い認識で臨むと、解約後に「あのデータが取り出せていなかった」「ファイルが開けない」という事態に陥る可能性があるのです。
本記事では、私自身がSalesforceからのデータ移行プロジェクトに関わった経験も踏まえながら、失敗しないエクスポートの手順と、多くの人が見落としがちな「バックアップの落とし穴」について詳しく解説していきます。
なぜ「とりあえずエクスポート」ではダメなのか
Salesforceには標準でエクスポート機能が備わっています。管理画面からボタンをクリックすれば、CSVファイルとしてデータを出力できる。だから多くの担当者は「解約前に全データをダウンロードしておけば問題ないだろう」と考えがちです。
しかし、この認識には大きな落とし穴があります。Salesforceのデータ構造は、一般的なExcelの表とは根本的に異なります。「取引先」の下に「商談」がぶら下がり、さらにその下に「活動履歴」や「添付ファイル」が紐付いている。このリレーショナル構造をCSVというフラットな形式に落とし込むと、データ間の「つながり」が見えにくくなってしまうのです。
さらに厄介なのは、Salesforce独自の「ID」の存在です。すべてのレコードには18桁の一意なIDが割り振られており、データ同士はこのIDで関連付けられています。CSVをエクスポートして、それを別のSalesforce環境や他のCRMにインポートし直すと、新しいIDが採番されます。つまり、手元のCSVにある「旧ID」は意味をなさなくなり、「この商談がどの取引先のものだったか」をシステム的に追跡できなくなってしまうわけです。
こうした構造的な問題を理解しないまま解約日を迎えると、「データはあるのに使えない」という最悪の事態に陥りかねません。
エクスポートの目的を明確にする
作業を始める前に、まず「何のためにデータを出すのか」を明確にしておく必要があります。目的によって、選ぶべきツールもデータの形式も変わってくるからです。
アーカイブ（保管）目的の場合
Salesforceはもう使わないが、税務や法務の観点から過去の取引履歴や顧客情報を保管しておかなければならない——このケースで求められるのは「人間が後から見てわかる形式」です。
CSVファイルだけでなく、取引先に紐付いていた契約書のPDFや、商談に添付されていた見積書、メールのやり取りを保存したドキュメントなど、「添付ファイル」の保全が最優先事項となります。後述する「データエクスポートサービス」が唯一の選択肢となるケースです。
他ツールへの移行（マイグレーション）目的の場合
SalesforceからHubSpotやKintone、あるいは別のSalesforce環境へデータを移すケース。ここで重要なのは「機械が読み取れる、整合性のあるデータ」です。
移行先のシステムに合わせてデータを加工（クレンジング）する必要があるため、特定の条件でデータを抽出したり、不要なフィールドを除外したりする細かな操作が求められます。「データローダー」が威力を発揮する場面です。
バックアップ（BCP対策）目的の場合
運用中のSalesforce環境におけるデータ消失リスクに備えるケース。実は、Salesforce標準のエクスポート機能は、この「バックアップ」用途としては不完全です。先ほど触れたリレーションの問題に加えて、Chatterの会話履歴やレポート・ダッシュボードの設定情報、自動化フローの定義など、CSVには含まれない「メタデータ」が存在するからです。
本格的なバックアップを実現したいのであれば、Salesforce公式の「Salesforce Backup」や、サードパーティ製の「OwnBackup」などの専用ツールを検討すべきでしょう。
Salesforceデータエクスポートの3つの手段
Salesforceからデータを取り出す方法は主に3つあります。それぞれの特徴と適した用途を整理しておきましょう。
データエクスポートサービス（ウィークリーエクスポート）
管理者の設定画面から実行できる、最もオーソドックスな機能です。全オブジェクトのデータに加えて、画像・ドキュメント・添付ファイルを一括で抽出できる唯一の標準機能という点が最大の強みです。
ただし、即時実行には対応していません。エディションによって週1回または月1回のスケジュールで実行されるため、「今すぐ全データが欲しい」という要望には応えられません。また、データ量によっては完了まで数時間から数日かかることもあります。解約前の「最終的な全量データ保管」には最適ですが、計画的に余裕を持って実行する必要があります。
データローダー（Data Loader）
PCにインストールして使うクライアントアプリケーションです。抽出条件をSOQL（Salesforce Object Query Language）で細かく指定できるため、「過去1年分の商談データだけ」「削除済みのデータも含める」といった柔軟な操作が可能です。
一方で、環境構築のハードルがあります。後述するJavaのバージョン問題など、技術的な知識がないと躓きやすいツールでもあります。また、添付ファイルの一括ダウンロードには向いていないため、「移行用のデータセット作成」に特化して使うのが賢明です。
レポートのエクスポート
普段の業務で使っている「レポート」の結果をExcelやCSVにダウンロードする機能です。現場のユーザーでも操作できる手軽さがメリットですが、行数制限があり、大量データの抽出には向きません。また、システム内部のIDフィールドが含まれないことも多く、データ移行の用途では使えません。
現場担当者が「自分の担当顧客リストだけ手元に残しておきたい」といった局所的な用途に限られます。
3つのエクスポート手段の比較
| 項目 | データエクスポートサービス | データローダー | レポートのエクスポート |
|---|---|---|---|
| 主な用途 | 全量バックアップ・アーカイブ | 移行用データの作成 | 個人の参照用 |
| 添付ファイル対応 | ○（一括抽出可能） | △（別途対応が必要） | × |
| 抽出条件の指定 | × | ○（SOQL対応） | △（レポートの条件のみ） |
| 即時実行 | ×（スケジュール制） | ○ | ○ |
| 技術的な知識 | 不要 | 必要（Java環境など） | 不要 |
| 大量データ対応 | ○ | ○ | ×（行数制限あり） |
| 解約・移行での重要度 | 必須 | 推奨 | 基本的に使わない |
「CSVがある＝バックアップ完了」という誤解
ここで、多くの担当者が陥る「バックアップの落とし穴」について、もう少し詳しく触れておきます。
「全データをCSVでエクスポートしたから、何かあってもこれをインポートし直せば元通りになる」——もしそう思っているなら、その認識は危険です。標準機能でエクスポートされたCSVデータは、「参照用」にはなりますが、「復元（リストア）用」としては極めて脆弱なのです。
リレーション（親子関係）が失われる
前述のとおり、Salesforceのデータは「Salesforce ID」という一意のキーで繋がっています。CSVに出力されたデータを別環境にインポートすると、新しいIDが採番されるため、旧IDとの紐付けが切れてしまいます。
これを修復するには、ExcelのVLOOKUP関数などを使って旧IDと新IDのマッピング表を作成し、すべての関連レコードを一つずつ紐付け直すという、気の遠くなるような作業が必要になります。数千件の商談データがあれば、それだけで数日を要する可能性があります。
メタデータがエクスポートされない
CSVエクスポートには含まれない情報があります。Chatterのフィード（会話履歴）、レポートやダッシュボードの設定定義、ページレイアウトや自動化フロー（Process BuilderやFlow）の設定などです。
他ツールへの移行であればこれらは諦めるしかないケースもありますが、「障害発生時に同じSalesforce環境へリストアしたい」というBCP目的であれば、標準エクスポートでは不十分です。有償のバックアップ専用ツールの導入を真剣に検討すべきでしょう。
2026年版：作業前に知っておくべき技術的な罠
ここからは少しテクニカルな話になりますが、実際に作業を行う担当者にとっては「知らなかった」では済まされない内容です。2025年から2026年にかけての仕様変更により、数年前のブログ記事に書かれている手順通りでは動かないケースが増えています。
データローダーが起動しない「Java 17問題」
データローダーの最新バージョン（v61.0以降）は、Java Runtime Environment（JRE）17以上が必須となっています。以前は適当なバージョンのJavaが入っていれば動作していたのですが、現在はそうはいきません。
古いPCを使っている場合や、社内のセキュリティポリシーでJavaのバージョンが固定されている環境では、最新のデータローダーをインストールしても起動すらしません。コマンドプロンプトで java -version を実行して、「11」や「8」と表示された場合は、OpenJDK 17などをインストールし直す必要があります。
これは意外と見落としがちなポイントで、私自身も過去のプロジェクトで「なぜか起動しない」という問い合わせを受けて原因究明に時間を取られた経験があります。
データエクスポートの「ダウンロード制限」
データエクスポートサービスで大量のデータ（特に添付ファイルを含む場合）を出力すると、データは複数のZIPファイルに分割されます。たとえばpart1.zipからpart50.zipまで、といった形式です。
以前はこれらをブラウザの機能で一気にダウンロードできたのですが、現在のSalesforceではセキュリティ強化とサーバー負荷対策の観点から、短時間に連続してダウンロードリクエストを送ると「HTTP 429 Too Many Requests」エラーが発生するようになっています。
対策としては地味ですが、「1つダウンロードしたら60秒ほど待つ」という運用が推奨されています。50個のファイルがあれば、ダウンロードだけで1時間以上かかる計算です。解約日ギリギリに作業を始めると、この待機時間で致命的な遅れが生じる可能性があります。
私が経験した「あと一歩」の失敗談
ここで少し、私自身の経験をお話しさせてください。
以前、あるクライアント企業でSalesforceからHubSpotへの移行プロジェクトを支援したことがあります。データローダーで主要オブジェクトのCSVを抽出し、文字コードも確認し、件数の突合も済ませて「これで準備完了」と思っていました。
ところが、解約後にクライアントから連絡が入りました。「商談に添付していた見積書のPDFがない」と。
原因は単純でした。データローダーでは添付ファイルの「メタデータ」（ファイル名やサイズ、紐付け先の情報）は取得できますが、ファイルの「実体」は取れないのです。データエクスポートサービスで「画像、ドキュメント、添付ファイルを含める」にチェックを入れて実行していれば防げたミスでした。
幸い、解約日までまだ数日あったため、急いでデータエクスポートサービスを実行して事なきを得ましたが、あと数日遅れていたら取り返しのつかない事態になっていたでしょう。この経験以来、私は「データローダーだけでは不完全」という点を必ずプロジェクト開始時に共有するようにしています。
移行先別：気をつけるべきポイント
Salesforceからの移行先として検討されることが多いツールについて、それぞれ注意点を整理しておきます。
HubSpotへ移行する場合
HubSpotにはSalesforce連携機能があるため、運用中であればデータ同期は比較的スムーズです。ただし、解約を前提とした「完全移行」となると話が変わります。
HubSpotのコンタクト（連絡先）は「メールアドレス」が一意キーとなるため、Salesforceの「取引先責任者」にメールアドレスが入っていないレコードはインポート時にエラーになります。事前にSalesforce側でデータクレンジングを行い、メールアドレスの欠損を補完しておく必要があります。
Kintoneへ移行する場合
Kintoneは柔軟にアプリを設計できる反面、Salesforceのような「標準オブジェクト」という概念がありません。取引先・商談・活動履歴をどのようなアプリ構成で再現するか、事前の設計が重要です。
また、Kintoneの1レコードあたりの添付ファイル容量に上限があるため、Salesforce側で大きなファイルを添付していた場合は移行できないケースがあります。ファイルサイズの棚卸しを事前に行っておくべきでしょう。
別のSalesforce環境へ移行する場合
親会社への統合や、Sandbox環境から本番環境への移行など、Salesforce同士のデータ移行もあります。この場合、「同じプラットフォームだから簡単だろう」と油断しがちですが、前述のID問題は同様に発生します。
「外部ID」フィールドを活用したり、データローダーの「Upsert」機能でマッピングを制御したりする工夫が必要です。技術的な難易度は他ツールへの移行より高い場合もあります。
失敗しないエクスポートの実行フロー
これまでの注意点を踏まえ、解約や移行を安全に完了させるための推奨フローを時系列で整理します。
Step 1：スケジュールの確保（解約日の1ヶ月前）
「前日にやればいいや」は禁物です。データエクスポートサービスは「リクエストしてから準備完了メールが届くまで」にデータ量次第で最大48時間ほどかかる場合があります。さらに、ダウンロード時の待機時間も考慮が必要です。最低でも解約日の1週間前にはデータ抽出が完了している状態を目指してください。
Step 2：添付ファイルの確保（データエクスポートサービス）
管理者メニューの「データのエクスポート」から、画像やドキュメントを含む全データの抽出を予約します。「画像、ドキュメント、添付ファイルを含める」「Salesforce FilesおよびSalesforce CRM Contentドキュメントを含める」のチェックボックスを必ず確認してください。
文字コードは、移行先の要件に合わせて選択します。日本語環境ではShift_JISを選びがちですが、HubSpotなど海外製ツールへの移行ではUTF-8が適している場合が多いです。
Step 3：移行用データの抽出（データローダー）
Step 2で全量バックアップは確保できましたが、ZIPの中に含まれるCSVはファイル数が多く、移行作業には使いにくい形式です。データローダーを使って、移行に必要な主要オブジェクト（取引先、取引先責任者、商談、活動履歴など）を個別にエクスポートします。
「Export All」機能を使うとゴミ箱のデータやアーカイブ済みデータも含まれますが、移行のノイズになりやすいため、基本的には通常の「Export」で、Where句を使って条件を絞ることをおすすめします。
Step 4：データの検証（最重要ステップ）
ダウンロードして終わりではありません。必ずファイルを開いて内容を確認してください。CSVをExcelで開いたときに文字化けしていないか。ZIPを解凍した添付ファイルは破損なく開けるか。Salesforce上のレポート件数とCSVの行数は一致しているか。
解約後に「データが壊れていた」と気づいても、Salesforce側は復旧してくれません。検証は絶対に省略しないでください。
よくある質問（FAQ）
Q1：データエクスポートの実行間隔はどのくらい？
エディションによって異なります。Enterprise Edition以上であれば週1回（6日間隔）、Professional Editionなどでは月1回が目安です。「今すぐエクスポート」をクリックしてから次に実行可能になるまで、最短でも6日間空ける必要があります。
Q2：エクスポートしたファイルの保管期限は？
データエクスポートサービスで生成されたファイルは、完了から48時間でダウンロードできなくなります。また、新しいエクスポートをキューに登録すると、たとえ48時間以内であっても前のファイルは削除されます。生成されたらすぐにダウンロードする習慣をつけてください。
Q3：Chatterの投稿内容はエクスポートできる？
標準のデータエクスポートサービスでは、Chatterのフィードデータ（投稿内容やコメント）はエクスポートされません。API経由で取得するか、サードパーティ製のバックアップツールを利用する必要があります。
Q4：解約後にデータを取り出すことはできる？
契約終了後は、Salesforce環境へのアクセス権が失われます。データの取り出しはできません。解約日までに必ずすべてのデータを取得しておく必要があります。Salesforceは解約後のデータ復旧には対応していません。
Q5：社内にデータローダーを使える人がいない場合は？
Salesforce導入支援を行っているパートナー企業に「データ移行支援」や「エクスポート代行」をスポットで依頼することを検討してください。数十万円程度の費用で、専門家がデータ抽出から検証までを代行してくれるサービスがあります。自社だけで対応しきれるか不安な場合は、外部リソースを活用するのも賢明な判断です。
まとめ：データは企業の「資産」——最後の瞬間まで油断せずに
Salesforceの解約や移行は、単なる「契約の終了」ではありません。企業が長年かけて蓄積してきた情報資産の引越しです。
便利なクラウドサービスであるがゆえに、「データは常にそこにあるもの」と錯覚しがちですが、解約の瞬間からそのアクセス権は完全に失われます。一度失ったデータは、どれだけお金を積んでも取り戻せません。
本記事でお伝えした内容を改めて整理すると、目的（保管・移行・バックアップ）に合わせてツールを使い分けること、標準のCSVエクスポートは「完全な復元」を保証しないと理解しておくこと、そして最新の技術仕様（Java 17やダウンロード制限）を把握して余裕を持ったスケジュールで作業すること——この3点を守ることで、トラブルなくスムーズな移行やクローズ処理が可能になります。
「たかがデータ抽出」と侮らず、万全の準備でプロジェクトを成功させてください。そして、少しでも不安があれば、専門家の力を借りることを躊躇わないでください。データを守ることは、会社の未来を守ることと同義なのですから。