Salesforceからクリーンにエクスポートする: 移行対応エクスポートガイド

著者: Calvin D. · 更新日: 2026年4月18日

あるミッドマーケットSaaS企業のSales OpsチームはCRM移行の準備に6週間かけました。ContactとAccountをエクスポートし、いくつかのレコードをスポットチェックし、エクスポート完了と判断しました。go-liveの3日後、新しいCRMで4,200件の連絡先に活動履歴がゼロと表示されました。チームはTaskとEvent、つまりすべての通話ログ、メール、ミーティングが存在する2つのSalesforceオブジェクトをエクスポートしていなかったのです。3年分のインタラクション履歴が消えました。

エクスポート自体は20分で完了しました。復元にはメールアーカイブと担当者の記憶からの手作業による再構成に3週間かかりました。すべてのレコードが戻ることはありませんでした。

このガイドでは、オブジェクト、リレーションシップ、カスタムフィールド、活動履歴を完全に保持するSalesforceのエクスポートプロセスを順番に説明します。手順は順番通りに実行してください。順序が重要です。

Salesforceのデータが何に対応するかを理解する

エクスポートツールに触れる前に、何を抽出するかを理解する必要があります。Salesforceはデータをオブジェクトに整理しています。多くのチームは明らかなものは知っています。見落とすものが問題を引き起こします。このマッピング作業は旧システムと新システム間のフィールドマッピングに直接つながります。抽出するオブジェクトを把握せずに信頼性の高いフィールドマップは作れません。

Gartnerのデータ品質に関する調査によれば、データ品質の低さによって企業は平均で年間約12億円の損失を被っており、CRM移行はデータ品質が最も低下しやすいリスクの高い局面の一つです。

必ずエクスポートすべきオブジェクト:

リレーションシップグラフはAccount → Contact → Opportunityで構成され、TaskとEventがすべてに添付されます。AccountなしでContactをエクスポートすると、すべてのContactがインポート時に会社のアソシエーションを失います。TaskとEventをスキップすると、活動タイムラインが完全に消えます。

開始前に自社の環境で使用しているすべてのオブジェクトを書き出します。確信がない場合はSalesforceの管理者に確認してください。

ステップ1: Data ExportとData Loaderの使い分け

Salesforceには2つの主要なエクスポートツールがあります。これらは互換性がありません。

Data Export（設定 > Data Export）

• UIを通じて週次でスケジュールするか、オンデマンドで実行
• オブジェクト別に1つのzipファイルにすべてをエクスポート
• 制限: ファイルあたり約512MB。大規模な環境ではContactやOpportunityでこの制限に達する
• フィルタリングなし: 各オブジェクトのすべてのレコードが含まれる
• 適している場合: 小〜中規模の環境、最初のフルエクスポート、Salesforce管理の経験が少ないチーム

Data Loader

• スタンドアロンのデスクトップアプリケーション（Windows/Mac）
• 大容量に対応: 数千万件のレコードまで検証済み
• SOQLクエリが必要: 取り出すフィールドを正確に制御できる
• 日付範囲、RecordType、または任意のフィールド値でフィルタリング可能
• 適している場合: 大規模な環境、選択的なエクスポート、複雑なリレーションシップを持つカスタムオブジェクト

ほとんどの移行ではData Loaderが正しい選択です。Data Exportはオブジェクトあたり5万件未満の環境では問題ありませんが、複雑なフィールドリレーションシップや大きな活動履歴を扱う場合、Data Loaderはより細かい制御を可能にします。自社の環境が複雑な移行に該当するか確認するには、データ移行前の準備でエクスポートが始まる前に作業をスコープ化します。

APIレート制限に関する注意: Data LoaderはSalesforceのAPIを使用します。他のインテグレーションが同時に稼働している環境では、エクスポート途中でレート制限に達することがあります。大きなエクスポートは時間外に実行するか、Salesforce管理者にAPIの割り当てを確認してください。SalesforceのData Loaderデベロッパードキュメントでは、バッチサイズの設定とAPIの使用制限について詳しく説明しています。

ステップ2: 正しい順序でエクスポートする

Salesforceのオブジェクト依存関係により、参照するレコードが移行先システムに存在しなければ、一部のレコードは意味のある形でインポートできません。間違った順序でエクスポートすると、孤立したレコードで埋まったCSVファイルが出来上がります。

必須のエクスポート順序:

