Salesforce スクラッチ組織: 開発者とアーキテクトのための徹底解説

背景と応用シナリオ

従来の Salesforce 開発では、すべての開発者が共有の Developer Sandbox を使用することが一般的でした。しかし、このアプローチにはいくつかの課題がありました。例えば、他の開発者による変更が意図せず影響を与える「コンフィグレーションの競合」、本番環境からのリフレッシュに時間がかかること、そして環境間の差異（Configuration Drift）が発生しやすいことなどです。これらの問題は、開発の生産性を低下させ、デプロイメントのリスクを高める原因となっていました。

このような課題を解決するために登場したのが、Salesforce DX (Developer Experience) という最新の開発手法と、その中核をなす Scratch Org (スクラッチ組織) です。スクラッチ組織とは、ソースコードから動的に作成される、一時的で使い捨て可能な Salesforce 組織です。バージョン管理システム（VCS）にあるメタデータを「信頼できる唯一の情報源（Single Source of Truth）」として扱い、クリーンな環境で開発、テスト、レビューを行うことを可能にします。

主な応用シナリオ

機能開発：各開発者または各機能ブランチごとに独立したスクラッチ組織を作成し、他の開発からの影響を受けずに分離された環境で開発を進めることができます。
自動テスト：CI/CD (継続的インテグレーション/継続的デリバリー) パイプラインに組み込み、プルリクエストごとに新しいスクラッチ組織を生成して自動テストを実行します。これにより、コード品質を常に高く維持できます。
管理パッケージ開発：名前空間を持つクリーンな組織でパッケージのインストールやアップグレードのテストを効率的に行えます。
バグの再現：本番環境と同じエディション、機能、設定を持つスクラッチ組織を素早く作成し、特定のバグを再現するための環境として利用できます。

原理説明

スクラッチ組織の概念は、「ソース駆動開発（Source-Driven Development）」という考え方に基づいています。つまり、Salesforce 組織そのものではなく、Git などのバージョン管理システムに保管されているソースコードやメタデータが正となります。スクラッチ組織は、このソースコードを反映させるための一時的な器に過ぎません。

スクラッチ組織のライフサイクルは Dev Hub (開発ハブ) によって管理されます。Dev Hub は、スクラッチ組織を作成し、管理する権限を持つ特別な本番組織またはビジネス組織です。開発者は Dev Hub に対して認証を行い、Salesforce CLI を通じてスクラッチ組織の作成や削除を指示します。

スクラッチ組織の作成プロセスは以下のようになります。

Dev Hub の有効化と認証：本番組織で Dev Hub 機能を有効化し、Salesforce CLI を使用して認証します。
設定ファイルの定義：プロジェクトのルートディレクトリに project-scratch-def.json というファイルを作成します。このファイルで、作成したいスクラッチ組織のエディション（Developer, Enterpriseなど）、有効化する機能（Person Accounts, Multi-Currencyなど）、各種設定を定義します。
スクラッチ組織の作成：Salesforce CLI コマンド sfdx force:org:create を実行し、定義ファイルに基づいて新しいスクラッチ組織を作成します。
ソースコードのプッシュ：ローカルのソースコード（Apex クラス、Visualforce ページ、オブジェクト定義など）を sfdx force:source:push コマンドでスクラッチ組織にデプロイします。
開発とテスト：スクラッチ組織で開発やテストを実施します。組織内で行った変更は sfdx force:source:pull コマンドでローカルに同期できます。
スクラッチ組織の削除：開発が完了したら、sfdx force:org:delete コマンドで組織を削除します。スクラッチ組織は最大30日で自動的に有効期限が切れます。

サンプルコード

スクラッチ組織を利用する上で最も重要なファイルとコマンドの例を以下に示します。これらのコードは Salesforce 公式ドキュメントに基づいています。

1. スクラッチ組織定義ファイル (project-scratch-def.json)

この JSON ファイルは、作成されるスクラッチ組織の「設計図」です。エディション、有効化したい機能、特別な設定などを定義します。

{
  "orgName": "DreamHouse Realty",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    },
    "quoteSettings": {
      "enableQuote": true
    },
    "accountSettings": {
      "enablePersonAccounts": true
    }
  }
}

詳細なコメント

orgName: スクラッチ組織に付ける表示名です。
edition: 組織のエディションを指定します（Developer, Enterprise, Professional, Group, Personal）。
features: 有効化する追加機能を配列で指定します。例では、API経由でのパスワード設定を有効にしています。
settings: 特定の設定を詳細に構成します。
- lightningExperienceSettings: Lightning Experience 関連の設定。
- mobileSettings: Salesforce モバイルアプリ関連の設定。
- quoteSettings: 見積もり機能を有効にします。
- accountSettings: 個人取引先（Person Accounts）を有効にします。これは一度有効にすると無効化できないため、スクラッチ組織でのテストに非常に便利です。

