Salesforce 開発者サンドボックス：ApexとLWC開発のための完全ガイド

日付:

背景と応用シーン

Salesforce 開発者として、日々の業務で最も頻繁に利用する環境、それが Developer Sandbox (開発者サンドボックス) です。これは、本番環境の安全性を確保しながら、新しい機能の開発、既存機能の修正、あるいは技術的な検証を行うための、隔離されたコピー環境です。Salesforce のエコシステムにおいて、アプリケーションライフサイクル管理 (Application Lifecycle Management, ALM) を支える基盤と言えるでしょう。

Salesforce の開発プロセスでは、本番環境で直接コードを記述したり、設定を変更したりすることは絶対に避けるべきです。たった一つの些細な変更が、ビジネスに甚大な影響を与える可能性があるからです。そこで、Developer Sandbox の出番です。この環境は、本番環境の「メタデータ (Metadata)」—つまり、オブジェクト定義、項目、Apex クラス、Lightning Web Components (LWC)、プロファイル、権限セットといった、組織の設計図—を完全にコピーして作成されます。しかし、取引先や商談といった「データ (Data)」は一切含まれません。

Developer Sandbox の主な応用シーンは多岐にわたります：

1. 新規機能開発と単体テスト

Apex トリガー、バッチ処理、インテグレーション用の REST API、そしてユーザーインターフェースを構成する LWC など、新しい機能をゼロから構築する際の主戦場となります。開発者は他の開発者の作業に影響を与えることなく、独立してコーディングとデバッグに集中できます。また、作成したコードが意図通りに動作するかを確認するための単体テスト (Unit Test) もこの環境で実施します。

2. 不具合修正と検証

本番環境で発生した不具合を調査・修正する際にも利用されます。本番と同じメタデータ構成を持つため、不具合の再現が容易です。修正コードを適用し、デバッグログを詳細に分析することで、安全かつ確実に問題を解決できます。

3. 技術検証 (PoC)

新しい技術や AppExchange アプリケーションを導入する前に、その影響範囲や実現可能性を検証する Proof of Concept (PoC) 環境としても最適です。本番環境に影響を与えることなく、自由に試行錯誤ができます。

4. 新人開発者のトレーニング

新しくチームに加わった開発者が、Salesforce の開発手法や組織独自の開発ルールを学ぶためのトレーニング環境としても非常に有効です。失敗を恐れずにコードを書いたり、さまざまな設定を試したりすることができます。

Developer Sandbox は、Developer Pro、Partial Copy、Full といった他の Sandbox タイプとは明確に区別されます。データストレージが 200MB と最も小さく、本番データを含まない代わりに、1日に1回という高い頻度でリフレッシュ（最新の本番環境のメタデータで上書き）が可能です。この特性が、アジャイルな開発サイクルにおける個々の開発タスクに最適なのです。

原理説明

Developer Sandbox の仕組みを理解する上で最も重要な概念は、メタデータ (Metadata) と データ (Data) の分離です。

メタデータとは、Salesforce 組織の「構造」や「定義」を指します。具体的には以下のようなものが含まれます。

  • オブジェクトと項目: カスタムオブジェクト、カスタム項目、リレーション、入力規則など。
  • ビジネスロジック: Apex クラス、Apex トリガー、フロー、承認プロセスなど。
  • ユーザーインターフェース: Lightning Web Components (LWC)、Aura Components、Visualforce ページ、ページレイアウトなど。
  • セキュリティとアクセス権: プロファイル、権限セット、共有ルールなど。

一方、データとは、これらの構造の中に格納される実際のレコードのことです。例えば、取引先責任者オブジェクトに登録されている「田中太郎」というレコードや、商談オブジェクトにある「〇〇商事様向け案件」といったレコードがこれにあたります。

