Salesforce Developer Sandbox 徹底解説：開発者向けガイド

背景と応用シーン

Salesforce 開発者として、私たちは常に新しい機能の構築、既存プロセスの改善、そしてビジネス要件の変化への迅速な対応を求められています。しかし、これらの変更を直接 Production Environment (本番環境) で行うことは、ビジネスの中断、データ破損、セキュリティリスクといった重大な問題を引き起こす可能性があるため、決して許されることではありません。ここで不可欠となるのが、安全で隔離された開発環境、すなわち Sandbox (サンドボックス) です。

Salesforce のエコシステムでは、Application Lifecycle Management (ALM) (アプリケーションライフサイクル管理) という、アプリケーションの企画、開発、テスト、展開、保守に至るまでの全工程を管理するフレームワークが中心的な役割を果たします。この ALM の出発点となるのが、今回テーマとする Developer Sandbox (開発者 Sandbox) です。Developer Sandbox は、開発者が Apex クラス、Lightning Web Components (LWC)、Visualforce ページ、フロー、オブジェクト設定などの Metadata (メタデータ)、つまり「データに関するデータ」や設定情報を、本番環境に影響を与えることなく自由に作成、変更、テストするために設計された個人用の作業スペースです。

具体的な応用シーンとしては、以下のようなものが挙げられます。

新機能のプロトタイピング： 新しい Apex トリガーや複雑な承認プロセスのロジックを、実際のデータを使わずに試作・検証する。
バグ修正： 本番環境で発生した不具合を再現し、原因を特定して修正コードを開発・テストする。
継続的インテグレーション (CI/CD)： Source Control (ソース管理) システム (例: Git) と連携し、変更をコミットする前に自動テストを実行する開発サイクルの基盤として利用する。
技術検証： Salesforce の新しいリリースで提供された機能を、既存のカスタマイズに影響を与えずに試す。

このように、Developer Sandbox は Salesforce 開発者にとって日常的な業務に欠かせない、いわば「デジタルな作業台」であり、品質の高いアプリケーションを安定して提供するための第一歩なのです。

原理説明

Developer Sandbox は、Salesforce が提供する複数の Sandbox タイプの中で最も基本的かつ利用頻度の高いものです。その原理と特徴を理解することは、効果的な開発戦略を立てる上で非常に重要です。

Developer Sandbox の最も重要な特徴は、「メタデータのみをコピーする」という点です。Sandbox 作成時または更新時に、ソースとなる本番環境から Apex クラス、オブジェクト定義、項目、ページレイアウト、プロファイルといった設定情報（メタデータ）はすべてコピーされますが、取引先、商談、ケースといったレコードデータは一切コピーされません。これにより、軽量で迅速に作成・更新できるというメリットが生まれます。

他の Sandbox タイプとの比較を通じて、Developer Sandbox の位置づけを明確にしましょう。

Sandbox タイプの主な違い

Developer Sandbox:
- 目的： 開発と単体テスト。
- コピー対象： メタデータのみ。
- データストレージ： 200MB。
- ファイルストレージ： 200MB。
- 更新間隔： 1日1回。
- 特徴： 最も手軽で、開発者個人の作業環境として最適。
Developer Pro Sandbox:
- 目的： より大規模な開発、結合テスト、QA。
- コピー対象： メタデータのみ。
- データストレージ： 1GB。
- ファイルストレージ： 1GB。
- 更新間隔： 1日1回。
- 特徴： Developer Sandbox よりも多くのテストデータをロードして、より複雑なテストシナリオを実行するのに適している。
Partial Copy Sandbox:
- 目的： ユーザ受け入れテスト (UAT)、インテグレーションテスト。
- コピー対象： メタデータと、Sandbox テンプレートで定義された本番データの一部（サンプル）。
- データストレージ： 5GB。
- ファイルストレージ： 本番組織と同量。
- 更新間隔： 5日ごと。
- 特徴： 本番に近いデータ構成でテストができるため、ユーザビリティの確認や現実的なデータ量でのテストに適している。
Full Sandbox:
- 目的： パフォーマンステスト、ステージング、本番リリース前の最終検証。
- コピー対象： メタデータと本番データのすべて。
- データストレージ： 本番組織と同量。
- ファイルストレージ： 本番組織と同量。
- 更新間隔： 29日ごと。
- 特徴： 本番環境の完全なレプリカ。大規模なデータ移行のテストや、負荷テストに不可欠。

