Microsoft Defender for Endpoint standard connectivity URLsの更新点と管理者の対応ポイント

Microsoft Defender for Endpointの接続先URLをファイアウォールやプロキシで厳しく制御している環境では、Microsoft Defender for Endpoint standard connectivity URLsの更新確認が必要です。結論から言うと、2026年6月上旬の公式情報で特に確認すべきなのは、reflector.defender.microsoft.comの追加、SmartScreen関連URL、Mac/Linux向け更新配信URL、*.endpoint.security.microsoft.comを含む合理化された接続への備えです。

今回の内容は、端末側の機能変更というより、Defender for Endpointがクラウドサービスと通信するための許可リスト・プロキシ・SSL検査除外・移行計画に関わる更新です。URLを固定的に管理している企業、閉域に近いネットワーク、プロキシ認証を使っている環境、IntuneやDefender for Cloudでオンボードしている環境では、早めに差分確認を行いましょう。Microsoft Learnの公式ページでは、この一覧が商用クラウド環境でデバイスをMicrosoft Defender for Endpointにオンボードし、維持するために必要な標準接続URLとして説明されています。(Microsoft Learn)

Microsoft Defender for Endpoint standard connectivity URLsとは

Microsoft Defender for Endpoint standard connectivity URLsは、商用クラウド環境でDefender for Endpointを利用する端末が、クラウド保護、EDR、セキュリティインテリジェンス更新、サンプル送信、ポータル操作などを行うために必要な接続先をまとめた公式リストです。

ここで重要なのは、「Defenderの画面が開けるか」だけを見るのでは不十分だという点です。端末が正しくオンボードされていても、必要なURLの一部がブロックされると、次のような問題が起きる可能性があります。

クラウド配信の保護が期待通りに動作しない
EDRの通信やテレメトリ送信に遅延・失敗が出る
Live Responseや自動調査など一部機能の応答が遅くなる
セキュリティインテリジェンスやエージェント更新が失敗する
管理ポータルからのオンボードパッケージ取得やファイル取得に支障が出る

公式リストでは、URLごとに「地理」「カテゴリ」「ポート」「必須または任意」「対象OS」「コメント」が示されています。たとえば、CRL確認には80番、Defender for EndpointやMicrosoft Defender Antivirus関連の多くの通信には443番が使われます。(Microsoft Learn)

2026年6月上旬の更新で確認すべき主な変更点

2026年6月上旬時点で管理者が優先して確認したいのは、単に「新しいURLが増えたか」ではありません。自社の通信制御ルール、対象OS、利用機能、移行方針に照らして、追加・変更された接続先が必要かどうかを判断することが重要です。

公式変更ログでは、直近の主な変更としてreflector.defender.microsoft.comの追加、Mac/Linux向け製品更新のCDN参照変更、SmartScreen関連URLの追加、Azure UAE North/Central向けURLの追加などが示されています。(Microsoft Learn)

変更項目	管理者が確認すべきポイント	影響を受けやすい環境
`reflector.defender.microsoft.com`の追加	IPv6接続のプローブに使われる任意URL。厳格なアウトバウンド制御をしている場合は、許可リストへの追加要否を確認する	FQDN単位で通信を制御している環境、IPv6関連の通信を監視・制限している環境
SmartScreen関連URLの追加	`.checkappexec.microsoft.com`、`.urs.microsoft.com`がSmartScreenによる信頼済みアプリ実行チェックに関係する	SmartScreen、ネットワーク保護、カスタムURLインジケーターを使うWindows環境
Mac/Linux向けCDN参照の変更	`officecdn-microsoft-com.akamaized.net`を前提にした古い許可設定が残っていないか確認する	macOS/LinuxのMDEエージェントを運用している環境
Azure UAE North/Central向けURL追加	UAEリージョンに関係するテナントや拠点がある場合、データ所在地と通信先を確認する	多国籍企業、リージョン別に通信制御している環境
「Microsoft Defender processes」から「Client processes」への整理	URLだけでなく、端末上のDefender関連プロセス通信がブロックされていないか再確認する	EDR/AVプロセスをサードパーティ製品で制御している環境

