Salesforce Developer Sandbox 徹底解説：管理者と開発者のための究極ガイド

日付:

背景と適用シナリオ

Salesforce プラットフォームの強力な機能の一つに、本番環境 (Production Environment) から隔離された安全な開発・テスト環境を構築できる Sandbox (サンドボックス) があります。Salesforce 管理者として、私たちは本番環境のデータの整合性とシステムの安定性を維持する責任があります。新しい機能の追加や既存のカスタマイズの変更を、本番環境に直接適用することは、ビジネスに深刻な影響を与えるリスクを伴います。ここで Sandbox の役割が極めて重要になります。

Sandbox は、本番組織のMetadata (メタデータ)、つまりオブジェクト、項目、Apex コード、Visualforce ページ、Lightning コンポーネントといった設定情報のコピーです。Salesforce は、用途に応じて複数の種類の Sandbox を提供しています。

  • Developer Sandbox: 開発と基本的なテストに特化した、メタデータのみをコピーする基本的なサンドボックス。
  • Developer Pro Sandbox: Developer Sandbox よりも多くのデータストレージとファイルストレージを持ち、より多くのテストデータを扱うことができます。
  • Partial Copy Sandbox: メタデータに加えて、本番データの一部（サンプリングされたデータ）をコピーします。統合テストやUAT（ユーザー受け入れテスト）の初期段階に適しています。
  • Full Sandbox: メタデータと本番データをすべてコピーします。本番環境とほぼ同一の環境で、パフォーマンステストや最終的なUAT、トレーニングに最適です。

本記事では、これらの中でも最も頻繁に利用される Developer Sandbox に焦点を当てます。Developer Sandbox は、以下のようなシナリオで不可欠なツールとなります。

適用シナリオ

  • 新規 Apex クラスやトリガの開発: 開発者が他の開発者や本番環境に影響を与えることなく、独立してコーディングと単体テストを行う。
  • Lightning Web Component (LWC) の構築: フロントエンドのコンポーネントを安全な環境で開発し、UI の動作確認を行う。
  • フローや入力規則の作成・テスト: 宣言的な自動化ツールやデータ品質ルールを構築し、意図した通りに動作するかを検証する。
  • AppExchange パッケージの評価: 新しい管理パッケージや非管理パッケージをインストールし、自社の組織との互換性や機能性を評価する。
  • 新人管理者や開発者のトレーニング: 新しいチームメンバーが、本番データを壊す心配なく、Salesforce の設定や開発を実践的に学ぶためのトレーニング環境として利用する。

このように、Developer Sandbox は日々の開発・運用業務において、品質と安全性を確保するための第一歩となる重要な環境です。

原理と特徴

Developer Sandbox の基本原理は「本番組織のメタデータの隔離されたコピー」であるということです。このシンプルな原理から、いくつかの重要な特徴が生まれます。

メタデータのコピー

Developer Sandbox を作成またはリフレッシュすると、その時点での本番組織のすべてのメタデータがコピーされます。これには以下のようなものが含まれます。

  • Apex クラス、トリガ、Visualforce ページ
  • Lightning コンポーネント (Aura/LWC)
  • カスタムオブジェクトと標準オブジェクトのカスタマイズ（カスタム項目、ページレイアウト、レコードタイプなど）
  • フロー、ワークフロールール、承認プロセス
  • レポートとダッシュボード
  • ユーザー、プロファイル、権限セット

これにより、開発者は本番と全く同じ設定基盤の上で作業を開始できます。

データはコピーされない

最も重要な特徴の一つは、Developer Sandbox には本番組織のデータ（取引先、取引先責任者、商談など）が一切コピーされないことです。これは、機密情報である顧客データを保護し、ストレージ容量を最小限に抑えるための仕様です。開発やテストに必要なデータは、別途作成またはインポートする必要があります。

ストレージとリフレッシュ間隔

Developer Sandbox には以下の制限があります。

  • データストレージ: 200 MB
  • ファイルストレージ: 200 MB
  • リフレッシュ間隔: 1日に1回