Developer Sandbox を作成またはリフレッシュすると、Salesforce は本番組織からメタデータのみを抽出し、それを基に新しい組織を構築します。このため、Sandbox は本番と全く同じアプリケーション構成を持ちますが、中身のデータは空っぽの状態から始まります。この「データが空」という点が、開発者にとって重要な意味を持ちます。

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

Developer Sandbox には、データストレージ 200MB、ファイルストレージ 200MB という上限が設けられています。これは、大量のデータを扱うことを想定していないためです。開発や単体テストに必要な少量のテストデータを作成・格納するには十分な容量です。この制約があるからこそ、環境の作成やリフレッシュが迅速に行えるという利点もあります。

リフレッシュ間隔が1日であることも大きな特徴です。本番環境で新しい項目が追加されたり、他の開発者が実装した機能がリリースされたりした場合、翌日にはその最新のメタデータ構成を自身の Sandbox に反映させることができます。これにより、常に最新の本番環境をベースに開発を進めることができ、「本番環境との差分」に起因する手戻りを最小限に抑えられます。

分離による安全性

各開発者に専用の Developer Sandbox を割り当てることで、開発作業は完全に分離（アイソレーション）されます。Aさんが開発中のトリガーが、Bさんが開発中の LWC に予期せぬ影響を与えることはありません。これにより、開発者は自身のタスクに集中でき、マージ時のコンフリクト（競合）も、ソースコード管理システムを通じて管理しやすくなります。この分離された環境こそが、チーム開発の生産性を飛躍的に向上させる鍵なのです。

サンプルコード

Developer Sandbox はコードを実行する「環境」そのものであるため、Sandbox 自体に特化した API というものは存在しません。ここでは、開発者が Developer Sandbox 内で日常的に行うであろう、基本的な Apex クラスと、それに対応するテストクラスの作成例を示します。これは、Salesforce の公式ドキュメントで紹介されている典型的な例です。

Apex クラスの例: HelloWorld.cls

このクラスは、シンプルな "Hello World" という文字列を返す public なメソッドを一つ持ちます。 

// HelloWorld.cls
// このクラスは、基本的なApexの構造を示します。
public class HelloWorld {
    // このメソッドは、呼び出されると 'Hello World' という文字列を返します。
    // 'public static' キーワードにより、このメソッドはインスタンス化せずに
    // 組織内のどこからでも呼び出すことができます。
    public static String hello() {
        return 'Hello World';
    }
}

テストクラスの例: HelloWorldTest.cls

Salesforce では、Apex コードを本番環境にリリースするために、最低75%のカバレッジを持つテストコードを記述することが義務付けられています。以下のテストクラスは、上記の `HelloWorld` クラスをテストします。 

// HelloWorldTest.cls
// このクラスは HelloWorld クラスの hello メソッドをテストします。
@isTest
private class HelloWorldTest {
    // @isTest アノテーションが付いたメソッドがテストメソッドとして実行されます。
    @isTest static void testHelloWorld() {
        // Test.startTest() と Test.stopTest() を使用して、
        // テスト対象のコードを囲むことで、ガバナ制限をリセットし、
        // 非同期処理の完了を待つことができます。
        Test.startTest();

        // テスト対象の HelloWorld.hello() メソッドを呼び出します。
        String result = HelloWorld.hello();
        
        Test.stopTest();

        // System.assertEquals() を使用して、メソッドの実行結果が
        // 期待通りの値 ('Hello World') であることを検証します。
        // これがテストの成功・失敗を判断するアサーションです。
        System.assertEquals('Hello World', result, 'The hello() method should return "Hello World"');
    }
}

開発者は Developer Sandbox 上でこのようなクラスを作成し、Developer Console や Visual Studio Code などの IDE を用いてテストを実行し、コードの品質を確保した上で、ソースコード管理システムにコミットします。

注意事項

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

1. テストデータの管理

前述の通り、Developer Sandbox には本番データが含まれていません。そのため、コードの動作検証に必要なテストデータは、開発者自身が作成する必要があります。手動でレコードを作成することも可能ですが、非効率的であり、再現性も低くなります。