reflector.defender.microsoft.comは「任意」とされていますが、任意だから無視してよいとは限りません。Defender for Endpointの一部機能やMicrosoft Security Intelligenceによる検出支援に関係するため、セキュリティ機能を最大限に活用したい環境では、ブロックログを確認したうえで許可を検討するのが現実的です。公式リストでは、このURLはIPv6接続のプローブに使用され、Microsoft Security Intelligenceによる攻撃者アクティビティ検出に役立つと説明されています。(Microsoft Learn)

影響範囲は「端末」だけでなくネットワーク全体に及ぶ

今回確認すべき範囲は、Defender for Endpointをインストールしている端末だけではありません。実務では、以下のようなチームや設定が関係します。

担当領域	確認すべき内容
ネットワーク管理者	ファイアウォール、プロキシ、SSL/TLSインスペクション、DNS解決、FQDN許可リスト
セキュリティ運用担当	EDR通信、Live Response、クラウド配信の保護、SmartScreen、アラート検知状況
Microsoft 365管理者	Microsoft Defenderポータル、オンボードパッケージ、Intune連携、Defender for Cloud連携
サーバー管理者	Windows Server 2012 R2/2016の統合エージェント化、MMA利用端末の扱い
Mac/Linux管理者	MDEエージェント更新、`packages.microsoft.com`、CDN、`mdatp`サービス再起動
開発者・SRE	Terraform、プロキシPAC、Ansible、JAMF、Intuneポリシーなどの構成管理コード

特に注意したいのは、Defender for Endpoint Plan 1とPlan 2は同じプロキシサービスURLを共有する点です。Microsoftのネットワーク構成手順では、ファイアウォールで地理列がWWのURLを開き、WW以外の行は自社テナントのデータ所在地に対応するURLを開くよう案内されています。さらに、*.blob.core.windows.net全体をネットワーク検査から除外するのではなく、MDE固有のBlob URLだけを除外するよう注意されています。(Microsoft Learn)

標準接続と合理化された接続の違いを整理する

Microsoft Defender for Endpointには、従来型のstandard connectivityと、接続先を集約するstreamlined connectivityがあります。今回の標準接続URLリストを確認するときは、自社がどちらの接続方式を使っているか、今後どちらへ寄せるのかも合わせて確認しましょう。

項目	標準接続	合理化された接続
接続先の考え方	サービス、地域、機能ごとに複数のURLを許可する	`*.endpoint.security.microsoft.com`など集約されたURLパターンを使う
運用負荷	URL数が多く、地域・OS・機能ごとの差分管理が必要	接続先を減らしやすいが、前提条件の確認が必要
向いている環境	レガシーOS、MMAベース端末、既存の標準接続を維持する環境	新規展開、対応OS・対応エージェントへ更新済みの環境
注意点	URL差分を定期的に追う必要がある	CRL、Windows Update、SmartScreenなど一部の必須サービスは引き続き別途必要
移行時の扱い	既存端末はそのまま動作する	既存端末の再オンボード、再起動、サービス再起動が必要になる場合がある

Microsoftは、商用デバイス向けの合理化された接続先として*.endpoint.security.microsoft.comを示し、クラウド配信の保護、マルウェアサンプル送信ストレージ、Auto-IRサンプルストレージ、Defender for Endpointのコマンド＆コントロール、サイバーおよび診断データの接続を統合すると説明しています。一方で、合理化された接続方式はDefender for Endpointの機能やエンドユーザー体験を変えるものではなく、変更されるのはサービス接続に使うURLまたはIPです。(Microsoft Learn)

また、古いサービスURLを廃止する計画はないとされていますが、今後の機能のために*.endpoint.security.microsoft.comへの継続的な接続性を確保するよう案内されています。つまり、標準接続を使い続ける場合でも、この集約ドメインを完全に無視する運用は避けたほうが安全です。(Microsoft Learn)

管理者が最初に確認すべき5つの設定

ファイアウォールのFQDN許可リスト