このストレージ容量は、大規模なデータセットを扱うテストには不十分ですが、機能開発や単体テストには十分です。また、1日に1回リフレッシュできるため、本番環境の最新の変更を頻繁に取り込みながら開発を進めることが可能です。

SandboxPostCopy インターフェース

Sandbox の作成またはリフレッシュが完了した直後に、特定の Apex クラスを自動的に実行させる仕組みがあります。これが SandboxPostCopy インターフェースです。これを利用することで、テストデータの自動作成、インテグレーション設定の無効化、ユーザー情報のマスキングなど、リフレッシュ後の手動作業を自動化できます。

Developer Sandbox の作成と管理

Salesforce 管理者として、Sandbox のライフサイクル全体を管理する手順を理解しておくことは必須です。

作成手順

  1. [設定] から、[クイック検索] ボックスに「Sandbox」と入力し、[Sandbox] を選択します。
  2. [新規 Sandbox] ボタンをクリックします。
  3. 名前 (例: dev_newfeature) と説明を入力します。命名規則をチームで統一しておくことが推奨されます。
  4. 作成する Sandbox の種類として [Developer] を選択します。
  5. [次へ] をクリックします。
  6. (任意) Sandbox 作成後に実行する Apex クラスを指定する場合、SandboxPostCopy を実装したクラス名を入力します。
  7. [作成] をクリックします。

作成プロセスが開始され、完了すると組織の管理者にメールで通知が届きます。

リフレッシュ

既存の Sandbox を本番組織の最新のメタデータで上書きするプロセスをリフレッシュと呼びます。新しいプロジェクトを開始する前や、本番の変更と同期を取りたい場合に実施します。

[Sandbox] の設定ページで、リフレッシュしたい Sandbox の横にある [リフレッシュ] リンクをクリックします。リフレッシュが完了すると、古いバージョンの Sandbox は削除キューに入り、新しい Sandbox がアクティベート可能になります。

アクティベーションとログイン

Sandbox の準備が完了すると、アクティベーションメールが届きます。メール内のリンクをクリックしてパスワードを設定し、Sandbox を有効化します。Sandbox へのログインは、本番環境の `login.salesforce.com` ではなく、`test.salesforce.com` を使用します。

また、ユーザーのメールアドレスは、本番環境と区別するために、末尾に Sandbox 名が付加された形式（例: `user@example.com.dev_newfeature`）に変更されます。これにより、Sandbox からの通知メールが誤って顧客に送信されるのを防ぎます。

コードサンプル: SandboxPostCopy の実装

前述の通り、`SandboxPostCopy` インターフェースは Sandbox リフレッシュ後の定型作業を自動化するのに非常に便利です。以下に、Salesforce の公式ドキュメントで提供されているサンプルコードを基に、テスト用の取引先責任者を作成するクラスの実装例を示します。 

/*
 * SandboxPostCopy インターフェースを実装するクラス。
 * このクラスは、Sandbox の作成またはリフレッシュが完了した直後に実行されます。
 * 主な目的は、開発やテストに必要な初期設定やデータ準備を自動化することです。
 */
global class CreateContactTest implements SandboxPostCopy {
    
    /*
     * runApexClass メソッドは、SandboxPostCopy インターフェースで定義されている唯一のメソッドです。
     * Sandbox のリフレッシュプロセスがこのメソッドを呼び出します。
     *
     * @param context SandboxPostCopyContext オブジェクト。組織 ID や Sandbox ID などのコンテキスト情報が含まれます。
     */
    global void runApexClass(SandboxPostCopyContext context) {
        // ここにリフレッシュ後に実行したいロジックを記述します。
        
        // 例: テスト用の取引先を作成する
        Account acct = new Account(Name='Test Account');
        insert acct;
        
        // 例: 作成した取引先に紐づく取引先責任者を作成する
        // これにより、データが空の Developer Sandbox 内で、すぐにテストを開始できます。
        Contact con = new Contact(
            FirstName='Test',
            LastName='Contact',
            AccountId=acct.Id
        );
        insert con;
        
        // 本番環境のエンドポイントを指している Named Credential (指定ログイン情報) を
        // テスト用のエンドポイントに更新するロジックなどもここに追加できます。
        
        // メール到達性を「すべてのメール」に設定するなどの設定変更は Apex からは直接行えないため、
        // 手動での対応、または Salesforce CLI などを利用したスクリプトでの対応が必要です。
        System.debug('Sandbox Post Copy script ran successfully.');
        System.debug('Org ID: ' + context.organizationId());
        System.debug('Sandbox ID: ' + context.sandboxId());
        System.debug('Sandbox Name: ' + context.sandboxName());
    }
}

