【Salesforce】Sandbox更新で困った時の監査ログと履歴で追う方法

SalesforceのSandbox更新は、本番環境の最新状態を開発・テスト環境に反映する重要な作業です。しかし更新後に、データが正しく移行されていない、項目の値が想定と異なる、自動化がいつも通り動かないなどの問題が発生することがあります。こうした問題の原因を特定するには、Salesforceが提供する監査ログや履歴機能を活用するのが効果的です。本記事では、Sandbox更新後に困ったときの追跡方法を、具体的な手順や判断基準とともに解説します。

1. Sandbox更新でよくある問題と原因の切り分け方

問題の種類

Sandbox更新後に報告される問題は、大きく3つのカテゴリに分類できます。まずデータに関する問題です。例えば、更新前には存在していたレコードが消えている、参照関係が壊れている、数値が変わっているなどがあります。次に設定の問題です。カスタム項目の属性や自動化ルールの条件が変わった、レイアウトが更新されていないなどの事例です。最後は自動化の挙動に関する問題です。フローやプロセスビルダーが想定外のタイミングで動いたり、エラーになったりします。

切り分けの基本

原因を切り分けるには、まずSandboxのタイプと更新方法を確認します。フルコピーSandboxと開発者Sandboxでは振る舞いが大きく異なります。フルコピーSandboxでは最新のデータがコピーされますが、Data Exportのバックアップとは異なる点に注意が必要です。また、今回の更新が「Refresh」なのか「Clone」なのかによっても、保持される情報が変わります。これらの前提を踏まえた上で、次の手順で調査を進めます。

2. 監査ログ(Event Monitoring / 設定監査 / ログイン履歴)の見方と実践手順

監査ログへのアクセス方法

Salesforceには複数の監査ログ機能があります。設定の変更履歴は「設定監査証跡(Setup Audit Trail)」で確認できます。画面右上の歯車アイコンから「設定」に進み、検索バーに「監査証跡」と入力して遷移します。ここでは、ユーザによる設定変更が操作者、更新日時、変更内容とともに記録されています。

その他に、イベント監視(Event Monitoring)を有効化している組織では、イベントログファイル(.csv)をダウンロードして詳細な操作を分析できます。ただし、この機能は有料のアドオンであるため、多くの運用環境では「設定監査証跡」と「ログイン履歴」でまず調査します。

具体的な検索手順

1. Sandbox環境にログインし、設定(Setup)画面を開きます。
2. 「設定監査証跡」を開き、表示期間を「過去30日間」などに設定します。
3. 問題の発生時刻前後に実施された変更を確認します。特に「アクション」の列で、オブジェクトや項目の編集、権限セットの変更、自動化ルールの編集などがないかチェックします。
4. もし変更履歴が見つからない場合は、イベントログファイルが利用可能かを確認します。利用可能であれば、「Reports」メニューから「Event Monitoring」を開き、該当するイベントタイプ(例:ApiEvent、ReportEvent)をダウンロードします。
5. ログイン履歴は「ユーザ」>「ログイン履歴」から表示できます。Sandbox更新後に誰がいつログインしたか、どのIPからアクセスしたかなどを調査し、不正アクセスや設定変更の有無をチェックします。

設定変更履歴(Setup Audit Trail)の確認

設定監査証跡は、自分自身の変更だけでなく、他の管理者がいつどの設定を変更したかを把握するのに役立ちます。例えば、Sandbox更新直後に管理者Aが特定のオブジェクトの共有設定を変更していた場合、それが問題の原因かもしれません。このログは直近の変更のみ表示されるため、古い情報は「View All History」ボタンから全履歴をエクスポートして確認します。エクスポートは最大で過去6か月分が保存されています。

3. レコード履歴(Field History / 自動化後の変更)を使ったデータ追跡

項目履歴の有効化と確認手順

特定のレコードの値が変わった場合、そのオブジェクトで「項目履歴の追跡」が有効になっていれば、レコードの履歴関連リストから変更を確認できます。有効になっていないオブジェクトの場合、Sandbox更新後でも過去の変更を追跡できません。そのため、Sandbox更新前に重要なオブジェクトの追跡設定を確認しておくことが重要です。

確認手順としては、設定メニューの「オブジェクトマネージャ」から該当オブジェクトを選択し、「項目履歴の追跡」セクションを開きます。ここで、追跡対象の項目にチェックが入っているかを確認します。もし入っていなければ、チェックを入れて保存します。ただし、既存のデータの履歴は保存されない点に注意が必要です。

自動化による履歴の見方

