Salesforce Developer Sandbox 徹底解説：開発者のための実践的活用ガイド

背景と適用シナリオ

こんにちは、Salesforce 開発者の皆さん。日々の開発業務、お疲れ様です。Salesforce プラットフォームでの開発において、私たちの最も身近な相棒と言えるのが Developer Sandbox (開発者サンドボックス) です。これは、本番環境の安全性を確保しながら、新しい機能の構築、バグの修正、そして様々な技術的検証を行うための、隔離された開発環境です。

Salesforce の Application Lifecycle Management (ALM) において、Developer Sandbox は開発サイクルのまさに第一歩に位置します。アイデアがコードに変わり、最初の動作確認が行われる場所、それが Developer Sandbox なのです。例えば、以下のようなシナリオで私たちは Developer Sandbox を活用します。

新規機能の開発

営業部門から「取引先に紐づく商談がすべてクローズされたら、取引先のフェーズを自動で『優良顧客』に更新したい」という要望が来たとします。この要件を満たすために、私たちはまず Developer Sandbox にログインし、Apex Trigger や Flow を作成します。本番データに一切影響を与えることなく、心ゆくまでコーディングと単体テストを繰り返すことができるのです。

バグの修正

ユーザーから「特定のプロファイルでカスタムの Visualforce ページが表示されない」という報告があった場合、私たちは問題の切り分けと修正作業を Developer Sandbox で行います。本番環境のメタデータをコピーしているため、本番とほぼ同じ設定（プロファイル、権限セットなど）の上で、原因を特定し、修正コードを適用して動作を検証できます。

技術検証 (PoC)

新しい技術、例えば Lightning Web Components (LWC) を使った動的な UI の実装や、外部 API との連携ロジックを試したい場合にも Developer Sandbox は最適です。失敗を恐れずに新しいライブラリを試したり、複雑な SOQL クエリのパフォーマンスを検証したりと、イノベーションのための実験場として機能します。

他の Sandbox タイプ、例えば Developer Pro、Partial Copy、Full Sandbox と比較して、Developer Sandbox はメタデータのみをコピーし、データストレージが 200MB と小さい代わりに、1日に1回リフレッシュできるという特徴があります。この手軽さと隔離性が、私たち開発者にとって日々のコーディング作業に最も適した環境たらしめているのです。

原理説明

Developer Sandbox がどのように機能し、なぜ開発に適しているのか、その基本的な仕組みを理解することは重要です。

メタデータのコピー

Developer Sandbox を作成またはリフレッシュすると、その時点での Production (本番環境) のすべてのメタデータがコピーされます。メタデータとは、Apex クラス、LWC バンドル、オブジェクト定義、項目、入力規則、ワークフロールール、プロファイル、権限セットなど、組織の「設計図」にあたるすべての設定情報です。これにより、開発者は本番と全く同じ構成の上で開発を開始できます。

データの非コピーとストレージ制限

最も重要な特徴は、Developer Sandbox には本番のデータ（取引先、商談、ケースなどのレコード）が一切コピーされないという点です。これは意図的な仕様であり、開発中に誤って顧客データにアクセスしたり、変更したりするリスクを完全に排除します。データストレージは 200MB、ファイルストレージも 200MB に制限されています。このため、開発とテストに必要な最小限のテストデータを手動で作成するか、スクリプトで投入する必要があります。この制限があるからこそ、環境の作成やリフレッシュが非常に高速に行えるのです。

独立した組織 ID

各 Developer Sandbox は、本番環境とは異なる、一意の組織 ID を持ちます。これにより、API 連携や認証の観点からも、本番環境とは完全に別の組織として扱われます。開発中のコードが誤って本番の API エンドポイントを呼び出す、といった事故を防ぐことができます。

開発ライフサイクルにおける位置づけ

一般的な開発フローでは、まず各開発者が個別の Developer Sandbox で機能開発と単体テストを行います。完成したコードや設定は、Change Sets (変更セット) や Salesforce CLI などのメタデータ API を通じて、より上位の環境（例えば、複数の開発者の変更を統合してテストする Developer Pro Sandbox や、UAT を行う Partial Copy Sandbox）にデプロイされます。このように、Developer Sandbox は開発の最小単位を支える基盤となっています。1日に1回リフレッシュできるという高い頻度は、開発者が常に最新の本番環境のメタデータを元に作業を開始できることを保証します。

