依存の棚卸しをすると、たいてい「どれくらい使っているか」で表を並べます。よく使う機能は上に、ほとんど使っていない機能は下に。順序としては自然で、作業量の見積もりにも合っています。
ところが撤去の影響を決めるのは、頻度ではありません。代替のしやすさと、壊れ方の質です。この2つは使用率とは別の軸で、表を頻度で並べた時点で視界から外れます。
ChromeのXSLT撤去は、その食い違いが数字つきで見える題材です。Chrome for Developersの公式ページは、XSLTを使うページ読み込みが全体の約0.02%しかないと書いています。残りの99.98%には何も起きません。けれども、その0.02%にとってXSLTは装飾ではなく変換です。本記事では、この「頻度では測れない部分」をどう点検するかを扱います。XSLT 3.0の書き方そのものや、Chrome以外のブラウザの撤去日程は扱いません（後者は参照した公式ページに記載がありません）。
30秒で要点
- Stableで停止するのはChrome 158（2026年11月17日）。Origin TrialとEnterprise Policyの参加者以外の全利用者でXSLTが止まる。延命手段もChrome 176（2027年8月17日）で失効する
- 止まると表示が崩れるのではなく、変換されていない生のXMLが出る。劣化ではなく別物が出る
- 使用率の数字は2つある。XSLTを使うページ読み込みが約0.02%、XSLTの処理命令を使うものは0.001%未満。桁が1つ以上違うので、まとめて語れない
- 撤去理由として公式が挙げているのは使用率の低さではなく、攻撃面を維持するコスト。この基準では、利用が少ないことは撤去を遅らせる方向に働かない
- 消えるのはXSLT用の2つのAPIだけ。XMLにCSSを当てる使い方は残る
止まると「崩れる」のではなく、別物が出る
XSLTは、XMLをHTMLへ変換する仕組みです。サイトマップ、RSS、データ配信、社内の設定ファイルや帳票のビューアなど、機械向けのXMLを人が読める形に見せるために使われてきました。
ここが重要な点です。XSLTは見た目を整える層ではなく、出力そのものを作る層にあります。CSSが外れたページは、情報は残ったまま装飾が落ちます。XSLTが外れたXMLは、HTMLが生成されません。ブラウザはXMLをそのまま表示します。
利用者の画面に出るのは、崩れたページではありません。タグが並んだテキストです。「少し見づらくなる」と「別のものが出る」の間には、問い合わせ対応の量でも、信用の損ね方でも、はっきりした差があります。
壊れ方の質が違えば、優先順位も変わります。頻度の低い依存を下に並べた表は、この差を表現できません。
使用率の数字は2つあり、桁が違う
公式ページに載っている使用率は、1つではありません。
表が収まらない場合は、横にスクロールできます
| 対象 | ページ読み込みに占める割合 |
|---|---|
| XSLTを何らかの形で使っているもの | 約0.02% |
XSLTの処理命令（<?xml-stylesheet type="text/xsl" ... ?>）を使っているもの | 0.001%未満 |
分母はページ読み込み数で、サイト数ではありません。2つの数字は桁が1つ以上違います。つまり、XSLTの利用のうち処理命令経由はごく一部で、残りはXSLTProcessorをJavaScriptから呼ぶ使い方だということになります。
この区別は実務に効きます。自社が処理命令経由なら、XMLファイルの先頭1行を見れば判定できます。XSLTProcessor経由なら、判定はコードの検索になり、呼び出し箇所が実行時の条件分岐の中にあることもあります。同じ「XSLTを使っている」でも、点検の手間と見落としやすさが違います。
なお、この0.02%という数字の測定方法や対象期間は、公式ページに書かれていません。母集団が何なのかを確認できないまま「0.02%だから影響は小さい」と要約すると、確認していないことを結論にしてしまいます。公式ページ自身も、使用率を影響範囲の評価として提示してはいません。維持コストの話の材料として挙げているだけです。
「使う人が少ないから消えない」は向きが逆である
棚卸しの表を頻度で並べると、暗黙のうちにもう一つの仮定が入ります。よく使われている機能ほど守られ、使われていない機能は放置されるという仮定です。放置されるなら、急いで動かなくてよい。この読み方は、プロダクトの機能追加では多くの場合当たります。
撤去の判断基準では当たりません。公式ページが撤去理由として挙げているのは、XSLTの実装を抱え続けること自体がセキュリティ上のリスクだという点です。ページはXSLTの実装（libxslt）を、複雑で古いC/C++のコードベースだと説明し、バッファオーバーフローのようなメモリ安全性の問題を起こしやすく、任意コード実行につながりうるとしています。実例として CVE-2025-7425 と CVE-2022-22834 を挙げ、XSLTが近年の目立つ攻撃の発生源になっていると述べています。結論は、この壊れやすい旧機能を維持するリスクが、限られた現代的な有用性を大きく上回るという評価です。
この基準で読むと、利用が少ないことは撤去を遅らせる要素ではありません。守るべき利用者が少ないほど、維持コストとリスクを払い続ける理由が薄くなります。 「使っている人が少ないから急には消えない」という読みは、向きが逆になっているわけです。
ここは判断の提示として書いています。公式ページは「使用率が低いから早く消す」とは書いていません。書いているのは維持コストの評価であり、そこから利用の少なさが撤去を遅らせないという読みを導いているのは本記事の側です。
消えるのはXSLTの使い方だけで、XMLもCSSも残る
撤去の話は、範囲を広く取り違えられやすいところです。公式ページが撤去対象として挙げているのは、次の2つだけです。
XSLTProcessorクラス（たとえばnew XSLTProcessor()）- XSLTの処理命令（
<?xml-stylesheet type="text/xsl" ... ?>）
逆に、消えないものが2つ明記されています。
XMLにCSSを当てる処理命令は残ります。 公式ページは「XML + CSS は撤去されない」という見出しを立て、XSLT用のtype="text/xsl"の非推奨と、処理命令そのものを区別するよう求めています。<?xml-stylesheet ... ?>はCSSと組み合わせて使う限りサポートが続き、ページにはその例も載っています。処理命令という書き方が消えるのではなく、XSLTを指す使い方だけが消えます。
XML自体もブラウザから撤去されません。 同じページには、XMLの解析をlibxml2からRust製のメモリ安全な実装へ置き換える計画が別の節として書かれており、そこで「撤去を検討しているのはXSLTだけで、XMLをブラウザから取り除くわけではない」と明示されています。ただしRust化の時期はこのページに書かれていないため、いつ置き換わるかは分かりません。
「XMLの見せ方がすべて消える」と理解すると、本来触らなくてよいものまで移行対象に入ります。範囲の取り違えは、作業量を増やす方向にも間違えます。
自社が該当するかを確かめる最小の検索
撤去対象が2つのAPIに限られているので、点検は2回の検索で始められます。
- 配信しているXMLに、XSLTの処理命令があるか。 サイトマップ、RSS/Atomフィード、データ配信用のXML、社内ツールが出力するXMLを開き、先頭付近に
type="text/xsl"があるかを見る。type="text/css"は対象ではないので、ここを混同しない - コードに
XSLTProcessorがあるか。 リポジトリ全体をXSLTProcessorで検索する。動的に生成している場合はtransformToFragmentやimportStylesheetも合わせて探す - ヒットしたものを、配布側と利用側に分ける。 自社サイトで使っているのか、顧客サイトへ配っているウィジェットやテンプレートに含まれているのかで、直す範囲も連絡先も変わる
- 「どう壊れるか」を1行で書く。 「このXMLが生のまま表示される」まで書けていれば、優先順位を頻度ではなく壊れ方で付け直せる
2つとも0件なら、少なくとも検索できた範囲には依存がありません。この手順が有効なのは、推測ではなく文字列の有無で判定できる点です。ただし、撤去対象を2つのAPIに特定したのは公式ページですが、「この2つを検索すれば判定できる」という手順自体は、その特定から本記事が導いたものです。
延命は「移行しない選択」ではなく「時期を買う選択」
公式ページのタイムラインは、2段構えになっています。
表が収まらない場合は、横にスクロールできます
| 時点 | 起きること |
|---|---|
| Chrome 158（2026年11月17日） | Stableリリースで、Origin TrialとEnterprise Policyの参加者以外の全利用者でXSLTが停止する |
| Chrome 176（2027年8月17日） | Origin TrialとEnterprise Policyも失効し、全利用者でXSLTが無効になる |
この2段を見れば、延命手段の性格が分かります。Origin TrialもEnterprise Policyも、移行しない選択ではなく、移行の時期を買う選択です。期限は2027年8月17日で、買える長さは決まっています。延命を選ぶなら、その期限内に何をするかを同時に決めないと、同じ判断を9か月後にもう一度することになります。
移行先として公式ページが挙げているのは、次の5つです。
- XSLTの変換をサーバー側へ移し、HTMLを返す
- XML APIをJSONへ移し、JavaScriptでクライアント側で描画する
- SaxonicaのJavaScript実装を使う（XSLT 3.0以降に対応）
- WASMベースのpolyfillを使う。
XSLTProcessorクラスの代替を含み、XML文書にxslt-polyfill.min.jsを読み込む1行を足すだけで、処理命令経由の文書も変換できるとされている - polyfillを全ページに適用するChrome拡張を使う
このうち拡張については、読み方に注意が必要です。公式ページは、元のXMLやXSLTを変更できない用途向けだと位置づけており、XSLTが無効化されたときにChromeが拡張の検索ページへ誘導する警告バナーを出すようになったとも書いています。拡張は閲覧者側が入れるものなので、サイト運営者が自社の読者全員に適用できる解決策にはなりません。
RSS/Atomフィードを人が読める形に見せていた場合、公式ページは2つの道を示しています。1つは、HTML側に <link rel="alternate" type="application/rss+xml"> を置き、利用者に見えるXMLへの直接リンクを置かない方法です。公式はこれを標準的なHTMLのやり方とし、HTMLは人向け、XMLは機械向けという通常のWebの分け方に沿うと説明しています。それで足りない場合はpolyfillの道があるとされています。ただしこれはChromeの推奨であり、RSSリーダー各社の挙動を保証するものではありません。
なお、ここまでのタイムラインはChromeの予定であり、実績ではありません。参照した公式ページの表示は2025年10月29日公開です。判断する時点で日付と版数が変わっていないかは、同じページを開いて確認してください。Chrome Platform StatusのエントリはDeprecate and remove XSLTです。FirefoxとWebKitも撤去の方針を示しているとこのページは述べていますが、両者の日程は書かれていないため、本記事では扱いません。
判断の土台として押さえておくこと
- 撤去の影響を決めるのは頻度ではなく、代替のしやすさと壊れ方の質である。棚卸しの表を使用率で並べると、この2つが視界から外れる
- XSLTが止まると、ページが崩れるのではなく生のXMLが出る。劣化ではなく別物が出る
- 使用率の数字は0.02%と0.001%未満の2つがあり、桁が違う。測定方法と期間は公式ページに書かれていない
- 撤去の判断基準は攻撃面の維持コストである。この基準では、利用が少ないことは撤去を遅らせない
- 消えるのはXSLT用の2つのAPIだけで、XMLにCSSを当てる使い方とXML自体は残る
- 延命は期限つきで、2027年8月17日に失効する。時期を買う選択として扱う
依存の棚卸しを頻度ではなく壊れ方で並べ替える作業は、XSLTだけで終わりません。どこから手を付けるかを言語化するところから始めることができます。
状況を整理する（15分）より深く学ぶ
- 外部スクリプトの棚卸しは、依存関係スキャンでは終わらない：棚卸しの単位を、出荷物と実行時のコードに分ける
- Chromeが2週間ごとに更新される時代｜「速くなった」ではなく前提が変わった：版数と日付を、確認の習慣として扱う
参考資料・引用元
- Chrome for Developers, Deprecating XSLT（表示上の公開日 2025年10月29日、著者 Mason Freed / Dominik Röttsches）. https://developer.chrome.com/docs/web-platform/deprecating-xslt （2026年10月14日確認）
- Chrome Platform Status, Deprecate and remove XSLT. https://chromestatus.com/feature/4709671889534976 （2026年10月14日確認）