この比較からもわかるように、Developer Sandbox は「隔離」「スピード」「手軽さ」を重視した環境です。開発者はこの空の環境でコードを作成し、単体テストをパスするために必要なテストデータは手動またはスクリプトで作成します。開発が完了したコードは、Salesforce DX (SFDX) などのツールを使ってソース管理システムにコミットされ、その後、他の Sandbox (Developer Pro や Partial Copy) にデプロイされて、さらなるテストフェーズへと進んでいきます。

示例代码

Developer Sandbox 自体はコードを持ちませんが、開発者がその中で行う典型的な作業として、メタデータの取得と Apex の単体テストがあります。ここでは、それらの作業に関連するコード例を Salesforce 公式ドキュメントに基づいて紹介します。

1. メタデータ取得のための package.xml

Salesforce DX (SFDX) や Ant 移行ツールを使用して Sandbox からメタデータを取得する際、どのコンポーネントを取得するかを定義するのが `package.xml` ファイルです。これは開発作業の基本となります。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <!-- Apexクラスをすべて取得 -->
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    <!-- Apexトリガーをすべて取得 -->
    <types>
        <members>*</members>
        <name>ApexTrigger</name>
    </types>
    <!-- 特定のカスタムオブジェクトを取得 -->
    <types>
        <members>Invoice__c</members>
        <members>Line_Item__c</members>
        <name>CustomObject</name>
    </types>
    <!-- Lightning Web Component をすべて取得 -->
    <types>
        <members>*</members>
        <name>LightningComponentBundle</name>
    </types>
    <!-- バージョンはプロジェクトのAPIバージョンに合わせる -->
    <version>59.0</version>
</Package>

注釈：この XML ファイルは、`<types>` タグでコンポーネントの種別（`<name>`）と、その種別に含まれる具体的なコンポーネント名（`<members>`）を指定します。`*` はワイルドカードで、その種別のすべてのコンポーネントを対象とすることを意味します。このファイルを元に SFDX コマンド `sf project retrieve start` を実行すると、指定したメタデータが Sandbox からローカル環境にダウンロードされます。

2. Apex 単体テストクラス

Developer Sandbox で作成した Apex コードは、本番環境にデプロイする前に必ずテストクラスによって検証される必要があります。以下は、簡単な温度変換を行うユーティリティクラスとそのテストクラスの例です。

対象の Apex クラス：TemperatureConverter.cls

public class TemperatureConverter {
    // 華氏を摂氏に変換するメソッド
    public static Decimal FahrenheitToCelsius(Decimal fahrenheit) {
        Decimal celsius = (fahrenheit - 32) * 5/9;
        // 小数点第2位で四捨五入
        return celsius.setScale(2);
    }
}

テストクラス：TemperatureConverterTest.cls

@isTest
private class TemperatureConverterTest {
    // テストメソッドは @isTest アノテーションを付与する
    @isTest static void testFahrenheitToCelsius() {
        // テストの準備：テストデータや変数を設定
        Decimal fahrenheit = 212;
        Decimal expectedCelsius = 100;
        Decimal actualCelsius;
        
        // テストの実行：ガバナ制限の新しいセットでテストを実行
        Test.startTest();
        actualCelsius = TemperatureConverter.FahrenheitToCelsius(fahrenheit);
        Test.stopTest();
        
        // 結果の検証：期待値と実際の結果が一致するかを確認
        System.assertEquals(expectedCelsius, actualCelsius, 'The conversion to Celsius was not correct.');
    }

    @isTest static void testFreezingPoint() {
        Decimal fahrenheit = 32;
        Decimal expectedCelsius = 0;
        Decimal actualCelsius;

        Test.startTest();
        actualCelsius = TemperatureConverter.FahrenheitToCelsius(fahrenheit);
        Test.stopTest();

        System.assertEquals(expectedCelsius, actualCelsius, 'The freezing point conversion is incorrect.');
    }
}

注釈：テストクラスは `@isTest` アノテーションで定義されます。`Test.startTest()` と `Test.stopTest()` のペアは、テスト対象のコードに専用のガバナ制限セットを適用するために使用されます。`System.assertEquals(expected, actual, message)` は、期待される結果と実際の結果を比較し、異なっていればテストを失敗させ、指定したメッセージを出力するアサーションメソッドです。これらのテストを Developer Sandbox で実行し、すべてのテストがパスすることを確認してから、次の環境へのデプロイを進めます。

