2026.10.26 業務システム

Salesforce Sandboxとは？4種別の選び方とログイン・作成・更新をCLIで回す手順

Salesforce Sandboxは、本番組織の設定を複製して作る検証用の組織です。本番のレコードやユーザーに触れずに設定変更やApexの開発を試せるため、Salesforceで何かを作るときの作業場所になります。この記事では、Developer・Developer Pro・Partial Copy・Fullの4種別の違いを押さえたうえで、test.salesforce.comとMy Domain URLでのログイン、Salesforce CLIの定義ファイルを使った作成と更新、更新直後の後処理を自動化するSandboxPostCopyの実装例までを、ログインから作成・更新、更新後の設定確認へと作業の流れに沿って示す構成です。数値と仕様は2026年10月時点の公式情報に基づきます。

まとめ：種別は複製データで選び更新はCLIと後処理クラスで定型化する

4種別の差は、本番のレコードをどこまで持ち込むかに集約されます。DeveloperとDeveloper Proはメタデータだけを複製し、Partial Copyはテンプレートで選んだ一部のレコードを、Fullは本番と同じ容量で全件を複製します。開発はDeveloper系で行い、本番データを使う結合検証と移行リハーサルにだけPartial CopyやFullを割り当てるのが基本の型です。

ログインはSandbox専用の入口から入ります。ユーザー名の末尾にSandbox名が付くため、本番と同じユーザー名とパスワードではlogin.salesforce.comから入れません。日常的に使うならMy Domainのsandbox.my.salesforce.com形式のURLを控えておき、CLIでも同じURLで認証します。

更新は担当者がその都度手で操作する手順に頼らず、同じ条件で繰り返し実行できる手順に定型化するのがお勧めです。Salesforce CLIのsf org refresh sandboxと定義ファイルで更新を定型化し、メール送信の設定や外部連携の接続先といった更新のたびに戻る項目は、SandboxPostCopyを実装したApexクラスで自動的に直します。Sandboxの構成と更新運用を開発体制ごと設計したい場合は、Salesforce導入支援サービス・Apex開発で要件の切り分けから相談できます。

Salesforce Sandboxが本番組織から複製する範囲と4種別の違い

Sandboxは模型ではなく、本番と同じSalesforceの組織です。違いは持ち込むデータの範囲と、作り直せる頻度の2点です。

メタデータは必ず複製しレコードは種別で変わるSandboxの基本構造

Salesforceの公式ガイド「What is a Salesforce Sandbox?」は、Sandboxが本番組織のメタデータを常に含むと説明しています。メタデータとは、カスタムオブジェクト、項目、入力規則、Flow、Apexクラス、権限セットといった組織の設定そのものです。どの種別を選んでも、作成した時点の本番の設定がそのまま手に入ります。

種別で変わるのはレコードです。設定の検証だけならレコードは不要で、帳票の出力や大量データの処理速度を確かめるなら取引先や商談などの業務データが要ります。

DeveloperからFullまで4種別のデータ容量と更新間隔の比較表

公式ガイドとTrailheadの記載をまとめると、2026年10月時点の主な仕様は次のとおりです。更新間隔は、一度更新してから次に更新できるまでの最短日数です。

種別	本番レコード	データ容量	更新間隔	主な用途
Developer	複製しない	200MB	1日	個人の開発
Developer Pro	複製しない	1GB	1日	開発・品質保証
Partial Copy	テンプレート指定分	5GB	5日	受け入れ・結合テスト
Full	全件	本番と同等	29日	性能試験・ステージング

Trailheadの単元「Salesforce 組織で Sandbox をセットアップする」は、Fullを性能試験や負荷試験とステージング向けとし、開発には推奨していません。29日に1回しか作り直せない環境で日々の開発をすると、壊れた状態から戻す手段がなくなるためです。開発用と検証用を何段に分けるかの構成例は、Salesforce開発の四層とリリース管理を整理した記事のサンドボックス章で扱っています。

