Partial Copy Sandbox 完全攻略:Salesforce 開発者が効率的な開発とテストを実現するためのガイド

概要とビジネスシーン

Partial Copy Sandbox(部分コピーサンドボックス)は、本番環境のメタデータと、選択されたオブジェクトのデータの一部をコピーして作成されるサンドボックスです。これにより、開発者やテスターは、本番環境に近いリアルなデータセットを基に、より効率的かつ安全に開発、テスト、およびトレーニングを行うことが可能になります。Full Sandbox(フルサンドボックス)と比較してリフレッシュ時間が短く、Developer Sandbox(開発者サンドボックス)では不足する本番データサブセットを提供するため、コストと効率のバランスに優れた選択肢となります。

実際のビジネスシーン

シーンA:金融業界 - ローン申請システムの統合テスト

  • ビジネス課題:複雑なローン申請ロジックや外部信用情報システムとの連携テストを行う際、特定の顧客のシナリオデータが必要だが、本番の機密情報をすべてコピーするわけにはいかない。Full Sandboxではリフレッシュに時間がかかりすぎ、Developer Sandboxではデータが不足する。
  • ソリューション:Partial Copy Sandbox を使用し、Sandbox Template(サンドボックステンプレート)で匿名化された少数の顧客データと関連するローン申請レコード、取引履歴のみをコピー。
  • 定量的効果:テスト環境の準備期間を30%短縮。本番環境のセキュリティリスクを低減しつつ、特定のケースにおけるテストカバレッジを向上。

シーンB:製造業界 - ERP連携モジュールのユーザー受け入れテスト (UAT)

  • ビジネス課題:Salesforceと基幹ERPシステム間のデータ連携モジュールを開発。特定の製品SKUやサプライヤーに関する連携テストを、本番環境に近いデータで行う必要がある。Full Sandboxではコストが高く、リフレッシュ頻度も限られる。
  • ソリューション:Partial Copy Sandboxで、特定の製品マスタ、顧客アカウント、オーダー関連オブジェクトのデータをコピー。ERP連携のテスト環境として活用。
  • 定量的効果:UATフェーズでのデータ準備にかかる時間を25%削減。本番リリース後のインテグレーションエラー発生率を20%削減。

シーンC:ヘルスケア業界 - 新しい患者管理機能の検証

  • ビジネス課題:HIPAA(医療保険の携行性と説明責任に関する法律)などの厳しい規制に準拠しつつ、新しい患者管理機能(例:予約システム、診断記録)を開発・テストする必要がある。患者の機密情報(PHI: Protected Health Information)を扱うため、厳密なデータ管理が求められる。
  • ソリューション:Partial Copy Sandboxで、匿名化された少数の患者レコードと関連する診断データ、予約データのみをテンプレートで指定してコピー。セキュリティリスクを最小限に抑えつつ、機能検証を行う。
  • 定量的効果:コンプライアンスリスクを大幅に低減。本番データに合わせたテストにより、機能の適合性と信頼性を向上させ、リリースまでの期間を短縮。

技術原理とアーキテクチャ

Partial Copy Sandboxは、Salesforceのサンドボックス生成メカニズムの一部として機能します。その核となるのは、コピー元となる本番組織(Production Org)のメタデータと、Sandbox Templateによって定義されたデータサブセットです。

基礎的な動作メカニズム

Partial Copy Sandboxの作成要求がSalesforceプラットフォームに送られると、以下のステップが実行されます。

  1. まず、本番組織のすべてのメタデータ(Apexコード、Visualforceページ、Lightningコンポーネント、カスタムオブジェクト、設定など)が新しいサンドボックスにコピーされます。
  2. 次に、指定されたSandbox Templateに基づいて、本番組織からデータがコピーされます。このテンプレートは、コピーするオブジェクト、そのオブジェクトのレコードをフィルタリングする条件、および関連するルックアップ/マスター詳細レコードを含めるかどうかを定義します。
  3. ファイルや添付ファイルも、選択されたオブジェクトに関連付けられている場合、コピーの対象となります。
  4. これらのプロセスが完了すると、新しいPartial Copy Sandboxが利用可能になります。

