約5〜7日。
次の版を試す環境「リリースプレビュー」を申請してから、できあがるまでの日数です。
しかも、14日続けてログインしないと、その環境は消えます。
NetSuiteのバージョンアップとは、年2回のメジャーリリースで、すべての利用企業が段階的に新しい版へ更新される仕組みです。
自社で更新の作業をする必要はありません。
その代わり、新しい版で自社の業務が動くかを、更新の前に確かめる役目が残ります。
「自動で最新になるから、何もしなくていい」
そう考えた会社ほど、更新の翌月に連携の停止や帳票のずれに気づきます。
では、限られた日数で、何から確かめればよいのか。
この記事で分かること
- 年2回のリリースの仕組みと、自社の更新日の見方
- 備えの4ステップと、リリースプレビューの期限
- リリースプレビューとサンドボックスの使い分け
- 検証で見る5つの観点と、連携の認証方式（TBAからOAuth 2.0へ）の期限
- 少人数の会社が、年2回の検証を回しきる体制
言葉の整理：リリースプレビューは、次の版を当てた本番のコピーの環境です。更新の前に、自社のデータで新しい版を試せます。
古い基幹システムの保守切れにともなう移行は、基幹システムの保守切れリスクで扱っています。
NetSuiteのバージョンアップの基本
年2回のメジャーリリースと、段階的な更新
NetSuiteのメジャーリリースは年2回です。
呼び名は「2026.1」「2026.2」のように、年と通し番号で表します。
Oracleのヘルプでは、メジャーリリースのたびに、利用企業が数か月かけて段階的に更新されると説明しています。
| 更新の種類 | 中身 | 届き方 |
|---|---|---|
| メジャーリリース | 新しい機能と改善 | 年2回。数か月かけて段階的に |
| マイナーリリース | 急ぎではない不具合の修正 | 全社に同時に |
| ホットプッシュ | 次を待てない重大な不具合の修正 | 特定の会社に向けて行うことが多い |
（出典：Oracle NetSuite公式ヘルプ「Release Delivery」、2026年9月確認）
備えが要るのは、主にメジャーリリースです。
新しい版で何が変わったかは、NetSuite最新アップデートまとめで扱っています。
自社の更新日を見る
自社の更新日は、NetSuiteのホーム画面にある「New Release」の欄に出ます。
欄が見えない場合は、画面の表示の設定で追加できます。
更新の案内は、メールと画面の通知で管理者に届きます。
サンドボックスを持つ会社は、本番の更新から7日以内にサンドボックスも更新されます。
（出典：Oracle NetSuite公式ヘルプ「NetSuite Version Upgrade Maintenance」、2026年9月確認）
日時は動かせるが、版を見送る前提にはできない
Customer-Scheduled Maintenanceは、利用企業が保守の日時を選び直せる仕組みです。
Oracleのヘルプでは、この仕組みで更新の日時を変更できると案内しています。
版の更新は、本番とサンドボックスの両方が対象です。
（出典：Oracle NetSuite公式ヘルプ「Types of Customer-Scheduled Maintenance」、2026年9月確認）
一方で、動かせる幅は、確かめた範囲の公式ヘルプには書かれていませんでした。
リリースを飛ばせるという案内も見当たりません。
決算と重なるなら日時を動かす。ただし、やるべき検証は変わりません。
備えの4ステップ
| ステップ | やること | 目安の時期 |
|---|---|---|
| 1. 更新日を知る | New Releaseの欄で日付を見て、社内に共有する | 案内が届いたらすぐ |
| 2. リリースプレビューを取る | 管理者が申請（オプトイン）する | 日付が分かったら早めに |
| 3. 検証する | 業務の流れ・連携・カスタマイズ・帳票を通す | 本番の更新日まで |
| 4. 本番を迎える | 直すべき点を直し、利用者に変更点を知らせる | 更新日の前後 |
リリースプレビューについて、Oracleのヘルプで確かめられたことは次のとおりです。
- 申請は、管理者のロールを持つ人が行う
- 申請してから作成まで、約5〜7日かかる
- データは、申請後に取った本番のバックアップから作られる
- 最初に入れるのは管理者だけ。必要に応じて他の利用者に権限を渡す
- 本番の更新日に使えなくなる
- 14日続けてログインがないと、削除される
（出典：Oracle NetSuite公式ヘルプ「Overview of Release Preview」ほか、2026年9月確認）
つまずきやすいのは、日数の見積もりです。
更新日の直前に申請すると、検証の時間がほとんど残りません。
取ったらその週のうちに検証を始め、14日の放置で消さないようにします。
検証の場所｜リリースプレビューとサンドボックス
| 軸 | リリースプレビュー | サンドボックス |
|---|---|---|
| 目的 | 次のリリースの事前検証 | 常設の開発・検証・研修 |
| 中身 | 本番のコピー＋次の版 | 本番のコピー（ふだんは今の版） |
| 使える期間 | 本番の更新日まで（放置すると削除） | 契約している間 |
| 契約 | 本番のアカウントがあれば申請で使える | 別に契約するオプション |
リリースの前の検証だけなら、リリースプレビューで足りることが多いです。
日ごろからカスタマイズの開発や研修をするなら、サンドボックスが向きます。
サンドボックスを持つ会社は、更新の時期のリフレッシュ（本番からのコピーの取り直し）に注意します。
ヘルプでは、更新日が近いときのリフレッシュは避けるよう案内しています。
更新の開始までに終わらないと、失敗するためです。
（出典：Oracle NetSuite公式ヘルプ「Scheduled Version Upgrade Dates…」、2026年9月確認）
種類や使い方は、NetSuiteのサンドボックスとはで扱っています。
何を検証するか｜5つの観点と順番
何から確かめるか。止まると売上や締めに響く流れからです。
画面が開くかではなく、業務が最後まで通るかを見ます。
- 業務の流れ：受注から出荷・請求・入金まで、購買、月次の締めを一連で通す
- カスタマイズ・追加アプリ：自社で組んだスクリプト（SuiteScript）や、追加したアプリ（SuiteApp）が動くか
- 連携：EC・倉庫・決済などとの連携が止まっていないか。認証方式も見る
- レポート・帳票：いつもの数字とレイアウトにずれがないか
- 画面と操作：新しい画面のデザインなど、利用者の操作が変わる部分
画面のデザインは、リリースによって大きく変わることがあります。
新しい画面への移り方は、NetSuite Redwood UIとはをご覧ください。
連携の認証方式には、版の更新とは別の期限がある
TBA（トークンベース認証）は、外部のシステムがNetSuiteにつなぐときの認証方式の1つです。
Oracleのヘルプでは、次の段階が示されています。
| リリース | 起きること |
|---|---|
| 2026.1 | 新しい連携は、RESTとOAuth 2.0で作るよう案内 |
| 2027.1 | TBAを使う新しい連携を作れなくなる。SOAPでの新しい連携も作れなくなる |
| 2028.2（予定） | 既存のTBAの連携のサポートが終わる。SOAPのエンドポイントはすべて無効になる |
（出典：Oracle NetSuite公式ヘルプ「TBA End of Support」「SOAP Removal Plans FAQ」、2026年9月確認）
OAuth 2.0は、Oracleが切り替え先として勧めている認証方式です。
ヘルプでは、止まる対象として、自社で作ったRESTletのほか、連携の製品（iPaaS）も挙げています。
既存の連携が止まるのは、2028.2の予定です。
それでも、連携の数が多い会社ほど、切り替えには時間がかかります。
年2回の検証のついでに、どの連携がTBAを使っているかを洗い出しておきます。
期限の段階を図にすると、次のとおりです。
詳しくはNetSuite認証の「2027年問題」で扱っています。
検証のやり方を選ぶ
| やり方 | 中身 | 向く会社 | 注意点 |
|---|---|---|---|
| A. その場で確かめる | 担当者が思いつく画面と処理を見る | カスタマイズも連携もほぼない | 毎回やることが変わり、漏れが出る |
| B. チェックリスト | 業務の流れごとの確認項目を表にし、毎回同じ順で通す | 多くの中堅・中小企業 | 表の更新を誰がやるか決める |
| C. シナリオ＋記録 | シナリオと期待する結果を決め、結果を毎回残す | 連携やカスタマイズが多い | 最初の整備に手間がかかる |
多くの会社は、Bから始め、連携の多い部分だけCにするのが現実的です。
結果が表で残っていれば、次のリリースで比べる材料になります。
リリースノートと表を照らす作業をAIに手伝わせるにも、まず記録が要ります。
どこまで自社で備えるか｜判断の物差し
| 自社で回しやすい会社 | 外部と一緒に回すほうがよい会社 |
|---|---|
| 標準の機能が中心で、カスタマイズが少ない | SuiteScriptによるカスタマイズや、追加アプリが多い |
| 外部との連携が数本まで | 止まると売上に響く連携がある |
| NetSuiteの設定が分かる担当者が2人以上 | 担当者が1人、または情シスがいない |
| 検証のチェックリストがすでにある | 導入したパートナーと、今は付き合いが薄い |
カスタマイズが多いほど、リリースのたびに見る項目が増えます。
標準の機能をうまく使うほど、更新の恩恵をそのまま受けられます。
判断の軸は、NetSuiteのカスタマイズ完全ガイドで扱っています。
作り込みの量は、導入の費用にも表れます。
ベンチャーネットが支援したNetSuite導入の費用では、3名程度・開発なしの事例が150万円程度・1.5か月でした。
100名程度で外部システムとの連携開発を含めた事例は、2億円程度（うち開発約7割）・1.5年です。
差を生むのは、機能範囲・開発（特に外部連携）・社内の体制・ユーザー数の4つです。
開発と連携が多い会社ほど、年2回の検証も重くなります。
4事例の条件は、NetSuiteの料金・費用・価格に載せています。
これから選ぶ会社は、「年2回の更新と付き合えるか」も判断に入れてください。
更新の時期を自社で決めたいなら、自社で環境を持つ形のOdooや国産のERP、AIを使ったスクラッチ開発が合うこともあります。
その場合、更新と保守の手間は自社側に残ります。
どちらの手間を引き受けるかで選びます。
いま使っていて「毎回の検証がつらい」会社へ
つらさの原因は、たいてい次の3つのどれかです。
| 原因 | 手当て |
|---|---|
| 作り込みが多く、見る範囲が広すぎる | 作り込みを棚卸しし、使っていないものを検証の対象から外す |
| 検証の手順が決まっておらず、毎回ゼロから考える | 業務の流れごとのチェックリストを作る |
| 導入したパートナーと離れ、相談先がない | 保守や伴走を担う相手を見直す |
NetSuiteをやめる前に、この3つを見てください。
サポートの選び方は、NetSuiteのサポート・保守はどう選ぶ？で扱っています。
よくある3つの失敗
失敗1：自動で更新されるからと、何もしない
起きること：更新の翌日に、連携の停止や帳票のずれに気づく。月末の締めで初めて問題が出ることもある。
原因：更新の案内を見ても動かず、リリースプレビューを取っていない。
避け方：案内が届いたら、その週のうちにリリースプレビューを申請します。
作成に約1週間かかり、14日放置すると消えることを、担当者の間で共有します。
失敗2：画面が開くかだけを見て、業務の流れを通さない
起きること：各画面は問題なく開いたのに、月末の締めや請求の処理でずれが出る。
原因：画面ごとの確認で終わり、受注から入金、締めまでを一連で通していない。
避け方：業務の流れごとのチェックリストで、毎回同じ順に通します。
連携は、認証方式がTBAのままかどうかも、あわせて見ます。
失敗3：一人の担当者が片手間で回し、形だけになる
起きること：毎回時間切れで、一部しか見られない。やり方が一人しか分からない。
原因：年2回、全社に響く検証を、本業のかたわらの一人に任せている。
担当者の力の問題ではなく、頻度と範囲の広さからくる構造の問題です。
避け方：検証を「誰が・いつ・何を」の定例にし、記録を残します。
抱えきれない部分は、保守や伴走のパートナーと分けて持ちます。
ベンチャーネットならこう見る｜自社の環境で試してから入れる、定例と課題管理表で回す
新しい版の機能も、Oracleのベストプラクティスも、そのまま本番には入れません。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、自社の環境で試してから入れる順番を守ります。
年2回の検証は、この考え方をそのまま定例にしたものです。
型1：試してから入れる
- リリースプレビューで試す：止まると困る流れと連携を、自社のデータで通す
- 直してから迎える：ずれが出た作り込みや帳票は、本番の更新日までに直す
- 使える新機能は次の改善の候補にする：試した結果、手作業を減らせる機能を記録する
型2：定例と課題管理表で回す
検証を一人の頭の中に置かないために、週次の定例と課題管理表を使います。
課題管理表には、見つけたずれ、担当、期限、直した結果を書きます。
次のリリースでは、その表が最初のチェックリストになります。
役割の分け方もはっきりさせておきます。
製品そのものの不具合は、日本オラクルの製品サポートに問い合わせます。
設定・作り込み・連携の直しと、検証の段取りは、保守を担うパートナーの仕事です。
ベンチャーネットの場合は、国内のチームがリモートで担います。
最初の打ち合わせで伺うのは、次の3つです。
- 更新日と、決算や繁忙期は重なっていないか
- 止まると売上や出荷に響く連携はどれか。認証方式は何か
- 前回の検証の記録は残っているか
年2回の検証は、まず「守り」です。
業務を止めずに新しい版を迎えることが、最初の目的になります。
記録がたまると、新しい機能で手作業を減らす「攻め」の材料に変わります。
今日できること｜1時間で「検証の地図」を作る
次の表を、表計算で作ってみてください。
| 業務の流れ | 使っている画面・帳票 | 外部のシステム・作り込み | 止まったときの影響 |
|---|---|---|---|
| （例）受注→出荷 | 受注、出荷、納品書 | EC、倉庫、受注の取込のスクリプト | 出荷が止まる |
受注・出荷・請求・入金・購買・月次の締めの6行を埋めれば十分です。
「止まったときの影響」が大きい行から、検証の順番を決めます。
外部のシステムの欄は、そのまま認証方式の洗い出しの一覧になります。
最後に、New Releaseの欄で次の更新日を見て、カレンダーに入れてください。
よくある質問
Q1. リリースプレビューはいつから使えますか
本番の更新の前に管理者が申請して使います。
申請から作成まで約5〜7日かかり、本番の更新日に使えなくなります。
14日続けてログインがないと削除されるため、取ったらすぐに検証を始めます。
Q2. 自社だけ更新を止めることはできますか
日時は変えられますが版を見送る前提にはできません。
Customer-Scheduled Maintenanceで、本番とサンドボックスの更新の日時を変更できます。
動かせる幅は、自社のアカウントの画面かOracleに確かめてください。
Q3. サンドボックスとリリースプレビューは、どう違いますか
リリースプレビューは一時的な試験の場でサンドボックスは常設の作業場です。
リリース前の検証だけならリリースプレビューで足りることが多いです。
日ごろの開発や研修にはサンドボックスが向きます。
Q4. サンドボックスも一緒に更新されますか
本番の更新から7日以内に更新されると案内されています。
更新日が近いときのリフレッシュは、失敗するおそれがあるため避けます。
Q5. 検証せずに更新を迎えると、どうなりますか
連携の停止や帳票のずれが本番で初めて見つかるおそれがあります。
月末や決算の時期に表に出ることもあります。
Oracleのヘルプでも、リリースプレビューの目的は業務の流れを試して問題を防ぐことだと説明しています。
Q6. 連携の認証方式は、いつまでに変える必要がありますか
2027.1で新しいTBAの連携が作れなくなり2028.2で既存の連携のサポートが終わる予定です。
既存の連携はすぐには止まりません。
ただ、連携が多い会社ほど時間がかかるため、早めの洗い出しをお勧めします。
Q7. 情シスがいない会社でも、年2回の検証は回せますか
範囲を絞って外部と分けて持てば回せます。
チェックリストを作り、止まると困る流れから確かめます。
一人で抱えきれない部分は、保守や伴走のパートナーに任せる形があります。
まとめ｜年2回を「リスク」から「改善の機会」に
- NetSuiteは年2回、全社が数か月かけて段階的に新しい版へ更新される
- 更新の日時は変えられるが、版を見送る前提にはできない
- リリースプレビューは作成に約5〜7日。14日放置すると消える
- 検証は画面ではなく、止まると困る業務の流れから通す
- 連携は、認証方式（TBA）の期限も一緒に見る
- 検証は定例にし、課題管理表で記録を残す
約5〜7日と14日。
この2つの数字を知っていれば、次の更新の準備は案内が届いた週に始められます。
まずはNew Releaseの欄で、次の更新日を見てください。
もう少し詳しく知りたい方へ
「次のリリースで何から手をつければよいか分からない」という段階から、ご相談をお受けしています。
検証の範囲の洗い出し、チェックリストづくり、連携の認証方式の点検まで、状況に合わせてお手伝いします。
コメント
コメント一覧 （1件）
[…] 更新の仕組みと、そのたびに何を見るかは、NetSuiteのバージョンアップへの備え方で解説しています。 […]