クラウドのデータのバックアップは誰が取るのか。サービス会社と自社の役割分担と「3-2-1ルール」

「クラウドを使っているので、データのバックアップはサービス会社が取っているはず」

自社にサーバー（データやシステムを置くコンピューター）を置かず、インターネット経由で業務システムを使うようになると、データの保管まで任せている感覚になります。

しかし、サービス会社が取っているバックアップと、利用する会社が必要とするバックアップは、必ずしも同じものではありません。実際に、利用する側にもバックアップを取るよう求めている、インターネット経由の業務ソフト（SaaS）の利用規約があります。

大切なのは、「バックアップはありますか」という一つの質問で確認を終わらせないことです。

誰が、何を、どこに保存し、事故が起きたときに、どの状態まで戻せるのか。

今回は、クラウドサービスでデータのバックアップを誰が取るのかという役割分担と、データを守る基本的な考え方である「3-2-1ルール」を整理します。

「クラウドに任せている」の中身を分けて考える

クラウドサービスの裏側には、複数の会社が関わっていることがあります。

例えば、業務ソフトを提供する会社（SaaS事業者）が、別の会社からサーバーなどの設備（クラウド基盤）を借りて、サービスを動かしている場合です。このとき、設備を貸す会社と業務ソフトの会社、業務ソフトの会社と利用する会社の間には、それぞれ別の契約があります。

IDCFクラウドの公開している条件では、利用者が作ったシステムなどのデータについて、契約者の責任で保管し、バックアップを取るとしています。業務ソフトの会社が直接契約していれば、ここでいう契約者は業務ソフトの会社です。

では、その業務ソフトを使う会社は何もしなくてよいのでしょうか。

これも、業務ソフト側の契約条件によります。例えばfreeeの共通利用規約第11条では、利用者自身の責任で情報を記録・保存・管理し、バックアップを取ることが定められています。サービスごとの個別の規約が優先される場合もあるため、実際に使うサービスの条件を確認する必要があります。

つまり、設備を貸す会社との間でバックアップの責任が決められていることと、最終的に利用する会社がどこまで対応するかは、別の話です。

「業務ソフトの会社が取る」「利用する会社が取る」のどちらか一方に決めつけるのではなく、それぞれが何を引き受けているのかを確認する必要があります。

サービスを復旧するためのバックアップと、自社の仕事を守るためのバックアップ

同じ「バックアップ」という言葉でも、目的が違います。

一つは、サービス会社が故障や災害からシステム全体を元に戻すためのバックアップです。もう一つは、利用する会社が、うっかり消したデータを戻したり、サービスが止まっている間も必要な情報を見られるようにしたりするための備えです。

例えばサイボウズは、故障や災害に備えてバックアップを保管している一方、それは利用者の操作ミスでデータがなくなったときに戻すための仕組みではないと説明しています。サービス会社にバックアップがあっても、自社が戻したいデータを、希望するタイミングで戻してもらえるとは限らないということです。

受注を管理するシステムを例に考えてみましょう。

サービス会社がシステム全体を元に戻せたとしても、それまで受注内容を確認できなければ、出荷やお客様への対応を止めざるを得ないかもしれません。反対に、自社で受注の一覧を保存していても、その一覧だけで業務ソフトそのものを再び動かすことはできません。

この二つは、どちらかがあれば、もう一方がいらなくなるという関係ではありません。

確認したいのは、「システムを元に戻す備え」と「元に戻るまで仕事を続ける備え」の両方があるかです。

なお、これは「利用する会社がバックアップを取っていなければ、すべて利用する会社の責任」という話ではありません。サービス会社が引き受けている内容と、利用する会社に求められている対応を、分けて確認することが出発点です。

保存先を考える基本は「3-2-1ルール」

役割分担を確認したら、次は保存の仕方です。

基本となるのが「3-2-1ルール」です。IPA（情報処理推進機構）も、大事なデータのバックアップを取るときに、この考え方を使うよう案内しています。