まず確認すべきは、ファイアウォールやセキュアWebゲートウェイの許可リストです。公式リストにあるURLを一括で追加するのではなく、以下の順番で棚卸ししましょう。

確認項目	実務上の判断基準
`WW`のURL	全テナント共通で必要になりやすいため、原則として優先確認
地域別URL	自社テナントのデータ所在地に合うものを確認
Required	対象OS・対象機能に該当する場合は原則許可
Optional	使用している機能に関係する場合は許可を検討
Blob URL	`*.blob.core.windows.net`全体ではなく、MDE固有のURLに絞る
ポータルURL	すべての端末ではなく、管理者端末や運用端末で必要かを確認

「Optional」と書かれているURLでも、Live Response、Security Management for Microsoft Defender for Endpoint、ネットワークデバイスの脆弱性評価、SmartScreenの一部機能などを使っている場合は実質的に必要になることがあります。たとえばlogin.microsoftonline.comはLive Responseやネットワークデバイスの脆弱性評価、Defender for Endpointのセキュリティ管理に関係するURLとして記載されています。(Microsoft Learn)

プロキシ認証とSSL/TLS検査

Defender for Endpointの通信では、プロキシ認証やSSL/TLS検査がトラブルの原因になりやすいポイントです。Microsoftの手順では、Defender for Endpoint向け通信について、プロキシが認証を要求したり、セキュアチャネルを壊すHTTPSスキャンやSSL検査を行ったりしないよう注意されています。(Microsoft Learn)

合理化された接続の説明でも、サービス接続は証明書ピンニングとTLSを使用し、トラフィック検査はサポートされないとされています。また、通信はユーザー起点ではなくデバイス起点のため、ユーザー認証を強制するプロキシは接続性を壊す可能性があります。(Microsoft Learn)

実務では、次のような設計が必要です。

NGになりやすい設定	推奨される見直し
Defender関連URLに対してSSLインスペクションを行う	DefenderサービスURLを検査除外にする
ユーザー認証必須のプロキシを通す	デバイスコンテキストの通信を許可する
ブラウザ用プロキシだけを設定する	WinHTTPやDefender Antivirus側のプロキシ設定も確認する
プロキシPACにDefender関連URLが未反映	PAC、明示プロキシ、SWG設定を同時に更新する

Windowsでは、Defender for EndpointセンサーがLocalSystemアカウントのシステムコンテキストで動作し、センサー通信にはWinHTTPが関係します。ブラウザでインターネットに出られることと、Defenderセンサーがクラウドに通信できることは同じではありません。(Microsoft Learn)

Microsoft Defender AntivirusとEDRのプロキシ設定

Defender for Endpointでは、EDR側とMicrosoft Defender Antivirus側でプロキシ設定を分けて考える必要があります。Microsoftのプロキシ設定手順でも、EDRとMicrosoft Defender Antivirusの2種類のプロキシ設定を正しく構成する必要があると説明されています。(Microsoft Learn)

確認例として、Windows端末では次のような観点をチェックします。

netsh winhttp show proxy

Microsoft Defender Antivirusのクラウド保護接続を確認する場合は、管理者権限のコマンドプロンプトでMpCmdRun.exe -ValidateMapsConnectionを実行して確認できます。公式の移行確認手順でも、クラウド保護のネットワーク接続確認としてこのコマンドが案内されています。(Microsoft Learn)

MpCmdRun.exe -ValidateMapsConnection

ただし、端末によってMpCmdRun.exeの場所が異なる場合があります。実運用では、最新のDefenderプラットフォームフォルダーを確認したうえで実行してください。

DefenderポータルURL

DefenderポータルURLは、すべてのエンドポイント端末に必要とは限りません。管理者やSOC担当者がMicrosoft Defenderポータルにアクセスする端末では、ポータル関連URLが必要です。

公式リストでは、Microsoft Defender Security Center Portal URLへアクセスするために必要なURLとして、security.microsoft.com、login.microsoftonline.com、*.securitycenter.windows.com、オンボードパッケージ用のBlob URLなどが示されています。(Microsoft Learn)

実務では、次のように分けて考えると整理しやすくなります。

