Microsoft 365の標準機能だけで十分？ バックアップが必要になるケースとは

第1回では、Microsoft 365（M365）に蓄積された業務データの見つかり方と使われ方が、Copilotによって変わることを説明しました。メールや文書、チャット、会議の記録は、従業員が参照するだけでなく、Copilotが回答を生成したり、資料作成を支援したりする際にも活用されます。

今回は、こうした業務データを失わないための備えとして、バックアップを取り上げます。

閉じる

生成AI時代にバックアップが重要になる理由

従来、バックアップの主な目的は、誤削除やシステム障害、ランサムウェアなどでデータを失った際に復旧し、業務を再開できるようにすることでした。この役割は現在も変わりません。ただし、生成AIを業務に取り入れた企業では、もう1つの意味が加わります。AIが活用する業務データそのものを守るという意味です。

例えば、長年の取引経緯を記したメールや、判断の理由を残した会議資料が失われたとします。担当者がそれらを参照できなくなるだけでなく、Copilotもその情報を回答の材料にできなくなります。質問に対する回答が必ず誤るわけではありませんが、参照できる記録が欠ければ、必要な経緯を十分に示せなくなる可能性があります。利用者がその不足に気づかないまま回答をもとに次の仕事を進めれば、情報の欠落は業務判断にも影響し得ます。

生成AIの導入によって変わったのは、これまで守ってきた業務データの用途です。業務の復旧に必要なデータと、AIが日々の業務で活用するデータを併せて見渡すことが、バックアップを考える出発点になります。

M365で失われる可能性があるデータ

M365のデータ消失というと、大規模なサイバー攻撃を想像しがちです。しかし、日常の運用にも原因はあります。従業員がファイルを誤って削除したり、必要な記述を上書きしたりすることは珍しくありません。管理者による設定変更や操作ミス、アカウントの削除などが、後になってデータの利用に影響する場合もあります。

悪意のある行為にも備える必要があります。侵害されたアカウントからファイルが削除・改ざんされる場合や、ランサムウェアによって暗号化されたファイルが同期される場合です。内部不正によって重要な記録が意図的に消される可能性もあります。また、設定した保持期間が過ぎてから過去の資料が必要になっても、すでに取り戻せないことがあります。

データ消失による影響は、失われた情報の重要性によって異なります。例えば、案件の経緯を示す唯一の記録が失われれば、利用者だけでなくCopilotも、その経緯を確認するための情報を参照できなくなります。重要なのは、ファイルの数ではなく、後から必要になる情報を復旧できるかという視点です。

Microsoft 365の標準機能でできること

M365には、データを削除・変更してしまったときに役立つ機能が用意されています。バックアップを検討する前に、標準機能で何を戻せるのかを確認しておきます。

SharePoint OnlineやOneDrive for Businessで削除したファイルは、一定期間、ごみ箱から復元できます。いずれも一次・二次のごみ箱を合わせた保持期間は、通常、削除から93日です。Exchange Onlineのメールにも削除済みアイテムを復元する仕組みがあり、復元可能なアイテムの保持期間は既定で14日、設定により最大30日まで延長できます。

誤って内容を書き換えたファイルには、バージョン履歴が役立ちます。過去の版を確認し、必要に応じて戻せるためですOneDrive for Businessには、直近30日以内の変更をまとめて元に戻す機能があります。SharePoint Onlineでも、サイト管理者は対応するドキュメントライブラリを過去30日以内の状態に復元できます。多数のファイルが短期間に変更された場合には、有効な手段となります。

さらに、利用しているライセンスや設定に応じてMicrosoft Purviewの保持ポリシーを使えば、定めた期間にわたりデータを保持できます。これは、法令や社内規則への対応、監査などを目的として情報を残すための仕組みです。削除された情報を保持できる場合もありますが、保持していることと、業務で使える元の状態へ迅速に復旧できることは同じではありません。

これらの機能は有用であり、事故が起きたらまず確認すべき復旧手段です。ただし、対象となるデータ、戻せる期間、復元の単位や方法は、機能ごとに異なります。設定やライセンス、サービスの仕様によっても利用条件が変わり得るため、自社の環境で実際に何ができるかを把握しておく必要があります。

標準の復元機能とバックアップの違い

標準機能とバックアップの違いは、復元できるかできないかだけでは整理できません。判断の鍵となるのは、事故の後にどのデータを、どの時点の状態へ、どの範囲まで戻す必要があるかという点です。