Partial CopyとFullの複製範囲を絞り込むSandboxテンプレートの役割

Sandboxテンプレートは、Partial CopyとFullで複製するオブジェクトを選ぶ設定です。Partial Copyでは作成時にテンプレートの指定が必要で、選んだオブジェクトのレコードだけが5GBの範囲で入ります。Fullでもテンプレートを指定すれば、添付ファイルや履歴のように検証で使わない大きなデータを外して作成時間を縮められます。

テンプレートを作るときは、検証で使うオブジェクトだけでなく、その参照先の親オブジェクトも含めているかを確かめてください。商談を検証したいのに取引先を外すと、画面や帳票で取引先の情報が引けず、本番と同じ条件の検証になりません。

test.salesforce.comとMy Domain URLのログイン手順

本番と同じ入口から入ろうとして失敗するのが、Sandboxの典型的なつまずきです。

Sandbox名が末尾に付くユーザー名とtest.salesforce.com

Salesforceのユーザー名はすべての組織を通じて一意でなければなりません。そのためSandboxを作ると、本番からコピーされたユーザーのユーザー名の末尾に、ピリオドとSandbox名が付きます。Salesforce CLIのsf org create sandboxのヘルプ文も、本番のユーザー名との衝突を避けるためにSandbox名を付加すると説明しています。Sandbox名がdev1なら、本番のユーザー名の後ろに「.dev1」を足した文字列がSandboxでのユーザー名です。パスワードは作成時点の本番のものが引き継がれます。

入口はhttps://test.salesforce.comです。本番の入口であるlogin.salesforce.comにSandboxのユーザー名を入れても認証は通りません。設定画面の［Sandbox］一覧にある［ログイン］リンクから開くと、ユーザー名が組み立てられた状態のログイン画面が開くので、初回はここから入ると確実です。

My Domain固有のURLでSandboxへ直接ログインする方法

My Domainを設定した組織では、Sandboxごとに固有のログインURLが割り当てられます。形式はhttps://<MyDomainName>--<SandboxName>.sandbox.my.salesforce.comで、My Domain名がacme、Sandbox名がdev1ならacme--dev1.sandbox.my.salesforce.comになります。

test.salesforce.comは汎用の入口でどの組織かを判別できないため、SSOを組んでいる組織ではこのURLから入らないとシングルサインオンに進めません。チームの手順書にはこのURLを固定して書いておきます。

sf org login webでSandboxを認証するCLIコマンド

VS CodeやCLIから開発する場合は、Salesforce CLIのplugin-authにあるsf org login webで認証します。plugin-authのヘルプは、Sandboxを指定するときは--instance-urlにMy DomainのSandbox URLを渡すよう案内しています。

# dev1 Sandboxをブラウザで認証し、別名dev1で既定の組織にする
sf org login web --instance-url https://acme--dev1.sandbox.my.salesforce.com --alias dev1 --set-default

# 認証済みの組織と別名を一覧で確かめる
sf org list

--instance-urlを省くと既定のlogin.salesforce.comが開き、Sandboxのユーザー名では入れません。sfdx-project.jsonのsfdcLoginUrlに入口を書いておく方法もありますが、--instance-urlを指定するとそちらが優先されます。

Salesforce CLIの定義ファイルでSandboxを作成し進捗を追う手順

設定画面から手で作ると担当者ごとに条件がばらつきます。CLIの定義ファイルに条件を書けば、同じ条件で何度でも作り直せます。

設定画面からSandboxを新規作成するときに決める名前と種別の制約

設定画面では、本番組織の［設定］から［Sandbox］を開き、［新規Sandbox］で作成します。名前は英数字の10文字以内で、本番組織の中で一意でなければなりません。削除処理中のSandboxと同じ名前は、削除が終わるまで再利用できない点にも注意が要ります。

