Salesforce スクラッチ組織の徹底解説：SFDX 開発者向けガイド

背景と適用シナリオ

こんにちは、Salesforce 開発者の視点から、今日のテーマである Scratch Orgs (スクラッチ組織) について深掘りしていきたいと思います。Salesforce の開発に携わっている方なら、かつては変更セットや Ant Migration Tool を使って、開発者 Sandbox から UAT Sandbox へ、そして本番環境へとメタデータをデプロイしていた時代をご存知でしょう。この従来のアプローチは「組織駆動型開発 (Org-Driven Development)」と呼ばれ、いくつかの課題を抱えていました。

例えば、複数の開発者が同じ開発者 Sandbox を共有することで、互いの変更が競合（コンフリクト）したり、意図せず上書きしてしまったりする問題がありました。また、開発環境が長期間使われることで、不要なメタデータや設定がゴミとして溜まり、本番環境との差異（ドリフト）が大きくなることも珍しくありませんでした。これにより、デプロイ時に予期せぬエラーが発生し、手戻りが多くなるという経験をした開発者も多いのではないでしょうか。

これらの課題を解決するために登場したのが、Salesforce DX (SFDX) という新しい開発手法と、その中核をなす Scratch Orgs です。Scratch Orgs は、使い捨て可能で、設定ファイルから簡単に作成できる、クリーンな Salesforce 環境です。開発者は、新しい機能開発やバグ修正のたびに、まっさらな Scratch Org を作成し、必要なメタデータだけをバージョン管理システム (Git など) からデプロイして作業を行います。

適用シナリオ

機能単位の開発: 各開発者が担当する機能やユーザーストーリーごとに独立した Scratch Org を作成し、他の開発者の影響を受けずに開発に集中できます。
CI/CD パイプラインの自動化: CI (継続的インテグレーション) / CD (継続的デリバリー) ツール (GitHub Actions, Jenkins, CircleCI など) と連携し、コードがリポジトリにプッシュされるたびに自動で Scratch Org を作成し、テストを実行するといった自動化プロセスを構築できます。
パッケージ開発: AppExchange で配布する管理パッケージや非管理パッケージの開発において、名前空間を持つクリーンな環境でコンポーネントのテストや検証を行うのに最適です。
再現性の高いテスト: 本番環境と同じエディション、有効化機能、設定を持つ Scratch Org を定義ファイルに基づいて作成できるため、再現性の高い環境で単体テストや結合テストを実施できます。

このように、Scratch Orgs は現代の Salesforce 開発における「ソース駆動型開発 (Source-Driven Development)」の基盤であり、チーム開発の効率と品質を劇的に向上させるための重要なツールとなっています。

原理の説明

Scratch Orgs がどのように機能するのか、その中心的な概念を理解することが重要です。主に3つの要素が連携して動作します。

1. Dev Hub (開発ハブ)

Dev Hub は、Scratch Orgs や第二世代パッケージ (2GP) を作成・管理するための特別な機能を持つ Salesforce 組織です。通常、本番組織またはビジネス組織でこの機能を有効にします。Dev Hub は、有効期間や作成上限数など、配下にあるすべての Scratch Orgs のライフサイクルを管理する司令塔の役割を果たします。開発者は、SFDX CLI (後述) を使って Dev Hub にログインし、そこから Scratch Org の作成を指示します。

2. Salesforce CLI (SFDX CLI)

Salesforce Command Line Interface (CLI) は、開発者がコマンドラインを通じて Salesforce 組織と対話するための強力なツールです。Scratch Org の作成、ソースコードのプッシュ・プル、テストの実行、データのインポート・エクスポートなど、開発プロセスにおけるほぼすべての操作をコマンド一つで実行できます。開発者はターミナルや VS Code の統合ターミナルから `sfdx` コマンドを使い、Dev Hub や Scratch Org を操作します。

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