端末種別	必要な確認
一般利用者PC	Defenderセンサー、AV、SmartScreen、更新、CRLなどの通信
SOC端末	上記に加えてDefenderポータル、調査、ファイル取得関連
管理者端末	オンボードパッケージ取得、Intune、Defender XDR管理画面へのアクセス
サーバー	GUIポータルよりもEDR通信、更新、プロキシ、CRLを重視

クライアントプロセスの除外

URLだけを許可しても、端末上でDefender関連プロセスの通信が別のセキュリティ製品によりブロックされていると、期待通りに動作しません。

公式ページでは、Defender for Endpoint関連プロセスはネットワーク通信を生成するため、これらのプロセスからの通信がブロックされていないことを確認するよう説明されています。Windows、macOS、Linuxごとに除外対象プロセスが示されており、WindowsではMsSense.exe、SenseCncProxy.exe、SenseIR.exe、MsMpEng.exeなどが含まれます。(Microsoft Learn)

サードパーティ製EDR、アンチウイルス、アプリケーション制御、ゼロトラスト系エージェントを併用している場合は、Defender関連プロセスが通信制御や隔離対象になっていないかを必ず確認してください。

移行を検討すべき環境と、標準接続を維持すべき環境

合理化された接続は魅力的ですが、すべての環境で即時移行すべきとは限りません。判断基準は、OS、エージェント、既存ポリシー、検証体制です。

環境	推奨される方針
Windows 10 1809以降、Windows 11、Windows Server 2019以降が中心	合理化された接続への移行を検討しやすい
Windows Server 2012 R2/2016で最新の統合ソリューションを利用	前提条件を満たすか確認して移行検討
Windows 7、Windows 8.1、Windows Server 2008 R2 MMA	MMAベースの標準接続を継続
Windows 10 1607/1703/1709/1803	合理化されたオンボードパッケージは利用できるが、長いURLリストが必要。既存端末の再オンボードには注意
macOS/Linux	MDE製品バージョン、CDN、`mdatp`サービス再起動、パッケージ配布方法を確認
Intune/Defender for Cloudで自動オンボード	既存端末が自動的に再オンボードされるわけではない点に注意

合理化された接続の前提条件では、Windows 10 version 1809以降、Windows 11、Windows Server 2019以降、統合ソリューションを実行するWindows Server 2012 R2/2016、対応バージョンのmacOS/Linuxなどが対象として示されています。一方で、MMAエージェントを使う端末は合理化された接続方式をサポートせず、標準URLセットを継続する必要があります。(Microsoft Learn)

移行時に失敗しやすいポイント

既存端末が自動的に切り替わると思い込む

IntuneやDefender for Cloudで新しい設定を有効にしても、既存端末が自動的に再オンボードされるとは限りません。Microsoftのネットワーク構成手順では、既にオンボード済みのデバイスは自動的には再オンボードされないため、Intuneではテストデバイスに新しいポリシーを割り当てて検証してから対象を広げることが推奨されています。(Microsoft Learn)

移行手順でも、既存端末の移行は小さく始め、接続を検証し、段階的に拡大する流れが推奨されています。(Microsoft Learn)

標準URLを早く削除しすぎる

合理化された接続へ移行する場合でも、いきなり既存の標準URL許可を削除するのは危険です。移行手順では、小規模な端末群でオンボードを適用して接続を監視し、正常性を確認してから段階的に拡大し、最終段階で古いURLをネットワーク機器から削除する流れが示されています。(Microsoft Learn)

実務では、少なくとも次の条件を満たすまでは、古い標準接続URLを残しておくのが安全です。

Defenderポータル上で端末が正常に表示されている
Device Inventoryに継続して表示される
アラートやタイムラインイベントが流れている
Live Responseの基本コマンドが成功する
クラウド配信の保護テストが成功する
主要OSごとのテスト端末で接続方式を確認できている

再起動・サービス再起動を忘れる

移行手順では、Windowsは再起動、macOSは再起動またはDefender for Endpointサービス再起動、Linuxはsudo systemctl restart mdatpが必要になる場合があります。特にLinuxでは、再起動しないと合理化された接続方式への切り替えが始まらないと説明されています。(Microsoft Learn)

