SharePointとPower Automateの上書き事故からファイルを復元する方法｜ライブラリの復元・サポート復旧・再発防止の完全ガイド

Power Automate の「ファイルのコピー」で上書きした結果、旧ファイルが消え、バージョン履歴やごみ箱にも残らない――現場で実際に起きうる厄介な事故です。本記事は、SharePoint ドキュメントライブラリの専門的な観点から、今できる現実的な復旧手段と、二度と同じ事故を起こさないための再発防止設計を、手順・判断基準・具体設定例まで徹底的に解説します。

背景と症状の正体：なぜ「上書き」で履歴もごみ箱も消えるのか

SharePoint Online では、同名ファイルの「更新」と「置換（実体の入れ替え）」は似て非なる動作です。ワークフロー（Power Automate）の 「ファイルのコピー（Copy file）」で「重複時は置換」 を指定した場合、環境やコピー先によっては内部的に 「古いファイルを削除」→「新しいファイルを作成」 という順序で処理されることがあります。このときは「更新（Update）」ではないため、

既存アイテムの バージョン履歴に“新しい版”として積み上がらない
削除がシステム（アプリ）主体で行われると、第一／第二段階のごみ箱に期待通り残らない ケースがある
結果として「上書き前の中身」がユーザー側から 全く追跡できない

一方、手動アップロード画面の「同名ファイルを置き換え」や、API で既存ファイルのコンテンツを PUT する 真の更新 は通常、同一アイテムのバージョンを増やします。事故の根は、「同名ファイルに対して、置換（Delete+Create）なのか、更新（PUT）なのか」 の違いにあります。

先に結論：ユーザー側でできる復旧は限定的。やるなら順番と時間が命

同ケースは設計上「復旧の難所」です。とはいえ、ゼロではありません。以下の優先順位で、時間と衝突リスクを最小化 しながら実行してください。

優先	手段	成功のカギ	目安時間	注意点
高	ライブラリの復元（Files Restore）	発生から30日以内、他ユーザー更新が少ない	数分〜	ライブラリ全体を巻き戻すため影響範囲に要注意
中	クライアント側「以前のバージョン」や社内バックアップ	同期クライアント/ファイル履歴/サードパーティの有無	数分〜数時間	PC/サーバ側の世代管理が鍵。保存先や世代数を確認
中	Microsoft 365 サポートへのポイントインタイム復元依頼	サイト/ライブラリ単位で時点戻しが可能な期間内	数日〜	成功は確約不可。復元単位や期間に制約がある

復旧手順１：SharePoint「ライブラリの復元」を使う（30日以内）

SharePoint チームサイトのドキュメントライブラリには、OneDrive と同様の 「ライブラリの復元（Files Restore）」機能 があります。これは ライブラリ全体を指定した過去の時点へ巻き戻す もので、今回のような「Delete+Create に近い置換」でも復元できる可能性が最も高い手段です。

操作手順

問題のドキュメントライブラリを開く。
右上の歯車アイコン → 「このライブラリを復元」 を選択。
スライダーまたはカレンダーで、事故発生直前の日時を選ぶ。
画面に表示されるアクティビティ一覧から、該当の 削除／作成／上書き を確認。
「復元」 を実行。完了後、対象ファイルの内容が戻っているか検証。

成功率を上げるコツ

巻き戻し地点は「事故直前」を狙います。早すぎると 意図した更新まで消える、遅すぎると 消失後の状態を固定 してしまいます。
巻き戻しは ライブラリ全体 に及びます。運用中のチームなら、影響を受けるファイルを事前に洗い出し、関係者に周知しましょう。
管理者は、復元前に 対象ライブラリを一時的に読み取り専用（サイト権限や情報バリアで代替）にし、同時更新の衝突を避けると安全です。

失敗するパターン

事故から 30日を超過。
巻き戻し後すぐに上書きワークフローが再動作し、再度消える二次事故。
そもそもライブラリの Files Restore が無効化（特殊テンプレートや権限設定）されている。

復旧手順２：ローカル同期フォルダーやバックアップの「以前のバージョン」を確認

ライブラリが PC に同期されている場合、エクスプローラーから当該ファイルの 「以前のバージョン」（Windows のファイル履歴／ボリュームシャドウコピー、またはバックアップソフトの世代管理）を利用できることがあります。

チェックポイント

対象 PC に OneDrive 同期クライアントが導入済みか。
企業のバックアップ（例：イメージバックアップ、NAS のスナップショット、3rd パーティの M365 バックアップ）の保護対象に 同期フォルダーや中間保存先 が含まれているか。

操作の例（Windows）

エクスプローラーで同期済みフォルダーを開き、同名ファイル（またはフォルダー）を右クリック。
「以前のバージョンの復元」 を選択し、事故前の世代をプレビュー。
該当があれば 「復元」 または 「コピー」 を選択。オリジナルと混同しないよう、復元先は一時フォルダーを推奨。

注意：エクスプローラーの「バージョン履歴」はクラウド側の履歴を参照することもあります。今回のように「Delete+Create」で SharePoint 側に履歴が残らない場合、ここにも出てこない ことがあるため、Windows の「ファイル履歴」やサーバ/NAS スナップショットなどローカル/基盤側の履歴も併せて確認してください。

