SCCM BranchCache（分散モード）× Cisco AnyConnect VPN接続時の挙動と設計ポイント｜VPNサブネット除外は可能？

SCCM（Microsoft Configuration Manager／Current Branch）でBranchCache（分散モード）を有効にすると、拠点LANでは配布を高速化できる一方、Cisco AnyConnect VPN接続中の端末で「変な探索通信が増えないか」「遅くならないか」「VPN越しに端末同士で勝手に配り合わないか」が気になることがあります。仕組みから運用設計まで、現場目線で整理します。

結論：AnyConnect VPN接続中はピア探索が成立しにくく、効かなければ通常ダウンロードへフォールバックする

先に結論だけ押さえると、BranchCache（分散モード）は「近くのピア（同一ネットワーク内の端末）」を前提に動作します。ピア探索はマルチキャスト（WS-Discovery）で行われ、探索パケットは通常TTLが1で送出されるため、基本的にルータ越え・VPN越えで転送されません。

さらにCisco AnyConnectは、環境設定（ヘッドエンドのポリシーやクライアント設定）によってマルチキャスト／ブロードキャストが通らない構成が多く、VPN接続中はピア探索（P2P）が成立しにくいのが実態です。結果として、VPN中にBranchCacheが効こうとしてもピアから取得できず、最終的にBITS経由でSCCMのDistribution Point（DP）から通常どおりダウンロードする流れになりがちです。

観点	期待する挙動	AnyConnect VPN接続中に起きやすい挙動	運用上の意味
ピア探索	同一サブネット内でピアを発見	マルチキャストが通らず失敗しやすい	P2Pが成立しない前提で設計しやすい
配布の実体	近くの端末から高速取得	DPから通常ダウンロード（フォールバック）	VPN中はDP負荷・回線負荷を想定する
変な通信	最小限の探索	探索は出るが成立しないため短時間で諦めるケースが多い	「勝手に端末間で大量転送」は起きにくい
速度	拠点LANでは高速化	VPN中は高速化しない（むしろDP経由の速度次第）	VPNユーザー向け対策は別枠で考える

前提整理：SCCMとBranchCache（分散モード）の関係

BranchCacheはWindowsの機能で、コンテンツサーバー（例：IIS/ファイルサーバー/DP）からダウンロードした内容をクライアント側でキャッシュし、同一ネットワーク内の他端末へ再配布できる仕組みです。SCCMでBranchCacheを使う場合、一般的には次の構成要素が絡みます。

• DP側：配布ポイントでBranchCache利用を許可（DPプロパティで有効化）
• クライアント側：WindowsのBranchCacheを有効化（GPOやクライアント設定など）
• 転送経路：SCCMのコンテンツダウンロードはBITSが絡む場面が多く、BITS＋BranchCacheで「ローカル配布」を狙う

ここで重要なのは、BranchCache（分散モード）は“同一サブネット内での助け合い”に最適化されていることです。拠点LANのように「同じL2に端末が多い」状況では効果が出やすい一方、VPNのように「論理的に遠い」「マルチキャストが通りにくい」環境では期待値を上げすぎないほうが安全です。

分散モードとHosted Cacheモードの違い

項目	分散モード（Distributed Cache）	Hosted Cacheモード	向いているケース
キャッシュの置き場所	各クライアント	専用のHosted Cacheサーバー	拠点にサーバーを置ける／置けない
ピア探索	同一サブネット内でピア探索（マルチキャスト前提）	クライアントはHosted Cacheへ問い合わせ	ネットワーク設計の自由度
運用の複雑さ	比較的シンプル（端末が増えるほど効果）	サーバー設計・可用性・証明書など考慮が増える	運用チームの体制
VPNとの相性	成立しにくいことが多い	VPN越しでも「サーバーに取りに行く」設計は可能（ただし回線次第）	「VPNでもキャッシュさせたい」要件の有無

AnyConnect VPN接続時に「どうなるか」をもう少し具体的に

なぜVPN越しにピア探索が成立しにくいのか

分散モードの流れを簡略化すると、以下の順番になります。

1. 端末AがDPから対象コンテンツをダウンロードしようとする
2. 端末Aは「同一ネットワーク内に同じコンテンツを持っている端末がいないか」探索する（WS-Discoveryのマルチキャスト）
3. 端末Bが見つかれば、端末Aは端末Bからデータブロックを取得する（P2P）
4. 見つからなければ、端末AはDPから通常どおりダウンロードする（フォールバック）

ここでボトルネックになるのが2の探索です。WS-Discoveryのマルチキャストは「同一サブネット前提」で使われることが多く、探索パケットのTTLも低く設定されるため、ネットワーク機器・VPN装置・クライアント設定のどこかで止まってしまうケースが典型です。

