Windows Update/WSUS の通信をファイアウォールで最小限に許可したいのに、古い TechNet しか出てこない…という悩みは多いです。本記事では Microsoft Learn の最新公式ドキュメントを根拠に、構成別（WSUS/直接更新/プロキシ）で許可すべき宛先（FQDN）とポートを整理します。
結論：最新の根拠は「Microsoft Learn」に集約されている
以前は TechNet／TechNet Wiki／古い WSUS 展開ガイドに「宛先URL一覧」が散らばっていましたが、現在は多くが Microsoft Learn のドキュメントへ統合・更新されています。特に厳格な IT 部門に説明する場合は、口頭の経験則よりも、Learn にある「ネットワーク接続（通信要件）」を根拠にして、構成図とセットで提示するのが最短ルートです。
「何をホワイトリスト化すればいいか」が難しい理由
Windows Update／WSUS は、単に “80/443 を開ければ終わり” ではありません。難しさの正体は、主に次の3点です。
- 更新経路が複数ある：クライアントが WSUS に行くのか、Windows Update（Microsoft Update）に直行するのかで、許可すべき宛先が変わります。
- IP では固定できない：Microsoft 側の負荷分散や CDN により、関連する IP は変動します。公式ドキュメントでも「IP 範囲で代替しない」旨が明記されています。
- TLS 検査（SSL インターセプト）が障害になり得る：Windows Update のメタデータ通信は証明書固定（ピン留め）で保護され、途中で TLS を終端・再暗号化すると失敗することがあります。
最初にやるべき整理：あなたの環境はどの更新経路か
「許可すべき宛先・ポート」をゼロから決めるときは、先に更新経路を確定させます。ここが曖昧だと、どれだけ URL を足しても “抜け” が出ます。
| パターン | クライアントの更新先 | インターネットに出るのは誰？ | 設計のポイント |
|---|---|---|---|
| WSUS集中（推奨） | 社内 WSUS | 原則 WSUS（上位）だけ | クライアントの外向き通信を最小化でき、ホワイトリストが管理しやすい |
| WSUS階層 | 社内 WSUS（下位） | 上位 WSUS だけ | 下位→上位の同期ポートも忘れずに設計する |
| 直接更新（WU/WUfB） | Windows Update / Microsoft Update | 各クライアント | FQDN ベースの許可＋TLS 検査の例外＋HTTP RANGE が重要 |
| 混在 | 端末/部署で WSUS と直更新が混在 | 両方 | “どの端末がどこへ行くか” を先に台帳化しないと承認が通りにくい |
WSUS を使う場合：最低限通すべき通信（送信元→宛先・ポート）
WSUS 構成の強みは、クライアントにインターネットアクセスが不要な設計にできることです。インターネットへ出るサーバーを限定できるため、厳格なファイアウォール運用ほど WSUS は有利です。
WSUS の標準ポート（まずここを押さえる）
Microsoft Learn では、WSUS の基本ポートが明確に整理されています。
| 通信 | 送信元 → 宛先 | プロトコル / ポート | 補足 |
|---|---|---|---|
| クライアントの更新チェック/取得 | クライアント → WSUS | TCP 8530（HTTP） / 8531（HTTPS） | 既定。80/443 も選択肢だが、その他のポートはサポートされない |
| WSUS 同期（上位→Microsoft Update） | WSUS（上位） → インターネット | TCP 80 / 443 | 更新の同期。企業FWが厳しい場合は、次の「宛先ドメイン」も許可 |
| WSUS 同期（下位→上位） | WSUS（下位） → WSUS（上位） | TCP 8530 / 8531 | 階層構成のとき必須 |
WSUS（上位）が外部へ出るために許可すべき「Microsoft ドメイン」
社内 FW で “どこへ出るのか” を問われたときは、WSUS の構成手順に書かれている 送信（アウトバウンド）許可が必要なドメイン一覧を、そのまま根拠にできます。ここが「TechNet が消えた」問題の実質的な回答です。
| 宛先（URL/FQDN） | 必要ポート | 用途のイメージ |
|---|---|---|
http://windowsupdate.microsoft.com | 80/443 | 更新サービス接続 |
http://*.windowsupdate.microsoft.com | 80/443 | 更新サービス接続 |
https://*.windowsupdate.microsoft.com | 80/443 | 更新サービス接続（TLS） |
http://*.update.microsoft.com | 80/443 | 更新サービス接続 |
https://*.update.microsoft.com | 80/443 | 更新サービス接続（TLS） |
http://*.windowsupdate.com | 80/443 | 更新コンテンツ取得 |
http://download.windowsupdate.com | 80/443 | 更新コンテンツ取得 |
https://download.microsoft.com | 80/443 | コンテンツ/前提要素の取得 |
http://*.download.windowsupdate.com | 80/443 | 更新コンテンツ取得 |
http://wustat.windows.com | 80/443 | 統計/関連通信 |
http://ntservicepack.microsoft.com | 80/443 | 関連コンテンツ |
http://go.microsoft.com | 80/443 | リダイレクト等 |
http://dl.delivery.mp.microsoft.com | 80/443 | 配信最適化/配布基盤 |
https://dl.delivery.mp.microsoft.com | 80/443 | 配信最適化/配布基盤（TLS） |
http://*.delivery.mp.microsoft.com | 80/443 | 配信最適化/配布基盤 |
https://*.delivery.mp.microsoft.com | 80/443 | 配信最適化/配布基盤（TLS） |
重要：上記ドメインに紐づく IP アドレスは変化するため、公式にも「IP アドレス範囲で代替しない」ことが明記されています。ファイアウォールが IP ベースの固定しかできない場合は、WSUS 側の出口をプロキシに寄せる／FQDN フィルタ対応の製品を使う、など運用設計そのものを見直すのが現実的です。
プロキシ経由にする場合の実務ポイント
企業ネットワークでプロキシを使う場合、WSUS 側の設定だけでなく、Windows Update クライアント側が WinHTTP（システムレベル）でプロキシを使えることも重要です。ユーザーの IE/Edge 設定だけでは足りないケースがあり、公式トラブルシューティングでも注意されています。
- プロキシは HTTP/HTTPS をサポートし、必要に応じて基本認証/Windows 認証に対応していること（WSUS 側の要件）。
- 更新ファイルのダウンロードでは WinHTTP と HTTP RANGE（部分範囲要求）が使われるため、プロキシが RANGE をブロックすると失敗や高負荷の原因になる。
WinHTTP のプロキシ設定例：
netsh winhttp set proxy ProxyServerName:PortNumber
netsh winhttp import proxy source=ieHTTP RANGE を明示的に許可する “目安” として、公式ドキュメントでは次の宛先が例示されています（環境によって追加が必要になることがあります）。
*.download.windowsupdate.com*.dl.delivery.mp.microsoft.com*.delivery.mp.microsoft.com
クライアントが Windows Update に直接出る場合の「最低限」
WSUS を使わず、クライアントが Windows Update / Microsoft Update に直接接続する場合は、出口が端末ごとになります。許可項目は増えますが、公式情報を組み合わせると、説明に耐える “最小セット” を作れます。
ポート要件（通信の種類で分けて考える）
| 用途 | プロトコル / ポート | ポイント |
|---|---|---|
| 更新メタデータ（スキャン/判定） | HTTPS（TCP 443） | 証明書固定（ピン留め）により、TLS 検査の例外が必要になることがある |
| 更新コンテンツ（ダウンロード） | HTTP（TCP 80） | CDN 配布のため、コンテンツ側は HTTP が基本（検証は署名/ハッシュで行われる） |
| 配信の最適化（P2P） | TCP 7680 | P2P を使う構成のときのみ。禁止したい場合はポリシーで無効化も検討 |
許可すべき代表的なエンドポイント（公式の例）
Windows 10 の例として、公式トラブルシューティングでは「到達できる必要があるエンドポイント」が具体的に提示されています。ここは FW 申請の根拠に使いやすい部分です。
| プロトコルの指定 | エンドポイント（例） | 補足 |
|---|---|---|
| TLS 1.2 | *.prod.do.dsp.mp.microsoft.com | 配信の最適化関連 |
| HTTP | emdl.ws.microsoft.com | ダウンロード系 |
| HTTP | *.dl.delivery.mp.microsoft.com | 更新/Store の配布基盤 |
| HTTP | *.windowsupdate.com | 更新関連 |
| HTTPS | *.delivery.mp.microsoft.com | 配布基盤（HTTPS） |
| TLS 1.2 | *.update.microsoft.com | 更新サービス接続 |
| TLS 1.2 | tsfe.trafficshaping.dsp.mp.microsoft.com | トラフィック制御/フォールバック |
注意：公式に「HTTP と指定されている宛先へ HTTPS で行かない／その逆もしない」と明記されています。URL は同じでもプロトコルを変えると接続が失敗することがあるため、プロキシの “HTTPS 強制” や “一律リダイレクト” は要注意です。
Windows 11 での追加観点：エンドポイントは OS/機能で増える
Windows 11 Enterprise 向けの接続エンドポイント一覧では、Windows Update の領域として、配信最適化・更新サービス・互換性 DB・Web API など、より幅広い宛先が整理されています。直更新を許可する場合は、上の “最小セット” に加えて、利用機能に応じて追加していくのが安全です。
| 用途 | 宛先（例） | メモ |
|---|---|---|
| 定義更新 | definitionupdates.microsoft.com | Defender 定義など |
| 互換性 DB | adl.windows.com | 互換性情報 |
| Windows Update / Microsoft Update 接続 | *.update.microsoft.com | サービス接続 |
| 配布基盤 | *.dl.delivery.mp.microsoft.com | 更新/Store の配布基盤 |
| 配信最適化 | *.prod.do.dsp.mp.microsoft.com | DO 関連 |
| トラフィック制御 | tsfe.trafficshaping.dsp.mp.microsoft.com | 制御/フォールバック |
| 公開 Web API | *.api.cdp.microsoft.com | OSに依存しない製品の更新確認など |
IT 部門に通すための「申請用テンプレ」：構成図＋通信表が最強
厳格な組織ほど、「なぜその宛先が必要か」「どの端末が、どこへ、どのポートで出るのか」を求めます。そこで、公式ドキュメントの粒度に合わせて、次のフォーマットで提示すると通りやすくなります。
| 区分 | 送信元 | 宛先（FQDN/セグメント） | 方向 | プロトコル/ポート | 目的 | 根拠（公式） |
|---|---|---|---|---|---|---|
| クライアント更新 | 社内端末 | WSUS（例：wsus.contoso.local） | Outbound | TCP 8530/8531 | 更新検出/ダウンロード | WSUS 構成手順（クライアント→WSUS の既定ポート） |
| WSUS 同期 | WSUS（上位） | Microsoft Update 関連ドメイン | Outbound | TCP 80/443 | 更新メタデータ/コンテンツ同期 | WSUS 構成手順（許可すべきドメイン一覧） |
| WSUS 階層 | WSUS（下位） | WSUS（上位） | Outbound | TCP 8530/8531 | 同期（チェーン/レプリカ） | WSUS 構成手順（下位→上位の既定ポート） |
| 直更新 | 社内端末 | *.update.microsoft.com 等 | Outbound | TCP 443/80（+7680） | スキャン/取得/配信最適化 | Windows Update セキュリティ/トラブルシューティング |
ありがちな落とし穴チェックリスト（ここを潰すと早い）
- 「WSUS を使うのに、端末がインターネットへ出ようとしている」：端末がどこを更新元としているかを確認し、GPO/MDM が意図通りか点検する。
- WinHTTP のプロキシ未設定：ユーザープロキシが設定されていても、WinHTTP が空だと更新が失敗することがある。
- HTTP RANGE をプロキシがブロック：ダウンロード失敗や過剰再ダウンロード（帯域/CPUの無駄）につながる。
- TLS 検査の一律適用：証明書固定の通信は例外が必要。更新メタデータの 443 が特に影響を受けやすい。
- Windows Store も同時に切ってしまった：WSUS 構成と関連するポリシー/レジストリの扱いによっては、Store 接続に影響することがある。
「端末がどこへ接続しているか」を確認したい場合、公式トラブルシューティングで紹介されている方法として、PowerShell から更新サービスの一覧を確認する手順があります（出力から WSUS/WU/Microsoft Update を判定できます）。
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services参考：最新情報に辿り着くための Microsoft 公式ドキュメント
ファイアウォール要件は更新され得るため、ブックマークして「このページに書いてある内容を根拠にする」運用にすると、属人化を防げます。
- 手順 2 – WSUS を構成する（ネットワーク接続/許可ドメイン一覧）
https://learn.microsoft.com/ja-jp/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus - WSUS 展開を計画する（既定ポート 80/443/8530/8531 の整理）
https://learn.microsoft.com/ja-jp/windows-server/administration/windows-server-update-services/plan/plan-your-wsus-deployment - Windows Server Update Services を使用して更新プログラムをデプロイする（WSUS 既定ポート/注意点）
https://learn.microsoft.com/ja-jp/windows/deployment/update/waas-manage-updates-wsus - Windows Update のセキュリティ（443/80/7680、証明書固定、IP範囲を提供しない理由）
https://learn.microsoft.com/ja-jp/windows/deployment/update/windows-update-security - Windows Update の問題のトラブルシューティング（エンドポイント例、HTTP/プロキシ、RANGE 要件）
https://learn.microsoft.com/ja-jp/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting - Windows 11 Enterprise の接続エンドポイントの管理（Windows Update 領域の宛先一覧）
https://learn.microsoft.com/ja-jp/windows/privacy/manage-windows-11-endpoints
上記を踏まえて、「クライアントがどこへ行くのか」→「外へ出るノードは誰か」→「送信元→宛先→ポート」の順に通信要件を組み立てると、“ゼロから許可する” 場合でも筋の通ったホワイトリストを作れます。
コメント