主要コンポーネントと依存関係

  • Sandbox Template(サンドボックステンプレート): Partial Copy Sandboxの作成時に必須となる設定です。コピーするオブジェクトと、そのオブジェクトからコピーするレコードをフィルタリングする条件を定義します。関連するルックアップまたはマスター/詳細リレーションシップを持つオブジェクトを含めることで、データの整合性を保ちます。
  • Data Copy Engine(データコピーエンジン): Salesforceプラットフォーム内部でデータを効率的にコピーするメカニズムです。
  • Metadata API / Tooling API: サンドボックスへのメタデータコピーや、開発者がメタデータをデプロイ・取得する際に利用されます。
  • 本番組織 (Source Org): データとメタデータのコピー元となる組織です。

データフロー

Partial Copy Sandboxのデータコピーの概略的なフローは以下の通りです。

ステップ 説明 関与するコンポーネント
1. テンプレート定義 管理者がSandbox Templateを作成・設定し、コピー対象のオブジェクトとフィルタリング条件を指定します。 Salesforce UI (Setup), Sandbox Template
2. サンドボックス作成要求 ユーザー(管理者)がPartial Copy Sandboxの作成を要求し、使用するSandbox Templateを選択します。 Salesforce UI (Setup)
3. メタデータコピー 本番組織のすべてのメタデータ(カスタムオブジェクト、Apexクラス、トリガー、LWCなど)が新しいサンドボックスにコピーされます。 Metadata API / Tooling API, Data Copy Engine
4. データコピー Sandbox Templateで指定されたオブジェクトのレコードと、その関連レコードが本番組織から新しいサンドボックスにコピーされます。最大10,000レコード/オブジェクトの制限があります。 Data Copy Engine, Sandbox Template
5. サンドボックスプロビジョニング コピーが完了し、新しいPartial Copy Sandboxが開発やテストに利用可能な状態になります。 Salesforce Platform

ソリューション比較と選定

Salesforceが提供する主要なサンドボックス種別とPartial Copy Sandboxを比較し、適切なソリューション選定の指針を提供します。

ソリューション 適用シーン パフォーマンス(リフレッシュ/実行) Governor Limits 複雑度(設定/管理)
Partial Copy Sandbox 統合テスト、ユーザー受け入れテスト (UAT)、品質保証 (QA)、特定のトレーニング(本番データの一部が必要な場合)。 - リフレッシュはFullより速く、実行はデータ量に依存。 本番と同様だが、データ量が少ないため、データ起因のパフォーマンス問題は起きにくい。 - Sandbox Templateの設定が必要。
Full Sandbox 大規模なステージング、パフォーマンステスト、負荷テスト、完全な本番データが必要な長期開発、本番リリース前の最終検証。 - リフレッシュは最も時間がかかり、実行も大量データのため遅延が生じやすい。 本番と同様だが、大量データによりGovernor Limitsに到達しやすい。 - データリフレッシュに時間とコストがかかる。
Developer Sandbox 開発、単体テスト、ApexコードやLightning Web Components(LWC)のデバッグ、小規模な機能開発。 - メタデータのみのためリフレッシュが速く、実行も高速。 本番と同様だが、データがないためデータ起因の問題はほぼ発生しない。 - 設定不要、メタデータのみコピー。
Developer Pro Sandbox Developer Sandboxと同様だが、より多くのストレージ(1GB)を持つため、より多くのテストデータを保存可能。 - Developer Sandboxに準じる。 本番と同様。 - 設定不要。

Partial Copy Sandbox を使用すべき場合

  • ✅ 特定のデータセットで本番に近いテストを行いたいが、Full Sandboxほどのコストや時間的制約を避けたい場合。
  • ✅ 個人情報や機密情報を扱うが、すべての本番データをコピーするリスクを避け、特定のサブセットのみで検証したい場合。
  • ✅ 開発者サンドボックスではデータが不足し、よりリアルな環境での統合テストや機能テストが必要な場合。
  • ✅ 本番環境へのデプロイ前に、実際のデータフローとデータ整合性を検証したい場合。

不適用シーン

  • ❌ 大規模なパフォーマンス・負荷テスト、すべての本番データが必要な最終ステージング環境としては、Full Sandboxが適しています。
  • ❌ メタデータのみの変更や単体テストを行う場合、Developer SandboxまたはDeveloper Pro Sandboxがより効率的です。