2. Salesforce CLI コマンドシーケンス

一般的な開発ワークフローにおける CLI コマンドの使用例です。

# 1. Dev Hub 組織にログインします (-d フラグでデフォルトの Dev Hub として設定)
sfdx auth:web:login -d -a MyDevHub

# 2. project-scratch-def.json を使用してスクラッチ組織を作成します
#    エイリアスを "my-scratch-org" とし、有効期間を 7 日間に設定します
sfdx force:org:create -f config/project-scratch-def.json -a my-scratch-org -s -d 7

# 3. ローカルのソースコードをスクラッチ組織にプッシュします
sfdx force:source:push -u my-scratch-org

# 4. 開発に必要な権限セットをユーザに割り当てます
sfdx force:user:permset:assign -n MyPermissionSet -u my-scratch-org

# 5. テストデータをインポートします (SOQL でエクスポートしたデータを使用)
sfdx force:data:tree:import -p ./data/sample-data-plan.json -u my-scratch-org

# 6. スクラッチ組織をブラウザで開いて確認します
sfdx force:org:open -u my-scratch-org

# 7. (開発後) スクラッチ組織で行った変更をローカルにプルします
sfdx force:source:pull -u my-scratch-org

# 8. (作業完了後) スクラッチ組織を削除します
sfdx force:org:delete -u my-scratch-org -p

注意事項

権限と Dev Hub：スクラッチ組織を作成するユーザーは、Dev Hub 組織で「Salesforce DX」権限セットが割り当てられている必要があります。また、スクラッチ組織機能を利用するには、まず本番組織またはビジネス組織で Dev Hub を有効化する必要があります。
API 制限：Dev Hub ごとに作成できるスクラッチ組織の数には上限があります。例えば、Enterprise Edition の Dev Hub では、有効なスクラッチ組織は最大100個、1日あたりの作成数は200個までといった制限があります。これらの制限は組織のエディションによって異なるため、公式ドキュメントで確認することが重要です。
有効期限：スクラッチ組織はデフォルトで7日間、最大で30日間有効です。永続的な環境ではないため、重要なデータや設定をスクラッチ組織内にのみ保存しないように注意してください。全ての変更はローカルにプルし、バージョン管理システムにコミットする必要があります。
データの取り扱い：スクラッチ組織はメタデータのみで作成され、データは含まれません。開発やテストに必要なデータは、sfdx force:data:tree:import/export コマンドや Apex のデータ生成クラス（@isTest(SeeAllData=false)を前提としたテストデータファクトリ）を利用してロードする必要があります。
サポートされていないメタデータ：一部のメタデータタイプや設定は、スクラッチ組織定義ファイルやソースプッシュで完全にはサポートされていない場合があります。その場合は、手動での設定手順をプロジェクトの `README.md` ファイルなどに明記し、チームで共有することが推奨されます。

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

スクラッチ組織は、現代の Salesforce 開発におけるパラダイムシフトです。従来の共有 Sandbox 開発が抱えていた多くの問題を解決し、開発チームに俊敏性、信頼性、そして高い生産性をもたらします。ソース駆動のアプローチを徹底することで、チームは一貫性のあるクリーンな環境で開発でき、CI/CD パイプラインとの連携により、品質保証のプロセスを大幅に自動化・効率化できます。

ベストプラクティス

ソースを信頼の源とする：全ての変更はバージョン管理システム（Gitなど）にコミットし、スクラッチ組織はいつでも再作成できるものとして扱います。
セットアップを自動化する：スクラッチ組織の作成、ソースのプッシュ、権限セットの割り当て、テストデータの投入といった一連のプロセスをシェルスクリプトや npm スクリプトにまとめ、ワンコマンドで実行できるようにします。
定義ファイルの一貫性を保つ：チーム全体でベースとなる project-scratch-def.json を共有し、プロジェクトの要件に応じて派生させることで、環境の一貫性を保ちます。
CI/CD パイプラインに統合する：GitHub Actions や Jenkins などの CI/CD ツールを活用し、プルリクエストの作成をトリガーとしてスクラッチ組織を自動生成し、Apex テストや Lint チェックを実行します。
データ戦略を確立する：小規模で代表的なテストデータを生成・ロードする仕組みを構築し、開発とテストの初期段階でデータ関連の問題を発見できるようにします。
こまめにクリーンアップする：不要になったスクラッチ組織は積極的に削除し、Dev Hub の上限に達しないように管理します。

スクラッチ組織を正しく理解し、活用することで、あなたのチームの開発プロセスはよりモダンで効率的なものへと進化するでしょう。

にゃんこのSalesforce日記

このブログを検索

Salesforceリード管理のマスター：アーキテクトのための技術ガイド