.NET 11 Preview 3で最初に押さえるべき結論は、今すぐ本番移行するためのリリースではなく、次の.NETサイクルで重点的に検証すべき領域が見えてきたリリースだということです。Microsoftは2026年4月14日に.NET 11 Preview 3を公開し、Runtime、SDK、Libraries、ASP.NET Core、.NET MAUI、C#、Entity Framework Core、コンテナイメージなど広い範囲の改善を発表しました。(Microsoft for Developers)
.NET developersやsolution architectsが今見るべきなのは、「新機能を全部試すこと」ではありません。ランタイム性能、JSONシリアライズ、ASP.NET Coreの圧縮とHTTP/3、EF Coreのマイグレーション、コンテナ署名、CLIワークフローのうち、自社アプリの設計・運用に影響する部分だけを切り出して検証することです。なお、.NET 11 Preview 3はプレビュー版であり、公式ダウンロードページでもプレビューリリースは一般に本番利用向けサポート対象ではないと説明されています。(Microsoft)
.NET 11 Preview 3は「移行開始」ではなく「検証開始」のサイン
.NET 11 Preview 3は、機能追加の見本市というより、.NET 11がどの方向へ固まりつつあるかを読むための材料です。特に、既存の.NET 8、.NET 9、.NET 10環境を運用しているチームは、Preview 3を本番更新の候補として扱うのではなく、互換性・性能・開発体験・運用セキュリティの検証対象として扱うのが現実的です。
| 判断項目 | 結論 | 実務での行動 |
|---|---|---|
| 本番導入 | まだ避けるべき | 本番ブランチとは分離した検証ブランチで試す |
| 移行判断 | 早期判断は不要 | 既存コードのビルド、テスト、ベンチマークだけ先に確認する |
| 影響が大きい領域 | Web API、Blazor、EF Core、コンテナ、MAUI、非同期処理 | 該当するプロジェクトだけ優先検証する |
| アーキテクト視点 | 次期.NETサイクルの設計思想を読む段階 | 長期運用方針、CI/CD、クラウドネイティブ対応に反映する |
Microsoftのサポートポリシーでは、.NETのメジャーバージョンは毎年11月にリリースされ、STSとLTSでサポート期間が分かれます。.NET 11は公式ダウンロードページ上でStandard Term Support、つまりSTSとして表示されています。(Microsoft) (Microsoft)
そのため、.NET 11は「長期固定のためのLTS」というより、最新機能を取り込みたいチームが次のサイクルで検討するバージョンとして見るべきです。長期サポート重視の組織は、.NET 10 LTSを軸にしながら、.NET 11で入る機能を先行評価する立ち位置が自然です。
開発者向けに重要な.NET 11 Preview 3の変更点
.NET 11 Preview 3の変更は多岐にわたりますが、実務で優先して見るべきポイントは次の7つです。
| 領域 | Preview 3の主な変更 | 影響を受けやすいプロジェクト |
|---|---|---|
| Runtime / JIT | runtime async、JIT最適化、WebAssembly改善 | 非同期処理が多いAPI、AOT、Blazor WebAssembly |
| Libraries | System.Text.Json、Zstandard、ZIP検証、Regex改善 | JSON API、圧縮処理、ファイル取込、ログ解析 |
| SDK / CLI | .slnf操作、file-based apps、dotnet run -e、dotnet watch改善 | 大規模リポジトリ、ローカル開発環境、CI検証 |
| C# | union typesのIDEサポート改善 | ドメインモデル、Result型、状態表現を検討するチーム |
| ASP.NET Core | zstd圧縮、Blazor Virtualize、HTTP/3改善 | Web API、Blazor、低レイテンシ用途 |
| EF Core | ChangeTracker、DbContext設定、Migrations、SQL生成改善 | データアクセス層、テスト環境、DB移行が多いシステム |
| Container Images | .NETコンテナイメージの署名 | Kubernetes、Azure Container Apps、GitOps、サプライチェーン管理 |
RuntimeとLibrariesは「性能」と「安全な既定値」が中心
.NET 11 Preview 3のRuntimeでは、runtime asyncが引き続き機能スイッチを使う一方、EnablePreviewFeaturesを有効にしなくても利用できるようになりました。また、NativeAOTとReadyToRunのサポート、JITによるswitch、境界チェック、キャストの最適化も含まれています。(GitHub)
これは、既存コードを書き換えなくても効果が出る可能性のある改善です。ただし、性能改善はアプリの構造に大きく依存します。非同期I/Oが多いWeb API、バックグラウンド処理、キュー処理、gRPCサービスでは、Preview 3を使って次の観点を測ると判断しやすくなります。
| 検証対象 | 見るべき指標 |
|---|---|
| async-heavyなAPI | レイテンシ、スループット、GC割り当て、スレッドプール待ち |
| AOT / ReadyToRun | 起動時間、バイナリサイズ、デプロイ手順への影響 |
| JIT最適化 | ホットパスのCPU使用率、ベンチマーク差分 |
| WebAssembly | デバッグ体験、JS境界をまたぐデータ受け渡し |
Librariesでは、System.Text.Jsonの命名・ignore設定の制御が強化され、Zstandard APIはSystem.IO.Compressionへ移動しました。さらにZIPエントリ読み込み時のCRC32検証、Unicode改行を扱うRegexオプションなども追加されています。(GitHub)
特に注意したいのは、ZIPのCRC32検証です。これまで読み込めていた壊れたZIPや途中で欠落したZIPが、Preview 3ではInvalidDataExceptionとして失敗する可能性があります。これは安全性の向上ですが、外部ベンダーから受け取るZIP、ユーザーアップロード、古いバッチ処理では「急に例外が出る」ように見えることがあります。
SDKとCLIは大規模開発チームに効く改善が多い
.NET 11 Preview 3のSDKでは、dotnet slnでsolution filter、つまり.slnfを作成・編集できるようになりました。大規模リポジトリで一部プロジェクトだけを読み込みたい場合、IDE操作に依存せずCLIから管理できる点が実務的です。(GitHub)
たとえば、モノレポでAPI、管理画面、バッチ、共有ライブラリが同じsolutionに入っている場合、開発者全員が常に全プロジェクトを読み込む必要はありません。.slnfを用途別に作れば、ビルド時間やIDE起動時間の削減につながります。
dotnet new slnf --name backend.slnf
dotnet sln backend.slnf add src/Api/Api.csproj
dotnet sln backend.slnf add src/Application/Application.csproj
dotnet sln backend.slnf listまた、dotnet run -eで一時的な環境変数をコマンドラインから渡せるようになった点も便利です。ローカル検証だけの設定をシェルに残したり、launchSettings.jsonを書き換えたりする必要が減ります。(GitHub)
dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debugdotnet watchではAspire app hostとの統合、クラッシュ後の再起動、WindowsデスクトップアプリでのCtrl+C処理改善などが入りました。ローカル開発ループを短くする方向の改善であり、次の.NETサイクルでも「開発者体験をCLIから整える」流れが続くことを示しています。(GitHub)
C# union typesは注目だが、公開APIへの採用は慎重に
C#ではPreview 2で追加されたunion type supportに対して、Preview 3でIDEサポートが改善されています。ただし、Preview 3時点ではUnionAttribute型とIUnionインターフェイスのpolyfillが必要とされています。(GitHub)
union typesは、複数の状態を安全に表現したい場面で魅力があります。たとえば、APIの結果を「成功」「検証エラー」「権限エラー」「外部サービス失敗」のように明示したい場合、従来は例外、nullable、独自Result型、継承階層などで表現していました。union typesが成熟すれば、こうした設計がより読みやすくなる可能性があります。
ただし、Preview 3の段階でライブラリの公開APIや長期運用するドメインモデルに組み込むのは早すぎます。試すなら、以下のような限定範囲が安全です。
| 試してよい範囲 | 避けたい範囲 |
|---|---|
| 社内検証用プロジェクト | NuGet公開ライブラリの外部API |
| サンプル実装 | 長期保守が必要な基幹ドメインモデル |
| 既存Result型との比較 | 複数チームが依存する共通契約 |
| IDE補完や可読性の評価 | 仕様変更に弱いコード生成基盤 |
ポイントは、union typesを「すぐ使う新構文」ではなく、今後のC#設計の方向性を読む材料として扱うことです。
ASP.NET Coreは圧縮、Blazor、HTTP/3が実務寄りに進化
ASP.NET Coreでは、Zstandard、つまりzstdによるレスポンス圧縮とリクエスト展開がサポートされました。既存のresponse compression middlewareやrequest decompression middlewareにzstdが追加され、既定で有効になります。(GitHub)
Web APIで大きなJSONレスポンスを返すシステム、モバイル回線向けのAPI、内部マイクロサービス間通信では、zstdが通信量削減に効く可能性があります。一方で、圧縮レベルを上げればCPU負荷も増えます。導入判断では「レスポンスサイズが何％減ったか」だけでなく、CPU使用率、p95/p99レイテンシ、プロキシやCDNの対応状況も合わせて見る必要があります。
Blazorでは、Virtualize<TItem>が可変高さのアイテムに適応しやすくなりました。従来の仮想化リストは、各行の高さがそろっている前提に近い挙動になりがちです。チャット、通知一覧、カード型UI、コメント一覧のように高さがばらつくUIでは、スクロール位置や余白のズレが改善する可能性があります。(GitHub)
HTTP/3では、Kestrelがcontrol streamとSETTINGS frameを待たずにリクエスト処理を開始できるようになり、新規接続の初回リクエストレイテンシ低減が期待されます。(GitHub)
EF Coreは「チーム開発で困る部分」に手が入っている
EF CoreのPreview 3では、派手な新機能よりも、日々の開発やテストで効く改善が目立ちます。ChangeTracker.GetEntriesForState()は、指定した状態のtracked entityを取得する際に余分なDetectChanges()を強制しません。長く生きるDbContextや、大量の変更追跡を扱うコードでは無駄な処理を減らせます。(GitHub)
また、RemoveDbContext()やRemoveExtension()により、既存のprovider設定を取り外して別のproviderを登録しやすくなりました。これはテストで本番用SQL Server設定をSQLiteやin-memory providerへ差し替える場面で役立ちます。(GitHub)
Migrationsでは、外部キー制約をマイグレーション対象から除外する制御や、migration treeの分岐を早く検出する仕組みが追加されています。複数チームが同じDBスキーマを扱うプロジェクトでは、マイグレーションの衝突や取り込み漏れを早めに見つける材料になります。(GitHub)
ただし、EF CoreはPreview 3で破壊的変更も含みます。MigrationsNotFoundが既定で例外になる、SqlVectorプロパティが既定でロードされない、Microsoft.Data.SqlClientが7.0.0へ更新されるなど、データアクセス層ではビルドが通っても実行時挙動が変わる可能性があります。(GitHub)
EF Coreを試す場合は、最低でも次を実行してください。
| 検証 | 目的 |
|---|---|
| 既存マイグレーションの再生成差分を確認 | 予期しないDDL変更を見つける |
| 代表的なLINQのSQL出力を比較 | join削減やJSON API変更の影響を見る |
| 結合テストをDB実体で実行 | provider差分を吸収できているか確認する |
| migration treeの運用ルールを見直す | 複数ブランチ開発での衝突を減らす |
.NET MAUIは地図、XAML、モバイルOS追随がポイント
.NET MAUIでは、Mapコントロールにpin clustering、custom pin icons、custom JSON styling、長押しイベント、図形クリックイベント、ZIndex、プログラムからのinfo window制御など、多数の機能が追加されています。地図中心のアプリでは、これまでplatform-specific実装やカスタムhandlerに逃がしていた処理を、より.NET MAUI側に寄せられる可能性があります。(GitHub)
XAML Source Generationでは、ResourceDictionaryのエントリを必要時に生成する方向の改善が入り、起動時にすべてのスタイルやブラシを実体化する負荷を下げる狙いがあります。Hot Reloadや動的UI更新に関係するAPIも追加されています。(GitHub)
さらに、LongPressGestureRecognizerが.NET MAUI本体に入り、長押し操作をfirst-party APIとして扱えるようになりました。Android 17 / API 37 preview support、iOS通知権限のcross-platform Permissions API対応なども含まれています。(GitHub)
MAUIアプリでPreview 3を見るべきチームは、特に次のようなケースです。
| アプリの種類 | 検証ポイント |
|---|---|
| 店舗検索、配送、位置情報アプリ | Mapのclustering、custom pin、長押し操作 |
| 起動時間が課題のアプリ | XAML Source Generationの影響 |
| OS新バージョン追随が必要なアプリ | Android 17 / API 37 preview support |
| 独自handlerが多いアプリ | first-party APIへ置き換えられるか |
コンテナイメージ署名はサプライチェーン対策の標準化を示している
.NET 11 Preview 3では、.NETコンテナイメージがMicrosoftによって暗号学的に署名され、Notary Project仕様に基づく署名検証が可能になりました。notationやorasで署名アーティファクトを確認できます。(GitHub)
これは、アプリコードの機能追加よりもアーキテクチャ上の意味が大きい変更です。今後の.NET運用では、「公式イメージを使っているから安心」ではなく、どのイメージを、誰が署名し、どのdigestでデプロイしたかをCI/CDで追跡することがより重要になります。
Kubernetes、Azure Container Apps、GitHub Actions、Azure Pipelinesなどで.NETコンテナを使っているチームは、Preview 3の段階で次を検討しておくと後の移行が楽になります。
notation inspect mcr.microsoft.com/dotnet/sdk:11.0.100-preview.3
oras discover mcr.microsoft.com/dotnet/sdk:11.0.100-preview.3ただし、署名があることと安全な運用は同じではありません。実務では、イメージ署名に加えて、digest pinning、脆弱性スキャン、SBOM、base image更新ルール、ロールバック手順を合わせて設計する必要があります。
Preview 3で失敗しやすいポイント
.NET 11 Preview 3の検証でありがちな失敗は、「新機能を試す」ことに集中しすぎて、互換性の確認を後回しにすることです。特に次の点は、既存アプリで見落としやすい部分です。
| 失敗しやすいポイント | 起こり得る問題 | 対策 |
|---|---|---|
| ZIP読み込みのCRC32検証を見ない | 壊れたZIPが例外になる | 外部ファイル取込の異常系テストを追加する |
| BackgroundService例外の扱いを見ない | 例外時にhost停止へ挙動が変わる可能性 | 例外処理、監視、再起動ポリシーを確認する |
| EF Coreのbreaking changesを読まない | migrationやSqlVectorで実行時差分が出る | DB結合テストとSQL出力比較を実施する |
| union typesを本番APIに入れる | Preview仕様変更の影響を受ける | 実験用途に限定する |
| zstd圧縮を無条件で有効評価する | CPU負荷やproxy対応で逆効果になる | 実トラフィックに近い条件で測る |
| コンテナ署名だけで満足する | supply chain全体の保証にならない | digest、SBOM、脆弱性スキャンも組み合わせる |
Librariesのbreaking changesには、ZIPのCRC32検証、未処理のBackgroundService例外、サーバー側client certificate validationでのAIA certificate download既定無効化などが含まれます。(GitHub)
.NET 11 Preview 3を既存プロジェクトで試す手順
Preview 3を試すときは、いきなり本番コードのtarget frameworkを書き換えないことが大切です。まずは検証ブランチを作り、SDKを固定し、ビルドとテストの差分だけを見る流れにします。
.NET 11 Preview 3のSDKは、公式ダウンロードページで11.0.100-preview.3として提供されています。WindowsでVisual Studioを使う場合、Microsoftは最新のVisual Studio 2026 Insidersを推奨しています。(Microsoft) (Microsoft for Developers)
dotnet --list-sdks
dotnet new globaljson --sdk-version 11.0.100-preview.3
dotnet restore
dotnet build
dotnet test既存ライブラリなら、一時的にmulti-targetingで比較する方法もあります。
<PropertyGroup>
<TargetFrameworks>net10.0;net11.0</TargetFrameworks>
</PropertyGroup>検証の順序は次のように進めると、手戻りを減らせます。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 検証ブランチを作成 | 本番ブランチへ影響しない |
| 2 | global.jsonでSDKを固定 | 開発者間とCIでSDK差分が出ない |
| 3 | restore / build / testを実行 | 既存コードの互換性を確認できる |
| 4 | 代表的なAPI・DB・バッチを実行 | 実行時例外や挙動差分を見つける |
| 5 | ベンチマークを取る | Preview 3の性能差を定量化できる |
| 6 | breaking changesをチェック | 移行時に必要な修正を洗い出せる |
| 7 | 採用判断を保留または記録 | Preview段階で無理に意思決定しない |
重要なのは、Preview 3で「使えるか」を決めるのではなく、GAやRCが近づいたときに判断できる材料を今から集めることです。
Preview 3が次の.NETサイクルに示すこと
.NET 11 Preview 3から見える方向性は、単なる機能追加ではありません。次の.NETサイクルでは、開発者体験、クラウドネイティブ運用、性能、安全な既定値の4つがより強く結びついていくと考えられます。
まず、RuntimeとJITの改善は、アプリコードを書き換えずに性能を底上げする方向です。これは、既存の大規模アプリを一気に再設計するのではなく、フレームワーク側の進化で負荷を下げていく流れを示しています。
次に、SDKとCLIの改善は、大規模開発チームを意識しています。.slnfのCLI操作、dotnet run -e、dotnet watchの改善は、個人開発よりも、複数人・複数プロジェクト・複数環境での再現性に効きます。
ASP.NET Core、EF Core、コンテナ署名の改善は、クラウドネイティブな本番運用に直結します。圧縮、HTTP/3、SQL生成、migration管理、署名済みイメージは、どれも「コードが動く」だけでなく、「安全に速く運用できる」ことへ関心が移っている証拠です。
最後に、C# union typesやMAUIの改善は、今後の表現力とクロスプラットフォーム体験への投資を示しています。ただし、これらはPreview 3時点では慎重に扱うべきです。特に言語機能は、仕様が固まるまで実験と評価に留めるのが安全です。
まとめ: .NET 11 Preview 3で今やるべきこと
.NET 11 Preview 3は、本番移行の号令ではなく、次の.NETサイクルに備えるための早期検証ポイントです。特に注目すべきなのは、runtime asyncとJIT、System.Text.JsonとZIP検証、SDK/CLIの開発体験、ASP.NET CoreのzstdとHTTP/3、EF Coreのmigration改善、MAUIのMap強化、コンテナイメージ署名です。
今すぐ取るべき行動は明確です。既存プロジェクトのうち、Preview 3の変更が効きそうな領域を1つ選び、検証ブランチでSDKを固定して、ビルド・テスト・ベンチマーク・breaking changes確認を行ってください。
特にsolution architectsは、.NET 11を「採用するかどうか」だけでなく、次の設計判断にどう影響するかを見るべきです。開発効率、クラウド運用、セキュリティ、データアクセス、UI体験のどこに投資すべきかを、Preview 3の段階からチームの技術ロードマップに反映しておくと、正式リリース前後の移行判断がかなり楽になります。
コメント