Salesforce Sandboxから本番環境へ安全にリリースする方法｜手順と運用チェックリスト

2026.03.26

#Salesforce #Sandbox #リリース

Salesforceに限らず、本番環境へのリリースは、「本番に影響を出さず、手戻りなく、監査にも耐える」ことが目標です。
リリース運用を作るには、手順そのものだけでなく事前準備、検証、バックアウト（戻し）までを一連で設計するのが近道です。

本記事では、Sandboxで作った変更を本番へ安全に反映するために、手順をまとめ、リリース前後に必要なポイントをチェックリストにまとめました。

前提：Sandboxの種類と役割

Sandboxは種類によって用途が異なります。
まずはSandboxの種類と役割を整理していきましょう。

Sandbox名	特徴	用途
Developer Sandbox	本番組織の設定 (メタデータ) のコピーが含まれる。	隔離された環境での開発とテストを目的としている。
Developer Pro Sandbox	Developer Sandbox より大きなデータセットを保持できる。	隔離された環境での開発とテストを目的としている。 より多くの開発および品質保証作業の処理や結合テストに使用される。
Partial Copy Sandbox	本番組織の設定 (メタデータ) のコピー、および本番組織のデータのサンプルが含まれる。	テスト環境として使用されることを目的としている。 ユーザー受け入れテストで使用される。
Full Sandbox	すべてのデータ (オブジェクトレコード、添付ファイルなど) とメタデータを含む、本番組織の複製。	テスト環境として使用されることを目的としている。 開発には不向き。 パフォーマンステスト、負荷テストで使用される。

(参照公式ヘルプページ：Sandbox の種別およびテンプレート)

「開発→結合→UAT→本番」のどこをどのSandboxで担うかを決め、検証の抜け漏れが出ない導線を作りましょう。

　関連記事もぜひ参考にしてみてください
　　　　◆SalesforceにおけるSandboxとは？使い方や種類などをわかりやすく解説

自分の組織に合うリリース方法の選択

次にリリース方法について紹介します。
リリース方法はいくつかありますが、現場ではどの方法で移送するかではなく、変更規模や体制に応じて複数手法を組み合わせるのが一般的です。

(DevOps Centerリリース管理画面：DevOps Centerを使い始める)

• 変更セット：Sandoboxで作成した設定や開発内容を、本番環境へ反映することができます。画面操作のため使用しやすいです。
  変更内容が増えるほど管理が複雑になりがちであるため、小規模な改修や単発の設定変更に向いています。
• DevOps Center：変更管理・リリース管理のためのツールです。
  従来の変更セットよりも、チームでの変更管理をしやすくすることを目的としています。Gitなどのソース管理と連携しながら、変更内容を整理する必要があります。
  変更セットでは管理しきれなくなってきたチーム開発に適した選択肢といえます。
• Salesforce CLI（SFDX）/ソース駆動：コマンドラインを使ってSalesforceの開発やリリースを行う方法です。
  設定情報をファイルとして管理し、ソースコードを中心に開発を進める運用に向いています。
  自動テストとも相性が良く、手作業を減らしながら安定したリリースを実現しやすいです。
  その反面、操作には一定の知識が必要なため、初心者にとっては少しハードルが高く感じられる場合もあります。
• Unlocked Package：メタデータを機能ごとにまとめて管理・配布するための方法です。
  単に変更を移すだけでなく、機能を「まとまり」として扱える点が大きな特徴です。開発内容やメタデータをパッケージとして管理できるため、必要な単位でテストやリリースを行いやすく、複数の環境に対して同じ内容を安定して展開しやすくなります。

　関連記事もぜひ参考にしてみてください
　　　　◆Salesforceのリリースをもっとスムーズに：VisualStudioCode + CLIによる実践的アプローチ

手順：Sandboxから本番へ安全にリリースする7ステップ

それでは、Sandboxから本番へ安全にリリースするための手順を紹介していきます。

ステップ1：リリース範囲を定義する

まずは、リリースする範囲を定義します。
ここでは項目やコンポーネントの依存関係を考慮する必要があります。

• 何を本番へ出すか（オブジェクト/項目、フロー、権限、Apex、Lightningページ等）をリスト化
• 依存関係（参照先項目、割り当て先の権限セット、フローが参照する項目など）も同時に洗い出し
• 依存コンポーネントを必ず含める（不足すると本番側で失敗しやすい）。

ステップ2：開発Sandboxで変更を完了し、移送単位を揃える

移行ツールに応じて、リリース単位を揃えます。

(DevOps Center Work Item管理画面：DevOps Centerを使い始める)

