MENU

XSLTEnabledとは？Edge 147の設定・動作確認・XSLT廃止への対処

Microsoft Edge

XSLTEnabledは、Microsoft EdgeでXSLTを利用できるかを管理する一時的なポリシーです。Windows・macOSのEdge 147以降で、XSLTProcessor JavaScript APIとXSL処理命令の利用可否を制御します。XMLを使うシステムすべてを停止する設定ではありません。

業務画面がXSLTへ依存している場合は、検証環境で影響を確認し、必要な範囲で有効化して移行を進めます。XSLTEnabledを一度有効にすれば将来も使い続けられる、という仕様ではありません。2026年10月3日に確認したMicrosoftの文書は、将来のEdgeで削除される一時ポリシーとしています。

目次

XSLTEnabledの有効・無効・未構成の違い

設定公式の動作運用で確認すること
有効：true／1ブラウザー既定の構成にかかわらずXSLTを利用可能XSLT依存画面の一時的な互換性対策として必要か
無効：false／0ブラウザー既定の構成にかかわらずXSLTを利用不可既存画面や帳票が壊れないか
未構成既定の構成と適用されるフィールド試験で決まる未構成を恒久的な「有効」と解釈しない

XSLTを使っていないと分かっている端末でも、検証なしで全社に無効を配布する必要はありません。依存関係、業務影響、組織の方針を確認して選びます。本番を一斉に変更する前に、代表的なアプリを検証することが大切です。

仕様内容
対象Edge 147以降のWindows・macOS。Android／iOSは非対応
型ブール値。WindowsレジストリではREG_DWORD
ポリシーの種類必須に設定可能。推奨には非対応
更新動的なポリシー更新に対応
適用単位プロファイルごと
個人用Microsoftアカウントのプロファイル公式文書ではMSAサインイン済みプロファイルには適用されない

XML全体の廃止と混同しない

影響を受ける代表例は、XMLに <?xml-stylesheet type="text/xsl" … ?> が付いていてブラウザーがHTMLへ変換する画面や、JavaScriptで new XSLTProcessor() を使う処理です。XMLのデータ形式自体、通常のXML解析、XMLにCSSを付けて表示する仕組みまで、XSLTEnabledが一括制御する意味ではありません。

Edge 147のWebプラットフォームリリースノートには、XSLTスタイルシートによるXMLからSVGへの変換の削除も記載されています。XSLTEnabledを有効にすれば、すでに削除されたすべての変換方式まで戻ると決めつけないでください。実際の入力XML・XSLと、出力形式を使って確認します。

最初に行う依存調査と比較テスト

  1. 社内コードや配布ファイルで、XSLTProcessor、transformToDocument、transformToFragment、xml-stylesheet、type="text/xsl"、.xsl を検索します。
  2. 対象がEdgeのタブで動くWebサイトなのか、WebView2を埋め込んだWindowsアプリなのかを記録します。
  3. 検証端末で、未構成・有効・無効の状態を比較します。同じURL、同じアカウント、同じ入力データを使い、画面・帳票・印刷結果を確認します。
  4. 開発者ツールのコンソールにXSLTの非推奨警告やエラーが出るか、XML/XSLの読み込みが成功しているかを確認します。通信エラーと変換エラーを分けます。

無効にすると白画面になり、有効で戻る場合はXSLT依存を疑う材料になります。ただし、比較だけで原因が確定するわけではありません。認証・CORS・URLの到達失敗や別のスクリプトエラーが同時に起きていないかも確認します。ページ自体へ到達できない場合は、Edgeの到達エラーの切り分けを先に行います。

設定値が適用されたか、小さなXSLT変換で確認する

XSLTProcessorの存在確認だけで終わらず、小さなXMLとXSLを実際に変換して、同じプロファイルで設定前後を比較します。 検証対象の通常のWebページでF12を開き、コンソールで以下の小さなテストを実行できます。外部ファイルを取得せず、ページの表示内容を書き換えない例です。管理者が許可した検証環境で、コードの内容を確認して使ってください。

(() => {
  try {
    if (typeof XSLTProcessor !== "function") {
      console.log("XSLTProcessor: 利用不可");
      return;
    }
    const parser = new DOMParser();
    const xml = parser.parseFromString('<check>xslt-ok</check>', "application/xml");
    const xsl = parser.parseFromString(`<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="/">
    <p><xsl:value-of select="/check"/></p>
  </xsl:template>
</xsl:stylesheet>`, "application/xml");
    const processor = new XSLTProcessor();
    processor.importStylesheet(xsl);
    const result = processor.transformToFragment(xml, document);
    console.log("XSLT変換結果:", result?.textContent?.trim() ?? "結果なし");
  } catch (error) {
    console.error("XSLT変換失敗:", error.name, error.message);
  }
})();
表示される結果分かること／次の確認
XSLT変換結果: xslt-okこのページ・プロファイルでは、少なくともこの変換が実行できた
XSLTProcessor: 利用不可APIが利用できない。Edgeの版・対象プロファイル・edge://policyの適用値を照合
XSLT変換失敗、または結果なし例外の名前と全文を記録。設定の状態と変換処理のエラーを分けて調査

