【Salesforce】データローダが想定と違う時の監査ログと履歴で追う方法

Salesforceのデータローダは、大量のレコードを一括でインポート・更新・削除できる便利なツールですが、操作後に「想定と異なる結果になった」と気づくことがあります。例えば、特定のレコードだけ更新されていない、意図しない値が書き込まれた、または処理件数が一致しないといったケースです。こうした場合、原因を特定するにはデータローダのログだけでなく、Salesforceが自動的に記録する監査ログやレコードの履歴を活用するのが効果的です。本記事では、データローダの実行結果が想定と違ったときに、どのように調査を進めればよいのかを具体的な手順とともに解説します。

データローダの処理結果が想定と違う原因とは

データローダを使用したあとに、期待した結果と異なる状況が発生する原因は多岐にわたります。代表的なものとして、CSVファイルのデータ形式やマッピングの誤り、外部IDの重複、参照整合性エラー、または更新日時や作成者の記録が期待と異なるなどが挙げられます。また、データローダはバッチ処理であるため、1つのバッチ内で一部のレコードだけ失敗することもあり、全体の成功件数だけでは問題を見落としがちです。こうした原因を特定するためには、まずデータローダ自身が出力するログファイルを確認し、次にSalesforce側に記録される監査ログやオブジェクトの履歴を照合する流れが基本となります。

データローダのログファイルの確認

データローダの実行後、指定した出力フォルダに「success.csv」と「error.csv」の2つのファイルが生成されます。success.csvには正常に処理されたレコードのIDや外部IDが記録され、error.csvには失敗したレコードとエラーメッセージが記録されます。まずはこのerror.csvを開き、エラーの内容を確認しましょう。よくあるエラーとして、「REQUIRED_FIELD_MISSING」「DUPLICATES_DETECTED」「INVALID_FIELD_FOR_EXCEPTION」などがあります。これらのエラーメッセージを手がかりに、データの修正や再実行を行います。ただし、success.csvに記録されていても、実際のレコード内容が意図と異なる場合は、さらに深掘りする必要があります。

操作履歴と監査ログの違い

Salesforceには2種類の追跡機能があります。「操作履歴(Setup Audit Trail)」はシステム管理者が設定変更した内容を記録するもので、データレコードの変更は含まれません。一方、「監査ログ(EventLogFile)」はより詳細なアクセスログで、データローダによるAPIコールや各操作のタイムスタンプ、ユーザ、IPアドレスなどを含みます。また、標準オブジェクトの多くには「変更履歴(Field History)」が有効化可能で、特定項目の値がいつ、誰によって変更されたかを追跡できます。調査の目的に応じて、これらを使い分けることが重要です。

レコードの履歴から変更を追跡する方法

データローダで更新したはずのレコードの内容が想定と異なる場合、そのレコードの「変更履歴(Field History)」を参照することで、実際にどの項目がいつ変更されたかを確認できます。以下の手順で調査してください。

1. Salesforceにログインし、該当のレコード(例:取引先や商談)の詳細画面を開きます。
2. 画面右上の「詳細」リンクをクリックし、関連リストの一覧を表示します。
3. 「変更履歴」関連リストが表示されていない場合は、ページのレイアウト編集権限が必要なため、管理者に追加を依頼してください。
4. 変更履歴リストには、項目名、旧値、新値、変更日時、変更者が表示されます。データローダで実行した日時と一致するエントリを探します。
5. もし変更履歴にデータローダによる変更が記録されていない場合、そのレコードはデータローダの対象外であったか、別のユーザやプロセスによって上書きされた可能性があります。

変更履歴は標準で有効になっているオブジェクトと項目に限られます。カスタムオブジェクトや一部の項目では履歴が取れない場合があるため、事前に管理者に確認しておきましょう。

監査ログでデータローダの実行を特定する方法

データローダはAPIを通じてデータを操作するため、監査ログ(EventLogFile)を活用すると、どのユーザがいつ、どのような操作を行ったかを詳細に把握できます。監査ログを参照するには「イベント監視ファイル」の権限が必要で、通常はシステム管理者のみアクセス可能です。以下の手順でデータローダの実行を特定します。

1. 「設定」メニューから「イベント監視ファイル」を検索して開きます。
2. 「APIイベント」または「レコード監査イベント」のログファイルをダウンロードします。通常は24時間ごとに生成されます。
3. ダウンロードしたCSVまたはJSONファイルをExcelなどで開き、データローダを実行した日時とユーザ名でフィルタリングします。
4. データローダのセッションIDやAPIバージョン、操作種別(insert, upsert, update, delete)を確認します。
5. 操作の対象となったレコードIDが記録されている場合、そのIDを使ってレコードの履歴と突き合わせます。

監査ログは大量のデータを含むため、目的の操作を特定するにはフィルタリングが欠かせません。また、ログの保持期間はエディションによって異なりますので、早めに確認することをおすすめします。

データローダと手動操作の監査ログ比較表

項目	データローダ(API経由)	手動操作(UI)
監査ログ上の操作種別	「API」イベントとして記録(例:RestApi、SoapApi)	「レコード監査」イベントとして記録
変更履歴への記録	変更履歴に「データローダ」と表示される場合あり(API名による)	変更者にユーザ名が表示される
IPアドレスの記録	ログインユーザのIPアドレスが記録	同様
実行ユーザの特定	APIコールを実行したユーザ(通常はデータローダを動かしたユーザ)	画面操作を行ったユーザ

よくある失敗パターンとその対処

データローダのトラブルにはいくつかの典型的なパターンがあります。以下に代表的な例とその調査方法を紹介します。

• パターン1:一部のレコードだけ更新されない – エラーログに記録がない場合、外部IDの重複や参照整合性エラーが原因かもしれません。変更履歴で該当レコードが他のプロセスでロックされていないか確認します。
• パターン2:意図しない値が書き込まれた – マッピングで列を間違えている可能性があります。CSVの列とオブジェクト項目の対応を再確認し、テスト環境で試行するのが安全です。
• パターン3:正常終了したが件数が合わない – success.csvの件数と監査ログのAPIコール回数が一致するか確認します。バッチ分割が原因で重複カウントされている場合もあります。
• パターン4:変更履歴に記録が残っていない – 変更履歴が有効になっていない項目やオブジェクトが対象です。管理者に問い合わせて有効化を依頼しましょう。

管理者に確認すべきポイント

データローダの調査では、自分だけで完結できないケースも多いため、システム管理者に以下の点を確認してください。

• 監査ログ(EventLogFile)へのアクセス権限があるか。
• 該当オブジェクトで変更履歴が有効になっているか。
• データローダで使用したAPIバージョンに制限や既知の問題がないか。
• 同時実行制限やガバナー制限に抵触していないか。
• ログの保持期間はどの程度か(監査ログは30日～最長1年)。

まとめ

データローダの操作後に想定と異なる結果が生じた場合、まずデータローダの成功・エラーログを確認し、次にレコードの変更履歴や監査ログを活用して原因を特定します。変更履歴はユーザとタイムスタンプを、監査ログはAPI操作の詳細を提供するため、これらを組み合わせることで多くのトラブルを解決できます。また、調査には管理者の協力が必要なケースが多いため、スムーズに連絡できる体制を整えておきましょう。日頃からデータローダの実行前にテスト環境で検証し、変更履歴の有効化を促進することで、問題発生時の解決が格段に容易になります。