自動化(フロー、プロセスビルダー、承認プロセス)による値の変更は、場合によっては「誰が変更したか」がシステムとして記録されます。フローなどがレコードを更新した場合、項目履歴には「自動化フロー」や「プロセスビルダー」が変更者として表示されることがあります。また、デバッグログを取得することで、自動化の実行詳細を追跡することも可能です。

ただし、自動化の再実行はSandbox更新時の設定により制御できます。「Sandboxの詳細」設定で「自動化ルールの無効化」を選択してから更新を行うと、更新後に自動化が実行されなくなります。問題を事前に防ぐためには、この設定を活用するか、更新前に手動で自動化を休止することを検討します。

4. Sandbox更新前後の設定差分確認とトラブルシューティング

Compare Sandbox機能の活用

Salesforceには「Sandboxの比較(Compare Sandbox)」機能が用意されています。この機能を使うと、本番環境とSandbox、または異なるSandbox間の設定差分を一覧表示できます。ただし、この機能はすべてのSandboxタイプで利用できるわけではなく、通常はフルコピーSandboxや部分データSandboxで利用可能です。

比較結果はカテゴリ別(オブジェクト、項目、権限、自動化など)に表示され、変更があった部分がハイライトされます。更新直後に本番環境とSandboxに差異が生じた場合、どの設定が変わったのかを特定できます。ただし、比較が可能なのは直近の更新との差分に限られる場合があるため、古いバージョンのバックアップを別途保持しておくことも検討します。

事前に取得すべきバックアップデータ

Sandbox更新前に、以下のデータをエクスポートまたは記録しておくと、トラブルシューティングに役立ちます。まず、設定のエクスポートです。Salesforceの設定メニューから「セットアップのダウンロード」で設定のスナップショットをXMLファイルとして保存します。次に、データのエクスポートです。Data Exportサービスを使うか、もしくは重要なレコードをCSVとして取得します。最後に、自動化ルールの現在の定義を、スケジュール済みアクションやフローのバージョンごとに記録します。

5. 関連テーブル:監査ログの種類と使い分け

ログの種類	保存期間	主な用途
設定監査証跡	約6か月(エクスポート可)	管理者が実施した設定変更の追跡
ログイン履歴	過去6か月	ログイン失敗や不正アクセスの確認
項目履歴	無制限(設定による)	特定レコードの項目値変更の追跡
イベントログファイル	約3日から7日(ライセンス依存)	APIコールやレポート実行など詳細分析

上記のログを目的に応じて使い分けることで、問題の原因を効率的に特定できます。特に設定監査証跡と項目履歴は、追加ライセンスなしで利用できるため、最初に確認することをおすすめします。

6. よくある質問と管理者連絡のポイント

よくある質問

Q1. Sandbox更新後、フローが突然動かなくなりました。原因は何でしょうか?
A. 更新時に自動化ルールが無効化される設定になっていない場合、フローはそのまま有効ですが、参照するオブジェクトや項目が変わった可能性があります。設定監査証跡でフローの定義が更新されていないかを確認してください。また、デバッグログを取得してエラー内容を特定します。

Q2. レコードの値が更新前と異なっています。誰が変更したのか知りたいです。
A. 該当オブジェクトで項目履歴が有効になっていれば、レコードの履歴関連リストから変更者と変更日時がわかります。有効でない場合は、あきらめるしかないかもしれませんが、設定監査証跡でバッチジョブやフローの実行記録を探す手もあります。

Q3. Sandbox更新後に、ユーザがログインできなくなりました。どうすればいいですか?
A. ログイン履歴から失敗理由を確認します。よくあるのが、IP制限やパスワードポリシーの変更です。設定監査証跡で直近の変更をチェックし、必要に応じて管理者に連絡して設定を元に戻してもらいます。

管理者に伝えるべき情報

問題が発生した際に管理者へ連絡するときは、以下の情報を整理して伝えると、迅速な対応が期待できます。

• 問題が発生したSandbox名と更新日時
• 影響を受けるユーザやレコードの具体例(オブジェクト名、レコードID)
• 確認した監査ログのスクリーンショットやCSV出力
• 期待する動作と実際の動作の差分

これらの情報を用意することで、管理者は原因を特定しやすいため、解決までの時間を短縮できます。

7. まとめ

Sandbox更新後の問題は、監査ログと履歴機能を使うことで多くの場合、原因を特定できます。最初に「設定監査証跡」と「項目履歴」を確認し、それでもわからない場合はイベントログファイルの解析やSandbox比較機能を利用します。Sandbox更新前には、設定やデータのバックアップを取得し、自動化ルールの再実行を制御する設定を確認しておくことが再発防止につながります。日頃から監査ログの保存期間を意識し、問題が起きたらできるだけ早く調査を開始することが重要です。