Salesforce データローダ完全ガイド:管理者向け徹底解説

背景と適用シナリオ

こんにちは! Salesforce 管理者の皆さん。日々の運用業務、お疲れ様です。今回は、私たち管理者にとって最も強力な武器の一つである Data Loader (データローダ) について、その基本からベストプラクティスまでを徹底的に解説します。Salesforce のデータを扱う上で、Data Loader を使いこなせるかどうかは、業務効率を大きく左右します。

Data Loader は、Salesforce が公式に提供しているクライアントアプリケーションで、データの一括挿入 (Insert)更新 (Update)アップサート (Upsert)削除 (Delete)、そしてエクスポート (Export/Export All) を行うために使用されます。GUI (グラフィカル・ユーザー・インターフェース) と CUI (コマンドライン・インターフェース) の両方をサポートしており、様々なシナリオで活用できます。

では、具体的にどのような場面で Data Loader は活躍するのでしょうか?

主な適用シナリオ

  • 初期データ移行: 他の CRM システムや Excel ファイルなど、既存のシステムから Salesforce へ初めてデータを移行する際に、数十万、数百万件のレコードを一括で登録します。
  • 大量データの更新: 組織再編に伴う担当者の変更、製品価格の一斉改定、リードソースのクレンジングなど、既存の多数のレコードを一度に更新する必要がある場合。
  • データのバックアップ: 定期的に Salesforce のデータをエクスポートし、オフラインでバックアップを保管します。特に `Export All` 機能を使えば、アーカイブされた活動やごみ箱にあるレコードも抽出できます。
  • データのクレンジングと削除: 古くなったデータや重複したレコードを特定し、一括で削除する場合。
  • 外部システムとの連携: 基幹システムから出力された売上データを Salesforce のカスタムオブジェクトに毎夜インポートするなど、定期的なデータ連携のバッチ処理として利用します(主にコマンドライン版を使用)。

Salesforce には標準で「データインポートウィザード」という機能もありますが、これは50,000件までのレコードしか扱えず、対応オブジェクトも限られています。一方、Data Loader は最大500万件のレコードを処理でき、カスタムオブジェクトを含むほぼ全てのオブジェクトに対応しているため、大規模なデータ操作には不可欠なツールと言えるでしょう。


原理説明

Data Loader がどのようにして Salesforce と通信し、データを処理しているのか、その裏側の仕組みを理解することは、トラブルシューティングやパフォーマンスチューニングにおいて非常に重要です。Data Loader は、主に2種類の Salesforce API (Application Programming Interface) を利用しています。

1. SOAP API

SOAP API は、リアルタイムな情報連携を目的とした Web サービスプロトコルです。Data Loader で SOAP API を使用すると、データは比較的小さなバッチ (Batch) と呼ばれる塊に分割されて、一つずつ同期的に処理されます。デフォルトのバッチサイズは200件です。

  • 特徴: 1件ずつの処理結果が即座に返ってくるため、小規模(数千〜数万件程度)のデータロードに適しています。
  • 注意点: 各バッチが1回の API コールを消費するため、大量のデータを処理すると、組織の API 制限に達しやすくなります。

2. Bulk API

Bulk API は、その名の通り、大規模なデータセットを効率的に処理するために設計された、非同期の REST ベースの API です。Data Loader の設定で "Use Bulk API" (Bulk API を使用) にチェックを入れることで利用できます。

  • 特徴: データは大きな塊として Salesforce に送信され、サーバー側で非同期(バックグラウンド)で処理されます。SOAP API に比べて API コールの消費量が大幅に少なく、処理速度も高速です。数十万件以上のデータを扱う場合は、Bulk API の利用が強く推奨されます。
  • 仕組み: データをジョブとして登録し、複数のバッチに分割して並列処理を実行します。処理が完了するまでステータスをポーリングし、完了後に結果を取得します。

管理者として私たちが Data Loader を操作する際の流れは、以下のようになります。

  1. CSV ファイルの準備: 操作対象のデータを CSV (Comma-Separated Values) 形式のファイルで用意します。1行目がヘッダー(項目名)、2行目以降がデータとなります。
  2. 認証: Data Loader を起動し、Salesforce 組織(本番環境 or Sandbox)へログインします。OAuth (オーオース) またはユーザ名とパスワード(セキュリティトークンが必要な場合あり)で認証を行います。
  3. 操作とオブジェクトの選択: 「Insert」「Update」などの操作と、対象となる Salesforce オブジェクト(取引先、取引先責任者など)を選択します。
  4. 項目マッピング: CSV ファイルの列(ヘッダー)と Salesforce オブジェクトの項目(API参照名)を対応付けます。
  5. 処理実行と結果の確認: 処理を実行すると、Data Loader は指定された API を通じて Salesforce と通信します。処理完了後、「success (成功)」と「error (エラー)」の2つの結果ファイルが生成されます。これらのファイルを確認し、エラーが発生した場合は原因を特定して対処します。