sudo systemctl restart mdatp

macOSでは、サービス再起動の例として次のコマンドが示されています。(Microsoft Learn)

sudo launchctl unload /Library/LaunchDaemons/com.microsoft.fresno.plist
sudo launchctl load /Library/LaunchDaemons/com.microsoft.fresno.plist

MMA端末を合理化された接続へ移せると思い込む

MMA、つまりMicrosoft Monitoring Agentベースの端末は、合理化された接続方式の対象外です。Windows 7、Windows 8.1、Windows Server 2008 R2、統合エージェントへ移行していないWindows Server 2012 R2/2016などは、引き続きMMAオンボード方式を使う必要があります。(Microsoft Learn)

この種の端末が残っている環境では、「URLリストを減らす」よりも先に、OS更改、統合エージェント化、サポート対象の見直しを検討しましょう。

展開前後の確認手順

URL追加や移行を行う場合は、変更前・変更中・変更後で確認する項目を分けると失敗を減らせます。

フェーズ	確認内容	具体的な作業例
変更前	現在の接続方式と対象端末を把握	OS、MDEバージョン、MMA有無、Intune/JAMF/GPO/ConfigMgrのポリシー確認
変更前	公式URLリストとの差分確認	`reflector.defender.microsoft.com`、SmartScreen URL、CDN参照、`*.endpoint.security.microsoft.com`を確認
変更中	小規模グループに適用	テスト端末へポリシー適用、再起動またはサービス再起動
変更後	通信正常性を確認	MDE Client Analyzer、Event Viewer、Advanced Hunting、`mdatp connectivity test`
変更後	セキュリティ機能を確認	Live Response、クラウド保護、SmartScreen、アラート発生テスト
安定後	古い設定を整理	標準URL削除は段階的に行い、ロールバック手順を残す

Windows端末では、MDE Client Analyzerを使って適切なURLへ接続できているか確認できます。合理化された接続の確認では、オンボードパッケージを指定するmdeclientanalyzer.cmd -o <path to cmd file>や、テナントの地域に応じたmdeclientanalyzer.cmd -g <GW_US, GW_UK, GW_EU>が案内されています。(Microsoft Learn)

mdeclientanalyzer.cmd -o <path-to-onboarding-package>
mdeclientanalyzer.cmd -g <GW_US|GW_EU|GW_UK>

Microsoft Defender XDRのAdvanced Huntingでは、DeviceInfoテーブルのConnectivityType列で接続方式の状態を確認できます。公式手順では、値としてStreamlined、Standard、空白が示されています。(Microsoft Learn)

DeviceInfo
| where OnboardingStatus == "Onboarded"
| summarize arg_max(Timestamp, ConnectivityType, OSPlatform) by DeviceName

ローカル確認では、WindowsのイベントビューアーでMicrosoft-Windows-SENSE/Operationalログを確認します。公式手順では、SENSE Event ID 4がDefender for Endpoint Command & Controlチャネルへの正常接続を追跡すると説明されています。(Microsoft Learn)

開発者・SREが確認すべき構成管理上のポイント

Microsoft Defender for EndpointのURL更新は、セキュリティ管理者だけの作業ではありません。ネットワークや端末設定をコードで管理している場合、次の場所に古いURLや不足した許可設定が残りがちです。

Terraform、Bicep、ARMテンプレートのNSG・Azure Firewallルール
プロキシPACファイル
Zscaler、Netskope、Prisma AccessなどのSWGルール
Intuneの構成プロファイル
Group Policy
JAMF ProのmacOS向けポリシー
Ansible、Chef、PuppetなどのLinux配布スクリプト
ConfigMgrの展開パッケージ
監視ツールの通信許可・アラート除外ルール

開発者やSREが特に注意すべきなのは、「本番のファイアウォール設定だけ直して、構成管理コードを直していない」状態です。この状態では、次回の自動適用や別環境展開で古い設定に戻る可能性があります。