Scratch Org の最大の特徴は、その「形」を JSON 形式の定義ファイルで完全にコントロールできる点です。このファイルが `project-scratch-def.json` です。このファイルには、以下のような情報を記述します。

edition: `Developer`, `Enterprise`, `Professional` など、組織のエディションを指定します。
features: `PersonAccounts`, `MultiCurrency`, `Communities` など、有効化したい Salesforce の機能をリスト形式で指定します。
settings: `orgPreferenceSettings` や `securitySettings` など、組織の各種設定を細かく定義できます。例えば、Einstein の機能を有効にしたり、セッション設定を構成したりすることが可能です。

この定義ファイルをプロジェクトのソースコードと一緒にバージョン管理システムで管理することで、チーム内の誰もが全く同じ構成の Scratch Org をオンデマンドで作成できるようになります。これにより、「私の環境では動いたのに」といった問題を根本的に排除することができます。

開発の基本的なフローは以下のようになります。

開発者が SFDX CLI を使って Dev Hub に認証します。
`project-scratch-def.json` ファイルを元に、新しい機能開発用の Scratch Org を作成します。 (`sfdx force:org:create`)
Git リポジトリから最新のソースコード（Apex クラス、LWC、プロファイルなど）をローカルに取得します。
取得したソースコードを、新しく作成した Scratch Org にデプロイ（プッシュ）します。 (`sfdx force:source:push`)
開発作業を行い、変更はローカルのファイルシステムに保存されます。
作業が完了したら、変更を Git リポジトリにコミットし、プルリクエストを作成します。
CI/CD パイプラインがその変更を検知し、テスト用の Scratch Org を自動作成して Apex テストなどを実行します。
テストが成功すれば、変更は後続の Sandbox や本番環境へとマージ・デプロイされていきます。

示例代码

ここでは、SFDX CLI を使用した Scratch Org の一般的な操作に関する公式ドキュメントベースのコード例を紹介します。

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

これは、Person Accounts (個人取引先) と Service Cloud 機能を有効にした Enterprise Edition の Scratch Org を定義するファイルの例です。

{
  "orgName": "DreamHouse Realty",
  "edition": "Enterprise",
  "features": ["PersonAccounts", "ServiceCloud"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    },
    "quoteSettings": {
        "enableQuote": true
    }
  }
}

2. Dev Hub への認証

まず、CLI から Dev Hub 組織にログインします。`-d` フラグでこの組織をデフォルトの Dev Hub として設定し、`-a` フラグでエイリアス（別名）を付けます。

// Webブラウザベースのログインフローを開始します。
// MyDevHub はこの組織を指すためのエイリアスです。
sfdx auth:web:login -d -a MyDevHub

3. Scratch Org の作成

`project-scratch-def.json` ファイルを使用して、新しい Scratch Org を作成します。`-f` で定義ファイルを指定し、`-a` でこの Scratch Org のエイリアスを `MyScratchOrg` とします。有効期間を `--durationdays` (または `-d`) で指定できます (最大30日)。

// config/project-scratch-def.json ファイルに基づいてスクラッチ組織を作成します。
// エイリアスを MyScratchOrg とし、有効期間を10日に設定します。
sfdx force:org:create -f config/project-scratch-def.json -a MyScratchOrg -d 10

4. ローカルのソースコードを Scratch Org にプッシュ

ローカルプロジェクトの `force-app` ディレクトリにあるメタデータを、作成した Scratch Org にデプロイします。SFDX はローカルと組織のメタデータの差分を追跡しています。

// MyScratchOrg というエイリアスの組織にソースコードをプッシュします。
// -u は --targetusername の短縮形です。
sfdx force:source:push -u MyScratchOrg

5. Apex テストの実行

開発が完了したら、Scratch Org 内で Apex テストを実行してコードの品質を保証します。