この一連の流れを正確に実行することが、データ操作を成功させる鍵となります。


使用例:外部IDを用いた取引先責任者の Upsert

ここでは、管理者業務で非常によく使う「Upsert」操作を例に、具体的な手順を解説します。Upsert は、対象のレコードが Salesforce 内に存在すれば「Update」、存在しなければ「Insert」を自動的に判断してくれる便利な機能です。これを実現するためには、External ID (外部ID) と呼ばれる一意の識別子が必要になります。

Step 1: 準備

  1. 外部ID項目の作成:
    まず、Salesforce の「取引先責任者」オブジェクトに、外部IDとして機能するカスタム項目を作成します。「設定」→「オブジェクトマネージャ」→「取引先責任者」→「項目とリレーション」から新規作成します。データ型は「テキスト」を選び、長さ(例: 255)、「外部ID」「ユニーク」のチェックボックスをオンにします。API 参照名は `Legacy_Contact_ID__c` としましょう。
  2. CSV ファイルの準備:
    以下のような CSV ファイルを準備します。`Legacy_Contact_ID__c` 列には、既存システムで使われていた一意のIDなどを入れます。このIDを使って、Data Loader は更新対象のレコードを特定します。
    FirstName,LastName,Email,Legacy_Contact_ID__c,AccountId
    Taro,Yamada,taro.yamada@example.com,CUST-001,0015j00000AbCdEfG
    Hanako,Suzuki,hanako.suzuki@example.com,CUST-002,0015j00000AbCdEfG
    Jiro,Sato,jiro.sato@example.com,CUST-003,0015j00000AbCdEfG
    

    ポイント: `AccountId` 列には、この取引先責任者が紐づく「取引先」レコードの Salesforce ID (18桁) を指定します。このように関連レコードを指定する場合は、親レコードの ID が必要です。

Step 2: Data Loader での操作

  1. ログイン: Data Loader を起動し、「Upsert」ボタンをクリックします。ログイン画面が表示されたら、対象の環境(Production/Sandbox)を選択し、OAuth 方式でログインします。
  2. オブジェクトと CSV の選択: ログイン後、Upsert 対象のオブジェクトとして「Contact (取引先責任者)」を選択します。次に、先ほど準備した CSV ファイルを指定します。
  3. 外部IDの選択: 次の画面で、レコードを照合するための項目を聞かれます。ここでは、取引先責任者オブジェクトの外部ID項目 `Legacy_Contact_ID__c` を選択します。これにより、Data Loader は CSV の `Legacy_Contact_ID__c` 列の値と、Salesforce 内の取引先責任者の `Legacy_Contact_ID__c` 項目の値を比較して、既存レコードかどうかを判断します。
  4. 項目マッピング: マッピング画面が表示されます。「Create or Edit a Map」ボタンを押し、「Auto-Match Fields to Columns」をクリックすると、CSV のヘッダー名と Salesforce の項目名が同じものを自動で対応付けてくれます。`FirstName` → `FirstName`、`LastName` → `LastName` のようにマッピングされていることを確認し、OK をクリックします。
  5. 処理の実行: 最後に、成功ファイルとエラーファイルの保存先ディレクトリを指定し、「Finish」をクリックします。処理が開始され、進行状況が表示されます。
  6. 結果の確認: 処理が完了すると、ダイアログに成功件数とエラー件数が表示されます。必ず指定したディレクトリに生成された `success.csv` と `error.csv` の両方を確認してください。`error.csv` には、エラーになったレコードと、その理由(例: `REQUIRED_FIELD_MISSING` (必須項目がありません))が記載されています。エラーを修正し、エラーファイルだけを再度アップロードすることも可能です。

注意事項

Data Loader は強力なツールですが、誤った使い方をすると組織のデータに深刻な影響を与えかねません。以下の点には常に注意を払いましょう。