Cisco AnyConnectは企業ネットワークで使われることが多く、セキュリティ設計としてVPNクライアント同士の直接通信（クライアント間通信）を許可しない、あるいはマルチキャスト／ブロードキャストを流さない構成にしていることが珍しくありません。そのため「端末同士でキャッシュ共有したい」というBranchCache側の前提と、VPN側の前提が噛み合わず、P2Pが成立しにくくなります。

「遅くなる」「変な通信が出る」心配はどれくらい現実的？

多くの環境では、VPN接続中にBranchCacheが“致命的に遅くする”ことはあまりありません。理由はシンプルで、探索が成立しない場合はフォールバックするため、最終的には通常ダウンロードに戻るからです。

不安	起こり得ること	現実の影響	対策の方向性
遅くなる？	ピア探索の試行が入る	探索が即座に諦められるなら影響は軽微。VPN品質が悪いと体感差が出る場合あり	VPNユーザー向けにDP/CMG/回線最適化を別途検討
変な通信が増える？	WS-Discoveryのマルチキャストが出ることがある	TTLの都合で拡散しにくく、監視で見えるが“異常”ではない	ネットワーク監視チームへ事前共有、必要ならFWルールで制御
VPN越しに端末同士で勝手に配る？	VPNがマルチキャスト/クライアント間通信を許可していると成立余地	一般的なAnyConnect設計では成立しにくい	VPN側でクライアント間通信を禁止、またはBranchCacheの共有を制限

ただし、注意点もあります。BranchCacheはVPN越しではなくても、「端末が今つながっている同一サブネット」に他の管理端末がいれば、そこでピア共有が成立する可能性はゼロではありません。たとえば同じ家庭内Wi-Fiに社用PCが複数台あるケースなどは、理屈上は同一サブネットです。これを“許容するか／禁止したいか”は組織の方針次第なので、後述の「明示的にコントロールする方法」を用意しておくと安心です。

VPNサブネットをBranchCache対象から除外できる？

結論：BranchCache単体に「特定サブネットを除外する」機能は基本的にない

よくある誤解として「BranchCacheに、除外サブネットのリストがあるのでは？」という発想がありますが、BranchCache（分散モード）はそもそも同一サブネット前提で、ルータ越えで拡散しない設計に寄っています。そのため、製品機能として「VPNサブネットを除外」のような粒度でスパッと制御する仕組みは一般的ではありません。

ただし、実運用では次のように“実質的に除外する”ことは可能です。目的別に、現実的な選択肢を並べます。

目的別：現実的な「除外」のやり方

やりたいこと	おすすめのアプローチ	メリット	注意点
VPN中はピア共有させたくない（実質ゼロにしたい）	VPN側でマルチキャスト/クライアント間通信を許可しない設計を維持	ネットワーク側で根本的に抑止	既に抑止されているなら追加作業不要
「社内LANのみ」ピア共有を許可したい	Windows FirewallのBranchCache関連受信規則をドメインプロファイル中心に限定	端末側で制御しやすい	VPN接続時にドメイン扱いになる環境では効きが変わる
VPNユーザーだけBranchCacheを無効化したい	SCCMのコレクション＋クライアント設定（BranchCache無効）を割り当て	管理がSCCMで完結	「VPN接続中だけ」の厳密な切替は難しい（判定が課題）
VPN境界ではDP選定を最適化したい（BranchCache云々より配布経路を最適化）	Boundary/Boundary GroupをVPN用に分離し、CMG/Cloud DP/専用DPへ誘導	体感改善につながりやすい	BranchCache除外というより配布設計の最適化

方法1：SCCM側で「VPNはVPNとして扱う」境界設計にする（ベストプラクティス寄り）

「VPNサブネットを除外したい」という相談の裏側には、実際にはBranchCacheそのものより“VPNユーザーの配布をどう設計するか”というテーマが隠れていることが多いです。BranchCache（分散）でVPNをどうこうするより、SCCMの境界設計で“取りに行く先”をコントロールしたほうが、結果的にトラブルが減ります。

Boundary/Boundary Group設計の考え方

• 社内拠点LAN：拠点内端末は同一サブネットに集まりやすい → BranchCache（分散）が効く余地がある
• VPN（AnyConnect）：端末は論理的に散らばり、ピア探索も成立しにくい → “最寄りの配布元”へ素直に誘導