// MyScratchOrg 組織でローカルテスト（@isTest アノテーションが付与されたテストクラス）を実行します。
// -l は --testlevel の短縮形で、ここでは RunLocalTests を指定しています。
// -r は --resultformat の短縮形で、人間が読みやすい形式 (human) で結果を出力します。
sfdx force:apex:test:run -l RunLocalTests -r human -u MyScratchOrg

6. Scratch Org を開く

コマンド一つで、デフォルトのブラウザで Scratch Org を直接開くことができます。パスワードを入力する必要はありません。

// MyScratchOrg 組織をブラウザで開きます。
sfdx force:org:open -u MyScratchOrg

注意事項

制限: Dev Hub ごとに作成できるアクティブな Scratch Org の数や、24時間以内に作成できる数には上限があります。`sfdx force:limits:api:display -u MyDevHub` コマンドで現在の消費量と上限を確認できます。不要になった Scratch Org は `sfdx force:org:delete` で削除し、上限を消費しないように心掛けることが重要です。
有効期限: Scratch Org は、その名の通り「使い捨て」です。デフォルトの有効期間は7日間で、最大30日まで延長できます。有効期限が切れると組織は削除され、復元できません。永続的な開発環境ではないことを常に意識する必要があります。
Sandbox との使い分け: Scratch Org は、すべての Sandbox を置き換えるものではありません。開発や自動テストには Scratch Org が適していますが、複数の機能を統合してテストする「統合テスト」や、ビジネスユーザーが受け入れテストを行う「UAT」のステージでは、従来の Developer Pro Sandbox や Partial Copy Sandbox、Full Sandbox が依然として重要な役割を果たします。
データ: 作成直後の Scratch Org には、メタデータはあってもビジネスデータは一切含まれていません。テストを実行するためには、テストデータを投入する必要があります。SFDX CLI のデータコマンド (`sfdx force:data:tree:export/import`) を使って、JSON 形式で定義したサンプルデータをインポートするのが一般的です。
本番環境の Dev Hub: Dev Hub 機能は、本番環境で有効にすることが推奨されています。これにより、本番環境のライセンスや機能制限が Dev Hub に反映され、それに基づいて作成される Scratch Org も本番環境と整合性が取れたものになります。

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

Scratch Orgs は、Salesforce 開発のパラダイムを大きく変えました。組織駆動型開発からソース駆動型開発への移行を促し、開発プロセスに俊敏性、信頼性、そして再現性をもたらしました。開発者として、このツールを使いこなすことは、生産性の向上に直結します。

ベストプラクティス

フィーチャーブランチごとに Scratch Org を作成する: Git で新しい機能開発用のブランチ (フィーチャーブランチ) を切ったら、それに対応する Scratch Org を作成します。これにより、開発作業が完全に分離され、コンフリクトのリスクが最小限に抑えられます。
定義ファイルをバージョン管理する: `project-scratch-def.json` はプロジェクトの「設計図」です。必ず Git リポジトリに含め、チーム全員が同じ構成の環境を再現できるようにします。
CI/CD パイプラインに組み込む: プルリクエストが作成された際に、自動的に Scratch Org を作成してテストを実行するワークフローを構築します。これにより、マージ前にコードの品質を自動的に検証できます。
テストデータ管理を自動化する: `sfdx force:data` コマンドやデータ生成スクリプトを用意し、Scratch Org 作成後に必要なテストデータを自動で投入する仕組みを整えましょう。
エイリアスを有効活用する: `sfdx force:org:create` や `sfdx auth:web:login` で設定するエイリアス (`-a` フラグ) を分かりやすい命名規則で管理することで、複数の組織を切り替えて作業する際の混乱を防ぎます。

Scratch Orgs と SFDX は、最初は学習コストがかかるかもしれませんが、一度その強力なエコシステムに慣れれば、もう以前の開発スタイルには戻れないと感じるはずです。ぜひ、次のプロジェクトから積極的に活用してみてください。

にゃんこのSalesforce日記

このブログを検索