実装例

Partial Copy Sandboxの「実装」は主にGUIによるサンドボックスの作成とSandbox Templateの設定が中心となります。しかし、開発者の視点では、Partial Copy Sandboxが提供する本番データのサブセットを最大限に活用し、効果的なテストを行うためのApexコードの記述が重要となります。ここでは、Partial Copy Sandboxでコピーされたデータを前提とし、追加のテストデータを準備してテストを実行するApexテストクラスの例を示します。

この例では、公式ドキュメントで推奨されているテストデータファクトリパターンとテストクラスのベストプラクティスに従っています。

// TestDataFactory.cls - テストデータを効率的に作成するユーティリティクラス
// Partial Copy Sandboxのデータに加えて、特定のテストシナリオに必要な追加データを生成する際に活用します。
public class TestDataFactory {
    // テスト用のAccountレコードを作成し、挿入するメソッド
    public static Account createTestAccount(String name) {
        Account acc = new Account(Name = name, Industry = 'Banking', Phone = '123-456-7890');
        insert acc; // データベースにレコードを挿入
        return acc;
    }

    // テスト用のContactレコードを作成し、指定されたAccountに関連付けて挿入するメソッド
    public static Contact createTestContact(Id accountId, String firstName, String lastName) {
        Contact con = new Contact(FirstName = firstName, LastName = lastName, AccountId = accountId);
        insert con; // データベースにレコードを挿入
        return con;
    }

    // 必要に応じて、さらに複雑な関連データを作成するメソッドを追加
    // 例: テスト用のOpportunityレコードを作成し、指定されたAccountに関連付けて挿入するメソッド
    public static Opportunity createTestOpportunity(Id accountId, String name, Date closeDate) {
        Opportunity opp = new Opportunity(
            Name = name,
            StageName = 'Prospecting',
            CloseDate = closeDate,
            AccountId = accountId
        );
        insert opp; // データベースにレコードを挿入
        return opp;
    }
}

// PartialCopySandboxFeatureTest.cls - Partial Copy Sandboxのデータと連携するテストクラス
// Partial Copy Sandboxでコピーされた既存データをクエリし、それに追加のデータを作成して機能検証を行います。
@IsTest
private class PartialCopySandboxFeatureTest {
    // @TestSetup メソッドは、テストクラス内の各テストメソッドが実行される前に一度だけ実行され、テストデータを準備します。
    // Partial Copy Sandboxには既に本番データの一部がコピーされていると仮定し、ここでは特定のテストシナリオに必要な追加データを準備します。
    @TestSetup
    static void makeData() {
        // テスト用のアカウントを作成
        Account testAcc = TestDataFactory.createTestAccount('Sandbox Test Account X');
        // 作成したアカウントに関連する連絡先を作成
        TestDataFactory.createTestContact(testAcc.Id, 'John', 'Doe');
        // 作成したアカウントに関連する商談を作成
        TestDataFactory.createTestOpportunity(testAcc.Id, 'New Business Opp X', Date.today().addDays(30));

        // Partial Copy Sandboxに本番からコピーされた「Existing Account From Prod」という名前のアカウントが存在すると仮定する
        // もし存在しない場合は、テスト用に作成することも可能だが、ここではコピーされたデータを使用する前提とする。
    }

    // Partial Copy Sandboxのデータと連携するカスタムロジックをテストするメソッド
    @IsTest
    static void testFeatureWithSandboxData() {
        // Partial Copy Sandboxにコピーされたデータ、または@TestSetupで作成されたデータをクエリします。
        // ここでは、本番からコピーされた「Existing Account From Prod」と@TestSetupで作成されたアカウントの両方を対象とします。
        List<Account> accounts = [SELECT Id, Name FROM Account WHERE Name LIKE 'Sandbox Test Account%' OR Name = 'Existing Account From Prod'];
        System.assertNotEquals(0, accounts.size(), 'テストに必要なアカウントデータが存在するべきです。');

        // ここで、Sandboxデータと連携するカスタムロジックやApexトリガーをテストします。
        // 例: 特定のアカウントに対する処理が正しく行われるか
        Account accToProcess = accounts[0]; // 取得した最初のアカウントを使用

        Test.startTest(); // ガバナ制限のリセットを開始
        // ここに、テスト対象のカスタムApexクラスやメソッドを呼び出す処理を記述します。
        // 例: MyCustomService.processAccount(accToProcess.Id);
        Test.stopTest(); // ガバナ制限のリセットを終了

        // 処理結果を検証します。
        // 例: 更新されたアカウントレコードをクエリし、カスタムフィールドの値が期待通りか確認
        // Account updatedAcc = [SELECT Id, CustomField__c FROM Account WHERE Id = :accToProcess.Id];
        // System.assertEquals('ExpectedValue', updatedAcc.CustomField__c, 'カスタムフィールドが正しく更新されているべきです。');
    }

    // 別のシナリオをテストするメソッド
    @IsTest
    static void testAnotherScenario() {
        // 別のシナリオテスト。必要に応じて異なるデータセットを作成またはクエリします。
        // 例: 「Existing Account From Prod」というアカウントをクエリし、存在しない場合は作成
        Account existingAcc = [SELECT Id, Name FROM Account WHERE Name = 'Existing Account From Prod' LIMIT 1];
        if (existingAcc == null) {
            existingAcc = TestDataFactory.createTestAccount('Existing Account From Prod');
        }
        // そのアカウントに関連する連絡先を作成
        TestDataFactory.createTestContact(existingAcc.Id, 'Jane', 'Smith');

        // 特定のトリガーや自動化プロセスが正しく動作するかを検証します。
        Test.startTest(); // ガバナ制限のリセットを開始
        // 例: 連絡先作成時の自動化がトリガーされるか
        // TriggerHandler.doSomethingOnContactInsert();
        Test.stopTest(); // ガバナ制限のリセットを終了

        // 検証として、関連連絡先の数をカウント
        Integer contactCount = [SELECT COUNT() FROM Contact WHERE AccountId = :existingAcc.Id];
        System.assertEquals(2, contactCount, '関連連絡先が期待通りに作成されているべきです。'); // TestSetupで1つ、このテストで1つ
    }
}

注意事項とベストプラクティス

権限要件

  • サンドボックスの作成・管理:組織でサンドボックスを作成、リフレッシュ、および削除するには、「すべてのデータの変更 (Modify All Data)」および「組織の管理 (Manage Organization)」権限を持つプロファイルまたは権限セットが必要です。
  • Sandbox Template の作成・編集:Sandbox Template を作成および編集するには、「サンドボックスの管理 (Manage Sandbox)」権限を持つプロファイルまたは権限セットが必要です。
  • 開発者としてのサンドボックス使用:Partial Copy Sandbox 環境で開発作業を行う場合、本番環境と同様の権限セットやプロファイルが適用されます。特定のオブジェクト、フィールド、Apexクラスへのアクセス権が適切に設定されていることを確認してください。

Governor Limits (2025年最新版に準拠)

Partial Copy Sandboxの環境下であっても、SalesforceのApex Governor Limitsは本番環境と同様に適用されます。Partial Copy Sandboxはデータ量が限られるため、Full Sandboxで発生しがちな「SOQLクエリが多すぎる」「CPUタイムが長すぎる」といったデータ起因の問題に遭遇しにくい傾向がありますが、大規模な処理を行う場合は注意が必要です。

  • SOQL クエリの合計行数:同期 Apex で 50,000 行、非同期 Apex で 50,000,000 行。
  • DML ステートメントの合計数:150 ステートメント。
  • Heap サイズ:同期 Apex で 6MB、非同期 Apex で 12MB。
  • CPU タイム:同期 Apex で 10,000 ミリ秒、非同期 Apex で 60,000 ミリ秒。
  • Partial Copy Sandbox のリフレッシュ頻度:5日に1回。

