Microsoft.NET.Test.Sdk 18.5.1更新の確認ポイント｜影響範囲と移行手順を解説

2026年5月5日に公開・更新された「Microsoft developer platform documentation update: Bump Microsoft.NET.Test.Sdk from 18.4.0 to 18.5.1」は、アプリ本体の機能追加ではなく、.NETテスト基盤の依存関係更新です。結論として、Microsoft.NET.Test.Sdk を使っているテストプロジェクトは 18.5.1 への更新状況を確認し、dotnet test とCI上のVSTest実行を再検証する必要があります。特に Azure DevOps の VSTest タスクや分散テストを使っている環境では、System.Collections.Immutable 関連の読み込みエラーを避ける観点から優先度が高い更新です。(GitHub)

今回の変更は小さく見えますが、テストSDKはテスト検出、テストホスト、コードカバレッジ、CI/CDの成否に関わります。この記事では、Microsoft developer platform の更新内容を、確認すべき変更点、影響範囲、移行・設定確認の順に整理します。

Microsoft.NET.Test.Sdk 18.5.1への更新で何が変わったか

今回のPRでは、microsoft/agent-governance-toolkit リポジトリ内のテストプロジェクトで、Microsoft.NET.Test.Sdk のバージョンが 18.4.0 から 18.5.1 に更新されました。変更対象は agent-governance-dotnet/tests/AgentGovernance.Tests/AgentGovernance.Tests.csproj の1ファイルで、差分はパッケージ参照のバージョン変更のみです。(GitHub)

確認項目	内容	実務で見る場所
更新日	2026年5月5日にPRがマージ	GitHub PR、Dependabot通知
対象パッケージ	`Microsoft.NET.Test.Sdk`	`.csproj`、`Directory.Packages.props`
更新前	`18.4.0`	既存のPackageReference
更新後	`18.5.1`	更新後のPackageReference
変更種別	DependabotによるNuGet依存関係更新	dependency updateのPR
影響しやすい領域	テスト検出、テスト実行、コードカバレッジ、CIのVSTest実行	`dotnet test`、Azure Pipelines、GitHub Actionsなど

実際の変更は次のような内容です。

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.5.1" />

既存コードのロジックやAPI利用方法を直接変える更新ではありません。ただし、テストプロジェクトのビルドターゲットやテストホストに関わるため、「ビルドは通るがCIのテスト検出で落ちる」「ローカルでは通るがAzure DevOpsで落ちる」といった差が出る可能性があります。

Microsoft.NET.Test.Sdkは何に影響するのか

Microsoft.NET.Test.Sdk は、.NETのテストプロジェクトをビルド・実行するためのMSBuildターゲットや関連プロパティを提供するNuGetパッケージです。NuGet上では、net8.0 向けに Microsoft.CodeCoverage と Microsoft.TestPlatform.TestHost への依存関係が示されており、.NET Framework 4.6.2 向けには Microsoft.CodeCoverage への依存関係があります。([NuGet][3])

つまり、このパッケージは「テストコードを書くためのフレームワークそのもの」ではなく、テストを検出し、実行し、結果を出力する土台に近いものです。xUnit、NUnit、MSTestなどのテストフレームワークを使っていても、Visual Studio Test Explorer、dotnet test、VSTestタスクを通じて影響を受けることがあります。

Microsoft Learnでは、dotnet test はソリューションをビルドし、VSTestまたはMicrosoft Testing Platform（MTP）を使ってテストを実行すると説明されています。使用するテストランナーによって、利用できるオプションや動作が変わります。(Microsoft Learn)

18.5.1で注目すべき修正点

今回の更新で重要なのは、18.5.0 を避けて 18.5.1 に上げる意味がある点です。Microsoft.NET.Test.Sdkのリリース情報では、18.5.0 はNuGet上でunlisted扱いになっており、18.5.1 では System.Collections.Immutable のバインディング不一致に関する修正が含まれています。(GitHub)

