Microsoft Edge 147 の XSLTEnabled ポリシーで一番大事なのは、XSLT を使う業務システムがあるなら未構成のままにしないことです。Stable 147.0.3912.60（2026年4月10日）のリリースノートでは XSLTEnabled が新しいポリシーとして追加され、ポリシー文書では XSLTProcessor JavaScript API と XSL 処理命令の利用可否を制御すると説明されています。しかもこのポリシーは一時的で、将来の Edge で削除予定です。つまり、今の互換性を守るための管理スイッチとしては有効ですが、恒久対策として頼り続ける設計には向きません。 (Microsoft Learn)
Microsoft Edge のポリシー管理で判断すべきことはシンプルです。XSLT 依存があるなら明示的に有効化し、不要なら明示的に無効化する。この記事では、XSLTEnabled が何を制御するのか、未構成が危ない理由、Windows/macOS での設定方法、edge://policy での確認方法、そして WebView2 と混同しやすい実務上の落とし穴まで整理します。公開されているポリシー文書では、Windows と macOS の Edge 147 以降が対象で、Android と iOS は対象外です。 (Microsoft Learn)
Edge 147 の XSLTEnabled ポリシーとは
XSLT は、XML を HTML などへ変換するために使われる仕組みです。Edge 147 で追加された XSLTEnabled は、その XSLT 機能を Microsoft Edge で使えるかどうかを管理者が固定するためのスイッチで、対象は XSLTProcessor JavaScript API と XSL 処理命令です。 (Chrome for Developers)
公式情報を運用向けに整理すると、基本仕様は次のとおりです。 (Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 追加されたバージョン | Microsoft Edge Stable 147.0.3912.60（2026年4月10日） |
| ポリシー名 | XSLTEnabled |
| 役割 | XSLT 機能の可用性を制御 |
| 制御対象 | XSLTProcessor JavaScript API、XSL 処理命令 |
| 対応バージョン | Windows 147以降、macOS 147以降 |
| 非対応 | Android、iOS |
| データ型 | ブール値 |
| 運用上の性質 | 必須に設定可能、推奨は不可、動的更新あり、プロファイルごと |
| 注意点 | Microsoft アカウントでサインインしているプロファイルには適用されない |
| 将来性 | 一時的なポリシーで、将来の Edge で削除予定 |
要するに、XSLTEnabled は「XSLT を使わせるかどうかを、管理者が明示的に固定するためのポリシー」です。ブラウザーの既定動作に任せず、組織の方針で挙動を決めたいときに使います。 (Microsoft Learn)
まず押さえたい: XSLTEnabled は XML 全体のオン・オフではない
ここを誤解すると判断を誤ります。XSLTEnabled が制御するのは XSLT であって、XML 処理全体ではありません。Edge 147 の Web プラットフォーム更新では、XSLT が不要なシナリオ向けに Rust ベースの XML パーサーが導入され、DOMParser、XMLHttpRequest の responseXML、SVG ドキュメントが対象とされています。つまり、単に XML を読み込むだけの処理まで一括で止める話ではありません。 (Microsoft Learn)
一方で、同じ Edge 147 では「XSLT スタイルシートで XML を SVG に変換するサポート」が削除され、互換性影響の大きい変更としても掲載されています。少なくとも Edge 147 の流れは、XSLT 依存をそのまま温存する方向ではなく、縮小しながら必要な組織には一時的な管理スイッチを用意する方向だと読み取りやすい状況です。 (Microsoft Learn)
次のような資産は、XSLTEnabled の影響を受けやすい候補です。
- XML 応答に
<?xml-stylesheet type="text/xsl" ... ?>を含む画面 - フロントエンドで
new XSLTProcessor()を使っているコード - XML 帳票、EDI 連携画面、古い社内ポータル、レポートビューア
- ブラウザーではなく WebView2 ベースの業務アプリ
ソースコードやレスポンスを見ずに「XML を使っているから影響する」「XML だから関係ない」と決めつけるのが、最初の失敗ポイントです。
有効・無効・未構成のどれを選ぶべきか
公式仕様をそのまま運用判断に落とすと、選び方は次のようになります。 (Microsoft Learn)
| 設定 | Edge の挙動 | 向いているケース | 注意点 |
|---|---|---|---|
| 有効 | ブラウザー既定の構成に関係なく XSLT を利用できる | 既存の業務アプリが XSLT に依存しており、互換性を優先したい | 将来削除予定の一時ポリシーなので、移行計画は別途必要 |
| 無効 | ブラウザー既定の構成に関係なく XSLT を利用できない | XSLT を使っておらず、利用可否を明確に固定したい | 古い XML ビューアや社内画面が動かなくなる可能性がある |
| 未構成 | ブラウザー既定の構成と該当するフィールド試用版に依存 | 影響調査や短期検証で、まず既定挙動を見たい | 本番では挙動を自社で固定できず、将来の変化を読みづらい |
未構成は「現状維持」ではなく、「既定値とフィールド試用版に任せる」です。 業務で XSLT 依存が1つでも残っているなら、本番では未構成より明示的な有効化のほうが安全に運用しやすいです。逆に、依存がないと確認できているなら、無効化しておくほうが将来の判断もシンプルになります。 (Microsoft Learn)
Edge 147 の XSLTEnabled ポリシー設定方法
Windows のグループポリシーで設定する
Windows のブラウザー向けポリシーとして使う場合、XSLTEnabled の GP 固有名は XSLTEnabled、GP 名は「XSLT 機能の可用性を制御する」、配置先は「管理用テンプレート/Microsoft Edge」、ADMX ファイルは MSEdge.admx です。また、このポリシーは必須設定のみで、推奨ポリシーとしては使えません。 (Microsoft Learn)
msedge.admx を導入済みなら、グループポリシー エディターで Microsoft Edge 配下から設定できます。XSLT を使わせたいなら有効、禁止したいなら無効です。ユーザーに判断を委ねるような「推奨設定」で配ることはできません。 (Microsoft Learn)
レジストリで素早く検証する例
検証機でまず動作確認したいなら、レジストリで試すと速いです。
有効化する例
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /f無効化する例
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 0 /fブラウザー向けの値名は XSLTEnabled、型は REG_DWORD、パスは SOFTWARE\Policies\Microsoft\Edge です。ローカルポリシーの確認やパイロット端末での再現テストには、この方法が最も手早いです。 (Microsoft Learn)
macOS で設定する
macOS では基本設定キー名が XSLTEnabled で、公式ドキュメントには <true/> のサンプル値が示されています。Mac 管理下の Edge でも、XSLT の利用可否を明示的に固定したいときに使えます。 (Microsoft Learn)
反映確認は edge://policy が基本
設定後は、対象端末で edge://policy を開いて XSLTEnabled が読み込まれているかを確認します。Microsoft の Windows 向け設定ガイドでも、ポリシー確認先として edge://policy が案内されています。ローカル設定はすぐ反映されやすい一方、Edge を開いたまま設定した場合は再起動が必要なことがあります。Active Directory 配下で即時反映を確認したいなら、gpupdate /force を使うと切り分けがしやすくなります。仕様上は動的なポリシー更新に対応していますが、検証時は再起動まで含めて確認するほうが確実です。 (Microsoft Learn)
WebView2 と Edge ブラウザーを混同しない
ここは実務でかなりハマりやすい点です。XSLTEnabled は Edge ブラウザー用だけでなく、WebView2 用にも同名ポリシーがあります。対象がブラウザーなのか、WebView2 ランタイムを埋め込んだ業務アプリなのかで、見るべき ADMX とレジストリ パスが変わります。 (Microsoft Learn)
| 対象 | ADMX | レジストリ パス | 主な想定 |
|---|---|---|---|
| Edge ブラウザー | MSEdge.admx | SOFTWARE\Policies\Microsoft\Edge | Edge 本体の表示・挙動を管理したい場合 |
| WebView2 | MSEdgeWebView2.admx | SOFTWARE\Policies\Microsoft\Edge\WebView2 | WebView2 ベースの Windows アプリを管理したい場合 |
「Edge では直ったのに、社内アプリでは直らない」「レジストリを入れたのに効かない」というときは、まずこの切り分けを疑うべきです。ブラウザー側に設定しても、影響を受けているのが WebView2 アプリなら別のポリシー領域を見ないといけません。 (Microsoft Learn)
導入前に確認したいチェックポイント
依存箇所を棚卸しする
まずは、XSLT を使っている画面やコードを洗い出します。検索の起点としては、次の文字列が実務で見つけやすいです。
<?xml-stylesheet
type="text/xsl"
new XSLTProcessor(
transformToDocument(
transformToFragment(
.xsl
application/xslt+xmlブラウザーで XML がそのまま表示される、帳票が白画面になる、表組みだけ崩れる、といった症状が出る画面は候補に入れておくと見落としを減らせます。
先に「無効」で壊れるかを試す
依存調査では、有効化テストだけでなく無効化テストも重要です。無効にして壊れるなら、その画面は XSLT 依存の可能性が高いです。逆に何も変わらないなら、少なくともブラウザー側 XSLT が主因ではない可能性が上がります。
対象プロファイルを確認する
XSLTEnabled はプロファイルごとのポリシーで、Microsoft アカウントでサインインしているプロファイルには適用されないと明記されています。共有端末、複数プロファイル運用、BYOD 混在環境では、この条件を見落とすと「同じ端末なのに人によって効いたり効かなかったりする」ように見えます。 (Microsoft Learn)
逃げ道ではなく、移行猶予だと理解する
このポリシーは一時的です。XSLT 依存があるなら、有効化で時間を稼ぎつつ、どの画面をサーバー側変換へ寄せるのか、どの XML 表示を別実装へ置き換えるのかまで決めておくべきです。方針が曖昧なまま有効化だけ先に入れると、将来の削除タイミングで同じ問題が再発します。 (Microsoft Learn)
よくある失敗
- 未構成なら今まで通りだと思い込む。未構成は既定の構成と該当するフィールド試用版に依存するため、本番挙動を固定したい運用には向きません。 (Microsoft Learn)
- Edge 用ポリシーだけ設定して、実際に影響している WebView2 アプリを見落とす。同名ポリシーでも管理場所が違います。 (Microsoft Learn)
- 推奨ポリシーで緩く配ろうとして、設定項目が見つからず迷う。XSLTEnabled は推奨設定に対応していません。 (Microsoft Learn)
- 一度有効化すれば長く使えると思う。公式には一時的なポリシーで、将来の Edge で削除予定です。 (Microsoft Learn)
- MSA サインイン済みプロファイルにも同じように効くと考える。公開文書では適用外です。 (Microsoft Learn)
まとめ
Edge 147 で追加された XSLTEnabled は、XSLT を使う資産の互換性を管理者が固定するための一時ポリシーです。Stable 147.0.3912.60 の新規ポリシーとして追加され、XSLTProcessor JavaScript API と XSL 処理命令を制御できます。やるべきことは3つだけです。まず XSLT 依存画面を棚卸しする。次に、依存があるなら明示的に有効化し、ないなら明示的に無効化する。最後に edge://policy で反映を確認し、WebView2 を含めた移行計画を作る。この順番で進めれば、Edge 147 の XSLTEnabled を「ただの新ポリシー」で終わらせず、将来の変更に備えた実務的な対策にできます。 (Microsoft Learn)
コメント