「クラウドだと、バックアップはどうなるのですか」
NetSuiteの導入を検討されている方から、よくいただく質問です。導入後の運用フェーズでも、担当者が変わるたびに同じ質問が出ます。
自社サーバーの時代は、答えが分かりやすいものでした。バックアップは自社で取る。それだけです。
クラウドになると、この線が見えにくくなります。サービス側がどこまでやってくれて、自社は何をすべきなのか。ここが曖昧なまま運用が続いている会社は、少なくありません。
この記事は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットが書いています。「クラウドは危ないから自分で守れ」という話ではありません。 責任の線を正確に引いたうえで、自社が持つべきデータと、その取り方を整理します。
この記事で分かること
- クラウドERPにおけるバックアップの責任分界
- サービス側が担っている保護の中身
- それでも自社でデータを持つべき4つの理由
- 自社で取れる3つの手段と、目的別の選び方
読了時間の目安：約12分
クラウドERPのバックアップは、誰の責任か
まず、責任の線を引きます。ここが曖昧なまま手段の話に入ると、判断を誤ります。
責任は、二つに分かれています
クラウドサービスでは、責任がサービス提供者と利用者に分かれます。
| 領域 | 誰の責任か |
|---|---|
| サーバー・ネットワークなどの基盤 | サービス提供者 |
| データセンターの障害・災害への対応 | サービス提供者 |
| システム全体の可用性の維持 | サービス提供者 |
| 誰がどのデータを操作できるかの設定 | 利用者 |
| 業務上必要なデータの保持と持ち出し | 利用者 |
自社サーバーの時代は、この全部が自社の責任でした。クラウドでは、上半分が移ります。
移らないのが下半分です。 ここを「クラウドだから全部お任せ」と考えると、抜けが生じます。
抜けやすいのは「操作の結果」
サービス提供者が守ってくれるのは、システムが壊れたときのデータです。
守ってくれないのは、正しく動いているシステムの上で起きた、利用者の操作の結果です。
誤って削除したレコード。間違った一括更新。退職者が最後に行った変更。これらはシステムの障害ではないので、基盤側の保護の対象になりません。
この区別が、この記事全体の前提になります。
サービス側がやってくれること
自社で何をすべきかを考える前に、サービス側が何をしているのかを正確に押さえます。
Oracle公式が示している体制
NetSuiteは、次の体制で運用されています。
- 稼働率：99.7%のサービスレベルコミットメント
- アクセス保護：多要素認証、ロールベースのアクセス制御、IPアドレス制限
- データ保護：暗号化に加え、複数のデータセンターへ継続的にバックアップ
- 透明性：稼働状況を公開するステータスページを常時提供
（出典：Oracle NetSuite公式 Cloud Infrastructure）
ここは、自社で用意する必要がありません
サーバーの調達も、バックアップ機器の管理も、災害対策の拠点分散も要りません。
自社サーバーの時代に情シスが多くの時間を割いていた領域が、まるごと移っています。専任の担当者を置けない会社ほど、この恩恵は大きくなります。
インフラの保護という意味では、多くの中堅・中小企業が自前で用意できる水準を上回っていると考えてよい部分です。
だから、不安をあおる必要はありません
「クラウドは危ない」という前提から入る説明を、私たちは取りません。
正確に言えば、基盤の保護は十分に手厚い。足りないのは、自社の業務都合で必要になるデータの持ち方です。
次の章で、その中身を具体的に見ていきます。
それでも自社でデータを持つ、4つの理由
自社でエクスポートを行う理由は、大きく4つあります。どれが自社に当てはまるかで、必要な手段が変わります。
理由①：誤削除・誤更新から戻すため
最も多い理由です。
レコードを誤って削除した。CSVで一括更新したら、意図しない項目まで書き換わった。こうした事故は、システムが正常に動いていても起こります。
基盤側の保護は、この種の事故を想定したものではありません。業務上重要なデータを、自社の手元にも持っておくことで、確認と復旧の選択肢が増えます。
理由②：監査や社内説明に答えるため
「この時点の残高はいくらだったか」「この変更は誰がいつ行ったか」。
監査や社内の照会で、過去のある時点のデータを求められることがあります。システム上で追える範囲を超える場合、手元にエクスポートがあると説明が早く済みます。
なお、法令上の保存要件については、NetSuiteと電子帳簿保存法・インボイス制度の対応で整理しています。本記事では要件の詳細には立ち入りません。
理由③：他システムでデータを使うため
BIツールで分析したい。別のシステムに連携したい。取引先へ定型の帳票を送りたい。
こうした用途では、NetSuiteの外にデータを出す必要があります。この場合の「エクスポート」は、保全ではなく活用が目的です。
目的が違えば、選ぶ手段も変わります。
理由④：将来の選択肢を確保するため
システムは、いつか見直す時期が来ます。会社の方針が変わることも、契約の形が変わることもあります。
そのとき、自社のデータをどう持ち出せるかを把握しているかどうかで、選択肢の幅が変わります。
なお、契約終了時のデータの扱いは契約内容によって異なります。一般論ではなく、自社の契約書で確認してください。
4つのうち、どれが自社の理由か
この4つは、それぞれ必要なデータの種類も頻度も違います。
- ①誤削除対策 → 更新頻度の高いトランザクション、短い周期
- ②監査対応 → 決算期など特定時点、長期保持
- ③他システム活用 → 分析に使う項目、継続的な同期
- ④選択肢の確保 → マスタを中心とした全体像、低頻度
全部を同じ方法でやろうとすると、たいてい無理が出ます。 ここが設計の出発点です。
自社で取れる、3つの手段
NetSuiteでユーザー側が能動的にデータを取り出す手段は、主に3つあります。
手段①：保存検索のCSVエクスポート
保存検索（Saved Search：条件を保存して繰り返し使える検索機能）の結果を、CSVで書き出す方法です。
画面から手動で出すこともできますし、定期送信の設定も可能です。
特別な開発を必要としないのが最大の利点です。保存検索を作れる人がいれば、その日から始められます。
保存検索そのものの作り方は、NetSuite保存検索の作り方で解説しています。
手段②：スケジュール済みスクリプトでの定期出力
SuiteScript（NetSuiteの拡張用プログラム）を使い、決めた時刻に自動でデータを出力する方法です。
保存検索では扱いにくい加工や、複数レコードをまたぐ処理に向いています。
開発と保守が必要になる点が、判断のポイントです。作った人が抜けたときに誰が引き継ぐかを、最初に決めておく必要があります。
手段③：SuiteAnalytics Connectでの外部DB同期
BIツールや外部のデータベースへ、NetSuiteのデータを接続して転送する方法です。
継続的に大量のデータを外部で扱いたい場合に向いています。
利用にあたっては契約条件の確認が必要です。自社の契約に含まれているかどうかは、個別にご確認ください。
3つの比較
| 観点 | ①保存検索CSV | ②スケジュール済みスクリプト | ③SuiteAnalytics Connect |
|---|---|---|---|
| 始めやすさ | 高い（開発不要） | 低い（開発が必要） | 中（接続設定と契約確認） |
| 自動化 | 定期送信の設定が可能 | 柔軟に設定できる | 継続的な同期に向く |
| 加工の自由度 | 保存検索でできる範囲 | 高い | 外部ツール側で行う |
| 保守の負担 | 小さい | 作った人への依存が生じやすい | 中 |
| 主な用途 | 保全・定型の出力 | 複雑な条件での定期出力 | 分析・外部システム活用 |
目的別に、どれを選ぶか
3つの手段は、優劣ではなく用途で選びます。
目的と手段の対応
| 目的 | 向いている手段 |
|---|---|
| ①誤削除・誤更新から戻す | 保存検索CSV（重要レコードを定期出力） |
| ②監査・社内説明に答える | 保存検索CSV（決算期など特定時点で出力し保管） |
| ③他システムで活用する | SuiteAnalytics Connect、またはスケジュール済みスクリプト |
| ④将来の選択肢を確保する | 保存検索CSV（マスタ中心に、低頻度で全体を） |
表を見ると分かるとおり、多くの目的は保存検索のCSVエクスポートで足ります。
開発が必要になるのは、条件が複雑な場合か、継続的な外部活用が必要な場合に限られます。
設計の順序
手段から入らず、次の順序で決めてください。
- 目的を決める（上の4つのどれか。複数でも構いません）
- 対象データを決める（マスタ／トランザクション／カスタム項目のどれを、どこまで）
- 頻度と保持期間を決める（毎日か月次か、何年残すか）
- 保管場所と権限を決める（どこに置き、誰が見られるか）
- 最後に手段を選ぶ
順序を逆にすると、たいてい「とりあえず全部出す」になります。全部出したファイルは、たいてい誰も見ません。
保管場所と権限を忘れない
見落とされやすいのが4番目です。
エクスポートしたファイルは、NetSuiteのアクセス制御の外に出ます。誰でも開ける場所に基幹データが置かれている状態は、それ自体がリスクです。
NetSuite側の権限設計については、NetSuiteの権限・ロール設計ベストプラクティスで解説しています。出したあとの管理も、同じ厳しさで設計してください。
データ保全でよくある4つのつまずき
ここからは、運用の現場で見てきたつまずきを整理します。
これは、うまくできていない会社を批判するためのものではありません。どれも、悪意も怠慢もないところで起こります。だから先にお伝えしておきたいのです。
つまずき①：設定して、そのまま誰も見ない
よくある現象
- 定期出力を設定したが、出力先を数年間開いていない
- 途中でエラーになっていたことに、必要になってから気づく
- ファイルは溜まっているが、中身が正しいか誰も確認していない
なぜ失敗するか
バックアップは、平常時に誰も使わないためです。
動いているかどうかを確認する機会が、仕組みとして存在しません。だから止まっても気づけません。
どう回避するか
四半期に一度でよいので、実際に開いて中身を確認する日を決めてください。
カレンダーに入れるだけで構いません。開いてみると、項目が足りない、文字化けしている、といった問題が見つかります。
つまずき②：全部を出そうとして、続かない
よくある現象
- 全レコード・全項目を毎日出力する設計にする
- ファイルが大きくなりすぎ、処理が重くなる
- 負担が大きく、いつのまにか止まっている
なぜ失敗するか
目的を決めずに始めたためです。
「念のため全部」は、一見すると安全に見えます。しかし運用の負担が大きく、続きません。そして続かない仕組みは、結果として何も守りません。
どう回避するか
目的を1つに絞って、小さく始めてください。
まずは誤削除対策として、更新頻度の高い主要レコードだけを対象にする。それが回り始めてから広げるほうが、確実です。
完璧を目指すより、まず回す。動かしながら磨いていくほうが、結果的に早く整います。
つまずき③：作った人しか分からない状態になる
よくある現象
- スクリプトで自動化したが、仕様書が残っていない
- 作った担当者が異動・退職し、誰も触れなくなる
- 不具合が出ても、直せる人が社内にいない
なぜ失敗するか
自動化は、動いている間は誰の目にも触れないためです。
触れないものは、引き継がれません。そして基幹データを扱う仕組みほど、止まったときの影響が大きくなります。
どう回避するか
何を・いつ・どこに出しているかを、1ページの表にしてください。
対象データ、頻度、出力先、担当者。この4項目が書いてあれば、担当が変わっても再現できます。
私たちは、運用フェーズで管理者をひとりにしないことを大切にしています。仕組みを作ることと、続けられる状態にすることは、別の仕事です。
つまずき④：出したあとの管理が抜ける
よくある現象
- 共有フォルダの誰でも見える場所に、基幹データのCSVが置かれている
- 古いエクスポートファイルが、何年分も削除されずに残っている
- 退職者のアカウントからも、まだアクセスできる状態になっている
なぜ失敗するか
エクスポートした瞬間に、NetSuiteのアクセス制御の外に出るためです。
システム内では厳密に権限を設計していても、出したファイルには適用されません。ここで守りの水準が一段落ちます。
どう回避するか
保管場所と閲覧権限を、出力の設定と同時に決めてください。
あわせて、いつ削除するかも決めます。保持期間を決めていないファイルは、増え続けるだけです。
四つに共通するもの
四つを並べると、共通点が見えてきます。
いずれも、バックアップを「作業」として捉えていることから生じています。
設定した時点で完了、と考えると、この4つはすべて起こります。バックアップは仕組みではなく、続く運用です。
ベンチャーネットは、お客様と対等な関係で仕事をしたいと考えています。だから、不安をあおって余計な仕組みを勧めることはしません。
自社にとって本当に必要な範囲はどこか。それを一緒に切り分けるところから、ご一緒させてください。
何から始めるか
現実的な進め方を3段階で整理します。
第1段階：目的を1つ決める
前述の4つの理由から、いま最も切実なものを1つ選んでください。
多くの会社では、①誤削除・誤更新から戻すことが最初の目的になります。実際に起きる頻度が高く、影響も分かりやすいためです。
第2段階：対象を絞って、保存検索で始める
その目的に必要な最小限のレコードを決め、保存検索のCSVエクスポートから始めます。
開発は不要です。まず動かして、運用に乗るかどうかを確かめることが目的です。
ここで無理があるようなら、対象をさらに絞ってください。続かない設計は、最初から作らないほうが得です。
第3段階：記録して、広げる
回り始めたら、何を・いつ・どこに出しているかを1ページにまとめます。
そのうえで、次の目的に広げます。分析での活用が必要になった段階で、初めて他の手段を検討すれば十分です。
急ぐ必要のない会社もあります
正直に申し上げると、いま急いで整える必要のない会社もあります。
- 導入直後で、まだデータの蓄積が少ない
- 手作業の運用が残っていて、そちらの整理が先
- 判断できる立場の人が、いま関与できない
該当する場合は、責任分界の理解だけ済ませて構いません。順番が違うだけで、方向が間違っているわけではありません。
よくある質問
Q1. クラウドなのに、自分でバックアップを取る必要があるのですか
基盤の保護という意味では、必要ありません。サーバーの障害や災害への対応は、サービス側が担っています。
必要になるのは、利用者側の操作の結果を戻したい場合です。誤って削除した、一括更新で意図しない変更が入った。こうした事故は、システムが正常でも起こります。
目的が「基盤の保護」なのか「操作の結果への備え」なのかを分けて考えてください。
Q2. 全データをまとめてダウンロードする方法はありますか
本記事では、そうした一括の取得方法についての断定は控えます。契約内容や利用しているモジュールによって、取れる範囲が変わるためです。
実務としては、目的に応じて必要なレコードを保存検索で出す進め方が現実的です。全部を一度に取ることを前提にすると、たいてい設計が止まります。
Q3. 解約したら、データはどうなりますか
契約終了時のデータの扱いは、契約内容によって異なります。一般論としてお答えできる範囲を超えます。
自社の契約書で条件を確認してください。そのうえで、必要なデータを事前に取り出しておく計画を立てることをお勧めします。
これは、記事の中で挙げた「④将来の選択肢を確保する」に当たります。
Q4. どのくらいの頻度で取るべきですか
目的によって変わります。
誤削除対策であれば、更新頻度の高いデータを短い周期で。監査対応であれば、決算期など特定の時点で。分析での活用であれば、継続的な同期を。
「毎日が正解」ではありません。 使わない頻度で出しても、運用の負担が増えるだけです。
Q5. 容量が心配なのですが
エクスポートしたファイルは自社側の保管になるため、NetSuite側の容量とは別の話になります。
NetSuite内のファイル容量やストレージの制限については、NetSuiteの容量・ストレージ制限ガイドで整理しています。
まとめ：バックアップは保険ではなく、動き続けるための備え
ここまで、責任分界と3つの手段、そして設計の順序を見てきました。
最後に、いちばんお伝えしたいことを書きます。
バックアップは、万一のための保険ではありません。何かあったときに、業務を止めずに動き続けるための備えです。
保険と考えると、「使わないもの」になります。使わないものは、点検されず、いつのまにか止まります。
備えと考えると、日常の運用の一部になります。四半期に一度開いて確かめる。担当が変わったら引き継ぐ。この積み重ねが、いざというときの差になります。
そして、この記事でお伝えしたかったのは、やみくもに全部を守る必要はないということです。
サービス側が担っている領域は十分に手厚い。自社が持つべきなのは、業務都合で必要になるデータだけです。目的を1つ決めて、対象を絞って、小さく始める。それで足ります。
なお、どこまでを自社で持つべきかは、業種や監査の要件、システム連携の状況によって変わります。ここは一律の正解がない領域です。
ご自身の状況で判断に迷われたら、一緒に整理させてください。いまは急ぐ必要がないと判断したときには、そのようにお伝えします。
もう少し詳しく知りたい方へ
- 運用の体制づくりから相談したい方へ：NetSuiteの運用・保守サポート
- 実際の画面を見ながら相談したい方へ：NetSuiteの無料デモ・個別相談
- 自社の状況を整理するところから相談したい方へ：お問い合わせ
関連記事
- NetSuiteが「使いにくい」と感じる本当の原因とは
- NetSuiteの容量・ストレージ制限ガイド
- NetSuiteの権限・ロール設計ベストプラクティス
- NetSuite保存検索の作り方
- NetSuiteと電子帳簿保存法・インボイス制度の対応
- NetSuiteのCSVインポート活用ガイド
- 基幹システムのセキュリティ設計
