拠点間でファイル共有を高速化したいが、容量や回線の都合で「全部は複製できない」。そんなときに DFS Replication（DFS-R）で一部フォルダーだけ支社へ置きつつ、同じパスで他フォルダーも参照させたい──この要件は設計を誤ると“見えるはずのフォルダーが消える”事故につながります。仕組みから、実務で成立する構成と移行手順まで整理します。
今回の要件を具体化する
本社（UK）にある共有 \\domain.local\data\Projects\ 配下に Project 1〜5 があり、そのうち容量の都合で Project 3 と Project 4 だけを支社（USA）の新ファイルサーバーへ複製して、USA 側の読み書きを高速化したいとします。
同時に、USA のユーザーは 複製しない Project 1/2/5 も参照可能である必要があります（= これらは WAN 越しに UK 側へアクセスしてもよい）。UK 側のユーザーは基本的に UK サーバーを優先させ、トラブル時は他拠点へフェイルオーバーできるとなお良い、という典型パターンです。
| 項目 | UK（本社） | USA（支社） |
|---|---|---|
| Project1/2/5 | 実体あり（ローカルアクセス） | 実体なし（必要なら UK を参照） |
| Project3/4 | 実体あり（ローカルアクセス） | 実体あり（ローカルアクセス、DFSR で同期） |
| ユーザーに見せたいパス | \\domain.local\data\Projects\ProjectX（X=1〜5）を共通化 | |
DFS Namespaces（DFS-N）と DFS Replication（DFS-R）を切り分けて理解する
まず混同しがちなのが、DFS には大きく 2 つの役割がある点です。
| 機能 | 何をしているか | 今回の論点 |
|---|---|---|
| DFS 名前空間（DFS-N） | ユーザーに見せる“論理パス”を提供し、クライアントをどのサーバーへ案内するか（Referral）を決める | 同じパスで、Project ごとに行き先を変えたい |
| DFS レプリケーション（DFS-R） | 複数サーバー間でファイルを同期する（複製する） | Project3/4 だけ同期したい |
今回の“事故ポイント”は DFS-R ではなく、DFS-N の紹介（Referral）の単位にあります。DFS-R で「一部だけ複製」できても、DFS-N の設計が悪いと、USA 側ユーザーが Project1/2/5 を“見失う”構造になってしまいます。
なぜ「Projects を 1 つの DFS フォルダー」にすると失敗するのか
よくある誤設計は、DFS 名前空間に \\domain.local\data\Projects という 1 つの DFS フォルダー（リンク）を作り、そのフォルダーターゲットとして次の 2 つを登録してしまうパターンです。
\\UKServer\Projects$（本社の実体）\\USAServer\Projects$（支社の実体）
この構成では、USA クライアントが \\domain.local\data\Projects にアクセスすると、DFS-N はサイトベース／コストなどのロジックで どちらか一方のターゲットを優先して紹介します（通常は USA サイトなら \\USAServer\Projects$）。
すると、エクスプローラーで見える Project1〜5 の一覧は 紹介されたターゲット側の“実体ディレクトリ一覧”です。つまり、USA サーバーに物理的に存在しない Project1/2/5 は、一覧に出ず、アクセスもできません。
| アクセスするパス | 紹介されやすいターゲット | 見える一覧 | 結果 |
|---|---|---|---|
\\domain.local\data\Projects | USA クライアント → \\USAServer\Projects$ | USA サーバー上に存在するフォルダーのみ | 複製していない Project1/2/5 が“消える” |
ここで重要なのは、これは「権限がないから見えない（Access-Based Enumeration）」の話ではなく、そもそも参照先が違うため、そのサーバーに無いものは見えないという構造問題だという点です。
DFS-R の“フォルダー除外”では解決しない理由
「じゃあ DFS-R で Projects 全体を複製して、Project1/2/5 を除外すれば？」と考える方もいます。確かに DFS-R にはファイル／フォルダーのフィルターがありますが、除外したフォルダーの中身は 複製されないため、USA 側にデータは存在しません。
DFS-N が親フォルダー（Projects）で USA を紹介してしまう以上、クライアントは USA 側の \\USAServer\Projects$ を見に行きます。そこで Project1/2/5 が空、または存在しないなら、ユーザーはアクセスできません。“レプリケーションの粒度”ではなく、“紹介の粒度”が合っていないのが本質です。
結論：プロジェクト単位で DFS 名前空間のフォルダーを分ける
この要件を破綻なく満たす王道は、複製したい単位（Project）ごとに DFS 名前空間のフォルダー（リンク）を作ることです。親の Projects は “入れ物（コンテナ）” として扱い、切り替えは子の Project 単位で行います。
| DFS パス（例） | フォルダーターゲット | DFS-R | 狙い |
|---|---|---|---|
\\domain.local\data\Projects\Project1 | UK のみ | なし | USA からは WAN 越しに参照 |
\\domain.local\data\Projects\Project2 | UK のみ | なし | USA からは WAN 越しに参照 |
\\domain.local\data\Projects\Project3 | UK + USA | あり | USA はローカルを優先して高速化 |
\\domain.local\data\Projects\Project4 | UK + USA | あり | USA はローカルを優先して高速化 |
\\domain.local\data\Projects\Project5 | UK のみ | なし | USA からは WAN 越しに参照 |
この構成のメリットは次のとおりです。
- USA ユーザーの一覧が成立する：
\\domain.local\data\Projects配下に Project1〜5 が“常に”見える - Project3/4 だけ支社へ配置できる：容量を抑えつつ、体感速度を改善できる
- UK ユーザーは UK 優先：サイト情報を正しく設定すれば、紹介は自動で最寄りを優先できる
- 障害時の逃げ道が作りやすい：Project3/4 は UK/USA 両方をターゲットにしておけばフェイルオーバー可能
実装手順：現場でそのまま使える設定の流れ
ここからは「既存パスはできるだけ変えずに」「運用で事故らない」ことを優先した手順を、UK/USA の 2 拠点・Project3/4 のみ複製という前提で説明します。
入れ物（Projects）を“コンテナ化”する
ポイントは、Projects 自体を「どこかの共有へ案内するリンク」にしないことです。Projects はフォルダーターゲットを持たないコンテナにして、その下に Project1〜5 の DFS フォルダー（リンク）を作ります。
- コンテナ：
\\domain.local\data\Projects（ターゲットなし） - リンク：
\\domain.local\data\Projects\Project3（ターゲットあり）
これにより、ユーザーが \\domain.local\data\Projects を開いたときに見える一覧は、サーバー上の実体ではなく 名前空間（DFS）の一覧になります。だからこそ、Project1/2/5 を USA に置かなくても“見える”状態を保てます。
フォルダーターゲットは「サブフォルダー指定」でよい
各 Project ごとに共有を切る必要はありません。たとえば UK 側に \\UKServer\Projects$ という 1 つの共有があるなら、DFS のフォルダーターゲットは次のように “共有の下のサブフォルダー” を指せます。
| Project | UK 側ターゲット例 | USA 側ターゲット例 |
|---|---|---|
| Project1 | \\UKServer\Projects$\Project1 | （なし） |
| Project3 | \\UKServer\Projects$\Project3 | \\USAServer\Projects$\Project3 |
「共有を増やしたくない」「運用で管理対象を増やしたくない」場合、この方式が一番現実的です。
Project3/4 だけ DFS-R のレプリケーショングループへ入れる
DFS-R は“レプリケーション グループ”と“複製フォルダー（Replicated Folder）”で構成します。今回なら次のイメージです。
- レプリケーショングループ名：
RG-Projects-Partialなど - 複製フォルダー：
Project3、Project4の 2 つ - メンバー：UK サーバー、USA サーバー
複製フォルダーは、UK では D:\Projects\Project3、USA では E:\Projects\Project3 のように、ローカルパスは拠点ごとに違っても問題ありません（DFS-R は“論理名”と“各メンバーのローカルパス”を紐づけます）。
紹介（Referral）は「サイトベース」を成立させる
Project3/4 で “USA は USA を優先” をやりたいなら、Active Directory のサイトが正しく効いていることが前提です。最低限、次を満たしてください。
- UK/USA のサイトを作成し、各拠点のサブネットをサイトに割り当てる
- クライアントが自分のサイトを正しく判定できる（誤判定だと UK を引き当てることがある）
- DFS 名前空間サーバー／ターゲットサーバーが適切なサイトに所属している
上が整ったら、Project3/4 のフォルダーターゲットで次のいずれかを使います。
- サイトベースの紹介：同一サイト内のターゲットがあれば優先される
- ターゲットの優先度（Priority）：Global High/Low などで意図的に順序を固定する
一般的には、まずサイトベースを成立させ、補助的に優先度を付けるのが事故りにくいです（サイト設計が崩れたときに、全拠点が特定サーバーへ吸い寄せられるのを避けられます）。
移行時に必ずやる：ユーザーの参照先を DFS パスへ統一する
設計が正しくても、ユーザーが \\UKServer\Projects$ のようにサーバー直指定を続けると、拠点最適化は起きません。移行フェーズで次を揃えると効果が出ます。
- ドライブマップ（GPO）やショートカットを DFS パス（
\\domain.local\data\Projects）へ変更 - 古いショートカットを放置しない（残ると「速い人/遅い人」が混在して問い合わせが増える）
- アプリやスクリプトが参照している UNC を棚卸しする
初回同期を速く安全にする：プレシード（事前コピー）
Project3/4 のデータ量が大きい場合、DFS-R の初回同期を WAN 越しに全部流すと時間がかかり、業務にも影響します。よく採られるのが プレシードです。
- 業務影響の少ない時間帯に、UK → USA へ Robocopy で 事前に同一内容をコピー
- コピー後に DFS-R を構成して同期開始（差分のみ流れる）
例（あくまで一例。運用ルールに合わせて調整してください）
robocopy "\\UKServer\Projects$\Project3" "\\USAServer\Projects$\Project3" /MIR /COPY:DATSOU /DCOPY:DAT /R:1 /W:1 /MT:32 /LOG:C:\temp\preseed_project3.logプレシード時は、NTFS 権限と所有者を揃える、コピー中の更新で差分が出る前提で進める、ログを残す、が重要です。
動作確認：クライアントが“どこへ案内されているか”を見える化する
「USA のユーザーが本当に USA を掴んでいるか」「UK に落ちていないか」は、体感だけでなくコマンドで確認できます。
dfsutil /pktinfo
dfsutil /pktflush紹介が意図通りなら、USA クライアントで Project3 は \\USAServer\Projects$\Project3 が優先され、Project1 は \\UKServer\Projects$\Project1 に案内されるはずです。
運用でハマりがちなポイントと対策
「見えるのに遅い」問題：サイト判定ミスとキャッシュ
DFS の紹介はクライアント側にキャッシュされます。サイト設定を直した直後でも、クライアントが古い紹介を持っていると挙動が変わりません。テスト時はキャッシュクリア（上記の dfsutil /pktflush など）をセットで行うと切り分けが速くなります。
また、拠点のサブネット定義が漏れていると、USA クライアントが “Unknown site” 扱いになり、UK を引き当てることがあります。DFS のチューニング前に、AD Sites and Services をまず疑うのが現場では鉄則です。
DFSR は“共有設定”を複製しない
DFS-R が同期するのは基本的にファイルとフォルダーの内容です。共有（SMB 共有）の設定や共有権限は複製されません。Project3/4 を USA 側に置くなら、\\USAServer\Projects$ の共有設定・共有権限も UK と整合させておきます。
アクセス権は「グループ設計」で事故を減らす
拠点が増えるほど、ユーザー単位の ACL 直貼りは破綻しやすくなります。おすすめは以下のような設計です。
- 権限付与は AD グループ（ロール）に集約する
- 共有権限は “フル（または変更）” を広めに、NTFS で細かく制御する
- 拠点差を付けたい場合でも、DFS パスは共通にして運用の複雑さを増やさない
レプリケーション設計：ステージングとバックログを甘く見ない
Project3/4 の更新が激しい場合、DFSR のステージング領域が足りないと再転送が増えて遅くなったり、イベントログに警告が出たりします。目安としては、少なくとも “最大ファイルサイズ + 余裕” を確保し、更新が多いプロジェクトは大きめに見積もるのが安全です。
運用で確認したい代表例：
- バックログ（未送信ファイル）が増え続けていないか
- イベントログ（DFS Replication）の警告・エラーが出ていないか
- USN ジャーナルやディスク逼迫で “再同期地獄” になっていないか
バックアップは DFSR と別物として設計する
DFSR は可用性・近接アクセスのための同期であり、バックアップの代替ではありません。誤削除やランサムウェアは複製されます。Project3/4 を USA に置くなら、UK/USA いずれか（または両方）で、世代管理できるバックアップ設計を別途用意してください。
どうしても構成を変えられない場合の“現実解”
事情により、Projects を 1 つのフォルダーターゲット（UK/USA 切替）として残さざるを得ないケースもあります。その場合、部分複製だけで「USA で Project1/2/5 も同じ一覧に出す」ことは原理的に難しく、運用で折り合いを付ける必要が出ます。
現実解：UK サーバー直指定のショートカットを配布する
最もシンプルなのは、複製しないプロジェクトへは \\UKServer\Projects$\Project1 のような UK 直指定の UNC を配布し、ユーザーに「ここから開く」導線を作る方法です。
- メリット：構成変更が小さい／すぐ始められる
- デメリット：パスが増え、運用・教育コストが上がる／“どれが正”か混乱しやすい
応用案：USA 側にシンボリックリンクで UK を指す（推奨度は低い）
技術的には、USA サーバーの Projects$ 配下に、複製しない Project1/2/5 を UK の共有へ向けたディレクトリ シンボリックリンクとして作る方法もあります。ただし、認証・監査・バックアップ・アプリ互換性の観点でクセが強く、トラブル時の切り分けも難しいため、一般的なファイルサーバー基盤では推奨しづらい手です。
既存環境からの移行パターン：いまのパスをできるだけ変えない
すでに \\domain.local\data\Projects が「UK の共有へ案内する DFS フォルダー（リンク）」として使われている場合でも、段階移行で安全に切り替えられます。ポイントは 先に Project 単位のリンクを作り、最後に親のターゲットを外すことです。
| フェーズ | やること | ユーザー影響 | 狙い |
|---|---|---|---|
| 準備 | Project1〜5 を DFS 名前空間の子フォルダーとして作成し、ターゲットを設定（Project3/4 は UK+USA） | ほぼなし（既存導線のまま） | まず“行き先の骨組み”を用意 |
| データ | Project3/4 を USA へプレシードし、DFS-R を構成して同期を安定させる | 同期中の負荷は増える可能性 | 切替前に複製の健全性を担保 |
| 切替 | 親フォルダー Projects のフォルダーターゲット（UK/USA）を外し、コンテナ化する | キャッシュ更新のタイミングで挙動が切り替わる | \\domain.local\data\Projects の一覧を“名前空間の一覧”へ変更 |
| 整流 | ドライブマップやショートカットを DFS パスへ統一し、旧 UNC（サーバー直指定）を回収 | 周知が必要 | 問い合わせと混乱を減らす |
切替フェーズの直後は、クライアントの紹介キャッシュによって挙動が揺れることがあります。検証端末ではキャッシュクリアを徹底し、本番では段階的にユーザー部門へ周知してから切り替えると事故が減ります。
切り替え前のチェックリスト
「設計は合っているのに、なぜか期待通りにならない」を潰すための確認項目です。運用チーム内のレビューや変更申請の添付にも使えます。
| チェック項目 | 確認ポイント | ありがちなNG |
|---|---|---|
| AD サイト／サブネット | 拠点サブネットがサイトに紐づき、クライアントが正しいサイトと判定できる | サブネット漏れで “Unknown site” になり UK を掴む |
| DFS パスの統一 | ユーザー導線（GPO、ショートカット、アプリ設定）が DFS パスになっている | サーバー直指定が残り、拠点最適化が効かない |
| フォルダーターゲットの存在 | 指定した UNC パスの共有・フォルダーが実在し、権限も通る | 空フォルダー／共有名違いで接続失敗 |
| Project3/4 の権限整合 | UK/USA で NTFS 権限と所有者が揃っている（プレシード含む） | USA 側だけ権限が欠けて “読めない/書けない” |
| DFSR の健全性 | バックログが収束し、イベントログに重大なエラーがない | 切替後に同期遅延が発覚して炎上 |
| バックアップ | 誤削除・暗号化に備えた世代管理がある | “複製してるから大丈夫”と思い込み |
よくある質問
Project の数が多すぎて、手作業で DFS フォルダーを作るのがつらい
プロジェクトが数十〜数百になると、GUI で 1 個ずつ作る運用は破綻します。PowerShell で “UK 側の実フォルダーを列挙して DFS フォルダーを自動作成” するのが現実的です。たとえば「既存の \\UKServer\Projects$ 配下のサブフォルダーを DFS にぶら下げる」だけなら、次のような考え方になります。
# 例：UK側の Projects 配下を列挙し、DFS 名前空間にリンクを作る（概念例）
# 実運用では除外フォルダーや命名規則、権限確認を組み込んでください。自動化する場合でも、複製対象（Project3/4）だけは別途フラグ管理し、DFSR グループへの追加を間違えない運用にします（誤って巨大プロジェクトを複製対象にするとディスクが破綻します）。
USA 側は Project3/4 だけ“書き込み”させ、他は参照専用にしたい
技術的には可能ですが、権限設計が重要です。DFS-N は “どこへ案内するか” の仕組みであり、“読み書き可否” は NTFS／共有権限で決まります。Project1/2/5 は UK ターゲットしか持たないので、USA からも UK へ書き込み可能になってしまうことがあります。要件として参照専用にしたい場合は、Project1/2/5 の NTFS 権限を「USA ユーザー（または USA グループ）は読み取りのみ」に設計する必要があります。
DFS-R を使わず、Project3/4 を手動コピーで済ませたい
更新頻度が低いなら、手動コピー＋切替（あるいはスケジュールコピー）で成立するケースもあります。ただし運用が属人化しやすく、差分の取りこぼしや監査の課題が出やすいです。継続的に更新が入るプロジェクトであれば、DFSR の方が “運用の再現性” を作りやすいことが多いです。
そもそも WAN の体感が問題なら、別のアプローチはある？
「全部を複製するほどではないが、読み取りだけでも速くしたい」なら、BranchCache のようなキャッシュ技術や、クラウド連携（Azure File Sync など）を検討する余地もあります。ただし、既存のファイルサーバー運用・監査・バックアップ設計との整合が必要になるため、まずは今回のように DFS で“置く場所”を整理するのが最短になることが多いです。
まとめ：親で切り替えず、複製したい単位で名前空間を切る
DFS-R で「一部だけ複製」は可能でも、DFS-N を親フォルダー単位で切り替える設計だと、支社ターゲットに存在しないフォルダーは“見えなくなる”という落とし穴があります。
拠点間ファイルサーバーの最適化で失敗しないためには、複製したい単位（Project）で DFS 名前空間のフォルダーを分けることが最短ルートです。Project3/4 だけを DFS-R で同期し、紹介をサイトベースで制御すれば、USA はローカル高速、その他は UK 参照という要件を、同じパスのまま成立させられます。
コメント