• 変更セット 　　 → Outbound Change Setを作る
• DevOps Center　→　Work Item単位で変更を集約（後で束ねてPromoteしやすい）
• CLI/Unlocked Package →　リポジトリに差分が揃った状態で「いつでも同じ成果物が作れる」形にしておく

ステップ3：結合/UAT環境で“本番想定”のシナリオテストを回す

本番環境を想定したSandbox環境（Partial Copy/Fullなど）でテストします。
特に以下はUATで潰すほど、本番障害が減ります。

• 既存業務（入力→自動化→承認→レポート）の回帰
• 権限不足によるエラー（項目が見えない、編集できない等）
• 既存フロー/入力規則への影響

ステップ4：本番デプロイ前に“検証デプロイ（Validate）”を実施する

本番環境にリリースする直前に必ず、検証デプロイ（Validate）を実施するようにしましょう。
検証デプロイを実施することで失敗要因（依存不足、Apexテスト、差分衝突）を先に潰すことができ、本番環境への安全なリリースが可能となります。

• 変更セット：Inbound Change Setで検証してからDeploy
• DevOps Center：Validate-Only（検証のみ）でパイプライン上の検証を先に通す
• CLI：project deploy validateで検証→問題なければquick deploy

Salesforce CLIで「検証→クイックデプロイ」を行う例

下記のように「project deploy validate」を使用することでCLIでリリースの検証を行うことができます。

検証が問題なく完了したら、「project deploy quick」でリリースを実行しましょう。

(参照 公式Trailhead：変更をテストしてリリースする)

ステップ5：本番へデプロイ（反映）する

検証を実施し、問題がないことを確認できたら、いよいよ本番環境へリリースします。

• 変更セット：Inbound Change SetをDeploy
• DevOps Center：パイプラインのステージへPromote（必要に応じて束ねる）
• CLI/Unlocked Package：検証が通った成果物を本番へ反映（validate→quick deployなどで本番作業時間を圧縮）

ステップ6：デプロイ後の動作確認と監視

デプロイ後は、リリースした内容が問題なく反映されているか、下記ポイントを確認しましょう。

(設定_デプロイ状況画面：デプロイメントについて)

• 主要画面：対象オブジェクトのレイアウト、Lightningページ、必須入力
• 自動化：フロー、承認、入力規則の想定分岐
• 権限：対象ユーザーでログインして「見える/作れる/実行できる」
• デプロイ状況：Deploymentsの監視やログ確認

ステップ7：バックアウト（戻し）を手順として用意しておく

(設定_デプロイ状況画面(デプロイ失敗)：メタデータ API のデプロイメントを詳しく見る)

デプロイ後に、問題や修正箇所が発覚し、バックアウトが必要になる場合があります。
そこで、下記観点でのバックアウト手順をあらかじめ用意しておくと、スムーズにバックアウトを実施することができます。

• 変更前の状態（設定値・メタデータ）を控える
• 戻し手順（無効化、前バージョン再デプロイ、設定値復元）をドキュメント化
• 影響が大きい変更は、事前に段階リリース（機能の一部を無効でリリースする等）も検討

運用チェックリスト

最後に、リリースをスムーズに実施できるように運用上必要なポイントをチェックリストで押さえておきましょう。

リリース前（計画）

まずは「何を・誰が・どの順番で進めるか」を明確にし、当日の判断ミスや作業漏れを防ぐことが大切です。

• リリース対象と依存関係が一覧化されている（権限・自動化・参照項目含む）
• どのSandboxでどのテストを実施するか固定されている
• 本番デプロイ手順（誰が、いつ、どのツールで）が決まっている

リリース前（検証）

本番反映の前に検証環境で問題を洗い出しておくことで、障害発生のリスクを大きく下げられます。

• 検証デプロイが成功している（変更セット/DevOps Center/CLIのいずれでも）
Apexテスト方針（RunLocalTests等）を前提に、失敗時の切り分け担当が決まっている

リリース当日（実施）

当日は「反映すること」だけでなく、関係者への周知と異常の早期検知までを含めて進行管理することが重要です。

• 影響範囲ユーザーへ周知（時間帯、影響、問い合わせ窓口）
• デプロイ中の監視（Deployments画面/ログ）

リリース後（確認）

リリース完了後は、画面上の成功表示だけで終わらせず、実際の業務影響がないかを確認しましょう。

• 主要業務シナリオの回帰が完了
• 想定外エラーが出た場合のバックアウト判断基準が共有されている

まとめ

Sandboxから本番へのリリースは、「どのツールを選ぶか」よりも、
①Sandboxの役割固定 → ②検証で安全を確認 → ③本番反映後の最小チェック → ④戻り手順の用意まですることが重要です。

日々のリリースを属人化させず、再現性のある手順として整えていくことが、Salesforce運用の安心感と継続的な改善につながります。

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら