背景と適用シナリオ
Salesforce のエコシステムにおいて、本番環境への変更を安全に開発、テスト、展開するためには、Sandbox (サンドボックス) の存在が不可欠です。Sandbox は本番組織の隔離されたコピーであり、Salesforce はビジネスニーズに応じて複数の種類を提供しています。主なものとして、メタデータのみをコピーする Developer Sandbox、より多くのデータを保持できる Developer Pro Sandbox、本番組織の完全なレプリカである Full Sandbox、そしてその中間に位置するのが、本稿の主役である Partial Copy Sandbox (部分コピーサンドボックス) です。
Partial Copy Sandbox は、本番組織のすべてのメタデータ(Apex クラス、Visualforce ページ、カスタムオブジェクトの定義など)をコピーし、さらにサンドボックス・テンプレートに基づいて選択された本番データの一部(サンプル)をコピーする、非常にバランスの取れた環境です。これにより、Developer Sandbox のようにデータが空の状態からテストデータを手動で作成する手間を省きつつ、Full Sandbox のように高コストでリフレッシュに時間がかかるというデメリットを回避できます。
Salesforce 管理者として、Partial Copy Sandbox が特に有効なシナリオは以下の通りです。
品質保証 (QA) とユーザー受け入れテスト (UAT)
新機能やプロセスの変更をリリースする前には、実際のデータに近い環境でのテストが不可欠です。Partial Copy Sandbox は、本番から抽出された現実的なデータサンプルを含むため、開発者が Developer Sandbox で行う単体テストよりも、はるかに現実に即したシナリオテストが可能になります。例えば、特定の取引先や商談データに基づいた複雑な入力規則や自動化プロセスが、予期せぬ動作をしないかを確認するのに最適です。
統合テスト
Salesforce を外部システム(ERP、マーケティングオートメーションツールなど)と連携させている場合、その連携が正しく機能するかをテストする必要があります。Partial Copy Sandbox には関連性のあるデータが含まれているため、外部システムとのデータ同期や API コールのテストを、より本番に近い状況で実施できます。
ユーザートレーニング
新しい機能やビジネスプロセスを導入する際、エンドユーザー向けのトレーニング環境として Partial Copy Sandbox は非常に優れています。ユーザーは使い慣れた実際のデータ(のサンプル)を操作しながら新しい機能を学ぶことができるため、トレーニングの効果が飛躍的に向上します。本番データを直接触ることなく、安全に操作を試すことができます。
原理の説明
Partial Copy Sandbox の中核をなすのは、Sandbox Template (サンドボックス・テンプレート) という概念です。管理者はこのテンプレートを使用して、どのオブジェクトからデータをコピーするかを定義します。
仕組みは以下の通りです。
- メタデータの完全コピー: Sandbox の作成またはリフレッシュ時、まず本番組織のすべてのメタデータがコピーされます。これには、カスタムオブジェクト、項目、ページレイアウト、Apex コード、フローなどが含まれます。
- データサンプリング: 次に、事前に定義されたサンドボックス・テンプレートに基づき、指定されたオブジェクトのレコードが本番組織からサンプリングされます。各オブジェクトにつき最大 10,000 レコードがコピーされ、このサンプリングはランダムに行われます。
- リレーションシップの維持: Partial Copy Sandbox の大きな利点の一つは、コピーされたレコード間のリレーションシップが維持されることです。例えば、取引先 (Account) オブジェクトをテンプレートに含め、その子オブジェクトである商談 (Opportunity) も含めた場合、コピーされた取引先レコードに紐づく商談レコードも一緒にコピーされます。これにより、データの整合性が保たれ、より現実的なテストが可能になります。
サンドボックス・テンプレートは [設定] > [プラットフォームツール] > [環境] > [Sandbox] から作成・編集が可能です。テンプレートを作成する際には、コピーしたい標準オブジェクトおよびカスタムオブジェクトを選択します。必須項目や参照関係のあるオブジェクトは自動的にテンプレートに追加されるため、データモデルを意識した選択が重要です。
また、Partial Copy Sandbox には以下の制約があります。
- データストレージ: 5 GB
- ファイルストレージ: 本番組織と同量
- リフレッシュ間隔: 5 日ごと
5 GB というデータストレージの上限は、テンプレートを設計する上で最も重要な考慮事項です。むやみに多くのオブジェクトを選択すると、すぐに上限に達してしまう可能性があります。テストに必要な最小限のオブジェクトを選択することが、効率的な運用に繋がります。
サンプルコード
Partial Copy Sandbox の作成またはリフレッシュが完了した直後に、特定の Apex クラスを自動実行させることができます。これを実現するのが SandboxPostCopy インターフェースです。管理者としては、このスクリプトを利用して、手動で行っていた後処理作業を自動化することが強く推奨されます。
例えば、以下のようなタスクを自動化できます。
- テストユーザーの作成や既存ユーザーのメールアドレスの無害化(例: `.invalid` を削除して有効なテスト用メールアドレスに変更)。
- 外部システムへの自動通知を送信するトリガーやワークフロールールの無効化。
- 連携用エンドポイントを本番用からテスト用 URL に更新するためのカスタム設定やカスタムメタデータ型の更新。
- 個人情報などの機密データをマスキングまたは匿名化する処理の実行。
以下は、Salesforce の公式ドキュメントで提供されている、Sandbox のリフレッシュ後に新しいテストユーザーを作成する SandboxPostCopy
の実装例です。
// SandboxPostCopy インターフェースを実装したグローバルクラスを定義 global class MySandboxPostCopy implements SandboxPostCopy { // SandboxContext オブジェクトを引数に取る runApexClass メソッドを実装 global void runApexClass(SandboxContext context) { // デバッグログに Sandbox のコンテキスト情報を出力 System.debug('Sandbox 作成/リフレッシュのコンテキスト情報:'); System.debug(' 組織 ID: ' + context.organizationId()); System.debug(' Sandbox ID: ' + context.sandboxId()); System.debug(' Sandbox 名: ' + context.sandboxName()); // 以下は、特定のタスクを実行するロジックの例 // 例: 新しいテストユーザーを作成する // '標準ユーザー' プロファイルを取得 Profile p = [SELECT Id FROM Profile WHERE Name='Standard User']; // 新しい User オブジェクトをインスタンス化し、必須項目を設定 User u = new User( Alias = 'newuser', Email='newuser@testorg.com', EmailEncodingKey='UTF-8', LastName='Testing', LanguageLocaleKey='en_US', LocaleSidKey='en_US', ProfileId = p.Id, TimeZoneSidKey='America/Los_Angeles', UserName='newuser@testorg.com' ); // DML 操作でユーザーを挿入 insert u; // ここに他の後処理(例:データマスキング、トリガーの無効化など)を追加可能 } }
この Apex クラスを本番組織で作成・有効化しておくと、Partial Copy Sandbox を作成またはリフレッシュする際に、[Apex クラス] 項目でこのクラスを指定することができます。これにより、Sandbox が利用可能になった時点で、指定した処理が自動的に実行され、環境設定の手間を大幅に削減できます。
注意事項
Partial Copy Sandbox を効果的かつ安全に利用するためには、管理者が注意すべき点がいくつかあります。
サンドボックス・テンプレートの戦略的設計
前述の通り、ストレージは 5 GB に制限されています。テスト対象の機能に必要なデータモデルを正確に理解し、必要最小限のオブジェクトを選択することが重要です。「とりあえず全部入れておこう」というアプローチは、リフレッシュの失敗やパフォーマンスの低下に繋がります。定期的にテンプレートを見直し、不要になったオブジェクトは削除する習慣をつけましょう。
データセキュリティとマスキング
Partial Copy Sandbox には本番のデータがコピーされるため、氏名、メールアドレス、電話番号といった PII (Personally Identifiable Information / 個人識別情報) が含まれる可能性があります。これは重大なセキュリティリスクとなり得ます。コンプライアンス(GDPR や個人情報保護法など)の観点からも、これらの機密データを保護する措置は必須です。
Salesforce が提供する Salesforce Data Mask という AppExchange パッケージを利用すると、Sandbox の作成プロセス中に機密データを自動的にマスキング(匿名化または仮名化)できます。あるいは、前述の SandboxPostCopy
スクリプト内で、特定の項目の値をランダムな文字列に置き換えるなどのカスタムロジックを実装することも可能です。
ユーザー管理とメールアドレス
Sandbox が作成されると、本番ユーザーのメールアドレスの末尾に .invalid
が自動的に付与されます。これは、テスト中に誤って実際の顧客にメールが送信されるのを防ぐための安全措置です。テスト担当者が Sandbox にログインするためには、管理者が手動で彼らのメールアドレスを有効なものに修正し、パスワードをリセットする必要があります。この作業も SandboxPostCopy
スクリプトで自動化することを検討すると良いでしょう。
リフレッシュの計画
リフレッシュ間隔は5日間と Full Sandbox よりは短いですが、それでもリフレッシュ中は Sandbox を利用できなくなります。UAT やトレーニングのスケジュールと競合しないよう、リフレッシュのタイミングは関係者と事前に調整し、計画的に実行する必要があります。
まとめとベストプラクティス
Partial Copy Sandbox は、データが空の Developer Sandbox と、高価で巨大な Full Sandbox との間のギャップを埋める、非常に強力でコストパフォーマンスに優れたツールです。Salesforce 管理者としてその価値を最大限に引き出すためには、戦略的なアプローチが求められます。
以下に、Partial Copy Sandbox を運用する上でのベストプラクティスをまとめます。
- 明確なサンドボックス戦略を定義する: 組織内で、どのテストフェーズでどの種類の Sandbox を使用するかのガイドラインを定めます。Partial Copy Sandbox は、主に QA、UAT、統合テスト、トレーニングに最適です。
- サンドボックス・テンプレートを最小限に保つ: テストシナリオに必要なオブジェクトのみをテンプレートに含めます。これにより、リフレッシュ時間を短縮し、ストレージ上限の問題を回避します。
- データマスキングを徹底する: 本番データに含まれる機密情報を保護するため、Salesforce Data Mask やカスタムスクリプトによるデータマスキングを必ず実施します。セキュリティは最優先事項です。
- リフレッシュ後のタスクを自動化する:
SandboxPostCopy
インターフェースを活用して、ユーザー設定、エンドポイントの更新、不要な自動化の無効化などの後処理を自動化し、手作業によるミスや時間の浪費を防ぎます。 - 定期的なリフレッシュとコミュニケーション: 開発チームやテストチームと連携し、定期的なリフレッシュスケジュールを立てて共有します。これにより、環境が常に最新の状態で保たれ、手戻りが少なくなります。
- ストレージ使用量を監視する: 定期的に Sandbox のストレージ使用量を確認し、上限に近づいている場合はテンプレートを見直して不要なデータを削減します。
これらのプラクティスを遵守することで、Salesforce 管理者は Partial Copy Sandbox を安全かつ効率的に運用し、本番環境へのリリースの品質を大幅に向上させることができるでしょう。
コメント
コメントを投稿