Sandbox 環境 (テスト環境)

Sandbox は、本番組織と分離された「テスト用環境」 。新機能の試験・パッケージアップグレード検証・カスタマイズの実験 — 本番に影響を与えずに行うために必須の環境です。

Sandbox とは

Salesforce の Sandbox は、本番組織の データやメタデータをコピーしたコピー組織 です。

• 本番と完全に独立 (本番への影響なし)
• 独立した URL (https://[企業名]--sandboxname.sandbox.lightning.force.com)
• 独立したログインアカウント (本番と同じユーザー ID + .sandboxname 追加)
• ライセンスは Sandbox 種類に応じて含まれる

Sandbox の 4 種類

ブリッジ葬儀の運用では、Developer Pro または Partial Copy が一般的。Full Sandbox は容量が大きく、エンタープライズ向け契約が必要。

Sandbox の作成

Setup → 環境 → Sandbox → 新規 Sandbox

1. 名前 (英数字、本番ドメインに追加される)
2. 種類 を選択
3. PostCopy スクリプト (任意): 作成後に実行するスクリプト
4. 作成 → 数分〜数時間で完了

PostCopy: BridgeSandboxPostCopy

ブリッジ葬儀パッケージには BridgeSandboxPostCopy という Apex クラスが含まれており、Sandbox 作成 / リフレッシュ時に 初期マスタが自動再投入 されます。

これにより、Sandbox を作るたびに手動で初期データを再入力する必要がなくなります。

Sandbox にログイン

Sandbox のログイン URL は 本番と別 :

https://test.salesforce.com

(本番は https://login.salesforce.com)

ユーザー名は 本番ユーザー名 + .sandboxname が付きます。

例:

• 本番: user@example.com
• Sandbox: user@example.com.devsbx1

本番と同じパスワードでログイン可能 (作成直後)。後でパスワードを変更しても本番には影響しません。

Sandbox の典型的な用途

1. パッケージアップグレードの検証

• 新バージョンを Sandbox に先にインストール
• 主要機能のテスト
• カスタマイズへの影響確認
• 問題なければ本番に適用

2. カスタマイズ開発

• 新しいフロー / Apex / Lightning ページの試作
• 業務ロジックの検証
• 後で本番にデプロイ

3. データ移行のリハーサル

• データインポートを本番でやる前に Sandbox で試行
• 重複・形式不一致の早期発見

4. ユーザー受け入れテスト (UAT)

• 業務ユーザーに Sandbox 上で操作してもらう
• フィードバックを反映 → 本番適用

5. トレーニング環境

• 新規入社者の Salesforce 操作練習に
• 本番データを触らないので安全

本番→ Sandbox のデプロイ手順

カスタマイズを本番に反映する流れ:

1. Sandbox でカスタマイズ作成
2. Sandbox でテスト
3. Change Set (変更セット) を Sandbox から本番へアップロード
4. 本番で「受信した変更セット」を確認 → デプロイ実行
5. 本番でテスト

Change Set (変更セット)

Setup → 環境 → 変更セット → 送信変更セット

メタデータをまとめて送信できる仕組み。一括デプロイに便利。

Metadata API / SFDX

より高度な運用では、コマンドラインツール (sf project deploy) や Metadata API を使ったデプロイも可能。CI/CD 化することも。

Sandbox リフレッシュ

Sandbox のデータは時間と共に古くなります。リフレッシュ で本番の最新状態に上書きできます。

注意点

• リフレッシュすると Sandbox 内のカスタマイズ・テストデータがすべて消える
• Developer Pro は最低 1 日に 1 回リフレッシュ可、Full は 29 日に 1 回
• リフレッシュ後に PostCopy が再実行 されるため、初期マスタは自動復元

リフレッシュ前にやること

• Sandbox 内の作業ログをエクスポート
• 進行中の Change Set はバックアップ
• メンバーへ事前通知

Sandbox の制約

• ライセンス: 一部の標準ライセンスが Sandbox では使えない場合あり
• メール送信: Sandbox からは標準でメール送信が制限 (テスト用フィルタ)
• 外部システム連携: 本番と違う API エンドポイントを指定する必要あり
• データ容量: Full でも本番より小さい場合あり

Sandbox 環境のベストプラクティス

命名規則

複数の Sandbox を用途別に運用すると整理しやすい。

定期的なリフレッシュ

• Developer Pro: 月 1 回程度
• Partial Copy: 月 1 回 (リフレッシュ間隔 5 日)
• Full: 重要リリース前 (リフレッシュ間隔 29 日)

本番との切り分け確認

ログイン後、必ず以下をチェック:

• URL に sandbox または --sandbox名 が含まれている
• 画面右上に Sandbox 名のリボン表示
• 画面の見た目 (Sandbox は赤系のテーマがデフォルト)

こんなときは

Sandbox にログインできない

• URL: https://test.salesforce.com か確認
• ユーザー名末尾の .sandboxname を確認
• パスワード: 作成直後は本番と同じ、変更後は Sandbox 個別

初期マスタが入っていない

• BridgeSandboxPostCopy が走ったか確認 (Setup → Apex ジョブ)
• 失敗していたら手動で初期化スクリプトを実行

Sandbox の容量がいっぱい

• 古いデータを削除 (バッチ削除可能)
• 不要な Sandbox は削除
• 上位の Sandbox 種類を購入

開発作業を本番にデプロイしたい

• Change Set または SFDX で送信
• 本番でテスト → 問題なければ承認

Sandbox を本番と勘違いして編集してしまった

• 画面右上の Sandbox 名表示で確認する習慣
• ブラウザの拡張機能で本番 / Sandbox を視覚的に区別 (Salesforce Inspector 等)
• 重要操作前は URL バーを確認

次に進む

• データインポート — Sandbox でのデータ移行リハーサル
• リリースとバージョンアップ — Sandbox 検証手順
• 画面のカスタマイズ — Sandbox でレイアウト試行

📅 最終更新日: 2026-06-16