数字	意味
3	元のデータを含めて、合計3つのコピーを持つ。つまり、普段使っているデータ1つとバックアップ2つ
2	2種類の異なる保存機器（保存する道具）に分ける
1	少なくとも1つは、別の場所に保管する

これは「バックアップを3日分取る」という意味ではありません。コピーの数、保存する機器、保管する場所を分けるための考え方です。

例えば、パソコンの中に保存している業務ファイルについて、パソコンにつなぐ外付けの保存機器にバックアップを取り、さらに離れた場所にあるクラウドにもバックアップを置く形が考えられます。

この形なら、パソコンの故障に備えるだけでなく、事務所の火災や盗難で、パソコンと外付けの保存機器を同時に失う事態にも備えられます。もちろん、実際には保存するデータの範囲や更新の頻度、クラウド側の保護の設定も確認しなければなりません。

3-2-1ルールの目的は、コピーの数をそろえることではなく、一つの事故ですべてを失わない形にすることです。

ランサムウェア対策では「別の場所」だけでは足りない

ランサムウェアとは、データを勝手に使えない状態にして、元に戻す代わりにお金を要求する悪質なプログラムです。ここで気をつけたいのが、保管場所を分けることと、攻撃の被害を分けることは、同じではないという点です。

離れた場所のクラウドに保存していても、普段使うパソコンから自由に消せる状態なら、そのパソコンやログイン用のIDとパスワードを奪われたときに、バックアップまで被害を受けるおそれがあります。英国の政府機関であるNCSCも、つないだままのUSBメモリーや社内ネットワーク上の共有の保存機器だけでなく、クラウド上のバックアップが攻撃を受けた例を踏まえ、ネットワークから切り離した備えを重視しています。

そのため、3-2-1ルールに加えて、バックアップを簡単に消されたり、書き換えられたりしない仕組みを考えます。

具体的には、バックアップを取った後に外付けの保存機器をネットワークから外す方法や、決めた期間は削除や変更ができないようにする「書き換え禁止」の機能（イミュータブルと呼ばれます）を使う方法です。バックアップを管理する権限を、普段の業務で使うアカウントと分けることも重要です。ただし、削除をどこまで防げるか、管理者がどんな条件で解除できるかは、製品や設定によって確認が必要です。

また、パソコンとクラウドの中身を自動で同じにする「同期」をしているだけで安心しないことも大切です。

例えばOneDriveでは、同期しているフォルダーの中のファイルを消すと、クラウド側からも消えます。ごみ箱や過去の履歴から戻せる場合はありますが、「パソコンとクラウドの両方に見える」ことだけで、別に保管されたバックアップがあるとは言えません。

場所が別でも、同じ操作や同じ侵入のされ方で全部消せるなら、備えとしては弱い。　この視点で保存の仕方を点検する必要があります。

SaaSでは「何を取り出せるか」から確認する

インターネット経由の業務ソフトの場合、利用する会社がサーバー全体をコピーすることは通常できません。ソフトに用意されているデータの書き出し機能や、対応しているバックアップ取りのサービスを使って、保存できる範囲を確認することになります。

例えばkintoneでは、登録したデータを表計算ソフトで開ける形式（CSVファイル）に書き出して保存する方法が案内されています。ただし、書き出せるデータには制限があり、アプリの設定などを保存するには別の機能が案内されています。データを書き出せることと、サービス全体を元の状態に戻せることは、同じではありません。

そのため、ただ「CSVを保存する」と決めるのではなく、次のように目的から考えます。

受注内容やお客様の連絡先が見られれば、サービスが止まっている間も電話対応を続けられるのか。請求書のPDFがあれば、入金の確認や再発行に対応できるのか。それとも、データ同士のつながりや添付ファイル、設定まで戻さなければ業務を再開できないのか。