例えば、誤って削除した1つのファイルにすぐ気づいたのであれば、ごみ箱からの復元で十分かもしれません。上書き前の内容を確認したいのであれば、バージョン履歴が適しています。一方、数カ月前に削除されたことが判明したファイルは、ごみ箱の保持期間を過ぎている可能性があります。

複数の部署にまたがるデータが改ざんされた場合には、個々のファイルを手作業で戻すだけでは、業務再開に時間がかかります。ランサムウェアによって多数のファイルが暗号化された場合には、影響が及ぶ前の時点を特定し、広い範囲を確実に復旧できる手段が必要になります。

保持ポリシーとバックアップの目的も区別しておきたい点です。保持ポリシーは、一定の情報を定められた期間残すことに重点があります。バックアップでは、それに加えて、必要なデータを選び、事故前の利用可能な状態へ戻すための手順が重要になります。監査用に情報を確認できることと、従業員が従来の場所で仕事を再開できることは、別の要件です。

特に注意したいのが、保全対象の違いです。M365には、メール、SharePoint OnlineやOneDrive for Businessのファイル、Teamsのチャット、会議に関連するファイルや記録など、性質の異なる情報があります。Teamsで共有したファイルは保存先がSharePoint OnlineやOneDrive for Businessである一方、チャットの本文まで同じ方法で戻せるとは限りません。Teamsを保護しているという説明だけで判断せず、チャット本文と共有ファイルをそれぞれどう扱えるかを確認する必要があります。

監査やコンプライアンス対応では、事故から復旧できるだけでなく、過去の文書やメール、変更の履歴を定められた期間確認できることも求められます。必要な期間が標準機能の保持期間を超える場合は、長期保全の方法を別途検討することになります。ただし、データのバックアップだけで、誰がいつ何をしたかを示す証跡まで残せるとは限りません。操作記録については、監査ログの保存期間や取得方法も併せて確認する必要があります。

また、バックアップデータの保存先や管理権限も重要です。M365上のデータを、原本と同じ認証・管理権限で操作できる場所にコピーするだけでは、管理者アカウントが侵害された際に、原本とコピーの両方を削除・改ざんされるおそれがあります。バックアップを検討する際は、原本に影響を及ぼした操作や攻撃から、復旧用データをどの程度守れるかも確かめておきます。

現在はMicrosoft自身も「Microsoft 365 Backup」を提供しており、バックアップは必ず外部製品で行うものという分け方はできません。まず自社の復旧要件を定め、Microsoftの標準的な復元・保持機能で満たせる部分と、別途バックアップ機能が必要な部分を見極めることが重要です。

生成AI時代のバックアップ設計

では、何を基準にバックアップを設計すればよいのでしょうか。以下の4点を順に確認します。

守るべき情報の範囲を決める

メールやファイルだけでなく、業務判断の経緯が残るチャットや会議関連のデータも候補となります。Copilotが利用し得る情報をすべて一律に保存するのではなく、業務上の重要性、保存期間、復旧の必要性を見て対象を決めます。

復旧の単位と時点を定める

誤削除された1通のメールや1つのファイルを戻したいのか、部署の共有領域を広く戻したいのか。事故に気づくまでにどれくらい時間がかかり、何日前の状態まで遡る必要があるのか。これらを想定しなければ、バックアップを取得していても、必要な場面で使えない可能性があります。

アカウント整理とデータ保全を切り離さない

退職者のアカウント削除やライセンス変更に伴って、重要なデータがどう扱われるかも確認します。担当者が変わった後でも、過去の契約や判断の経緯を参照する必要は生じます。アカウントを整理する手順と、残すべき業務データの引き継ぎ・保全は、一体で設計します。

復旧手段を平時に試す

バックアップがあるという記録だけでは、必要なデータを希望する場所へ、許容できる時間内に戻せるかは分かりません。対象データを選んで復旧し、内容を確認するところまで試して初めて、業務継続に役立つ備えになります。

まとめ

生成AIの活用が進んでも、バックアップの基本的な役割は変わりません。変わるのは、守る対象の意味です。M365上の業務データは、従業員が参照する記録であると同時に、Copilotが回答を組み立てる際の材料にもなりました。そのため、失われた情報は業務の停滞だけでなく、AIが示す内容の確かさにも影響し得ます。標準機能で戻せる範囲を正しく把握したうえで、自社が必要とするデータ、時点、範囲に照らして不足する部分を補うという順序で検討することが重要です。次回は、もう一方の視点である権限管理を取り上げます。残したデータを誰が利用できるかを、Copilot時代にどう見直すべきかを解説します。