注意事項

Developer Sandbox は非常に便利なツールですが、その特性を理解せずに使用すると、予期せぬ問題に直面することがあります。以下に開発者が特に注意すべき点を挙げます。

データとストレージの制限

前述の通り、Developer Sandbox には本番データが含まれていません。そのため、トリガーやフローの動作確認には、テストデータを手動で作成するか、データロードツール（Data Loader）、または Apex テスト用の `@TestSetup` メソッドを使用して準備する必要があります。また、データとファイルストレージがそれぞれ 200MB と非常に小さいため、大量のテストデータやファイルを扱う開発には向いていません。必要であれば Developer Pro Sandbox の利用を検討してください。

更新間隔とタイミング

Developer Sandbox は1日に1回更新（リフレッシュ）できます。更新を行うと、Sandbox 内のすべての変更は破棄され、ソースとなる本番環境の最新のメタデータが再度コピーされます。開発の途中で誤って更新してしまうと、すべての作業が失われるため注意が必要です。ソース管理システムを導入し、変更を頻繁にコミットする習慣がこのようなリスクを軽減します。

メール送信とインテグレーション

セキュリティ上の理由から、新規に作成または更新された Sandbox のメール送信機能は、デフォルトで「システムメールのみ」に設定されています。これは、Salesforce システムからの通知（パスワードリセットなど）のみが許可され、Apex やフローから送信されるメールはブロックされることを意味します。メール送信機能をテストする場合は、設定画面から「すべてのメール」に変更する必要があります。また、外部システムとの連携（インテグレーション）がある場合、Sandbox 内のエンドポイント設定は本番環境のものを引き継いでいる可能性があります。テスト中に誤って本番の外部システムにデータを送信しないよう、必ず Sandbox 用のテストエンドポイントに修正してください。

ユーザー情報とアクセス

Sandbox を作成または更新すると、本番環境のユーザー情報がコピーされますが、意図しないメール送信を防ぐため、すべてのユーザーのメールアドレスの末尾に `.invalid` が自動的に付加されます（例：`developer@example.com` → `developer@example.com.invalid`）。開発者が Sandbox にログインするためには、システム管理者が手動でメールアドレスを修正し、パスワードをリセットする必要があります。

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

Developer Sandbox は、Salesforce 開発の基盤となる重要な環境です。その特性を最大限に活かし、効率的で安全な開発プロセスを確立するために、以下のベストプラクティスを推奨します。

一人一つの Sandbox を原則とする: 複数の開発者が一つの Developer Sandbox を共有すると、互いの変更が衝突し、作業効率が著しく低下します。「一人一つの開発環境」を徹底することで、各開発者は独立して作業に集中できます。
ソース管理を真実のソースとする (Source of Truth): Sandbox はあくまで一時的な作業場所に過ぎません。開発したコードや変更したメタデータは、必ず Git などのソース管理システムにコミットしてください。これにより、変更履歴の追跡、チームでのコードレビュー、CI/CD パイプラインとの連携が可能になります。
Salesforce DX (SFDX) を活用する: SFDX は、モダンな開発ワークフローをサポートする強力なツールセットです。スクラッチ組織（Scratch Orgs）や Developer Sandbox と連携し、ソース駆動型の開発、モジュール化、自動化を推進します。
テストデータの作成を自動化する: Apex の `@TestSetup` アノテーションや、SFDX のデータ生成コマンドを活用して、テストデータの作成プロセスを自動化しましょう。これにより、テストの再現性が高まり、開発効率が向上します。
ハードコードを避ける: コード内に組織IDや特定のURLを直接記述する（ハードコードする）と、Sandbox から本番環境へのデプロイ時に問題が発生します。カスタムメタデータ型、カスタム設定、カスタム表示ラベルなどを活用し、環境に依存しない柔軟なコードを記述してください。
適切な Sandbox を選択する: すべての作業を Developer Sandbox で行う必要はありません。複数の開発者による変更を統合する「結合テスト」には Developer Pro Sandbox、本番に近いデータ量でテストする「UAT」には Partial Copy Sandbox と、開発フェーズに応じて適切な Sandbox を使い分けることが、プロジェクト全体の成功に繋がります。

Developer Sandbox を正しく理解し、これらのベストプラクティスを実践することで、あなたは Salesforce 開発者として、より高品質で信頼性の高いソリューションを迅速に提供できるようになるでしょう。

にゃんこのSalesforce日記

このブログを検索