OneDriveを再インストールしてSharePointライブラリを同期し直した直後、共有フォルダーが空になり「ファイルが消えた」ように見える――この手のトラブルは現場で起きると焦ります。この記事では、原因の切り分けから、SharePointの「ライブラリの復元」で安全に戻す実務手順、代替の復旧ルート、再発防止までをまとめます。
起きた現象:OneDrive再インストール後、SharePointフォルダーが空になり「ファイルが消えた」
社内でSharePoint+OneDrive同期を利用しており、ユーザーはPCのOneDriveフォルダー(エクスプローラー)から共有データにアクセスしていました。ところが、あるユーザーがOneDriveをアンインストール後に再インストールし、同期をやり直した直後から次のような症状が発生しました。
- SharePoint上で151個のフォルダーが「追加されたフォルダー」として新規作成されたように見える
- 該当フォルダーの中身がすべて空(ファイルが消えているように見える)
- 以前は中身があったことは確実
- SharePointのごみ箱/第2段階ごみ箱、OneDrive側のごみ箱にも該当ファイルがない
- OneDriveクライアントの履歴上も「削除」の記録が見えない
- 「ライブラリの復元」画面でも「フォルダーが追加された」履歴しか見えず、「削除」履歴が見えない
この状況でよく出る相談が、次の2点です。
- ライブラリ全体を問題発生直前の時刻に「復元」しても安全か?
- 他に元に戻す手段はないか?
まず確認:本当に「消えた」のか、それとも「見えていない」だけか
復旧作業に入る前に、“消失”に見えるだけのパターンを先に潰します。ここを飛ばすと、復元の巻き戻しで余計な影響を出すことがあります。
| 確認ポイント | よくある落とし穴 | 確認方法(現場向け) | 判断 |
|---|---|---|---|
| 見ている場所が正しいか | 別サイト/別ライブラリ/別フォルダーを見ている | SharePointのサイト コンテンツから対象ライブラリを開き、URLとライブラリ名を確認 | 場所違いなら「消失」ではない |
| ビューのフィルター | フィルターで非表示になっている | 「すべてのドキュメント」など標準ビューに切替、フィルター解除 | 表示条件の問題なら復元不要 |
| 権限 | ユーザー権限で見えない(管理者は見える/逆もあり) | 管理者・サイト所有者・一般ユーザーの複数アカウントで同じ場所を確認 | 権限が原因なら設定見直し |
| OneDrive同期の「見え方」 | 同期が止まっているだけで、SharePoint上は残っている | SharePointのWeb画面でファイル数を確認し、OneDriveのアクティビティセンターでエラー有無を確認 | Webに残っていれば復旧は不要 |
| 「ショートカットをOneDriveに追加」と混在 | 同期(Sync)とショートカットが混ざり、別フォルダーを見ている | エクスプローラー側で「建物アイコン(組織)」配下の表示や、ライブラリの接続状況を確認 | 混在はトラブルの温床 |
上記を確認しても、SharePointのWebでも空・ごみ箱にもない・履歴も薄い、となると「何らかの形でライブラリの内容が以前の状態から変わった」可能性が高いです。ここから復旧手段の検討に入ります。
なぜ「削除履歴なし」で空になることがあるのか:原因の考え方
このケースは、いわゆる「ユーザーが大量削除してごみ箱に入った」パターンと違い、画面上の手掛かりが乏しいのが特徴です。現場で説明しやすいように、起こり得るメカニズムを“可能性”として整理します(実際の原因特定には監査ログ等が必要です)。
OneDriveアンインストールで「同期情報」がリセットされる
OneDriveのアンインストールやリセットは、PC上の同期設定・キャッシュ・ローカルに保持していた差分情報を大きく変えます。再インストール後の初回同期は、クライアントが“新規端末・新規同期”に近い状態で動き始めるため、次のようなズレが起こりやすくなります。
- ローカル側のフォルダー構造だけが残り、ファイルは未取得/未存在の状態になっている
- サーバー側からの取得が一時的に不完全で、空フォルダーとして認識される
- 同期の初期化タイミングで差分処理が崩れ、“想定外の大量変更”としてサーバーへ反映される
「削除」ではなく「上書き的な変化」として扱われると、見え方が変わる
現象としては、
空のフォルダー構造が同期され、結果として「ファイルが消えたように見える」。ただし、ユーザーがWeb上でファイルを削除したような分かりやすい履歴が残らないことがある。
という“説明”が現場では一番しっくり来ます。重要なのは、UI上の履歴(ごみ箱・復元タイムライン)に「削除」が見えない=データが絶対に消えていない、とは限らない点です。逆に、UIに出ないからこそ、復旧の主軸は「巻き戻し(復元)」になります。
実務でよく混ざる別要因
- 同名フォルダーの再生成:同期のやり直しで“同じ名前のフォルダー”が再作成され、ユーザーが「以前の中身が消えた」と感じる
- 移動・整理が大量発生:削除ではなく別階層へ移動され、検索しないと見つからない
- 権限・ラベル・保持設定:組織の保持ポリシーやラベルで、復元や表示に制約が出る(この場合は管理者調査が必要)
ここまでを踏まえると、相談の結論はシンプルです。「元に戻す」ことを最優先するなら、SharePointの『ライブラリの復元』が最短距離になります。
最も確実な復旧策:SharePoint「ライブラリの復元」で時間指定で巻き戻す
SharePointの「ライブラリの復元(Restore this library)」は、ドキュメントライブラリ全体を指定時刻時点の状態に巻き戻す機能です。今回のように「ごみ箱にない」「削除履歴が薄い」ケースでも、復旧できる可能性が高いのが強みです。
ライブラリの復元が“効く”ケース/効きづらいケース
| 観点 | 内容 | 現場での判断ポイント |
|---|---|---|
| 効くケース | 短時間で大量の変更が入って「元に戻したい時刻」が明確 | 「再同期した直後からおかしい」など、トリガー時刻が分かると成功率が上がる |
| 効くケース | ごみ箱にない/履歴が追いにくいが、以前は確実に存在した | “削除ログがない”こと自体が復元選択の後押しになる |
| 効きづらいケース | 問題発生から時間が経ち、以降の正しい更新が多い | 巻き戻し影響が大きい。退避と復元後の戻し作業が必須 |
| 要注意 | 復元権限がない/組織の保持・訴訟ホールド等の制約が強い | 管理者・コンプライアンス担当・Microsoftサポートの連携が近道 |
「復元しても安全か?」への答え(結論:安全にできるが、段取りが必須)
ライブラリの復元は強力ですが、“巻き戻し”である以上、復元ポイント以降に行われた正しい更新もまとめて戻ってしまいます。したがって安全性は、次の段取りで大きく変わります。
- 復元ポイント以降の変更を退避できるか(例:問題発生~復旧までの間に他ユーザーが更新した40件を別場所にコピーしておく)
- 復元の影響範囲を関係者に周知し、編集を止められるか(同期クライアントの動作も含む)
- 復元のプレビューで「戻る内容」を確認できるか
つまり、無計画に実行すると危険ですが、退避・周知・同期停止をセットにすれば、現実的に“安全に近い形”で実行できる、というのが実務上の回答になります。
復元前チェックリスト(これだけはやる)
| チェック項目 | 理由 | 具体策 |
|---|---|---|
| 対象ライブラリの特定 | 別ライブラリを戻す事故を防ぐ | サイトURL/ライブラリ名(例:共有ドキュメント)をメモ |
| 問題発生時刻の特定 | 復元ポイント選定の精度が上がる | ユーザーの作業時刻、同期開始時刻、フォルダー追加が見えた時刻を突き合わせ |
| 編集停止の周知 | 復元中に更新が入ると混乱が増える | 関係者に「今から復旧対応、編集停止」連絡(Teams等) |
| 同期クライアントの停止 | 復元後に“再び変化”が入るのを防ぐ | 影響ユーザーにはOneDriveを一時停止または終了、可能ならリンク解除 |
| 復元ポイント以降の変更を退避 | 巻き戻しで失う更新を後で戻すため | 「最近変更されたファイル」を一覧化→重要分を別ライブラリ/ローカルに退避 |
手順:SharePoint「ライブラリの復元」で問題発生直前へ戻す
画面構成はテナントやUI更新で多少変わりますが、流れは同じです。
- 対象のSharePointサイトを開く
- 右上の歯車アイコン(設定)からサイト コンテンツへ移動する
- 問題が起きているドキュメント ライブラリを開く(例:共有ドキュメント)
- ライブラリ画面で、再度歯車アイコン(設定)を開き、「ライブラリの復元」を選ぶ
- タイムラインから「OneDrive再インストール後の再同期を行った時刻の直前」を選ぶ
- 表示される変更内容のプレビューを確認する(戻る項目・影響範囲を目視)
- 問題なければ復元を確定する
復元が完了したら、まずはWebで次を確認します。
- 問題のフォルダーの中に、期待していたファイルが戻っているか
- ファイル数や主要フォルダー構造が整合しているか
- 検索で代表的なファイル名を探してヒットするか
復元後チェックリスト(復旧を“成功”にする仕上げ)
| チェック項目 | 狙い | 実施内容 |
|---|---|---|
| 退避した更新の戻し | 巻き戻しで失った正しい更新を復元する | 退避ファイルをライブラリへ再アップロード/上書き |
| 同期の再開タイミング管理 | 復元直後の再同期で“再発”を防ぐ | 確認が終わるまで同期は停止→完了後に段階的に再開 |
| 影響範囲の報告 | 利用者の混乱を減らす | 「〇時〇分時点へ復元、以降の更新は戻し済み」など短く共有 |
| 再発防止の是正 | 同じ操作で再事故を防ぐ | OneDriveの扱い手順を整備(後述) |
「他に元に戻す手段はないか?」状況別の復旧ルート
ライブラリの復元が第一候補ですが、状況によっては併用・代替が有効です。特に業務データでは「可能な限り証拠を残しつつ復旧する」ことが重要です。
SharePointのごみ箱(第1段階・第2段階)
基本ですが、まずはここです。今回の相談では「どちらにもない」前提でしたが、復旧初動の標準作業として外せません。
- サイトのごみ箱(第1段階):ユーザー操作で削除されたアイテムが入ることが多い
- 第2段階ごみ箱:第1段階から削除された後に残る領域(管理者が確認)
ポイントは、「ごみ箱にない=削除されていない」ではなく、別の変化(移動・同期由来の大量変更・保持設定)の可能性を疑うことです。
バージョン履歴(Version History)
ファイルが「消えた」のではなく「上書きされた/中身が変わった」タイプなら、ファイルのバージョン履歴から戻せることがあります。ただし今回のように“フォルダーごと空”だと、対象ファイル自体が見えないため、単体復元は難しく、やはりライブラリの復元に軍配が上がります。
監査ログで「何が起きたか」を追う(原因究明と再発防止に効く)
「削除履歴が見えない」ケースほど、監査ログ(操作ログ)の確認が役立ちます。復旧そのものはライブラリ復元で間に合っても、再発防止のために誰が・いつ・何を・どのクライアントでを押さえると、運用が一段強くなります。
- 確認したいイベント例:大量削除、移動、同期クライアント由来の更新、権限変更など
- 必要になりやすい権限:グローバル管理者、コンプライアンス系の管理ロール、監査ログ閲覧権限など
もし監査ログで「操作の連鎖」が追えない/権限や保持の関係で調査が難しい場合は、次のMicrosoftサポートが現実的です。
Microsoft 365サポートへの問い合わせ(バックエンド調査・復旧の可能性)
組織の業務データが絡む場合、Microsoft 365管理センターからサポート要求(サービスリクエスト)を起票するのは非常に有効です。特に次の条件に当てはまるなら、早めの連携が安全です。
- 復元ポイントを誤ると影響が大きい(更新が多い、利用者が多い)
- 監査ログ等で原因が追えず、再発防止策が立てにくい
- 保持ポリシー・訴訟ホールドなどコンプライアンス要件が絡む
問い合わせ時に用意すると話が速い情報:
- サイトURL、対象ライブラリ名
- 問題が起きた日時(できれば開始と終了の範囲)
- 影響ユーザー(OneDriveを再インストールしたユーザー)
- 症状のスクリーンショット(空になっている画面、復元タイムラインの内容など)
- 社内で実施した対応履歴(いつ何を復元したか、退避したか)
ユーザーPC側に痕跡が残っている場合の復元
クラウド側で見つからなくても、端末側にデータが残っていることがあります。特に「同期が完了していなかった」「ローカルにしか存在しなかった」ケースでは重要です。
Windowsのごみ箱
- 対象ユーザーPCのごみ箱を開く
- OneDriveフォルダー由来のファイルがないか検索する
- 見つかったら右クリックで元に戻す
以前のバージョン/ファイル履歴(設定していた場合)
- 以前ファイルが存在したフォルダー(例:
C:\Users\ユーザー名\OneDrive - 会社名\配下)を右クリック - プロパティを開く
- 以前のバージョンタブで問題発生前の日時があるか確認
- 「開く」で内容確認→問題なければ「復元」
これは事前に保護機能やバックアップが有効化されている場合に限りますが、ハマると強い復旧ルートです。
復旧手段の比較(どれから当たるべきか)
| 手段 | 戻せる範囲 | 強み | 注意点 |
|---|---|---|---|
| ライブラリの復元 | ライブラリ全体 | 今回のような「履歴が薄い」ケースでも復旧しやすい | 巻き戻し。復元ポイント以降の更新を退避しないと失う |
| ごみ箱(第1・第2段階) | 削除されたアイテム | 対象が明確で早い | 今回のように出てこない消え方もある |
| バージョン履歴 | 単体ファイル | 上書き事故に強い | ファイル自体が見えないと辿れない |
| 監査ログ調査 | 原因究明 | 再発防止・責任分界の整理に効く | 権限・ライセンス・保持条件で見える範囲が変わる |
| Microsoftサポート | 調査+復旧支援 | 画面から見えない領域まで含めて相談できる | 組織の管理者経由が基本。必要情報の整理が重要 |
| PC側復元(ごみ箱/履歴/バックアップ) | 端末に残る範囲 | 「クラウド未反映」だったデータに強い | 事前設定が必要なことが多い |
復旧後に重要:OneDrive同期を“まっさら”に整えて再発を防ぐ
ライブラリを復元しても、問題を起こした端末が同じ同期状態のまま再接続すると、復元直後に再び差分が走り、混乱が再燃することがあります。復旧の仕上げとして、OneDriveクライアント側も整理するのが実務的です。
推奨フロー(復旧直後の端末対応)
- 同期を一時停止(OneDriveのアクティビティセンターから実施)
- 可能なら、該当端末は一度OneDriveを終了
- 復元完了と内容確認が終わるまで、ユーザーに編集させない
- 確認後、必要に応じて「このPCのリンク解除」→再サインインし、改めてライブラリを同期
OneDriveの挙動が不安定なときは、(運用ポリシーに従った上で)OneDriveのリセット操作を検討するケースもあります。ただし環境により影響が大きいので、社内標準手順として整備し、個人判断で実行させないのが安全です。
同期方式の整理:「同期」か「OneDriveにショートカット追加」か
SharePointのデータをエクスプローラーで扱う方法には、主に2系統があります。
- 同期(Sync):OneDrive同期クライアントがライブラリをローカルに同期する
- ショートカットをOneDriveに追加:OneDrive配下に“リンク”として追加し、エクスプローラーで扱う
組織としてどちらを標準にするかは、データ量・運用成熟度・端末管理の厳格さで変わります。混在すると「同じ名前のフォルダーが複数見える」「どこが本体かわからない」などのトラブルが増えるため、採用方式を決めて教育するだけでも事故率は下がります。
再発防止:OneDrive再インストール・再同期を事故にしない運用設計
今回の事故は「OneDriveを入れ直したら直るはず」という善意の操作が引き金になっています。現場あるあるだからこそ、やってはいけない手順を明文化し、代替手順を用意するのが効果的です。
| 対策 | 狙い | 現場での具体例 | 導入難易度 |
|---|---|---|---|
| OneDrive再インストールは“申請制”にする | 独断操作を防ぐ | 「同期不調時はITへ連絡」「自己判断で削除/再インストール禁止」を周知 | 低 |
| 復旧手順(Runbook)を作る | 復旧の初動を標準化 | ごみ箱→権限/ビュー確認→復元の判断→退避→復元→再同期、をテンプレ化 | 中 |
| 復元前の退避を徹底 | 巻き戻しの副作用を最小化 | 「最近変更されたファイル」を抽出し、別ライブラリに一時退避 | 中 |
| 監査ログ確認の運用 | 原因究明と抑止 | 重大インシデントは監査ログで操作主体と時刻を記録し、再発防止策に反映 | 中〜高 |
| 専用バックアップの検討 | “最悪”に備える | 大容量・多数ユーザー環境はSaaSバックアップでRPO/RTOを設計する | 高 |
特に、利用者が多くライブラリが肥大化している組織では、SharePoint/OneDriveの標準機能(ごみ箱・バージョン・復元)だけで運用するのは、障害時の意思決定が重くなりがちです。ビジネス上の重要度が高いデータほど、「復元できる」ではなく「復元が簡単にできる」状態に寄せるのが、結果的にコストを下げます。
まとめ:この症状は「ライブラリの復元」が最短ルート。安全性は“段取り”で担保する
OneDrive再インストール後にSharePoint同期フォルダーが空になり、フォルダーだけが大量に「追加」されたように見える――この現象は、画面上の削除履歴やごみ箱に手掛かりが出ないことがあります。まずは「見え方の問題」を除外し、それでも改善しなければ、SharePointの「ライブラリの復元」で問題発生直前へ巻き戻すのが現実的で効果の高い手段です。
ただし復元は巻き戻しなので、復元ポイント以降の正しい更新を退避し、同期を止めたうえで実施することで安全性が大きく上がります。復旧後はOneDrive同期を整え、運用ルールとバックアップ方針まで含めて再発防止に繋げてください。

コメント