ADVERTISEMENT

【Salesforce】Sandboxの変更が本番に反映されない時のリリース手順と差分確認

【Salesforce】Sandboxの変更が本番に反映されない時のリリース手順と差分確認
🛡️ 超解決

SalesforceのSandbox環境で入念にテストした変更が、本番環境に反映されないという経験はありませんか。Sandboxはあくまで開発やテスト用の隔離された環境であり、そこで行った設定変更やカスタマイズは自動的に本番環境に同期されません。変更を本番に適用するためには、明示的なリリース手順を踏む必要があります。本記事では、変更が反映されない原因を切り分ける方法、正しいリリース手順、差分確認の具体的な手法について解説します。適切な手順を理解することで、リリース漏れや誤った設定のデプロイを防ぎ、安全に変更を適用できるようになります。

【要点】この記事で確認すること

  • 最初に見る場所: 変更セット(Outbound Change Set)のアップロード状態とデプロイ履歴を確認します。また、Sandboxと本番環境の接続設定(Deployment Connections)が正しく構成されているかも確認してください。
  • 切り分けの軸: 問題が「変更セットの内容不足」「権限や依存関係の欠落」「デプロイ自体の失敗」「差分確認ツールの誤解」のいずれに起因するのかを、段階的に切り分けます。
  • 注意点: 本番環境の直接操作は可能な限り避け、必ずSandboxで検証してからリリースしてください。また、デプロイには適切なプロファイル権限やApexテストクラスのカバレッジ(75%以上)が必要です。管理者権限がない場合は、事前にIT部門へ依頼しましょう。

ADVERTISEMENT

1. Sandboxの変更が本番に反映されない主な原因

原因を特定するには、まず前提としてSandboxと本番環境の関係を理解する必要があります。Sandboxは組織のコピーですが、双方向に自動同期されるわけではありません。以下に、よくある原因を挙げます。

1.1 リリース手順そのものを実施していない

最も単純な原因です。Sandbox内で設定を変更しただけで、変更セットを作成・アップロード・デプロイする一連の操作を行っていない場合、本番環境には一切反映されません。とくに初心者の場合、Sandboxでの作業がそのまま本番に反映されると誤解しているケースが多く見られます。

1.2 変更セットの内容に漏れがある

変更セットに追加するコンポーネントが不足しているケースです。たとえば、カスタムオブジェクトのみを追加し、そのオブジェクトに関連する項目、項目レベルのセキュリティ、ページレイアウトを忘れると、本番環境で不完全な状態になります。また、Apexクラスやトリガは関連するテストクラスも含める必要があります。

1.3 権限や依存関係の問題

デプロイ時に、本番環境に存在しない依存コンポーネントがあるとエラーになります。たとえば、Sandboxで作成したカスタム項目を参照する数式項目をそのままデプロイしようとすると、カスタム項目が先にデプロイされていないため失敗します。また、プロファイルや権限セットへの割り当てが不足していると、ユーザーが新しい機能を利用できません。

1.4 Apexテストカバレッジ不足によるデプロイ失敗

本番環境へのデプロイ時には、全Apexクラスのテストカバレッジが75%以上必要です。Sandboxで新しいApexコードを追加した場合、テストクラスも作成して十分なカバレッジを確保しないとデプロイが拒否されます。これはよくある失敗パターンの一つです。

2. リリースの基本手順(変更セットを使用)

Salesforceの標準機能である変更セットを利用したリリース手順を説明します。Sandbox組織から本番組織へ変更を移行する基本的な流れです。

2.1 変更セットの作成

  1. Sandbox環境にログインし、[設定](歯車アイコン)→ [変更セット] → [アウトバウンド変更セット] を開きます。
  2. [新規] をクリックし、変更セットに名前と説明を付けます(例:「2025年4月 リリース v1.2」)。
  3. [追加] から、本番環境に移行したいコンポーネントを選択します。コンポーネントの依存関係を自動検出する機能はないため、関連するすべての要素(カスタムオブジェクト、項目、ページレイアウト、Apexクラス、権限セットなど)を漏れなく追加してください。
  4. コンポーネントを追加したら [アップロード] をクリックします。アップロードが成功すると、変更セットのステータスが [アップロード済み] になります。

2.2 本番環境へのデプロイ

  1. 本番環境にログインし、[設定] → [変更セット] → [インバウンド変更セット] を開きます。
  2. Sandboxからアップロードされた変更セットが一覧に表示されます。[デプロイ] をクリックします。
  3. デプロイオプションで、テストの実行方法を選択します。「デフォルトのテストを実行」または「すべてのテストを実行」を推奨します。ただし、大量のテストがある場合は時間がかかるため、影響範囲が明確な場合は「テストなしでデプロイ」も可能ですが、Apexコードが含まれる場合は避けるべきです。
  4. [デプロイの開始] をクリックし、完了を待ちます。デプロイの進捗はリアルタイムで表示され、成功または失敗の結果が通知されます。
  5. デプロイが失敗した場合は、エラーメッセージを確認し、原因を修正して再度アップロード・デプロイを行います。エラー内容は多くの場合、依存関係の欠落やテストカバレッジ不足です。

3. 差分確認の方法

リリース前にSandboxと本番環境の差分を正確に把握することで、リリース漏れや不要な変更を防げます。いくつかの方法を紹介します。

3.1 変更セットの内容を確認する

アップロード済みの変更セットを開くと、含まれるコンポーネントの一覧が表示されます。このリストとSandboxで実際に変更した内容を突き合わせてください。ただし、コンポーネントの内部的な差分(項目の詳細設定など)までは表示されません。

