14日。
リフレッシュで取り直したサンドボックスは、この日数のうちに有効化しないと削除されます。
しかも、一度申請したリフレッシュは取り消せません。
NetSuiteのサンドボックスとは、本番のデータと設定をコピーした、有償のテスト環境です。
本番に影響を与えずに、設定の変更やカスタマイズを試せます。
ただ、すべての会社にサンドボックスが要るわけではありません。
カスタマイズや連携が多い会社には、事故を防ぐ保険として価値があります。
年2回の更新の検証だけなら、リリースプレビューで足りることもあります。
では、自社はどちらの側か。
そして、持つと決めたなら、冒頭の14日のような決まりをどう運用に落とすのか。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットが、Oracleの公式ヘルプで確かめた事実をもとに答えます。
この記事で分かること
- サンドボックス・リリースプレビュー・開発アカウントの違い
- リフレッシュ（本番からの取り直し）で注意すること
- サンドボックスが要る会社、要らない会社の条件
- 運用でよくある3つの失敗と、その避け方
言葉の整理：本番環境は、実際に日々の業務が動いているNetSuiteの環境です。リフレッシュは、本番の最新の状態をサンドボックスにコピーし直すことです。
NetSuiteのサンドボックスとは
「サンドボックス」は英語で「砂場」の意味です。
砂場で山を作って崩しても、本物の建物には影響しません。
同じように、本番に影響を与えずに試せる場所です。
Oracleのヘルプでは、サンドボックスを次のように説明しています。
（出典：Oracle NetSuite公式ヘルプ「The Sandbox Account」、2026年9月確認）
- 本番から切り離された安全な環境で、新しい手順やアプリを作れる
- データは本番のコピー
- 本番のデータに影響せず、連携や手順の試験、社員の研修ができる
- 本番からリフレッシュでき、そのたびに前のサンドボックスは上書きされる
- 1つだけでなく、複数を購入することもできる
NetSuiteは、会計・販売・在庫・購買が1つにつながった基幹システムです。
ある画面の設定の変更が、別の業務に響くことがあります。
本番で試して不具合が出れば、業務そのものが止まりかねません。
サンドボックスで試してから、本番に反映する。
この順番が、安定した運用の土台です。
3つの環境の違い｜サンドボックス・リリースプレビュー・開発アカウント
NetSuiteには、本番のほかに試すための環境がいくつかあります。
混同しやすいので、役割を並べます。
| 観点 | サンドボックス | リリースプレビュー | 開発アカウント |
|---|---|---|---|
| 主な目的 | 本番のデータで、業務を端から端まで試す | 次の版で、今の業務が動くか見る | 新しい機能やカスタマイズを単体で作り、試す |
| データ | 本番のコピー | 本番のコピー＋次の版 | テスト用のデータだけ |
| 使える期間 | 契約している間 | 本番の更新日まで | 契約している間 |
| 費用 | 有償のオプション | 本番があれば申請で使える | 契約の内容で確認 |
| 向く場面 | 大きな設定変更、連携の試験、研修 | 年2回の更新の前 | 開発の初めから終わりまで |
（出典：Oracle NetSuite公式ヘルプ「NetSuite Sandbox FAQ」ほか、2026年9月確認）
Oracleのヘルプでは、サンドボックスは本番のデータで通しの試験をする場とされています。
開発アカウントは、テスト用のデータだけで単体の試験をする場です。
新しい開発のプロジェクトは、開発アカウントで始めるのがよいとも案内しています。
（出典：Oracle NetSuite公式ヘルプ「NetSuite Development Accounts」、2026年9月確認）
3つは、競合しません。
開発アカウントで作り、サンドボックスで通しで試し、年2回の更新の前にはリリースプレビューで確かめる。
変更は、この順に本番へ近づけていきます。
サンドボックスは、1つだけでも、複数でも購入できます。
有効なライセンスがあれば、リフレッシュは必要なときに依頼できます。
（出典：Oracle NetSuite公式ヘルプ「The Sandbox Account」「NetSuite Sandbox FAQ」、2026年9月確認）
いくつ、どの条件で使えるかは契約の内容で決まり、最終的な費用はOracleの営業が示します。
サンドボックスの使い方の流れ
- サンドボックスを用意する：契約にサンドボックスを加える。用意された時点の本番のコピーが作られる
- コピーで試す：新しい設定やカスタマイズを試す。実際に使う人の権限で試すのが理想
- 本番に反映する：問題がないと分かってから、本番に反映する
リフレッシュで押さえる5つの事実
サンドボックスは、用意した時点の本番のコピーです。
時間がたつほど本番とずれるため、リフレッシュで取り直します。
- 申請は取り消せない：一度申請したリフレッシュは止められない
- 元に戻せない：リフレッシュすると中身は本番の内容で置き換わる
- 準備中も使える：新しいコピーの準備中も、今のサンドボックスは使える
- 14日以内に有効化：準備ができたら管理者が有効化する。14日を過ぎると新しいコピーは削除され、やり直しになる（12日目に2回目の通知が届く）
- 更新日の直前は避ける：更新の開始までに終わらないと、リフレッシュは失敗する
（出典：Oracle NetSuite公式ヘルプ「Sandbox Refresh Notifications」ほか、2026年9月確認）
5つの事実を図にすると、次のとおりです。
サンドボックスで作ったものは、リフレッシュで上書きされます。
残したい設定やスクリプトは、有効化の前に外に保存しておきます。
更新日の前のリフレッシュの目安
Oracleのヘルプには、リフレッシュに約2日かかる会社を例にした判断が示されています。
| 更新日までの残り | 判断の例 |
|---|---|
| 3日（72時間） | 本番とサンドボックスの更新が終わるまで見送る |
| 1週間 | 進めてもよい場合がある |
（出典：Oracle NetSuite公式ヘルプ「Scheduled Version Upgrade Dates…」、2026年9月確認）
自社のリフレッシュに何日かかるかを、一度記録しておくと判断が早くなります。
コピーされないもの
リフレッシュしても、本番からコピーされないものがあります。
| 分類 | コピーされないものの例 |
|---|---|
| 連携・認証 | SAMLの設定、TBA（トークンベース認証）、OAuth 2.0 |
| 履歴 | レコードのシステムノート、ワークフローの履歴とインスタンス、削除したレコード |
| その他 | Webサイトのドメイン、会社間取引の消去、キャンペーンの反応の履歴 |
（出典：Oracle NetSuite公式ヘルプ「Data That is Not Copied…」、2026年9月確認）
SAMLは、シングルサインオンに使う仕組みです。
連携の認証がコピーされないため、リフレッシュの後は連携の設定を入れ直します。
一方、スマートフォンのアプリなどを使う2要素認証は、本番とサンドボックスで共有されます。
（出典：Oracle NetSuite公式ヘルプ「NetSuite Sandbox FAQ」、2026年9月確認）
入れ直す設定を一覧にしておけば、リフレッシュの後の検証をすぐに始められます。
試し方を比べる｜どこで、どう試すか
| 試し方 | 向く会社 | 注意点 | AIとの親和性 |
|---|---|---|---|
| A. 本番で直接 | 変更がごく小さく、元に戻しやすい | 間違えると業務が止まる | 低。試した記録が残りにくい |
| B. リリースプレビューだけ | カスタマイズも連携も少ない | 常設ではないため、日ごろの変更は試せない | 中。更新ごとの確認の表をAIで整えやすい |
| C. サンドボックス＋手順書 | カスタマイズや連携が多い | 費用と、リフレッシュの運用が要る | 高。試験の手順と結果が残り、AIに確認の抜けを点検させやすい |
AIに手伝わせる場合も、本番で試すのは避けます。
AIが書いたスクリプトや設定の案は、まずサンドボックスか開発アカウントで動かします。
判断の物差し｜サンドボックスが要る会社、要らない会社
サンドボックスが要る会社
- SuiteScript（NetSuiteの開発言語）によるカスタマイズが多い
- EC・倉庫・決済など、止まると売上に響く連携がある
- 設定の変更を、月に何度も行う
- 新しく入る社員の研修を、本番のデータに近い形で行いたい
- AIに作らせたスクリプトや設定を、安全に試したい
サンドボックスがなくてもよい会社
- 標準の機能が中心で、カスタマイズがほとんどない
- 連携が少なく、止まっても手作業で補える
- 設定の変更が年に数回程度
- 年2回の更新の検証は、リリースプレビューで足りている
分かれ道を図にすると、次のとおりです。
「要らない」側の会社は、まずリリースプレビューを確実に使うことから始めます。
カスタマイズが増えてきたら、サンドボックスを検討する順番で十分です。
カスタマイズをどこまで持つかは、NetSuiteのカスタマイズ完全ガイドで扱っています。
これから選ぶ会社と、いま使っている会社
これからNetSuiteを選ぶ会社
導入の途中でも、設定を試す場所が要ります。
だから、サンドボックスを入れるかは、導入の見積もりの段階で決めておきます。
NetSuiteの費用は、ミニマム構成で月額20万円〜が出発点です。
モジュール・ユーザー数・オプションで変わり、数百万円規模になることもあります。
ベンチャーネットが支援したNetSuite導入の費用には、大きな開きがありました。
3名程度・開発なしで150万円程度、100名程度・外部システム連携の開発ありで2億円程度です。
差を広げた要因の一つが、開発の量です。
開発や連携を多く持つ会社ほど、サンドボックスを毎年の費用として見込む意味が大きくなります。
事例の詳細は、NetSuiteの料金をご覧ください。
いまNetSuiteを使っている会社
サンドボックスを持っているのに使えていない。
あるいは、持たずに本番で試している。
どちらも、見直すきっかけです。
- 持っているが使えていない：最後のリフレッシュの日を見る。数か月前なら、本番とずれている
- 持たずに本番で試している：この1年に本番で起きた設定のトラブルを数える。1件でも業務が止まったなら、検討する価値がある
- 導入したパートナーと離れた：検証の手順を誰が持っているかを確かめる
保守の相手の選び方は、NetSuiteのサポート・保守の選び方で扱っています。
よくある3つの失敗
失敗1：本番で直接いじってしまう
起きること：新しいスクリプトや設定を本番で試し、請求や在庫の数字が狂う。業務が止まる。
原因：「少しの変更だから大丈夫」という油断。試す環境を持っていない。
避け方：「サンドボックスで試してから本番へ」を決まりにします。
どの変更をどの環境で試すかを、表にして共有します。
失敗2：更新の前の動作確認を怠る
起きること：年2回の更新の後、引き継がれたカスタマイズが想定どおりに動かない。
原因：カスタマイズは更新で引き継がれますが、新しい版で同じように動くとは限りません。
リリースプレビューを使わずに、本番の更新を迎えています。
避け方：リリースプレビューで、今の業務が新しい版で動くかを試します。
14日ログインがないと削除されるため、取ったらすぐに始めます。
年2回の更新への備え方は、NetSuiteのバージョンアップへの備え方で扱っています。
失敗3：サンドボックスを持っているだけで放置する
起きること：本番とのずれが広がり、試した結果が当てにならない。更新の直前に慌ててリフレッシュし、失敗する。
原因：リフレッシュと検証の段取りを決めていない。有効化の14日の期限も知られていない。
避け方：リフレッシュの時期と担当者を決めます。
更新日の直前を避け、有効化の期限と、入れ直す設定の一覧を共有します。
ベンチャーネットならこう見る
環境を持つこと自体は、目的ではありません。
いつ・誰が・何を試すかが決まって、初めて費用に見合う価値が出ます。
ベンチャーネットは、その段取りを2つの型で組みます。
ベストプラクティスは、自社の環境で試してから入れる
Oracleは、NetSuiteの標準の使い方（ベストプラクティス）を示しています。
ただ、それがそのまま自社の業務に合うとは限りません。
ベンチャーネットは、Oracleのベストプラクティスを、お客様の環境で試してから本番に入れます。
その試す場が、サンドボックスです。
役割の分け方もはっきりさせます。
日本オラクルは、ライセンス・トレーニング・製品サポートを担います。
ベンチャーネットは、設定・カスタマイズ・アドオン開発・保守を担います。
どの変更をどの環境で試すかの段取りも、保守の中で組みます。
情報システムの担当が少ない会社でも、検証の流れを回せるようにするためです。
引き継ぎで最初に探すのは「検証の手順」
ベンチャーネットの仕事は、ゼロからの導入より、他社のあとの引き継ぎや立て直しが多くを占めます。
引き継ぎで最初に探すのは、スクリプトの中身より、検証の手順です。
前のパートナーが離れると、サンドボックスの使い方も一緒に失われがちです。
最後のリフレッシュがいつか、入れ直す設定は何か、誰が有効化するのか。
答えられる人がいなければ、そこから決め直します。
最初の打ち合わせで伺うのは、次の3つです。
- 本番で直接試している変更はないか
- 止まると売上や締めに響く連携・カスタマイズは何か
- 最後のリフレッシュはいつで、誰が段取りを持っているか
今日できること｜1時間で「変更の棚卸し」
直近3か月に行った設定の変更を、次の表に書き出してください。
| 変更の中身 | 試した場所 | 試した人 | 本番で起きたこと |
|---|---|---|---|
| （例）請求書の様式の変更 | 本番 | 経理の担当 | 1日だけ旧様式で出た |
「試した場所」が本番の行が多いほど、サンドボックスの価値は大きくなります。
サンドボックスを持っている会社は、最後のリフレッシュの日も書き添えてください。
よくある質問
Q1. サンドボックスは有償ですか
有償のオプションです。
費用は契約の内容で変わります。
具体的な金額は、Oracleの営業かパートナーにお問い合わせください。
Q2. サンドボックスとリリースプレビューはどう違いますか
サンドボックスは常設でリリースプレビューは更新の前だけの環境です。
サンドボックスは日ごろの検証や研修に使います。
リリースプレビューは、次の版で今の業務が動くかを見るために使います。
Q3. サンドボックスと開発アカウントはどう違いますか
本番のデータで通しの試験をするか・テスト用のデータで単体の試験をするかの違いです。
Oracleのヘルプでは、新しい開発のプロジェクトは開発アカウントで始めるのがよいとしています。
Q4. サンドボックスはいくつ持てますか
1つだけでなく複数を購入することもできます。
開発と試験の担当ごとに分けて持つ使い方があります。
数と条件は、契約の内容によります。
Q5. リフレッシュで気をつけることは何ですか
14日以内の有効化と更新日の直前を避けることです。
リフレッシュは取り消せず、元にも戻せません。
SAMLの設定やTBA・OAuth 2.0はコピーされないため、入れ直しが要ります。
Q6. いつサンドボックスを使うべきですか
本番に響く変更を行う前が基本です。
新しいカスタマイズやスクリプトを試すとき、大きな設定の変更、外部との連携の試験です。
AIに作らせた設定やスクリプトを試すときも同じです。
Q7. 小さな会社でもサンドボックスは要りますか
カスタマイズと連携が少なければなくても回せます。
年2回の更新は、リリースプレビューで試します。
作り込みが増えてきた時点で、改めて検討してください。
まとめ
- サンドボックスは本番のコピーで、常設の有償の環境
- リリースプレビューは更新の前だけ、開発アカウントは開発の場
- リフレッシュは取り消せず元に戻せない。有効化は14日以内
- SAML・TBA・OAuth 2.0はコピーされない。入れ直す一覧を用意する
- カスタマイズと連携が少なければ、なくても回せる
冒頭の14日の期限は、段取りが決まっていれば怖くありません。
まずは変更の棚卸しで、自社が本番で試している回数を数えてください。
もう少し詳しく知りたい方へ
「自社の検証の流れをどう組めばよいか分からない」「リリースプレビューをうまく使えていない」。
そうした段階から、ご相談をお受けしています。
コメント
コメント一覧 （1件）
[…] 詳しくはNetSuiteのサンドボックスをご覧ください。 […]