Microsoft Edge Browser Policy Documentationを確認する目的は、「新しいポリシー名を知ること」だけではありません。組織で配布しているMicrosoft Edgeの挙動、Copilot表示、ローカルフォント権限、Webアプリの互換性、更新ポリシーとの切り分けまで見直すための公式リファレンスです。今回まず押さえるべき結論は、Microsoft Edge version 150では新規ポリシーは追加されておらず、version 149で追加された7つのポリシーと、version 150でobsolete扱いになったDisabledMiniAppsの確認が実務上の優先ポイントになります。(Microsoft Learn)
特に管理者は、既存GPOやIntune構成をそのまま流用するのではなく、edge://policyで現在適用中のポリシーを棚卸しし、廃止予定・無効化済み・新規追加ポリシーを分けて確認する必要があります。開発者は、data: URLから生成するWeb Worker、ローカルフォント情報の利用、navigator.cpuPerformanceに依存する処理がないかを優先的に検証してください。
Microsoft Edge Browser Policy Documentationでまず押さえる結論
Microsoft Edge Browser Policy Documentationは、組織内のMicrosoft Edgeを制御するためのブラウザーポリシー一覧です。公式ドキュメントでは、Microsoft Edge version 77以降が対象とされ、更新タイミングや更新方法を制御するポリシーは別の「Microsoft Edge Update policies」として案内されています。つまり、ブラウザー機能の制御と、Edge本体の更新制御は分けて設計する必要があります。(Microsoft Learn)
| 確認項目 | 公式情報上の要点 | 管理者が取るべき対応 |
|---|---|---|
| Edge 150の新規ポリシー | 新規ポリシーはなし | 新規追加よりも、既存ポリシーの廃止・互換性影響を確認する |
| Edge 149の新規ポリシー | 7つのポリシーが追加 | Copilot、ローカルフォント、Web Worker、パフォーマンス関連を優先確認する |
| Edge 150のobsoleteポリシー | DisabledMiniAppsがobsolete | Android向けMini Apps制御をこのポリシーに依存していないか確認する |
| deprecatedポリシー | Proxy、Wallet、Officeメニュー、Games、WebWidgetなど複数あり | 設定が残っている場合は「効いている前提」で運用しない |
| 更新ポリシー | ブラウザーポリシーとは別体系 | msedge.admxとmsedgeupdate.admxを混同しない |
| Microsoftアカウントの扱い | Edge 116以降、一部ポリシーはMicrosoftアカウントでサインインしたプロファイルに適用されない場合がある | Entra IDの業務プロファイルと個人Microsoftアカウントの挙動を分けて検証する |
この変更で重要なのは、「Edge 150で新機能が大量に追加された」という話ではありません。むしろ、Edge 149で追加されたポリシーがEdge 150環境にも関係し、同時に一部の古い制御方法が使えなくなる点です。
Edge 149で追加された7つのポリシー
Edge 149で追加された新規ポリシーは、次の7つです。大きく分けると、プライバシー・AI表示・Web互換性・パフォーマンス制御に関係します。(Microsoft Learn)
| ポリシー名 | 何を制御するか | 実務での確認ポイント |
|---|---|---|
DefaultLocalFontsSetting | ローカルフォント権限の既定動作 | フォント情報へのアクセスを既定でブロックするか、都度確認にするかを決める |
LocalFontsAllowedForUrls | 指定サイトでローカルフォント権限を許可 | デザインツール、DTP系Webアプリ、社内制作システムなど必要なサイトだけ許可する |
LocalFontsBlockedForUrls | 指定サイトでローカルフォント権限を拒否 | 外部サイトや不要な業務外サイトでローカルフォント情報を取得させない |
CopilotAddressBarSuggestionsEnabled | アドレスバーのCopilotチャット候補表示 | 社内AI利用ポリシーに合わせ、表示を許可するか抑止する |
CpuPerformanceTierOverride | navigator.cpuPerformanceの返却値を上書き | 端末性能に応じてUIや処理を変えるWebアプリの検証に使う |
DataUrlInWebWorkerOpaqueOriginEnabled | data: URL由来のWeb Workerをopaque originにするか | 旧挙動に依存する社内Webアプリの互換性を確認する |
ForceForegroundPriorityForUrls | 指定URLのバックグラウンドWebコンテンツを前面優先度で動かす | 常時稼働ダッシュボード、通話、監視画面などに限定して使う |
ローカルフォント権限は「既定ブロック＋必要サイトのみ許可」が基本
DefaultLocalFontsSettingは、サイトが端末内のローカルフォント情報へアクセスしようとしたときの既定動作を制御します。設定値は、ローカルフォント権限を既定で拒否するBlockLocalFonts、またはアクセス要求時にユーザーへ確認するAskLocalFontsです。未構成の場合は、ユーザーに確認し、ユーザーが設定を変更できる既定動作になります。(Microsoft Learn)
実務では、全サイトに広く許可するよりも、DefaultLocalFontsSettingで慎重な既定値を置き、業務上必要なサイトだけLocalFontsAllowedForUrlsで許可する運用が安全です。たとえば、社内のデザイン確認システムや印刷プレビュー系アプリがローカルフォント情報を必要とする場合は、そのドメインだけを許可リストに入れます。
LocalFontsAllowedForUrlsとLocalFontsBlockedForUrlsはURLパターンのリストで制御します。ワイルドカードは利用できますが、判定はoriginベースで、URL内のpathは無視されます。たとえば、https://example.com/app1とhttps://example.com/app2を分けて制御したつもりでも、originが同じであれば意図通りに分離できない可能性があります。 (Microsoft Learn)
ローカルフォント設定で失敗しやすい例
| 失敗例 | 起きる問題 | 対応 |
|---|---|---|
| パス単位で許可・拒否できると思い込む | 同じorigin内の別アプリにも影響する | サブドメイン分離やアプリ配置の見直しを検討する |
| 外部SaaSをまとめて許可する | 不要なサイトにもローカルフォント情報を許可してしまう | 業務上必要なURLだけに絞る |
| ユーザー確認に任せる | 部署や端末ごとに挙動がばらつく | 管理対象端末では既定値と許可リストを明示する |
Copilotのアドレスバー候補表示は社内AIポリシーと合わせて判断する
CopilotAddressBarSuggestionsEnabledは、Microsoft EdgeのアドレスバーにCopilotチャット候補を表示するかどうかを制御するポリシーです。有効または未構成の場合は候補が表示され、無効にすると表示されません。対応環境はWindowsとmacOSのEdge 149以降で、AndroidとiOSは対象外です。また、Microsoftアカウントでサインインしたプロファイルには適用されないと記載されています。(Microsoft Learn)
ここで注意したいのは、これは「Copilot全体の利用可否」だけを決める設定ではなく、アドレスバー上の候補表示に関する制御だという点です。組織でCopilotや生成AIの利用ルールを定めている場合は、次のように整理すると判断しやすくなります。
| 組織の方針 | 推奨される確認 |
|---|---|
| Copilot利用を積極的に進める | 候補表示が業務効率化に寄与するか、ユーザー教育と合わせて確認する |
| 生成AI利用を限定運用している | 候補表示だけが先に出て、利用ルールと矛盾しないか確認する |
| 部署ごとにAI利用可否が違う | OU、Intuneグループ、プロファイル種別ごとに適用範囲を分ける |
| 個人Microsoftアカウント利用を許容している | 業務プロファイルと個人プロファイルで表示差が出る可能性を検証する |
アドレスバーは全ユーザーが頻繁に触れる場所です。小さなUI変更でも問い合わせにつながりやすいため、展開前にスクリーンショット付きの社内案内を用意しておくと、ヘルプデスク負荷を下げられます。
Web Workerのopaque origin化は開発チームが必ず確認する
DataUrlInWebWorkerOpaqueOriginEnabledは、data: URLから作成されたWeb Workerに一意のopaque originを割り当てるかどうかを制御します。Edge 149以降では既定でopaque originが割り当てられ、作成元ページから分離される挙動になります。公式ドキュメントでは、旧挙動に依存する社内アプリの互換性問題に対する一時的な緩和策としてのみ、無効化を使うべきだと説明されています。さらに、このポリシーは一時的なもので、Edge version 157で削除される予定とされています。(Microsoft Learn)
開発者が確認すべきなのは、次のような実装です。
new Worker()でdata:URLを渡している- Worker内の処理が、作成元ページと同一originであることを前提にしている
- 認証情報、Cookie、ストレージ、同一origin前提のAPIアクセスに依存している
- 古いライブラリや社内フレームワークがWorker生成処理を隠蔽している
このポリシーを無効化して旧挙動へ戻すことは、あくまで移行期間を確保するための手段です。Edge 157で削除予定とされているため、「ポリシーで戻せるから問題なし」と判断すると、将来のアップデートで再び障害化する可能性があります。対応方針としては、まずコード上のdata: Worker利用を洗い出し、可能であれば通常の同一originスクリプトファイルやBlob URLなど、アプリ設計に合った方法へ見直すことを優先してください。
CPU Performance APIとバックグラウンド優先度は使いどころを絞る
CpuPerformanceTierOverrideは、CPU Performance API、つまりnavigator.cpuPerformanceが返す値を0から4の範囲で上書きできるポリシーです。Windows、macOS、AndroidのEdge 149以降でサポートされ、iOSは対象外です。未構成の場合は、既定のパフォーマンス階層計算が使われます。(Microsoft Learn)
このポリシーは、一般ユーザー端末へ一律展開するというより、Webアプリの検証で役立ちます。たとえば、端末性能に応じてアニメーション、動画品質、重い処理の有効化を切り替える社内アプリがある場合、実機を多数用意しなくても一部の挙動を検証しやすくなります。ただし、値を上書きすると実際の端末性能とアプリ側の判定がずれるため、本番運用では慎重に扱うべきです。
ForceForegroundPriorityForUrlsは、指定したURLパターンに一致するバックグラウンドWebコンテンツを、前面タブと同じ優先度で実行させるためのポリシーです。通常、ブラウザーは非表示タブの優先度を下げてシステム全体の応答性を保ちます。このポリシーは、その最適化を特定サイトだけ上書きするものです。(Microsoft Learn)
使いどころは限定的です。たとえば、コールセンターの待受Webアプリ、リアルタイム監視ダッシュボード、業務上バックグラウンドでも処理遅延を避けたいWebアプリなどが候補になります。一方で、対象URLを広げすぎるとCPU使用率やバッテリー消費、端末全体のレスポンスに影響する可能性があります。
また、ForceForegroundPriorityForAllTabsが有効な場合、すべてのタブがすでに前面優先度で動作するため、ForceForegroundPriorityForUrlsは無視されます。URL単位で細かく制御したい場合は、全タブ対象のポリシーと同時に使わないように設計してください。(Microsoft Learn)
obsoleteになったDisabledMiniAppsは「効いている前提」で残さない
Edge 150でobsoleteとして示されているのがDisabledMiniAppsです。このポリシーは、Android版Microsoft EdgeでMini Appsを無効化するためのリスト型ポリシーでしたが、公式ドキュメントでは「Microsoft Edge version 149より後では動作しない」と明記されています。対応バージョンもAndroid 140から149までで、Windows、macOS、iOSは対象外です。(Microsoft Learn)
管理者が避けるべきなのは、「設定が残っているから制御できている」と考えることです。obsoleteポリシーは、設定値が管理画面や構成プロファイルに残っていても、実際には効果がない可能性があります。Android向けにMini Appsや関連機能を抑止していた組織は、次の順番で見直してください。
| 確認内容 | 対応 |
|---|---|
DisabledMiniAppsを構成しているか | GPO、MDM、管理対象アプリ構成を棚卸しする |
| Edge 150以降の端末があるか | 実機で該当機能が抑止されているか確認する |
| 何を止めたかったのか | Copilot、Games、Wallet、PDF Readerなど目的別に整理する |
| 代替ポリシーがあるか | Microsoft Edge Browser Policy Documentationで機能単位に探す |
| 代替がない場合 | 社内ルール、アプリ制限、ネットワーク制御など別レイヤーで補完する |
「古いポリシーを残しておく」こと自体は一見無害に見えます。しかし、監査や問い合わせ対応の場面では、実際には効いていない設定を根拠に説明してしまうリスクがあります。obsoleteポリシーは、削除・置換・例外管理のいずれかを明確にしておくべきです。
deprecatedポリシーは移行計画の対象にする
公式一覧では、deprecatedポリシーとして複数の項目が示されています。代表的なものには、証明書選択、Gamesメニュー、Microsoft Officeメニュー、Officeショートカット、ブラウザー側のProxy関連、Related Website Sets、Wallet、WebWidget、JavaScriptタイマー関連などがあります。(Microsoft Learn)
deprecatedは、ただちに無効になるとは限りません。しかし、新規設計で採用すべきではなく、既存構成がある場合は移行計画の対象にするべき状態です。
| deprecatedの種類 | 影響しやすい運用 | 確認ポイント |
|---|---|---|
| Proxy関連 | 社内プロキシ、PAC、例外リスト | OS側設定、ネットワーク設定、Edge Update側Proxyポリシーと混同していないか |
| Office・Games・Wallet・WebWidget関連 | UI抑止、業務外機能の非表示 | 後継ポリシーの有無と、実際の表示状態を端末で確認する |
| 証明書関連 | クライアント証明書認証 | 代替ポリシーや認証フローの動作確認を行う |
| Web互換性関連 | 古いWebアプリの延命 | 将来の削除に備え、アプリ側の改修計画を立てる |
特にProxy関連は注意が必要です。Microsoft Edge Updateの更新制御やProxy制御は、ブラウザーポリシーとは別の更新ポリシー体系にあります。Microsoftの構成ガイドでも、Edge本体の設定に使うmsedge.admxと、Edge更新管理に使うmsedgeupdate.admxは別テンプレートとして説明されています。(Microsoft Learn)
管理者が確認すべき展開手順
Microsoft Edgeのポリシー変更は、いきなり全社配布するのではなく、棚卸し、テンプレート更新、検証、段階展開の順で進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状把握 | 管理対象端末でedge://policyを開き、適用中ポリシーを確認する | 期待したポリシーと、実際に適用されているポリシーが一致するか |
| 構成元の特定 | GPO、Intune、レジストリ、macOS構成プロファイル、Android管理構成を確認する | 同じポリシーを複数経路で設定していないか |
| ADMX更新 | 最新のMicrosoft Edgeポリシーテンプレートを入手し、Central Storeまたは端末へ配置する | msedge.admxとmsedgeupdate.admxを取り違えない |
| 新規ポリシー検討 | Edge 149追加ポリシーを必要性ごとに分類する | Copilot、ローカルフォント、Web Worker、パフォーマンスを優先 |
| deprecated/obsolete整理 | 使っている古いポリシーを一覧化する | obsoleteは効いている前提で残さない |
| パイロット展開 | 情シス、開発、ヘルプデスク、業務部門代表で検証する | UI変更、Webアプリ障害、端末負荷、問い合わせを確認 |
| 本番展開 | OUやIntuneグループ単位で段階的に配布する | 問題発生時に切り戻せる単位で展開する |
| 適用確認 | gpupdate /forceやEdge再起動後にedge://policyで確認する | ポリシー名、値、適用範囲、エラー表示を確認する |
Microsoftの構成ガイドでは、GPOでEdgeを構成する場合に管理用テンプレートをCentral Storeまたは個別端末へ配置する方法、mandatoryポリシーとrecommendedポリシーの違い、edge://policyで適用状況を確認する方法が説明されています。Active Directory環境では反映まで時間がかかる場合があり、必要に応じてgpupdate /forceを実行して確認します。(Microsoft Learn)
mandatoryとrecommendedを混同しない
Microsoft Edgeのポリシーには、mandatoryとrecommendedがあります。mandatoryはユーザー設定を上書きし、ユーザーが変更できない設定です。recommendedは既定値を提示するもので、ユーザーが上書きできる場合があります。両方が設定されている場合はmandatoryが優先されます。(Microsoft Learn)
たとえば、セキュリティ上必ず無効にしたい機能をrecommendedで設定してしまうと、ユーザー操作で変更される可能性があります。一方で、部署ごとの利便性を考慮して既定値だけ配りたい設定までmandatoryにすると、現場の例外対応が増えます。
判断基準は次のように分けると実務で迷いにくくなります。
| 設定方針 | 向いている例 |
|---|---|
| mandatoryにする | セキュリティ、情報漏えい対策、監査要件、業務禁止機能 |
| recommendedにする | ホームページ、検索設定、軽微なUI既定値、ユーザー裁量を残す設定 |
| 未構成にする | 組織として統制不要、または影響範囲が未検証の設定 |
今回追加された新規ポリシーの多くは、mandatoryとして構成可能で、recommendedには対応しないものが中心です。つまり、設定すればユーザー裁量ではなく組織の制御として効くため、展開前の検証がより重要になります。
開発者が確認すべき互換性チェックリスト
Edgeのポリシー変更は、管理者だけの話ではありません。特に社内WebアプリやSaaS連携を開発・運用しているチームは、次の観点で確認してください。
| チェック項目 | 確認方法 | 問題があった場合の対応 |
|---|---|---|
data: URL由来のWeb Workerを使っていないか | コード検索でnew Worker、data:、Worker生成ライブラリを確認 | opaque origin前提で動くように設計を見直す |
| ローカルフォント情報へ依存していないか | デザイン、帳票、プレビュー機能を実機で確認 | 必要な業務サイトだけ許可リストへ入れる |
navigator.cpuPerformanceを参照していないか | フロントエンドコード、性能判定ロジックを確認 | 上書きポリシーで検証し、実機差分も確認する |
| バックグラウンド動作が重要なWebアプリがあるか | 監視画面、通話、通知、リアルタイム処理を確認 | 必要最小限のURLだけ前面優先度対象にする |
| Copilot候補表示が業務フローに影響しないか | アドレスバー入力、検索、ユーザー教育資料を確認 | AI利用ルールに合わせて表示可否を決める |
合格基準は、「画面が開く」だけでは不十分です。ログイン状態、権限プロンプト、バックグラウンド動作、処理遅延、ユーザーへの表示文言まで確認してください。特にWeb Workerとローカルフォントは、普段の簡易テストでは見落としやすい領域です。
展開前に確認したい実務上の注意点
個人Microsoftアカウントのプロファイルを見落とさない
公式ドキュメントでは、Edge 116以降、一部ポリシーがMicrosoftアカウントでサインインしたプロファイルに適用されない場合があると案内されています。(Microsoft Learn)
企業端末であっても、ユーザーが個人Microsoftアカウントのプロファイルを使っている場合、Entra IDの業務プロファイルとは挙動が異なる可能性があります。Copilot関連やCPU Performance API関連のように、個別ページで「Microsoftアカウントのプロファイルに適用されるか」が明示されているポリシーは、必ずプロファイル種別ごとに検証してください。
セキュリティベースラインと個別ポリシーを混同しない
Microsoft Edge Browser Policy Documentationは、利用可能なポリシーを確認するためのリファレンスです。一方で、推奨セキュリティ構成を確認する場合は、Microsoft Security Compliance Toolkitやセキュリティベースラインの参照が案内されています。(Microsoft Learn)
新しいポリシーが追加されたからといって、すべてを有効にする必要はありません。セキュリティベースライン、社内標準、業務要件、例外要件を分けて判断することが重要です。
URLパターンは検証用と本番用を分ける
ローカルフォント許可・拒否、前面優先度制御など、URLパターンを使うポリシーでは、検証用URLをそのまま本番へ流用しないよう注意してください。ワイルドカード指定は便利ですが、範囲を広げすぎると意図しないサイトまで対象になります。
本番展開前には、次の3点を確認します。
- 対象ドメインが業務上本当に必要か
- サブドメインやポート番号を含めた指定が正しいか
- 将来のアプリ統合やドメイン変更で影響が広がらないか
「ポリシーが表示されない」はADMX不整合を疑う
新規ポリシーがグループポリシーエディターに表示されない場合、まずADMXテンプレートが古い可能性を疑います。Edgeの管理用テンプレートは、Microsoft Edge Enterpriseの提供ファイルから取得し、msedge.admxと該当言語のmsedge.admlを正しい場所へ配置する必要があります。(Microsoft Learn)
複数ドメインコントローラーがある環境では、Central Storeへの配置後にレプリケーションのタイミングも考慮してください。端末側で見えているポリシー一覧と、管理者が編集しているテンプレートのバージョンがずれていると、検証結果が混乱します。
すぐに取るべき対応
今回のMicrosoft Edge Browser Policy Documentationで、管理者が最初にやるべきことは明確です。Edge 150に新規ポリシーはありませんが、Edge 149で追加されたポリシーは現行運用に影響し、DisabledMiniAppsのようにEdge 150でobsoleteになった項目もあります。(Microsoft Learn)
まず、代表端末でedge://policyを開き、現在適用中のポリシーを一覧化してください。次に、Edge 149追加ポリシー、deprecatedポリシー、obsoleteポリシーに分類します。そのうえで、ADMXテンプレートやIntune構成を更新し、Copilot表示、ローカルフォント権限、Web Worker互換性、バックグラウンド優先度をパイロット環境で検証します。
最後に、obsoleteやdeprecatedの設定を「残しておけば安心」と考えないことが重要です。効かないポリシーや将来削除されるポリシーを整理し、業務要件に必要な制御だけを現行のサポート対象ポリシーへ移行することが、安定したMicrosoft Edge管理につながります。
コメント