設計項目	社内LAN境界グループ	VPN境界グループ	狙い
Boundaryの定義	拠点ごとのサブネット/IPレンジ	VPNクライアント払い出しIPレンジ	“今どこにいるか”を正しく判定
優先DP	拠点に近いDP（あるいは拠点内DP）	VPN経由で近いDP、またはCMG/Cloud DP	体感速度と回線負荷の最適化
フォールバック	データセンターDP	インターネット向け経路（CMG等）	通信断や混雑時の逃げ道

この設計にしておくと、VPN中にBranchCacheが効かなくても「配布元が遠すぎて遅い」という事故を減らせます。特に、在宅勤務が多い環境ではVPN＝一時的ではなく常態になりがちなので、BranchCacheよりもまず配布経路（DP選定、CMG、帯域制御）を整えるほうが費用対効果が出やすいです。

方法2：端末側で「BranchCacheの共有を明示的に抑える」

「VPN中だけ」「社外では絶対に」など、より強い統制が必要な場合は、端末側で“共有の入口”を絞るのが現実的です。BranchCache分散モードでピアに配るには、端末がコンテンツ提供側として待ち受けできる状態である必要があります。つまり、Windows FirewallなどでBranchCacheの受信（提供）を抑えるだけでも、実害を大きく減らせます。

Windows Firewallで制御する考え方

• BranchCache関連の受信規則（例：Peer Discovery、Content Retrieval など）を、社内で使うプロファイルだけに限定する
• 必要に応じて、規則の適用をインターフェース種別（LAN/Wireless/Remote Access）で絞る

実務的には、次のような落としどころが多いです。

ポリシー方針	設定イメージ	向いている組織
社内LANのみ共有	BranchCache受信規則を「ドメイン」プロファイルに限定	社外ネットワークでの端末間通信を極力避けたい
社内LAN＋社給Wi-Fi等も共有	ドメイン＋プライベートに限定（パブリックは除外）	社外でも社給ネットワークがあり、効率化したい
VPN中は共有させたくない	Remote Accessインターフェースには適用しない（または受信を禁止）	VPNクライアント同士の通信を厳格に抑えたい

注意点として、Windowsのネットワークプロファイル判定（ドメイン/プライベート/パブリック）が、VPN接続時にどう変化するかは環境差があります。AnyConnect接続時に端末が“ドメインネットワーク”扱いになる構成もあるため、「ドメインのみ許可＝VPNも許可」になり得ます。ここは必ず実機で確認し、必要ならインターフェース種別で絞る運用が安全です。

方法3：SCCMクライアント設定でBranchCacheを無効化する（ただし「VPN中だけ」は難しい）

SCCMにはクライアント設定でBranchCacheの有効/無効をコントロールできる環境が多く、組織ポリシーとして「モバイル端末はBranchCacheを使わない」と割り切るなら、この方法が最も管理しやすいです。

ただし、SCCMのクライアント設定は基本的にコレクション単位での適用です。「VPNにつないだ瞬間だけ無効化し、切断したら自動で戻す」といったリアルタイム制御は、コレクション評価やインベントリ更新のタイミングに依存するため、運用上の工夫が必要です。

割り切り運用の例

端末区分	BranchCache方針	理由
据え置きPC（拠点LAN常駐）	有効（分散モード）	同一サブネットで効果が出やすい
ノートPC（持ち出し/在宅が多い）	無効（または共有抑制）	社外ネットワークでの挙動差・問い合わせを減らす
特定拠点（少人数）	有効だが効果測定して判断	台数が少ないと効果が薄い場合がある

現場でよくある運用例：こうするとトラブルが減る

運用例A：拠点LAN（数十台以上）では分散モードを素直に活かす

支社や工場など、同一サブネットにクライアントがまとまる拠点では、分散モードは非常に相性が良いです。よく効く条件は次のとおりです。

• 同一サブネット内に同じ配布を受ける端末が複数台いる
• コンテンツサイズが大きい（OSアップグレード、Office、機能更新など）
• 拠点回線が細い/高コストで、データセンターからのダウンロードを減らしたい

一方、端末が数台しかいない拠点では、そもそもピアが存在しないため効果は限定的です。その場合は「BranchCacheを入れたのに効かない」ではなく、効く土壌がないだけという整理になります。

運用例B：VPNユーザーはBranchCacheに期待しない。配布経路（DP/CMG）を最適化する

VPN経由のユーザーは、分散モードでP2Pを期待するよりも、以下を優先したほうが満足度が上がることが多いです。

• VPN境界グループを切って、近い配布元へ誘導する
• インターネットベース管理（CMG等）やCloud DPを使い、VPNを経由しない経路を用意する
• BITSの帯域制御・スケジューリングで、業務時間帯の圧迫を抑える