報告された問題では、Microsoft.TestPlatform 18.5.0 を使った環境で System.Collections.Immutable, Version=8.0.0.0 を読み込めないエラーが発生していました。メンテナーの説明では、Azure DevOpsのCIパイプラインでVSTest@2と分散実行を使うケースに関係し、クラウド版Azure DevOpsではVSTest@3への更新が推奨されています。(GitHub)

実務上は、次のようなエラーが出ている場合に特に確認すべきです。

症状	確認すべきこと	対応の方向性
`System.Collections.Immutable` の読み込みエラー	`Microsoft.NET.Test.Sdk` または `Microsoft.TestPlatform` が18.5.0になっていないか	18.5.1へ更新、または一時的に18.4.0へ戻す
テスト検出の段階でCIが失敗する	VSTestタスクのバージョン、分散実行設定	VSTest@3への移行を検討
ローカルでは通るがAzure DevOpsで落ちる	エージェント側のテストプラットフォーム取得方法	Test Platform Installerの固定バージョンを確認
コードカバレッジの出力が変わる	`Microsoft.CodeCoverage` の実行結果	カバレッジ成果物のパスとPublish設定を再確認

対応すべきチームと優先度

すべての開発チームが即時対応する必要はありません。優先度は、Microsoft.NET.Test.Sdk の利用有無と、テストをどこで実行しているかで判断します。

対象	優先度	理由
`Microsoft.NET.Test.Sdk` 18.5.0を使っている	高	既知のバインディング問題を踏む可能性がある
18.4.0から18.5.1へ更新するDependabot PRが来ている	高	PRを放置せず、テスト結果を確認して取り込むべき
Azure DevOpsでVSTest@2を使っている	高	関連問題でVSTest@3への更新が推奨されている
GitHub ActionsやCLIで `dotnet test` のみを使っている	中	テストSDK更新後の復元・テスト実行確認が必要
Visual StudioのTest Explorer中心でCIを使っていない	中	ローカルのテスト検出と実行結果を確認
.NETテストプロジェクトがない	低	直接の影響は基本的にない

Dependabot PRでは dependency-type: direct:production と表示されていますが、今回の差分は tests/AgentGovernance.Tests 配下のテストプロジェクトです。実務では、Dependabotの分類だけで判断せず、「どのプロジェクトファイルで更新されたか」を必ず確認してください。(GitHub)

まず確認するべき設定

パッケージ参照の場所を確認する

個別の .csproj に直接書かれている場合は、次のような記述を探します。

<ItemGroup>
  <PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.5.1" />
</ItemGroup>

一方、Central Package Managementを使っている場合は、Directory.Packages.props にバージョンが集約されていることがあります。

<Project>
  <ItemGroup>
    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="18.5.1" />
  </ItemGroup>
</Project>

複数のテストプロジェクトがある場合、1つだけ更新されているとテスト環境が不揃いになります。特にソリューション単位で dotnet test を実行している場合は、全テストプロジェクトのバージョンをそろえるのが安全です。

現在のバージョンをCLIで確認する

ソリューション全体で確認する場合は、次のコマンドが便利です。

dotnet list package | grep Microsoft.NET.Test.Sdk

PowerShellでは次のように確認できます。

dotnet list package | Select-String "Microsoft.NET.Test.Sdk"

パッケージロックファイルを使っている場合は、packages.lock.json も更新対象です。.csproj だけを変えても、ロックファイルが古いままだとCIで意図したバージョンが復元されないことがあります。

移行・更新の基本手順

更新作業は、単にバージョンを書き換えて終わりではありません。テスト基盤の更新では、復元、ローカル実行、CI実行、成果物確認までを1セットで見ます。

手順	作業	失敗しやすいポイント
1	`Microsoft.NET.Test.Sdk` の参照場所を確認	`.csproj` と `Directory.Packages.props` の二重管理
2	バージョンを `18.5.1` に更新	18.5.0で止めてしまう
3	`dotnet restore` を実行	ロックファイル未更新
4	`dotnet test` をローカルで実行	テスト検出だけ成功し、カバレッジ確認を忘れる
5	CIで同じテストを実行	エージェント側のVSTestバージョン差を見落とす
6	テスト結果・TRX・カバレッジを確認	PublishTestResultsやカバレッジ成果物のパス変更に気づかない

