Aug 11, 2026

下書き_Salesforceのスクラッチ環境（Scratch Org）入門とよく使う操作

この記事は、Salesforce のスクラッチ環境（Scratch Org）を初めて使う人、または「Sandbox との違いがまだ曖昧」な人向けに、概要とよく使う操作をまとめたものです。

読み終わると、Scratch Org を作る条件、作成〜開発〜削除の流れ、Sandbox との使い分けが分かるようになります。

想定読者

Salesforce DX（sf CLI / VS Code）で開発を始めようとしている人
Sandbox はあるが、Scratch Org をまだ常用していない人
この記事では扱わないこと: 2GP パッケージの詳細設計、形状の複雑な org shape 運用、CI 全体の設計

結論

Scratch Org は 短命・使い捨て前提の開発用 org。機能検証やブランチ単位の開発に向く
使うには Dev Hub の有効化 と CLI 認証が必要
日常の流れは「作成 → ソース push → テスト → 不要なら削除」
長期の結合試験や本番近いデータ検証は、従来どおり Sandbox の方が向くことが多い

実際の環境

OS: Windows / WSL 想定
ツール: Salesforce CLI（sf）、VS Code
前提: Dev Hub が使える本番 or Partner/Developer 系 org があること
検証日: 2026-08-11（CLI は更新が早いため、オプションは --help で再確認推奨）

Scratch Org とは何か

Scratch Org は、Salesforce DX の仕組みで作成する 一時的な開発用組織 です。

特徴のイメージ:

定義ファイル（JSON）に書いた機能・設定をもとに、空に近い org を都度生成できる
有効期限があり、期限切れや手動削除で消える（使い捨て）
Git 管理したソースを push / pull して開発する前提と相性が良い

「本番や共有 Sandbox を汚さずに、機能単位で試す場所」と考えると分かりやすいです。

Sandbox との使い分け

観点	Scratch Org	Sandbox
寿命	短い（数日〜最大でも短め）	長い
初期状態	定義に近い、比較的クリーン	本番コピーや既存設定が残る
向く用途	機能開発、実験、PR 単位の検証	結合試験、UAT、データ寄り検証
向いていない用途	長期のデータ蓄積、長い検証期間	毎回クリーンにゼロから作りたい場合

実務では「機能は Scratch、業務シナリオ確認は Sandbox」のように併用することが多いです。

使う前の前提

Dev Hub を有効化する（Dev Hub 側の設定）
CLI で Dev Hub にログインする
プロジェクトに Scratch Org 定義ファイルがある（例: config/project-scratch-def.json）

# Dev Hub へログインし、デフォルト Dev Hub に設定
sf org login web --alias my-devhub --set-default-dev-hub

# 確認
sf org list

定義ファイルのイメージ

config/project-scratch-def.json の例です（プロジェクトによって異なります）。

{
  "orgName": "Demo Company",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

ここで edition や features を変えると、作られる Scratch Org の初期能力が変わります。
「この機能が org に無い」ときは、まず定義ファイルを疑うと早いです。

よく使う操作

1. Scratch Org を作成する

sf org create scratch \
  --definition-file config/project-scratch-def.json \
  --alias scratch-feature-a \
  --duration-days 7 \
  --set-default

ポイント:

--alias : あとから指定しやすい名前
--duration-days : 有効日数（必要以上に長くしない）
--set-default : 以降のコマンドのデフォルト org にする

2. org を開く / 情報を見る

# ブラウザで開く
sf org open

# 詳細表示（Org ID やログイン URL など）
sf org display --target-org scratch-feature-a

# 一覧
sf org list

3. ソースを push / pull する

Scratch Org へローカルソースを反映:

sf project deploy start --source-dir force-app --target-org scratch-feature-a

Scratch Org 上の変更をローカルへ取得:

sf project retrieve start --source-dir force-app --target-org scratch-feature-a

（環境や拡張機能によっては、push/pull のラッパー操作を使う場合もあります。本質は「ソースと org を同期する」ことです。）

4. Apex テストを回す

sf apex run test \
  --target-org scratch-feature-a \
  --test-level RunLocalTests \
  --result-format human \
  --code-coverage \
  --wait 20

5. 不要になったら削除する

sf org delete scratch --target-org scratch-feature-a --no-prompt

期限切れを待たず、検証が終わったら消す運用の方が、Dev Hub の枠（同時作成数など）を圧迫しにくいです。

実務での一日の流れ（例）

# 1. Dev Hub 認証済み前提
sf org create scratch -f config/project-scratch-def.json -a scratch-SF123 -d 3 -s

# 2. ソース反映
sf project deploy start --source-dir force-app

# 3. ブラウザで動作確認
sf org open

# 4. テスト
sf apex run test --tests MyFeatureTest --wait 20 --result-format human

# 5. 終了後
sf org delete scratch --target-org scratch-SF123 --no-prompt

ハマったこと・注意点

Dev Hub 未設定 / 別アカウントを見ていて作成できない
→ sf org list で Dev Hub を確認
features 不足でメタデータ deploy に失敗する
→ Scratch 定義に必要な feature / setting を足す
デフォルト org が Sandbox のまま
→ Scratch に deploy したつもりが別環境へ行く。作成時に --set-default、または毎回 --target-org
有効期限切れで突然入れなくなる
→ 長期検証は Sandbox 側へ移す
共有しない前提なのに URL だけ渡して混乱する
→ Scratch は個人・短命。共有検証が必要なら Sandbox を使う

向いている人 / 向いていない人

向いている人

Git ブランチ単位で機能開発したい人
クリーンな状態から設定やメタデータを検証したい人
Sandbox を壊したくない人

向いていない（または併用が必要な）人

本番相当のデータ量で性能や業務フローを見たい人
何週間も同じ org で継続検証したい人
Dev Hub を使えない制約がある人

まとめ

Scratch Org は 短命の開発用サンドボックス代替（完全な Sandbox 置き換えではない）
基本は create scratch → deploy → test → delete scratch
Sandbox と役割を分けて使うと安全
作成前に Dev Hub、定義ファイル、デフォルト org を確認する