名前はユーザー名の末尾とMy DomainのURLにそのまま入るため、後から変えられない識別子として扱ってください。dev1やuat、stagingのように用途が分かる短い名前にしておくと、CLIの別名とも揃えやすくなります。

定義ファイルとsf org create sandboxで作成を定型化する設定例

Salesforce CLIのplugin-orgには、Sandboxを扱うsf org create sandbox・sf org refresh sandbox・sf org resume sandbox・sf org delete sandboxの4コマンドがあります。--license-typeに渡せる値はDeveloper、Developer_Pro、Partial、Fullの4つです。

// config/dev1-sandbox-def.json
{
  "sandboxName": "dev1",
  "licenseType": "Developer",
  "apexClassName": "SandboxSetup"
}

# 本番組織 prodOrg を起点に、定義ファイルの条件でSandboxを作る（最大30分待つ）
sf org create sandbox --definition-file config/dev1-sandbox-def.json --alias dev1 --target-org prodOrg --wait 30

plugin-orgのsandboxRequest.tsを読むと、定義ファイルのキーは先頭を大文字に変換してSandbox作成の要求へ渡され、licenseTypeを省くとDeveloperになります。apexClassNameはクラス名からApexClassを照会してIDに解決する仕組みで、apexClassIdとの同時指定はエラーです。DeveloperとDeveloper Proで作ったSandboxは、既定でソース追跡が有効になります。

–asyncで作成を要求しsf org resume sandboxで再開

Sandboxの作成と更新は、種別とデータ量によって数十分から長いものでは日をまたぎます。--waitの時間内に終わらなかった場合、CLIはジョブIDと再開用のコマンドを表示して制御を返すので、作業はそこで中断して構いません。

# 作成を要求だけしてすぐ戻る
sf org create sandbox --definition-file config/dev1-sandbox-def.json --alias dev1 --target-org prodOrg --async

# 後から状況を確かめ、完了していれば認証情報を取り込む
sf org resume sandbox --name dev1 --target-org prodOrg

既存のSandboxを元に複製するときは--source-sandbox-nameを使い、元と先は同じ本番組織に属している必要があります。

Sandbox更新の前後に確認する項目とSandboxPostCopyの実装例

更新はSandboxを本番の最新状態で作り直す操作です。便利な反面、Sandboxにしか無いものはすべて消え、本番から持ち込んだ設定の中には検証環境で動かすと危険なものが混ざります。

更新で破棄されるデータと変更を守るために更新前に確かめること

Trailheadの単元は、更新すると前回の更新後に作成したデータとカスタマイズが破棄されると明記しています。開発途中のApexクラスや画面の設定がSandboxにしか無い状態で更新すると、それらは戻りません。更新の前に、次の3点を確かめてください。

Sandboxにしか無い変更が、Gitなどのソース管理か本番へのリリース予定に入っているか
検証のために手で作ったテストレコードを、更新後に作り直す手段があるか
そのSandboxを使う担当者全員に、更新日時と作業停止の時間を伝えたか

CLIで更新する場合、sf org refresh sandboxに--no-auto-activateを付けると、更新が終わっても新しい環境へ自動では切り替わりません。担当者の作業が落ち着いた時点で切り替えたいときに使います。

メール送信のアクセスレベルとユーザーのメールアドレスを更新直後に見直す

新しく作ったSandboxでは、送信アクセスレベルの既定値として設定されているのは「システムメールのみ」です。Trailheadの単元は、最初のログイン時と更新のたびに［設定］の［メールの到達性］を開き、「システムメールのみ」か「アクセス権なし」になっているかを確認するよう求めています。検証のために「すべてのメール」へ変えたまま更新を重ねると、本番の顧客アドレスへ検証メールを送る事故の入口になります。

