会社のリモートアプリを開くWeb画面が、ブラウザーの更新後に表示できなくなる可能性があります。Windows ServerのRD Web Accessを使っている職場では、ブラウザー内のXSLTが無効になる前に、代替の入口と一時回避策を確認しておきたいところです。
Chromeは158（2026年11月17日予定）から、通常の設定では安定版でXSLTが動作しなくなる計画です。一方、Edgeの公式資料では安定版159で既定の無効化が予定されています。
この記事では、まずXSLTとRD Web Accessの意味を整理し、影響の確認方法と管理者向けの対処手順を紹介します。確認日は2026年10月11日です。ブラウザーの予定は変更される場合があります。
XSLTとRD Web Accessとは？まずは仕組みを整理
XSLTは、XMLデータを表示用の画面へ変換する仕組み
XSLT（Extensible Stylesheet Language Transformations）は、XML形式のデータを、HTMLなど別の形式へ変換するための言語です。XMLはデータを整理して持つ形式、HTMLはブラウザーに画面を表示する形式、と考えると関係をつかみやすくなります。
例えば、「利用できるアプリの名前と接続先」というデータがあっても、そのままでは使いやすいメニューになりません。XSLTの変換ルールを使い、アプリ一覧として見える画面を作ります。これは仕組みを理解するための例です。
今回、廃止されるのはブラウザーが内蔵するXSLT処理です。サーバー側でXSLTを使う処理まで一律に使えなくなる、という話ではありません。Chrome公式の説明では、ブラウザー内のXSLTProcessorとXSLTを参照するXML処理命令が対象とされています。
RD Web Accessは、会社のリモートアプリを選ぶWebの入口
RD Web Access（Remote Desktop Web Access）は、Windows Serverのリモートデスクトップサービスで、利用者にアプリやデスクトップの一覧を提供するWebポータルです。会社から案内されたURLにアクセスし、サインインして、必要な業務アプリを選ぶ使い方が該当します。
従来のWebポータルは、選んだアプリやデスクトップを端末側のリモートデスクトップクライアントで起動します。「ブラウザーで選ぶ入口」と「接続して業務を行う仕組み」を分けて考えると、今回の影響を整理できます。出典：Microsoft LearnのRDSロール解説。
Microsoftは、RD Web Accessの画面表示が利用者のブラウザー内のXSLT処理に依存すると説明しています。この変換が止まると、画面を作れず、アプリを選ぶ入口が使えなくなります。
いつ変わる？ChromeとEdgeの日程・猶予を分けて確認
| ブラウザー | 既定でXSLTが無効になる予定 | 一時的に継続する方法 | 猶予の終了予定 |
|---|---|---|---|
| Chrome | 158：2026年11月17日 | 企業ポリシーXSLTEnabled、またはサイト側のOrigin Trial | 176：2027年8月17日に例外措置も終了 |
| Microsoft Edge | 安定版159。Canary・Dev・Betaは157 | 一時ポリシーXSLTEnabled | 176：2027年夏にポリシー削除予定 |
出典：ChromeのXSLT廃止計画、EdgeのBetaリリースノート。Edgeの具体的な安定版公開日は、上記のXSLT告知からは確認できません。Chromeの日付をEdgeにも当てはめないようにしてください。
Chrome 176になってから設定しても延長できる、という意味ではありません。同バージョンで企業ポリシーとOrigin Trialによる継続措置が終了する計画です。今の画面が使えていても、移行の準備は必要です。
どんな症状が出る？Microsoftが案内しているエラー
Microsoftのサポート記事KB5130994は、Windows Server 2016・2019・2022・2025を対象に、XSLTが無効なChromeまたはEdgeでRD Web Accessの表示に失敗する場合があると案内しています。
Unable to display RD Web Access画面を正しく表示できない旨の説明が続く場合があります。ただし、RD Web Accessが表示されない原因を、この変更だけで決めつけることはできません。ブラウザーのバージョン、XSLTの設定、同じURLへのアクセス状況を合わせて確認します。
公開サポート記事の初回公開日は2026年10月6日です。確認時点ではMicrosoftは修正に取り組んでいると説明しており、解決する更新プログラムの番号や提供日は掲載されていません。
利用者は何をすればよい？管理者へ伝える情報
- 表示できない画面のURLとエラー文を控える。
- ChromeまたはEdgeのバージョンを控える。
- いつから表示できなくなったか、ブラウザー更新の前後かを伝える。
- 会社から案内された代替のURLや接続方法があるか確認する。
会社のPCでは、ブラウザーの設定を管理者が配布している場合があります。利用者が個別に設定を変える前に、担当者へ確認してください。以下のポリシー設定は管理者向けです。
管理者向け：XSLTEnabledで一時的に表示を復旧する
Microsoftが案内する一時回避策は、利用者側のPCでXSLTEnabledを有効にする方法です。サーバーだけに設定しても、別のPCで使うブラウザーには適用されません。まず対象端末を絞り、表示と業務アプリ起動を確認してから配布します。
1．現在のポリシーを確認する
アドレスバーにEdgeならedge://policy、Chromeならchrome://policyを入力し、XSLTEnabledを確認します。設定の有無と値、適用元を記録しておくと、変更後の比較や後日の撤去に役立ちます。
Edgeの公式ポリシーでは、有効なら既定の設定にかかわらずXSLTを使用でき、無効なら使用できません。未設定の場合はブラウザーの既定設定などに従います。未設定だから必ず利用できる、と判断しないことが大切です。出典：XSLTEnabledポリシー仕様。
2．対象PCでXSLTEnabledを有効にする
組織でグループポリシーを使っている場合は、各ブラウザー用の管理用テンプレートにあるXSLTEnabledを有効にして配布します。Edgeでは「管理用テンプレート → Microsoft Edge」の項目です。項目がない場合は管理用テンプレートの対応状況を確認してください。
端末でレジストリを使う場合、Microsoftは管理者として開いたコマンドプロンプトで、次のコマンドを実行する方法を案内しています。既存の同名設定がある場合は上書きされるため、先に管理元と現在値を確認します。
Microsoft Edgeの場合
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v XSLTEnabled /t REG_DWORD /d 1 /fGoogle Chromeの場合
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v XSLTEnabled /t REG_DWORD /d 1 /f使うブラウザーのコマンドを選び、設定後にブラウザーを再起動します。ポリシー画面で反映を確認し、RD Web Accessを開き直してください。組織の配布設定と端末の個別設定が食い違う場合は、配布元を確認します。
3．画面が戻った後は、アプリの起動まで確認する
一覧が表示されることに加え、サインイン、必要なアプリの選択、リモート接続、業務開始まで確認しておきます。画面が戻っても接続に失敗する場合は、表示の問題と接続先側の問題を切り分けて調べます。
XSLTEnabledは恒久対策ではありません。ブラウザーのセキュリティ上の理由で廃止される機能を一時的に戻す設定です。対象端末・設定元・代替手段の準備期限を記録し、不要になったら元の設定へ戻す計画も残します。
代替の入口：HTML5 WebクライアントとEdgeのIEモード
HTML5 Webクライアントは、管理者側の準備が必要
Microsoftは代替策としてHTML5 Webクライアントを案内しています。これを使うには、管理者がWebクライアントを導入・公開している必要があります。従来のURLを書き換えるだけで、どの環境でも使えるわけではありません。
公開後のURLの形式は次のとおりです。server_FQDNは、組織が案内するサーバー名に置き換えます。
https://server_FQDN/RDWeb/webclient/index.htmlHTML5 Webクライアントではブラウザー内で接続する方法に加え、設定でRDPファイルのダウンロードを選ぶ方法も案内されています。既存クライアントを使う運用を続けたい場合は、この入口を利用できるか検討します。
導入時はRDSの構成、証明書、ライセンスなどの前提条件をMicrosoftのセットアップ手順で確認してください。特に公式手順はユーザー単位のCALを前提としており、デバイス単位のCALについて注意事項があります。
EdgeのIEモードも公式の一時回避策
Microsoftは、EdgeのIEモードでRD Webポータルを開く方法も一時回避策として挙げています。通常のEdgeで開き直すだけではなく、対象URLをIEモードで開く設定が必要です。
組織でIEモードの対象サイトを管理している場合は、管理者が設定を確認します。KB5130994には初回のActiveX許可に関する説明もあるため、利用者向け案内を作る際は、公式手順と組織の運用方針を合わせて確認してください。
更新前に管理者が確認しておきたいこと
- RD Web Accessを使う部署と、実際に利用しているURLを把握する。
- 利用ブラウザーのバージョン・更新チャネル・ポリシー設定を確認する。
- 業務に影響しない検証端末でXSLTを無効にし、画面への影響を確認する。
- 一時回避策を配布する対象と、設定の管理元を決める。
- HTML5 Webクライアントなどの代替方法で、アプリ起動まで検証する。
- ヘルプデスクへエラー文と代替の接続方法を共有する。
検証端末で意図的にXSLTを無効にする場合は、既存設定を控え、検証後に戻します。本番の全端末へいきなり無効化を配布すると、依存している別の業務サイトにも影響する可能性があります。
よくある疑問
リモートデスクトップ接続そのものも廃止される？
今回の告知は、RD Web Accessの画面表示がブラウザー内のXSLTに依存することに関するものです。RDPやリモートデスクトップサービス自体の廃止を告知する内容ではありません。ただし、入口が表示されないと、利用者は必要なアプリへ進めなくなる場合があります。
ChromeからEdgeへ変えれば解決する？
一時的に表示できる環境はあっても、EdgeもXSLTの既定無効化を予定しています。ブラウザー名を変えるだけで恒久的に解決すると考えず、バージョンとXSLTEnabledの設定を確認してください。
サーバーを更新すれば今すぐ直る？
確認時点のKB5130994には、この表示問題を解決する更新プログラムは掲載されていません。Microsoftの修正情報を確認しながら、一時回避と代替の入口を準備する必要があります。
今のうちに、業務アプリへ入る別の方法を用意する
RD Web Accessを使っている職場では、ブラウザーの更新予定と一緒に、利用者がアプリへ入る方法を点検しておくと対応しやすくなります。まずは対象のURLと利用端末を確認し、一時回避を使う期間と代替手段を決めてください。
本記事は公式資料に基づく解説です。実環境での再現や動作検証は行っていません。変更前には、組織の構成と適用中のポリシーを確認してください。
