Salesforce スクラッチ組織の徹底活用：開発者のための短期開発環境ガイド

背景と適用シナリオ

Salesforce 開発者として、私たちは常に効率的で信頼性の高い開発プロセスを追求しています。従来の開発モデルでは、すべての開発者が共有の Developer Sandbox を使用することが一般的でした。しかし、このアプローチにはいくつかの課題がありました。他の開発者による変更が意図せず自分の作業に影響を与えたり（「お前のせいで動かなくなった！」）、環境をクリーンな状態にリセットするのが困難であったり、本番環境とのメタデータの乖離が大きくなりがちでした。

これらの課題を解決するために登場したのが、Salesforce DX (Developer Experience) という新しい開発手法と、その中核をなす Scratch Org (スクラッチ組織) です。Scratch Org は、ソースコード駆動で作成される、使い捨ての（ephemeral）短期的な Salesforce 環境です。バージョン管理システム（VCS）、特に Git と連携することを前提に設計されており、現代的な DevOps や CI/CD (継続的インテグレーション/継続的デプロイメント) のプラクティスを Salesforce 開発に持ち込むことを可能にします。

具体的な適用シナリオとしては、以下のようなケースが挙げられます。

新機能開発： 新しい機能やユーザーストーリーごとに、完全に独立したクリーンな Scratch Org を作成し、他の開発者の影響を受けずに開発に集中できます。
バグ修正： 特定のバグを再現するための最小限の構成を持つ Scratch Org を作成し、迅速に原因究明と修正、テストを行うことができます。
自動テスト： CI/CD パイプライン内で Scratch Org を自動生成し、Apex テストや UI テストを実行した後、自動的に破棄することで、毎回クリーンな環境でテストの信頼性を担保します。
プルリクエストのレビュー： 開発者がプルリクエスト（Pull Request）を作成した際に、そのブランチのコードから自動的に Scratch Org を生成し、レビュアーが実際の動作を確認しながらコードレビューを行うことができます。

このように、Scratch Org は Salesforce 開発者に、これまでにないスピード、俊敏性、そして信頼性をもたらす画期的なツールなのです。

原理説明

Scratch Org の魔法を理解するためには、いくつかの重要なコンセプトを把握する必要があります。

Dev Hub (開発ハブ)

Dev Hub は、すべての Scratch Org とそのライフサイクルを管理する中心的な Salesforce 本番組織または Trailhead Playground です。Dev Hub 組織で機能を有効にすると、その組織が司令塔となり、Salesforce CLI (Command Line Interface) を通じて Scratch Org の作成、削除、管理を行う権限を持ちます。どの Scratch Org がアクティブで、誰が作成し、有効期限はいつまでか、といった情報を一元管理します。

Salesforce CLI (SFDX CLI)

Salesforce CLI は、開発者がコマンドラインから Salesforce 組織を操作するための強力なツールです。Scratch Org のライフサイクル管理（作成、ソースコードのプッシュ/プル、データのインポート/エクスポート、テストの実行、削除など）は、すべてこの CLI を通じて行われます。sf コマンドは、開発ワークフローを自動化し、スクリプト化するための基盤となります。

Scratch Org Definition File (スクラッチ組織定義ファイル)

新しい Scratch Org を作成する際、どのような「形」の組織にするかを定義する必要があります。これを担うのが project-scratch-def.json という JSON 形式のファイルです。このファイル内で、組織のエディション（Developer, Enterprise, etc.）、有効化する機能（マルチ通貨、Person Accounts など）、そして特定の設定を宣言的に定義します。

この定義ファイルをバージョン管理システムに含めることで、チーム全員が全く同じ構成の Scratch Org をオンデマンドで作成できるようになり、開発環境の標準化と一貫性が保たれます。「私の環境では動いたのに」という問題が劇的に減少します。

ソース駆動 (Source-Driven) 開発モデル

Scratch Org は「ソース駆動」という考え方を体現しています。これは、信頼できる唯一の情報源 (Single Source of Truth) は、Salesforce 組織内のメタデータではなく、Git などのバージョン管理システムにあるコードである、という考え方です。

開発者はまず、ローカルのコードを編集します。そして、その変更を Scratch Org にプッシュ (push) して動作確認を行います。組織内で直接変更を加えることは稀で、もし行った場合もその変更をローカルにプル (pull) して、最終的にはバージョン管理システムにコミットします。この流れにより、すべての変更履歴が追跡可能になり、チームでのコラボレーションが容易になります。

Scratch Org は、作成時にはほとんど空っぽの状態です。開発者は、バージョン管理システムからチェックアウトしたメタデータ（Apex クラス、Visualforce ページ、オブジェクト定義など）をデプロイし、必要なテストデータを投入して初めて、意味のある開発環境として機能します。

サンプルコード

ここでは、Salesforce CLI を使用した Scratch Org の一般的なライフサイクルを示すコード例を紹介します。これらのコマンドは、Salesforce DX プロジェクトのルートディレクトリで実行することを想定しています。

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

まず、作成する Scratch Org の構成を定義します。この例では、Enterprise Edition で、いくつかの追加機能（担当者 ToDo と行動のリマインダー、Person Accounts）を有効にしています。

{
  "orgName": "Dreamhouse Realty",
  "edition": "Enterprise",
  "features": ["ContactsToMultipleAccounts", "PersonAccounts"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    }
  }
}

2. Scratch Org の作成

次に、CLI を使って Dev Hub に接続し、上記の定義ファイルに基づいて新しい Scratch Org を作成します。

# Dev Hub 組織にログイン (ブラウザが開き、認証を行います)
# my-dev-hub は Dev Hub 組織を識別するためのエイリアス (別名) です
sf org login web -d -a my-dev-hub

