VSTestのNewtonsoft.Json依存削除とは?.NET 11とVisual Studio 18.8で影響を受ける人と対処法

Microsoftが2026年4月29日に公開した「VSTest is Removing its Newtonsoft.Json Dependency」は、.NET 11 Preview 4とVisual Studio 18.8に向けて、VSTestがNewtonsoft.Jsonへの依存を外すという更新です。結論から言うと、多くのテストプロジェクトでは対応不要です。ただし、VSTestに同梱されていたNewtonsoft.Jsonを暗黙的に使っていたプロジェクトでは、ビルドエラーやFileNotFoundExceptionが発生する可能性があります。対象になりやすいのは、JObjectやJsonConvertを使っているのにPackageReferenceを追加していないテストコード、ExcludeAssets="runtime"で実行時アセットを除外しているプロジェクト、テストアダプターやデータコレクターを開発しているチームです。(Microsoft for Developers)

目次

VSTestのNewtonsoft.Json依存削除で何が変わるのか

VSTestは、dotnet testやVisual StudioのTest Explorerを支えるテストプラットフォームです。今回の変更では、VSTestが長年持っていたNewtonsoft.Json依存を削除し、.NETではSystem.Text.Json、.NET FrameworkではJSONiteを使う方針に変わります。対象として示されているのは、.NET 11 Preview 4とVisual Studio 18.8です。(Microsoft for Developers)

重要なのは、これは「アプリケーションでNewtonsoft.Jsonを使えなくなる」という話ではないことです。自分のプロジェクトがNewtonsoft.Jsonを必要としているなら、これまで通り明示的にNuGetパッケージとして参照できます。変わるのは、VSTestがたまたま持ち込んでいたNewtonsoft.Jsonに依存できなくなるという点です。

Microsoftはこの変更を、保守性とセキュリティのための更新と説明しています。公式ブログでは、Newtonsoft.Json 13.0.0未満のバージョンがNuGet.org上で脆弱性ありとして扱われていること、不要になった依存関係をテストプラットフォーム側で持ち続けると将来のアドバイザリの影響を受けやすくなることが理由として挙げられています。(Microsoft for Developers)

まず確認すべき影響範囲

今回の変更で影響を受けるかどうかは、「プロジェクトがNewtonsoft.Jsonを使っているか」ではなく、Newtonsoft.Jsonを自分で明示的に参照しているかで判断すると分かりやすくなります。

プロジェクトの状態影響対応
Newtonsoft.Jsonを使っていないほぼ影響なし原則対応不要
Newtonsoft.Jsonを通常のPackageReferenceで参照している影響は小さいテスト実行だけ確認
JObjectやJsonConvertを使っているがPackageReferenceがない影響ありNewtonsoft.Jsonを追加
ExcludeAssetsでruntimeを除外している影響ありruntime除外をやめる、または参照方法を見直す
独自のテストアダプター、データコレクターがNewtonsoft.Jsonを使う影響の可能性あり拡張側で依存関係を宣言、または移行
VSTestの通信APIを直接扱う拡張を開発している影響の可能性ありJToken依存の有無を確認

通常のxUnit、NUnit、MSTestのテストプロジェクトで、Newtonsoft.Jsonを使っていない場合は、慌てて何かを追加する必要はありません。公式ブログでも、ほとんどのプロジェクトは対応不要とされています。(Microsoft for Developers)

影響を受けやすい典型パターンと修正方法

ビルド時にNewtonsoft.Jsonの参照不足で失敗する

テストコード内で次のような型やメソッドを使っている場合は注意が必要です。

using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

var json = JsonConvert.SerializeObject(value);
var obj = JObject.Parse(json);