基本コマンドは次の流れです。

dotnet restore
dotnet test --no-restore

CIでRelease構成を使っている場合は、ローカルでも同じ構成で確認します。

dotnet test --configuration Release --no-restore

Azure DevOpsを使っている場合の注意点

Azure DevOpsでVSTestを使っている場合は、NuGetパッケージの更新だけでなく、パイプライン側のテストタスクも確認してください。Microsoft Learnでは、VSTest@3が最新バージョンであり、パイプラインで使用すべきタスクとして案内されています。(Microsoft Learn)

VSTest@2を使っている場合は、次のようにタスクバージョンを確認します。

- task: VSTest@3
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      **\bin\**\*test*.dll
      !**\*TestAdapter.dll
      !**\obj\**

エージェントに完全なVisual Studioを入れず、Visual Studio Test Platform Installerでテストプラットフォームを取得している場合は、特定バージョンを指定できます。Microsoft Learnでは、VisualStudioTestPlatformInstaller@1 に versionSelector: specificVersion と testPlatformVersion を指定できること、またVisual Studio Testタスクの前に配置する必要があることが説明されています。(Microsoft Learn)

- task: VisualStudioTestPlatformInstaller@1
  inputs:
    packageFeedSelector: 'nugetOrg'
    versionSelector: 'specificVersion'
    testPlatformVersion: '18.5.1'

- task: VSTest@3
  inputs:
    vstestLocationMethod: 'version'
    vsTestVersion: 'toolsInstaller'
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      **\bin\**\*test*.dll
      !**\*TestAdapter.dll
      !**\obj\**

latestStable は便利ですが、CIの再現性を重視するなら特定バージョン固定が安全です。今回のように特定バージョンで不具合が入り、次のパッチで修正されるケースでは、「昨日まで通っていたCIが突然落ちる」原因になりやすいためです。

MTPを使っている場合はVSTestとの混在に注意

.NET 10以降では、dotnet test のテストランナーとしてVSTestだけでなくMicrosoft Testing Platform（MTP）を選択できます。Microsoft Learnでは、global.json に runner: Microsoft.Testing.Platform を指定することでMTPを有効にする方法が説明されています。(Microsoft Learn)

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

MTPを使っているプロジェクトでは、VSTest前提のオプションやAzure DevOpsのVSTestタスクと混同しないことが重要です。Microsoft LearnのVSTest@3ページでも、VSTest Azure taskはVSTestプラットフォーム固有であり、新しいMTPはサポートしないと説明されています。(Microsoft Learn)

確認すべきポイントは次の3つです。

確認項目	VSTest中心の環境	MTP中心の環境
実行コマンド	`dotnet test`、`vstest.console`、VSTestタスク	`dotnet test` のMTPモード
設定ファイル	`.runsettings`、VSTestオプション	`global.json`、MTP固有オプション
CIタスク	VSTest@3、Test Platform Installer	DotNetCoreCLIやスクリプトでの `dotnet test`

ソリューション内にVSTest系とMTP系のテストプロジェクトが混在している場合、同じ dotnet test でも挙動が分かりにくくなります。移行期は、プロジェクト単位で実行コマンドを分け、CIログにどのランナーを使ったかが残るようにしておくとトラブルシューティングが楽になります。

更新後に見るべきテスト結果

Microsoft.NET.Test.Sdk 18.5.1 に更新した後は、単に「CIが緑になったか」だけで判断しないでください。次の項目まで確認すると、後からの手戻りを減らせます。

確認項目	見るべき内容
テスト検出数	更新前後でテスト数が大きく変わっていないか
失敗テスト	実行前の検出エラーではなく、テスト本体の失敗か
TRX出力	Azure DevOpsやGitHub Actionsで結果が取り込まれているか
コードカバレッジ	カバレッジファイルが生成・公開されているか
実行時間	異常に遅くなっていないか
エージェント差	Windows/Linux、ローカル/CIで結果が一致するか