実務では、次のようなレビュー項目をPull Requestのチェックリストに入れると安全です。

- [ ] Microsoft Defender for Endpoint standard connectivity URLsの差分を確認した
- [ ] `WW`とテナントのデータ所在地に応じたURLを分けて反映した
- [ ] `reflector.defender.microsoft.com`の追加要否を確認した
- [ ] SmartScreen関連URLの利用有無を確認した
- [ ] Mac/Linux向けCDN参照を古いホスト名に固定していない
- [ ] SSL/TLS検査除外とプロキシ認証除外を確認した
- [ ] 標準接続から合理化された接続への移行対象を分けた
- [ ] MMA端末を合理化された接続の対象に含めていない
- [ ] テスト端末でMDE Client AnalyzerまたはAdvanced Huntingによる確認を行った

よくある疑問

`reflector.defender.microsoft.com`は必ず許可すべき？

公式リスト上は任意です。ただし、IPv6接続のプローブに使われ、Microsoft Security Intelligenceによる攻撃者アクティビティ検出に役立つと説明されています。厳格な通信制御をしている環境では、まずブロックログを確認し、Defender関連通信として許可するかをセキュリティポリシーに沿って判断しましょう。(Microsoft Learn)

`*.endpoint.security.microsoft.com`を許可すれば標準URLは不要になる？

すぐに不要になるとは考えないほうが安全です。合理化された接続ではコアサービスが集約されますが、CRL、Windows Update、SmartScreenなど、統合対象外のサービスは引き続き必要になる場合があります。Microsoftの説明でも、簡素化ドメインを使う場合でも標準接続URLリストにある残りの必須サービスへの接続を維持する必要があるとされています。(Microsoft Learn)

すべての`*.blob.core.windows.net`を許可・除外してよい？

推奨されません。Microsoftの構成手順では、*.blob.core.windows.net全体をネットワーク検査から除外するのではなく、MDEに固有のBlob URLだけを除外するよう注意されています。(Microsoft Learn)

IPv6-only環境でも使える？

Microsoftのプロキシ構成手順では、IPv6-onlyトラフィックに構成されたデバイスはサポートされないと記載されています。今回追加されたreflector.defender.microsoft.comがIPv6接続のプローブに使われるからといって、IPv6-only構成がサポートされるという意味ではありません。(Microsoft Learn)

標準接続を使っている既存端末はすぐ移行が必要？

必ずしも即時移行が必要な内容ではありません。合理化された接続の説明では、古いサービスURLを廃止する計画はなく、標準接続でオンボード済みのデバイスは継続して機能するとされています。ただし、今後の機能のために*.endpoint.security.microsoft.comへの接続性を確保するよう案内されているため、次回のネットワーク変更や端末更改に合わせて移行計画を立てるのが現実的です。(Microsoft Learn)

管理者が取るべき次のアクション

今回のMicrosoft Defender for Endpoint standard connectivity URLs更新は、派手な機能追加ではありません。しかし、URL許可リストやプロキシ設定が古いままだと、Defender for Endpointの検出・応答・更新・管理操作に影響が出る可能性があります。

まずは次の順番で確認してください。

自社端末のOS、MDEバージョン、MMA利用有無、接続方式を棚卸しする
公式URLリストとの差分を確認し、reflector.defender.microsoft.com、SmartScreen関連URL、Mac/Linux向けCDN参照を確認する
ファイアウォール、プロキシ、SSL/TLS検査、DNS、PAC、SWGの設定を見直す
WWのURLと、自社テナントのデータ所在地に対応するURLを分けて管理する
合理化された接続へ移行する場合は、小規模テスト、接続確認、段階展開、旧URL削除の順で進める
変更後はMDE Client Analyzer、Advanced Hunting、Event Viewer、Live Response、クラウド保護テストで確認する

最も避けたいのは、「Defenderポータル上で端末が見えているから問題ない」と判断してしまうことです。Microsoft Defender for Endpointは複数のクラウドサービスと連携して動作します。URLリストの更新は、セキュリティ機能を安定して使い続けるための運用作業として、定期的にレビューしましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。