これまでは、VSTestやMicrosoft.NET.Test.Sdk経由でNewtonsoft.Jsonがビルド時に見えていたため、明示的なPackageReferenceがなくてもコンパイルできていたケースがあります。更新後はその暗黙的な参照がなくなるため、コンパイルエラーになります。Microsoftの破壊的変更トラッキングでも、以前はNewtonsoft.Json.dllが出力フォルダーに存在し、プロジェクトによってはそれを拾えていたが、新しい挙動ではコンパイル時・実行時に利用できなくなると説明されています。(GitHub)

修正はシンプルです。テストプロジェクトの.csprojに、Newtonsoft.Jsonを明示的に追加します。

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>

公式ブログの例では13.0.3が示されていますが、実務では自社の依存関係管理ルールに合わせてバージョンを決めてください。Central Package Managementを使っている場合は、個別の.csprojではなくDirectory.Packages.propsでバージョンを管理する方が安全です。NuGetのパッケージページでは、利用可能なバージョンが更新されることがあるため、固定する前に組織の検証済みバージョンを確認しましょう。(NuGet)

実行時にFileNotFoundExceptionが出る

ビルドは通るのに、テスト実行時に次のようなエラーが出るケースもあります。

System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json'

特に注意したいのが、次のようにruntimeアセットを除外しているプロジェクトです。

<PackageReference Include="Newtonsoft.Json" Version="13.0.3">
  <ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>

この設定では、コンパイル時にはNewtonsoft.Jsonを使えても、テスト実行時にDLLが出力されないことがあります。以前はVSTest側のコピーに依存して動いていた場合でも、更新後はVSTestがNewtonsoft.Jsonを持たないため失敗します。公式ブログでは、この場合は<ExcludeAssets>runtime</ExcludeAssets>を削除するか、runtimeアセットを除外しない形でNewtonsoft.Jsonをインストールするよう案内されています。(Microsoft for Developers)

修正例は次の通りです。

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>

失敗しやすいのは、CIでは落ちるがローカルでは通るケースです。ローカル環境に古い出力ファイルが残っていたり、Visual Studioのキャッシュで一時的に動いているように見えたりすることがあります。修正後は、binとobjを削除してから再ビルドし、CIと同じコマンドで確認するのが確実です。

dotnet clean
dotnet test

テストアダプターやデータコレクターが読み込めない

独自のテストアダプター、データコレクター、VSTest拡張を開発しているチームは、アプリケーション開発者よりも注意が必要です。拡張側でNewtonsoft.Jsonを使っているのに依存関係として宣言していない場合、拡張のロード時にFileNotFoundExceptionが発生する可能性があります。公式ブログでは、エラーには対象の拡張名が表示されるため、どのアダプターやデータコレクターを更新すべきか分かると説明されています。(Microsoft for Developers)

利用者側でできる現実的な対応は、次の3つです。

  • 拡張の最新版が出ていないか確認する
  • 一時的にテストプロジェクトへNewtonsoft.Jsonを追加する
  • 問題のある拡張を無効化し、更新を待つ

拡張の開発者側では、Newtonsoft.Jsonを使い続けるなら自分のパッケージで明示的に依存関係を宣言する必要があります。長期的には、VSTest本体と同じくSystem.Text.Jsonへの移行を検討すると、依存関係の管理が簡単になります。

変わらない点も押さえておく

今回の更新は破壊的変更として扱われますが、すべてが大きく変わるわけではありません。Microsoftは、VSTestのワイヤーフォーマットは変わらず、Newtonsoft.Json、System.Text.Json、JSONiteのどれを使ってもメッセージは同じようにシリアライズされると説明しています。また、古いtesthostと更新後のプラットフォームの互換性も維持され、シリアライズ性能は同等または改善されるとされています。(Microsoft for Developers)

実務上の意味は、テスト結果のJSON構造やTRXの扱いを前提にした通常のCI運用では、大規模な作り直しは不要ということです。問題が起きるとすれば、Newtonsoft.JsonのDLLが「どこかから来るはず」と期待していた部分です。

公開APIの変更に注意が必要な人