復旧手順３：Microsoft 365 サポートに「ポイントインタイム復元」を依頼

管理センターからサポートチケットを起票し、サイト/ライブラリの 時点復元（Point-in-time restore） を依頼する選択肢です。これはバックエンドのスナップショットを用いて、指定時刻付近の状態に戻す作業で、ユーザー機能では復旧できないケースの最後の望みになります。

依頼時にまとめる情報

サイト URL、ライブラリ名、該当ファイルのサーバー相対パス
ファイル名、サイズ、拡張子、既知のメタデータ（作成者・更新者・ID 等）
事故発生時刻（タイムゾーン明記）、発生直前の最終正常時刻
Power Automate のフロー名、対象アクション（Copy file など）、トリガーと実行ログ
直近でテナントやサイトに実施された大きな変更（権限、ライフサイクル、保持、DLP など）

期待値と留意点

サポートでの復元は 確約ではありません。期間や復元単位は運用基盤の制約に従います。
一般に 短期間（おおむね 14 日程度） が目安です。93 日 という数字は サイト/アイテムのごみ箱保持期間 に関するもので、バックエンド復元の保証期間ではありません。混同しないでください。
復元は サイトまたはライブラリ単位 で行われることがあり、他アイテムへの影響を伴います。事前の周知と復元後の差分吸収計画が必要です。

「実は復旧できていた」かを見極める診断チェックリスト

確認項目	見る場所	目的	期待する結果
Files Restore の可用性	対象ライブラリの歯車メニュー	最短での復元可否	「このライブラリを復元」が表示される
アクティビティの時系列	ライブラリの復元画面の一覧	巻き戻しポイント特定	削除→作成（上書き）が連続で見える
監査ログ	監査検索（管理者）	誰（どのアプリ）が消したか	FileDeleted / FileUploaded が一致
ローカル履歴	エクスプローラー「以前のバージョン」	PC 側での退避の有無	事故前の世代が存在

なぜ起きる？技術的メカニズムを噛み砕く

Power Automate の SharePoint コネクタ「Copy file」の置換は、内部で 既存アイテムを論理的に削除し、新規ファイルとして作成 する振る舞いになる場合があります。これに対し、HTTP 要求（SharePoint REST / Microsoft Graph）で既存ファイルへ PUT する 方法は、同一アイテムのバージョンを増やす 更新処理です。前者はアイテム ID（UniqueId）が切り替わりますが、後者は UniqueId を維持しつつ VersionLabel が進みます。
設計の観点では 「同名＝同一」ではなく、「同一アイテム＝同一 UniqueId」 と捉えるのが安全です。

再発防止設計：事故を“そもそも”起こさない

バージョン管理を必ず有効化

ライブラリ設定 → バージョン設定 → 「アイテムのバージョン管理」をオン、メジャーバージョンを十分な数（例：500）に。
ドラフト（下書き）と承認を使う場合は、承認済みの公開版が残るように運用設計。

保持ラベル／保持ポリシーで「完全削除」を抑止

Microsoft Purview のデータライフサイクル機能で、重要ライブラリに 保持ラベル（期間中は削除不可）を適用。
「記録（Record）」ラベルで コンテンツの削除と改ざんを禁止。ワークフローの誤操作でも削除不能にし、更新のみ許容 の設計が可能。

Power Automate 側の安全なパターン

「Copy file（置換）」の代わりに、既存ファイルへ内容を書き込むパターンに切り替えます。

既存ファイルのメタデータ取得：Get file metadata (using path) → UniqueId, ETag を取得。
HTTP 要求で内容を PUT（例：SharePoint REST）：
Method: POST Uri: _api/web/GetFileByServerRelativePath(decodedurl='{ServerRelativeUrl}')/$value Headers: X-HTTP-Method: PUT IF-MATCH: {ETag} Body: <バイナリ/ファイル本文> これにより バージョンが増える ため、ロールバックが容易になります。
必要ならチェックアウト/チェックイン を挟む：Check out → PUT → Check in（コメント必須） の順。

「存在確認 → 分岐 → 安全に保存」のフローパターン

[Get file metadata (using path)]
        │（成功）
        ├─&gt; [HTTP PUT: 既存に上書き]  ← バージョン増加
        │
        └─（失敗＝存在しない）
           └─&gt; [Create file: 新規作成]

この分岐により、DELETE を伴わない 保存を徹底できます。

本番前のテストと安全網

ダミーファイルで 1件 → 10件 → 実データに近い件数 の 3 段階で動作確認。
テスト中は対象ライブラリを 一時専用領域 に切り出し、誤操作の影響を局所化。
重要ライブラリには 別系統のバックアップ（例：サードパーティ製 M365 バックアップ）を併用。

緊急対応テンプレート（インシデント初動）

更新停止：該当フローを直ちにオフ。対象ライブラリの更新権限を一時的に制限。
時系列の確定：発生日時、対象ファイル、影響件数、関係者を洗い出し。
Files Restore 試行：巻き戻し候補を 2〜3 点用意（直前/前日始業前/週初など）。
ローカル/バックアップ探索：PC、NAS、バックアップから候補を収集。
サポート依頼：必要情報を添えてチケット起票。復元単位と実施可否・見込みを確認。
恒久対策：再発防止設計（本章参照）を速やかに適用。