ベストプラクティスは、テストデータファクトリ (Test Data Factory) と呼ばれる Apex クラスを準備することです。これは、指定されたパラメータに基づいてテスト用の sObject レコードを生成するユーティリティクラスです。また、テストクラス内では `@TestSetup` アノテーションを付けたメソッドを利用することで、テストメソッド間で共通して利用するデータを一度だけ作成でき、テストの実行速度を向上させることができます。

2. リフレッシュによる上書き

Sandbox のリフレッシュは、現在 Sandbox 内にあるすべての変更を破棄し、本番環境の最新のメタデータで完全に上書きする、破壊的な操作です。リフレッシュを実行する前には、必ず開発したソースコードや変更した設定内容を Git などのバージョン管理システム (Version Control System, VCS) にコミットし、退避させておく必要があります。Sandbox をソースコードの信頼できる唯一の保管場所（Source of Truth）として扱ってはいけません。

3. メールの送信制御

デフォルトでは、Sandbox からのメール送信は「システムメールのみ」に制限されています。これは、テスト中に誤って実際の顧客にメールを送信してしまう事故を防ぐための安全機能です。メール送信機能（ワークフロールールによるメールアラートや Apex からの送信など）をテストする必要がある場合は、[設定] > [メール] > [送信] にある「アクセスレベル」を「すべてのメール」に変更する必要があります。ただし、変更する際は、テスト用のメールアドレス以外に送信されないよう、コードや設定を十分に確認してください。

4. 外部システム連携

外部システムと連携する機能を開発する場合、Sandbox の連携エンドポイントが本番環境のままである可能性があります。テスト中に本番の外部システムに意図せずデータを送信してしまうことを避けるため、連携先をテスト用のエンドポイント（モックサーバーなど）に切り替えるか、名前付きクレデンシャルで Sandbox 用の URL を設定するなどの対策が必須です。

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

Developer Sandbox は、Salesforce 開発者にとって最も基本的かつ強力なツールです。本番環境の安全性を担保しながら、高品質なアプリケーションを効率的に開発するための隔離された作業スペースを提供します。その特性を正しく理解し、以下のベストプラクティスを実践することで、その価値を最大限に引き出すことができます。

  1. 一人一つの専用 Sandbox:

    原則として、開発者一人ひとりに専用の Developer Sandbox を割り当てます。これにより、作業のコンフリクトを避け、個々の開発者が独立してタスクに集中できる環境を確保します。

  2. バージョン管理システムの徹底活用:

    すべてのソースコードとメタデータ変更は、Git などの VCS で管理します。Sandbox はあくまで一時的な作業環境であり、VCS を信頼できる唯一のソース（Single Source of Truth）とします。定期的なコミットを習慣づけましょう。

  3. 明確な命名規則の導入:

    Sandbox には、`dev_[開発者イニシャル]_[機能名]_[作成日]` のような、目的と所有者が一目でわかる命名規則を適用します。これにより、複数の Sandbox の管理が容易になります。

  4. 戦略的なリフレッシュ:

    新しい大規模な機能開発に着手する前や、本番のメタデータと著しい乖離が生じた場合には、Sandbox をリフレッシュして最新の状態から開発を開始します。これにより、デプロイ時の予期せぬエラーを未然に防ぎます。

  5. テストデータ戦略の確立:

    テストデータファクトリクラスや、CSV ファイルをインポートするためのスクリプトを整備し、誰でも迅速かつ一貫性のあるテストデータを準備できる体制を整えます。

Developer Sandbox は、開発、単体テスト、そして技術検証のための環境です。その役割を正しく認識し、結合テストは Developer Pro や Partial Copy Sandbox、UAT (User Acceptance Testing) は Full Sandbox といったように、開発フェーズに応じて適切な環境へ変更をプロモートしていくことが、Salesforce 開発における成功の鍵となります。

コメント

コメントを投稿