VSTestの通信プロトコルに直接関わるコードを書いている場合は、公開APIの変更も確認してください。公式ブログでは、VSTestが通信APIの一部で公開していたNewtonsoft.Json.Linq.JTokenが削除されると説明されています。実利用者は多くないとされていますが、テストアダプターや独自ツールを開発している場合は見逃せません。(Microsoft for Developers)

GitHub上のPRでは、JSONシリアライズを.NET Core側ではSystem.Text.Jsonへ、.NET Frameworkやnetstandard2.0側ではJsoniteへ移行し、プロダクションコードのNewtonsoft.Json依存を削除したことが説明されています。また、Message.PayloadからRawMessage中心の設計への変更など、VSTest内部や拡張開発者に関係する変更点も示されています。(GitHub)

一般的なテストコードを書いているだけなら、このAPI変更を意識する場面はほとんどありません。一方で、VSTestのメッセージを直接扱うツールを持っている場合は、Preview段階でビルドと実行確認を済ませておくべきです。

いつから影響が出るのか

Microsoftが公式ブログで示した予定では、.NET 11 Preview 4は2026年5月12日、Visual Studio 18.8 Insiders 1は2026年6月9日に予定されています。2026年5月時点では、これらは将来のプレビュー/Insiders向けリリースとして扱うのが適切です。(Microsoft for Developers)

対象予定日確認すべきこと
.NET 11 Preview 42026年5月12日dotnet test、Microsoft.NET.Test.Sdk更新後のテスト結果
Visual Studio 18.8 Insiders 12026年6月9日Test Explorerでの実行、拡張・アダプターの読み込み
CI環境SDK更新時TRX、Azure DevOps、GitHub Actionsのテスト表示

特に管理者は、開発者のローカル環境より先にCI環境のSDKやVisual Studio Build Toolsが更新されるケースに注意してください。ビルドエージェントのイメージ更新、Hosted runnerの更新、コンテナイメージのベースタグ変更によって、先にCIだけ失敗する可能性があります。

開発チーム向けの確認手順

更新前にやるべきことは、すべてのプロジェクトにNewtonsoft.Jsonを追加することではありません。まず、どのプロジェクトが暗黙依存しているかを洗い出します。

手順確認内容判断基準
1テストプロジェクトでNewtonsoft.Jsonを検索JsonConvert、JObject、JTokenがあれば要確認
2.csprojを確認PackageReference Include="Newtonsoft.Json"があるか
3ExcludeAssetsを確認runtimeを除外していないか
4独自アダプター・データコレクターを確認拡張側で依存関係を宣言しているか
5Preview環境でdotnet testを実行ビルドエラー、実行時エラー、TRX出力を確認
6CIで再現確認GitHub ActionsやAzure DevOpsで同じ結果になるか

Windows環境なら、PowerShellで次のように検索できます。

Select-String -Path .\**\*.cs,.\**\*.csproj -Pattern "Newtonsoft.Json","JsonConvert","JObject","JToken"

macOSやLinuxなら、次のように確認できます。

grep -R "Newtonsoft.Json\|JsonConvert\|JObject\|JToken" .

見つかったプロジェクトに対して、まずは「本当にNewtonsoft.Jsonが必要か」を判断します。テストデータの簡単なJSON読み書きだけならSystem.Text.Jsonへ移行してもよいでしょう。一方で、既存コードがJObjectや柔軟なJSON操作に強く依存している場合は、無理に移行せずNewtonsoft.Jsonを明示参照する方が短期的には安全です。

管理者・プロダクトウォッチャーが押さえるべきポイント

今回の変更は、単なるライブラリ差し替えではなく、Microsoftの.NET SDK全体で依存関係を整理する流れの一部として見るべきです。テストプラットフォームが不要なDLLを出力フォルダーに持ち込むと、テスト対象コードの依存関係と混ざり、問題の切り分けが難しくなります。Microsoftの破壊的変更トラッキングでも、テスト対象コードが必要な依存関係はそのコード自身が持つべきであり、VSTestが持ち込む依存関係を減らすことが理由として説明されています。(GitHub)

