Microsoft Intune の「Manage endpoint security policies in Microsoft Intune」は、エンドポイント セキュリティ ポリシーを使ってデバイスのセキュリティ設定を管理するための公式ガイドです。今回の確認ポイントは、単に「新しい設定が増えたか」ではありません。重要なのは、Intune の Endpoint security、Device configuration、Security baselines、Microsoft Defender for Endpoint 連携が同じデバイスにどう適用され、どこで競合しやすいかを整理することです。
2026年7月1日の公式 GitHub 履歴では、該当ドキュメントに「Metadata updates」が記録されています。本文レベルで強制移行や即時対応が必要な破壊的変更が示されたものではありませんが、管理者は RBAC 権限、ポリシー競合、Defender for Endpoint 連携、Linux 向け Antivirus 設定の追加などをあわせて確認しておくべきです。(GitHub)
Microsoft Intune のエンドポイント セキュリティ ポリシーとは
Microsoft Intune のエンドポイント セキュリティ ポリシーは、管理対象デバイスのセキュリティ設定に特化したポリシー群です。Microsoft Learn では、Security Administrators が Endpoint Security policies と profiles を使い、デバイスのセキュリティ構成に集中できると説明されています。通常のデバイス構成プロファイルよりも、ウイルス対策、ファイアウォール、ディスク暗号化、攻撃面の縮小など、セキュリティ目的ごとに管理しやすい点が特徴です。(Microsoft Learn)
Intune 管理センターでは、基本的に Endpoint security > Manage から各ポリシー種別にアクセスします。ここで作成するポリシーは「セキュリティ担当者が見るべき設定」を中心に整理されているため、全社的なデバイス管理担当と SOC／セキュリティ運用担当が分担しやすくなります。(Microsoft Learn)
一方で、同じ設定を Security baselines、Device configuration、Settings catalog、Endpoint security の複数箇所で管理すると、設定競合が起きやすくなります。Intune では複数のポリシー種別が同じデバイス設定のソースになり得るため、「どの設定をどのポリシーで管理するか」を決めずに展開すると、適用失敗や conflict 状態の原因になります。(Microsoft Learn)
今回の更新ポイントを実務目線で整理
今回の「Manage endpoint security policies in Microsoft Intune」で管理者が見るべきポイントは、次のとおりです。
| 確認ポイント | 実務への影響 | 管理者が行うべきこと |
|---|---|---|
| 2026年7月1日のドキュメント履歴 | GitHub 上ではメタデータ更新として記録。機能廃止や強制移行を示す内容ではない | 公式本文だけでなく、関連する Intune What’s new も確認する |
| エンドポイント セキュリティ ポリシーの整理 | Antivirus、Firewall、Disk encryption、EDR などをセキュリティ用途別に管理しやすくなる | 既存の Device configuration や Security baselines と重複していないか棚卸しする |
| ポリシー競合 | 同じ設定に異なる値が配布されると、設定が適用されない可能性がある | 設定ごとの管理元を決め、競合レポートを確認する |
| RBAC 権限 | Endpoint security の一部ワークロードで粒度の細かい権限が使われる | カスタムロールを利用している組織は権限不足を確認する |
| Microsoft Defender for Endpoint 連携 | Intune 未登録端末にも一部のセキュリティ設定を適用できる | MDE 管理端末、Intune 登録端末、ConfigMgr 管理端末の境界を整理する |
| Linux Server 向け Antivirus 設定 | Service release 2606 で既存の Linux 向け Antivirus ポリシーに新しい設定が追加 | Linux Server を管理している場合は既存プロファイルを確認する |
特に重要なのは、今回の対象ページ単体では「いつまでに移行しなければならない」という明確な移行期限が示されていない点です。したがって、慌てて設定を変更するよりも、まずは既存ポリシーの重複、RBAC、Defender 連携対象を確認するのが現実的です。
影響範囲：誰が、どのデバイスを、どのポリシーで管理するのか
エンドポイント セキュリティ ポリシーの影響範囲は、Windows だけではありません。ポリシー種別によって、Windows、macOS、Linux が対象になります。Microsoft Learn では、Antivirus は Windows、macOS、Linux、Disk encryption は Windows と macOS、Endpoint detection and response は Windows、macOS、Linux、Firewall は Windows と macOS を対象に含むと整理されています。(Microsoft Learn)
| ポリシー種別 | 主な対象プラットフォーム | 代表的な用途 | 注意点 |
|---|---|---|---|
| Account protection | Windows | Windows Hello、LAPS、ローカル管理者グループ管理 | ID 保護や管理者権限の運用ルールとセットで設計する |
| Antivirus | Windows、macOS、Linux | Microsoft Defender Antivirus、除外設定、更新制御 | 除外設定を安易に広げると防御効果が下がる |
| App Control for Business | Windows | WDAC によるアプリ実行制御 | 検証なしに本番適用すると業務アプリが起動できない可能性がある |
| Attack surface reduction | Windows | ASR ルール、Device control、Exploit protection | Microsoft Defender Antivirus が主たるウイルス対策であることが前提になる設定がある |
| Disk encryption | Windows、macOS | BitLocker、Personal Data Encryption、FileVault | 回復キーの保管先とヘルプデスク手順を先に決める |
| Endpoint detection and response | Windows、macOS、Linux | Microsoft Defender for Endpoint のオンボーディングと構成 | Defender for Endpoint のライセンスとテナント接続が必要 |
| Firewall | Windows、macOS | OS 標準ファイアウォール、Windows Firewall rules | ネットワーク、VPN、業務アプリ通信との整合性を確認する |
この表で見るべきポイントは、「全ポリシーを一律に有効化すること」ではありません。たとえば、Windows 11 クライアント、Windows Server、macOS、Linux Server が混在するグローバル企業では、同じ Antivirus でも運用上の論点が異なります。Windows では Defender Antivirus の標準構成と ASR ルール、macOS では Defender for Endpoint エージェントの状態、Linux ではエージェント更新やスキャンスケジュールが重要になります。
設定変更で最も失敗しやすいのは「競合」
Intune のエンドポイント セキュリティ ポリシーで最も多い失敗は、機能を知らないことではなく、同じ設定を複数の場所で管理してしまうことです。Microsoft Learn では、Intune の複数のポリシー種別はデバイス構成設定のソースとして同等に扱われ、同じ設定に異なる値が配布されると競合が起こると説明されています。(Microsoft Learn)
たとえば、次のような構成は注意が必要です。
| 競合しやすい例 | 起こり得る問題 | 見直し方 |
|---|---|---|
| Security baseline と Endpoint security の両方で BitLocker を設定 | 片方の設定が conflict になり、暗号化状態の確認が難しくなる | BitLocker は Disk encryption ポリシーで管理するのか、Baseline で管理するのかを決める |
| Device configuration と Firewall ポリシーの両方でファイアウォール規則を設定 | 業務アプリ通信が想定外にブロックされる | Windows Firewall rules は Endpoint security 側に集約する |
| 複数の Antivirus ポリシーで除外設定や保護設定を分ける | どのポリシーが最終的に効いているか追いづらくなる | 例外設定は用途別に命名し、対象グループを明確にする |
| ASR ルールを複数プロファイルで段階的に展開 | テストリングと本番リングの両方が同じ端末に当たる | Entra ID グループのメンバーシップを重複させない |
実務では、ポリシー作成前に「設定の所有者」を決めると事故を減らせます。たとえば、Firewall と Antivirus はセキュリティチーム、Wi-Fi や VPN はエンドポイント管理チーム、Windows の広範な推奨設定は Security baseline というように、管理元を文書化します。
判断基準はシンプルです。セキュリティ機能そのものを管理するなら Endpoint security、OS やアプリの広範な構成なら Settings catalog や Device configuration、Microsoft 推奨の初期値をまとめて適用するなら Security baselines を使います。ただし、Security baselines は便利な反面、意図せず多くの設定を持ち込むため、既存の Endpoint security ポリシーと重複しないかを必ず確認してください。
RBAC：カスタムロールを使っている組織は要確認
今回の公式情報で見落としやすいのが RBAC です。Intune は、すべてのエンドポイント セキュリティ ワークロードに一律の Security baselines 権限を使う形から、ポリシー種別ごとの粒度の細かい権限へ移行中と説明されています。これにより、ポリシー種別によって必要な権限が異なります。(Microsoft Learn)
公式情報では、App Control for Business、Attack surface reduction の多く、Endpoint detection and response は粒度の細かい権限を使う一方、Antivirus、Account protection、Disk encryption、Firewall、一部の Attack surface reduction プロファイルは Security baselines 権限を使うとされています。さらに、Antivirus の粒度の細かい権限が一部テナントで一時的に見える場合があるものの、リリース済みではなく、設定しても Intune では無視されると明記されています。(Microsoft Learn)
| 管理対象 | 権限確認のポイント | 実務上の注意 |
|---|---|---|
| Endpoint Security Manager | エンドポイント セキュリティ全般を管理できる | セキュリティ管理者に付与しやすいが、権限が広い |
| Help Desk Operator | 一部の運用作業と参照 | 設定変更を任せる用途には向かない |
| Read Only Operator | ポリシーとレポートの参照 | 監査担当や SOC の一次確認に向く |
| カスタムロール | ポリシー種別ごとの権限を確認 | App Control、ASR、EDR で権限不足が起きやすい |
| Defender ポータル連携 | Intune RBAC と整合させる | Defender 側だけ権限があっても Intune ポリシー管理で詰まる場合がある |
管理者が今すぐ行うべきなのは、既存のカスタムロールを棚卸しすることです。特に、以前から Security baselines 権限を前提にしていたロールでは、App Control for Business や EDR の作成・編集・レポート参照が期待通りできるかを確認してください。
また、Multi Admin Approval を使っているテナントでは、ロール変更そのものに承認フローが必要になる場合があります。セキュリティチームの権限見直しは、ポリシー変更の直前ではなく、運用設計の段階で済ませておくべきです。(Microsoft Learn)
Microsoft Defender for Endpoint 連携で変わる管理範囲
Microsoft Intune のエンドポイント セキュリティ ポリシーは、Microsoft Defender for Endpoint と深く連携します。公式ページでは、EDR は Defender for Endpoint のテナント接続とライセンスが必要であり、Antivirus、Attack surface reduction、Application Control なども Defender の機能やエージェントと関係すると説明されています。(Microsoft Learn)
特に重要なのが、Defender for Endpoint security settings management です。Intune と Defender for Endpoint を統合すると、Intune に登録されていないデバイスに対しても、一部の Intune エンドポイント セキュリティ ポリシーを使って Defender のセキュリティ設定を管理できます。対象には Windows、Windows Server 2012 R2 以降、Linux、macOS が含まれます。(Microsoft Learn)
ただし、ここで誤解しやすい点があります。すでに Intune に登録されているデバイスは、Defender for Endpoint security settings management のポリシーではなく、Intune の通常のポリシーで管理します。つまり、「Intune 登録済み端末」と「Defender 管理端末」を同じものとして扱わず、どちらの経路で設定を配布しているかを確認する必要があります。(Microsoft Learn)
Defender 連携を使う場合は、少なくとも次の条件を確認します。
| 確認項目 | 内容 |
|---|---|
| ライセンス | Microsoft Defender for Endpoint P1 以上など、対象機能を利用できるライセンス |
| テナント接続 | Intune と Defender for Endpoint のサービス間接続 |
| エージェント | 対象 OS に応じた Defender for Endpoint エージェント |
| ネットワーク | *.dm.microsoft.com への通信 |
| 対象グループ | Microsoft Entra ID のデバイスグループ |
| レポート確認 | Intune 管理センターと Defender ポータルの両方で状態確認 |
Defender 経由の管理では、ユーザー対象ではなくデバイスオブジェクトが中心になります。また、Microsoft Defender for Endpoint チャネル経由で通信するデバイスでは、Intune の assignment filters がサポートされない点にも注意が必要です。(Microsoft Learn)
Service release 2606 で関連して確認すべき Linux Server 向け Antivirus 設定
今回の対象ページそのものとは別に、Intune の What’s new では、Week of June 29, 2026、Service release 2606 として Linux Server 向けの Microsoft Defender Antivirus 設定追加が案内されています。既存の Endpoint security > Antivirus ポリシーの Microsoft Defender Antivirus プロファイルに、Offline security intelligence update と Scheduled scan の設定が追加されました。新しいプロファイルを作る必要はなく、既定では Not configured です。(Microsoft Learn)
Linux Server を Intune または Defender for Endpoint security settings management で管理している組織では、この変更は見逃せません。特にグローバル環境では、拠点やデータセンターによってネットワーク制約、メンテナンス時間、オフライン運用の頻度が異なります。スキャン時刻やセキュリティインテリジェンス更新を一律に設定すると、業務時間帯の負荷や通信量の増加につながる可能性があります。
実務では、次の順で確認すると安全です。
| 手順 | 作業内容 | 判断ポイント |
|---|---|---|
| 1 | 既存の Linux 向け Antivirus ポリシーを確認 | 追加設定が表示されるかを見る |
| 2 | 対象 Linux Server を分類 | 常時オンライン、閉域、低帯域、夜間稼働などで分ける |
| 3 | Offline security intelligence update の要否を判断 | オフライン時間が長い端末ほど重要 |
| 4 | Scheduled scan の時間帯を決める | 業務ピーク、バックアップ、バッチ処理と重ならないようにする |
| 5 | テストグループに展開 | いきなり全 Linux Server に配布しない |
| 6 | レポートで成功、エラー、競合を確認 | 端末単位・設定単位で確認する |
「既定が Not configured」だから放置してよい、とは限りません。既存の運用で Linux Server の Defender 設定を別の手段で管理している場合は、Intune 側で新設定を有効化すると二重管理になる可能性があります。逆に、これまでスキャンや更新を明示的に管理できていなかった環境では、今回の追加設定は運用標準化のきっかけになります。
エンドポイント セキュリティ ポリシーの作成・変更手順
新しいエンドポイント セキュリティ ポリシーを作成する流れは、公式ページでは次のように整理されています。Intune 管理センターにサインインし、Endpoint security から目的のポリシー種別を選び、Create Policy を実行します。その後、Platform と Profile を選択し、Basics、Configuration settings、Scope tags、Assignments、Review + create の順に設定します。(Microsoft Learn)
実務では、作成手順そのものよりも、ポリシー名と割り当て設計が重要です。たとえば、次のような命名にすると後から追跡しやすくなります。
ES-AV-Windows-Defender-Prod-v2026-07
ES-FW-Windows-Rules-Pilot-v2026-07
ES-EDR-macOS-Onboarding-Global-v2026-07
ES-ASR-Windows-Audit-Pilot-v2026-07命名に含めたい要素は、ポリシー種別、対象 OS、用途、展開リング、作成時期です。特にグローバル企業では、地域名だけでポリシーを分けると設定内容が追えなくなります。地域差が必要な場合でも、まずは共通ポリシーを作り、例外だけを別ポリシーに分けるほうが管理しやすくなります。
既存ポリシーを複製する機能もあります。公式ページでは、ポリシーの Duplicate は既存構成をコピーして別シナリオ向けに変更できる機能とされ、複製されたポリシーは元の設定とスコープタグを保持しますが、割り当ては引き継がれません。(Microsoft Learn)
この仕様は安全面では有利です。複製しただけで本番グループに配布されることはありません。ただし、割り当てが空のままになり、「作ったつもりなのに適用されていない」という確認漏れも起こります。複製後は、必ず Assignments を設定し、テストグループでデバイス状態を確認してください。
ポリシー競合を防ぐ運用設計
エンドポイント セキュリティ ポリシーを安定運用するには、次の3つを最初に決めます。
| 設計項目 | 決めること | 例 |
|---|---|---|
| 管理元 | どの設定をどの機能で管理するか | BitLocker は Disk encryption、ASR は Endpoint security |
| 展開リング | どの順番で配布するか | Pilot → IT部門 → 一部拠点 → 全社 |
| 例外管理 | 例外をどこに記録し、誰が承認するか | 除外設定はチケット番号をポリシー説明欄に記録 |
競合が起きた場合は、いきなり設定値を変更するのではなく、まずレポートで「どの設定が」「どのデバイスで」「どのポリシーと競合しているか」を確認します。公式ページでも、競合のトラブルシューティングとして、ポリシー展開レポート、設定単位の状態、セキュリティ ベースラインの値、同じ設定を管理する複数ポリシーの確認が推奨されています。(Microsoft Learn)
| 症状 | よくある原因 | 確認場所 | 対処 |
|---|---|---|---|
| ポリシーが conflict になる | 同じ設定を複数ポリシーで異なる値にしている | Endpoint security のレポート、Per-setting status | 管理元を1つに絞る |
| 一部端末だけ適用されない | 対象グループやスコープタグが想定と違う | Assignments、Scope tags | グループメンバーとスコープタグを確認 |
| Defender 管理端末に適用されない | Intune 登録端末と MDE 管理端末を混同している | Managed by 列、Defender ポータル | 管理経路に合うポリシーに分ける |
| ヘルプデスクがレポートを見られない | RBAC 権限不足 | Intune roles、Custom roles | Read 権限やレポート権限を追加 |
| Linux 設定が想定どおりにならない | エージェント、通信、対象プロファイルの条件不足 | Defender portal、Intune report | エージェント状態と対象プラットフォームを確認 |
競合対策で最も効果があるのは、設定の一覧表を作ることです。すべての設定を完璧に棚卸しする必要はありません。まずは Antivirus、Firewall、BitLocker、ASR、EDR の5領域だけでも、管理元、対象グループ、例外、承認者を記録すると、トラブル対応の速度が大きく変わります。
移行期限はあるのか
今回の「Manage endpoint security policies in Microsoft Intune」単体では、特定の日付までに移行しなければならない強制移行期限は確認できません。したがって、管理者が取るべき行動は「即時移行」ではなく「運用整理」です。
ただし、移行期限がないからといって放置してよいわけではありません。Intune は RBAC、Security baselines、Defender 連携、Linux 管理などが継続的に更新されています。特にカスタムロールを使っている場合、今後の粒度の細かい権限モデルに備えて、Endpoint security の各ポリシーを誰が作成・編集・参照できるかを確認しておくべきです。(Microsoft Learn)
また、周辺の Intune 更新では、既存プロファイルが自動的に新しい推奨構成へ上がらないケースがあります。たとえば、Service release 2606 では Microsoft 365 Apps for Enterprise のセキュリティ ベースライン更新や Windows security baseline version 25H2 の設定追加も案内されており、既存プロファイルの扱いには管理者の確認が必要です。(Microsoft Learn)
つまり、移行期限の有無だけで優先度を決めるのではなく、次の基準で対応順を決めるのが現実的です。
| 優先度 | 対応内容 | 対象 |
|---|---|---|
| 高 | 競合中の Endpoint security ポリシーを解消 | すでに conflict や error が出ている端末 |
| 高 | RBAC 権限の不足確認 | カスタムロール、SOC、ヘルプデスク |
| 中 | Defender for Endpoint security settings management の対象整理 | Intune 未登録の Windows Server、Linux、macOS |
| 中 | Linux Server 向け Antivirus 追加設定の確認 | Linux Server 管理環境 |
| 中 | Security baselines と Endpoint security の重複確認 | Windows 10/11、Microsoft 365 Apps |
| 低 | 命名規則、説明欄、ドキュメント整備 | 全ポリシー |
グローバル環境での運用ポイント
グローバル企業では、エンドポイント セキュリティ ポリシーを国や地域ごとに無計画に分けると、数か月後に管理できなくなります。地域別に分けるべきなのは、法規制、ネットワーク要件、業務アプリ、メンテナンス時間が本当に異なる場合だけです。
たとえば、Firewall は国別よりも「社内ネットワーク」「VPN」「工場端末」「開発端末」のように用途別に分けたほうが運用しやすくなります。Antivirus の除外設定も、地域ではなくアプリケーション単位で管理したほうが、例外の理由を説明しやすくなります。
一方で、Linux Server の Scheduled scan は地域差を考慮したほうがよい場合があります。日本、欧州、米国で業務時間や夜間バッチの時間が異なる場合、一律のスキャン時刻ではなく、地域ごとまたはワークロードごとにポリシーを分けるほうが安全です。
グローバル運用では、次のルールをおすすめします。
| ルール | 目的 |
|---|---|
| 共通ポリシーを先に作る | 基本セキュリティ水準をそろえる |
| 例外ポリシーは少数に抑える | 例外の肥大化を防ぐ |
| ポリシー説明欄に変更理由を残す | 監査と引き継ぎを容易にする |
| Pilot グループを地域ごとに用意する | 地域固有の影響を早期に見つける |
| レポート確認日を運用カレンダーに入れる | 適用後の放置を防ぐ |
管理者が今すぐ確認すべきチェックリスト
エンドポイント セキュリティ ポリシーの更新ポイントを踏まえ、管理者は次の順で確認すると効率的です。
| チェック項目 | 確認内容 |
|---|---|
| 既存ポリシーの棚卸し | Endpoint security 配下の Antivirus、Firewall、ASR、EDR、Disk encryption を一覧化する |
| 重複設定の確認 | Security baselines、Device configuration、Settings catalog と同じ設定を管理していないか確認する |
| RBAC の確認 | Endpoint Security Manager、カスタムロール、レポート参照権限を確認する |
| Defender 連携の確認 | Intune 登録端末と MDE 管理端末を分けて確認する |
| Linux Server の確認 | 新しい Antivirus 設定が表示されるか、既定値のままでよいか確認する |
| レポート確認 | Success、Error、Conflict をポリシー単位・設定単位で見る |
| 例外設定の見直し | Antivirus 除外、Firewall 許可、ASR 除外の理由を確認する |
| 展開リングの整備 | Pilot、本番、例外グループを分離する |
| 変更記録 | ポリシー名、説明欄、チケット番号、承認者を残す |
まず取り組むべきなのは、新しいポリシーを作ることではなく、既存ポリシーの競合と権限不足を見つけることです。特に Endpoint security は、セキュリティ強化のつもりで設定しても、競合によって適用されなければ意味がありません。
まとめ：新機能よりも「管理設計」の見直しが重要
Microsoft Intune の「Manage endpoint security policies in Microsoft Intune」は、エンドポイント セキュリティ ポリシーを使ったデバイス保護の基本を整理する重要な公式情報です。2026年7月1日の履歴はメタデータ更新として確認されており、対象ページ単体で強制移行期限や破壊的変更が示されたわけではありません。
ただし、実務上は見直すべき点が多くあります。Endpoint security、Security baselines、Device configuration の競合、RBAC の粒度変更、Defender for Endpoint security settings management、Linux Server 向け Antivirus 設定の追加は、いずれも運用に影響します。
次に取るべき行動は明確です。まず Endpoint security 配下の既存ポリシーを一覧化し、同じ設定を複数の場所で管理していないかを確認してください。そのうえで、RBAC、Defender 連携、Linux Server の新設定、レポート監視を順に見直すと、Intune のエンドポイント セキュリティ管理を安全に整理できます。
コメント