権限 (Permissions)

  • API の有効化: Data Loader を使用するユーザのプロファイルには、「API の有効化 (API Enabled)」権限が必要です。
  • オブジェクト権限: 対象オブジェクトに対する適切な参照・作成・編集・削除 (CRUD) 権限が必要です。例えば、取引先レコードを更新するには「編集」権限が、新規作成するには「作成」権限が必須です。
  • 「すべてのデータの変更」権限: この権限を持つユーザは、共有ルールや項目レベルセキュリティの一部を無視してデータを操作できます。非常に強力な権限であるため、使用は慎重に行うべきです。

API 制限 (API Limits)

  • Data Loader の操作は、組織の API コール数を消費します。特に SOAP API を使用して大量のデータを処理すると、1日の上限に達してしまう可能性があります。「設定」の「組織情報」から、現在の API 使用状況を常に把握しておきましょう。
  • 前述の通り、大量データを扱う際は Bulk API を使用することで、API コールの消費を大幅に抑えることができます。

データ形式と検証ルール (Data Format and Validation Rules)

  • 日付/時間形式: `2023-10-27T10:00:00.000Z` のような特定の形式(ISO 8601)で指定する必要があります。Excel で日付を扱う際は、セルの書式設定に注意してください。
  • Boolean 型 (チェックボックス): `true`/`false` または `1`/`0` を使用します。
  • リレーション項目: 取引先責任者の `AccountId` のように、他のオブジェクトとのリレーション項目(参照関係、主従関係)には、親レコードの18桁の Salesforce ID を指定する必要があります。VLOOKUP 関数などを使って、事前に CSV ファイル上で ID を付与しておく作業が一般的です。
  • 入力規則とトリガ: Data Loader での操作も、Salesforce 上で設定された入力規則 (Validation Rules)、Apex トリガ (Apex Triggers)、フロー (Flows) などの自動化プロセスを起動します。これにより、予期せぬエラーが発生したり、パフォーマンスが低下したりすることがあります。大規模なデータ移行の際は、一時的にこれらの自動化を無効にすることも検討します(ただし、ビジネスロジックへの影響を十分に評価した上で判断してください)。

エラー処理 (Error Handling)

  • データロードが完了したら、結果を鵜呑みにせず、必ず成功ファイルとエラーファイルを確認する癖をつけましょう。
  • エラーファイルには、失敗した理由が具体的に記載されています。これをヒントに元の CSV を修正し、エラーファイル自体を次のデータロードの入力ファイルとして使用することで、効率的にエラーを解消できます。

まとめとベストプラクティス

Data Loader は、私たち Salesforce 管理者が大量のデータを迅速かつ正確に処理するための、非常に信頼性の高いツールです。その原理を理解し、正しい手順で慎重に操作すれば、日々の業務効率を飛躍的に向上させることができます。

最後に、Data Loader を安全かつ効果的に活用するためのベストプラクティスをまとめます。

  • 必ず Sandbox でテストする:

    本番環境でいきなり大量のデータを操作するのは非常に危険です。必ず、本番環境の構成をコピーした Full Sandbox や Partial Sandbox で、一連の操作をリハーサルしてください。

  • 大規模データには Bulk API を使用する:

    数万件を超えるデータを扱う場合は、パフォーマンスと API コール消費の観点から、Bulk API の利用がほぼ必須です。

  • 適切なバッチサイズを設定する:

    Data Loader の設定でバッチサイズを調整できます。トリガなどの処理が複雑な組織では、バッチサイズを小さくする(例: 50)ことで、`CPU time limit exceeded` のようなガバナ制限エラーを回避できる場合があります。逆に、シンプルなデータロードでは、バッチサイズを大きくする(例: SOAP API で200、Bulk API で10,000)と処理が高速化します。

  • 更新・アップサートには外部IDを活用する:

    レコードIDは環境によって異なるため、Sandbox から本番へデータを移行・更新する際には、外部IDが非常に役立ちます。一意性を保てる項目を外部IDとして定義する運用を心がけましょう。

  • 操作前には必ずバックアップを取得する:

    特に大量の更新や削除を行う前には、Data Loader の「Export」機能や、Salesforce の「データのエクスポート」サービスを使って、対象データのバックアップを取得しておきましょう。万が一の事態に備えることが重要です。

  • ログファイルを保管する:

    いつ、誰が、どのようなデータ操作を行ったのかを追跡できるように、成功ファイルとエラーファイルは、作業記録として一定期間保管しておくことをお勧めします。

これらのプラクティスを実践し、Data Loader を自信を持って使いこなせるようになりましょう!

コメント