1. Account
2. Contact（Accountを参照）
3. Lead（独立しているが早めにエクスポート）
4. Opportunity（Accountを参照）
5. OpportunityContactRole（OpportunityとContactをリンクする結合オブジェクト）
6. Task（Contact、Lead、Opportunity、Accountを参照）
7. Event（Taskと同じ）
8. EventRelation（複数の参加者がいる共有ミーティングを使用している場合）
9. Case（使用している場合）
10. カスタムオブジェクト（独自の依存関係順序でエクスポート）

なぜAccountが最初なのか？ContactはAccountIdを参照するからです。移行先システムにContactをインポートする際、ContactはすでにあるAccountレコードを参照する必要があります。Accountを先にエクスポートし、先にインポートし、その後に正しいAccountアソシエーションを持つContactを処理します。

OpportunityContactRoleはサイレントな落とし穴です。これはどのContactがどのOpportunityに関連付けられているかを保存する結合オブジェクトです。スキップすると、Opportunityが新しいCRMに入った時点で連絡先のリレーションシップが一件もない状態になります。多くのチームがその存在を忘れています。同じ原則が過去の活動履歴、メモ、メールの取り扱いにも当てはまります。リレーションシップデータと活動履歴はどちらも、デフォルトの「全エクスポート」ではなく、意図的なエクスポート判断が必要です。

ステップ3: 参照フィールドとIDを処理する

ここからエクスポートが技術的に重要になります。Salesforceのすべての参照フィールドにはSalesforceのレコードID（18文字の英数字の文字列）が含まれています。このIDはSalesforce外では意味をなしません。ContactレコードのAccountIdフィールドを開くと、001A000001B2cDEFABのような文字列が表示されます。このIDは新しいCRMには存在しません。

対応方法:

すべての参照フィールドについて、SalesforceのIDと並んで関連レコードの意味のある識別子もエクスポートします。Contactの場合、AccountIdとAccount.Nameの両方を同じ行にエクスポートします。Opportunityの場合、AccountIdとAccount.Name、さらにOwnerIdとOwner.Nameをエクスポートします。

Data Loaderの場合、SOQLクエリは次のようになります:

SELECT Id, FirstName, LastName, Email, Phone, AccountId, Account.Name,
       OwnerId, Owner.Name, LeadSource, CreatedDate
FROM Contact

ドット表記法（Account.Name）は関連フィールドをインラインで取得します。これにより整理とインポートのステップで、SalesforceのIDと並んで人間が読める参照が得られます。

外部ID: 環境がカスタム外部IDフィールドを使用している場合（ERPや請求システムと連携している環境では一般的）、それらのフィールドもエクスポートします。これらが移行先システムでの結合キーになります。

ID変換参照テーブル:

すべてのIDと並んでリレーションシップ名をエクスポートします。次のステージのフィールドマッピング時に必要になります。

ステップ4: 活動履歴を正しくエクスポートする

TaskとEventは独自のオブジェクトに存在します。ContactやOpportunityのレコードに埋め込まれているわけではありません。また、上記の参照フィールドと同じ処理が必要な独自のリレーションシップフィールドがあります。

Task（Data Loaderを使ったSOQL）:

SELECT Id, Subject, Description, Status, Priority, ActivityDate,
       WhoId, Who.Name, Who.Type,
       WhatId, What.Name, What.Type,
       OwnerId, Owner.Name, CreatedDate
FROM Task
WHERE ActivityDate >= 2022-01-01

WhoIdはタスクに関係する人物（ContactまたはLead）です。WhatIdは関連するレコード（Opportunity、Account、またはCase）です。IDと名前の両方をエクスポートします。

Eventの場合:

SELECT Id, Subject, Description, StartDateTime, EndDateTime, Location,
       WhoId, Who.Name, WhatId, What.Name, OwnerId, Owner.Name, CreatedDate
FROM Event
WHERE StartDateTime >= 2022-01-01T00:00:00Z

日付範囲でのフィルタリング: ほとんどのチームは創業当初からのすべてのTaskとEventが必要なわけではありません。特定の業務上の理由がない限り、直近2〜3年にフィルタリングします。成熟したSalesforce環境からフィルタリングなしで活動をエクスポートすると、実際の内容のないシステム自動生成イベントを多数含む数百万件のレコードになる場合があります。移行するものとアーカイブするものについての判断フレームワークは過去の活動履歴、メモ、メールの取り扱いを参照してください。

WhoId.TypeフィールドはタスクがContactとLeadのどちらにリンクされているかを示します。インポート時に正しく振り分けられるようにエクスポートします。

ステップ5: Salesforceを離れる前にエクスポートを検証する

整理を始める前にエクスポートが完全であることを確認します。この確認は30分で完了し、go-liveの6週間後に表面化するような問題を事前に発見できます。

行数検証:

スポットチェックのプロセス:

エクスポートからランダムなContactレコード20件を選びます。各レコードについて:

1. Salesforceでレコードを開く
2. 主要なフィールドがCSVの行と一致するか確認
3. Account.Nameが入力されているか確認
4. 関連する活動タイムラインに少なくとも1件のTaskまたはEventが表示されているか確認
5. いずれかのレコードが失敗したら、続行前に調査する

カスタムフィールドの完全性:

「設定 > オブジェクトマネージャー > [オブジェクト] > 項目とリレーションシップ」からフィールドリストを取得します。これをエクスポートの列ヘッダーと比較します。欠けている列は、SOQLクエリに追加フィールドを加えて再エクスポートが必要なことを意味します。

Salesforceエクスポートチェックリスト

エクスポートにサインオフする前にこれを使います:

• 必要なオブジェクトをすべて特定してリストアップ
• エクスポートの順序がAccount → Contact → Lead → Opportunity → OpportunityContactRole → Task → Eventに従っている
• すべての参照フィールドに、SalesforceのIDと並んで関連レコードの人間が読める名前が含まれている
• TaskとEventのWhoIdとWhatIdフィールドに.Nameと.Typeが含まれている
• Salesforceのレポートまたはデベロッパーコンソールのクエリで行数を検証
• オブジェクトごとにランダム20件のレコードをスポットチェック
• オブジェクトのフィールドリストに対してカスタムフィールドを確認
• 活動履歴を適切な日付範囲にフィルタリング
• エクスポートファイルをアクセスを移行チームに限定した管理された場所に保管

よくある失敗パターン

**ContactのみエクスポートしてAccountを忘れる。**ContactはAccountを参照します。Accountがなければ、すべてのContactがインポート時に会社のアソシエーションを失います。常にAccountを先にエクスポートします。

**数式フィールドの値を失う。**Salesforceの数式フィールドは動的に計算されます。値は保存されません。エクスポートすると、エクスポート時点の計算値が取得されます。数式が参照する別のオブジェクトが変更された場合、エクスポートされた値は更新されません。数式フィールドはそのままエクスポートし、どれが数式フィールドかをフィールドマップに記録します。

**RecordTypeを忘れる。**環境がRecordTypeを使用している場合（異なるレコードカテゴリで異なるページレイアウトとピックリスト値を持つ場合）、RecordType.Nameフィールドをエクスポートに含める必要があります。RecordTypeの区別は移行先CRMでのレコードの分類方法に影響することがよくあります。

**エクスポート途中にAPIレート制限に達する。**Data Loaderはバッチでかたります。大規模なエクスポート（例: Task200万件）は環境の日次API割り当てを使い切ることがあります。バッチの進捗を監視し、大きなオブジェクトは必要に応じて夜間にエクスポートします。

**削除されたレコードをエクスポートしない。**ソフト削除されたレコード（ごみ箱内）を移行する必要がある場合は、SOQLでALL ROWSを使った別のクエリが必要です。ほとんどのチームには不要ですが、エクスポート前にステークホルダーに確認する価値があります。NISTのデータ整合性ガイドラインは、システム移行時にどのレコードを保持すべきかを定義するための有用なフレームワークを提供しています。移行しないが保持が必要なレコードは、移行先システムではなくレガシーCRMデータの長期アーカイブに入れます。放置してはいけません。

次に取るべき行動

検証済みのエクスポートはこれ以降のすべての作業の原材料です。しかし、生のエクスポートファイルはインポートできる状態ではありません。移行先CRMのインポートツールを開く前に、整理、重複排除、フィールドマッピングが必要です。

次のステップはデータクレンジング: 重複排除、正規化、エンリッチメントです。新しいシステムに移行する前にエクスポートされたCSVをそのプロセスに通します。McKinseyのデータ戦略レポートでは、強力なデータガバナンスの規律を持つ企業は顧客獲得率が23倍高いとされています。整理・検証済みのエクスポートから移行を開始することは、その規律の基盤です。

フィールドマッピングがまだ確定していない場合は、旧システムと新システム間のフィールドマッピングで整理開始前に必要な判断を行います。

TaskとEventの扱いをまだ決めていない場合は、データ移行前の準備でエクスポートとインポートのすべての判断の形を決める戦略的な判断を扱っています。

関連ガイド

• データクレンジング: 重複排除、正規化、エンリッチメント
• 旧システムと新システム間のフィールドマッピング
• データ移行前の準備
• シャドーインポートによる移行テスト
• CRMデータモデル設計: カスタムフィールド、オブジェクト、リレーションシップ
• go-live後のCRMデータ品質管理文化