作業のために確保される時間は4時間。
ところが、多くは60分以内に終わります（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
それでも、アップグレードのたびに慌てる会社は少なくありません。
NetSuiteのアップグレードとは、年に2回提供される新しいバージョンに、アカウントが順番に切り替わることです。
断ることはできません。
毎回焦るのは、作業が難しいからではなく、手順が決まっていないからです。
「気づいたら来週だった」
「リリースノートが長すぎて、どこを読めばいいか分からない」
「前回どうやって確認したか、誰も覚えていない」
どれも、予定日から逆算した手順を一度決めれば防げます。
では、何週間前に、誰が、何をすればよいのか。
事実はOracleの公式ヘルプから取りました。
段取りの区切り方は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットの推奨です。
この記事で分かること
- アップグレードについて、押さえておくべき公式の事実
- リリースノートを「全部読まない」読み方
- 予定日の3週間前から当日後までの手順
- よくある3つの失敗と、その避け方
- AIに任せられる作業と、人が決める作業
まず押さえておきたい、アップグレードの事実
年2回、全員に順番にやってくる
バージョンは「2026.1」「2026.2」のように、年と上期・下期で呼ばれます。
仕組みの全体像は、NetSuiteのバージョンアップ（年2回リリース）への備え方で解説しています。
あちらは「仕組みと、何を検証するか」の記事です。
こちらは「毎回、いつ・誰が・何をするか」という運用の手順を扱います。
公式の説明で分かっていること
Oracleの公式ヘルプには、次のことが書かれています。
| 項目 | 公式の説明 |
|---|---|
| 予定日の確認場所 | ホーム画面の「New Release」ポートレットで確認する |
| 通知 | 自動のメールとアカウント内の通知が、管理者に送られる |
| 作業時間 | 4時間が確保されているが、多くは60分以内に終わる |
| サンドボックス | 本番のアップグレード後、7日以内にアップグレードされる |
| 日程の変更 | サービスの契約の種類にかかわらず、「Customer-Scheduled Maintenance」の画面で変更できる |
| 事前の確認 | リリースプレビューを申し込み、重要な業務を新しいバージョンで試すことが勧められている |
サンドボックスは、本番の設定やデータをコピーした、常設のテスト環境です。
詳しくはNetSuiteのサンドボックスとはをご覧ください。
通知は「管理者」にしか届かない
見落とされやすいのが、通知の宛先です。
予定日の通知は、管理者の役割を持つ人に届きます。
管理者が1人で、しかも兼務なら、通知は埋もれがちです。
「気づいたら来週だった」の多くは、ここから始まります。
最初に決めるのは、通知を受けた人が誰に何を渡すかです。
毎回焦る会社と、焦らない会社の違い
同じNetSuiteでも、アップグレードの迎え方は会社によって大きく違います。
| 観点 | 毎回焦る会社 | 焦らない会社 |
|---|---|---|
| 予定日の把握 | 通知に気づいた人だけが知っている | 社内の予定表に入っている |
| リリースノート | 全部読もうとして、読み切れない | 自社に関係する分類だけ読む |
| テスト | その都度、思いついた操作をする | 前回のテスト表を使い回す |
| 担当 | 管理者が1人で抱える | 業務ごとにテストする人が決まっている |
| 記録 | 残っていない | 次回に引き継ぐメモがある |
| AIとの親和性 | 低い（毎回ゼロから考え、AIに渡す材料がない） | 高い（前回のテスト表と影響表を、AIの下書きの材料にできる） |
右の列の会社は、特別な技術を持っているわけではありません。
同じ手順を、毎回くり返しているだけです。
年2回だからこそ、手順を型にする価値があります。
リリースノートは「全部読まない」
リリースノートとは
リリースノートは、新しいバージョンで何が追加され、何が変わるかをまとめた公式の文書です。
NetSuiteのヘルプセンターで公開されています。
たとえば2026.2のリリースノートは、20を超える分類に分かれています。
会計、在庫、製造、連携、認証など、分野ごとの見出しがあります。
すべてを読む必要はありません。
読む前に知っておきたい3つの注意
公式のリリースノートには、次の注意書きがあります。
- 毎週変わることがある：一度読んで終わりにせず、直前にもう一度読む
- アップグレードされるまで使えない：新しい機能は、自社のアカウントが切り替わってから使える
- 契約によっては使えない機能もある：追加の購入が必要な機能も含まれる
とくに1つ目は見落とせません。
早めに読んだ内容が、直前に変わっていることがあるからです。
3つのステップで読む
ベンチャーネットは、次の3つのステップで読むことをおすすめしています。
ステップ1：自社に関係する分類だけを選ぶ
使っている機能に関係する分類だけに印をつけます。
使っていない機能の分類は、読み飛ばして構いません。
ステップ2：「増える」と「変わる」を分ける
新しく増える機能は、あとで試せば間に合います。
急ぐのは、いまの動きが変わるものです。
認証、連携、全体の告知（General Notices）の分類は、毎回必ず目を通します。
ステップ3：影響を1枚の表に落とす
読んだ結果を、次のような表にまとめます。
| 分類 | 変わること（要約） | 自社への影響 | 担当・テスト |
|---|---|---|---|
| 例：認証 | 連携の認証方式の変更 | 外部の連携に影響あり | 連携の担当者・試す |
| 例：在庫 | 画面の項目の追加 | 影響は小さい | 在庫の担当者・試さない |
この表が、次の章のテストの出発点です。
そして、次回のアップグレードで最初に開く資料にもなります。
3つのステップを図にすると、次のとおりです。
予定日から逆算する手順（3週間前〜当日後）
区切りは、ベンチャーネットの推奨
「3週間前・2週間前・1週間前」という区切りは、Oracleの決まりではありません。
公式の説明にある所要日数や注意点をもとに、ベンチャーネットが無理のない段取りとして組んだものです。
予定日が3週間を切ってから分かった場合は、テストの範囲を絞り、同じ順番で進めます。
全体の流れ
| 時期 | やること | 根拠になる公式の説明 |
|---|---|---|
| 予定日が分かったら | 予定日を社内の予定表に入れ、担当を決める | 予定日はNew Releaseポートレットで確認 |
| 3週間前 | リリースプレビューを申し込む。リリースノートの影響表をつくる | 作成に5〜7日ほどかかる |
| 2週間前 | リリースプレビューでテストする | 14日間ログインがないと削除される |
| 1週間前 | 結果を判定し、関係者に知らせる。必要なら日程を変更する | 日程は専用の画面で変更できる |
| 前日〜当日 | 定期的に動く処理を止め、終わったら戻す | 本番の切り替え前に止め、完了後に戻すよう案内されている |
| 当日後 | 主要な業務を通し、記録を残す | 完了は管理者にメールで通知される |
予定日が分かったら：予定表に入れ、担当を決める
最初の作業は、とても地味です。
予定日を社内の予定表に入れること。
あわせて、次の2つを決めます。
- リリースノートを読む人
- 業務ごとにテストする人（会計、販売、在庫など）
前回のテスト表と影響表があれば、ここで取り出しておきます。
3週間前：リリースプレビューを申し込む
リリースプレビューは、次のバージョンを本番より先に試せる、期間限定のテスト用アカウントです。
年に2回、各リリースの直前に提供されます。
公式の説明は、次のとおりです。
- 管理者が「設定 ＞ 会社 ＞ リリースプレビュー」から申し込む
- 申し込んでから、作成まで5〜7日ほどかかる
- 本番のデータのバックアップをもとに作られる
- サンドボックスから申し込めば、そのサンドボックスをもとに作れる
- リリースプレビューで行った操作は、本番には影響しない
作成に1週間近くかかります。
3週間前に申し込めば、2週間前からテストに入れる計算です。
この時期に、もう1つ決めておく設定があります。
テスト環境からのメールの送り先です。
サンドボックスとリリースプレビューのメールは、次の3つから選べます。
| 設定 | 内容 |
|---|---|
| 指定した宛先に送る | 決めたアドレスにだけ届く（テストでの利用が勧められている） |
| ログイン中の人に送る | 操作している人に届く（例外あり） |
| 送らない | メールを送らない |
パスワードの再設定など、安全に関わるメールは、この設定にかかわらず本人に届きます。
2週間前：リリースプレビューでテストする
公式の説明では、リリースプレビューの目的は新機能を試すことではありません。
自社のふだんの業務が、問題なく動くかを見ることです。
Oracleは、テスト計画のひな形（Excel）も公開しています。
前回のテスト表がない会社は、ここから始めると手間が省けます。
テストで気をつけたい点を、公式の説明からまとめます。
| 気をつけること | 公式の説明 |
|---|---|
| 放置すると消える | 14日間続けてログインがないと、削除される |
| 保存検索は止まっている | 自動のメールを減らすため、初期状態では無効になっている |
| 連携の鍵はコピーされない | トークン認証を試すには、リリースプレビューで作り直す必要がある |
| コピーされないものがある | システムノート、ワークフローの履歴、顧客センターの役割など |
| 動きが遅いことがある | 最初の数回は遅く、くり返すと速くなる |
トークン認証は、外部のシステムがNetSuiteに接続するときに使う「鍵」の仕組みの一つです。
連携をテストするなら、鍵の作り直しを段取りに入れておきます。
何を検証するかの観点は、バージョンアップへの備え方の「何を検証すべきか」にまとめています。
1週間前：判定し、知らせる
テストの結果から、次のどれかを判定します。
- 問題なし：予定どおり進める
- 回避策あり：当日までに手順を変える
- 問題あり：NetSuiteのサポートに報告する
判定の結果は、テストしなかった部署にも短く知らせます。
「当日は数時間止まる可能性がある」「この画面の項目が変わる」程度で十分です。
予定日がどうしても合わないなら、日程を変える方法があります。
管理者などの権限を持つ人が、「Customer-Scheduled Maintenance」の画面で変更します。
画面で選べない日にしたい場合は、所定の期限までに、理由を添えてサポートへ依頼します。
サンドボックスの更新（本番からのコピーのし直し）は、予定日の近くでは避けます。
アップグレードの開始までに終わらないと、更新は失敗するとされているからです。
予定日まで72時間を切っていれば、アップグレードが終わるまで待つよう案内されています。
前日〜当日：定期的に動く処理を止め、戻す
本番で定期的に動く処理は、アップグレードの前に止めるよう案内されています。
そして、終わったら再び動かします。
止める処理は、3週間前の時点で一覧にしておきます。
当日に慌てて探すと、漏れが出ます。
当日後：業務を通し、記録を残す
アップグレードが終わると、管理者にメールで通知が届きます。
その後にやることは4つです。
- 止めていた処理が再開しているかを見る
- 主要な業務（受注、請求、入金など）を1件ずつ通してみる
- 7日以内に切り替わるサンドボックスで、開発中のものが動くかを試す
- 気づいたことを、影響表とテスト表に書き足す
最後の記録が、次回の3週間前の作業を大きく減らします。
3週間前チェックリスト
3週間前にやることを、1枚にまとめました。
| # | 確認すること | 担当 |
|---|---|---|
| 1 | 予定日を社内の予定表に入れたか | 管理者 |
| 2 | リリースプレビューを申し込んだか | 管理者 |
| 3 | テスト環境のメールの送り先を設定したか | 管理者 |
| 4 | リリースノートの影響表をつくり始めたか | リリースノートを読む人 |
| 5 | 業務ごとのテスト担当を決めたか | 各部署の責任者 |
| 6 | 前回のテスト表を取り出したか | 管理者 |
| 7 | 外部の連携の一覧と、鍵の作り直しの段取りはあるか | 連携の担当者 |
| 8 | 当日に止める定期処理の一覧をつくったか | 管理者 |
8項目すべてに「はい」と言えれば、残りの手順はほぼ決まった流れで進みます。
2027.1は、とくに「認証」の分類を見る
どの分類が重要かは、回ごとに変わります。
2027.1では、認証の分類がとくに重要になります。
NetSuite認証の「2027年問題」で解説しているとおり、2027.1では外部との連携の認証方式に大きな変更が予定されています。
認証の変更は、画面の変化と違って目に見えません。
連携が静かに止まり、気づくのは業務が動かなくなってから、ということも起こりえます。
2027.1では、チェックリストの7番をいつも以上に丁寧に行ってください。
そもそも移行が必要かどうかは、アップグレードの時期より前に判断しておく必要があります。
画面や使い方の大きな変化も、リリースごとに届きます。
新しい画面やAIの機能は、NetSuite Nextとはで扱っています。
AIに任せられること、人が決めること
リリースノートの読み込みやテスト表の作成は、生成AI（文章や表を自動でつくるAI）と相性のよい作業です。
| 作業 | AIに任せやすいこと | 人が行うこと |
|---|---|---|
| リリースノート | 選んだ分類の要約、日本語での下書き | 自社に関係するかの判断 |
| 影響表 | 前回の表と今回の要約を並べた下書き | 影響の大きさの判定 |
| テスト表 | 前回の表をもとにした手順の下書き | 実際の操作と、結果の判定 |
| 社内への周知 | 知らせる文面の下書き | 誰に何を知らせるかの判断 |
| 記録 | テスト結果のまとめ | 次回に残すことの選別 |
リリースノートは英語が中心です。
AIに要約させると、読む時間は短くなります。
ただし、要約は原文と照らし合わせてから使います。
認証や連携の分類は、言葉一つの違いで意味が変わるからです。
リリースノートは毎週変わることもあるため、直前にもう一度原文を読みます。
スクリプトの一覧から確認表を下書きさせる
年2回、確認する項目を毎回ゼロから洗い出す。
この手間は、AIに下書きを任せると減らせます。
渡すのは、自社のスクリプト（独自に追加した処理）の一覧です。
気をつけたい点が1つあります。
予定スクリプト（決まった時刻に動く処理）は、リリースプレビューでは自動で実行されません（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
この注意を、頼み方に入れておきます。
頼み方の例です。
「このスクリプト一覧から、リリースプレビューでの確認表を作ってください。予定スクリプトは自動実行されないので手動で試す、という注意も入れてください」
3本のスクリプトを渡した結果は、次のとおりです（サンプルは架空です）。
| スクリプトの中身 | 種類 | 確認のしかた | 注意 |
|---|---|---|---|
| 請求書の保存時に税区分を点検 | ユーザーイベント | レコードを保存して動きを見る | 保存時の処理を見る |
| 毎朝、売掛残高をメールで送る | 予定 | デプロイの画面から手動で実行し、結果を見る | 予定どおりには実行されない |
| 受注の入力時に単価を点検 | クライアント | 受注の画面で入力して動きを見る | 画面の操作で見る |
表に載るのは、渡した一覧にあるものだけです。
漏れているカスタマイズがないかは、担当者が一覧と照らし合わせます。
AIは下書きまで。確認の結果を判定するのは人です。
この表は、第4章の2週間前のテストでそのまま使えます。
よくある3つの失敗
3つの失敗と避け方を図にすると、次のとおりです。
失敗①：リリースプレビューが、使わないうちに消えた
現象
早めに申し込み、アカウントもできた。
けれども忙しくて、誰もログインしないまま日が過ぎます。
テストしようとしたときには、もう使えなくなっていました。
原因
リリースプレビューは、14日間続けてログインがないと削除されます。
申し込む日だけ決めて、テストする日を決めていなかったのです。
回避
申し込むときに、テストの日も予定表に入れます。
担当者が複数いるなら、少なくとも週に1回は誰かがログインするよう決めておきます。
失敗②：取引先にメールが届く心配で、手が止まる
現象
請求書の送付や承認のテストに入ったところで、手が止まる。
「取引先にメールが届いてしまわないか」という不安が消えないからです。
結局、メールが絡む業務はテストされないまま当日を迎えます。
原因
テスト環境のメールの送り先を、確かめていなかったことです。
設定が分からないと、試すこと自体が怖くなります。
回避
3週間前に、送り先を「指定した宛先に送る」などに設定しておきます。
テストの担当者には、どこにメールが届くかを伝えます。
安全に関わるメールは設定にかかわらず本人に届くことも、あわせて伝えます。
失敗③：止めた処理を、再開し忘れる
現象
アップグレードは無事に終わった。
ところが数日後、「毎晩の連携データが届いていない」と気づきます。
当日に止めた定期処理が、止まったままでした。
原因
止める作業だけが手順にあり、戻す作業が手順になかったのです。
無事に終わった安心感で、確認が抜けました。
回避
止める処理の一覧に、「再開した人・再開した時刻」の欄をつくります。
当日後の最初の項目を、「止めた処理が全部動いているか」にします。
この手順が向く会社、簡単でよい会社
手順を型にしたほうがよい会社
- 外部のシステムとの連携がある
- 独自の画面や処理（カスタマイズ）を追加している
- 管理者が1人で、兼務している
こうした会社ほど、アップグレードの影響を受けやすく、準備が属人化しやすいからです。
簡単な手順でよい会社（やらない選択肢）
標準の機能だけを使い、外部の連携もない会社もあります。
その場合、ここまでの手順をすべて行う必要はありません。
- 予定日を予定表に入れる
- リリースノートの全体の告知だけを読む
- 当日後に主要な業務を1件ずつ通す
この3つだけでも、「気づいたら来週だった」は防げます。
手順の重さは、自社の使い方に合わせて調整してください。
ベンチャーネットならこう見る
「自社の環境で検証してから入れる」をリリースごとに回す
ベンチャーネットは、Oracleのベストプラクティスも、自社の環境で検証してから入れる進め方をとっています。
リリースごとの新機能も同じです。
リリースノートに載ったからといって、すぐ本番で使い始めることはしません。
- 影響表で「変わる」と判定したもの → リリースプレビューで、いまの業務が動くかを試す
- 「増える」と判定した新機能 → 切り替え後にサンドボックスで試し、使うかどうかを決める
- 使わないと決めた新機能 → 理由を影響表に書き、次回にもう一度見る
役割の分け方も、はっきりさせておきます。
製品そのものの不具合は、日本オラクルの製品サポートが受け持ちます。
自社の設定・カスタマイズ・連携への影響を調べて直すのは、保守を担うパートナーの仕事です。
テストで「問題あり」が出たときに、どちらへ連絡するかを先に決めておくと、1週間前の判定で迷いません。
アップグレードを「守り→攻め→次へ」の点検に使う
稼働後のNetSuiteを、ベンチャーネットは3段で見ています。
業務が回る「守り」、データで打つ「攻め」、経営が変わる「次へ」です。
この記事の手順の大半は、守りの仕事です。
いまの業務を止めないこと。
ただ、影響表の「増える」の欄には、攻めや次への材料も並びます。
年2回、影響表を開くたびに「この新機能で、次の段に進めないか」を1行だけ書き足す。
それだけで、アップグレードは負担から点検の機会に変わります。
よくある質問
Q1. アップグレードを断ったり、先送りしたりできますか
断ることはできません。
全員のアカウントが順番に切り替わります。
ただし、日程は「Customer-Scheduled Maintenance」の画面から変更できます。
変えられるのは日程であって、アップグレードそのものは避けられません。
Q2. リリースプレビューは有料ですか
バージョンアップへの備え方で解説しているとおり、追加の費用なく利用できます。
申し込みは、管理者の役割を持つ人が行います。
Q3. リリースノートは英語しかありませんか
NetSuiteのヘルプセンターには、翻訳版のリリースノートも用意されています。
ただし、英語版は毎週変わることがあります。
重要な分類は、英語版の最新の内容も読むのが安全です。
要約にはAIも使えますが、原文と照らし合わせてから使ってください。
Q4. サンドボックスがあれば、リリースプレビューは不要ですか
役割が違います。
サンドボックスは、いまのバージョンで開発やテストをする常設の環境です。
リリースプレビューは、次のバージョンを先に試すための期間限定の環境です。
次のバージョンでの動きを見るには、リリースプレビューを使います。
Q5. アップグレード中は、どのくらい使えなくなりますか
公式の説明では、作業のために4時間が確保されています。
ただし、多くは60分以内に終わるとされています。
止まる可能性がある時間帯は、事前に社内へ知らせておきます。
Q6. リリースプレビューの確認表はAIで作れますか
スクリプトの一覧を渡せば、下書きは作れます。
予定スクリプトは自動で実行されないため、手動で試す注意も頼み方に入れます。
漏れの確認と結果の判定は人が行います（第7章）。
まとめ
- アップグレードは年2回、止められない。毎回焦るのは手順が決まっていないから
- 予定日の通知は管理者に届く。最初に決めるのは、通知を受けた人が誰に何を渡すか
- リリースノートは全部読まない。関係する分類だけを選び、影響表に落とす
- 3週間前にリリースプレビューを申し込み、2週間前からテスト、1週間前に判定する
- 定期処理は止めるだけでなく、戻すところまでを手順にする
- 記録を残せば、次回の準備は軽くなる
4時間の枠に、60分の作業。
慌てる理由は、作業の中ではなく、その前の3週間にあります。
次の予定日を「New Release」ポートレットで開き、まず社内の予定表に入れてください。
同じ手順をくり返せる会社にとって、年2回の新しいバージョンは、NetSuiteを使い続ける理由の一つになります。
出典（2026年9月23日確認）
- Oracle NetSuite Help Center「NetSuite Version Upgrade Maintenance」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_1120120832.html
- Oracle NetSuite Help Center「Overview of Release Preview」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4471776042.html
- Oracle NetSuite Help Center「The Release Preview Account」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/subsect_1121105228.html
- Oracle NetSuite Help Center「Preparing for Testing」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4471778785.html
- Oracle NetSuite Help Center「Data That Is Not Copied from Production to Release Preview」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_1549916016.html
- Oracle NetSuite Help Center「Sandbox and Release Preview Email Preferences」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/bridgehead_4369903537.html
- Oracle NetSuite Help Center「Scheduled Version Upgrade Dates and Refresh Requests」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/subsect_162577313831.html
- Oracle NetSuite Help Center「Customer-Scheduled Maintenance」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_159129486361.html
- Oracle NetSuite Help Center「NetSuite 2026.2 Release Notes」：https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_72152418635.html
もう少し詳しく知りたい方へ
リリースごとに影響を調べ、テストの段取りを組む作業を、導入後の保守として一緒に進めます。
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
- アップグレード対応を含む保守を相談したい方：NetSuiteパートナーリプレイス（導入の立て直し・引継ぎ・伴走保守）
- 自社のアップグレードの進め方を相談したい方：お問い合わせ
