SharePoint にバックアップが必要な理由は、Microsoft の保護機能に限界があるからだけではありません。企業が日常的に直面するさまざまなリスクが、標準機能の範囲を超えてデータを消失させる可能性を持っています。具体的にどのようなリスクがあるかを整理しておくことが、経営層への説明責任を果たす上でも重要です。
ユーザーが誤ってファイルを削除した場合や、ランサムウェア感染によってデータが暗号化された場合など、「人的・外的要因によるデータ消失」が発生する可能性があります。こうした事態に対して、Microsoft の標準機能がどこまで対応可能なのかを、あらかじめ明確に整理しておく必要があります。
この記事では、SharePoint の標準保護機能の実態から外部バックアップの必要性、さらには運用設計の考え方まで、情シス担当者・企業管理者が押さえるべき情報を体系的に解説します。自社のバックアップ体制を見直すきっかけとしてぜひご活用ください。
多くの企業が「Microsoft がクラウドで管理しているから安全」という前提で SharePoint を運用しています。しかし、Microsoft が提供するのはサービスの継続稼働（可用性）であり、ユーザーデータの完全な復元保証ではありません。この違いを正確に理解しないまま運用を続けると、有事の際に取り返しのつかない事態を招くことになります。
クラウドサービスにおける「共有責任モデル」とは、クラウドプロバイダーとユーザー企業のそれぞれが担うべき責任範囲を明確に定めた考え方です。Microsoft は SharePoint を含む Microsoft 365 において、インフラの冗長性・物理的なセキュリティ・サービスの可用性維持に責任を負っています。
一方でユーザーデータの保護、つまりデータが削除・上書き・破損した場合に備えてバックアップや復元体制を整えることは、共有責任モデル上、主にユーザー企業側の責任領域とされています。Microsoft 365 ではインフラやサービス提供は Microsoft が担い、データ保護やバックアップ設計は顧客側で行うべきと整理されている点が、業界全体でも広く前提とされています。サービスが止まらないことと、データが守られることは別の話だと理解することが出発点になります。
「保持ポリシーを設定しているからバックアップは大丈夫」という誤解は非常に多く見られます。しかし保持機能とバックアップは、目的も仕組みも全く異なるものです。保持機能とは、コンプライアンス要件を満たすためにデータを一定期間削除できない状態にする機能であり、特定の時点の状態を任意に取り出せる「バックアップ」とは異なります。
SharePoint のごみ箱は、第一段階と第二段階を合わせて最大約 93 日間データを保持する仕様であり、この期間を過ぎると完全削除されて復元は原則として不可能です。保持機能はあくまで「保存しておく」ことであり、「確実に戻せる」ことを意味しません。この違いを経営層や現場にも共有することが、適切なバックアップ設計の第一歩です。
上記のような標準機能の制約を踏まえると、企業の SharePoint 運用においては「外部バックアップを前提とした設計」が合理的な判断と言えます。特に、業務上重要なファイルを大量に格納している組織や、コンプライアンス上の長期保存が求められる業種では、標準機能だけで要件を満たすことは困難です。
外部バックアップを導入することで、ユーザー誤操作・内部不正・ランサムウェアといった脅威に対して復元の確実性を高められます。加えて、バックアップデータを Microsoft 365 環境の外に保持することで、クラウド環境そのものが影響を受けた際の最終的な保険としても機能します。
SharePoint にバックアップが必要な理由は、Microsoft の保護機能に限界があるからだけではありません。企業が日常的に直面するさまざまなリスクが、標準機能の範囲を超えてデータを消失させる可能性を持っています。具体的にどのようなリスクがあるかを整理しておくことが、経営層への説明責任を果たす上でも重要です。
最も発生頻度が高いのが、ユーザーによる誤操作です。SharePoint ではファイルの削除・上書き・移動が非常に簡単に行えるため、意図せずに重要なデータを消してしまうケースが頻繁に起こります。
特に問題となるのは、削除に気づくまでに時間がかかるケースです。ごみ箱の保持期間（第一段階・第二段階の合計で 93 日）を超えて発覚した場合は、もはや復元の手段がありません。
また、ファイルを上書き保存してしまった場合も、バージョン履歴の件数上限を超えていると以前の状態に戻せなくなります。こうした日常的な誤操作リスクを考えると、外部バックアップは「万一」の備えではなく、日常的な運用安全網として機能します。
SharePoint は OneDrive の同期クライアントと連携していることが多く、PC がランサムウェアに感染すると、同期を通じて SharePoint 上のファイルまで暗号化されるリスクがあります。この場合、感染が広がる速度が非常に速く、気づいたときには数千ファイルが暗号化済みという事態も発生しています。
バージョン履歴が有効な状態であれば、暗号化前のバージョンに戻せる可能性はありますが、ファイル数が多い場合の復元作業は膨大な工数を要します。また、バージョン履歴の上限を超えていれば完全に対応できません。外部バックアップがあれば、特定の時点に一括でロールバックできるため、復旧速度が大幅に改善されます。
退職者の Microsoft 365 アカウントを削除した際、そのユーザーが所有していた OneDrive データや SharePoint のコンテンツが連動して失われるケースがあります。Microsoft はアカウント削除後のデータを一定期間保持する仕組みを持っていますが、適切な引き継ぎ設定や移行手順が取られていない場合は、データが宙に浮いて消失することがあります。
また、悪意を持った退職者や内部不正者が意図的にファイルを削除・持ち出す行為も、標準機能だけでは事後の完全復元を保証できません。退職処理とデータ保全の手順を組み合わせた設計が求められます。
金融業・医療・製造業など、特定の業種では法令に基づくデータの長期保存義務が課せられています。SharePoint の標準機能では、保持ポリシーである程度の対応が可能です。
ただし、任意の時点への復元・改ざん検知・ログとの紐付けといった要件まで満たすには、別途専用のソリューションが必要になる場合があります。
訴訟対応・監査対応において「復元できなかった」では済まない状況を回避するためにも、法的保存義務の観点からバックアップ設計を検討することが欠かせません。
SharePoint には標準でいくつかのデータ保護機能が備わっています。これらの機能を正確に把握したうえで「何ができて、何ができないか」を整理することが、自社に必要なバックアップ設計を考える基本になります。
SharePoint のごみ箱は二段階構造になっています。ユーザーがファイルを削除すると、まず第一段階のごみ箱に移動し、ここで保持されます。ユーザー自身がさらに空にしてしまった場合は第二段階（サイトコレクションのごみ箱）に移り、第一段階と合算で約 93 日間の保持期間が設けられています。
この 93 日という期間は、気づくのが早ければ十分に機能しますが、数ヶ月後に誤操作が発覚するケースでは対応できません。また、管理者が手動でごみ箱を空にしてしまうと、この保持期間内であっても復元が不可能になります。ごみ箱の保持機能を過信せず、補完的なものとして位置付けることが重要です。
【関連ブログ】
SharePoint のごみ箱はどこ？復元方法・削除方法についても徹底解説！
SharePoint のバージョン履歴機能は、ファイルの変更のたびにバージョンが保存される仕組みです。デフォルトでは最大 500 バージョンが保持されますが、設定によってバージョン数の上限や保持日数を変更できます。
この機能は上書き誤操作や内容の誤変更に対して有効ですが、いくつかの制約を理解することが必要です。まず、バージョン履歴はファイルを削除すると一緒に失われます。次に、上限を超えた古いバージョンは自動的に削除されます。
さらに、ライブラリ単位で有効・無効の設定があるため、設定が無効になっているライブラリでは履歴が残りません。バージョン履歴はあくまで変更管理の補助機能であり、体系的なバックアップには代替できないため、注意が必要です。
Microsoft 365 のコンプライアンス機能として提供されている Microsoft Purview では、保持ポリシーや保持ラベルを活用することで、SharePoint のコンテンツを指定した期間削除できない状態にしたり、自動削除のルールを設定したりすることができます。これはコンプライアンス要件への対応として有効ですが、バックアップの代替にはなりません。
保持ポリシーで保護されたデータは削除されない状態を維持できますが、「任意の時点の状態に戻す」というリストア機能を持つわけではないからです。Purview を活用する場合も、バックアップとは役割を分けて設計することが求められます。
標準機能では対応できない復元不可ケースは複数存在します。たとえば、ごみ箱の保持期間（約 93 日）を超えて削除されたデータは復元できません。バージョン履歴の上限を超えた古いバージョンも同様です。
また、サイトコレクション自体が削除されてから 93 日を超えた場合も復元は不可能になります。Microsoft サポートへエスカレーションすることで復元できるケースもありますが、これは保証されたサービスではなく、対応可否はケースバイケースです。標準機能だけに頼ることのリスクを把握したうえで、外部バックアップの必要性を判断することが適切です。
標準機能の限界を理解した上で、次に問われるのが「では外部バックアップは本当に必要か」という問いです。費用・運用負荷との兼ね合いもある中で、どのような基準で判断すべきかを整理します。
前述の共有責任モデルを改めて確認すると、Microsoft が担うのはインフラ・可用性の維持であり、ユーザーデータの完全な復元保証は企業側の責任とされています。つまり「Microsoft が責任を持ってくれる」という前提は、データ保護の観点では成立しません。
企業側の責任として求められるのは、誤操作・悪意ある操作・外部攻撃によるデータ消失に備えた体制を自ら整えることです。この責任範囲を正確に把握することが、外部バックアップを導入するかどうかの判断根拠になります。
バックアップ設計において重要な指標が RPO（Recovery Point Objective：目標復旧時点）と RTO（Recovery Time Objective：目標復旧時間）です。RPO は「どの時点のデータまで失っても許容できるか」を示し、RTO は「何時間以内に業務を再開する必要があるか」を示します。たとえば RPO が 24 時間以内であれば、1 日 1 回のバックアップで対応可能です。
一方で RPO を数時間単位で設定する必要がある業務では、より頻繁なバックアップが必要になります。SharePoint の標準機能では RPO・RTO を企業側が制御する手段が限られるため、外部バックアップによって要件を満たす設計が必要になることが多いです。
外部バックアップを実現する手段として広く活用されているのが、サードパーティ製のバックアップサービスです。これらは自動スケジュール・世代管理・粒度の高い復元（ファイル単位・サイト単位）など、標準機能では得られない機能を提供しています。
代表的なサービスとしては、Veeam Backup for Microsoft 365 や AvePoint Cloud Backup などが Microsoft 365 に特化したソリューションとして知られています。選定においてはバックアップ頻度・保持世代数・復元の粒度・保存先の柔軟性・価格を比較検討することが重要です。
外部バックアップを取得する場合、バックアップデータをどこに保存するかも設計上の重要な選択です。自社管理のオンプレミスサーバーに保存する場合は、データ主権を完全に自社で管理できる反面、ストレージ運用の負担が発生します。
クラウドストレージ（Azure Blob Storage・AWS S3 など）を保存先にする場合は拡張性が高く、運用負荷を抑えられますが、Microsoft 365 環境と別のクラウドを使うなど、障害影響範囲を分散させる設計が望まれます。自社のセキュリティポリシーとコスト感の両面から選択することが求められます。
外部バックアップの必要性を認識した後は、具体的にどのような設計で運用を構築するかが問われます。ここでは実務的な視点から設計の考え方を整理します。
バックアップの頻度は、業務の重要度と更新頻度によって決定することが基本です。毎日更新される契約書・設計データ・顧客情報などは少なくとも 1 日 1 回のバックアップが望まれます。一方、参照頻度が低いアーカイブ的なコンテンツであれば、週 1 回程度でも許容できる場合があります。
前述の RPO を基準に、業務カテゴリ別にバックアップ頻度を設定することで、コストと保護レベルのバランスを取った設計が可能になります。一律に同じ頻度で全データをバックアップするよりも、重要度別に細分化した設計のほうが実運用での継続性を高めます。
バックアップデータを何世代分保持するかも設計の核心です。世代数が少なければコストは抑えられますが、過去に遡って復元できる範囲が狭まります。一般的には直近 7 世代（日次）・月次・年次のように階層化して管理する「GFS（Grandfather-Father-Son）方式」が多く採用されています。
法的保存義務がある場合は、数年単位での長期保存が必要になることもあります。長期保存データはコールドストレージへ移行させることでコストを最適化しながら保持する設計も有効です。世代管理の設計は一度決めたら終わりではなく、業務要件の変化に応じて定期的に見直す運用が求められます。
ランサムウェア対策の観点では、バックアップデータそのものが攻撃対象になるリスクを考慮した設計が必要です。たとえばバックアップ先が Microsoft 365 環境と同じ認証基盤で管理されている場合、アカウント乗っ取りによってバックアップデータまで消去・暗号化される危険性があります。
これを防ぐには、バックアップデータを別環境・別認証で管理する「オフライン / オフサイトバックアップ」の考え方が有効です。さらに、イミュータブルストレージ（書き換え不能なストレージ）を活用することで、バックアップデータへの不正な改ざん・削除を防止できます。多層防御の観点でバックアップ設計を組み立てることが、高度な脅威への対策になります。
バックアップは取得しているだけでは意味をなさず、実際に復元できることを確認して初めて機能します。定期的な復元テストを実施しない場合、有事の際に「バックアップは取れていたが、復元できなかった」という最悪の事態が発生することがあります。
復元テストは四半期に 1 回程度を目安に、実際の業務データに近い環境で実施することが望まれます。テストの際はファイル単位・サイト単位・全体単位など、粒度を変えて実施することで、復元プロセスの実効性を確認できます。テスト結果はドキュメント化し、担当者が変わっても手順を継承できる体制を整えることも重要です。
実際に発生したトラブル事例を知ることで、「自社でも起こりうる」というリスク感度を高めることができます。以下に代表的なケースを整理します。
ある企業で、プロジェクト完了後に担当者が誤って重要な資料フォルダを削除してしまいました。削除直後は誰も気づかず、93 日以上が経過した後に「あのファイルが必要だ」と発覚したケースです。この時点で SharePoint のごみ箱からは既に完全削除されており、Microsoft サポートへの問い合わせでも復元は叶いませんでした。
このケースから得られる教訓は、保持期限に依存した運用の危うさです。93 日という期間は一見長く感じますが、業務の進行スピードによっては気づくまでに超過してしまいます。外部バックアップが有効であれば、遡った時点のデータを取り出せる可能性があります。
複数の従業員が同時期に退職した際、管理担当者が Microsoft 365 のアカウントを一括削除しました。しかしその中の一人が、SharePoint 上の重要な業務ドキュメントのオーナーになっており、アカウント削除と同時にデータへのアクセスが失われるという事態が発生しました。
Microsoft はアカウント削除後のデータを一定期間保持していますが、管理者が適切な保全措置を取っていなければデータは失われます。退職者対応フローにデータ引き継ぎ確認のステップを組み込むとともに、外部バックアップで定期的にデータを保全する体制が重要であることを示すケースです。
社内のあるユーザーが PC の移行作業中に、OneDrive の同期設定を誤って操作し、SharePoint に同期されていた大量のファイルが一斉に削除されました。同期処理はほぼリアルタイムで行われるため、SharePoint 上のデータも瞬時に削除され、気づいた頃には数百ファイルが消えている状態でした。
バージョン履歴とごみ箱を使って一部は復元できましたが、全ファイルの復元作業には相当な時間と工数がかかります。外部バックアップがあれば、特定時点の一括復元が可能であり、復旧速度を大幅に短縮できたケースです。同期クライアント経由のリスクは見落とされがちですが、実際の事故原因として非常に多い類型です。
SharePoint のバックアップに関しては、現場の担当者からよく寄せられる疑問がいくつかあります。「そもそも自動バックアップはないのか」「OneDrive とは何が違うのか」といった基本的な問いから、ランサムウェア対応の実態まで、正確な情報をもとに一つひとつ整理しました。自社の運用設計を見直す際の参考にしてください。
Microsoft 365 側ではサービス保護のためのバックアップが内部的に実施されていますが、ユーザーが任意の世代を指定して復元できる「完全なバックアップ」として提供されているわけではありません。SharePoint にはごみ箱（最大約 93 日）やバージョン履歴機能がありますが、保持期限を超えたデータや完全削除されたデータは原則として復元できない仕様です。
企業として長期保存・世代管理・確実な復元保証が必要な場合は、これらの標準機能を補完する形で外部バックアップ設計を行うことが求められます。「自動バックアップがある」という認識のまま運用を続けることは、有事の際のリスクにつながります。
SharePoint はチーム・組織向けの共同作業用ストレージであり、OneDrive は個人ユーザー向けのストレージという位置づけです。技術的には同じ基盤を利用していますが、管理単位や利用目的が大きく異なります。
OneDrive のデータも、退職者アカウントの削除や保持期限の経過によって消失するリスクを持っており、SharePoint と同様にバックアップ設計の対象として考える必要があります。Microsoft 365 全体のデータ保護を考える際は、SharePoint と OneDrive を一体的に設計することが望ましいです。
条件付きで対応できる場合があります。バージョン履歴が有効な状態であれば、暗号化が行われる前のバージョンに戻せる可能性があります。ただし、バージョン数の上限を超えていたり、保持期限を過ぎていたりする場合は復元できません。
また、OneDrive 同期クライアント経由で大量のファイルが一斉に暗号化・削除されると、影響範囲が広がり手作業での復元が現実的でない状況になることもあります。ランサムウェア対策としては、外部バックアップと組み合わせた多層防御の設計が強く推奨されます。
小規模な利用で短期間の保持のみが目的であれば、SharePoint の標準機能で対応できるケースもあります。しかし、監査対応・法的な長期保存・世代管理・確実な復元保証が求められる企業利用においては、標準機能だけでは不十分になる場面が多いのが実情です。
自社の RPO・RTO を整理したうえで、標準機能で充足できる要件と外部バックアップで補う必要がある要件を切り分けることが不可欠です。「無料だから使わない理由がない」という発想ではなく、「自社の要件に対して何が足りないか」という視点で判断することを推奨します。
SharePoint の標準機能は可用性の確保に優れている一方で、ユーザー誤操作・ランサムウェア・退職者アカウント削除といった人的リスクへの復元保証は限定的です。自社の RPO・RTO を基準に外部バックアップを組み合わせた多層的な設計を行うことが、データ消失リスクを最小化する現実的なアプローチです。バックアップは取得するだけでなく、定期的な復元テストと運用の継続が不可欠です。
SGプラス株式会社は、Microsoft 365 を中心としたクラウド環境のセキュリティ・運用設計・バックアップ体制の構築支援を提供しています。SharePoint をはじめとする Microsoft 365 製品のデータ保護設計から、運用定着までをトータルでサポートしています。
標準機能だけでは不安を感じている企業や、バックアップ体制を一から見直したい情シス担当者の方は、ぜひ SGプラスにご相談ください。貴社の環境・規模・業種に合わせた最適な設計をご提案します。
SharePoint の関連ブログ一覧は こちら
関連サービス：SharePoint ポータルサイト構築支援サービス