Windowsでオフラインファイルの競合が急に増えたとき、最初に疑うべきは「同じファイルの二重更新」「VPNや無線の遅延で実質オフラインになっている」「共有の設計が Offline Files 向きではない」の3つです。Windows の Offline Files はネットワーク共有をローカルにキャッシュする仕組みで、slow-link mode では要求をキャッシュから返すため、利用者が“オンラインのつもり”でも競合条件がそろいます。先に競合を消すより、サーバー版とローカル版の両方を退避し、共有設定とポリシーを確認するほうが安全です。(Microsoft Learn)
ここでいうオフラインファイルは、Windows の Offline Files / Sync Center（CSC）です。特にフォルダーリダイレクト、DFS Replication、クラスター共有、共有サーバー移行が絡む環境では、単一の不具合というより「設計と運用の噛み合わせ」で競合が増えやすくなります。(Microsoft Learn)
Windowsでオフラインファイルの競合が増える主な原因
競合が増えやすい条件を、実務で多い順に整理すると次のとおりです。
| 起きやすい条件 | なぜ競合が増えるか | 先に見る項目 |
|---|---|---|
| 同じファイルをPC側とサーバー側で更新している | ローカルキャッシュ側とサーバー側の両方で変更が発生すると競合になる | 別端末、別ユーザー、サーバー上の処理が同じファイルを書いていないか |
| VPN・Wi-Fi・高遅延で不安定 | slow-link mode では要求がキャッシュから返され、実質オフラインに近い動きになる | slow-link と server disconnect の設定 |
共有の CachingMode が Documents や Programs | 想定以上に広い範囲が自動でオフライン対象になる | 共有の CachingMode を Manual または None にできないか |
| フォルダーリダイレクトの共有先変更やサーバー移行 | パス変更時のキャッシュ移送が適切でないと競合や取りこぼしが起きやすい | optimized move の有無、移行手順 |
| DFS Replication 配下で複数人が書き込み | 分散ロックがないため、同時更新が構造的に起きやすい | その共有で Offline Files を使い続けるべきか |
| 容量不足・クォータ・権限変更 | 書き戻し失敗や片側だけの更新が起きやすい | 空き容量、ユーザークォータ、共有/NTFS ACL |
表の判断基準は、Microsoft の Offline Files、SMB 共有、Folder Redirection、DFS Replication 関連ドキュメントをもとに整理しています。(Microsoft サポート)
Sync Center に「このコンピューターがオフラインの間に、このコンピューターとサーバーの両方でファイルが変更された」系の競合が出るなら、本命は同時更新です。本人が“オフラインで作業した覚えがない”場合でも、slow-link mode に入っていれば条件は成立します。まずは「誰も触っていないはず」を疑い、別端末・別ユーザー・移行作業・バックグラウンド処理まで含めて確認してください。(Microsoft サポート)
その共有が Offline Files 向きかを先に見極める
競合対処でいちばん効くのは、細かい調整よりも「その共有に Offline Files を使い続けるべきか」の判断です。Microsoft の DFS Replication FAQ でも、Offline Files と DFSR を安全に組み合わせられるのは、基本的に一度に1人だけが書き込む前提のケースです。(Microsoft Learn)
| 共有の使い方 | Offline Files との相性 | 理由 |
|---|---|---|
| 個人ホームフォルダー、本人だけが編集する業務フォルダー | 良い | 単一ユーザー更新と相性がよい |
| 拠点間を移動するが、実際に書くのはほぼ1人 | 条件付き | 一度に1人が書く前提なら成り立つ |
| 部署共有、複数人同時編集、DFSR 配下の共有 | 悪い | 分散ロックがなく、競合が構造的に増える |
チーム共有で競合が増え続けるなら、Sync Center 側を頑張って直すより、その共有を Offline Files の対象から外すほうが早く安定することが多いです。(Microsoft Learn)
まず確認したい設定
サーバー側では共有の性格を、クライアント側では offline / slow-link の振る舞いを確認します。サーバーでの切り分けは Get-SmbShare が手早いです。(Microsoft Learn)
Get-SmbShare | Select Name, CachingMode, ContinuouslyAvailableGet-SmbShare では CachingMode と ContinuouslyAvailable を確認できます。業務共有が Documents や Programs なら自動キャッシュが広すぎる可能性があり、クラスター共有で ContinuouslyAvailable が有効な場合は Offline Files のオフライン移行が遅れることがあります。(Microsoft Learn)
| 設定 | 何を見るか | 問題が出やすい状態 | 見直しの方向 |
|---|---|---|---|
CachingMode | Manual / Documents / Programs / None | Documents や Programs | 個人用以外は Manual または None を検討 |
| Configure slow-link mode | Latency / Throughput threshold | 少しの遅延で offline 化 | 閾値を実回線に合わせる |
| Configure Background Sync | 同期間隔、除外時間 | 復帰後も差分が長く残る | 同期間隔と blockout を見直す |
| Action on server disconnect | Work offline / Never go offline | 一瞬の切断で offline に入る | 切断時の挙動を統一する |
| Do not automatically make specific redirected folders available offline | 除外対象の有無 | 大容量フォルダーまで自動キャッシュ | 自動オフライン対象を絞る |
| Enable optimized move of contents in Offline Files cache… | パス変更時の挙動 | 共有移行直後に競合が増える | 移行前に有効化する |
| Event logging level | ログの詳細度 | 原因が見えない | 切り分け中だけ上げる |
この表の設定項目は、Microsoft Learn の Offline Files / Folder Redirection / Policy CSP / SMB Share ドキュメントをもとに整理しています。(Microsoft Learn)
原因が見えにくい場合は Event logging level を一時的に上げると、既定の「キャッシュ破損だけ」ではなく、サーバー切断・再接続やネットワーク接続イベントまで Application log に記録できます。競合が“なぜ増えたか”を追うには、かなり効く確認ポイントです。(Microsoft Learn)
特に注意したいのが Always Offline mode です。これは「競合を減らす魔法の設定」ではなく、Latency=1ms にして意図的に常時オフライン運用へ寄せる設定です。回線が不安定な現場では有効ですが、サーバー側でも同じファイルが更新される運用のまま使うと、競合の火種を隠すだけになりやすいです。(Microsoft Learn)
更新や権限変更が引き金になるケース
競合が増え始めた時期に、共有サーバーの移行、フォルダーリダイレクトのパス変更、GPO 更新が重なっていないかを確認してください。Microsoft は、パス変更時に optimized move を使わないと、コピー遅延だけでなく、移行開始から最初の同期までに行われたローカル変更が失われる可能性があると案内しています。(Microsoft Learn)
移行作業では、タイムスタンプやファイル状態を保てる方法を選ぶことも重要です。Microsoft はバックアップ/リストア方式に加え、Robocopy /B <Source> <Destination> /Copyall /MIR /EFSRAW のように状態を保ちやすい方法を例示しています。共有移行のたびに競合が増えるなら、コピー手段まで見直してください。(Microsoft Learn)
また、Folder Redirection 用共有は Microsoft がかなり厳密な ACL を提示しています。共有権限だけ変更して NTFS 権限を崩したり、移行時にアクセス制御を雑に入れ替えたりすると、一部端末だけ書き戻せず、結果として「サーバー版とローカル版がずれた」状態になりやすいと考えてよいです。(Microsoft Learn)
サーバーの空き容量やユーザークォータも見落としがちです。少なくとも Windows 7 の Microsoft Support 事例では、クォータ超過でサーバーコピーが破損し、Sync Center に競合メッセージが出るケースが案内されています。現在の環境でも、競合が急増した直後は容量とクォータ確認を優先する価値があります。(Microsoft サポート)
競合が増えたときの安全な対処手順
対処は「競合を消す」より「未同期変更を失わない」順で進めます。特に CSC キャッシュ再初期化は未同期変更を失う可能性があるため、最後に回すのが鉄則です。(Microsoft Learn)
| 順番 | やること | 失敗しやすいポイント |
|---|---|---|
| 1 | 競合ファイルのサーバー版とローカル版を別名で退避する | 先に解消すると、どちらの変更が残ったか分かりにくくなる |
| 2 | 同時編集している人・端末・サーバー処理を止める | 複数人編集のままだと直しても再発する |
| 3 | 共有の CachingMode、slow-link、disconnect、redirected folder 設定を確認する | クライアントだけ見て終えると再発しやすい |
| 4 | 同期が通る状態を作ってから、残った競合だけを解消する | 権限やネットワーク問題が残ると再び競合しやすい |
| 5 | 共有移行中なら optimized move とコピー方法を見直す | 属性や状態を崩すコピーは差分を増やしやすい |
| 6 | どうしても直らない場合だけ CSC キャッシュを再初期化する | 未同期変更が残ったまま実行すると消える |
考え方の土台は、Microsoft の DFSR、Offline Files、Folder Redirection、CSC キャッシュ再初期化のドキュメントに沿っています。(Microsoft Learn)
CSC キャッシュ再初期化は最終手段
古いサーバー情報が残っている、オフライン状態から戻れない、フォルダーが見えないなどでキャッシュ破損が疑われるなら、CSC キャッシュ再初期化が最終手段になります。Microsoft は FormatDatabase を追加して再起動すると CSC キャッシュが再初期化されると案内していますが、未同期の変更は失われます。実行前に同期完了と退避を必ず確認してください。(Microsoft Learn)
REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v FormatDatabase /t REG_DWORD /d 1 /f再起動時にキャッシュが再初期化され、レジストリ値は自動的に削除されます。(Microsoft Learn)
再発を防ぐ設計のコツ
| やること | 効果 |
|---|---|
| チーム共有や複数人同時編集の共有を Offline Files 対象から外す | 構造的な競合を減らせる |
共有の既定 CachingMode を Manual または None に寄せる | 勝手な自動キャッシュを防げる |
| 大容量フォルダーを自動オフライン対象から外す | キャッシュサイズと同期時間を減らせる |
| 共有移行前に optimized move を有効化する | 切替時の競合と取りこぼしを抑えやすい |
| 切り分け中だけ Event logging level を上げる | 引き金を追いやすい |
| クラスター共有では continuous availability の設定も確認する | オフライン移行の遅れを見直せる |
再発防止は、クライアントの小手先調整より「どの共有をオフライン対象にするか」の設計で決まります。個人用フォルダー中心に絞るだけでも、競合件数はかなり落ちやすいです。(Microsoft Learn)
迷ったら、この順で進めれば外しにくい
Windows でオフラインファイルの競合が増える原因は、単純な故障よりも「その共有に Offline Files を使う設計が合っていない」「slow-link や disconnect の挙動が運用と合っていない」「移行や権限変更で片側だけ更新されている」の3つに集約できます。まず共有が単一ユーザー向けかを見極め、次にサーバーの CachingMode とクライアントの Offline Files ポリシーを確認し、それでも改善しないときだけ CSC キャッシュ再初期化に進んでください。これが、データを失わずに収束させる最短ルートです。(Microsoft Learn)
コメント