「クラウドなんだから、バックアップはOracleがやってくれる」
半分は、そのとおりです。
NetSuiteのバックアップとデータエクスポートとは、Oracleが基盤で行うデータの保護と、利用者が自社の目的で行うデータの取り出しの2つを指します。
基盤の保護はOracleが担います。
ただ、誤って消したレコードや、監査で求められる過去の時点のデータは、その保護の外にあります。
残りの半分は、自社の仕事です。
といっても、全部を守る必要はありません。
目的を1つ決め、対象を絞り、保存検索のCSVから小さく始めれば足ります。
では、自社が持つべきデータは、どこで線を引けばよいのか。
線の位置が分かると、要る手段も、やらなくてよいことも決まります。
この記事で分かること
- クラウドERPのバックアップで、Oracleと自社の責任がどこで分かれるか
- NetSuiteの中で追えることと、追えないこと
- データを取り出す6つの手段と、「戻す・答える・使う・残す」の目的別の選び方
- 設定の順番と、続けるための1ページの一覧
- パートナーを変える前に集めておくもの
言葉の整理：エクスポートは、システムの中のデータをファイルなどの形で外に出すことです。
保存検索（Saved Search）は、条件を保存して繰り返し使えるNetSuiteの検索機能です。
クラウドERPのバックアップは、誰の責任か
| 領域 | 誰の責任か |
|---|---|
| サーバー・ネットワークなどの基盤 | サービス提供者（Oracle） |
| データセンターの障害・災害への対応 | サービス提供者（Oracle） |
| システム全体の稼働の維持 | サービス提供者（Oracle） |
| 誰がどのデータを操作できるかの設定 | 利用者（自社） |
| 業務で必要なデータの保持と持ち出し | 利用者（自社） |
自社サーバーの時代は、この全部が自社の責任でした。
クラウドでは、上の3行が移ります。
移らないのは下の2行です。
抜けやすいのは「操作の結果」
サービス提供者が守るのは、システムが壊れたときのデータです。
守らないのは、正しく動くシステムの上で起きた利用者の操作の結果です。
誤って消したレコード、間違えた一括更新、退職者が最後に行った変更。
どれも障害ではないため、基盤の保護の対象になりません。
Oracleが担っていること
NetSuiteの公式サイトでは、次の体制が示されています。
（出典：Oracle NetSuite公式「Cloud Infrastructure」、2026年9月確認）
- 稼働：99.7%のサービスレベルのコミットメント。近年の平均稼働率は99.96%
- バックアップ：複数のデータセンターに、データを継続的にバックアップ
- 拠点：北米・欧州・アジア太平洋に、地理的に離れたデータセンター
- アクセスの保護：多要素認証、ロールにもとづくアクセスの制御、IPアドレスによる制限
- 透明性：稼働の状況を示すステータスのページを公開
NetSuiteは、世界220地域・44,000社以上で使われています（出典：Oracle NetSuite公式サイト、2026年9月時点）。
サーバーの調達も、バックアップの機器の管理も、災害に備えた拠点の分散も要りません。
専任の情シスを置けない会社ほど恩恵は大きくなります。
NetSuiteの中で追えること
操作の結果も、NetSuiteの中である程度は追えます。
| 機能 | できること | できないこと |
|---|---|---|
| System Notes（システムノート） | 変更の日時・変更した人・項目・変更前後の値を記録。記録は誰も編集できない | 変更前の状態に自動で戻す |
| 削除したレコードの検索 | 削除されたレコードの基本の情報と、削除の日時を検索できる | 削除したレコードを元に戻す |
出典：Oracle NetSuiteのヘルプ（System Notes／削除したレコードの検索）、2026年9月確認。
誰がいつ何を変えたかは、追えます。
ただ、元の値に戻す作業は人が行います。
消したレコードの中身を戻すには、手元のデータが要ります。
自社でデータを持つ4つの目的｜戻す・答える・使う・残す
| 目的 | 起きる場面 | 要るデータ | 頻度 |
|---|---|---|---|
| ①戻す（誤削除・誤更新） | 誤って消した。CSVの一括更新で意図しない項目まで変わった | 更新の多い取引・主要マスタ | 短い周期 |
| ②答える（監査・社内の説明） | 「この時点の残高は」と過去の時点のデータを求められる | 決算期など特定の時点 | 特定の時点で長く保管 |
| ③使う（他のシステム） | BIで分析する、別のシステムに渡す | 分析に使う項目 | 継続して同期 |
| ④残す（将来の選択肢） | システムの見直し・契約の変更 | マスタを中心とした全体 | 低い |
いちばん多いのは、①戻すです。
System Notesで変更前の値は分かっても、消したレコードの中身は手元にないと戻せません。
②の法令上の保存の要件は、NetSuiteと電子帳簿保存法・インボイス制度の対応で扱っています。
③は保全ではなく、活用のためのエクスポートです。
目的が違えば、手段も変わります。
④で、契約を終えたときにデータをどう受け取れるかは、契約の内容で決まります。
自社の契約書で条件を見てください。
4つを同じ方法でやろうとすると、無理が出ます。
4つの目的を図にすると、次のとおりです。
データを取り出す6つの手段
Oracleのヘルプでは、データを取り出す方法として次のものが挙げられています。
（出典：Oracle NetSuiteのヘルプ「Extracting Data from NetSuite」、2026年9月確認）
スケジュール済みスクリプトは、決めた時刻や定期的に処理を動かせるSuiteScriptの一種です。
（出典：Oracle NetSuiteのヘルプ「SuiteScript 2.1 Script Types」、2026年9月確認）
| 手段 | 中身 | 始めやすさと保守 | 向く目的 |
|---|---|---|---|
| ①保存検索のCSV | 条件を決めて、要るレコードだけを出す。定期送信も設定できる | 始めやすい。開発は不要 | ①戻す ②答える ④残す |
| ②レポートのCSV | レポートの結果をCSVで出す | 始めやすい | ②答える（合計を合わせやすい） |
| ③Full CSV Export | 主要なリストと取引の明細をまとめてZIPで出す | 始めやすい（管理者のみ） | ④残す（全体像の確認） |
| ④スケジュール済みスクリプト | SuiteScriptで、決めた時刻に加工して出す | 開発が要る。作った人への依存が出やすい | 複雑な条件の定期出力 |
| ⑤SOAP Web サービス | プログラムでデータを問い合わせる | 開発が要る | ③使う |
| ⑥SuiteAnalytics Connect | ODBCなどで外部のツールからデータにつなぐ | 接続の設定が要る | ③使う（AIやBIで続けて分析） |
SuiteScriptは、NetSuiteを拡張するためのプログラムの言語です。
ODBCは、外部のツールからデータベースにつなぐための標準的な方式です。
SOAP Web サービスは、2028.2で使えなくなる予定です。
これから作るなら、REST Web サービスを前提にします。
（出典：Oracle NetSuiteヘルプ「SOAP Removal Plans FAQ」、2026年9月確認）
使う前に知っておきたい注意
Oracleのヘルプには、次の注意が書かれています（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
- Full CSV Export は全データを出すものではない。対象は顧客・仕入先・品目・従業員・取引の明細などの一覧に限られる
- Full CSV Export を使えるのは、管理者のロールを持つ人だけ
- ODBCでの接続は追加の有料サービス
- どの手段でも、内部ID（NetSuiteがレコードごとに振る番号）を一緒に出すと、データ同士の関係を保てる
実務で困りやすい点が、もう1つあります。
CSVをExcelで直接開くと、16桁を超える数字は精度が落ちるとヘルプに書かれています。
長い番号の列は、文字列として読み込む設定にしておきます。
保存検索の作り方は、NetSuite保存検索の作り方で解説しています。
開発の言語は、SuiteScriptとはをご覧ください。
設定の順番｜目的→対象→頻度→保管→手段
手段は、優劣ではなく用途で選びます。
多くの目的は、保存検索のCSVで足ります。
開発が要るのは、条件が複雑な場合か、続けて外部で使う場合だけです。
| 目的 | 向いている手段 |
|---|---|
| ①戻す | 保存検索のCSV（主要なレコードを定期に出す） |
| ②答える | 保存検索またはレポートのCSV（決算期などに出して保管） |
| ③使う | SuiteAnalytics Connect、SOAP Web サービス、またはスクリプト |
| ④残す | 保存検索のCSV（マスタ中心）＋Full CSV Export で全体を確認 |
設定は、手段から入らずに次の順で決めます。
- 目的を決める：戻す・答える・使う・残すのどれか。複数でも構わない
- 対象を決める：マスタ・取引・カスタム項目のどれを、どこまで
- 頻度と保管の期間を決める：毎日か月次か、何年残すか
- 保管の場所と見られる人を決める
- 最後に手段を選ぶ
順番を逆にすると、「とりあえず全部出す」になります。
全部出したファイルは、たいてい誰も見ません。
つまずきやすいのは4番目です。
エクスポートしたファイルは、NetSuiteのアクセスの制御の外に出ます。
NetSuiteの側の権限は、NetSuiteの権限・ロール設計ベストプラクティスで解説しています。
出したあとの管理も、同じ厳しさで決めてください。
情報の守り方の全体は、基幹システムのセキュリティとはで扱っています。
どこまで作り込むか
| 会社の条件 | 向いている進め方 |
|---|---|
| 取引の件数が少なく、操作する人も限られる | 保存検索のCSVを月に1回。System Notesで変更を追う |
| 一括更新やCSVの取込が多い | 取込の前に、対象のレコードを保存検索で出しておく |
| 監査への対応が重い（上場の準備・親会社への報告など） | 決算期ごとのCSVの保管と、保管の場所の権限を先に決める |
| BIやAIで続けて分析したい | SuiteAnalytics Connect などで外部のデータベースに同期する |
| 導入の直後で、データの蓄積が少ない | いまは責任の線の理解だけでよい。手作業の整理が先 |
いまは急がなくてよい会社もあります。
手作業の運用の整理が先の時期なら、順番が違うだけです。
データの持ち方は、ERPの選び方にも関わります。
Odooを自社のサーバーで動かす場合や、オンプレミスの国産ERPでは、バックアップの設計は自社かベンダーの保守に戻ります。
AIでスクラッチ開発したシステムなら、復旧の手順まで自社で決めます。
バックアップの責任を、誰にどこまで持たせたいか。選び方はそこで変わります。
これから契約する会社が、先に聞いておくこと
- 契約を終えるとき、データをどの形で受け取れるか（契約書で見る）
- 外部のツールで分析するなら、SuiteAnalytics Connect の費用が見積りに入っているか
- 導入のパートナーに、エクスポートの設計と引き継ぎの資料まで頼めるか
- 社内に、保存検索を作れる人を育てる予定があるか
いま使っている会社が、更新や乗り換えの前にすること
- 契約の更新の前に、④残すためのエクスポートを一度行う
- 別のシステムへ移るなら、Full CSV Export だけでは全データが出ない前提で、対象ごとの出し方を決める
- すでに動いている定期の出力を開き、いまも正しく出ているかを見る
よくある3つの失敗
失敗1：設定して、そのまま誰も見ない
起きること：定期の出力を設定したが、出力先を何年も開いていない。途中でエラーになっていたと、要るときに気づく。
原因：バックアップは、平常時に誰も使わない。動いているかを見る機会が、仕組みとしてない。
避け方：四半期に一度は実際に開く日をカレンダーに入れます。
開くと、項目が足りない、文字化けしている、といった問題が見つかります。
失敗2：全部を出そうとして、続かない
起きること：全レコード・全項目を毎日出す設計にした。ファイルが大きく処理が重くなり、いつのまにか止まっている。
原因：目的を決めずに始めた。「念のため全部」は安全に見えて、続かない。
避け方：目的を1つに絞って小さく始めます。
まずは①戻すの備えとして、更新の多い主要なレコードだけを対象にします。
回り始めてから広げるほうが確実です。
失敗3：出したあとの管理が抜ける
起きること：共有フォルダの誰でも見える場所に、基幹データのCSVがある。古いファイルが何年分も残り、退職者のアカウントからも見られる。
原因：エクスポートした時点で、NetSuiteの権限の外に出る。システムの中の権限は、ファイルには効かない。
避け方：保管の場所と見られる人を出力の設定と同時に決めます。
いつ削除するかも、あわせて決めます。
ベンチャーネットならこう見る｜パートナーを変える前に集める3つ
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、ゼロからの導入より引き継ぎが多い会社です。
他社のあとの立て直しで、よく出会う場面があります。
定期の出力が動いているのに、何のために、何を出しているのか、誰も説明できない。
作った人しか分からない仕組みは、止まっても誰も気づけません。
そこで、パートナーの変更や保守の引き継ぎの前に、次の3つを集めてもらいます。
- 出力の一覧：何を・いつ・どこに・誰が出しているか
- スクリプトの仕様：スケジュール済みスクリプトなどで作った出力の、条件と加工の中身
- 保管の場所と権限：出したファイルを、どこに置き、誰が見られるか
3つがそろえば、引き継いだ翌月から、出力が正しく出ているかを点検できます。
そろわなければ、まず中身を調べるところから始めます。
NetSuiteの外で動く連携の出力も、同じ一覧に載せて一緒に引き継ぎます。
変わること、注意が要ることも先にお伝えします。
Full CSV Export だけでは、全データは出ません。
外部で分析するためのODBCの接続には、追加の費用がかかります。
いまは作り込まなくてよい会社には、そうお伝えします。
最初に伺うのは、次の3つです。
- 最近1年で、戻したくなった操作はあったか
- 監査や親会社から、過去の時点のデータを求められるか
- 出力の一覧は1ページにまとまっているか
今日できること｜出力の一覧を1ページで作る
1時間で、次の表を埋めてみてください。
| いま出しているデータ | 目的と頻度 | 出力先と担当者 | 最後に開いた日 |
|---|---|---|---|
| （例）顧客マスタ | ④残す・月1回 | 経理の共有フォルダ・経理課長 | 不明 |
埋まらない行が、手当ての要る場所です。
「最後に開いた日」が分からない行は、失敗1の状態にあります。
1行もなければ、①戻すの目的で保存検索を1本作るところから始めます。
この表は、パートナーを変えるときに、そのまま渡せる資料にもなります。
第8章で集める3つのうち、1つ目がこれです。
残りの2つ（スクリプトの仕様、保管の場所と権限）は、表の行ごとに書き足していけば足ります。
よくある質問
Q1. クラウドなのに、自社でバックアップを取る必要がありますか
基盤の保護のためなら要りません。
サーバーの障害や災害への対応は、Oracleが担います。
要るのは、誤った操作の結果を戻したい場合や、監査・分析のためにデータを手元に持ちたい場合です（第1章・第3章）。
Q2. 全データをまとめてダウンロードできますか
Full CSV Export がありますが全データは出ません。
Oracleのヘルプに、全データをCSVで出すものではないと書かれています。
使えるのは管理者のロールの人だけです。
目的に応じて、保存検索などで対象ごとに出す進め方が現実的です（第4章）。
Q3. 誤って削除したレコードは、NetSuiteで戻せますか
削除の記録は検索できますがレコードは戻りません。
削除したレコードの検索で、基本の情報と削除の日時は分かります。
中身を戻すには、手元のエクスポートが要ります（第2章）。
Q4. 解約したら、データはどうなりますか
契約の内容で決まります。
自社の契約書で条件を見てください。
そのうえで、要るデータを前もって取り出す計画を立てます（第3章）。
Q5. どのくらいの頻度で取るべきですか
目的で変わります。毎日が正解ではありません。
戻すためなら短い周期、答えるためなら決算期などの時点、使うためなら継続した同期です。
使わない頻度で出しても、負担が増えるだけです。
Q6. 出したファイルの容量が心配です
出したファイルは自社の保管でNetSuiteの容量とは別です。
NetSuiteの中のファイルの容量は、NetSuiteの容量・ストレージ制限ガイドで扱っています。
まとめ：バックアップは保険ではなく、動き続けるための備え
- 基盤の保護はOracleが担う。99.7%のサービスレベルのコミットメントと、複数のデータセンターへの継続的なバックアップ
- 自社が持つのは、戻す・答える・使う・残すのためのデータ
- 変更の履歴はSystem Notesで追えるが、消したレコードは手元のデータがないと戻せない
- 取り出す手段は6つ。多くの目的は保存検索のCSVで足りる
- 目的→対象→頻度→保管→手段の順で決め、1ページの一覧で引き継ぐ
「Oracleがやってくれる」のは、半分です。
残りの半分は、出力の一覧を1ページ作るところから始まります。
日々の使い方でのつまずきは、NetSuiteが「使いにくい」と感じる本当の原因とはでも扱っています。
乗り換えのときのデータの移し方は、基幹システムのデータ移行をご覧ください。
もう少し詳しく知りたい方へ
どこまでを自社で持つべきかは、業種や監査の要件、システムの連携の状況で変わります。
いまは急がなくてよいと判断した場合は、そのようにお伝えします。
- 運用の体制づくりや、パートナーの変更を相談したい方：NetSuiteの導入・伴走・保守サービス
- 定期の出力や外部への連携を作り込みたい方：NetSuiteの開発・カスタマイズ
- 自社の状況の整理から相談したい方：お問い合わせ