よくある誤解と正しい理解

誤解	実際	対処
同名で置換しても履歴は必ず残る	置換の実装によっては Delete+Create になり履歴は残らない	PUT による更新へ切替／保持ラベルで削除抑止
ごみ箱保管 93 日＝何でも戻せる	93 日はごみ箱保持の話。上書きやバックエンド復元の保証とは別	Files Restore（30 日）を最優先し、無理ならサポートへ
Power Automate の「コピーで置換」は安全	安全ではない。環境により旧ファイルが消える	「存在確認→更新（PUT）」に設計変更
保持ラベルは閲覧制御だけ	保持は削除や改ざんの抑止にも効く	重要ライブラリに保持・記録ラベルを必ず適用

ケース別：どの復旧手段を選ぶべきか

条件	最優先	代替	備考
発生から24時間以内、他更新少	ライブラリの復元	ローカル履歴/バックアップ	衝突が少なく成功率が高い
30日を少し超過	ローカル履歴/バックアップ	サポート依頼	Files Restore は原則不可
重要ライブラリで保持ラベルあり	バージョン履歴からの復元	ライブラリの復元	Delete が阻止され履歴が残る可能性
別サイト間コピーで事故	ライブラリの復元（コピー先）	サポート依頼	サイト横断は Delete+Create になりやすい

監査・証跡から事実関係を固める（管理者向け）

監査検索：対象ファイル名やパスで FileDeleted / FileMoved / FileUploaded を時系列で確認。フロー（アプリ）の動作主体であることを明示。
フローの実行履歴：エラーや分岐条件、トークン（If-Match の有無等）を点検。
影響範囲の抽出：同ロジックで処理された同名ファイルが他にも無いか検索。

具体設定のサンプル：Send an HTTP request to SharePoint

Power Automate で既存ファイルへ内容を安全に上書きする例です。

Get file metadata (using path)
Server Relative URL に対象のパスを指定し、UniqueId と ETag を得ます。
Send an HTTP request to SharePoint Site Address: <対象サイト> Method: POST Uri: _api/web/GetFileByServerRelativePath(decodedurl='{パス}')/$value Headers: X-HTTP-Method: PUT IF-MATCH: @{outputs('Get_file_metadata_(using_path)')?['body/ETag']} Accept: application/json;odata=nometadata Content-Type: application/octet-stream Body: @{<コピー元ファイルの内容>} IF-MATCH により 競合時は失敗 し、暗黙の「置換」を防げます。失敗時は分岐して管理者通知に回すと安全です。
（任意）Check in file：コメントに「自動更新」「ソース」等を記載して追跡性を高めます。

「この設計、本当に安全？」を点検する自己診断

重要ライブラリに 保持ラベル/記録 は付与しているか。
フローは PUT 更新 を基本にし、Delete を一切使わない か。
保存前に IF-MATCH 等で競合検出をしているか。
本番前に ダミーデータ＋監査で挙動確認 をしたか。
ユーザー通知・メンテナンス時の 変更凍結手順 が定義されているか。

まとめ：今回のケースの現実解とベストプラクティス

ユーザー単独での復旧は 極めて難しい。ただし Files Restore（30 日以内） が最有力。
同期フォルダーの 以前のバージョン、社内バックアップの 世代保管 も忘れず確認。
それでもダメなら Microsoft 365 サポートの時点復元 に賭ける（成功は保証されない）。
再発防止は 「保持＋バージョン＋PUT 更新」 の三点セット。Delete を使うフローは設計から排除。

付録：関係者へのインシデント報告テンプレ（抜粋）

件名：SharePoint ライブラリでの誤上書き発生と対応
日時：2025-11-xx 10:32（JST）
対象：/sites/xxx/Shared Documents/yyy/zzz.xlsx
症状：Power Automate「Copy file（重複時は置換）」により旧版が削除され、新版で置換。
影響：yyy フォルダー配下の 12 ファイル（現時点）
暫定対応：フロー停止、ライブラリを復元（候補：直前・前日始業前）
恒久対策：保持ラベル適用、PUT 更新へ設計変更、IF-MATCH 導入

付録：意思決定フロー（テキスト版）

事故発生 ──&gt; フロー停止 ──&gt; 巻き戻し時点の特定
      │
      ├─ Files Restore 可能（30日以内）？ ── はい ──&gt; 実行 → 検証
      │                                       いいえ
      ├─ ローカル履歴/バックアップに痕跡？ ── はい ──&gt; 取得 → 再配置
      │                                       いいえ
      └─ サポートに時点復元依頼 ──&gt; 実施可否判断 → 実行/代替策

最後に：検索で来た方へ（要点の一行まとめ）

30日以内なら「ライブラリの復元」が最優先。無理ならPC/社内バックアップ、最後の望みとしてサポートの時点復元。今後は「保持＋バージョン＋PUT 更新」で同事故を根絶。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。