有効・無効・未構成を比較するときは、ポリシーを再読み込みしてからページを開き直し、同じテストと実業務の入力を使います。無効から有効へ変更して小さなテストだけ直った場合も、実際のXML/XSLの読み込み、名前空間、出力形式や画面描画まで直ったことにはなりません。

この例のAPIはMDNのtransformToFragmentの説明を参照できます。現在のブラウザでの利用状態を調べるためのテストで、新規開発にXSLT依存を増やすための推奨ではありません。設定値の意味と一時ポリシーであることはMicrosoftの現行XSLTEnabled文書で確認します。

Windowsのグループポリシーで設定する

現在のEdgeに対応する管理用テンプレートを用意し、MSEdge.admx と必要な言語ファイルを導入します。［管理用テンプレート］→［Microsoft Edge］で、XSLT機能の可用性を制御する設定を探します。内部名は XSLTEnabled です。推奨ポリシーの階層ではなく、必須設定として配布します。

依存が残る検証対象で一時的に使う場合は有効、XSLTを使えない状態を試す場合は無効を選びます。組織のGPOやMDMが管理している端末では、ローカル設定で上書きを繰り返さず、管理元で対象グループと競合を確認してください。

レジストリで検証する場合の例

以下は管理者が管理のない検証端末で、現在の値を記録したうえで確認する例です。端末全体に設定するHKLMの例なので、管理者権限が必要です。

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /f

無効の検証では同じ値を 0 にします。元の状態が未構成で、自分がこの値だけを作成した場合の戻し方は、次の値だけを削除します。Edgeのポリシーキー全体を削除しないでください。既存の値があった場合は削除ではなく元の値へ戻します。

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /f

ドメインやIntuneなどから設定が配布されている場合は、レジストリ値の削除だけでは戻らず、次回の更新で再適用されます。配布したGPO・MDMの設定を管理元で戻してください。

macOSで設定する場合

macOSの基本設定キー名も XSLTEnabled で、ブール値を指定します。有効なら <true/>、無効なら <false/> を構成プロファイル等で配布し、対象プロファイルで確認します。WindowsのレジストリコマンドをMacで使う手順ではありません。

設定したのに効かないときはedge://policyで確認

  1. 対象のEdgeプロファイルで edge://version を開き、Edgeのバージョンが147以降か確認します。
  2. edge://policy を開き、［ポリシーの再読み込み］を実施します。XSLTEnabled の値、状態、適用元、適用範囲を確認します。
  3. 不明なポリシー、エラー、競合がある場合は、テンプレートと実際のブラウザーバージョン、GPO／MDMの配布を見直します。
  4. 対象の業務ページを再読み込みします。必要ならEdgeを終了して再起動し、同じデータで変換結果を比較します。

ポリシーにはプロファイルの条件があるため、「別プロファイルでは動く」という比較ではサインイン状態も確認します。個人用Microsoftアカウントでサインインしたプロファイルは、このポリシーの適用対象外とされています。Windowsの［組織によって管理されています］という表示だけでは、Edgeのこの値が適用済みとは判断できません。

WebView2アプリでは別の管理先を確認する

Edge本体とWebView2 Runtimeの更新・ポリシーは分けて確認します。WebView2にもWindows 147以降の同名ポリシーがあり、管理用テンプレートは MSEdgeWebView2.admx、レジストリの管理先は下記です。

対象テンプレートレジストリパス
EdgeブラウザーMSEdge.admxSOFTWARE\Policies\Microsoft\Edge
WebView2MSEdgeWebView2.admxSOFTWARE\Policies\Microsoft\Edge\WebView2

Edgeのタブだけ直って社内アプリが直らない場合は、アプリが使用するRuntimeのバージョン、管理先、アプリの再起動を確認します。WebView2の役割が分からない場合は、msedgewebview2.exeとEdge本体の違いも参照できます。WebView2用の設定をEdgeの edge://policy だけで検証完了とはしません。

削除予定に備える：Chromeの予定をEdgeの確定期限へ流用しない

GoogleはChromeのXSLTについて、Stableでの停止をChrome 158・2026年11月17日、猶予用の仕組み終了をChrome 176・2027年8月17日とする計画を公開しています。これはChromeの計画です。Edgeが同じ日程で削除するとMicrosoftが確定した情報として読み替えないでください。MicrosoftのXSLTEnabled文書は将来削除と説明しており、本文書だけではEdgeの削除版・日付を確定できません。

移行では、サーバー側でXSLT変換してHTMLを返す、XML解析と表示処理を分けてJavaScriptで描画する、JSONなどへデータの受け渡しを変更する方法を検討します。既存XSL資産を使う別ライブラリ等を選ぶ場合も、必要なXSLT仕様、性能、文字コード、CSP、データの扱いを検証します。

暫定的にポリシーを有効にするなら、対象アプリ、管理責任者、見直し時期、移行先と確認データを記録します。機能が残る期限を断定せず、Microsoftのリリースノートとポリシー文書を継続して確認してください。

参考：公式の手順と仕様

Microsoft Edge
Microsoft Edge WebView2 ポリシー管理 XSLT

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次