必要な範囲が分かったら、取り出せるデータについて、普段使う環境とは管理を分けた保存先や、ネットワークから外して保管する機器を組み合わせていきます。これは3-2-1の考え方を業務ソフトに当てはめる方法ですが、一部のデータだけを保存して、業務ソフト全体のバックアップが取れたと考えないことが重要です。

また、別のクラウドサービスを使っただけで、「2種類の保存機器」や、別に管理された保管場所を用意できたとすぐに判断しない方がよいでしょう。クラウドは利用者から見えない部分もあるため、保管場所だけでなく、管理の権限や削除の制限、トラブルのときの取り出し方まで確認します。

取り出せない情報が業務にとって重要なら、その制約自体を、サービスを選ぶときや使い続けるかどうかの判断材料に含めるべきです。

「誰が取るか」だけでなく、「誰が確認するか」まで決める

バックアップを取る作業は、IT支援会社などに任せることができます。しかし、自社がどの程度データを守る必要があるかを決め、任せる先と合意し、きちんと行われているかを確認する役割は自社に残ります。IPAも、ITサービスを外部に任せる範囲をはっきりさせ、安全対策の内容を契約などで確認することを、取り組むべき項目として挙げています。

例えば、次のように担当を整理すると、作業の抜けを見つけやすくなります。

決めること	担当の置き方の例
守るデータと、どれだけの時間なら業務が止まっても耐えられるかを決める	経営者・業務の責任者
保存の仕方を決め、バックアップを取る	社内のIT担当者または委託先
失敗の知らせを確認し、対処する	日々の運用の担当者
バックアップからデータを戻し、業務で使えることを確かめる	IT担当者・委託先と業務の担当者

この表は役割分担の例です。一人が複数を兼ねても構いませんが、担当者の名前と、その人が不在のときの対応は決めておきたいところです。

さらに、バックアップは「取得成功」という表示だけで終わらせず、定期的に実際にデータを戻してみる必要があります。米国の政府機関であるCISAも、重要なデータについて、ネットワークから切り離し、第三者に読めない形にしたバックアップを持ち、それが使えるか、欠けていないかを定期的に確認することをすすめています。

例えば、毎日夜にバックアップを取っているなら、昼間に事故が起きると、その日に入力した分が戻らない可能性があります。バックアップのデータを取り出せても、設定のやり直しや確認に丸一日かかるなら、翌朝からいつも通り営業できるとは限りません。

「何時間分のデータなら入力し直せるか」「何時間までなら業務を止められるか」を先に決め、その条件に合うバックアップの取り方と、元に戻す手順を試して確かめます。試すときは、普段使っているデータをうっかり上書きしないよう、安全な環境・方法で行うことが前提です。

なお、バックアップは主に元に戻すための備えです。盗まれた情報を取り戻したり、情報が外に漏れること自体を防いだりする対策の代わりにはなりません。誰がデータを見られるかの管理などの予防策も、別に必要です。

バックアップのゴールは、データを置くことではなく、仕事を再開できること

「クラウド会社が取っているはず」
「業務ソフトの会社が対応するはず」
「保守会社に任せているはず」

こうした思い込みのすき間に、担当が決まっていない作業を残さないことが大切です。

まずは、止まると業務が困るサービスを一つ選び、契約上の役割、保存できるデータ、保存先、元に戻す方法を確認してみてください。そのうえで、3-2-1ルールを基本に、一つの故障や攻撃ですべてを失わない形を考えます。

バックアップの仕組みは、保存容量を増やした時点でも、ソフトを入れた時点でも完成しません。

誰がバックアップを取り、誰が確認し、事故のときに誰が戻すのか。その手順を実際に試して、仕事を再開できると確かめるところまでが、バックアップの運用です。

---

※本記事のサービス規約・公開情報は2026年10月8日時点で確認しています。具体的な役割分担や補償条件は、利用するサービスの最新の規約・個別の契約をご確認ください。本記事は、特定の事故における法的責任を判断するものではありません。