このクラスを Sandbox 作成時またはリフレッシュ時に指定することで、毎回手動でテストデータを作成する手間を省くことができます。

注意事項

Developer Sandbox を効果的に利用するためには、いくつかの注意点を理解しておく必要があります。

  • データがないことの認識: 最も重要な点です。テストにはデータが必要です。Data Loader を使用して CSV ファイルからデータをインポートする、前述の `SandboxPostCopy` でスクリプトを実行する、または手動でレコードを作成するなどの方法でテストデータを準備する必要があります。
  • メール到達性 (Email Deliverability): デフォルトでは、Sandbox からのメール送信はブロックされています。メール通知や Apex からのメール送信機能をテストする場合は、[設定] > [メール] > [送信] に移動し、[アクセスレベル] を [すべてのメール] に変更する必要があります。
  • インテグレーションのエンドポイント: Sandbox は本番環境のコピーであるため、外部システムとの連携設定（Named Credentials やリモートサイト設定など）も本番と同じものを指しています。テスト中に誤って本番の外部システムにデータを送信しないよう、必ず Sandbox 用のテストエンドポイントに修正してください。
  • 変更の追跡: Developer Sandbox で行った変更は、手動で追跡する必要があります。どのメタデータを変更したかをメモしておくか、より高度な開発チームでは Git などのバージョン管理システムを導入します。変更のデプロイには、Salesforce の標準機能である Change Sets (変更セット) を使用するのが一般的です。
  • ライセンス数: Sandbox の種類と数は、契約している Salesforce のエディションによって決まります。利用可能な Sandbox の数には限りがあるため、不要になった Sandbox は削除し、リソースを有効活用することが重要です。

まとめとベストプラクティス

Developer Sandbox は、Salesforce プラットフォームにおける開発、テスト、トレーニングの基盤となる不可欠なツールです。メタデータを隔離された環境で安全に変更できることで、本番環境の安定性を保ちながら、新しい価値を迅速にビジネスに提供することが可能になります。

最後に、Developer Sandbox を活用するためのベストプラクティスをいくつか紹介します。

  1. 一人一つの Developer Sandbox: 可能な限り、開発者一人ひとりに専用の Developer Sandbox を割り当てます。これにより、他の開発者との作業の競合（コンフリクト）を防ぎ、各自が独立して開発に集中できます。
  2. 定期的なリフレッシュ: 開発を開始する前には、必ず Sandbox をリフレッシュして本番環境の最新のメタデータを取り込みましょう。古い環境で開発を続けると、デプロイ時に予期せぬエラーが発生する原因となります。
  3. 一貫した命名規則: Sandbox には `dev_[プロジェクト名]_[開発者イニシャル]` のような一貫した名前を付け、目的が明確にわかるように管理します。
  4. リフレッシュ後の手作業を文書化・自動化: メール到達性の設定やテストデータのロードなど、リフレッシュ後に必要な手作業をチェックリストとして文書化しましょう。可能な限り `SandboxPostCopy` を活用して自動化することが望ましいです。
  5. 適切な Sandbox を選択する: 開発と単体テストには Developer Sandbox、データを含むテストや統合テストには Developer Pro や Partial Copy Sandbox、本番同様の環境での最終テストには Full Sandbox と、目的に応じて最適な Sandbox を使い分けることが、効率的な開発ライフサイクルを実現する鍵です。

Salesforce 管理者としてこれらの原則とプラクティスを理解し実践することで、組織の Salesforce 環境をより安全かつ効率的に運用管理することができるでしょう。

コメント

コメントを投稿