Microsoft Intune の Endpoint Privilege Management（EPM）は、ユーザーをローカル管理者にしたまま運用するのではなく、標準ユーザー権限を基本にしながら、必要なファイルやスクリプトだけを一時的に昇格させるための機能です。今回確認すべきポイントは、「新しいボタンが増えた」というより、2026年7月1日以降の Microsoft 365 ライセンス・パッケージ変更により、EPMを検討できる組織が増える点と、管理者が標準ユーザー化の設計を始めやすくなる点です。Microsoft 365 E5 では、Microsoft 365 E3 に追加される機能に加えて、Intune Endpoint Privilege Management、Microsoft Cloud PKI、Intune Enterprise Application Management、Microsoft Security Copilot が追加対象として示されています。ロールアウトは2026年夏に進み、Microsoftの案内では関連機能の展開完了目安は2026年8月1日です。(Microsoft)
一方で、Microsoft Learn の「Use Endpoint Privilege Management with Microsoft Intune」ページ自体は、確認時点で最終更新日が2026年4月15日と表示されています。つまり、2026年7月1日の実務上の更新ポイントは、EPM概要ページ単体ではなく、Microsoft 365 のパッケージング変更と、EPMの導入・設定・レポート関連ドキュメントを合わせて読む必要があります。(Microsoft Learn)
Microsoft Intune Endpoint Privilege Managementとは何か
Microsoft Intune Endpoint Privilege Management は、Windowsデバイス上のユーザーを標準ユーザーとして運用しながら、業務上必要なアプリのインストール、ドライバー更新、診断ツールの実行など、管理者権限が必要な作業だけを制御された形で実行させる機能です。EPMはゼロトラストの考え方に沿って、常時付与されるローカル管理者権限を減らし、必要なときだけ最小限の権限昇格を許可する設計になっています。(Microsoft Learn)
従来の運用では、ユーザーにローカル管理者権限を与えたままにするか、すべてをヘルプデスク対応に寄せるかの二択になりがちでした。EPMを使うと、「このアプリのこの実行だけは許可する」「このファイルはサポート承認が必要」「この実行ファイルは昇格禁止」といったルールをIntune側で管理できます。
実務での価値は、単にユーザーの権限を下げることではありません。重要なのは、次の3つを同時に満たせることです。
| 観点 | EPMで実現しやすくなること |
|---|---|
| セキュリティ | ローカル管理者権限の常時付与を減らし、攻撃者が端末上で高権限を得るリスクを下げる |
| 業務継続 | 必要なアプリやツールは、事前承認・ユーザー確認・サポート承認などで実行できる |
| 監査 | 管理された昇格と管理外の昇格をレポートで確認し、ルール改善に使える |
2026年7月1日以降の更新ポイント
今回の更新で管理者が特に見るべき点は、EPMの機能そのものだけでなく、ライセンス上の扱いです。Microsoftの価格・パッケージング情報では、2026年7月1日から商用向け Microsoft 365 スイートの価格・パッケージ変更が有効になり、パッケージ変更は2026年6月からロールアウト、関連機能の展開完了目安は2026年8月1日とされています。既存顧客は、更新時期まで現在の価格が維持されるとも説明されています。(Microsoft)
MicrosoftのIntune製品ページでは、Intune Suiteの機能は2026年第3四半期から Microsoft 365 E5 と E7 に含まれ、一部機能は Microsoft 365 E3 にも含まれると説明されています。また、E5/E7以外のプランで個別アドオンを使う場合は、2026年7月1日以降、Microsoft Intune Plan 1 が基本ライセンス要件になるとされています。(Microsoft)
管理者が押さえるべき変更点
| 確認項目 | 実務上の意味 |
|---|---|
| Microsoft 365 E5での利用範囲 | EPMを追加購入前提で見送っていた組織でも、標準ユーザー化の検討を始めやすくなる |
| ロールアウト時期 | テナントごとに即日使えるとは限らないため、Message Centerやライセンス画面で確認する |
| 既存契約の更新時期 | 価格・契約影響は契約更新タイミングと国・通貨・契約形態に左右される |
| E3との違い | E3にはIntune Remote Help、Advanced Analytics、Intune Plan 2などが追加対象だが、EPMはE5側の追加対象として整理されている |
| アドオン利用 | E5/E7以外では、Intune Plan 1を前提に個別アドオンまたはIntune Suiteを検討する |
影響範囲：誰が確認すべきか
EPMの影響を受けるのは、主にWindows端末をMicrosoft Intuneで管理している組織です。特に、ローカル管理者権限をユーザーに付与している部門、開発者・情シス・現場端末・検査端末・共有PCを持つ企業では、EPMの導入効果が大きくなります。
対象になりやすいのは、次のような環境です。
| 環境 | 確認すべき理由 |
|---|---|
| Microsoft 365 E5を利用中 | 2026年7月以降、EPMを含む高度なIntune機能の利用可能性を確認する価値がある |
| Intune Suiteを個別契約中 | Microsoft 365 E5との重複や更新時の契約整理を確認する |
| ユーザーがローカル管理者のまま | EPMで標準ユーザー化できる業務を洗い出す |
| ヘルプデスクが昇格依頼に追われている | サポート承認や事前ルール化で問い合わせ削減を検討できる |
| 監査・ゼロトラストを強化したい | 管理された昇格、管理外の昇格、アプリ別・ユーザー別のレポートを活用できる |
注意したいのは、ライセンスに含まれるようになったからといって、自動的にユーザー権限が変わるわけではない点です。EPMを有効化し、昇格設定ポリシーと昇格ルールポリシーを作成・割り当てて初めて、端末上で制御が始まります。EPMクライアントは、昇格設定ポリシーがユーザーまたはデバイスに割り当てられたときに導入され、Microsoft EPM Agent Service と C:\Program Files\Microsoft EPM Agent 配下のコンポーネントを使います。(Microsoft Learn)
移行期限はあるのか
EPMの概要ドキュメント上、既存環境に対して「この日までに移行しなければならない」という強制的な移行期限は示されていません。管理者が期限として見るべきなのは、主に次の3つです。
| 期限・時期 | 管理者が見るべき内容 |
|---|---|
| 2026年7月1日 | Microsoft 365の価格・パッケージ変更の有効日。EPMの利用可否や契約影響を確認する |
| 2026年8月1日まで | Microsoftが関連機能のロールアウト完了目安として示している時期。テナントでの反映状況を確認する |
| 契約更新日 | 既存顧客の価格・契約影響は更新時期に左右されるため、更新前にEPMやIntune Suiteの重複を整理する |
もう一つ見落としやすい期限が、Windows 10のサポートです。EPMの計画ドキュメントではWindows 10も許可されたバージョンとして記載されていますが、Windows 10は2025年10月14日にサポート終了となり、機能保証や更新の観点では注意が必要と説明されています。EPMを本格展開するなら、Windows 11への移行計画とセットで考えるのが現実的です。(Microsoft Learn)
EPMの前提条件を確認する
EPMを導入する前に、まず対象デバイスが条件を満たしているか確認します。サポート対象として、Windows 11 version 24H2、Windows 11 version 23H2、22H2、21H2の指定ビルド以降、Windows 10 version 22H2および21H2の指定ビルド以降が記載されています。また、64ビットOSアーキテクチャのみが対象で、Arm64も含まれます。(Microsoft Learn)
デバイス構成としては、Microsoft Entra joined または Microsoft Entra hybrid joined であること、Intuneに登録されていること、またはMicrosoft Configuration Managerとの共同管理状態であることが必要です。EPMに必要なエンドポイントへ、SSLインスペクションなしで通信できることも確認対象です。(Microsoft Learn)
導入前チェックリスト
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft 365 E5/E7、Intune Suite、個別アドオンなど、EPMの利用権があるか |
| OS | Windows 11の対象バージョン・ビルドか。Windows 10端末はサポート終了後の運用リスクも見る |
| 参加状態 | Microsoft Entra joined または hybrid joined か |
| 管理状態 | Intune登録済み、またはConfiguration Manager共同管理の対象か |
| 通信 | EPMに必要なクラウドエンドポイントへ到達できるか |
| 管理権限 | EPMポリシー作成、レポート閲覧、承認処理に必要なRBAC権限があるか |
| 運用設計 | 誰が承認し、どのアプリを許可し、どのログを監査するか決まっているか |
EPMで使う2種類のポリシー
EPMの設定は、大きく「昇格設定ポリシー」と「昇格ルールポリシー」に分かれます。昇格設定ポリシーはEPMクライアントの有効化、既定の昇格応答、レポート送信範囲を管理します。昇格ルールポリシーは、特定の実行ファイルやスクリプトをどの条件で昇格させるかを定義します。(Microsoft Learn)
| ポリシー | 主な役割 | 例 |
|---|---|---|
| 昇格設定ポリシー | EPMの有効化、既定の応答、レポート範囲を決める | 未定義ファイルは拒否、またはサポート承認にする |
| 昇格ルールポリシー | どのファイルをどの条件で昇格するか決める | 特定の.msiだけユーザー確認で昇格、PowerShellスクリプトは拒否 |
| 再利用可能な設定グループ | 証明書などを複数ルールで再利用する | ベンダー証明書を複数ポリシーで参照する |
実務では、最初から細かい昇格ルールを作り込むより、まず昇格設定ポリシーで監査・レポートを有効化し、どのアプリが実際に管理者権限を必要としているかを把握する流れが安全です。
昇格タイプの選び方
EPMでは、ファイルの昇格方法を複数のタイプから選べます。重要なのは、便利さだけで選ばないことです。特に自動昇格はユーザー操作なしで昇格するため、業務上不可欠で、信頼できるファイルに限定して使うべきです。Microsoft Learnでも、自動昇格は慎重に、信頼済みかつ業務上重要なファイルに限って使うことが推奨されています。(Microsoft Learn)
| 昇格タイプ | 向いている用途 | 注意点 |
|---|---|---|
| Deny | 昇格させたくないファイルを明示的にブロックする | 競合時もDenyが優先されるため、誤設定に注意する |
| Support approved | 未知のアプリ、例外的な昇格、リスク確認が必要な作業 | 承認者の運用体制が必要。承認後は一定期間ユーザーが昇格可能になる |
| User confirmed | 低〜中リスクの社内ツール、業務上よく使う管理操作 | 認証や業務理由の入力を組み合わせて監査性を高める |
| Automatic | 信頼済みで頻繁に使う業務必須ファイル | 広い条件で設定するとリスクが大きい。原則として最小限にする |
| Elevate as current user | 仮想アカウント昇格では動作しないアプリ | ユーザーのコンテキストを引き継ぐため、攻撃面が広がる。互換性問題がある場合に限定する |
通常は、既定の応答を「Deny」または「Support approved」に寄せ、明確に許可したいものだけルールで昇格する設計が安全です。昇格設定ポリシーの既定応答を「Require user confirmation」にすると、ルールに一致しないファイルもユーザー確認だけで昇格できるため、Microsoft Learnでは注意喚起されています。(Microsoft Learn)
ルール作成で失敗しやすいポイント
EPMのルール作成で最も危険なのは、「ファイル名が一致すれば許可」のような弱い条件にすることです。ファイル名は変更されやすく、信頼済み証明書とファイル名だけで判定すると、意図しないファイルが昇格対象になる可能性があります。Microsoft Learnでは、ファイルハッシュが最も強いルールであり、証明書ルールも製品名・内部名・説明などの属性と組み合わせることが推奨されています。(Microsoft Learn)
ルールでは、.exe、.msi、.ps1 が対象になります。昇格ルールポリシーは、Microsoft Intune admin centerから1ポリシーあたり最大100ルールまで追加できます。(Microsoft Learn)
安全なルール設計の基準
| ルール要素 | 推奨度 | 理由 |
|---|---|---|
| ファイルハッシュ | 高 | 対象ファイルを強く識別できる |
| 署名証明書＋製品名などの属性 | 高 | ベンダー署名を使いつつ、対象を絞り込める |
| ファイルパス | 高 | 標準ユーザーが書き換えられない場所に限定しやすい |
| ファイル名のみ | 低 | リネームで誤検知・誤昇格が起きやすい |
| ワイルドカード多用 | 低 | 想定外のファイルまで対象に入りやすい |
| 子プロセスの無制限昇格 | 低 | スクリプトエンジンやコマンドシェル経由で権限が広がりやすい |
特にPowerShell、ブラウザ、コマンドシェル、インストーラーは慎重に扱うべきです。子プロセス制御を誤ると、親プロセスの昇格に引きずられて別のプロセスまで高権限で動く可能性があります。EPMでは子プロセスに独自ルールを求める、すべて非昇格で起動する、親の昇格を引き継がせる、といった制御が可能ですが、最小権限の原則に沿って設計する必要があります。(Microsoft Learn)
サポート承認を使うべき場面
Support approved は、ユーザーが「Run with elevated access」から昇格要求を送り、Intune管理者が内容を確認して承認または拒否する方式です。未知のアプリや、頻度は低いが業務上必要になる作業に向いています。申請にはユーザー名、デバイス、ファイル名、業務理由などが含まれ、管理者はIntune管理センターで確認できます。(Microsoft Learn)
承認後、ユーザーは承認されたファイルを24時間、昇格して実行できます。現在の説明では、この24時間をカスタムしたり、期限前に承認を取り消したりするサポートは示されていません。また、拒否時はIntuneからユーザーに通知されないため、運用上はヘルプデスク側で連絡ルールを決めておく必要があります。(Microsoft Learn)
サポート承認の運用ルール例
| 項目 | 推奨ルール |
|---|---|
| 承認者 | Endpoint Privilege Management Elevation Requests の表示・変更権限を持つ管理者に限定する |
| 承認基準 | 発行元、ファイルハッシュ、配布元、業務理由、端末の準拠状態を確認する |
| 応答時間 | 業務影響の大きい部門は優先度を決める |
| 拒否時の連絡 | Intuneから自動通知されない前提で、Teams・チケット・メールなどの連絡方法を決める |
| ルール化判断 | 同じ申請が繰り返される場合は、個別承認ではなく昇格ルール化を検討する |
Microsoft Security Copilotのライセンスがある場合、承認画面から「Analyze with Copilot」を使い、Defender Threat Intelligenceなどの情報をもとにファイル評価を支援できます。ただし、最終判断は管理者の承認プロセスに組み込むべきで、Copilotの結果だけで自動承認する運用は避けた方が安全です。(Microsoft Learn)
レポートで見るべき項目
EPMの展開では、レポートを使って「実際に何が昇格されているか」を確認することが重要です。EPMレポートでは、EPMが処理した管理された昇格だけでなく、ローカル管理者がWindows標準の「管理者として実行」を使ったような管理外の昇格も確認できます。レポートデータは30日間保持され、利用状況レポートの反映には最大で一定の遅延があり、データは24時間ごとに処理されると説明されています。(Microsoft Learn)
レポート閲覧には、Endpoint Privilege Management Policy Authoring の View Reports 権限が必要です。以前は Device configurations の Read 権限でアクセスできた情報も、現在は明示的な View Reports 権限が必要と説明されています。(Microsoft Learn)
管理者が確認すべきレポート
| レポート | 見るべきポイント | 次のアクション |
|---|---|---|
| Elevation report | どのファイルが、誰の端末で、いつ昇格されたか | ルール化、拒否、サポート承認への振り分け |
| Managed elevations report | EPMルールで管理できている昇格 | 期待通りのルール適用か確認する |
| Application別レポート | 昇格頻度が高いアプリ | 業務必須アプリか、リスクの高いアプリか分類する |
| Publisher別レポート | 発行元ごとの昇格傾向 | 信頼済みベンダーの範囲を見直す |
| User別レポート | ユーザー単位の昇格傾向 | ローカル管理者から標準ユーザーへ移行できる候補を探す |
おすすめの導入手順
EPM導入で最も避けたいのは、いきなりローカル管理者権限を削除して業務を止めることです。Microsoft Learnの展開ガイドでも、監査、ペルソナ識別、ルール作成、監視、ユーザー権限レビューという段階的な流れが示されています。(Microsoft Learn)
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| ライセンス確認 | Microsoft 365 E5/E7、Intune Suite、個別アドオンの状態を確認する | 利用可能な対象ユーザー一覧 |
| 対象端末の棚卸し | OS、Entra参加状態、Intune登録状態、Windows 10端末を確認する | EPM展開対象リスト |
| 監査ポリシー作成 | 昇格設定ポリシーでEPMとレポート収集を有効化する | 昇格利用状況の可視化 |
| ペルソナ分類 | 一般ユーザー、開発者、情シス、現場端末などに分ける | ルール設計単位 |
| ルール作成 | レポートや申請内容から必要な昇格ルールを作る | 昇格ルールポリシー |
| パイロット展開 | 限定グループに割り当て、業務影響を確認する | 例外・不具合リスト |
| 標準ユーザー化 | Local Users and Groupsなどでローカル管理者権限を整理する | 管理者権限削減 |
| 継続監視 | レポートを見ながらルールを更新する | 監査・改善サイクル |
EPMは、Local Users and Groupsの管理と組み合わせることで、ローカル管理者から標準ユーザーへの移行を進めやすくなります。Microsoft Learnでは、EPMでアプリ昇格を制御し、Local Users and Groupsでローカル管理者グループを管理する流れが示されています。(Microsoft Learn)
よくある誤解と注意点
EPMを有効にすれば自動的に安全になるわけではない
EPMは、設定すれば終わりの機能ではありません。既定の昇格応答を広く許可しすぎたり、自動昇格を多用したりすると、ローカル管理者権限を減らしても別のリスクが残ります。
最初の方針としては、未定義ファイルは「Deny」または「Support approved」にし、業務で必要なものだけを強い検出条件で許可するのが安全です。
証明書ルールだけに頼りすぎない
証明書は強い識別要素ですが、ベンダーが多数のアプリに同じ証明書を使っている場合、想定より広い範囲を許可する可能性があります。計画ドキュメントでも、証明書ルールが同じ証明書で署名された任意のアプリを許可し得る点に注意するよう示されています。(Microsoft Learn)
証明書を使う場合は、製品名、内部名、ファイルパス、バージョン、ファイルハッシュなどを組み合わせて、対象を狭く定義します。
「Elevate as current user」は互換性対策として使う
Elevate as current user は、サインイン中のユーザー自身のコンテキストで昇格するため、ユーザープロファイル、環境変数、個別設定に依存するアプリでは役立ちます。しかし、通常の仮想アカウント昇格より分離性が下がり、ユーザーデータへの露出も増えます。Microsoft Learnでも、互換性が問題でない場合は仮想アカウントを使う方式が推奨されています。(Microsoft Learn)
ルール競合時の優先順位を理解する
複数のルールが同じアプリに適用されると、Denyが常に優先されます。そのうえで、ユーザーに割り当てられたルールはデバイスに割り当てられたルールより優先され、ハッシュ定義があるルールはより具体的なルールとして扱われます。競合を前提に、ルール名、対象グループ、スコープタグ、変更履歴を整理しておくことが重要です。(Microsoft Learn)
グローバル展開で確認したいポイント
グローバル企業では、国・地域、クラウド環境、契約形態、端末標準が異なります。EPMはPublic cloudに加え、GCC HighやDoDなどのソブリンクラウド環境にも関する記載がありますが、機能の反映時期や利用条件はテナントやクラウドによって異なる可能性があります。(Microsoft Learn)
特に以下は、海外拠点を含めて統一的に確認したい項目です。
| 項目 | 確認ポイント |
|---|---|
| ライセンス | 国・契約種別ごとのMicrosoft 365 E5/E7、Intune Suite、個別アドオンの扱い |
| OS標準 | Windows 10が残っていないか。Windows 11移行とセットで進められるか |
| 承認体制 | タイムゾーンをまたいでSupport approvedの承認が滞らないか |
| 監査要件 | 各国の監査・ログ保持・プライバシー要件に合うか |
| ヘルプデスク | 拒否時通知、業務理由、承認SLA、例外対応の言語対応 |
| アプリ配布 | 国別アプリ、現地ベンダーアプリ、工場・店舗端末の例外を洗い出せているか |
管理者が今すぐ確認すべきこと
今回の更新を受けて、Microsoft Intune管理者はまずライセンスとテナント反映状況を確認し、そのうえでEPMの小規模な監査展開を始めるのが現実的です。いきなり権限を削除するのではなく、「どのユーザーが、どのアプリを、どの頻度で昇格しているか」を見える化し、リスクの低いものからルール化します。
最初のアクションは、次の順番で進めると失敗しにくくなります。
| 優先度 | アクション |
|---|---|
| 高 | Microsoft 365管理センターとIntune管理センターで、EPMのライセンス利用可否を確認する |
| 高 | Message Centerで、自社テナントへのロールアウト通知を確認する |
| 高 | Windows 10端末、非対応ビルド、未登録端末を洗い出す |
| 高 | 昇格設定ポリシーを監査目的で限定展開する |
| 中 | レポートを見て、よく使われる昇格アプリを分類する |
| 中 | 未知のアプリはSupport approved、明確に不要なものはDenyにする |
| 中 | ハッシュ、証明書、ファイルパス、引数、子プロセス制御を組み合わせてルールを作る |
| 低 | ローカル管理者権限の削除は、部門別・段階的に進める |
Microsoft Intune Endpoint Privilege Managementは、ローカル管理者権限を一気に奪うための機能ではなく、標準ユーザー化を安全に進めるための運用基盤です。2026年7月1日以降のパッケージ変更により、特にMicrosoft 365 E5を利用する組織では、EPMをセキュリティ強化・監査強化・ヘルプデスク負荷削減の具体策として検討しやすくなりました。まずはライセンス、対象端末、レポート収集、承認運用を確認し、小さなパイロットから始めることが最も確実です。
コメント