「VPNサブネットを除外したい」という相談が出たら、まずはVPN経由の配布設計が適切かを点検し、BranchCacheは“効いたらラッキー”程度に置くと、運用コストが下がります。

監視・検証のポイント：VPN中にBranchCacheが動いているかをどう確認する？

想定どおり「VPN中は効かずにDPにフォールバックしている」かどうかは、事前に確認しておくと安心です。BranchCacheはWindows機能なので、SCCMだけでなくOS側でも確認します。

OS側（端末）での確認コマンド例

管理者権限のPowerShell/コマンドプロンプトで、BranchCacheの状態確認に使われることが多いコマンド例です（環境により利用可否があります）。

netsh branchcache show status all

Get-BCStatus

確認観点は以下です。

• BranchCacheが有効か（無効化されていないか）
• 分散モード/Hosted Cacheモードのどちらで動作する設定か
• キャッシュサイズ・キャッシュが増えているか

SCCM側の確認観点（ログ/挙動）

SCCMのコンテンツ取得は、最終的には「どこから」「どの経路で」取りに行ったかが重要です。BranchCacheが効いていない場合でも、SCCMクライアントはDPからの通常ダウンロードで完走します。したがって、次のような視点で確認すると切り分けが早いです。

確認したいこと	見るポイント	判断の目安
配布元の選定が正しいか	Boundary Group/DPの関連設定、クライアントが選ぶソース	VPN中に「遠いDP」を選んでいないか
フォールバックが起きているか	コンテンツ取得ログ（BITS関連ログ含む）	ピア取得の痕跡がなく、DPから進むなら想定どおり
VPN中の負荷が問題か	DP側帯域/CPU/IIS負荷、VPN帯域	BranchCacheではなく“DP集中”がボトルネックになりやすい

よくある落とし穴：BranchCacheとSCCMの「Peer」系機能を混同する

SCCM界隈では「ピアキャッシュ」「P2P」という言葉が複数の機能を指します。BranchCacheの相談をしているつもりでも、実は他機能のほうが要件に合っている場合があります。混同を避けるため、簡単に整理します。

機能	主な対象	特徴	VPNとの付き合い方
BranchCache（分散）	Windows機能（BITS/HTTP/SMB等のキャッシュ）	同一サブネット前提でシンプル	VPNでは効きにくい前提で設計することが多い
SCCM Peer Cache	SCCMコンテンツ（アプリ/パッケージ等）	SCCMがピア提供役を管理しやすい	要件次第で検討余地（ただし設計/セキュリティ要検討）
Delivery Optimization（DO）	主にWindows Update等	Microsoft側の最適化機能と親和性	VPN考慮のポリシーが取りやすい（別機能）

「VPN中にもP2Pで配りたい」「在宅でも端末同士で配らせたい」という要件が強いなら、BranchCache（分散）だけで頑張るより、SCCMの他機能や配布経路全体の設計を見直したほうが、結果的に安定します。

トラブルシュートのチェックリスト

最後に、検証・本番導入で詰まりやすいポイントを、チェックリスト形式でまとめます。

チェック項目	確認内容	よくある原因	対処の方向性
拠点LANで効果が出ない	同一サブネット内にピアがいるか	台数が少ない/配布タイミングがバラバラ	段階展開の設計、配布スケジュールの調整
VPN中に期待した挙動にならない	そもそもVPN越しにP2Pを期待していないか	マルチキャスト不可、クライアント間通信禁止	VPNはDP/CMG前提に切り替える
ネットワーク監視でマルチキャストが見える	WS-Discovery探索の発生	BranchCacheの通常動作の一部	影響範囲（TTL/セグメント）を説明し合意
社外でピア共有が起きるのが不安	端末の受信規則・プロファイル	FW許可範囲が広い	ドメイン限定/インターフェース限定などで制御
VPNユーザーの配布が遅い	DP選定と回線	境界設計が雑、DPが遠い	VPN境界グループ分離、CMG/Cloud DP検討

まとめ：VPNサブネット除外に悩むより「VPNは効きにくい前提」で設計すると安定する

• BranchCache（分散モード）はマルチキャスト探索＋同一サブネット前提のため、AnyConnect VPN中はピア探索が成立しにくい
• 成立しない場合はDPからの通常ダウンロードにフォールバックするため、「VPN越しに勝手に端末間で配り合う」挙動にはなりにくい
• 「VPNサブネットを除外」したい場合、BranchCache単体での除外機能に期待するより、境界設計（Boundary Group）と端末側FW制御で現実的に抑える
• VPNユーザーの体感改善は、BranchCacheよりも配布経路（DP/CMG/帯域制御）の最適化が効きやすい