Edge 147のRustベースXMLパーサー移行とは？影響範囲と確認ポイント

Edge 147 の「Rust ベース XML パーサー」変更で、最初に押さえるべき結論はシンプルです。Microsoft は 2026年4月10日付の Stable Channel リリースノートで Edge 147.0.3912.60 を案内し、Microsoft Edge Web プラットフォームの 147 リリースでは、XSLT を必要としない XML 解析を Rust ベースの XML パーサーに切り替えると明記しました。対象は DOMParser、XMLHttpRequest.responseXML、SVG ドキュメントで、狙いは XML 解析におけるメモリ破壊系バグの排除によるセキュリティ強化です。 (Microsoft Learn)

つまり、多くの一般的なWebサイトでは大規模改修が直ちに必要になるわけではありません。一方で、XML を扱う業務アプリ、SVG をドキュメントとして使う仕組み、XSLT に依存した古い実装は Edge 147 で回帰テストを前倒しすべきです。しかも v147 では inline XSLT を使って XML から SVG を生成する機能の削除も案内されているため、単なる内部実装の差し替えと見て済ませないほうが安全です。 (Microsoft Learn)

Edge 147 で実際に変わること

今回のポイントは、新しい XML API が増えたことではなく、既存の XML 経路の内部実装が変わることです。Microsoft の説明はあくまで「XSLT を必要としないシナリオ」が対象で、すべての XML 処理が一律に Rust 化されるとまでは書いていません。実務上は、XSLT 依存の経路は別枠で扱い、それ以外の主要な XML 解析面をより安全な実装へ寄せた変更と理解するのが自然です。 (Microsoft Learn)

公式に対象とされている3つの経路

• DOMParser: JavaScript から XML 文字列を解析する経路です。 (Microsoft Learn)
• XMLHttpRequest.responseXML: XMLHttpRequest のレスポンスをブラウザーが XML として扱う経路です。 (Microsoft Learn)
• SVG ドキュメント: SVG を XML ドキュメントとして処理する経路です。 (Microsoft Learn)

逆にいえば、Fetch API で JSON を取得しているだけの画面は、今回の変更の中心ではありません。ただし、最終的に DOMParser で XML を組み立てているなら、実務上は影響対象として見ておくのが無難です。 (Microsoft Learn)

Rust ベース XML パーサー移行が重要な理由

Microsoft が今回強調しているのは、パフォーマンスではなくセキュリティです。Web Platform リリースノートでは、Rust ベースの XML パーサーにより XML 解析のメモリ破壊系バグを排除すると説明しています。また、Rust 公式ドキュメントでも ownership によってガベージコレクタなしでメモリ安全性を保証できると説明されています。ブラウザーの XML パーサーのような低レベル処理を Rust に寄せるのは、その設計上の強みをセキュリティ改善に使う流れとして理解しやすい変更です。 (Microsoft Learn)

もちろん、Rust 化したから XML 関連の不具合がゼロになるわけではありません。仕様解釈、互換性、アプリ側の前提ミスは別問題です。ただ、ブラウザーコアの処理でメモリ破壊系のリスクを減らす方向が明示された意味は大きく、特に企業内の古い XML ワークフローを抱える環境ほど無視しにくい変更です。 (Microsoft Learn)

影響が出やすいケース

公式に挙がっている対象と v147 の互換性変更をもとに、実務上の優先度を整理すると次のようになります。 (Microsoft Learn)

利用パターン	影響の出やすさ	先に確認したいこと
通常のHTML/JSON中心サイト	低	SVGや古いXML機能が紛れ込んでいないか
DOMParser で XML を読む画面	中〜高	不正XML時の挙動、名前空間、既存テストの期待値
XMLHttpRequest.responseXML 依存	高	レスポンスヘッダー、文字コード、解析失敗時の処理
SVGをドキュメントとして扱う機能	高	表示崩れ、読み込み失敗、生成フロー
XSLTや <?xml-stylesheet ...?> を使う旧実装	非常に高	Edge 147 互換性、代替案、暫定ポリシーの要否

XSLT を使っているなら、今回の本丸はここ

XSLT 依存がある場合は、「Rust ベース XML パーサーに変わった」というニュースだけで判断しないことが重要です。Microsoft は Edge 147 の Web Platform リリースノートで、inline XSLT を使って XML データを SVG に変換する機能の削除を案内しています。さらに Stable Channel リリースノートでは XSLTEnabled が新規ポリシーとして追加され、専用ドキュメントではこのポリシーが XSLTProcessor JavaScript API と XSL processing instruction の可用性を制御し、しかも一時的で将来のバージョンで削除予定と明記されています。つまり、XSLT を使う環境では「暫定的に逃がす仕組みはあるが、長期運用の前提にはしないほうがよい」という理解が実務向きです。 (Microsoft Learn)

これは単発ではなく、XML 周辺を安全側へ寄せる流れ

Microsoft Edge のサイト互換性影響一覧を見ると、v147 では inline XSLT for SVG の削除が明記され、v144 では外部 XML entities / DTD の同期取得の削除も案内されています。今回の Edge 147 だけを個別対応するより、XML と XSLT を前提にした古い設計をまとめて棚卸しするほうが、次の変更にも強くなります。 (Microsoft Learn)