示例代码

Developer Sandbox での典型的な作業は、Apex コードを書き、その動作を保証するためのテストクラスを作成することです。ここでは、取引先 (Account) が挿入されたときに、その取引先名に 'TEST' という文字列が含まれていないかチェックする簡単なトリガと、そのテストクラスを例に挙げます。このコードは Salesforce 公式ドキュメントに記載されている標準的な例です。

トリガの例：MyAccountTrigger

このトリガは、新しい取引先レコードがデータベースに保存される直前 (before insert) に起動します。

trigger MyAccountTrigger on Account (before insert) {
    //
    // This trigger prevents an account from being saved
    // if its name is "TEST".
    // This is a simple trigger, but it shows how you can use Apex
    // to add custom business logic.
    //
    for (Account a : Trigger.new) {
        if (a.Name == 'TEST') {
            a.Name.addError('The account name cannot be TEST.');
        }
    }
}

コードの解説：
・`trigger MyAccountTrigger on Account (before insert)`: Account オブジェクトに対し、レコードが挿入される前にこのトリガを実行することを宣言しています。
・`for (Account a : Trigger.new)`: `Trigger.new` は、トリガを起動させたレコードのリストを保持するコンテキスト変数です。このループで、挿入されようとしている各取引先レコードを処理します。
・`if (a.Name == 'TEST')`: 取引先名が 'TEST' という文字列と完全に一致するかどうかをチェックします。
・`a.Name.addError(...)`: 条件に一致した場合、`addError` メソッドを使って保存処理をブロックし、ユーザーにエラーメッセージを表示します。これにより、不正なデータの作成を防ぎます。

テストクラスの例：TestAccountTrigger

上記のトリガが正しく動作することを検証するためのテストクラスです。Salesforce では、本番環境に Apex コードをデプロイするために、十分なコードカバレッジを持つテストクラスが必須です。

@isTest
private class TestAccountTrigger {
    @isTest static void TestAccountNameCannotBeTest() {
        // Create a list of accounts to test
        List<Account> accounts = new List<Account>{
            new Account(Name='TEST'),
            new Account(Name='My Account')
        };
        
        // Start the test
        Test.startTest();
        
        // Insert the accounts and catch the exception
        Database.SaveResult[] results = Database.insert(accounts, false);
        
        // Stop the test
        Test.stopTest();
        
        // Verify that the first account failed to save
        for (Database.SaveResult sr : results) {
            if (sr.isSuccess()) {
                // This account should have been saved successfully
                System.assertEquals('My Account', accounts[1].Name);
            } else {
                // This account should have failed
                // Get the error message
                Database.Error error = sr.getErrors()[0];
                System.assert(error.getMessage().contains('The account name cannot be TEST.'));
            }
        }
    }
}

コードの解説：
・`@isTest`： このアノテーションは、このクラスがテストコードであり、組織のコードサイズ制限にはカウントされないことを示します。
・`Test.startTest()` と `Test.stopTest()`： これらはテストの実行コンテキストを区切るためのメソッドです。このブロック内で実行されたコードは、新しいガバナ制限のセットを取得するため、テストの精度が向上します。
・`Database.insert(accounts, false)`： 2番目のパラメータを `false` に設定することで、一部のレコードでエラーが発生しても、処理全体が停止しないようにします（All or None オプションの無効化）。これにより、成功したケースと失敗したケースの両方を1回の DML 操作でテストできます。
・`Database.SaveResult[] results`： `Database.insert` の結果を `SaveResult` オブジェクトのリストで受け取ります。各 `SaveResult` には、対応するレコードの保存が成功したかどうかの情報と、エラーメッセージが含まれています。
・`System.assert(...)` と `System.assertEquals(...)`： これらはアサーションメソッドです。テストの結果が期待通りであるか（例えば、エラーメッセージが正しいか、成功したレコードの名前が変更されていないか）を検証します。アサーションが失敗すると、テストも失敗します。

注意事項

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

データの準備と管理

