DFSR（DFS レプリケーション）で2台のファイルサーバーを同期していると、「片側で開いている（ロックしている）ファイルを、反対側でも開けてしまう」ことで二重編集・上書きが発生しがちです。ここでは、DFSRでロック共有ができない理由を整理し、データ損失を防ぐための現実的な設計と回避策を具体的にまとめます。
結論：DFSRだけで「別サーバー側のファイルロック共有」はできない
最初に結論です。DFSRには「分散ファイルロック（サーバー間でロック状態を共有する仕組み）」がありません。そのため、AサーバーでロックされたらBサーバー側でも開けない、という動作はDFSRの機能だけでは実現できません。
この問題の本質は、ファイルロックが「そのファイルを提供しているサーバー（SMBセッション）」に閉じた状態情報であり、DFSRはその情報を相手へ伝搬しない（できない）ことにあります。
混同しがちなポイント：DFS 名前空間とDFSRは別の仕組み
「DFS」とひと括りにされがちですが、現場のトラブルはこの切り分けができると一気に理解しやすくなります。
| 要素 | 役割 | 得意なこと | 苦手なこと（今回の論点） |
|---|---|---|---|
| DFS 名前空間（DFS-N） | 同じパス（例：\\domain\share）に見せる入口 | 参照先（ターゲット）を案内する、切替、冗長化 | ロック状態の統合・共有はしない |
| DFS レプリケーション（DFSR） | フォルダー内容をサーバー間で複製 | 拠点間同期、差分転送、帯域制御 | 開いている最中のロックを相手へ伝えない |
| SMB 共有（ファイルサーバー機能） | 実際にファイルを提供してロックを管理 | 同一共有内の排他制御（ロック）、アクセス制御 | 別サーバーの共有とはロックを共有しない |
つまり、DFS-Nは「どちらのサーバーに繋ぐか」を決める仕組みで、DFSRは「データを合わせる」仕組みです。どちらも“サーバーをまたいだロック一元管理”を担当していません。
なぜロックは共有できないのか：SMBロックはセッション依存、DFSRは非同期複製
ファイルロックは「そのサーバーに接続しているユーザーのセッション情報」
Windowsのファイル共有（SMB）におけるロックは、ざっくり言うと「このサーバー上のこのファイルを、このユーザーがこのセッションで開いている」という状態です。ロックはファイルの中に書き込まれる“目印”ではなく、サーバー側（SMBのハンドル管理）に存在する揮発的な状態です。
そのため、Aサーバーでユーザーがファイルを開いてロックしていても、Bサーバーから見るとまったく別の共有・別のセッション・別のファイル（同名でも別実体）として扱われます。B側からは「誰も開いていないファイル」に見えるので、別ユーザーが開けてしまいます。
DFSRは「今ロックされているか」を伝える仕組みではない
DFSRが扱うのは、基本的にファイルの内容とメタデータです。しかも複製はリアルタイムの分散トランザクションではなく、一般に非同期です。変更検知・ステージング・転送・適用という流れで動くため、“開いている最中の状態（ロック）”を同期する設計思想ではありません。
結果として「Aで開いている（ロック）→Bでも開けない」という動作は、DFSR単体では実現できない、という結論になります。
このまま運用すると何が起こる？二重編集で起きがちな事故パターン
「開けてしまう」こと自体が問題というより、開けた結果として、後でデータが壊れる・失われるのが本当の痛点です。現場で起きやすいパターンを整理します。
| 起きがちな状況 | 現象 | よくある結末 | 被害が大きくなる理由 |
|---|---|---|---|
| Aで編集中（ロック）だが、Bでも同じファイルを開ける | 同時編集（別コピーに対する編集）が成立してしまう | 後から来た更新が上書き／競合として片方が退避 | ユーザーは“同じ共有”のつもりで編集している |
| 拠点間の回線遅延・レプリケーション遅延がある | 更新が相手に届くまでタイムラグ | 「保存したはずなのに古い内容が見える」 | 認知のズレが二重編集を誘発する |
| Office系ファイルを複数人が扱う | 一時ファイルや保存タイミングが絡む | 意図しない版が残る／最終版が読めない | Officeの挙動はネットワーク/保存方式に影響される |
| 「どっちが正しい？」が曖昧なまま復旧作業 | コンフリクト発生 | 復旧に時間、関係者調整でさらに時間 | ビジネス上の正解はログだけでは決めにくい |
DFSRは競合発生時に退避フォルダー（例：ConflictAndDeleted）に移す挙動が絡むことがあり、「消えた」と誤解されることもあります。復旧できても、“どの版が正しいか”を業務側が判断しないといけないため、IT側だけで解決しづらいのが厄介です。
現実的な解決策：ロックを共有するのではなく「二重編集が起きない設計」に寄せる
ここからが本題です。DFSRでロック共有ができない以上、狙うべきゴールは次のどちらか（または併用）になります。
- そもそも同時編集が起きない導線にする（書き込み先を実質1つにする）
- 同時編集しても破綻しない基盤にする（共同編集・バージョン管理・アプリ排他など）
選択肢の全体比較（最初にここで方向性を決める）
| 選択肢 | ロックの一元管理 | 二重編集の起きにくさ | 主なメリット | 主なデメリット | 向くケース |
|---|---|---|---|---|---|
| 書き込み先ターゲットを1つに固定（Active/Passive運用） | ◎（実質1サーバー） | ◎ | 構成変更が小さく、既存のSMB運用を維持しやすい | 切替手順・監視・権限設計が必須 | 「同時編集は不要、拠点間の近接性/冗長性が目的」 |
| Windows フェールオーバークラスター（ファイルサーバー） | ◎（クラスターが統合） | ◎ | 単一共有として見せつつ高可用性、ロック継続性も期待しやすい | 共有ストレージ等の要件、設計・運用難度、コスト | 「ファイルサーバーを止められない」「真のHAが必要」 |
| SharePoint / OneDrive / Teams（共同編集） | ○（基盤側で制御） | ◎（Office中心なら特に） | 共同編集、バージョン管理、監査、外部共有など業務機能が強い | 移行コスト、ファイル種別/容量/運用ルールの見直し | 「Officeファイル中心」「共同編集が前提」 |
| アプリ側で排他制御（チェックアウト、DBロック、ロックファイル） | △（設計次第） | ○〜◎ | 業務要件に合わせた制御ができる | 開発/改修が必要、運用が複雑化しやすい | 「業務アプリでのドキュメント管理」「監査や承認が必要」 |
多くの現場では、まず「書き込み先を実質1つに固定」で被害を止め、将来的に共同編集基盤への移行やクラスター化を検討する流れが現実的です。
回避策1：共有先を“実質1つ”に統一して二重編集を封じる（最も現場で効く）
DFSRを使いつつ二重編集を防ぐ王道は、ユーザーの書き込み先を1台に寄せることです。DFS名前空間は入口として便利なので残し、書き込みターゲットだけを固定します。もう片側は参照専用またはフェイルオーバー用にします。
具体的な設計イメージ
- ユーザーは常に \\domain\share でアクセス（パスは統一）
- 平常時は サーバーA を書き込み先（アクティブ）
- サーバーBは読み取り専用、または通常は参照されないようにする
- DFSRでA→Bへ同期（結果としてBは最新コピーを保持）
- 障害時に手順に沿ってBを書き込み先に切替
「読み取り専用化」でよく使う制御ポイント
| 制御ポイント | やること | 狙い | 注意点 |
|---|---|---|---|
| 共有権限 | セカンダリ（B）の共有は基本Readにする | 誤って編集させない | 管理者/特定グループの例外権限を作ると穴になりやすい |
| NTFS権限 | B側のフォルダー権限を読み取り中心に設計 | 共有権限のすり抜け対策 | アプリが書き込みを期待する場合は要検証 |
| DFS名前空間の参照（紹介）優先度 | 通常はAに誘導、Bは低優先度またはフェイルオーバー用 | ユーザーの接続先を揃える | 拠点最適化とのトレードオフ（近いサーバーに行きたい要件と衝突） |
| ユーザー教育とUI | 「必ず\\domain\shareを使う」「サーバー名直打ちは禁止」 | 抜け道を塞ぐ | 運用ルールが守られないと再発する |
フェイルオーバー運用を成立させるコツ
「Aが落ちたらBへ切替えられる」こと自体は魅力ですが、切替運用は手順と責任分界が曖昧だと事故の温床になります。最低限、次を文章化しておくのがおすすめです。
- 切替のトリガー（何分停止で切替？一次対応は誰？）
- 切替手順（DFS名前空間側の切替、B側の権限変更、監視設定の変更など）
- 切替後に“戻す”手順（A復旧後にどう戻すか、差分の整合性確認）
- 切替中の編集ルール（復旧作業中は編集停止、など）
「DFSRでロック共有できない」問題の多くは、実は書き込み先が揃っていないことが原因で発生します。まずはこの回避策で、二重編集を仕組みとして起こしにくくするのが最短ルートです。
回避策2：ロックが一元管理される構成へ（Windows フェールオーバークラスター等）
「どうしても2台で冗長化しつつ、1つの共有として扱いたい」「可用性と整合性を両立したい」という要件なら、DFSRではなくクラスター（ファイルサーバーの高可用性）側に寄せるのが筋です。
ポイントは、ユーザーから見て共有が単一の実体になり、サーバー側でロックが統合されることです。構成としては、Windows フェールオーバークラスターのファイルサーバー（用途により一般的なファイルサーバー役割やスケールアウト型など）を検討します。
クラスター化を検討すべき判断基準
| 判断項目 | クラスターが向く | クラスター以外が向く |
|---|---|---|
| 停止許容 | 停止が許されない（業務影響が大きい） | 夜間メンテや短時間停止が許容できる |
| 整合性 | 二重編集や競合が致命的 | 参照中心で、更新頻度が低い |
| コスト | 設備投資・運用工数をかけられる | 最小コストで当面止血したい |
| 運用成熟度 | 監視・手順・障害対応体制がある | 担当者が少なく運用を増やしたくない |
クラスターは魔法の杖ではなく、要件・構成・運用体制が揃うほど効果が出ます。一方で、ロックをサーバー間で共有したいというニーズに対しては、DFSRよりも設計思想が一致しています。
回避策3：共同編集が前提の基盤へ移行（SharePoint / OneDrive / Teams）
「複数人が同じファイルを扱う」こと自体が業務要件なら、ファイルサーバー＋DFSRで頑張るより、共同編集・バージョン管理を前提にした基盤へ寄せた方が結果的に事故が減ります。特にOfficeファイル中心の業務では、SharePoint / OneDrive / Teams の効果が大きいケースがあります。
ファイルサーバー運用と共同編集基盤の違い
| 観点 | ファイルサーバー（SMB + DFSR） | 共同編集基盤（SharePoint/OneDrive/Teams） |
|---|---|---|
| 同時編集 | 原則「ロック」で衝突を避ける | 同時編集（共同編集）やバージョン管理で衝突を吸収 |
| 版管理 | 運用でカバーしがち（命名ルール等） | 標準で履歴・差分・復元が用意されやすい |
| アクセス制御 | 共有/NTFS権限中心 | サイト/ライブラリ権限、共有リンク、監査など |
| 拠点分散 | 回線品質に左右される（レプリケーション遅延も） | 基盤側の配信・同期機構に寄せられる |
もちろん、CADや大容量データ、特殊ファイルなど、クラウド共同編集基盤と相性が悪い領域もあります。ですが「二重編集で困っている」「Officeファイルが主役」「変更履歴も欲しい」という条件なら、“ロック共有”を追いかけるより、仕組みとして衝突しにくい世界へ移る方が長期的に楽になります。
回避策4：アプリ側で排他制御（チェックアウト方式・ロックファイル・DBロック）
ファイルの扱いが業務アプリの一部になっている場合は、ファイルサーバーのロックだけに頼らず、業務ルールをアプリ側に実装する方法もあります。
| 方式 | 概要 | メリット | 注意点 |
|---|---|---|---|
| チェックアウト（貸出）方式 | 編集前に「貸出」し、他ユーザーは参照のみ | 二重編集を業務ルールとして防げる | 手順が増えるので定着が重要 |
| ロックファイル運用 | 編集中は「.lock」等の目印ファイルを作る | 既存環境でも導入しやすい | 異常終了時のロック解除運用が必須 |
| DBロック/ワークフロー | 編集権限をDBで管理し、承認や版管理も併用 | 監査・承認・責任所在が明確 | 開発/運用コストが高くなりやすい |
「DFSRでロック共有したい」という要求は、言い換えると“業務的に同時編集させたくない”ということが多いです。その場合、サーバー機能で無理に実現しようとするより、業務に近い層（アプリ・運用）で縛る方が、事故の形が読みやすくなります。
追加で効く実務ポイント：事故を起こさないためのチェックリスト
設計の大枠を決めたうえで、細部で事故確率を下げるチェック項目も押さえておくと効果的です。
| カテゴリ | チェック項目 | 狙い |
|---|---|---|
| 利用導線 | サーバー名直打ちを禁止し、DFSパスを周知 | アクセス先の分散（＝二重編集）を減らす |
| 権限 | セカンダリ側の書き込み権限を原則付与しない | 「開けるから編集した」が起きないようにする |
| 監視 | レプリケーション遅延や停止を監視・通知 | 古い版を編集して競合する事故を減らす |
| バックアップ | DFSRとは別に世代バックアップを確保 | 競合・誤上書き・ランサムウェアから復旧できるようにする |
| 運用手順 | 切替手順・復旧手順・連絡フローを文書化 | 障害時の判断ミスや二次災害を減らす |
| 教育 | 「同時編集できない運用」なら明確に周知 | ユーザー側の期待値ズレをなくす |
また、DFSRを「バックアップ代わり」と誤解すると危険です。DFSRは変更を複製するため、誤削除や暗号化（ランサムウェア）も複製され得ます。二重編集対策と合わせて、復旧できる仕組み（世代バックアップ、スナップショット、監査）もセットで考えると、トラブル対応が一段楽になります。
Microsoft公式の考え方：DFSRに分散ロックがないのは仕様
DFSRに分散ロックがないのは「未設定」ではなく設計上の仕様です。Microsoftのエンジニア/サポート情報（AskDSなどの技術情報）でも、DFSRが分散ロックを提供しない理由や、マルチマスター複製で同時編集を前提にすると事故が起きやすいことが説明されています。
製品として機能が存在しない以上、もし要件としてどうしても必要なら、機能要望（フィードバック）として上げつつ、現時点では本記事の回避策のいずれかで設計を組み替えるのが現実解になります。
よくある質問（現場で詰まりやすいところ）
Q. 「DFSのパスで開いているのに、なぜロックが効かないの？」
A. DFS名前空間は入口のパスを統一しますが、実体はサーバーAまたはBのどちらかに接続しています。ロックはその接続先サーバーでしか管理されないため、反対側には伝わりません。
Q. 「片側を読み取り専用にしたら、コピーが古くならない？」
A. 古くなる可能性はあります。DFSRは非同期なので、更新頻度・回線・スケジュールによって遅延します。読み取り専用にする場合は、遅延監視と「どれくらいの遅延なら業務上許容か」を決めておくのが重要です。
Q. 「どうしても拠点ごとに近いサーバーへ書き込みたい」
A. その要件は、DFSRの得意領域と衝突しやすいです。拠点ごとの書き込みを許すほど同時編集・競合の確率が上がります。業務上それが必須なら、共同編集基盤やアプリ排他、あるいは別の分散ファイルシステム設計を検討した方が、長期的に事故が減る傾向があります。
Q. 「DFSR側で“片方向レプリケーション”みたいにできないの？」
A. DFSRは基本的にマルチマスターの考え方で、設計思想としては「どちらでも更新できる」前提です。ただし実務上は、権限・運用で片側を更新させないことで、結果として片方向運用に近い形にできます（この場合もロック共有は起きませんが、二重編集は抑えられます）。
まとめ：ロック共有を追うより「同時編集が成立しない設計」へ
DFSRで「別サーバー側のファイルロック」を共有して二重編集を防ぐ、という発想は自然ですが、DFSRには分散ロック機能がないため実現できません。したがって、対策の軸は次のいずれかになります。
- 書き込み先を実質1つに固定して二重編集を仕組みで止める（最短で効く）
- クラスター化してロックが一元管理される「単一共有」の世界へ寄せる（HAが必要なら）
- SharePoint/OneDrive/Teamsなど共同編集前提に移す（同時編集が要件なら）
- アプリ側の排他制御で業務ルールとして縛る（要件が複雑なら）
「DFSR ファイルロック 共有できない」「DFSR 二重編集 防ぐ」といった悩みは、機能不足ではなく設計思想の違いから生じます。まずは被害が出ない導線（書き込み先固定）で止血し、要件に応じてクラスター化や共同編集基盤へ段階的に移行するのが、最も失敗しにくいアプローチです。
コメント