特に注意したいのは、テスト検出数です。パッケージ更新後にテスト数が減っている場合、成功に見えても一部のテストが実行されていない可能性があります。CIのログで「Passed」の数だけでなく、検出されたテスト総数を更新前と比べてください。

すぐに対応できない場合の判断基準

すぐに 18.5.1 へ更新できない場合でも、18.5.0 のまま放置するのは避けたほうが安全です。既知の読み込み問題に関係する可能性があるため、短期的には 18.4.0 に戻すか、18.5.1 への更新を優先して検証します。

判断の目安は次の通りです。

状況	推奨対応
18.5.0でCIが失敗している	18.5.1へ更新。難しければ一時的に18.4.0へ戻す
18.4.0で安定している	18.5.1へ更新してテスト検証。急がないが放置しない
Dependabot PRが来ている	自動マージせず、CIログとテスト数を確認してから取り込む
Azure DevOps VSTest@2を使っている	VSTest@3への移行計画を立てる
MTPへ移行中	VSTest前提のCI設定と混在していないか確認する

パッケージ更新のPRは差分が小さいため、レビューが形式的になりがちです。しかし、テストSDKは開発者体験とリリース品質を支える部分です。アプリの本番コードに変更がなくても、テストが正しく実行されなければ、リリース判断の信頼性が落ちます。

今回の更新で取るべき次のアクション

今回の Microsoft developer platform documentation update は、Microsoft.NET.Test.Sdk を 18.4.0 から 18.5.1 に上げる依存関係更新です。対応の要点は、対象プロジェクトのパッケージ参照を確認し、18.5.0 を避けて 18.5.1 にそろえ、ローカルとCIの両方でテスト検出数・テスト結果・カバレッジ出力を確認することです。

まずは次の順に進めてください。

リポジトリ内で Microsoft.NET.Test.Sdk の参照場所を検索する
18.5.0 または古い固定バージョンがないか確認する
18.5.1 に更新し、ロックファイルも更新する
dotnet test をローカルで実行する
CIでVSTestタスク、Test Platform Installer、MTP設定を確認する
テスト数、TRX、コードカバレッジの出力を更新前後で比較する

差分は1行でも、テスト基盤の更新はリリース品質に直結します。DependabotのPRをそのままマージするのではなく、「どのテストプロジェクトに効くのか」「CIのテストランナーは何か」「更新後も同じ数のテストが実行されているか」まで確認するのが、安全な移行のポイントです。

[3]: https://www.nuget.org/packages/microsoft.net.test.sdk “
NuGet Gallery
| Microsoft.NET.Test.Sdk 18.5.1
“

この記事を書いた人

佐藤健司

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

Microsoft.NET.Test.Sdk 18.5.1更新の確認ポイント｜影響範囲と移行手順を解説

Microsoft.NET.Test.Sdk 18.5.1への更新で何が変わったか

Microsoft.NET.Test.Sdkは何に影響するのか

18.5.1で注目すべき修正点

対応すべきチームと優先度

まず確認するべき設定

パッケージ参照の場所を確認する

現在のバージョンをCLIで確認する

移行・更新の基本手順

Azure DevOpsを使っている場合の注意点

MTPを使っている場合はVSTestとの混在に注意

更新後に見るべきテスト結果

すぐに対応できない場合の判断基準

今回の更新で取るべき次のアクション

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft.NET.Test.Sdk 18.5.1更新の確認ポイント｜影響範囲と移行手順を解説

Microsoft.NET.Test.Sdk 18.5.1への更新で何が変わったか

Microsoft.NET.Test.Sdkは何に影響するのか

18.5.1で注目すべき修正点

対応すべきチームと優先度

まず確認するべき設定

パッケージ参照の場所を確認する

現在のバージョンをCLIで確認する

移行・更新の基本手順

Azure DevOpsを使っている場合の注意点

MTPを使っている場合はVSTestとの混在に注意

更新後に見るべきテスト結果

すぐに対応できない場合の判断基準

今回の更新で取るべき次のアクション

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル