Salesforceを解約する前に──逆算すべき3つの日付と、データで持ち出せないもの
乗り換えを決めてから動き出すと、たいてい間に合いません。解約には「更新を断る期限」と「最終使用日」という別々の日付があり、そこから逆算しないと1年分の費用が確定します。移行支援の現場で組んだスケジュールに加え、エクスポートの仕様（エディション別の実行間隔・48時間の期限・Winter '26で入ったダウンロードのレート制限）、解約後にデータが消えるまでの30日ルール（利用規約で裏取り）、持ち出しの主役になる添付ファイルの扱いまで整理します。
「高いから乗り換えよう」と決めた時点では、まだ何も始まっていません。解約には「更新を断る期限」と「実際に使えなくなる日」という、別々の日付があります。この2つを取り違えると、移行が終わる前に画面が開かなくなるか、逆に1年分の費用が確定します。
この記事でわかること
- 解約で逆算すべき3つの日付と、その間隔の決め方
- エクスポートで持ち出せるもの・持ち出せないもの（公式仕様）
- 解約後、データが消えるまでの30日ルール（利用規約で裏取り）
- 並行稼働をどう設計するか
まず押さえる：自動更新の期限は「使用期限」より前にある
Salesforceは1年単位の自動更新契約が基本です。そして解約の意思表示には期限があります。一般的な約款では、契約期間の満了日より前（たとえば30日前）までに通知しなければ、さらに1年間自動更新されたものとみなされます。
ここが最初の罠です
「まだ使えるから、移行の目処が立ってから解約を伝えよう」と考えると、その時点で更新が確定します。移行が完了していなくても、先に「更新しない」意思を伝える必要があります。契約条件は個社ごとに異なるので、まず自社の契約書で「解約通知の期限」を確認してください。ここが全ての起点になります。
逆算すべき3つの日付
実際に移行を支援したある事業会社のケースでは、次のように日付を並べてスケジュールを組みました。この会社は年数百万円規模でMA＋SFAを契約しており、更新時に約13%の値上げを提示されたことが検討のきっかけでした（機能は変わらないまま金額だけが上がる状態）。
「更新を断る返事の期限」
契約上、これを過ぎると自動更新が確定する日です。移行の目処が完全に立っていなくても、ここまでに意思表示が要ります。
逆に言えば、この日までに「移行できそうか」の見極めを終える必要があります。実案件では、この時点までに構築の方向性とデータ移行の可否を確認し、「行けそう」の感触を作るところまでをゴールにしました。
「実際に使えなくなる最終使用日」
契約期間の満了日です。この日を過ぎるとログインできなくなり、データも取り出せなくなります。
上記のケースでは、①と②の間が約1ヶ月空いていました。つまり「更新しない」と伝えてから、実際に止まるまでに1ヶ月の猶予があった形です。この間隔は契約によって違うので、必ず自社の条件を確認してください。
「新システムへの移管完了目標（②より前に置く）」
最終使用日の当日に移行を終える計画にしてはいけません。実案件では「最終使用日までに運用の8割を新システムへ移管する」という目標を置きました。
8割としたのは、最後の2割は必ず想定外が出るからです。使っていないと思っていたレポートが月次で必要だった、特定の担当者だけが使っていた項目があった——こうしたものは、止まる直前まで出てきません。
第4の日付：解約後、データが消える日
3つの日付を押さえたら、もう1つ把握しておくべき日付があります。解約後、Salesforceに残ったデータが消去される日です。Salesforceの利用規約（Master Subscription Agreement・2023年10月16日版）には、次の内容が明記されています。
利用規約（MSA）に書かれていること
- 契約の終了・満了の発効日から30日以内に顧客が要求すれば、Salesforceは顧客データをエクスポートまたはダウンロードできる形で提供する
- この30日を過ぎると、Salesforceは顧客データを保持・提供する義務を負わない。以降、法的に禁止されない限り、システム上の顧客データの全コピーを削除・破棄する
つまり、「解約したものの、あのデータを取り出し忘れた」という事態に対応してもらえるのは、原則30日間だけです。この30日はあくまで「要求できる期限」であり、画面にログインして通常どおり操作できる期間ではありません。移行作業が終わってから「そういえばあのレポートの元データをダウンロードしていなかった」と気づいても、時間は待ってくれません。
最終使用日の後に「30日」という第4の日付を書き込んでください
ただし、これはあくまで保険であり、頼りにする日付ではありません。エクスポートは最終使用日より前に完了させるのが大原則です。第4の日付は、「取り漏れに気づいた際、まだ間に合うかを判断する」ための目安です。なお、契約内容や終了の経緯によって扱いは異なる場合があるため、必ず自社の契約書で確認してください。
データのエクスポート：仕様を知らないと詰みます
「最後にまとめてエクスポートすればいい」と考えていると間に合いません。Salesforceのデータエクスポートサービスには、知っておくべき制約があります。
データエクスポートサービスの仕様（2026年9月時点）
| 項目 | 内容 |
|---|---|
| 実行間隔 | ウィークリー（7日ごと）またはマンスリー（29日ごと）。エディションによって選べる間隔が異なります |
| 形式 | CSV（zip圧縮） |
| 添付ファイル | 含められます。エクスポート設定時に画像・ドキュメント・添付を含めるオプションを選択（Setup → Data Export） |
| 受け取り方 | 準備完了後にメール通知。zipは通知から48時間で削除される |
48時間という制約が実務で効きます
エクスポートの準備完了メールが金曜の夜に届いて、気づいたのが月曜の朝——これで消えます。次のエクスポートは最短でも7日後（マンスリーなら29日後）。解約日直前にこれが起きると、取り返しがつきません。担当者を決めて、通知が来たら即ダウンロードする体制にしてください。
エクスポートは「1日で終わる作業」ではない
解約日から逆算するとき、多くの方がエクスポートを1日の作業だと見積もります。実際は違います。仕様を知らないと、最終日に間に合いません。
実行間隔はエディションによって変わります
| 実行間隔 | 対象エディション |
|---|---|
| マンスリー（29日ごと） | すべてのエディションで利用可能 |
| ウィークリー（7日ごと） | Enterprise・Performance・Unlimited のみ |
自社がマンスリーしか使えない場合、エクスポートのやり直しが効くのは29日後です。「失敗したら取り直せばいい」が成立しません。解約日の1ヶ月前に1回しかチャンスがない、という前提でスケジュールを引く必要があります。また、出力されるzipは約512MBごとに分割されるため、データ量が多い組織ではダウンロード対象が数個〜数十個のファイルになります。
Winter '26 で、ダウンロードに待ち時間が入った
2026年のWinter '26リリースで、画面からのダウンロードにレート制限が導入されました。①同時ダウンロードは不可（1ファイルずつ） ②次のファイルまで約60秒待つ必要がある ③早すぎると HTTP 429（Too Many Requests） エラーになる——ファイルが30個あれば待ち時間だけで最低30分、数十個規模ならダウンロード作業だけで数時間かかる計算です。なおこの制限は画面からの手動ダウンロードに対するもので、APIや外部ツール経由の取得には適用されないとされています。
これが48時間の制限と組み合わさると危険です。通知から48時間でzipは削除されます。「週末に通知が来て、月曜に大量のファイルを順番に落とす」という段取りだと、落とし切る前に期限が来る可能性があります。データ量が多い組織は、手作業でのダウンロードを前提にしない方が安全です。
だから、こう段取りします
- 11回目のエクスポートを、練習として実行する（解約の2〜3ヶ月前）
- 2ファイル数・容量・所要時間を実測する
- 3週次が使えないエディションなら、次の機会が29日後であることを確認しておく
- 4担当者を決め、通知が来たら即日落とす運用にする
- 5落としたzipを開いて中身を確認する（壊れていないか）
本番の一発勝負にしないこと。これが唯一の対策です。1回練習しておけば、所要時間も、落とし漏れが起きる箇所も分かります。
持ち出しに一番時間がかかるのは、添付ファイル
エクスポートの段取りにおいて、最後にもう1点。実務で最も時間を要するのは、レコードのCSVではなく添付ファイルです。エクスポート設定で画像・ドキュメント・添付ファイルを含めると、出力されるzipの総容量は一気に跳ね上がります。zipは約512MBごとに分割されるため、添付を含めた瞬間にファイル数が数倍〜数十倍に膨らむ組織は珍しくありません。そこに、前述の2つの制約——zipは通知から48時間で削除、画面からのダウンロードは1ファイルずつ・約60秒待ちのレート制限——が重なります。ファイル数が膨大になった状態でこの2つの制約に挟まれると、「48時間以内に、手作業では落とし切れない」という事態が現実味を帯びてきます。だからこそ、添付ファイルは次のように扱ってください。
添付ファイルの扱い方
- 1添付だけ先に、別便で退避する──解約の2〜3ヶ月前に行うテストエクスポートで、添付を含めた場合のファイル数と所要時間を実測し、本番前に添付の退避を済ませておく
- 2ファイル数が多いなら、画面からの手動ダウンロードを前提にしない──レート制限は画面からの手動ダウンロードに対するもので、API・外部ツール経由の取得には適用されないとされています
- 3移行先には「URL」ではなく「実体」を持ち込む──ファイルの実体を確保しておかないと、移行先に登録するデータそのものがなくなります。移行先がAirtableの場合も、添付はURLでなく実体で扱う必要があります
レコードのCSVは容量も軽く、やり直しも効きます。一方、添付ファイルは大容量で、48時間の壁があります。段取りの主役はCSVではなく添付——これがエクスポートの実務を経験した人間の結論です。
エクスポートしても「そのままでは使えない」もの
CSVは出力できますが、出力された状態と、移行先で使える状態は別物です。ここを見落とすと、データはあるのに業務が再現できないという事態になります。
移行時に作業が必要になるもの
- 1レコード間の紐付け — CSVではSalesforce内部のIDで表現されます。移行先では別のIDになるため、紐付けを張り直す作業が必要です
- 2添付ファイルとレコードの対応 — ファイル本体は取り出せても、「どのレコードに紐づいていたか」の対応表を別に管理する必要があります
- 3レポート・ダッシュボードの定義 — これは「データ」ではありません。何を見ていたかを人が書き出して、移行先で作り直すことになります
- 4自動化（フロー・ワークフロー）の設定 — 同様に、仕様を書き出して再実装が必要です
- 5権限設定・入力規則 — 移行先の仕組みが違うため、そのままは移せません
最も見落とされるのが3番目と4番目です。「データさえあれば大丈夫」と考えていると、移行後に「あのレポートが出せない」「あの自動送信が止まっている」が続出します。止まる前に、使っている機能の一覧を人の手で棚卸ししてください。
移行先でもファイルの扱いには注意が必要です
移行元だけの問題ではありません。たとえばAirtableでは、APIで取得できる添付ファイルのURLに有効期限があります。移行元でも移行先でも、最も壊れやすいのは添付ファイルです。この観点はAirtableのバックアップ方法3段構えにもまとめています。
並行稼働の設計
理想は、旧システムが使えるうちに新システムを動かし始めることです。ただし並行稼働には二重のコストがかかります（旧システムの費用が残ったまま、新システムの構築費と運用が始まる）。
| 進め方 | 向くケース | リスク |
|---|---|---|
| 一斉切り替え | 利用部署が限定的／データがシンプル | 問題が出たとき戻せない |
| 並行稼働（推奨） | 複数部署が使う／業務を止められない | 二重入力の負荷。期間を区切らないと定着しない |
| 段階移行（部署単位） | 部署ごとに使い方が違う | データが分断する期間が生まれる |
並行稼働を選ぶ場合、「いつ旧システムへの入力をやめるか」を先に決めてください。これを決めずに始めると、両方に入力し続ける状態が続き、現場が疲弊します。
解約前チェックリスト
この順で確認すると漏れません
- 1契約書で解約通知の期限を確認（満了日ではなく通知期限。ここが起点）
- 2使っている機能の棚卸し（レポート・自動化・連携。データ以外を書き出す）
- 3エクスポートを一度テスト実行（本番直前が初回にならないように。添付を含めるとサイズと時間が変わります）
- 4移管完了目標を最終使用日より前に置く（8割を目安に。残り2割で想定外が出ます）
- 5並行稼働の終了日を決める（旧システムへの入力をいつやめるか）
- 6移行先の構築期間を確認（一般的に3〜6ヶ月。外注する前に用意するもの参照）
まとめ
解約で見るべきは「更新を断る期限」「最終使用日」「移管完了目標」の3つの日付です。そして移行の準備期間（3〜6ヶ月）を足すと、動き出すべきタイミングは想像よりずっと早いことが分かります。値上げの通知が来てから検討を始めると、たいてい1年分を払ってからの移行になります。
社内を通す段取りは稟議・情シス承認を通す方法に、移行後のデータ整理はExcelからの移行手順（表記ゆれ・重複の処理）にまとめています。
この記事の情報について
エクスポート仕様は2026年9月時点の公開情報にもとづきます。契約条件・エディションによって解約通知の期限やエクスポートの実行間隔は異なります。必ず自社の契約書と管理画面でご確認ください。事例は実際の支援案件にもとづきますが、企業が特定されない範囲に抽象化しています。
他の記事