Microsoft Edgeの拡張機能を組織で管理している場合、2026年5月の「Microsoft Edge: Extensions monitoring in the Edge management service」は早めに確認すべき更新です。結論から言うと、管理者はMicrosoft Edge管理サービス上で、管理対象ユーザーにインストールされている拡張機能を把握し、ブロックされた拡張機能に対するユーザー申請も扱いやすくなります。単に「見えるようになる」だけではなく、拡張機能の棚卸し、許可・ブロック判断、ヘルプデスク対応、セキュリティレビューの運用を見直すきっかけになる機能です。
公式ロードマップでは、Roadmap ID 552597として「Microsoft Edge: Extensions monitoring in the Edge management service」が登録され、Previewは2026年2月、General Availabilityは2026年5月、対象はMicrosoft Edge、プラットフォームはWeb、クラウドはWorldwide Standard Multi-Tenantとされています。更新時刻はUTCで2026年5月8日22:15のため、日本時間では2026年5月9日付の更新として確認できます。(microsoft.com)
Microsoft EdgeのExtensions monitoringで何が変わるのか
今回の変更の中心は、Microsoft Edge management serviceにおける「拡張機能の可視化」です。Microsoftの説明では、管理者が管理対象ユーザー全体でインストールされている拡張機能を確認でき、Extensions monitoringページからインストール済み拡張機能の把握と、ブロック済み拡張機能に対するユーザーリクエストの管理ができるようになります。(microsoft.com)
これまで拡張機能管理は、許可リスト、ブロックリスト、強制インストール、ExtensionSettingsポリシーなどを設定する作業が中心でした。新しいExtensions monitoringは、実際にどの拡張機能が使われているかを見ながら、設定の見直しや申請対応につなげやすくする位置づけです。
| 観点 | これまで起こりやすかった課題 | Extensions monitoringで期待できること |
|---|---|---|
| 利用実態の把握 | 各端末や問い合わせベースで確認しがち | 管理対象ブラウザー全体の拡張機能利用を集約して確認しやすい |
| ブロック済み拡張機能への対応 | ユーザーから個別に問い合わせが来る | 申請された拡張機能を管理画面上で確認しやすい |
| 許可・ブロック判断 | 事前に作ったリストが放置されやすい | 実際の利用状況を見ながらポリシーを調整しやすい |
| セキュリティレビュー | 権限やアクセス先の確認が属人的になりやすい | 利用頻度や申請状況を踏まえて優先順位を付けやすい |
重要なのは、この機能が「すべての拡張機能を自動的に安全判定する機能」ではない点です。最終的に許可するか、ブロックするか、強制インストールするかは、管理者が業務要件とリスクを見て判断する必要があります。
対象者と影響範囲
Extensions monitoringの主な対象は、Microsoft Edge for Businessを組織で管理しているIT管理者、セキュリティ担当者、情報システム部門、ヘルプデスク担当者です。拡張機能を提供する社内開発者やSaaSベンダー側にも影響があります。企業管理下で使われる拡張機能は、権限、更新元、アクセス対象サイト、データの取り扱いを説明できないと、承認されにくくなる可能性があるためです。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Edge管理者 | Extensions monitoringを有効化する条件、既存ポリシーとの競合、対象ユーザー範囲 |
| セキュリティ担当者 | 高権限の拡張機能、全サイトアクセス、閲覧履歴・Cookie・ダウンロード権限の扱い |
| ヘルプデスク | ブロック時の案内文、申請フロー、承認までの目安、代替手段 |
| 社内開発者 | 社内業務で必要な拡張機能のID、必要権限、対象ドメイン、更新方法 |
| エンドユーザー | 勝手に許可されるわけではなく、ブロックされた拡張機能は申請が必要になる場合があること |
Microsoft Edge management service自体はMicrosoft 365管理センター上の機能で、Edgeブラウザー設定をクラウドに保存し、グループ割り当てやグループポリシーを通じてユーザーのブラウザーに適用できます。ただし、ユーザーがMicrosoft Edgeにサインインしている必要があります。(Microsoft Learn)
利用前に確認すべき前提条件
導入前に特に確認したいのは、対象デバイス、管理権限、データ収集の設定、既存ポリシーとの関係です。
Microsoft Edge management serviceの前提条件として、Microsoft Edge 115.0.1901.7以降、Microsoft 365管理センターでのMicrosoft Edge Administrator権限、対応OSの利用が挙げられています。また、MicrosoftはGCCプランの顧客にはMicrosoft Edge management serviceが現在利用できないと説明しています。(Microsoft Learn)
Extensions monitoringについては、現時点で拡張機能データはWindowsデバイスのみ利用可能とされています。macOSやモバイル端末でもEdge管理サービスの対象になる場面はありますが、拡張機能監視データの確認範囲を「全デバイス」と誤解しないよう注意が必要です。(Microsoft Learn)
有効化で確認すべき設定
Extensions monitoringは、Microsoft Edge management service上のオプトイン機能です。拡張機能インベントリを表示するには、まず「Enable monitoring dashboard」を有効にし、その後「Extensions monitoring」を有効にします。この操作により、テナント内の構成ポリシーでCloudProfileReportingEnabled設定が構成されると説明されています。(Microsoft Learn)
有効化後は、管理対象ブラウザーからインストール済み拡張機能やブロック済み拡張機能へのユーザー申請に関するデータが収集され、Extensions monitoringページに表示されます。ただし、データはブラウザーを管理しているテナントと一致するIDのユーザープロファイルからのみ受信され、同じユーザーが複数デバイスにサインインしている場合は、最後にサインインしたデバイスからのみレポートされると説明されています。(Microsoft Learn)
この仕様は実務上かなり重要です。例えば「営業部のユーザーがノートPCとVDIの両方でEdgeを使っている」場合、すべての端末の拡張機能利用が完全に並列で見えるとは限りません。監視結果を監査証跡として過信せず、Intune、GPO、端末管理ツール、EDRなどの情報と合わせて判断するのが安全です。
管理者が最初に行うべき確認手順
Extensions monitoringを有効化したら、すぐに許可・ブロックを大量変更するのではなく、まず現状把握から始めるべきです。拡張機能はユーザーの業務効率に直結する一方、閲覧履歴、Cookie、ページ内容、ダウンロード、外部通信などに関わる可能性があるため、急なブロックは業務停止につながります。
| 手順 | 作業内容 | 判断ポイント |
|---|---|---|
| 事前確認 | 既存のEdge管理方法を確認する | GPO、Intune、Edge management serviceのどれで制御しているか |
| 有効化 | Monitoring dashboardとExtensions monitoringを有効化する | 診断データ設定、対象ユーザー、対象デバイスを確認 |
| 棚卸し | インストール済み拡張機能を一覧化する | 部門別、利用者数、業務必須度で分類 |
| リスク評価 | 権限とアクセス先を確認する | 全サイトアクセス、履歴、Cookie、ダウンロード権限は優先確認 |
| ポリシー反映 | Allow、Block、Force、Normalを設定する | 業務必須か、代替手段があるか、許容できるリスクか |
| 申請運用 | ブロック済み拡張機能のリクエスト対応を整える | 承認基準、通知先、対応期限、却下理由を明文化 |
| 段階展開 | パイロット部門から展開する | 問い合わせ量、業務影響、誤ブロックを確認 |
Microsoftのベストプラクティスでは、拡張機能を個別名だけで管理するのではなく、要求する権限やアクセスできるWebサイトに基づいて管理する方法が推奨されています。特に大規模組織では、権限ベースと実行時のホスト制御を組み合わせるほうが、単純な許可リスト・ブロックリストより運用しやすいとされています。(Microsoft Learn)
許可・ブロックを判断する基準
拡張機能の判断では、「有名な拡張機能だから許可」「利用者が多いから許可」といった判断は避けるべきです。業務上の必要性と、拡張機能が要求する権限のバランスを見ます。
許可しやすい拡張機能の例
業務上必要で、権限が用途に対して過剰でなく、提供元や更新元が明確なものは許可候補になります。
例えば、社内で標準利用しているパスワードマネージャー、電子署名、Web会議補助、開発者向けツールなどは、部門や業務によって必須になる場合があります。ただし、パスワードマネージャーのように機密情報へ関わる拡張機能は、提供元、認証方式、管理コンソール、監査ログ、緊急停止手段まで確認してから許可するべきです。
慎重に扱うべき拡張機能の例
以下のような拡張機能は、利用者が便利だと感じても、組織利用では慎重に評価する必要があります。
| 種類 | 注意点 |
|---|---|
| AI要約・翻訳系 | ページ内容や入力データを外部サービスに送る可能性がある |
| 画面キャプチャ系 | 機密画面や個人情報を含む画面の取り扱いに注意が必要 |
| PDF・フォーム補助系 | ファイル、入力内容、ダウンロードへのアクセス権限を確認する |
| クーポン・価格比較系 | 業務利用との関連が薄く、閲覧データ収集の懸念がある |
| 開発者ツール系 | 開発部門には必要でも、一般部門に広く許可する必要はない場合がある |
Microsoftのドキュメントでも、拡張機能はWebページやデバイスに変更を加えるための権限を要求する場合があり、ホスト権限とデバイス権限の両方を確認すべきとされています。(Microsoft Learn)
ユーザー申請をどう運用するか
今回の更新で特に実務効果が大きいのは、ブロックされた拡張機能に対するユーザー申請を管理しやすくなる点です。Microsoft Edge management serviceでは、ブロック済み拡張機能についてユーザーからのリクエストを許可でき、Requestsタブでリクエスト機能を有効化すると、ユーザーが申請した拡張機能を確認できます。メール通知も設定でき、通知頻度は日次、週次、月次から選べます。(Microsoft Learn)
申請運用では、次の4点を事前に決めておくと混乱を防げます。
| 決めること | 具体例 |
|---|---|
| 申請時に必要な情報 | 拡張機能名、拡張機能ID、利用目的、対象業務、利用部門 |
| 承認基準 | 業務必須、権限が妥当、提供元が信頼できる、代替手段がない |
| 却下時の案内 | 却下理由、代替ツール、再申請に必要な条件 |
| 対応期限 | 通常申請は5営業日以内、緊急申請は部門長承認が必要など |
注意したいのは、「Mark as resolved」は申請を処理済みに移す操作であり、必ずしも拡張機能を許可する操作そのものではない点です。許可、ブロック、強制インストール、通常インストールといったインストールポリシーは、対象拡張機能の設定で明確に変更する必要があります。(Microsoft Learn)
既存ポリシーとの競合に注意する
Extensions monitoringを導入するときに見落としやすいのが、既存のGPO、MDM、Intuneポリシーとの関係です。Microsoft Edge management serviceで作成した構成ポリシーはMicrosoft Entraグループに割り当てられ、複数ポリシーが競合する場合は優先度で適用内容が決まります。ただし、Intune構成ポリシーには同じ優先度の仕組みがなく、競合設定は自動解決されないと説明されています。(Microsoft Learn)
さらに、デバイス側で既存のGPOまたはMDMポリシーが設定されている場合、Microsoft Edge management serviceで適用したポリシーよりも、既存のGPOやMDMポリシーが優先されるケースがあります。(Microsoft Learn)
つまり、管理画面で「許可」にしたのにユーザー側ではブロックされる、あるいは「ブロック」したはずなのに既存ポリシーの影響で想定どおりにならない、といったトラブルが起こり得ます。展開前に、少なくとも次の設定元を確認しておきましょう。
| 確認対象 | 確認内容 |
|---|---|
| GPO | ExtensionInstallBlocklist、ExtensionInstallAllowlist、ExtensionInstallForcelist、ExtensionSettings |
| Intune | Edgeの設定カタログ、構成プロファイル、割り当て対象、除外グループ |
| Edge management service | Cloud policyかIntune policyか、ポリシー優先度、割り当てグループ |
| 端末状態 | Edgeのバージョン、サインイン状態、再起動の有無 |
| ユーザー属性 | Entraグループ、複数ポリシー割り当て、部門別例外 |
Cloud policyとIntune policyの使い分け
Microsoft Edge management serviceでは、Cloud policyとIntune policyの扱いに違いがあります。Cloud policyでは、競合時の優先度設定、拡張機能リクエスト、組織ブランディングなどが利用できると説明されています。一方、Intune policyはEdge management serviceとIntuneポータルの両方で管理できますが、スコープタグ、詳細な割り当て、Intune側のRBACなどで制限があります。(Microsoft Learn)
拡張機能リクエストを本格的に運用したい場合は、現在の管理設計がCloud policy中心なのか、Intune中心なのかを確認してください。特に大企業では、すでにIntuneの構成プロファイルやGPOで細かくEdge設定を管理していることが多いため、Edge management service側だけを見て判断すると、実際の端末挙動とずれる可能性があります。
移行・展開時の注意点
既存の拡張機能管理をEdge management serviceへ整理する場合、いきなり本番全体へ適用するのは避けましょう。Microsoftのドキュメントでは、拡張機能設定をJSONとしてインポート・エクスポートでき、エクスポートしたJSONをExtensionSettingsグループポリシーの値として使えることも説明されています。既存設定の棚卸しやバックアップに活用できます。(Microsoft Learn)
展開では、次の順序が現実的です。
| フェーズ | やること | 失敗しやすいポイント |
|---|---|---|
| 調査 | 現在の拡張機能ポリシーを一覧化 | GPOとIntuneの重複を見落とす |
| パイロット | 情シス、セキュリティ、代表部門でテスト | 例外部門の業務ツールを把握していない |
| 分類 | 必須、許可候補、要審査、禁止に分ける | 利用者数だけで判断する |
| 通知 | ブロック時のメッセージと申請方法を案内 | ユーザーが問い合わせ先を知らない |
| 本番展開 | 部門単位で段階的に適用 | 全社一括で業務停止が起こる |
| 見直し | 月次または四半期で申請と利用状況を確認 | 一度作った許可リストを放置する |
また、Edge management serviceのポリシーは即時反映とは限りません。Microsoftの説明では、構成ポリシーが作成・適用されるとEdgeがCloud Policyを定期的に確認し、変更がある場合はポリシー設定が適用されます。変更確認には90分周期や24時間周期が関係し、ポリシーによってはEdgeの再起動後に適用されます。(Microsoft Learn)
開発者・ベンダーが確認すべきこと
拡張機能を提供する開発者やSaaSベンダーは、企業管理者から見た「承認しやすさ」を意識する必要があります。Extensions monitoringによって、管理者は利用実態を見ながら不要・高リスクな拡張機能を整理しやすくなります。社内で使ってもらいたい拡張機能ほど、次の情報を明確にしておくべきです。
| 確認項目 | なぜ重要か |
|---|---|
| 拡張機能ID | 管理者が許可・ブロック・強制インストールを設定する際に必要 |
| 必要な権限 | 過剰な権限は承認を妨げる |
| アクセス対象ドメイン | 社内システムや機密サイトへの影響を判断するため |
| データ送信先 | 個人情報・機密情報の取り扱い確認に必要 |
| 更新URL・配布元 | サプライチェーンリスクや更新管理の確認に必要 |
| 最小対応バージョン | 古いバージョンの脆弱性や不具合を避けるため |
| 管理者向けドキュメント | ヘルプデスクとセキュリティレビューの負荷を下げる |
Microsoft EdgeのExtensionSettingsポリシーでは、拡張機能IDや更新URLに対して設定を割り当てられ、既定設定には特殊IDの*を使えます。また、ExtensionSettingsは従来の拡張機能関連ポリシーより優先される説明があり、サードパーティストア由来の拡張機能を更新URL単位でブロックする設定例も示されています。(Microsoft Learn)
社内拡張機能を開発している場合は、不要な権限を削ることが最も効果的です。「全サイトのデータ読み取り」が必要に見えても、実際には特定の社内ドメインだけで済むケースがあります。権限を限定できれば、管理者が許可しやすくなり、ユーザーへの説明もしやすくなります。
よくある誤解と注意点
監視を有効にすると自動的に危険な拡張機能がブロックされるのか
自動的にすべてを安全判定してブロックする機能ではありません。Extensions monitoringは、拡張機能の利用状況や申請状況を可視化し、管理者が判断しやすくする機能です。実際の許可、ブロック、強制インストールなどは、管理者が拡張機能ポリシーとして設定します。
Windows以外のデバイスも同じように見えるのか
公式ドキュメントでは、Extensions monitoringの拡張機能データは現在Windowsデバイスのみ利用可能とされています。Macやモバイルを含む組織では、監視画面だけで全体の利用実態を判断しないようにしましょう。(Microsoft Learn)
GCC環境でも利用できるのか
公式ドキュメントでは、Microsoft Edge management serviceは現在GCCプランの顧客には利用できないと記載されています。また、今回のロードマップ項目のクラウドインスタンスはWorldwide Standard Multi-Tenantです。政府機関向けクラウドや特殊環境では、管理センター上の実表示とMicrosoftのメッセージセンターを確認してください。(Microsoft Learn)
ロードマップの日付は確定なのか
Microsoft 365 Roadmapは商用機能の予定日と説明を提供するものですが、Microsoftはロードマップ上の情報は変更される可能性があると明記しています。したがって、GAが2026年5月と記載されていても、実際のテナント反映タイミング、UI表示、利用条件は管理センターやメッセージセンターで確認する必要があります。(microsoft.com)
管理者が今すぐやるべきこと
まず、Microsoft Edgeの拡張機能を「禁止するか許可するか」だけで考えるのをやめ、利用実態、業務必要性、要求権限、アクセス先、申請状況をセットで管理する方針に切り替えましょう。
最初にやるべきことは、既存のGPO、Intune、Edge management serviceの設定を棚卸しし、どのポリシーが最終的に端末へ効いているかを確認することです。そのうえで、Extensions monitoringをパイロット環境で有効化し、インストール済み拡張機能とユーザー申請を確認します。
特に、全サイトアクセス、閲覧履歴、Cookie、ダウンロード、外部通信に関わる拡張機能は優先的にレビューしてください。業務に必要な拡張機能は、拡張機能ID、必要権限、対象部門、許可理由を明文化し、不要またはリスクが高いものはブロック理由と代替手段を用意します。
Extensions monitoringは、Edge拡張機能管理を「設定して終わり」から「利用状況を見て継続的に改善する」運用へ変える機能です。2026年5月のGAに向けて、管理者は監視の有効化だけでなく、申請フロー、承認基準、既存ポリシーとの整合性までまとめて見直すことが重要です。
コメント