今すぐ確認したいチェックリスト

まずは「自分のシステムが XML を使っているかどうか」を感覚で判断しないことが大切です。フロントエンドの JavaScript だけでなく、サーバー生成の XML、SVG テンプレート、帳票、社内ポータルの古い部品まで含めて確認します。

確認項目	具体的に見る点	失敗しやすいポイント
コード検索	DOMParser、responseXML、XSLTProcessor、xml-stylesheet、.xsl、.xslt、.svg	フロント側だけ見て、テンプレートやサーバー出力を見落とす
通信確認	XML エンドポイントの Content-Type、文字コード、壊れた XML を返した場合の挙動	正常系だけ見て異常系を試さない
画面確認	SVG 表示、社内ダッシュボード、帳票プレビュー	単体画面だけ見て印刷やエクスポートを試さない
運用確認	管理ポリシーの要否、利用部門への影響	暫定回避を恒久運用にしてしまう

まずは横断検索から始める

rg "DOMParser|responseXML|XSLTProcessor|xml-stylesheet|\.xsl|\.xslt|\.svg" .

この検索で何も出なければ安心材料になりますし、1件でもヒットしたら Edge 147 での動作確認対象として管理表に起こすのが早いです。とくに <?xml-stylesheet ...?> は JavaScript から見えない場所に埋もれていることがあるので、テンプレートや生成物まで追うのがコツです。 (Microsoft Learn)

DOMParser を使うなら、正常系と異常系を両方見る

const xml = `<feed xmlns="urn:sample"><item id="1">ok</item></feed>`;
const doc = new DOMParser().parseFromString(xml, "application/xml");

console.assert(doc.documentElement.localName === "feed");
console.assert(doc.documentElement.namespaceURI === "urn:sample");
console.assert(doc.getElementsByTagNameNS("urn:sample", "item").length === 1);

テストでは「読めるかどうか」だけで終えず、名前空間、必須ノード数、属性値、壊れた XML を渡したときのエラー処理まで確認します。Edge 147 の変更は内部パーサーの差し替えなので、境界条件ほど差が出やすいからです。 (Microsoft Learn)

responseXML 依存は失敗時の処理まで見直す

const xhr = new XMLHttpRequest();
xhr.open("GET", "/feed.xml");

xhr.onload = () => {
  const xmlDoc = xhr.responseXML;
  if (!xmlDoc) {
    console.error("XML として解釈できませんでした");
    return;
  }

  console.log(xmlDoc.documentElement.localName);
};

xhr.send();

既存コードが responseXML を当然のように使っているなら、失敗時のハンドリングや、サーバーが返す Content-Type とエンコーディングをこの機会に見直す価値があります。業務アプリでは「たまたま今まで動いていた」実装が残っていることが珍しくありません。 (Microsoft Learn)

管理者が押さえるべき運用ポイント

情シスやブラウザー管理者の視点では、Edge 147 で XSLTEnabled が追加された点は見逃せません。Stable Channel リリースノートでは新規ポリシーとして案内され、専用ドキュメントでは Windows と macOS の Edge 147 以降でサポートされること、XSLT を強制的に有効または無効にできることが示されています。ただし同じドキュメントで一時的なポリシーとされているため、互換性検証や移行期間のための緩衝材として使い、本命は XSLT 依存の縮小に置くのが安全です。 (Microsoft Learn)

Edge 147 をきっかけに見直したい設計

今回の変更を「Rust 採用で安全になった」で終わらせるのはもったいありません。実務上の本質は、Edge が XML 周辺の古い経路を少しずつ整理し、安全側に寄せていることです。新規開発で選べるなら、クライアント側 XSLT に依存する設計は避け、XML が必要でも変換はビルド時やサーバー側で済ませるほうが、ブラウザー差分を吸収しやすくなります。v147 の inline XSLT for SVG 削除は、その方向性をかなり分かりやすく示しています。 (Microsoft Learn)

どうしても XML を使うなら、ブラウザー任せの暗黙的な解析に頼り切るより、入力バリデーション、テストデータの固定化、異常系テストの自動化を先に整えるほうが結果的に強いです。Edge 147 の変更は、古い XML 実装を「動いているから放置」から「仕様どおりに管理する」へ切り替える良いきっかけになります。

まとめ

Edge 147 は、非 XSLT シナリオの XML 解析で Rust ベースの XML パーサーを使うようになり、対象は DOMParser、XMLHttpRequest.responseXML、SVG ドキュメントです。Microsoft はその目的を XML 解析のメモリ破壊系バグの排除によるセキュリティ改善と説明しており、同じ v147 で inline XSLT for SVG の削除と XSLTEnabled ポリシーの追加も案内しています。 (Microsoft Learn)

次にやることは明確です。まず DOMParser、responseXML、XSLTProcessor、xml-stylesheet の利用を棚卸しし、次に Edge 147 で正常系と異常系の回帰テストを行い、最後に XSLT 依存が見つかったら暫定ポリシーに頼り切らず代替設計まで決めることです。今回の Edge 147 は、XML を使うシステムにとって「いつかやる見直し」を前倒しする合図だと捉えると動きやすくなります。 (Microsoft Learn)