3.2 比較ツールを活用する

より詳細な差分を確認するには、専用のツールが有効です。以下の表に主なツールを比較します。

ツール 特徴 差分の粒度 難易度
Salesforce Change Set 標準機能、追加したコンポーネント一覧を表示 コンポーネント単位
Workbench 無料ツール、オブジェクトや項目のメタデータを比較可能 項目・設定レベル
VS Code + Salesforce Extension Pack 開発者向け、メタデータをローカルにダウンロードし差分比較 XML要素単位
GitベースのCI/CD(例:GitHub Actions) バージョン管理と自動デプロイ、PRベースの差分確認 ライン単位 高(導入需要)

3.3 手動で差分を確認する際の注意点

特に項目レベルのセキュリティやページレイアウトの変更は見落としやすいため、Sandboxと本番環境でスクリーンショットを比較する、または設定画面を開いて一つずつ確認する方法も有効です。ただし、手動確認は漏れが発生しやすいため、可能であればツールの活用をおすすめします。

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

実際の運用で頻発する失敗パターンを挙げ、対処法を説明します。

4.1 権限セットの紐付け忘れ

新しいカスタムオブジェクトや項目を作成した場合、それらを参照する権限セットやプロファイルへの割り当てを変更セットに含めるのを忘れるケースです。対処法として、変更セットに「権限セット」または「プロファイル」を明示的に追加し、さらに権限セット自体もSandboxから本番へ移行する必要があります。また、デプロイ後に本番環境で権限設定を再確認しましょう。

4.2 項目レベルのセキュリティ(FLS)の差分

カスタム項目を作成しても、項目レベルのセキュリティ設定がデフォルトのまま(全員参照可能)になっていることがあります。本番環境では意図しないユーザーに表示されてしまうため、Sandboxで適切に設定し、その設定も変更セットに含める必要があります。FLSは「項目」の設定の一部としてエクスポートされますが、プロファイルごとの読み取り/編集権限は別途管理されているため注意してください。

4.3 Apexテストカバレッジ不足

新しくApexクラスを追加した場合、そのクラスをカバーするテストクラスのコードカバレッジが75%に達していないとデプロイが失敗します。対処法は、テストクラスを十分に作成し、Sandbox内で「すべてのテストを実行」してカバレッジを確認してから変更セットをアップロードすることです。また、既存のクラスに変更を加えた場合も、全体のカバレッジが低下しないように注意してください。

5. 管理者へ確認すべきポイント

リリース作業を安全に行うために、管理者(または自分が管理者権限を持つ場合)は以下の点を事前に確認してください。

  • デプロイ権限: 変更セットのデプロイを実行するには、「変更セットのアップロード」および「変更セットのデプロイ」権限が必要です。システム管理者プロファイルであれば通常問題ありませんが、カスタムプロファイルの場合は権限設定を確認してください。
  • 本番環境のメンテナンスウィンドウ: デプロイ中は本番環境に負荷がかかる可能性があるため、利用者が少ない時間帯を選びましょう。また、Salesforceのリリースアップデートやメンテナンスと重ならないか確認します。
  • 外部システム連携への影響: 変更によってAPIの挙動や外部システムとの連携が変わる場合、連携先の担当者に事前に通知し、テスト環境で影響を検証してください。
  • バックアップ: デプロイ前に本番環境のメタデータのバックアップを取得しておくことを推奨します。WorkbenchやVS Codeでエクスポートするか、Sandboxから変更セットでエクスポートする方法があります。

6. よくある質問(FAQ)

  1. Q: Sandboxで削除したデータ(レコード)は、変更セットで本番に反映できますか?
    A: いいえ、変更セットはメタデータ(設定情報)のみを移行します。レコードデータの移行にはデータローダーやData Export Serviceを使用してください。
  2. Q: 変更セットのアップロードが「失敗」と表示されるのはなぜですか?
    A: 主な理由は、依存コンポーネントが不足しているか、組織間の接続設定が正しくないことです。Sandboxと本番環境の間でDeployment Connectionが確立されているか確認してください。また、アップロード時に選択したコンポーネントに互換性の問題がないか見直します。
  3. Q: デプロイ中に「Apexテストが失敗しました」とエラーが出ました。どうすればいいですか?
    A: エラーの詳細を確認し、該当するApexクラスやテストクラスを修正します。Sandboxでテストを実行して合格することを確認してから、再度変更セットをアップロード・デプロイしてください。テストクラスが不足している場合は追加します。
  4. Q: 複数のSandboxから同時に変更セットをアップロードできますか?
    A: 技術的には可能ですが、同時にデプロイすると競合が発生する可能性があります。推奨される方法は、一つのSandboxで変更を統合し、単一の変更セットとしてリリースすることです。どうしても複数必要な場合は、順番にデプロイし、それぞれの完了を確認してから次を行ってください。

7. まとめ

Sandboxの変更が本番に反映されない原因の多くは、リリース手順の未実施、変更セットの内容漏れ、権限や依存関係の問題です。正しい手順として、変更セットを作成し、依存関係を漏れなく含めた上でアップロード・デプロイを行うことが基本です。差分確認には標準の変更セット一覧に加え、Workbenchなどのツールを活用するとより確実です。また、デプロイ前には管理者と連携し、権限設定や外部システムへの影響を確認してください。本記事の手順を参考に、安全で確実なリリースを実現しましょう。


ADVERTISEMENT

この記事の監修者
✍️

超解決 第一編集部

疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。

ADVERTISEMENT