OneDriveとSharePointの同期が最新状態を反映せず古い版で上書きされる問題の原因と対策【サイレント版ずれ防止ガイド】

OneDrive 同期クライアントで SharePoint ドキュメントライブラリを運用していると、「なぜか一部だけ同期されない」「古い版で上書きされていた」「誰がどの版を正とすべきか分からない」といったトラブルが発生しがちです。本記事では、こうしたサイレントな版ずれが起こる仕組みを技術的に分解し、ユーザーの注意力に頼らずスケーラブルに診断・予防・復旧するための考え方と実装のヒントをまとめます。

現象の整理：OneDrive 同期で実際に起きていること

まず、現場でよく聞く症状を整理します。

同じ SharePoint ライブラリを同期しているのに、端末Aと端末Bで「最新」と表示される版が違う
Office ファイルは共同編集できているように見えるが、非 Office ファイル（CAD／画像／ZIP 等）が気づかないうちに古い版で上書きされている
ユーザーは「削除していない」のに、ファイルが消えている／ごみ箱からも戻せない
バックアップ／DLP／移行ツールなどを動かした時間帯だけ、同期遅延や版履歴の乱れが増える
ライブラリ復元や保持ポリシーの影響で、一部ユーザーのローカルとサーバー版が大きく乖離する

このような「なんとなく不安定」な状態は、ユーザーの操作ミスだけでなく、OneDrive クライアント・SharePoint Online・各種 API／ポリシーの組み合わせによって生じることが少なくありません。

サイレントな同期／版ずれが起きる技術的な仕組み

ETag とタイムスタンプによる整合制御

SharePoint Online と OneDrive 同期クライアントは、ファイルの整合性を主に次の情報で管理しています。

ETag：アイテム（コンテンツ＋メタデータ）の版を識別する ID
cTag：コンテンツ変更を識別するタグ（メタデータだけの更新と区別されることがある）
最終更新日時（LastModifiedDateTime）

通常は、クライアントが持っている ETag とサーバーの ETag を比較し、差分を同期することで衝突を回避します。しかし、次のような状況で破綻しやすくなります。

端末がスリープ中に別ユーザーが編集し、復帰後に古い ETag を持ったまま大量更新を実施
端末の 時刻ずれ とネットワーク遅延で、「どちらが新しいか」の判断が境界ギリギリになる
一時的なネットワーク断でリトライが発生し、クライアント側で黙って再試行している間に別端末で更新される

このような場合、本来は同期クライアントが「競合コピー」を作るべきですが、条件によってはユーザーに何も見せないまま古い版を書き戻すパターンが出ます。結果として、現場から見ると「いつの間にか古いファイルに戻った」「警告も競合ファイルも出ていない」という事象になります。

スロットリングと API 帯域上限による遅延・取りこぼし

SharePoint Online／OneDrive は高負荷時に スロットリング（処理制限） を行います。典型的には、次のようなワークロードが重なったときです。

バックアップツールやマイグレーションツールが大量のファイルを読み書き
DLP（データ損失防止）スキャンやウイルススキャンが集中
Power Automate や自社開発アプリが Graph API を高頻度に叩く

このとき、OneDrive クライアントや独自アプリは HTTP 429（Too Many Requests）や 503 を受け取り、再試行ロジックに入ります。多くの場合は自動的にリトライされますが、

リトライ回数・待ち時間が不十分
複数アプリが同じライブラリに同時アクセス

といった条件が重なると、一部の更新が極端に遅延したり、最終的に失敗したままログに埋もれることがあります。ユーザー視点では、これが「反映されない」「誰かの編集が消えた」と見えるわけです。

ライブラリ規模・階層構造・命名規則の問題

同期トラブルが発生しやすいライブラリには共通点があります。

アイテム数が数十万以上に膨れた巨大ライブラリ
フォルダ階層が深く、パス長が 260 文字を超えがち
禁止文字／予約語を含むファイル名（* ? : < > | など）
同名ファイルを大量に含むアーカイブフォルダ（image_001.jpg が何百個もある等）

OneDrive クライアントはこうした状況でスキャンや比較に時間がかかり、一部ファイルの同期がスキップされたり、長時間「処理中」のままになりがちです。

アイデンティティや権限の不整合

次のようなケースも、版履歴や同期の一貫性を乱します。

同じ PC に 複数の Microsoft 365 アカウント を設定している
ゲストユーザー（来訪者）が OneDrive 同期で編集し、誰の編集か特定しにくい履歴ができる
共有リンク経由で編集され、元のライブラリと権限スコープがずれる

結果として、「自分の OneDrive ではこの版が最新に見えるが、SharePoint では別の人の編集が最新になっている」という、人間には解釈しづらい履歴が出来上がります。

