SharePoint Onlineへ移行すると「フォルダーだけ以前の状態に戻したい」という相談が増えます。ところがSPOはNTFSの「以前のバージョン」と同じ発想では復旧できません。本記事では標準機能の限界と、事故別の現実的な復旧手順・再発防止策を具体的にまとめます。
SharePoint Onlineで“フォルダー単位の時点復元”が欲しくなる典型シーン
オンプレのファイルサーバー（NTFS）では、ボリュームシャドウコピー等を使った「以前のバージョン」で、フォルダー階層ごと“ある時点の姿”に戻せる運用が成立していました。ところがSharePoint Online（SPO）では、同じように「フォルダーだけを最後に正常だった状態へ巻き戻す」操作が頻繁に必要になります。
- 同期（OneDrive同期）中に、誤ってフォルダーを別の場所へドラッグしてしまった
- フォルダー名を変えた結果、参照しているユーザーが「消えた」と勘違いして業務停止した
- フォルダー配下の大量ファイルが一括移動され、元の位置が分からなくなった
- 削除ではないためごみ箱に存在せず、復元ボタンが効かない
特に「移動／名前変更」は“データの存在はしているのに見つからない”状態を引き起こし、現場の混乱が大きいのが厄介です。
結論：SharePoint Onlineの標準機能だけではフォルダー単位の時点復元はできない
まず結論から言うと、SharePoint Onlineの標準機能には、NTFSの「以前のバージョン」のように特定フォルダーだけを過去時点へ巻き戻すための“専用ボタン”や“復元ウィザード”は用意されていません。標準でできるのは大きく分けてファイル単位（バージョン履歴）とライブラリ全体（復元）であり、「フォルダー丸ごとの時点復元」は想定外の領域になります。
まず押さえる：SPOの復旧手段は“削除対策”と“編集対策”で性格が違う
フォルダー復元が難しいと感じる原因は、SPOの回復機能が「削除」「編集」「大量変更（ランサムウェア等）」といった事故タイプごとに分かれているためです。フォルダーという単位は、復旧機能の中心に据えられていません。
| 手段 | 戻せる範囲 | 主に強い事故 | 主に弱い事故 | 運用上の注意 |
|---|---|---|---|---|
| ごみ箱（第1/第2） | 削除されたファイル/フォルダー | 誤削除 | 移動/名前変更、上書き | 保持は原則93日。削除していないものは出てこない |
| バージョン履歴 | ファイル単位（過去版に戻す） | 誤上書き、破損 | フォルダー構造の巻き戻し | バージョン管理が無効だと復旧力が落ちる |
| 「このライブラリを復元」 | ドキュメント ライブラリ全体 | 大量変更、誤移動/誤名前変更を含む一括巻き戻し | 影響範囲を絞った復元 | 直近30日を目安。サイト管理者が実行 |
| Microsoftサポートへの復元依頼 | サイト コレクション/サブサイト単位（状況依存） | UIで回復できない重大事故 | ファイル/フォルダー単体 | 依頼可能期間や可否は条件次第 |
| Microsoft 365 Backup 等のバックアップ | バックアップ時点から（サービスによりフォルダー/ファイル単位も） | 監査・復元要件が厳しい組織 | 未導入の環境 | 有償。復元先を“新URL/別場所”に出せると安全 |
上の表で重要なのは、ごみ箱は「削除」に強いが、移動／名前変更には基本的に効かないという点です。ごみ箱保持が93日であること、また「このライブラリを復元」が直近30日分の操作を元に戻す設計であることは、復旧手順を組むうえで前提になります。
標準機能の“現実解”は3本柱：追跡して戻す／ライブラリを巻き戻す／バックアップで救う
追跡して戻す：移動・名前変更は「監査ログ」で所在を突き止める
移動／名前変更で「消えた」ように見える場合、最初にやるべきは“復元”ではなく“追跡”です。Microsoft Purview の監査ログ（統合監査ログ）には、SharePoint/OneDriveのフォルダー操作としてMoved folder（FolderMoved）やRenamed folder（FolderRenamed）が記録されます。つまり「誰が、いつ、どこからどこへ動かしたか」をログから辿れます。
現場で使いやすい手順は次のとおりです。
- 対象ライブラリで、フォルダー名（旧名/現名）や特徴的なファイル名で検索して、まず“現在地”が見つからないか確認する
- 見つからない場合、監査ログで「FolderMoved」「FolderRenamed」「FileMoved」「FileRenamed」などを期間を絞って検索する
- 操作ユーザーと移動先/改名後のパスの手掛かりを得たら、手動で元の位置へ戻す（必要なら権限者が実施）
ポイントは、復旧の意思決定を急ぐ前に「実体はどこにあるのか」を特定することです。フォルダーが見つかれば、単純に“元へ戻す”だけで業務が復旧することも多く、ライブラリ全体を巻き戻すより安全です。
ライブラリを巻き戻す：「このライブラリを復元」でフォルダー移動も含めて戻せる
追跡が難しい（大量の移動、複数ユーザーの操作、同期クライアントが暴走した等）場合は、標準機能の中で最も強力なのが「このライブラリを復元（Restore this library）」です。設定（歯車）メニューから実行し、日付（例：昨日、または任意の日時）を選び、操作の一覧から“戻したい最初の操作”を指定すると、それ以降の変更をまとめて元に戻します。操作の対象にはファイルだけでなくフォルダー操作も含まれます。
ただし、この機能は「フォルダーだけ」を戻すものではなく、ライブラリ全体をその時点に近い状態へ戻す仕組みです。現場では次のような“被害を抑える工夫”が効きます。
| 工夫 | 狙い | 具体例 |
|---|---|---|
| 退避用ライブラリを作る | 巻き戻しで失いたくない変更を避難 | 事故発生後に更新された重要ファイルだけ別ライブラリへコピーしておき、復元後に戻す |
| 復元前に関係者へ周知 | 復元中の編集で“やり直し”が発生するのを防ぐ | 該当ライブラリの編集を一時停止してもらう（Teamsのファイルも同様） |
| まずは最小の巻き戻しポイントを探す | 影響範囲をできるだけ小さくする | 活動フィードの中から「フォルダー移動」直後を狙って戻す |
制限として、復元は主に直近30日分のアクティビティを前提に設計されており、実行できるのはサイト管理者です。また、復元はバージョン履歴とごみ箱を使うため、バージョン管理が無効だと期待した結果になりません。復元できない項目がある場合はログファイルが出力されることがあります。
バックアップで救う：「フォルダー単位で戻したい」を本気で満たすなら
「どうしてもフォルダー単位で過去時点に戻したい」「ライブラリ全体の巻き戻しは業務影響が大きすぎる」という要件があるなら、標準機能だけで解決しようとするのではなく、バックアップ製品を前提に設計するのが現実的です。
たとえばMicrosoft 365 Backupでは、SharePointサイトやOneDriveをバックアップし、復元ポイント（過去時点）を選んで復元できます。さらにプレビュー機能として、バックアップした復元ポイントの中をブラウズ/検索し、ファイルやフォルダーを選択して復元する手順が公開されています。これは「フォルダーだけ時点復元したい」という要求に最も近いアプローチです。
バックアップの導入判断では、次の観点で比較すると失敗しにくいです。
| 観点 | 標準機能（SPO） | Microsoft 365 Backup/サードパーティ |
|---|---|---|
| 復元粒度 | ファイル単位/ライブラリ単位が中心 | サイト/ライブラリ/フォルダー/ファイル（製品・機能により） |
| 復元先 | 基本は元の場所へ巻き戻し | 別場所/新URLへ出して差分マージしやすい |
| 監査・証跡 | 監査ログは追跡に有効 | 復元作業自体も監査対象にできる |
| コスト | 追加コストなし（機能範囲に限界） | 有償（ただし“復旧時間と影響範囲”を買う） |
影響範囲を小さくする設計：フォルダーではなく“ライブラリ分割”で被害半径を縮める
「フォルダー単位で復元できない」問題に対して、現場でよく効くのがライブラリ分割です。なぜなら、標準の強力な復旧機能である「このライブラリを復元」はライブラリ単位だからです。1つの巨大ライブラリに全社データを詰め込むと、1つのフォルダー事故でも“全社に影響する巻き戻し”になりかねません。
| 設計パターン | メリット | デメリット | 向いているケース |
|---|---|---|---|
| 巨大ライブラリ＋深いフォルダー階層 | 見た目がファイルサーバーに近い | 巻き戻しの影響が大きい／移動事故が起きやすい | 移行直後の暫定運用 |
| 用途/部門/案件ごとにライブラリ分割 | 復元の影響範囲を限定しやすい | ライブラリが増えるためガバナンスが必要 | 重要データが多い、運用ルールを作れる |
| メタデータ＋ビュー中心（フォルダー最小） | 検索・抽出が強い／移動事故が減る | 利用者教育が必要 | 長期運用、ナレッジ管理、再利用が多い |
「フォルダー単位の時点復元」がどうしても必要な組織ほど、実は“フォルダーで守ろう”としない方が復旧しやすいことが多いです。守りたい単位をライブラリやサイトに引き上げることで、標準機能のままでも“狙った範囲だけ巻き戻す”運用に近づけます。
「削除」なら簡単に戻せるのに「移動/名前変更」だと辛い理由
ごみ箱は“削除されたアイテム”を元の場所へ戻す設計です。一方、移動や名前変更は「削除ではない」ため、そもそもごみ箱に入りません。結果として、現場では「消えた」と感じるのに復元できず、運用負荷が跳ね上がります。
このギャップを埋めるには、復旧手段を「復元」から「追跡＋整備」へシフトするのがポイントです。具体的には、監査ログで動線を追える状態にしておく、フォルダー運用を深くしすぎない、重要ファイルはメタデータ/ビュー中心にする、といった設計が効きます。
事故パターン別：最短で業務復旧するための実務フロー
| 事故タイプ | 最優先の確認 | 次の一手 | 最終手段 |
|---|---|---|---|
| 誤削除（ファイル/フォルダー） | サイトごみ箱（第1/第2） | 期限内なら復元（原則93日） | バックアップから復元／サポートへ相談 |
| 誤上書き・破損 | 対象ファイルのバージョン履歴 | 直前の正常版へ戻す | ライブラリ復元／バックアップ |
| 誤移動・誤名前変更 | 検索＋監査ログ（FolderMoved/FolderRenamed） | 所在が分かれば手動で戻す | ライブラリ復元（影響に注意）／バックアップ |
| 大量変更（ランサムウェア、同期暴走） | 「このライブラリを復元」の可否 | 最小の巻き戻しポイントを選んで復元 | バックアップでサイト/ライブラリを復旧 |
ごみ箱保持が93日であること、そしてライブラリ復元が直近30日を中心に設計されていることは、復旧のタイムリミットを決める重要な前提です。
Microsoftサポートに相談する場合の現実ライン
標準機能で回復できないとき、管理者がMicrosoftサポートへ問い合わせる選択肢があります。ただし、サポート側の復旧は「何でも戻せる魔法」ではありません。Microsoftのサポート情報として、SharePoint Onlineは削除後も追加期間バックアップを保持しているが、復元対象はサイト コレクションやサブサイトであり、特定のファイル/ライブラリ単位ではない旨が案内されています。したがって“フォルダーだけ復元”の期待値は上げすぎない方が安全です。
機能要望としてフィードバックを上げる価値
フォルダー単位の時点復元は、同じ悩みを抱える管理者が多いテーマです。Microsoftのコミュニティ回答でも「フォルダー単位の復元機能が欠けている」という認識が示され、フィードバックポータルへの提案が推奨されています。組織内で困りごとが継続しているなら、運用対策と並行して、要望を公式ルートに上げておくのは無駄になりません。
再発防止：フォルダー事故を起こさないための設計・設定チェック
バージョン管理を必ず有効化し、上書き事故に強くする
「このライブラリを復元」も含め、SPOの復旧力はバージョン履歴に大きく依存します。運用上の容量や管理負担とのバランスは必要ですが、重要ライブラリでバージョン管理を無効化するのは、復旧オプションを自ら捨てるのに近い判断になります。
監査ログを“使える状態”にしておく
移動/名前変更は「追跡できるか」が勝負です。監査ログでFolderMoved/FolderRenamed、FileMoved/ FileRenamedなどが追えることを理解したうえで、いざという時に検索できる権限（監査閲覧権限）と手順書を準備しておくと、復旧時間が大幅に短縮されます。
同期（OneDrive同期）を“便利機能”ではなく“変更発生源”として扱う
同期は便利ですが、エクスプローラー上のドラッグ＆ドロップがそのまま大量の移動・改名操作になり得ます。さらに、ネットワーク断や競合が重なると、利用者の意図しない変更が連鎖しやすいのも現実です。重要ライブラリでは「同期してよい範囲」「大規模移動はWeb上で実施」「移動前に関係者へ連絡」など、ルール化しておくと事故率が下がります。
“深いフォルダー運用”を減らし、メタデータとビューを活用する
フォルダーは分かりやすい一方で、移動・改名が起きた瞬間に「居場所が分からない」事故になりやすい構造でもあります。SharePointの強みは、列（メタデータ）とビューで分類・抽出できる点です。深い階層で整理するほど、同期やドラッグ＆ドロップの誤操作が致命傷になります。フォルダー階層は最小限にし、分類はメタデータとビューに寄せると、事故の種類そのものを減らせます。
バックアップを“最後の砦”ではなく“要件”として選ぶ
「フォルダー単位で過去時点に戻せないと困る」という要件が明確なら、導入前にバックアップの粒度と復元先（別場所へ戻せるか）まで含めて設計すべきです。Microsoft 365 Backupのように復元ポイントから選択復元（フォルダー/ファイル）ができる仕組みは、標準機能の穴を埋める現実解になります。
よくある質問
フォルダーにも「バージョン履歴」はありますか？
ファイルにはバージョン履歴がありますが、フォルダー全体を“その時点の状態”として管理し、ワンクリックで巻き戻す仕組みは標準では提供されていません。フォルダー配下の各ファイルのバージョンは戻せても、フォルダー階層の復元は別問題です。
「このライブラリを復元」を実行したら元に戻せますか？
復元後に「やっぱりやめたい」となった場合、同じ画面から復元操作自体を元に戻す導線が用意されています。とはいえ、復元は広範囲に影響する可能性があるため、実行前の退避と周知は必須です。
復旧のタイムリミットはどこですか？
削除の場合はごみ箱保持（原則93日）が目安です。大量変更などでライブラリを巻き戻す場合は、ライブラリ復元が直近30日分の活動を基準に設計されている点を意識してください。要件がそれ以上の期間や粒度を求めるなら、バックアップ（Microsoft 365 Backupやサードパーティ）を前提にするのが安全です。
まとめ：SPOの限界を知り、復旧手順を“運用として”準備する
SharePoint Onlineは、NTFSのようにフォルダー単位で過去時点へ戻す設計ではありません。だからこそ、事故が起きたときに「削除ならごみ箱」「上書きならバージョン」「移動/改名なら監査で追跡」「最悪はライブラリ巻き戻し」「要件が厳しければバックアップ」という判断軸を、事前に手順化しておくことが最大の対策になります。復元ボタンが無いことを嘆くより、SPOの強み（監査・検索・バージョン・バックアップ連携）を使って“復旧できる運用”へ寄せていきましょう。
コメント