エラー処理

  • データコピーエラー:Sandbox Templateの設定不備(例: 関連レコードがコピー対象外で参照整合性が崩れる)、大容量データのコピー中のタイムアウト、または特定のレコードにアクセスできない権限の問題などが原因で発生します。解決策としては、Sandbox作成ログを確認し、Sandbox Templateの設定を調整するか、コピー対象のレコード数を削減することを検討してください。
  • デプロイエラー:開発者がPartial Copy SandboxにApexコードやメタデータをデプロイする際に、メタデータの競合、不足しているコンポーネント、または不正な参照が原因でエラーが発生することがあります。Salesforce DX CLIやVS Codeの出力、または「設定」メニューの「展開状況 (Deployment Status)」を確認し、エラーメッセージに基づいて修正を行います。

パフォーマンス最適化

  1. Sandbox Template の最適化: 必要最小限のオブジェクトとフィルタリング条件に絞り、コピーするデータ量を減らすことで、リフレッシュ時間を短縮し、より迅速な開発サイクルを実現します。これにより、必要なテストデータのみが存在するクリーンな環境を維持できます。
  2. テストデータの効率的な管理: Sandbox Templateでコピーされない追加のテストデータは、Apex TestDataFactoryクラスや外部データローダー(Salesforce Data Loader, SFDX Data Tree)を使って効率的に生成・投入します。これにより、テストに必要なデータを迅速に準備し、テストの実行を円滑にします。
  3. 定期的なリフレッシュとクリーンアップ: Partial Copy Sandboxを定期的にリフレッシュし、古いデータや不要な設定をクリアすることで、テスト環境の健全性を保ちます。また、テスト後に不要になった一時的なテストデータは、データローダーやApexスクリプトを使用して定期的に削除し、環境をクリーンに保つことが重要です。

よくある質問 FAQ

Q1:Partial Copy SandboxとDeveloper Sandboxの主な違いは何ですか?

A1:Partial Copy Sandboxは、Sandbox Templateで指定した本番データの一部(最大10,000レコード/オブジェクト)とすべてのメタデータをコピーします。一方、Developer Sandboxは本番のメタデータのみをコピーし、データは含まれません。Partial Copy Sandboxはより本番に近いデータを使った統合テストやUATに適しており、Developer Sandboxはメタデータレベルでの開発や単体テスト、デバッグに適しています。

Q2:Partial Copy SandboxでApexコードのデバッグを行う際のおすすめのツールはありますか?

A2:Visual Studio CodeにSalesforce Extension Packを導入することが最も推奨されます。Apex Debugger、LWC Local Development Server、Query Editorなどを使って、コードのステップ実行、変数監視、SOQLクエリの実行、デバッグログの解析が効率的に行えます。また、Salesforce Developer Consoleもシンプルなデバッグやログ確認には有用です。

Q3:Partial Copy Sandboxのリフレッシュにかかる時間はどれくらいですか?また、パフォーマンスを監視するにはどうすればよいですか?

A3:リフレッシュ時間は、コピーするデータ量とメタデータ量に大きく依存します。通常、数時間から半日程度かかることが多いですが、データ量が少ない場合はより早く完了します。パフォーマンスを監視するには、サンドボックスの「設定履歴」を確認してリフレッシュ開始時間と完了時間を把握するほか、SalesforceのTrustサイト(trust.salesforce.com)でインスタンスのステータスを確認すると良いでしょう。大規模なデータコピーの場合は、Salesforceサポートに問い合わせて状況を確認することも可能です。


まとめと参考資料

Partial Copy Sandboxは、Salesforce開発ライフサイクルにおいて非常に有用なツールです。本番環境のメタデータと特定のデータサブセットを提供することで、Developer Sandboxでは再現できないリアルなシナリオでの開発・テストを可能にし、Full Sandboxよりも迅速かつコスト効率の高い環境を提供します。開発者としては、Sandbox Templateの特性を理解し、テストデータの準備とテストコードの最適化を通じて、その真価を最大限に引き出すことが重要です。

重要ポイント:

  • 本番データの一部をコピーし、より本番に近い環境で効率的な開発・テストを可能にする。
  • Sandbox Templateによるコピー対象オブジェクトとフィルタリング条件の定義が成功の鍵。
  • Full Sandboxよりも高速なリフレッシュとコスト効率を実現する。
  • 開発者にとっては、リアルなデータを使った統合テストやユーザー受け入れテストのシナリオ検証に最適。
  • Governor Limits、権限要件、データ管理のベストプラクティスを常に意識する。

公式リソース:

コメント