保持ポリシー・ライブラリ復元・ドラッグ＆ドロップの影響

コンプライアンス機能やライブラリ復元も、条件次第で版ずれの原因になります。

保持ポリシーで「削除後も保持」しているが、ユーザーのごみ箱には見えない版が存在する
ライブラリ全体を過去日時に復元した結果、一部クライアントから見ると「大量の巻き戻し」が発生
エクスプローラーからフォルダをドラッグ＆ドロップで上書きし、版履歴が飛ぶ／意図しない大量上書きが発生

これらが組み合わさると、単純な「誰かが間違えて削除した／上書きした」では説明できない事象が起こります。

主な原因と症状のマッピング

原因カテゴリ	典型的な症状	最初に確認すべきポイント
ETag／タイムスタンプ競合	古い版で上書き、端末ごとに最新版が異なる	対象ファイルの版履歴（更新者／時刻／コメント）、端末の時刻ずれ
スロットリング／API 帯域	特定時間帯だけ同期遅延、Graph/API エラー増加	監査ログ・アプリログの HTTP 429/503、同時間帯のバッチ処理
ライブラリ規模・構造	一部ファイルだけ同期されない、同期完了まで非常に遅い	アイテム数、パス長、禁止文字、深い階層
アイデンティティ不整合	履歴の編集者が不自然、ゲスト名が混在	複数アカウントの有無、共有リンク・ゲストユーザーの利用状況
保持ポリシー／復元	ごみ箱に見えない削除、突然大量の巻き戻し	保持ポリシー設定、ライブラリ復元実施の有無

緊急時に優先すべきは「データ保全」

すでに版ずれやサイレントな上書きが疑われる場合は、原因究明よりも先にデータのこれ以上の破壊を止めることが重要です。

緊急対処フロー

ステップ	やること	目的	具体例
1	同期クライアントでの編集を一時停止	これ以上の誤上書き・削除を防ぐ	影響ライブラリの同期解除／一時停止を案内し、Web（Office Online）編集に切替
2	ライブラリのスナップショット取得	現状の状態を丸ごと保全	バックアップツールや Export、PowerShell 等でフルバックアップ
3	版管理を強化	衝突を物理的に発生させにくくする	チェックアウト必須、メジャー／マイナー版を厚めに設定
4	非 Office ファイルは排他運用へ	サイレント競合を避ける	CAD・画像・ZIP 等は「チェックアウトしないと編集不可」にする

ここまでを 即日対応 として実施し、その上で中長期の「診断と構成見直し」に進むとスムーズです。

ユーザー操作に頼らない診断の仕組み化

「ユーザーに注意してもらう」だけでは再発を防げません。システム側で 差分の欠落・遅延・競合を自動検知する仕組み を用意するのがポイントです。

Graph API の delta を使った差分整合チェック

Microsoft Graph の delta API を利用すると、SharePoint ライブラリの「サーバーが把握している最新の変更一覧」を効率的に取得できます。これを基に、次のような自動チェックを実装できます。

監視対象ライブラリの driveId／ドキュメントライブラリ URL を特定
/sites/{site-id}/drives/{drive-id}/root/delta を定期実行し、変更トークンと変更一覧を取得
変更一覧と、実際に存在するファイル／版履歴を照合
「サーバーには存在するがクライアントになさそう」「同じファイルに短時間で大量更新」などのパターンを検出
異常パターンがあれば、管理者向けダッシュボードやアラートに表示

擬似コードイメージは以下のようになります。

// 疑似コード（実際は認証やエラーハンドリングが必要）
GET /sites/{site-id}/drives/{drive-id}/root/delta

foreach (change in response.value) {
  // change.id, change.lastModifiedDateTime, change.eTag などを保存
  // 自前のインデックスと比較して、抜け・重複・異常パターンを検出
}

これにより、「ユーザーからの問い合わせが来たときにはすでに遅い」という状況を減らし、兆候が出た時点で先回りして対処できるようになります。

サイレント上書きを技術的に禁止する書き込みルール

自社開発ツールやバッチ処理がライブラリを更新している場合は、必ず次の設計を徹底します。

更新 API には If-Match ヘッダーで最新 ETag を指定する
ConflictBehavior=fail 相当（競合時は失敗させる）を採用し、黙って上書きしない
競合検知時は、別ファイルとして保存しアラートを上げる

イメージとしては以下のような感じです。

PATCH /sites/{site-id}/drives/{drive-id}/items/{item-id}/content
If-Match: "{最新の eTag }"

// 成功 ⇒ その eTag を持つ版だけを上書き
// 失敗（412 Precondition Failed 等） ⇒ 誰かが先に更新しているので、
// アラート＋別ファイル名で保存（*_conflict_日付.ext など）