# scratch-def.json ファイルを元に新しいスクラッチ組織を作成
# -f: 使用する定義ファイルを指定
# -a: これから作成するスクラッチ組織に 'my-scratch-org' というエイリアスを設定
# -d: このスクラッチ組織をデフォルトの組織として設定
# -v: 接続先となる Dev Hub 組織のエイリアスを指定
# 有効期間を10日に設定
sf org create scratch -f config/project-scratch-def.json -a my-scratch-org -d -v my-dev-hub --duration-days 10

3. メタデータのデプロイ

ローカルプロジェクトにあるソースコード（Apex、LWCなど）を、新しく作成した Scratch Org にデプロイします。

# プロジェクト内のすべてのメタデータをデフォルトの組織 (my-scratch-org) にデプロイ
sf project deploy start

4. 権限セットの割り当て

開発やテストに必要な権限をユーザーに付与するため、プロジェクトに含まれる権限セットを割り当てます。

# 'MyPermissionSet' という名前の権限セットをスクラッチ組織のデフォルトユーザーに割り当て
sf org assign permset -n MyPermissionSet

5. テストデータのインポート

開発や手動テストを効率的に行うために、サンプルデータを投入します。以下のコマンドは、`sfdx-data/data-plan.json` のようなプランファイルに基づいて関連するデータをインポートします。

# ./data/sample-data.json に定義されたデータをインポート
# sObject ツリー API を使用して、関連レコードも一度にインポート可能
sf data tree import -p ./data/Account-Contact-plan.json

6. Apex テストの実行

コードの品質を担保するため、Apex テストを実行します。

# 組織内のすべての Apex テストを実行
# -c: コードカバレッジの結果も表示
# -r: 人間が読みやすい形式 (human) で結果を出力
sf apex test run -c -r human

7. Scratch Org の削除

機能開発やテストが完了したら、Scratch Org は不要になります。積極的に削除することで、Dev Hub のアクティブな Scratch Org の上限数を管理します。

# 'my-scratch-org' というエイリアスのスクラッチ組織を削除
# -p: 確認プロンプトなしで削除を実行
sf org delete scratch -o my-scratch-org -p

注意事項

権限

Scratch Org を作成するには、Dev Hub 組織で「Dev Hub」機能を有効にし、操作を行うユーザーに「Salesforce DX」権限セットが割り当てられている必要があります。通常、System Administrator プロファイルにはこの権限が含まれています。

API 制限と組織の上限

Dev Hub 組織には、作成できる Scratch Org の数に上限があります。この上限は、Salesforce のエディションによって異なります。

アクティブな Scratch Org の上限： 同時に存在できる Scratch Org の数。
日次 Scratch Org の上限： 24時間以内に作成できる Scratch Org の数。

CI/CD パイプラインなどで大量に Scratch Org を作成する場合は、これらの上限に達しないように、不要になった組織を速やかに削除するなどの管理戦略が必要です。上限数は `sf limits api display -o YOUR_DEV_HUB_ALIAS` コマンドで確認できます。

ライフサイクル管理

Scratch Org のデフォルトの有効期間は7日間で、最大で30日まで延長できます。有効期限が切れると、組織は自動的に削除され、復元することはできません。Scratch Org はあくまで一時的な環境であり、永続的なデータを保存する場所ではないことを強く認識する必要があります。

Sandbox との使い分け

Scratch Org はすべての開発環境を置き換えるものではありません。Developer Sandbox や Partial/Full Sandbox も依然として重要な役割を担います。

Scratch Orgs: 個別の機能開発、ユニットテスト、自動化されたテスト。クリーンで使い捨て。
Developer/Developer Pro Sandboxes: 複数の機能がマージされた状態での結合テスト (SIT) や、より長期間にわたる探索的テスト。
Full/Partial Sandboxes: 本番に近いデータ量でのパフォーマンステスト、ステージング、UAT (ユーザー受け入れテスト)。

適切な環境を適切な目的で使い分けることが、開発プロセス全体の成功の鍵となります。

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

Scratch Org は、Salesforce 開発のパラダイムを大きく変える強力なツールです。ソース駆動のアプローチを促進し、開発の俊敏性、再現性、そして信頼性を飛躍的に向上させます。

以下に、Scratch Org を最大限に活用するためのベストプラクティスをまとめます。

バージョン管理を徹底する: Git のようなバージョン管理システムを信頼できる唯一の情報源とし、すべてのメタデータ、設定ファイル (project-scratch-def.json を含む)、テストデータを管理します。
CI/CD パイプラインに組み込む: プルリクエストの作成やメインブランチへのマージをトリガーとして、Scratch Org の作成、テスト、検証、破棄を自動化します。これにより、コードの品質が常に高く保たれます。
エイリアスを賢く使う: -a フラグを使って、Dev Hub や Scratch Org にわかりやすいエイリアスを付けましょう。これにより、複数の組織を切り替えて作業する際の混乱を防ぎます。
定義ファイルを標準化する: チームやプロジェクトで共通の project-scratch-def.json を使用し、全員が同じ基盤の上で開発できるようにします。必要に応じて、特定の機能開発用に派生バージョンを作成することも有効です。
テストデータ戦略を持つ: sf data コマンドやデータ生成ツールを活用し、開発やテストに必要なデータを迅速に Scratch Org へ投入できる仕組みを構築します。
不要な組織はすぐに削除: Dev Hub の上限数を圧迫しないよう、タスクが完了した Scratch Org は積極的に削除する文化をチームに根付かせます。

Salesforce 開発者として Scratch Org を使いこなすことは、もはや選択肢ではなく必須のスキルです。この一時的でパワフルな開発環境を味方につけ、より高品質なアプリケーションをより迅速に提供していきましょう。

にゃんこのSalesforce日記

このブログを検索