管理者は、次の観点でリリース前の確認を進めるとよいでしょう。

立場優先して見るべきポイント具体的な対応
開発者テストコードの暗黙依存必要なプロジェクトにPackageReferenceを追加
CI管理者SDK・Build Toolsの更新タイミング更新前後でdotnet test結果を比較
拡張開発者アダプターやデータコレクターの依存宣言Newtonsoft.Jsonを明示依存にするか移行
セキュリティ担当古いNewtonsoft.Jsonの混入13.0.0未満が残っていないか確認
プロダクト担当Visual Studio Insidersでの影響利用中のテスト拡張の互換性を確認

よくある誤解と注意点

Newtonsoft.Jsonを全部やめる必要はない

この更新は、VSTestがNewtonsoft.Jsonを同梱しなくなる変更です。アプリケーションやテストコードでNewtonsoft.Jsonを使うこと自体が禁止されるわけではありません。必要なら明示的に参照すれば使えます。

System.Text.Jsonへ急いで全面移行しなくてもよい

長期的にはSystem.Text.Jsonへの移行を検討する価値はありますが、互換性や既存コード量によって判断すべきです。特にJObject、JArray、動的なJSON操作、独自のコンバーターに大きく依存している場合、短期間での全面移行はテスト不備を招きます。まずはビルド・テストを安定させ、その後に移行計画を立てるのが現実的です。

テスト失敗はサイレントではない

公式ブログでは、想定される失敗はサイレントではなく、テスト実行結果、TRX、Azure DevOpsやGitHubのテストビューに流れると説明されています。つまり、気付かないままテストが成功扱いになるリスクは低いと考えられます。(Microsoft for Developers)

すべてのテストプロジェクトに機械的に追加しない

失敗を避けるために、すべてのテストプロジェクトへNewtonsoft.Jsonを追加するのはおすすめしません。不要な依存関係が増えると、将来の脆弱性対応やバージョン管理が複雑になります。追加するのは、実際にNewtonsoft.Jsonを使っているプロジェクト、または一時的な回避策が必要なプロジェクトに限定しましょう。

実務でのおすすめ対応方針

今回の更新に対しては、次の順序で進めると安全です。

  1. まず、テストプロジェクトとテスト拡張でNewtonsoft.Json、JsonConvert、JObject、JTokenを検索する
  2. PackageReferenceがないのに使っているプロジェクトへ、明示的な参照を追加する
  3. ExcludeAssetsでruntimeを除外している場合は、除外理由を確認して設定を見直す
  4. Preview SDKまたはInsiders環境でdotnet testとTest Explorerの両方を確認する
  5. CI環境でTRX、GitHub Actions、Azure DevOpsのテスト表示まで確認する
  6. 独自アダプターやデータコレクターがある場合は、拡張パッケージ側の依存関係を修正する

開発チームとして最初に行うべきことは、依存関係の棚卸しです。エラーが出てから場当たり的に修正するより、Preview段階で「Newtonsoft.Jsonを明示的に使っている場所」と「VSTestに偶然依存していた場所」を分けておく方が、移行コストを抑えられます。

VSTestのNewtonsoft.Json依存削除は、多くの利用者にとっては小さな変更です。しかし、暗黙的な依存関係に頼っていたプロジェクトでは、.NET 11 Preview 4やVisual Studio 18.8の導入時に分かりやすい形で失敗します。次に取るべき行動は明確です。自分のリポジトリでNewtonsoft.Jsonの利用箇所を検索し、必要なプロジェクトだけにPackageReferenceを追加し、CIでdotnet testを確認してください。これだけで、今回の変更による大半のトラブルは事前に防げます。

この記事を書いた人

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

コメント

コメントする

目次