これにより、少なくとも 自動化経路からのサイレント上書き を確実に防げます。

同期遅延の可視化：Webhook＋メトリクス

Graph の変更通知（Webhook）と delta を組み合わせることで、

「ファイルが変更されてから、クライアントに反映されるまでの時間」を計測
時間帯ごと・ライブラリごとの平均遅延・最大遅延を可視化

といった監視が可能です。たとえば、

通常は数十秒以内に反映されているのに、特定時間帯だけ数十分かかっている
特定ライブラリだけ常に遅延が大きい

といったパターンが見えるようになれば、API 帯域のボトルネックや特定アプリの過負荷を絞り込むことができます。

監査ログと版履歴の突合

SharePoint 監査ログと各ファイルの版履歴を定期的に突き合わせることで、異常なパターンを検知できます。

ごく短時間に同じユーザーから大量の上書きが発生している
「削除 → 復元 → 上書き」が繰り返されている
非営業時間帯にだけ大量の更新が集中している（バックアップ等）

こうしたログを日次ジョブで集計し、しきい値を超えた場合にアラートを上げることで、「いつの間にか壊れていた」を避けることができます。

構成・運用ベストプラクティス：再発防止のための設計

Files On-Demand の使い分け

Files On-Demand は便利な一方で、頻繁に編集される共有ライブラリではリスクにもなります。特に重要なライブラリについては、次を検討します。

重要共有ライブラリは「このデバイス上で常に保持」を基本にする
容量に余裕のない端末では、編集頻度の高いフォルダだけ常駐化する
「オンラインのみ」にしているフォルダでは、ローカル編集を前提としない運用（Web 編集推奨）にする

ライブラリ設計の見直し

同期トラブルを減らす「設計の型」をまとめると、以下のようになります。

項目	推奨方針
ライブラリ規模	数十万アイテムを超える場合は、サイト単位／業務単位でライブラリを分割
フォルダ階層	深さは 5 階層程度までを目安にし、論理的な区切りでサイト／ライブラリを分ける
パス長	パス全体が 260 文字を超えないように、短めのサイト名／ライブラリ名／フォルダ名を採用
命名規則	禁止文字を避け、`YYYYMMDD_案件名_バージョン` など、人間にも機械にも判別しやすい形式を採用
アーカイブ	過去年度分などは「参照のみ」ライブラリとして分離し、同期対象から外すことも検討

並列バッチ処理の制御

バックアップ／DLP／移行ツールなど、ライブラリを大量に読む／書く処理がある場合、次のような制御を行うと安定します。

本番利用が少ない時間帯（深夜など）にスケジューリングする
複数ツールが同じライブラリを同時にスキャンしないよう、時間帯を分散する
ツール側の最大同時接続数・スレッド数を抑制し、429/503 が多発しないよう調整する

バージョン数と保持ポリシーの設計

版数を多く持たせることは保険になりますが、無制限に増やすとストレージと性能の問題が出ます。ポイントは、

「典型的な復元シナリオ」から逆算して必要な版数を決める
保持ポリシー（何年分保持するか）と合わせて検討し、復元できる期間と粒度を明確にする
アーカイブ用ライブラリは版数を少なめにし、編集頻度の高いライブラリに版数を多く割く

といった「設計としてのバランス」が重要です。

ネットワーク・クライアントの標準化

Microsoft 365 宛ての通信は、プロキシ例外・SSL 中間解読の除外を検討する
拠点間のレイテンシが大きい場合は、ローカルブレイクアウトなど WAN 設計も見直す
OneDrive 同期クライアント、Office、OS のバージョンと更新リングを組織で統一し、「誰かだけ古い」状態を減らす

ファイル種別ごとの編集ポリシー

すべてのファイルを「共同編集前提」にするのではなく、タイプ別にルールを分けます。

ファイル種別	推奨運用	理由
Office（Word/Excel/PowerPoint 等）	共同編集＋AutoSave 有効、OneDrive 同期も可	共同編集前提で設計されており、競合検出が比較的強い
非 Office（CAD／画像／動画／ZIP 等）	チェックアウト必須／単独編集、場合により同期対象外	バイナリ上書きで競合しやすく、サイレント上書きのリスクが高い
大量自動生成ファイル（ログ／一時ファイル等）	SharePoint ではなく専用ストレージ（Azure Files など）を検討	版管理やライブラリ設計と相性が悪く、肥大化しやすい

復旧の基本動作と考え方

すでに何らかの破壊が起きている場合、次の順序で復旧可能性を探ります。

1. 版履歴からの復元

