Microsoft は 2026年4月10日付の Microsoft Edge Stable Channel リリースノートで、Microsoft Edge 管理サービスに「拡張機能の監視」を追加したと案内しました。これはパブリック プレビュー機能で、管理者は管理対象ユーザーにインストールされている拡張機能を可視化し、ブロックされた拡張機能のリクエストも確認できます。結論から言うと、今回の更新は Edge 拡張機能の「何が入っているか分からない」「利用申請が場当たり的になる」という運用を、管理画面ベースで立て直しやすくする機能追加です。 (マイクロソフト ラーン)
ただし、すぐに全環境でそのまま使える一般提供機能ではありません。現時点では Targeted release への参加が必要で、拡張機能データは Windows デバイスでのみ利用でき、既存の GPO や MDM 設定と競合すると Edge 管理サービス側の設定が優先されない点も押さえておく必要があります。記事後半では、このあたりの実務上の注意点まで含めて整理します。 (マイクロソフト ラーン)
2026年4月10日の更新で何が変わったか
今回の更新で、Microsoft Edge 管理サービスに追加された実務上の変化は大きく3つあります。
- 管理対象ユーザーにインストールされている拡張機能を、拡張機能の監視ページから把握できるようになりました。 (マイクロソフト ラーン)
- ブロックされた拡張機能について、ユーザーからのリクエストを確認し、構成ポリシー側で対応しやすくなりました。 (マイクロソフト ラーン)
- この機能はパブリック プレビューで、Microsoft 365 管理センターの Targeted release へオプトインすることで利用できます。 (マイクロソフト ラーン)
ニュースとして読むなら「拡張機能の監視が追加された」で終わりですが、管理者目線では「拡張機能の棚卸し」と「申請対応」が同じ運用線上に乗ったことが重要です。これにより、許可・保留・却下の判断を、実際の利用状況を見ながら進めやすくなります。 (マイクロソフト ラーン)
なぜこの機能が重要なのか
Microsoft は、拡張機能は可視性や監督なしに導入されると、セキュリティ、プライバシー、コンプライアンス上のリスクを持ち込みやすいと説明しています。今回の拡張機能監視は、管理対象ブラウザーで動作している拡張機能の集約情報を提供し、どの拡張機能が広く使われているか、どこでブロックが発生しているか、どこにリスクの芽があるかを中央で見えるようにする仕組みです。 (マイクロソフト ラーン)
現場で特に効くのは、次のような場面です。
- 情シスとしては全面禁止にしたくないが、何が使われているか把握できていない。
- ブロックされた拡張機能の問い合わせがメールや Teams に散らばり、承認履歴が残りにくい。
- 監査や内部点検の前に、「誰がどの種類の拡張機能を使っているか」を短時間で棚卸ししたい。
特に Edge 拡張機能は、ブラウザー上で業務を完結させる企業ほど影響が大きいです。便利さだけで採用すると、閲覧ページの読み取り権限やデバイス権限が広すぎる拡張機能まで入り込みやすくなります。今回の監視機能は、その“見えない拡張”を減らすための基盤と考えると分かりやすいです。 (マイクロソフト ラーン)
利用前に押さえておきたい前提
管理画面の場所と必要な権限
Microsoft Edge 管理サービスは Microsoft 365 管理センター内の Settings > Microsoft Edge から利用します。Microsoft のドキュメントでは、この画面に入るには Microsoft Edge Administrator 権限が必要で、管理サービスの前提として Microsoft Edge 115.0.1901.7 以降が案内されています。あわせて、ユーザー側は Microsoft Edge にサインインしていないとクラウド側の設定を受け取れません。 (マイクロソフト ラーン)
もうひとつ見落としやすいのが提供範囲です。Microsoft は、現行ドキュメントで Edge 管理サービスは GCC プランの顧客には提供されていないと案内しています。社内テナントの契約形態によっては、そもそも画面が見えない可能性があります。 (マイクロソフト ラーン)
パブリック プレビュー参加には Targeted release が必要
今回の拡張機能監視は、Stable Channel のリリースノートでも「Targeted release にオプトインすることでアクセスできるパブリック プレビュー」と明記されています。Targeted release は Microsoft 365 の早期リリース設定で、選択ユーザー向けにも全社向けにも設定できます。 (マイクロソフト ラーン)
ただし、Microsoft 365 の Targeted release は一部機能で組織単位の展開になることがあります。Microsoft も、すべての Targeted release 機能を確実に見たい場合は、組織全体の Targeted release か、検証用テナントの利用を勧めています。対象ユーザーだけで設定したのに画面が出ない場合は、この前提を疑うと切り分けが早いです。 (マイクロソフト ラーン)
収集されるデータの範囲
拡張機能監視のデータは、現時点では Windows デバイスのみが対象です。また、データは管理対象テナントと同じ ID テナントを持つユーザープロファイルからのみ受信され、同じユーザーが複数デバイスにサインインしている場合は、最も最近サインインしたデバイスからのレポートのみが対象になります。台数や件数が想像より少なく見えるときは、この仕様が原因になりやすいです。 (マイクロソフト ラーン)
有効化の流れ
実際に使い始めるまでの流れは、次の順番で進めると迷いにくいです。
- Microsoft 365 管理センターで
Settings > Org settings > Organization profile > Release preferencesを開き、Targeted release を有効化します。設定変更にはグローバル管理者権限が必要で、反映には最大 24 時間かかることがあります。 (マイクロソフト ラーン) Settings > Microsoft Edgeから Microsoft Edge 管理サービスに入ります。 (マイクロソフト ラーン)- まず
Enable monitoring dashboardをオンにします。これは、必要な診断データを Microsoft Edge が受け取るための必須ステップです。 (マイクロソフト ラーン) - 続けて
Extensions monitoringをオンにします。この操作で、テナント全体の構成ポリシーにCloudProfileReportingEnabled設定が構成されます。 (マイクロソフト ラーン) - 管理対象ユーザーが Edge にサインインして利用すると、インストール済み拡張機能と、ブロックされた拡張機能のリクエストが監視ページに集約されます。 (マイクロソフト ラーン)
反映待ちで焦りやすいですが、Microsoft の説明では、構成ポリシーはユーザーが初回サインインした際にすぐ確認され、その後は状況に応じて 90 分または 24 時間間隔で再確認されます。さらに、Cloud Policy 由来の設定は Edge の再起動時に適用される挙動が基本です。設定後すぐに見えないときは、ブラウザー再起動まで含めて確認したほうが確実です。 (マイクロソフト ラーン)
ブロックされた拡張機能リクエストは、どう裁くべきか
ここからが実務です。単にリクエストが見えるようになっても、承認基準が曖昧だと運用はすぐ崩れます。Microsoft は拡張機能管理のベストプラクティスとして、拡張機能を個別の許可・禁止だけで捌くのではなく、権限とアクセス先で管理する考え方を勧めています。多くの組織では、この方が安全で、運用もスケールしやすいからです。 (マイクロソフト ラーン)
業務に本当に必要か
最初に見るべきは、便利かどうかではなく、業務上の必須性です。たとえば「議事録要約」「翻訳」「画面キャプチャ」系の拡張機能は要望が出やすい一方で、標準機能や既存の承認済みツールで代替できることも多いです。代替できるなら、新しい拡張機能を増やさない判断のほうが管理コストを抑えられます。
権限が広すぎないか
Microsoft は、拡張機能の権限を大きくホスト権限とデバイス権限に分けて整理しています。閲覧中サイトへの幅広いアクセス、ストレージ、画面表示、ネイティブプログラム連携など、要求権限が広い拡張機能は、企業のデータ保護ポリシーに反する可能性があります。申請が来たら、まず「どの権限を求めるのか」を確認する運用に変えるだけでも事故は減ります。 (マイクロソフト ラーン)
アクセス先を必要最小限にできるか
Microsoft は、拡張機能管理において「権限ベースの制御」と「Runtime block hosts」の組み合わせを推奨しています。つまり、拡張機能そのものを許可するかどうかだけでなく、どのサイトにアクセスさせるかまで絞る発想です。全社で使う拡張機能でも、重要サイトへのアクセス範囲を最小化できるなら、リスクをかなり抑えられます。 (マイクロソフト ラーン)
個別承認で終わらせず、標準化する
同じ拡張機能への申請が何度も来るなら、都度判断より標準化のほうが合理的です。Microsoft Edge では、強制インストール、Allowlist/Blocklist、拡張機能ごとの個別設定などを組み合わせて管理できます。承認した拡張機能を放置せず、「全社標準にするのか」「特定グループ限定にするのか」まで決めて初めて、運用が安定します。 (マイクロソフト ラーン)
実際の画面運用としては、拡張機能監視ページの上部にアクティブな拡張機能リクエストが表示されます。各リクエストを開くと、個別の構成ポリシー内でインストール設定を更新でき、不要になったものは Mark as resolved で解決済みに回せます。まとめて整理したい場合は Delete all requests も使えます。 (マイクロソフト ラーン)
実務で失敗しにくい判断の置き方は、次の3区分です。
- 承認: 業務必須で、要求権限も妥当。代替手段がない。
- 保留: 必要性はあるが、提供元や権限範囲の確認が終わっていない。
- 却下: 権限が過剰、代替手段がある、またはコンプライアンス上の懸念が大きい。
この3区分にするだけでも、申請対応が「感覚」から「基準」へ変わります。
Cloud policy と Intune policy は使い分けたほうがいい
Edge 管理サービスの構成ポリシーは、Cloud policy と Intune policy の両方を扱えます。ただし、機能差は小さくありません。Microsoft のドキュメントでは、拡張機能リクエストの表示と承認・拒否対応、そして競合時の優先度制御は Cloud policy 側で使える機能として整理されています。Intune policy は Edge 管理サービスと Intune の両方から管理できますが、競合時の自動解決はなく、Intune 側の RBAC やデバイス対象指定などが前面に出ます。 (マイクロソフト ラーン)
運用方針としては、次の切り分けが実用的です。
- ブロックされた拡張機能リクエストを Edge 管理サービス内で回したいなら Cloud policy を優先する。 (マイクロソフト ラーン)
- デバイス単位の割り当て、除外グループ、Assignment filters を重視するなら Intune policy を検討する。 (マイクロソフト ラーン)
- グループまたぎで設定がぶつかる環境では、Cloud policy の優先順位を先に設計する。優先度は
0が最優先です。 (マイクロソフト ラーン)
ここで見落としやすいのが、全社適用ポリシーです。Cloud policy 作成時に Add all users を選んでテナント全体ポリシーにすると、その対象は後から変更できません。まずは pilot 用の Microsoft Entra グループに絞って動作確認し、問題がなければ広げる流れのほうが安全です。 (マイクロソフト ラーン)
失敗しやすいポイントと対策
機能が見えない
最初に疑うべきは、Targeted release の設定です。Microsoft 365 側の設定変更は最大 24 時間かかることがあり、選択ユーザー向けの Targeted release では一部機能が早期公開されないこともあります。早く検証したい場合は、検証用テナントか組織全体の Targeted release のほうが確実です。 (マイクロソフト ラーン)
承認したのにブラウザーへ反映されない
Cloud Policy は基本的に Edge 再起動時に適用されます。さらに、ユーザーが Edge にサインインしていないと設定取得自体が行われません。管理サービス側で承認操作をしたあと、ブラウザー再起動とサインイン状態の確認までセットで行うのが確実です。 (マイクロソフト ラーン)
Edge 管理サービスで設定したのに別の値になる
これは GPO や MDM と競合している可能性が高いです。Microsoft は、既存の Group Policy Object または Mobile Device Management の設定と競合した場合、Edge 管理サービスのポリシーは上書きされると明記しています。既存の AD 管理や Intune 管理がある環境では、まずどこが最終的な設定元かを整理してから進めるべきです。 (マイクロソフト ラーン)
台数や拡張機能数が思ったより少ない
拡張機能監視のデータは Windows デバイスのみで、同一ユーザーが複数デバイスにサインインしている場合は最新サインイン端末からのレポートのみが対象です。全端末ぶんが常に重複なく見える設計ではないため、「ゼロだから未使用」と早合点しないほうが安全です。 (マイクロソフト ラーン)
導入後のおすすめ運用
最初の1週間は「承認」より「棚卸し」を優先する
公開プレビューの初期段階でいきなり細かい許可・拒否運用に入ると、例外だらけになりがちです。最初の1週間は、まずよく使われている拡張機能を把握し、社内で未知のもの、権限が広そうなもの、部署依存で使われているものを分類するところから始めたほうが失敗しません。
2週目で承認基準を短く文書化する
長い規程より、「業務必須か」「権限は妥当か」「代替手段はあるか」「全社標準にするか」の4項目で十分です。Microsoft も、拡張機能管理ではコンプライアンス要件、過剰権限、保存データ、許可/ブロックや強制インストールといった観点を整理して戦略化することを勧めています。 (マイクロソフト ラーン)
その後は月次レビューに落とし込む
Microsoft のガイドでも、拡張機能管理は一度決めて終わりではなく、月次・四半期・年次で見直しながら微調整する流れが示されています。新しい拡張機能は必ず増えるので、「毎月1回、監視画面と未処理リクエストを見る」だけでも、拡張機能運用はかなり安定します。 (マイクロソフト ラーン)
今やるべきこと
今回の「エッジ管理サービスはパブリック プレビューで拡張機能の監視を追加します」という更新は、単なる画面追加ではありません。Microsoft Edge 管理サービスを使って、拡張機能の実態把握、ブロック済み拡張機能の申請対応、そしてポリシー化までを一連で回しやすくしたアップデートです。 (マイクロソフト ラーン)
実務としては、次の順で着手するのが最短です。
- Microsoft 365 の Release preferences で Targeted release を確認する。 (マイクロソフト ラーン)
Settings > Microsoft Edgeから Edge 管理サービスに入り、pilot グループ向けに監視を有効化する。 (マイクロソフト ラーン)- まずはインストール済み拡張機能の傾向を見て、承認基準を決める。 (マイクロソフト ラーン)
- ブロック済み拡張機能の申請対応まで回したいなら、Cloud policy を中心に設計する。 (マイクロソフト ラーン)
- 反映トラブルを避けるため、GPO/MDM との競合とブラウザー再起動を必ず確認する。 (マイクロソフト ラーン)
拡張機能の管理は、禁止リストを増やすことではなく、「何を、なぜ、どこまで許可するか」を決めることです。今回のプレビューは、その判断をデータベースで支えるための第一歩として、かなり実用的です。
コメント