Microsoft developer platformのPrompty関連リポジトリで見つかった「fast-xml-parser 5.5.9から5.7.1への更新」は、すべての利用者が急いで設定変更すべき大規模アップデートではありません。まず確認すべき結論は、Promptyをフォークしている開発者、@prompty/coreやVS Code向けPrompty拡張をビルドしているチーム、XMLパース結果をテストで厳密に比較しているチームは、依存関係とテスト結果を確認すべきという点です。
この更新は、Microsoftのmicrosoft/promptyリポジトリにおけるDependabot由来のPRで、対象は/vscode/prompty/packages/core配下のfast-xml-parserです。PR自体は2026年5月5日に「fast-xml-parserはすでに最新のため不要」としてクローズされていますが、上流のfast-xml-parserではエンティティ処理、CDATA・コメントのサニタイズ、型定義まわりに変更が入っているため、Prompty周辺を自社開発に組み込んでいる場合は無視しない方が安全です。(GitHub)
Microsoft developer platformのPrompty更新で何が起きたのか
今回の「Microsoft developer platform documentation update: chore(deps): Bump fast-xml-parser from 5.5.9 to 5.7.1 in /vscode/prompty/packages/core」は、機能追加というより依存関係の更新通知です。
GitHub上のPR #361では、Dependabotがfast-xml-parserを5.5.9から5.7.1へ上げる変更を提案していました。対象ブランチはmain、変更ファイルはvscode/prompty/packages/core/package-lock.jsonで、依存関係の種類はindirect、つまり直接依存ではなく推移的依存として扱われています。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 対象リポジトリ | microsoft/prompty |
| 対象パス | /vscode/prompty/packages/core |
| 更新対象 | fast-xml-parser |
| 更新内容 | 5.5.9から5.7.1への更新提案 |
| 変更ファイル | package-lock.json |
| PRの状態 | 2026年5月5日にクローズ |
| 実務上の見方 | 既存環境で依存関係が最新化済みか、テストが通るかを確認する案件 |
重要なのは、PRがクローズされたからといって「関係ない」と判断しないことです。Dependabotが対象PRを不要と判断した理由は、リポジトリ側で依存関係がすでに最新状態になっていた可能性を示すものであり、あなたのフォーク、社内ミラー、古いlockfile、CI環境まで自動的に安全だと保証するものではありません。
Prompty利用者が知っておきたい影響範囲
Promptyは、LLM向けプロンプトを.promptyファイルとして作成・管理・実行するためのフォーマットおよびツール群です。Microsoftのリポジトリ説明では、VS Code、Python、TypeScriptからプロンプトを実行できる仕組みとして紹介されています。(GitHub)
そのため、今回の更新で確認対象になるのは、主に次のような利用者です。
| 利用状況 | 対応の必要性 | 確認ポイント |
|---|---|---|
| Promptyを通常利用しているだけ | 低 | 利用中の拡張機能やパッケージが更新済みなら大きな対応は不要 |
microsoft/promptyをフォークしている | 高 | lockfile、CI、依存関係の解決結果を確認 |
/vscode/prompty/packages/coreをビルドしている | 高 | npm install後の依存バージョンとテスト結果を確認 |
@prompty/coreをTypeScriptアプリに組み込んでいる | 中〜高 | 推移的依存としてfast-xml-parserが入っているか確認 |
| XMLを含む外部データ、設定、レスポンスを処理している | 高 | エンティティ、CDATA、コメント、エラー文言の差分を重点確認 |
| エラーメッセージをスナップショットテストしている | 高 | エンティティ関連のエラー文言変更に注意 |
Prompty自体はLLMプロンプト管理のためのツールですが、TypeScriptランタイムやVS Code拡張のビルドでは複数のnpm依存関係が関わります。今回のような推移的依存の更新は、アプリの画面やAPI仕様に直接現れなくても、パース処理、型チェック、テストスナップショット、CIの再現性に影響することがあります。
fast-xml-parser 5.5.9から5.7.1で見るべき変更点
fast-xml-parser側の変更を追うと、今回の確認ポイントは単なるパッチ更新より少し広めです。5.7.1自体ではCJS型定義ファイルのtypo修正が記載されていますが、5.5.9から5.7.1へ上げる場合、その間の5.6.0や5.7.0の変更も含めて確認する必要があります。(GitHub)
エンティティ処理が変わっている
5.7.0では、エンティティ処理に@nodable/entities v2.1.0を使う変更が入っています。リリース情報では、エンティティ値を使って別のエンティティ名を形成できないこと、数値外部エンティティを追加できないこと、エンティティ展開制限を超えた場合のエラーメッセージが変わる可能性があることが示されています。(GitHub)
実務では、次のようなテストが影響を受けやすいです。
- XML内の
&、&#xNN;、独自エンティティを処理しているテスト - エンティティ展開エラーのメッセージを完全一致で検証しているテスト
- XMLパーサーの例外メッセージをログ監視やアラート条件に使っている処理
- 外部入力のXMLをPrompty関連のワークフローに取り込む処理
特に、エラー文言に依存したテストは失敗しやすいポイントです。エラーの意味が同じでも、文言が変わるとスナップショットテストや文字列比較は落ちます。テストでは「完全一致」ではなく、必要なエラー種別やステータスを確認する方式に寄せると保守しやすくなります。
processEntitiesの設定で性能影響が変わる
リリース情報では、processEntitiesがfalseの場合は性能影響がない想定、processEntitiesがtrueでエンティティデコーダーを別途渡していない場合は約8〜10%の性能低下があり得るとされています。一方で、エンティティが存在するケースでは過去バージョンより改善する可能性も示されています。(GitHub)
つまり、性能確認では「小さなXMLを1件だけパースする」ようなテストでは不十分です。実運用に近いXMLサイズ、エンティティの有無、同時処理数で見る必要があります。
| XMLの使い方 | 確認方法 |
|---|---|
| エンティティを使わない | 通常の回帰テストで十分な場合が多い |
| エンティティを含む | パース結果と処理時間を更新前後で比較 |
| 大きなXMLを処理する | CIだけでなくローカルまたは検証環境でベンチマーク |
| エラー文言を参照している | エラーメッセージ完全一致のテストを見直す |
| 外部入力を処理する | 不正なCDATA、コメント、深いネストを含むケースを追加 |
CDATAとコメントのサニタイズにも注意する
5.7.0では、fast-xml-builder側で悪意あるCDATAやコメント内容をサニタイズする更新も含まれています。これは安全性の観点では歓迎すべき変更ですが、XML出力を文字列としてスナップショット保存している場合は差分が出る可能性があります。(GitHub)
たとえば、テストで以下のような比較をしている場合は注意が必要です。
expect(xmlOutput).toEqual(expectedXmlString);この形式では、サニタイズ後の出力やコメントの扱いが少し変わるだけでテストが失敗します。実務では、XML文字列の完全一致だけでなく、パース後の構造、必要な属性、必要なテキストノードを検証するテストに分けると、依存関係更新に強くなります。
今回すぐ確認すべきコマンド
Promptyをフォークしている、または/vscode/prompty/packages/coreをビルドしている場合は、まず依存関係の実体を確認します。
cd vscode/prompty/packages/core
npm ls fast-xml-parser
npm explain fast-xml-parsernpm lsでは実際に解決されたバージョンを確認できます。npm explainでは、どのパッケージ経由でfast-xml-parserが入っているかを確認できます。今回のPRではfast-xml-parserは推移的依存として扱われているため、package.jsonだけを見ても判断できない場合があります。(GitHub)
次に、lockfileを再生成して差分を確認します。
npm install
git diff -- package-lock.json古いlockfileが残っている場合は、更新差分が出るはずです。差分が出ない場合でも、CI環境のNode.js/npmバージョンやキャッシュの影響で異なる解決結果になることがあるため、CI上のnpm ciも確認してください。
npm ci
npm test
npm run buildnpm testやnpm run buildは、リポジトリやパッケージの実際のスクリプトに合わせて実行してください。スクリプトが存在しない場合は、TypeScriptの型チェック、ユニットテスト、VS Code拡張のビルドに相当する処理を実行します。
移行時に重点確認するチェックリスト
今回の更新は、アプリケーションコードを大きく書き換えるタイプではありません。ただし、推移的依存の変更は「普段見ないところ」で失敗しやすいため、次の順番で確認すると効率的です。
| 順番 | 確認項目 | 見るべき結果 |
| -: | —————————– | ————————— |
| 1 | npm ls fast-xml-parser | 解決バージョンが古いまま残っていないか |
| 2 | npm explain fast-xml-parser | どの依存経路で入っているか |
| 3 | package-lock.jsonの差分 | 予期しない大量更新が混ざっていないか |
| 4 | XML関連テスト | エンティティ、CDATA、コメント、属性の差分がないか |
| 5 | 型チェック | CJS/ESMまわりの型エラーが出ないか |
| 6 | スナップショットテスト | エラー文言やXML出力の完全一致で落ちていないか |
| 7 | CI | npm ciで再現性があるか |
特に見落としやすいのは、package-lock.jsonだけの変更を「安全な自動更新」として即マージしてしまうケースです。Dependabotの依存関係更新は便利ですが、XMLパーサーのように入力データの解釈に関わるライブラリでは、最低限の回帰テストを通してから取り込むべきです。
対応が必要なケース、不要なケース
今回のPRは2026年5月5日にクローズされており、Dependabotは「fast-xml-parserが最新のため不要」とコメントしています。つまり、Microsoft側の対象リポジトリでは、同じPRをそのまま追いかける必要がなくなった可能性があります。(GitHub)
ただし、社内で利用しているコードベースは別です。以下の基準で判断するとよいでしょう。
対応不要と判断しやすいケース
- Promptyを単に利用しているだけで、ソースからビルドしていない
- VS Code拡張やnpmパッケージを通常の更新経路で使っている
- 自社プロジェクトに
fast-xml-parserが入っていない npm ls fast-xml-parserで該当依存が確認できない- XML処理をPrompty関連ワークフローで使っていない
確認または対応すべきケース
microsoft/promptyをフォークしている- 古い
package-lock.jsonを社内で固定している - PromptyのTypeScript runtimeをアプリに組み込んでいる
- XML、HTML、CDATA、コメントを含むデータを処理している
- エンティティ展開エラーの文言をテストやログ監視で使っている
- CIで
npm ciが突然失敗した、またはlockfile差分が出ている
5.7.1だけを固定すべきか
今回のPR名は5.5.9から5.7.1への更新ですが、上流のfast-xml-parserではその後のバージョンも出ています。たとえば5.7.2では、数値外部エンティティの後方互換対応やattributesGroupName、長いタグ式でのstackoverflow修正が記載されています。(GitHub)
そのため、社内で対応する場合は「PR名にあるから5.7.1へ固定する」と機械的に決めない方がよいです。依存関係ポリシーに応じて、次のどちらかを選びます。
| 方針 | 向いているケース |
|---|---|
5.7.1相当までの差分だけ確認する | Microsoft側PRとの差分を最小限にしたい |
| より新しいパッチ版まで確認する | 既知の後続修正も取り込みたい |
| lockfileを現行mainに合わせる | PromptyのフォークをMicrosoft側に追随させたい |
| 一時的に固定して段階更新する | XML処理の互換性リスクを慎重に見たい |
実務では、まず現在のlockfileで何が解決されているかを見てから判断します。すでに5.7.2以降が入っているなら、5.7.1への個別PRを作る必要はありません。逆に5.5.9以前が残っているなら、更新差分を切り出してテストする価値があります。
失敗しやすいポイント
package.jsonだけを見て判断する
今回のPRでは、更新対象は推移的依存です。package.jsonにfast-xml-parserが直接書かれていないからといって、影響がないとは限りません。必ずpackage-lock.json、npm ls、npm explainで実際の依存ツリーを確認してください。
エラー文言の変化を軽視する
リリース情報では、エンティティ関連のエラーメッセージが変わる可能性が示されています。これは小さな変更に見えますが、スナップショットテスト、ログ監視、例外メッセージを使った分岐処理には影響します。(GitHub)
エラー処理では、文字列の完全一致ではなく、例外の種類、戻り値、処理結果、ログの分類など、変わりにくい情報を基準にするのが安全です。
性能確認を通常ケースだけで済ませる
processEntitiesがtrueのケースでは、設定やデコーダーの渡し方によって性能影響が変わります。小さなXMLだけで問題がなくても、大量データやエンティティを含むデータでは違いが出ることがあります。(GitHub)
パフォーマンスを見るなら、実運用に近い入力を用意し、更新前後で処理時間、メモリ使用量、失敗率を比較してください。
Prompty開発・運用チームの次のアクション
PromptyやMicrosoft developer platform関連の開発環境で今回の更新を見かけたら、次の順に進めるのが現実的です。
- 対象プロジェクトで
npm ls fast-xml-parserを実行する npm explain fast-xml-parserで依存経路を確認するpackage-lock.jsonの差分がある場合は、XML関連のテストを重点的に走らせる- エンティティ、CDATA、コメント、長いタグ式を含むケースを追加で確認する
- 問題がなければ、lockfile更新を通常の依存関係更新として記録する
- 問題が出た場合は、テストの完全一致条件やエラー文言依存を見直す
今回のポイントは、PRがクローズされているかどうかよりも、自分の環境でどのバージョンが解決され、どの入力データに影響するかです。Promptyをソースから扱っているチームは、依存関係の状態を確認し、XMLパースまわりの回帰テストを一度通しておくと、後続の更新にも対応しやすくなります。
コメント