対象ファイルを右クリック → バージョン履歴 を開き、問題前の版を復元
複数ユーザーが編集している場合は、誰の編集を採用するかを業務ルールに沿って決定

2. サイトのごみ箱（第一段階／第二段階）

ユーザーのごみ箱（第一段階）にない場合でも、サイトコレクションの第二段階ごみ箱を確認
保持ポリシーが適用されている場合、管理者のみがアクセス可能な保持ライブラリから復元できるケースがあります

3. バックアップからのリストア＋差分マージ

版履歴やごみ箱で復元できない場合は、バックアップからの復元＋差分マージが必要です。

バックアップ時点のライブラリを別サイトやプレフィックス付きのフォルダにリストア
現行ライブラリと比較し、必要なファイルだけを手動／スクリプトでコピー
業務側と相談し、どの時点の版を「正」とするかを明確にしてから反映

このプロセスを短時間で実施できるかどうかは、日頃のバックアップ設計と検証に大きく依存します。

原因が複雑な場合のエスカレーション戦略

テナント全体に影響するような事象や、特定条件下でのみ発生する同期不具合などは、Microsoft Support（Unified Support 等）による調査が必要になることがあります。その際、次の情報を事前に整理しておくと話が早く進みます。

項目	内容
発生時間帯	日時・タイムゾーン・再現時間帯（例：毎週月曜 9:00〜10:00 に集中）
対象サイト／ライブラリ	URL、用途、アイテム数、ファイル種別など
影響件数	何ファイル／何ユーザーに影響したか（概算でも可）
再現手順	可能なら簡易な再現手順（○○を編集 → △△を削除 → 同期結果）
代表ファイルの版履歴／ETag	問題発生前後の版履歴スクリーンショットや ETag の値
スロットリングの証跡	Graph／アプリログの HTTP 429/503、エラー内容・頻度
併用ツール情報	バックアップ／DLP／移行ツールの種類と実行時間帯

ここまで揃えて問い合わせることで、単なる「ヘルプデスク対応」を超えて、製品チームによる根本原因分析（RCA）につなげやすくなります。

よくある落とし穴と、短期で効いた対処例

API 帯域がネックだったケース

実際の現場報告でも多いのが、API 層のスループット上限がボトルネックになっていたケースです。典型的なパターンは次の通りです。

1つの巨大ライブラリに、数十万件の Office＋非 Office ファイルが混在
業務時間中にバックアップツールと DLP スキャンが同時に走っている
そこへユーザーの OneDrive 同期クライアントと Power Automate フローが加わる

このケースでは、次のような対処で症状が収束しました。

ライブラリを用途ごとに分割し、ファイル数と更新頻度が均等になるよう再設計
バックアップ／DLP の実行時間帯と同時実行数を見直し、ピーク時の API 呼び出し数を削減
各ファイルの版数上限を適正化し、不要な古い版を削減

これだけでも、ユーザーから見た「同期が遅い」「古い版で上書きされた」という訴えが大幅に減ることがあります。

「ルールを決めただけ」で改善したケース

技術的な設定変更を最小限に抑えつつ、次のようなルールだけで安定度が増したケースもあります。

非 Office ファイルは必ずチェックアウトしてから編集するという業務ルールを徹底
エクスプローラーからの「フォルダ丸ごとドラッグ＆ドロップ上書き」を禁止し、変更は単位ごとに行う
大きなフォルダ構造変更（移動・改名）は、時間帯と実行者を決めて計画的に行う

もちろんルールだけでは限界がありますが、「どの操作がリスクを高めるか」を明示するだけでも、トラブル頻度は確実に下がります。

まとめ：SharePoint＋OneDrive 同期は「設計して使う」時代へ

OneDrive 同期クライアントと SharePoint Online の組み合わせは、うまく設計・運用すれば非常に強力な共同編集基盤になります。しかし、

ETag／タイムスタンプによる整合制御
スロットリングや API 帯域上限
ライブラリ設計・保持ポリシー・自動化ツール

などの要素が絡み合うと、ユーザーからは「サイレントな同期／版ずれ」として現れます。

ポイントは、

緊急時はまず編集を止めてスナップショットを取る
Graph delta や監査ログを活用し、ユーザー任せにしない診断・監視を用意する
ライブラリ設計・Files On-Demand・バッチ処理の時間帯を含めて全体を設計し直す
非 Office ファイルや大量バイナリは、共同編集前提にせず運用ルールを分ける

という 4 点です。

「ユーザーが気をつける」だけでは限界があります。この記事をきっかけに、OneDrive 同期と SharePoint ライブラリの運用を、システムとして設計し直すことを検討してみてください。

この記事を書いた人

佐藤健司

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