コピーされたユーザーのメールアドレスには、末尾に.invalidが付いて届かない状態になります。通知メールの動作を検証する担当者だけ、自分のメールアドレスを手で正しい値に戻す運用が一般的です。外部システムの接続先も本番を向いたまま複製されるので、連携先の切り替え方はSalesforceのシステム連携とAPIコール上限の設計と合わせて決めておいてください。

SandboxPostCopyインターフェースで更新後の初期設定を自動化するApex

更新のたびに手で直す項目は、SandboxPostCopyインターフェースを実装したApexクラスにまとめられます。Sandboxの作成時と更新時に後処理クラスとして指定すると、複製が終わった直後にSalesforceがrunApexClassを呼び出します。次の例は、外部連携の接続先を持つカスタム設定（組織の既定値）を、検証用の値へ書き換えるものです。

global class SandboxSetup implements SandboxPostCopy {
    global void runApexClass(SandboxContext context) {
        // 外部連携の接続先を検証環境に向け、どのSandboxかを記録する
        Integration_Setting__c s = Integration_Setting__c.getOrgDefaults();
        s.Endpoint__c = 'https://stg.example.com/api';
        s.Sandbox_Name__c = context.sandboxName();
        upsert s;
    }
}

@isTest
private class SandboxSetupTest {
    @isTest
    static void rewritesEndpointAfterCopy() {
        Test.testSandboxPostCopyScript(
            new SandboxSetup(), UserInfo.getOrganizationId(),
            UserInfo.getOrganizationId(), 'dev1');
        System.assertEquals('dev1', Integration_Setting__c.getOrgDefaults().Sandbox_Name__c);
    }
}

Integration_Setting__cと2つの項目は説明用のカスタム設定です。SandboxContextからはorganizationId()・sandboxId()・sandboxName()を取れるため、Sandbox名で処理を分けることもできます。このクラスは本番組織に置いておく必要があり、本番へのデプロイにはテストクラスとコードカバレッジが要ります。Apexのテストとガバナ制限はApexの言語仕様とガバナ制限の解説を参照してください。

定義ファイルのapexClassNameで後処理クラスを指定して更新するコマンド

先ほどの定義ファイルにapexClassNameを書いておけば、作成時も更新時も同じ後処理が走ります。更新を次の1行に固定すると、メール設定と接続先の戻し忘れが手順から消えます。

# 定義ファイルの条件（後処理クラス SandboxSetup を含む）でdev1を更新する
sf org refresh sandbox --name dev1 --definition-file config/dev1-sandbox-def.json --target-org prodOrg --wait 30

メールの到達性のような設定画面の項目は、更新後の確認手順に残します。後処理クラスはデータとカスタム設定の書き換えに絞ると役割がはっきりします。

本番データを持たない開発用Sandboxへ検証データを用意する方法

DeveloperとDeveloper Proは本番のレコードを1件も持たずに始まります。設定の検証には十分ですが、画面の表示件数や一括処理の動作を確かめるには、検証用のレコードを別途入れる必要があります。

Data Mask & Seedで個人情報を匿名化し検証データを投入できる範囲

Salesforceは検証データ用にData Mask & Seedを提供しています。公式ページによると、個人情報の項目は匿名化・仮名化・パターン一致・削除の4方式で置き換えられ、Seed Templateを使ってDeveloper・Developer Pro・Partial・Fullの各Sandboxへ検証に使うレコードを投入することが可能です。ジョブは日次・週次・月次で定期実行でき、データ分類でPIIと指定した項目だけを対象に絞ることもできます。

価格は公式ページに記載がなく、契約内容によって変わります。Fullは本番の全レコードと権限設定を複製するため、個人情報を抱えた組織がもう一つ増えると考えてください。外部の開発者がSandboxに入る前提なら、マスキングの手段と、入れるユーザー・案件後に削除する時期を先に決めてから種別を選びます。

Sandboxを増やさず運用で済ませる判断とFullを用意すべき案件の条件

