SaaSの復旧経路
SaaS内にしか業務データがない会社の復旧経路
会計、勤怠、顧客管理、予約、販売管理等の重要データがSaaS内にしかない会社向けに、サービス内復元、アカウント回復、エクスポート、契約終了時の可搬性を事故別に整理します。
目次
この状態なら読む
次のような会社を対象にします。
- 会計、勤怠、顧客管理、予約、販売管理等をSaaSで使っている
- 重要データの正本がそのSaaS内にしかない
- PCやNASへ同じデータをファイルとして保存しているわけではない
- サービス内に履歴や削除復元機能はありそうだが、条件を確認していない
- 契約終了やアカウント喪失時に何を取り出せるか分からない
SaaSを使うこと自体が問題なのではありません。
自社でサーバーやデータベースを運用しなくてもよいため、小規模な会社にとって合理的な選択になる場合があります。
ただし、事業者がサービスを運用・バックアップしていることと、自社が必要な事故から業務を復旧できることは別です。
このページでは、自社が使える復旧経路を事故別に整理します。
最初に「何を失った状態か」を分ける
SaaSで「データが使えない」とき、原因は一つではありません。
| 状態 | 何が失われているか | 確認する復旧経路 |
|---|---|---|
| 一部データを誤削除した | レコードやファイル | ごみ箱、履歴、サポート復旧 |
| 大量に変更・削除された | 広い範囲のデータ | 一括復元、履歴、独立バックアップ |
| 利用者がログインできない | アクセス手段 | 管理者復旧、MFA・復旧先 |
| 管理者がログインできない | 管理経路 | 緊急アクセス、公式アカウント復旧 |
| SaaSが一時停止した | サービス利用経路 | 代替手順、エクスポート済みデータ |
| 契約を終了する | 利用権 | 事前エクスポート、移行先 |
| サービスを恒久的に使えない | サービスそのもの | 独立コピー、別システムで読める形式 |
この表を作るだけでも、「バックアップありますか」という一問より実態を把握しやすくなります。
事業者のバックアップと、自社の復旧手段を分ける
SaaS事業者はサービス継続のために冗長化やバックアップを行っている場合があります。
しかし、利用者が自由に任意時点へ戻せるとは限りません。
確認したいのは、事業者内部の設備構成そのものより、自社がどの操作をすれば、どの状態まで戻せるかです。
たとえば次を確認します。
- 削除したレコードを自分で戻せるか
- 管理者なら戻せるか
- サポートへ依頼すれば戻せるか
- 戻せる期間はどの程度か
- 過去の状態へ戻せるか
- 一部だけ戻せるか
- 契約終了後も復旧依頼できるか
「事業者がバックアップしている」と書かれていても、この答えが分からなければ利用者側の復旧手順にはなりません。
SaaS内の復元機能を確認する
最初に、今の契約内で利用できる機能を確認します。
履歴
レコード、設定、文書等の変更履歴が残る場合があります。
確認するのは、
- 何が履歴対象か
- 何日・何世代残るか
- 元へ戻せるのか、見るだけなのか
- 管理者だけ使えるのか
です。
削除復元
ごみ箱や削除済み項目がある場合があります。
- 論理削除と完全削除の違い
- 保持期間
- 管理者による復元
- 一括復元の有無
を確認します。
サポートによる復旧
利用者画面から戻せなくても、事業者サポートが対応できる場合があります。
ただし、
- 対象
- 依頼期限
- 本人確認
- 費用
- 所要時間
はサービスごとに異なります。
実際の利用規約、ヘルプ、契約内容を確認します。
履歴や削除復元だけへ依存しない
NCSCは、クラウドサービスに過去版や削除済みデータの保持機能があっても、重要データの信頼できるバックアップをそれらだけに依存せず、別の安全な場所またはサービスへ独立コピーを持つよう示しています。
これは「全SaaSを毎日丸ごとバックアップしなければならない」という意味ではありません。
まず、SaaS内の機能だけでは戻せない事故を特定します。
たとえば、
- 保持期間を超えた削除
- 管理者権限まで侵害された破壊
- アカウントやテナントへのアクセス喪失
- 契約終了
- サービスの恒久停止
まで備える必要があるデータかを判断します。
エクスポートできるか確認する
NCSCは、クラウドサービスへ重要情報を保存する場合でも、必要なデータがエクスポートされバックアップされていることを確認するよう示しています。
SaaSでは「バックアップ」というボタンがなくても、次のような取り出し方法がある場合があります。
- CSV
- Excel形式
- JSON
- XML
- 画像・添付ファイル一括取得
- API
- 管理者向けデータエクスポート
ここで重要なのは、形式名だけで判断しないことです。
「エクスポートできる」と「業務を復旧できる」は違う
たとえば顧客管理SaaSからCSVを出せても、次の情報が失われる場合があります。
- 添付ファイル
- コメント
- 履歴
- 権限
- 関連レコード間の関係
- 自動処理設定
- 画面上の状態
- 独自項目の意味
PDFなら人が読めても、新しいシステムへ再取込できない場合があります。
APIで全量取得できても、復元プログラムがなければ緊急時に使えない場合があります。
そのため、エクスポート形式ごとに目的を決めます。
| 目的 | 必要な状態 |
|---|---|
| 内容を閲覧できればよい | PDF、帳票等でも足りる場合がある |
| 集計を続けたい | CSV等の構造化データが必要 |
| 別SaaSへ移行したい | 項目対応、添付、ID関係等も必要 |
| 元SaaSへ戻したい | 正式なインポート・復元形式が必要 |
| 監査・履歴を残したい | 変更履歴や操作ログも別途必要な場合がある |
「ダウンロードした」ではなく、何に使えるデータなのかを確認します。
重要データだけ決める
SaaS内の全データを完全複製することが常に合理的とは限りません。
まず、サービスが使えないと何の業務が止まるかを見ます。
優先しやすいもの
- 顧客台帳
- 契約・請求情報
- 会計上必要な記録
- 予約・受注残
- 勤怠・給与計算に必要な記録
- 商品・価格・在庫等の基礎データ
- 法令・契約上保持が必要な記録
サービス内だけでもよい可能性があるもの
- 再作成しやすい一時設定
- 重要性の低い履歴
- 他の正本から再生成できるデータ
復旧対象を絞ると、エクスポート頻度や保存容量も決めやすくなります。
エクスポート頻度は失ってよい期間から決める
月1回、週1回、毎日という固定の正解はありません。
たとえば毎日受注が入るシステムで月末にしかエクスポートしなければ、最大1か月分を独立コピーでは戻せません。
一方、年に数回しか更新しないマスターデータを毎時間出力しても効果は小さくなります。
次の2点で決めます。
- どれくらいの期間の変更を失ってよいか
- 失った分を紙・メール・他システム等から再構成できるか
重要度が違うデータは頻度を分けても構いません。
誤削除と契約終了を同じ復旧手段で考えない
誤削除
サービス内の履歴、ごみ箱、サポート復旧が速い場合があります。
契約終了
契約終了後は管理画面やエクスポート機能へ入れなくなる可能性を前提に、終了前に必要データを取り出します。
確認項目は、
- 契約終了日
- データ取得期限
- 出力方法
- 添付ファイルの扱い
- 利用履歴やログ
- 削除時期
- 移行先で必要な形式
です。
退職者対応と同じく、「アクセスできなくなった後で考える」のではなく、失効前に移管します。
一時的なサービス停止と恒久的な移行も分ける
一時停止への備え
数時間から数日の停止であれば、最新の全データを別システムへ復元するより、最低限の業務継続手順が重要な場合があります。
例として、
- 本日の予約一覧だけ印刷・出力する
- 緊急連絡先だけ別に保持する
- 紙で受付し、復旧後に入力する
といった方法です。
恒久的な移行への備え
サービス終了や乗り換えでは、長期的にデータを再利用できる形式が必要です。
- CSVの項目定義
- コード値の意味
- 添付ファイルとレコードの対応
- 一意なID
- 文字コード
- 日時・金額の形式
等を確認します。
同じ「エクスポート」でも目的が違います。
アカウント喪失はデータバックアップとは別問題
SaaS内のデータが無事でも、会社側がログインできなければ利用できません。
そのため、
- 管理者が誰か
- 管理者が複数いるか
- MFA端末は誰が管理するか
- 復旧用メール・電話番号は会社管理か
- SSOが止まった場合の復旧方法
- サポートへ本人確認するための契約情報
を整理します。
データの復旧経路とアカウントの復旧経路は、別々に確認します。
エクスポートしたデータも保護する
SaaSから取り出したデータは、別の保存先へ移った時点でその保存先の管理対象になります。
顧客情報や従業員情報をCSVで書き出して個人PCやUSBへ置けば、SaaS内で設定していたアクセス制御は引き継がれません。
確認するのは、
- 保存場所
- 読める人
- 暗号化
- 保持期間
- 古い出力の削除
- バックアップ先の管理者
です。
「復旧用だから」と無制限にコピーを増やさないようにします。
実際に使えるか試す
既存のバックアップ方針と同様に、取り出したデータを実際に確認します。
NCSCは、バックアップから復元する方法を把握し、期待どおり動作するか定期的に試すことを示しています。
SaaSの場合、復元テストは必ずしも本番SaaSへ再投入する必要はありません。
目的に応じて、
- CSVを表計算ソフトで開く
- 必要な顧客を検索できる
- PDF帳票を閲覧できる
- 添付ファイルとの対応を確認できる
- テスト環境へインポートできる
- API出力を別処理で読める
などを確認します。
最低限の復旧台帳を作る
各SaaSについて次だけでも記録します。
| 項目 | 記録すること |
|---|---|
| サービス | SaaS名 |
| 管理者 | 自社側の管理責任者 |
| 重要データ | 止まる業務・必要データ |
| 誤削除 | 履歴、ごみ箱、サポート等 |
| アカウント喪失 | 管理者・MFA・公式復旧 |
| エクスポート | 形式、対象、手順 |
| 契約終了 | 取得期限、削除時期 |
| 独立コピー | 保存場所、頻度 |
| 復元確認 | 最終確認日、確認方法 |
製品比較表ではなく、自社の復旧経路表として使います。
費用を増やさず最初にやること
新しいバックアップサービスを契約する前に、今のSaaSで次を確認します。
- 重要データを3種類程度挙げる
- 削除・変更履歴の保持条件を確認する
- エクスポート方法を確認する
- 実際に少量出力する
- 出力データを別の環境で開く
- アカウント復旧方法を確認する
- 契約終了前に必要な作業を確認する
ここで不足が分かってから追加のバックアップを検討します。
目標とする状態
目標はSaaS内の全データを手元へ複製することではありません。
次の質問に会社として答えられる状態を目指します。
- 誤削除したらどこから戻すか
- 履歴はどこまで残るか
- 管理者が入れなくなったら誰が復旧するか
- 一時停止中に最低限どの業務を続けるか
- 契約終了前に何を取り出すか
- 取り出したデータは何に使えるか
- SaaSを恒久的に失っても必要な記録を読めるか
- 最後にエクスポートや復元を試したのはいつか
SaaS事業者がデータを保持していることではなく、自社が必要な事故ごとの復旧経路を説明し、実際に使えることを基準にします。
根拠・一次情報
外部事実は、資料トップではなく実際に確認した原典内の位置へ戻れるようにしています。リンク先が対応している場合は該当文言を直接表示します。
-
NCSCは、クラウドサービスへ重要情報を保存している場合でも、必要なデータがエクスポートされバックアップされていることを確認するよう示している。
- 支持: Back up your organisation’s critical data — Back up your organisation’s critical data(UK National Cyber Security Centre) / 確認日: 2026-09-13
-
NCSCは、クラウドサービス内の過去版や削除済みデータ保持だけに重要データのバックアップを依存せず、別の安全な場所またはサービスへ独立コピーを持つよう示している。
- 支持: Back up your organisation’s critical data — Back up your organisation’s critical data(UK National Cyber Security Centre) / 確認日: 2026-09-13
-
NCSCは、重要なファイルのバックアップについて、復元方法を把握し、期待どおり動作するか定期的にテストすることを示している。
- 支持: Mitigating malware and ransomware attacks — Action 1: make regular backups(UK National Cyber Security Centre) / 確認日: 2026-09-13