前述の通り、Developer Sandbox にはデータがありません。したがって、テストデータの作成は開発者の責任です。テストクラス内では `@TestSetup` アノテーションを使ってテストデータを一度に作成し、各テストメソッドで再利用するのがベストプラクティスです。手動テストのためには、データローダや Apex スクリプトを使って、少量のリアルなテストデータを準備する必要があります。

メール送信の制限

デフォルトでは、Sandbox からのメール送信はブロックされるか、メールを送信したユーザー（通常は開発者自身）のメールアドレスにリダイレクトされるように設定されています。これは、テスト中に誤って実際の顧客にメールを送信してしまう事故を防ぐためです。設定メニューの Deliverability (到逹性) でこの設定を変更できますが、本番の顧客にメールが届かないよう、細心の注意が必要です。

リフレッシュの影響

Sandbox をリフレッシュすると、その Sandbox は完全に削除され、本番環境の最新のメタデータを使って新しく作り直されます。つまり、リフレッシュ前に Sandbox 内で行ったコーディングや設定、作成したテストデータはすべて失われます。リフレッシュを行う前には、必ず進行中の作業を Git などのソースコード管理システムにコミットするか、ローカル環境にバックアップしてください。

外部システム連携 (Integrations)

開発中のコードが外部システムと連携する場合、Sandbox 内の連携設定（エンドポイント URL など）が本番環境のものを向いていないか確認が必要です。Named Credentials (指定ログイン情報) を使うことで、環境ごとに異なるエンドポイントをコードの変更なしに管理できるため、このようなリスクを大幅に低減できます。連携先の外部システムにも、テスト用のエンドポイント（サンドボックス環境）を用意してもらうのが理想です。

API 制限とガバナ制限

Developer Sandbox にも、本番環境と同様のガバナ制限（SOQL クエリの発行回数、CPU 時間など）が適用されます。コードがこれらの制限に抵触しないか、テストを通じて常に意識する必要があります。API コール数の制限も本番とは別枠で存在しますが、無尽蔵ではないため、大規模なデータロードや頻繁な API 連携テストには注意が必要です。

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

Developer Sandbox は、私たち Salesforce 開発者にとって、日々の業務に不可欠なツールです。その特性と制約を正しく理解し、ベストプラクティスに従うことで、開発効率と品質を最大限に高めることができます。

まとめ：
・Developer Sandbox は、本番のメタデータをコピーした、データのない隔離された開発環境です。
・高速なリフレッシュ（1日1回）が可能で、個々の開発者が独立して作業するのに最適です。
・ストレージ制限（200MB）があるため、テストデータの管理戦略が重要になります。
・メール送信や外部連携など、本番環境に影響を与えないための安全装置が組み込まれています。

ベストプラクティス：

1. 開発者ごとに専用の Sandbox を使う： 複数の開発者が1つの Developer Sandbox を共有すると、互いの変更が衝突し、作業効率が低下します。可能であれば、開発者一人ひとり、あるいは担当する機能ごとに専用の Sandbox を用意しましょう。

2. ソースコード管理システム (VCS) を利用する： Sandbox はあくまで一時的な作業場所に過ぎません。コードやメタデータの「信頼できる唯一の情報源 (Single Source of Truth)」は、Git などのバージョン管理システムであるべきです。作業の区切りごとに変更をコミットする習慣をつけましょう。

3. Salesforce CLI を活用する： Salesforce CLI を使うことで、ローカルの開発環境 (VS Codeなど) と Sandbox 間のメタデータのデプロイや取得を迅速に行えます。これにより、開発のイテレーションが高速化します。

4. 定期的なリフレッシュを計画する： 本番環境のメタデータは日々変更されていきます。開発中の環境が古くならないよう、定期的に Sandbox をリフレッシュし、常に最新の本番構成に近い状態で開発を進めることが推奨されます。

5. Sandbox の種類を使い分ける： Developer Sandbox は単体開発には最適ですが、より多くのデータが必要な結合テストやパフォーマンステストには不向きです。目的に応じて、Developer Pro や Partial Copy Sandbox など、適切な種類の Sandbox を選択しましょう。

この記事が、皆さんの Developer Sandbox の活用の一助となれば幸いです。安全で効率的な開発環境を構築し、素晴らしい Salesforce アプリケーションを共に作り上げていきましょう。

にゃんこのSalesforce日記

このブログを検索