種別を上げれば検証の精度は上がりますが、容量の大きいSandboxほど作り直しに時間がかかり、追加の契約費用も発生します。足りない理由が種別なのか運用なのかを切り分けてから増やすべきです。

Developer一つで足りる体制とPartial Copyを追加すべき兆候

担当者が1〜2名で、改修が設定変更と小さなApexの追加に収まるなら、Developer一つと本番の二段で回ります。1日1回作り直せるので、壊したら更新して戻す運用が取れるからです。この規模でPartial CopyやFullを先に契約しても、使われないまま費用だけが積み上がります。

Partial Copyを追加すべき兆候は、検証のたびにテストレコードを手で作っている時間が開発時間を上回り始めたときと、利用部門の受け入れテストを本番に近いデータで行う必要が出たときです。前者はData Mask & Seedで解消できる場合があるため、先にそちらの費用と比べてください。

Full Sandboxの費用に見合う案件と契約を見送ってよい場面

Fullが必要になるのは、本番と同じデータ量で処理時間を測る性能試験と、他システムからのデータ移行を本番前に通しで試すリハーサルの2つです。数十万件規模のバッチ処理や移行を含む案件では、Fullなしで本番に入ると、処理時間とガバナ制限の超過を本番で初めて知ることになります。

逆に、画面と入力規則とFlowの改修が中心で、データ量に依存する処理が無い案件ではFullを見送って構いません。29日の更新間隔があるため、Fullはリリース直前に取り直す運用も組めません。Sandboxの種別と更新日程を、開発会社への発注範囲と合わせて決めたい場合は、Salesforce導入支援サービス・Apex開発で環境設計から相談できます。製品そのものの機能と料金体系はSalesforceの機能と料金の解説にまとめています。

よくある質問

Salesforce Sandboxのログインと種別選びについて、検索の多い質問に答えます。

Salesforce Sandboxにログインできないときはどこを確認しますか？

まず入口がtest.salesforce.comかMy DomainのSandbox URLになっているかを確かめます。login.salesforce.comからはSandboxに入れません。次にユーザー名の末尾にピリオドとSandbox名が付いているかを見ます。パスワードは作成時点か最後の更新時点の本番のものなので、その後に本番で変えたパスワードは反映されていません。SSOを組んでいる組織では、汎用の入口ではなくMy DomainのSandbox URLから入ってください。

test.salesforce.comとlogin.salesforce.comの違いは何ですか？

test.salesforce.comはSandbox用、login.salesforce.comは本番組織とDeveloper Edition用の入口です。同じ人でも本番とSandboxではユーザー名が異なるため、入口を取り違えるとユーザー名かパスワードの誤りとして扱われます。CLIではsf org login webの--instance-urlで入口を指定し、省略するとlogin.salesforce.comが開きます。

Sandboxの作成や更新にはどれくらい時間がかかりますか？

複製するデータ量で大きく変わり、メタデータだけのDeveloperは短く、本番の全件を持つFullは長くかかります。所要時間を事前に保証する仕組みは無いので、Fullの更新は利用部門の受け入れテストと重ならない日程に置いてください。

Developer EditionとDeveloper Sandboxは何が違いますか？

Developer Editionは無料で取得できる独立した組織で、自社の本番組織とは関係がありません。Developer Sandboxは自社の本番組織から複製するため、本番のカスタムオブジェクトや権限設定がそのまま入っています。学習や製品の試用にはDeveloper Edition、自社の業務に合わせた開発にはDeveloper Sandboxと使い分けます。

Sandboxとスクラッチ組織はどう使い分けますか？

スクラッチ組織は、Dev Hubを有効にした組織からソースと定義ファイルで組み立てる短期間の組織で、有効期限が来ると消えます。本番の設定を複製しないため、パッケージ開発のように、本番に依存しない部品を作る場面が主な用途です。既存の本番組織の設定を前提に改修するなら、Sandboxの方が手戻りは少なくなります。