複数拠点をVPNで結び、拠点ごとにサブネットは分かれているのにADサイトは1つだけ──この状態でBranchCache（ブランチキャッシュ）を使えるのか、Hosted Cache（ホステッドキャッシュ）の自動検出はどうなるのか迷いがちです。本記事では「サブネット」と「ADサイト」の違いから、拠点単位で効かせる設計の勘所まで整理します。
結論：BranchCacheは「サブネットだけ」でも利用できるが、Hosted Cacheを拠点単位で最適化するならADサイトが重要
まず結論を先に押さえます。
- BranchCache自体は、ドメイン環境がなくても端末を個別構成して使えるため、「ADがないと動かない」機能ではありません。
- ただしHosted Cacheを“自動検出”で運用し、拠点Aは拠点Aのキャッシュ、拠点Bは拠点Bのキャッシュ…のように拠点単位で確実に使い分けたいなら、ADサイト（Active Directory Sites and Services）の設計がほぼ必須になります。
- 一方で、Distributed Cache（分散キャッシュ）は拠点内のクライアント同士でキャッシュを共有する方式のため、Hosted CacheほどADサイトに依存しません（ただし同一ネットワークセグメント内で成立する設計が前提です）。
つまり「拠点ごとにサブネットが違う」だけでは、Hosted Cacheの自動検出で拠点単位のスコープ制御ができません。ここがハマりどころです。
よくある混同：サブネットとADサイトは同じものではない
相談で多いのが、「拠点ごとに別サブネットだから、ADサイトを分けなくても“拠点ごと”に制御できるはず」という発想です。しかしADの用語としては、サブネット（Subnet）とADサイト（Site）は別のオブジェクトで、役割が異なります。
| 要素 | 何を表すか | 主な目的 | BranchCacheとの関係 |
|---|---|---|---|
| サブネット | IPアドレス範囲（例：10.10.1.0/24） | 「どこにいる端末か」をネットワーク的に表す | Distributed Cacheのピア発見の範囲や、ADサイト判定の材料になる |
| ADサイト | 物理拠点/ネットワーク境界（論理コンテナ） | DCロケータ、複製トポロジ、サービス探索の最適化 | Hosted Cacheの自動検出（スコープ制御）で重要 |
| ADの「サブネット」オブジェクト | サブネット→サイトの関連付け | 端末が「自分はどのサイト所属か」を判断する材料 | 関連付けが曖昧だと、Hosted Cacheの設計も想定外になりやすい |
ここで重要なのは、AD的に「サブネットだけ増やす」ことはできても、増えたサブネットを同じADサイトに関連付ける限り、端末は全部“同一サイト”所属になる点です。拠点を分けたつもりでも、BranchCacheが参照する“サイト境界”は分かれません。
BranchCacheの全体像：どこで効いて、どこで詰まるのか
BranchCacheは、WAN越しに取りに行くファイルやWebコンテンツを、拠点内にキャッシュして再利用することで、帯域の節約と応答速度の改善を狙う仕組みです。ポイントは「コンテンツを丸ごと置く」のではなく、コンテンツサーバーが提供する情報（ハッシュなど）を用いて、安全に同一データであることを確認しながら再利用することです。
運用モードは大きく2つです。
| モード | キャッシュの置き場所 | 拠点側サーバー | 向く環境 | 落とし穴 |
|---|---|---|---|---|
| Distributed Cache | 拠点内のクライアント端末 | 不要 | 小規模拠点、端末台数が少なめ、サーバーを置きたくない | 同一セグメント前提になりやすい／端末の電源OFFが多いとヒット率が落ちる |
| Hosted Cache | 拠点のホステッドキャッシュサーバー | 必要（拠点または集約） | 拠点端末が多い、安定したキャッシュが欲しい、拠点内に小型サーバーを置ける | 自動検出やスコープ制御でADサイト設計が効く／証明書や到達性も考慮が必要 |
質問の焦点である「ADサイトが必要か」は、ほぼHosted Cache側の話です。特に“自動検出”で拠点内のHosted Cacheを見つけさせたい場合、ADサイトが設計の要になります。
導入前のチェックリスト：ADサイト設計に入る前に確認したいこと
ADサイト分割の議論に入る前に、BranchCacheが効果を出せる前提を押さえておくと、導入後の「動くけど効かない」「拠点でヒットしない」を減らせます。
| 確認項目 | なぜ重要か | 確認のヒント |
|---|---|---|
| 対象クライアントOS/エディションがBranchCache対応 | 端末側でBranchCacheが使えないと、設計以前に成立しない | 展開対象のWindowsエディション、グループポリシー/機能の有無を棚卸し |
| コンテンツサーバー側（SMB/HTTP）がBranchCacheを提供できる | ファイルサーバーやWebサーバーでBranchCacheが無効だとキャッシュが作られない | 対象の共有/サイトがBranchCache対応になっているかを確認 |
| 拠点内ネットワークでクライアント⇔キャッシュの通信が成立 | 拠点内で通信が遮断されていると、キャッシュがあっても取りに行けない | 拠点LANのファイアウォール/ACL、端末間通信の制限方針を確認 |
| Hosted Cacheの場合、証明書や到達性の準備 | Hosted Cacheはクライアントからキャッシュサーバーへ安全に接続できる必要がある | 社内PKI/証明書の運用、名前解決、拠点端末からの疎通を事前に確認 |
| 拠点内に複数サブネットがあるか（VLAN分割） | Distributed Cacheはセグメント境界で効きにくくなりやすく、Hosted Cacheのほうが向く場合がある | 拠点のL2/L3構成、端末が跨るサブネット数を確認 |
| ADのサブネット定義が正確か（マスク含む） | サイト判定がズレると、Hosted Cache自動検出もズレる | 「サブネット→サイト」の関連付け、登録漏れ、重複/誤マスクを点検 |
特に最後の「ADサブネット定義」は、BranchCacheに限らずAD運用の基礎です。拠点ごとにADサイトを作る場合でも、拠点内に複数のサブネットがあるなら“同じサイトに複数サブネットを関連付ける”ことで、拠点単位の境界を作れます。
Hosted Cacheの「自動検出」でADサイトが重要になる理由
Hosted Cacheを拠点ごとに置く場合、理想は次の状態です。
- 拠点AのPCは、拠点AのHosted Cacheを自動的に見つけて使う
- 拠点BのPCは、拠点BのHosted Cacheを自動的に見つけて使う
- 拠点をまたいでキャッシュを取りに行かない（WANを無駄にしない）
この「自動的に見つける」仕組みで、ADは“同一サイトのHosted Cacheサーバーだけを探索対象にする”という役割を担います。Microsoftのドキュメントでも、Hosted Cacheの自動検出はADサイトに基づいて行われ、クライアントとHosted Cacheサーバーが同一サイトであることが前提として示されています（BranchCache Deployment Guide 参照）。
逆に言うと、ADサイトが1つしかないと「拠点A・B・Cが全部同一サイト」扱いになります。その結果、クライアントが検出するHosted Cacheの“範囲”を拠点単位に絞れず、設計意図（WAN節約）と反する動きになりやすいのです。
ADサイトが1つのままだと起きやすいこと
「実際に動くか？」だけなら動くケースはあります。しかし運用で困りやすい論点を整理すると、判断がしやすくなります。
| 観点 | ADサイト1つ（全拠点同一サイト） | 拠点ごとにADサイト分割 |
|---|---|---|
| Hosted Cache自動検出 | 拠点単位での限定ができず、意図しないキャッシュへ誘導される可能性 | 拠点内キャッシュだけを対象にできる |
| WAN節約 | 拠点外キャッシュ利用が混ざると、WANを消費して本末転倒になりやすい | 原則、拠点内で完結しやすい |
| トラブルシュート | 「どのキャッシュを参照しているのか」が見えづらく、現場切り分けが難しい | サイト境界があるため、原因切り分けがしやすい |
| GPOの当て方 | OU分割など別軸で頑張る必要 | サイト単位リンク/フィルタリングの選択肢が増える |
| 将来の拡張 | 拠点追加のたびに「例外ルール」が増えやすい | 拠点＝サイトのルールで整理しやすい |
このため、「拠点ごとにHosted Cacheを置きたい」なら、拠点ごとにADサイトを作るのがセオリーになります。サブネットが分かれていること自体は大前提ですが、サブネットだけでは「キャッシュ自動検出のスコープ」になりません。
構成例：3拠点の最小設計（Hosted Cacheを拠点単位で効かせたい場合）
イメージを掴むために、よくある「本社＋小規模拠点2つ」の最小設計例を示します。ポイントは、拠点（場所）をADサイトとして表現し、各拠点のサブネットをそのサイトに関連付けることです。
| 拠点 | サブネット例 | ADサイト | Hosted Cacheサーバー | 狙い |
|---|---|---|---|---|
| 本社 | 10.0.0.0/24 | HQ | （任意） | コンテンツサーバーの配置場所になりやすい |
| 拠点A | 10.10.10.0/24 | Branch-A | HC-Branch-A | 拠点Aの端末は拠点Aのキャッシュを自動検出 |
| 拠点B | 10.20.20.0/24 | Branch-B | HC-Branch-B | 拠点Bの端末は拠点Bのキャッシュを自動検出 |
（WAN/VPN）
本社（HQ）--- 拠点A（Branch-A：HC-Branch-A）
└------ 拠点B（Branch-B：HC-Branch-B）
この形にしておくと、Hosted Cacheサーバーの“探索範囲”が拠点内に閉じやすく、拠点追加のたびにルールが崩れにくいです。
「ADサイト＝拠点にDCが必要」は誤解になりやすい
ADサイトの話になると、「拠点ごとにADサイトを作る＝拠点ごとにドメインコントローラー（DC）を置く必要があるのでは？」と心配されがちです。しかし、設計上はサイトを作ること自体と、そこにDCを配置することは別です。
- ADサイトは「このIP帯の端末はこの場所（サイト）にいる」と定義するための枠組み
- DCの配置は「その場所に認証基盤を置くか」「複製をどうするか」という別判断
BranchCacheのHosted Cache自動検出の目的だけで言えば、必ずしも拠点にDCが必要とは限りません。ただし、サイトを増やすとDCロケータやサイトリンクの設計も関係してくるため、認証トラフィックや拠点回線の品質と合わせて検討してください。
設計パターン：小規模拠点で現実的な3案
「ADサイトを増やすべきか」は、BranchCacheの使い方（Hosted/Distributed、サーバー有無、運用負荷）で最適解が変わります。よくある3案を比較します。
| 案 | 概要 | ADサイト分割 | メリット | デメリット | こんなときに選ぶ |
|---|---|---|---|---|---|
| 案1：Distributed Cache | 拠点内クライアント同士でキャッシュ共有 | 必須ではない | 拠点サーバー不要、導入が軽い | 端末OFFが多いと効きにくい／拠点が複数サブネットだと共有範囲が途切れやすい | 端末台数が少ない、まずは効果検証したい |
| 案2：Hosted Cache＋拠点ごとADサイト | 拠点にHosted Cacheを置き、同一サイトで自動検出 | 推奨 | 拠点内で安定して効く、WAN節約しやすい | サーバー/証明書/監視など運用要素が増える | 拠点が増えても“拠点単位”で整理したい |
| 案3：Hosted Cache（手動指定） | 自動検出に頼らず、拠点ごとにサーバーを明示指定 | 不要にできる場合あり | ADサイト増加を避けられる | GPO/OU/端末配置が崩れると破綻しやすい／拠点追加時の手作業が増える | 拠点PCがOUで綺麗に管理できている、運用で吸収できる |
案1：Distributed Cacheを選ぶときのコツ
Distributed Cacheは「拠点側サーバーを置けない」「端末が10台前後でまずは効果を出したい」といった小規模拠点で選びやすい方式です。一方で、拠点内が複数VLAN（複数サブネット）に分割されていると、ピア探索が途切れてキャッシュ共有が弱くなることがあります。拠点内ネットワークの設計（セグメント分割の理由）も含めて選定するのが現実的です。
案2：Hosted Cache＋拠点ごとADサイトが王道になりやすい理由
Hosted Cacheは、拠点内に「キャッシュの中継点」を1台用意する発想です。端末同士の電源状態に左右されにくく、拠点端末が増えるほど効きやすいのが強みです。ここでADサイト分割を行うと、Hosted Cache自動検出の範囲を拠点に閉じ込められるため、WAN節約という目的に素直な構成になります。
案3：ADサイトを増やさずHosted Cacheを使う（自動検出に頼らない）
運用上どうしてもADサイトを増やしたくない場合は、OUを拠点単位で分けてGPOでHosted Cacheサーバーを明示指定する、という回避が現実的です。端末オブジェクトの配置がきちんと運用できるなら、拠点追加も「OU作成＋GPO適用」で回せます。
ただし、拠点移転やVPN経由の一時利用（別拠点から持ち込んだPCなど）に弱く、ネットワークの場所とポリシー適用がズレると想定外の通信を生みやすい点に注意が必要です。「場所で制御したい」要件が強いほど、サイト分割のほうが長期的に安定しやすいです。
実装イメージ：拠点ごとにADサイトを作ってHosted Cacheを自動検出させる
ここでは、最も問い合わせが多い「拠点ごとにHosted Cacheを置き、拠点内で自動検出させる」パターンの実装イメージをまとめます。
作業の流れ
- 拠点ごとにADサイトを作成（例：Branch-A、Branch-B）
- 拠点のサブネットを作成し、対応するサイトに関連付け（例：10.10.10.0/24 → Branch-A）
- 必要に応じてサイトリンクとコストを整理（回線品質に合わせる）
- 各拠点のHosted Cacheサーバーを構築し、Hosted Cacheとして有効化
- クライアントにBranchCacheポリシーを配布（GPOが基本）
- 動作確認（クライアントが正しいサイトに所属し、拠点内キャッシュを参照しているか）
まず最優先で確認すべきこと：「端末が想定のADサイトに所属しているか」
Hosted Cacheの自動検出以前に、端末が正しいサイト判定になっていないと、設計通りに動きません。現場での定番確認は次の2つです。
- 端末のIPが、ADに登録したサブネット範囲に含まれているか（マスクも含めて）
- 端末が認識しているサイトが想定通りか
nltest /dsgetsite
上記で表示されるサイト名が想定と違う場合、まずはADのサブネット定義（範囲やマスク）とサイトへの関連付けを疑うのが近道です。ここがズレると、BranchCacheだけでなくログオンやDC探索の最適化も崩れます。
BranchCache側の状態確認（クライアント）
BranchCacheが有効化されているか、どのモードで動いているかは、BranchCache関連のコマンドで把握できます。環境によりコマンド体系（PowerShell/GUI）が異なるため、まずは「状態が取れる」手段を用意してください。
Get-BCStatus
Get-BCClientConfiguration
Hosted Cacheを自動検出させたい場合、クライアント側が「Hosted Cacheクライアント」として構成され、かつ拠点内のHosted Cacheを検出できる状態になっているかを確認します。
運用で差が出るポイント：ADサイト分割はBranchCache以外にも効く
ADサイトを増やす判断は、BranchCache単体ではなく、拠点運用全体で考えると納得感が出ます。例えば次のような領域は、サイト設計と相性が良いです。
- GPOの配布最適化：サイトにGPOをリンクできるため、「場所で当てたい設定」と親和性があります。
- DFS/ファイルサーバーの参照最適化：拠点内サーバーを優先させたい設計と整合しやすいです。
- 認証/名前解決の最適化：将来拠点にRODC等を置く判断になった際にも、サイト設計が土台になります。
一方で、サイトが増えるほど「サブネット登録漏れ」「回線変更時の追従漏れ」「サイトリンクのコスト設計」などの運用ポイントも増えます。BranchCacheの効果（WAN削減、ユーザー体感改善）と、運用コストのバランスで決めるのが現実的です。
トラブルシュート：うまく効かないときの典型パターン
| 症状 | よくある原因 | まず確認すること |
|---|---|---|
| Hosted Cacheを検出しない | 端末のサイト判定が誤り／Hosted Cache側の公開設定が不足 | nltest /dsgetsite の結果、ADサブネット定義、GPO適用状況 |
| 拠点外のキャッシュを使っているように見える | ADサイトが1つでスコープが絞れていない／OU運用が崩れて誤GPO | 端末が所属するサイト/OU、適用されているポリシー、経路と名前解決 |
| Distributed Cacheがほとんどヒットしない | 端末台数が少ない／同一セグメントに端末が分散／端末が頻繁に電源OFF | 拠点内セグメント構成、稼働端末数、キャッシュサイズ設定 |
| 効果はあるが、ユーザー体感が改善しない | 元の回線が十分速い／対象コンテンツがキャッシュに乗っていない | 対象サーバー（SMB/HTTP）のBranchCache有効化、対象データの性質（更新頻度） |
判断基準：「ADサイトを分けるべきか」を短時間で決めるチェック
最後に、設計判断を早めるためのチェック観点をまとめます。
- 拠点ごとにHosted Cacheサーバーを置く予定がある（または既にある）
- 自動検出で拠点内サーバーだけを使わせたい
- 拠点追加が今後も見込まれ、例外ルールを増やしたくない
- 場所に依存する設定（更新配信、WSUS、ファイル参照など）も将来まとめて整理したい
これらに当てはまるほど、拠点ごとADサイト＋サブネット関連付けの設計が長期的に効いてきます。逆に「サーバーは置かない」「端末数も少ない」「OUで拠点管理が徹底できる」なら、Distributed CacheやHosted Cacheの手動指定で割り切る選択もあります。
まとめ
- サブネットとADサイトは別物で、サブネットだけではHosted Cache自動検出のスコープを拠点単位に絞れません。
- Hosted Cacheを拠点ごとに自動検出させてWAN節約を狙うなら、拠点ごとにADサイトを作成し、サブネットを対応サイトに関連付けるのが基本です。
- ADサイトを増やしたくない場合は、Distributed Cacheの採用や、OU/GPOでHosted Cacheを明示指定するなど、運用で吸収する代替案があります。
コメント