.NET 11 Preview 4の変更点まとめ｜開発者・管理者が確認すべき移行ポイント

.NET 11 Preview 4は、すぐに本番環境へ適用する更新というより、2026年11月予定の正式リリースに向けて「互換性・性能・開発体験を早めに検証するためのプレビュー」です。特に確認すべきなのは、Runtime Async、Process APIの大幅拡張、ASP.NET CoreのOpenAPI/Blazor改善、.NET MAUIのCoreCLR既定化、EF CoreのSQL Server 2025向けベクトル検索です。

Microsoftの公式情報では、.NET 11 Preview 4は.NET Runtime、SDK、ライブラリ、ASP.NET Core、.NET MAUI、C#、Entity Framework Coreなど広い範囲に改善が入ったリリースとされています。Previewリリースは早期検証用であり、一般的には本番利用向けではありません。まずは開発環境やステージング環境で、ビルド・テスト・パフォーマンス・デプロイ手順への影響を確認するのが現実的です。(Microsoft for Developers)

.NET 11 Preview 4の位置づけ

.NET 11 Preview 4は、.NET 11の4回目のプレビューリリースです。Microsoft Learnでは、.NET 11は現在プレビュー段階で、正式リリースは2026年11月予定と説明されています。(Microsoft Learn)

.NETのサポートポリシーでは、偶数番号のリリースはLTS、奇数番号のリリースはSTSとして扱われ、STSは2年間のサポートを受けるモデルです。したがって、正式版の.NET 11はSTS系リリースとして計画を立てるのが自然です。(Microsoft)

ただし、Preview 4の段階では「新機能を先に試す」ことが目的です。本番サーバーに入れるのではなく、次のような用途で使うべきです。

.NET 11対応に向けたライブラリや自社アプリの互換性確認
CI/CD、Docker、IIS、クラウド環境でのビルド検証
ASP.NET CoreやBlazorの新機能の試験導入
EF Coreの移行差分やSQL生成結果の確認
.NET MAUIアプリのCoreCLR移行に向けた検証

変更点の全体像

.NET 11 Preview 4の変更は広範囲です。最初に、どの領域が自分のシステムに関係するかを切り分けると、確認作業が進めやすくなります。

領域	主な変更点	影響を受けやすいチーム
Runtime	Runtime Async、JIT最適化、ReadyToRun改善、WebAssembly/CoreCLR関連	非同期処理が多いWeb API、AOT/高性能化を重視するチーム
Libraries	Process API拡張、System.Text.Json改善、RateLimiter修正、MemoryCacheのOpenTelemetryメトリクス	CLIツール、バックグラウンド処理、監視基盤を持つチーム
SDK/CLI	dotnet watchのモバイル対応強化、CLIテレメトリのOpenTelemetry化、NativeAOT CLI基盤	CI/CD管理者、MAUI開発者、開発環境を統制する管理者
ASP.NET Core	HTTP QUERYのOpenAPI対応、Blazor改善、MCP Serverテンプレート、Kestrel TLS可観測性	Web API、Blazor、AI連携サービス、API仕様管理チーム
.NET MAUI	CoreCLRが既定ランタイムに、Android/iOS向けdotnet watch改善	モバイルアプリ開発チーム
EF Core	SQL Server 2025向けベクトル検索、JSONマッピング改善、dotnet-ef.json	データ基盤、AI検索、DBマイグレーション担当者
C# / Roslyn	shebang診断改善、VBCSCompilerのコンパイルキャッシュ	C#スクリプト、CIビルド高速化を検証するチーム

Runtime AsyncとJIT最適化で何が変わるのか

.NET 11 Preview 4では、ランタイムライブラリがruntime-async=onでビルドされるようになりました。これは、従来のコンパイラ生成の非同期ステートマシンではなく、ランタイム側の非同期機能を使う方向への大きな変更です。Microsoftは、スループットやライブラリサイズの改善が期待できる一方、実際の効果は非同期処理の使い方に左右されると説明しています。(GitHub)

実務で見るべきポイントは、単に「速くなるか」ではありません。次のような観点で検証する必要があります。

確認項目	見るべき内容
非同期処理の性能	Web API、DBアクセス、ストリーム処理などでレイテンシやスループットが変わるか
例外・スタックトレース	監視ツールやログ解析で既存の検知ルールが崩れないか
NativeAOT / ReadyToRun	AOTビルドやR2Rビルドのサイズ、起動時間、ビルド時間に変化があるか
ライブラリ互換性	自社ライブラリやサードパーティ製ライブラリが`net11.0`で正常に動くか

JIT最適化では、定数同士のstring.EqualsやReadOnlySpan<T>.SequenceEqualの比較を結果に畳み込む改善、空でないSpanの先頭要素アクセスに対する境界チェック削減などが入っています。通常のC#コードでも、インライン化後に条件式が簡略化される場面では恩恵を受ける可能性があります。(GitHub)

ただし、性能改善はアプリのコードパスに依存します。Preview 4を評価する場合は、ベンチマークだけでなく、実際のAPIエンドポイント、バッチ処理、メッセージ処理など、本番に近い負荷で確認することが重要です。

Process APIの大幅拡張はCLI・バッチ処理で効果が大きい

.NET 11 Preview 4のライブラリ更新で特に実用的なのが、System.Diagnostics.ProcessのAPI拡張です。Process.Run、Process.RunAsync、Process.RunAndCaptureText、Process.RunAndCaptureTextAsyncなどにより、子プロセスの起動、標準出力・標準エラーの取得、終了待ちを少ないコードで扱えるようになります。(GitHub)

従来のProcess利用では、標準出力と標準エラーを順番に読み込んだ結果、パイプバッファが詰まってデッドロックする失敗が起こりがちでした。Microsoftの解説でも、標準出力・標準エラーを同時にドレインしないとハングする可能性があると説明されています。(Microsoft for Developers)

たとえば、Gitや外部CLIを呼び出す処理では、次のような書き方に整理できます。

using System.Diagnostics;

ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
    "git",
    ["status", "--porcelain"]);

Console.WriteLine(result.StandardOutput);
Console.WriteLine(result.ExitStatus.ExitCode);

移行時は、単純に既存コードを置き換えるのではなく、次の条件を確認してください。

標準出力と標準エラーを分けて扱う必要があるか
タイムアウト時に子プロセスを終了させる必要があるか
出力エンコーディングを固定しているか
終了コードだけでなく、stderrの内容で成否判定していないか
Windows、Linux、macOSで同じ挙動を期待してよいか

特に運用スクリプト、社内CLI、CIジョブ、PDF生成や画像処理など外部プロセスを呼び出すアプリでは、今回のProcess APIを早めに試す価値があります。

ライブラリ更新で確認したい実務ポイント

Process API以外にも、.NET 11 Preview 4のライブラリには実務に関わる改善が複数あります。

System.Text.JsonとF#連携

System.Text.Jsonでは、F#の判別共用体に対するサポートや、Utf8JsonWriter.Resetの改善、ソースジェネレーターの修正などが入っています。F#で定義した型をC#側で扱う構成や、JSONシリアライズを高頻度で行うAPIでは確認対象になります。(GitHub)

注意すべきなのは、JSONの出力形式がアプリ間契約になっているケースです。プレビュー機能を使ってシリアライズ形式を変える場合は、クライアント、OpenAPI定義、メッセージキュー、保存済みJSONとの互換性を必ず確認してください。

RateLimiterのRetryAfter改善

System.Threading.RateLimitingでは、FixedWindowRateLimiterのRetryAfterメタデータやChainedRateLimiter関連の修正が入っています。ASP.NET CoreミドルウェアやHTTPリトライポリシーでRateLimiterを使っている場合、クライアントに返すRetry-Afterヘッダーの扱いを確認するとよいでしょう。(GitHub)

MemoryCacheのOpenTelemetryメトリクス

Microsoft.Extensions.Caching.Memory.MemoryCacheにはOpenTelemetry向けのメトリクスが追加されました。dotnet.cache.requests、dotnet.cache.evictions、dotnet.cache.entries、dotnet.cache.estimated_sizeなどを取得できます。ただし、統計を追跡するにはMemoryCacheOptions.TrackStatistics = trueを設定する必要があります。(GitHub)

キャッシュヒット率を推測で見ていたチームは、Preview 4を使ってメトリクス設計を見直す好機です。特に、APIレスポンスキャッシュ、DBクエリ結果キャッシュ、外部API呼び出し結果のキャッシュでは、ヒット率と退避数を可視化するだけで改善ポイントが見つかりやすくなります。

SDKとCLIの変更で管理者が確認すべきこと

.NET 11 Preview 4のSDKでは、開発体験とCLI基盤にも変更があります。管理者やDevOps担当者は、開発者PCだけでなくCI/CD環境への影響を確認してください。

dotnet watchがMAUI・モバイル開発で使いやすくなる

dotnet watchは、MAUIやモバイルプロジェクトでデバイス選択フローに対応しました。対象フレームワークを選んだ後、利用可能なデバイスを計算し、単一デバイスなら自動選択、複数ある場合は検索可能な対話プロンプトを表示します。(GitHub)

Androidデバイスやエミュレーターに対応し、iOS Simulator向けの信頼性改善も入っています。ただし、iOSプロジェクトでdotnet watchを使うには、現時点で.csprojに<MtouchLink>None</MtouchLink>が必要とされています。(GitHub)

<PropertyGroup>
  <MtouchLink>None</MtouchLink>
</PropertyGroup>

この設定は検証用に限定し、本番ビルド用の構成と混同しないようにしてください。

CLIテレメトリはOpenTelemetryベースへ

dotnet CLIのテレメトリは、従来のApplication Insights依存からOpenTelemetry、Azure Monitor、OTLPエクスポーターを使う形に変更されました。ユーザー向けの挙動は変わらず、オプトアウトは引き続きDOTNET_CLI_TELEMETRY_OPTOUTで行えます。(GitHub)

企業環境では、次のようにCI/CDや開発者端末のポリシーを確認してください。

export DOTNET_CLI_TELEMETRY_OPTOUT=1

Windowsの開発端末、GitHub Actions、Azure Pipelines、社内ビルドサーバーで環境変数の設定方針が統一されていないと、監査時に説明しづらくなります。Preview導入時に、テレメトリ設定も合わせて棚卸ししておくと安全です。

dotnet runのstdout依存スクリプトは確認が必要

dotnet runの「Using launch settings from …」という情報メッセージは、Preview 4でstdoutではなくstderrへ出力されるようになりました。これにより、標準出力をパースするスクリプトでは不要な行を取り除く必要が減りますが、逆にstderrをエラーとして扱う独自ツールでは確認が必要です。(GitHub)

ASP.NET Coreの変更点：OpenAPI、Blazor、Kestrelを重点確認

ASP.NET Coreでは、API仕様、Blazorの運用、TLS診断、レスポンス圧縮など、Webアプリ運用に関係する更新が多く含まれます。

HTTP QUERYがOpenAPI生成に対応

Preview 4では、生成されるOpenAPIドキュメントでHTTP QUERYが認識されるようになりました。QUERYは、検索条件がURLに収まらない、または構造化された検索条件をリクエストボディで送りたい場合に使われる提案中のHTTPメソッドです。OpenAPI 3.2ではquery操作として表現できますが、OpenAPI 3.0/3.1ではx-oai-additionalOperations拡張に出力されます。(GitHub)

API仕様を外部公開している場合は、次の点を確認してください。

利用中のクライアント生成ツールがOpenAPI 3.2に対応しているか
QUERYを使うエンドポイントを既存のAPI GatewayやWAFが許可するか
OpenAPI 3.0/3.1の拡張表現を社内ツールが無視しないか
検索APIでGET、POST、QUERYのどれを採用するかを設計ルールとして明文化しているか

Blazor Serverのサーキット停止要求はデプロイ時に役立つ

Blazor Serverでは、サーバー側からクライアントへサーキットの一時停止を要求できるCircuit.RequestCircuitPauseAsyncが追加されました。Microsoftの説明では、デプロイやロードバランサーの再配置時に、サーキットをプログラム的にドレインする用途が想定されています。(GitHub)

Blazor Serverを本番運用しているチームは、ローリングデプロイ時に次を確認してください。

アクティブなCircuitを追跡するCircuitHandlerを用意するか
デプロイ前に一時停止要求を送る運用フローを作るか
一時停止できなかったCircuitをどう扱うか
ユーザーに表示するメッセージや再接続導線をどう設計するか

Virtualizeのスクロール安定化

Virtualize<TItem>では、画面上部のコンテンツ高さが変化した場合でも表示位置がずれにくくなる改善が入りました。また、AnchorModeにより、チャット、通知一覧、ログビューアのような動的リストで、先頭または末尾を基準に表示を維持しやすくなります。(GitHub)

参照型のアイテムでは、再取得したデータを同じ論理アイテムとして認識させるためにItemComparerの指定が重要です。これを忘れると、データ更新時にスクロール位置が期待通りに維持されない可能性があります。(GitHub)

KestrelのTLS診断とレスポンス圧縮

Kestrelでは、TLSハンドシェイク失敗時の例外をITlsHandshakeFeature.Exceptionで取得できるようになりました。また、従来のTlsClientHelloBytesCallbackは非推奨となり、新しいListenOptions.UseTlsClientHelloListenerを使う形に変更されています。(GitHub)

さらに、レスポンス圧縮ミドルウェアは、圧縮が有効な場合にレスポンス自体が圧縮されていなくてもVary: Accept-Encodingを出力するようになりました。CDNや共有キャッシュを使っている場合、キャッシュキーやヘッダー検証を見直してください。(GitHub)

AI/Copilot開発の観点ではMCPとベクトル検索が注目点

今回の.NET 11 Preview 4は、Microsoft Copilot製品そのものの更新ではありません。ただし、AIアプリやエージェント連携を.NETで実装するチームにとっては、MCP ServerテンプレートとEF Coreのベクトル検索対応が重要です。

ASP.NET Coreでは、これまで別途インストールが必要だったmcpserverプロジェクトテンプレートが.NET SDKに同梱され、dotnet new listから見つけやすくなりました。(GitHub)

dotnet new mcpserver -o MyMcpServer

AIエージェントに社内APIやツールを安全に公開したい場合、MCP Serverテンプレートを使って検証環境を作ると、実装パターンを早く掴めます。ただし、本番導入前には認証、認可、監査ログ、レート制限、機密情報のマスキングを必ず設計してください。

.NET MAUIはCoreCLR既定化が最大の確認ポイント

.NET MAUIでは、.NET 11 Preview 4をターゲットにしてビルドするプロジェクトで、すべてのMAUIプラットフォームの既定ランタイムがCoreCLRになりました。Microsoftは、デバッグ、プロファイリング、Hot Reload、アプリサイズ、パフォーマンスの面でランタイム統一のメリットがあると説明しています。(GitHub)

一方で、Preview 4時点ではモバイルプラットフォーム向けCoreCLRのデバッガーがまだ利用できないため、Visual StudioやVisual Studio CodeでiOS/Androidのデバッグが必要な場合は、プロジェクトに次の設定を追加してMonoランタイムを使う方法が案内されています。(GitHub)

<UseMonoRuntime Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) != 'windows'">true</UseMonoRuntime>

MAUIチームが確認すべきことは次の通りです。

確認項目	理由
CoreCLRとMonoの切り替え	デバッグ可能性と実行時挙動を分けて検証するため
AndroidのMaterial 3表示	`ImageButton`、`DatePicker`、`Entry`、`Slider`などの見た目が変わる可能性があるため
`x:Code`の利用可否	XAML内インラインC#はプレビュー機能で、`EnablePreviewFeatures`が必要なため
`dotnet watch`	Android/iOSのHot Reload検証に関係するため
Xcodeバージョン	AppleプラットフォームではXcode 26.4 Stableがサポート対象として示されているため

MAUIアプリでは、見た目、ビルド、デバッグ、配布パッケージの影響が同時に出やすいです。Preview 4を導入する場合は、既存アプリをそのまま本番移行するのではなく、検証ブランチを作り、主要画面と主要デバイスでスモークテストを実施してください。

EF CoreはSQL Server 2025とAI検索の検証価値が高い

EF Coreでは、SQL Server 2025向けの近似最近傍ベクトル検索に対応しました。VectorSearch()でベクトル距離順の行を取得し、WithApproximate()を加えるとSQL Serverのベクトルインデックスを使うWITH APPROXIMATE句へ変換されます。(GitHub)

var query = await context.Blogs
    .VectorSearch(b => b.Embedding, queryVector)
    .WithApproximate()
    .Take(10)
    .ToListAsync();

RAG、社内文書検索、類似商品検索、ログ類似検索などを.NETとSQL Serverで実装したいチームは、Preview 4でLINQからどのようなSQLが生成されるかを確認する価値があります。特に、近似検索と厳密検索の結果差、インデックス有無による速度差、上位件数の再現性を検証してください。

JSONマッピングは内部改善だがマイグレーション確認が必要

EF CoreのJSONカラムはリレーショナルモデルにより深く統合され、JSONドキュメントの一部更新に使うパスが文字列ではなく構造化されたJsonPath/JsonPathSegmentとして表現されるようになりました。多くのアプリではOwnsOneやOwnsManyのJSONマッピングはそのまま動きますが、プロバイダー作者やマイグレーションスナップショットを読むチームには影響があります。(GitHub)

アップグレード検証では、次を必ず確認してください。

dotnet ef migrations addで不要な差分が出ないか
JSONカラムの部分更新SQLが期待通りか
compiled modelを使っている場合に生成物が変わらないか
既存データのJSON構造と変換処理に影響がないか

dotnet-ef.jsonでEFコマンドの既定値を管理できる

dotnet efは、.config/dotnet-ef.jsonからproject、startupProject、contextなどの既定値を読み取れるようになりました。コマンドライン引数が優先されるため、普段の操作は簡略化しつつ、必要なときだけ上書きできます。(GitHub)

{
  "project": "src/App.Infrastructure",
  "startupProject": "src/App.Api",
  "context": "AppDbContext"
}

dotnet ef migrations add InitialCreate

便利な一方で、.config/dotnet-ef.jsonはリポジトリに含める可能性が高いファイルです。接続文字列、パスワード、個人環境固有の絶対パスは入れないでください。チーム共通のプロジェクトパスとDbContext名だけを管理するのが安全です。

C#とビルド環境の変更点

C#関連では、shebangの位置が不正な場合の診断メッセージが分かりやすくなりました。#!はファイルの1行目の先頭にある必要があり、Preview 4ではこのルールに対して専用のCS9378エラーが出るようになっています。(GitHub)

また、C#/VBのビルドサーバーであるVBCSCompilerに、オプトインのファイルシステムコンパイルキャッシュが追加されました。ROSLYN_CACHE_PATH環境変数、またはMSBuildのfeature flagで有効化できます。ただし、現時点ではキャッシュ削除の仕組みが実装されていないため、キャッシュディレクトリの管理は利用者側の責任です。(GitHub)

CIで同じ入力を繰り返しビルドする環境では試す価値がありますが、次の点に注意してください。

キャッシュディレクトリの容量上限を決める
CIジョブ間でキャッシュを共有する場合はキーを明確にする
警告や/reportanalyzer出力がキャッシュヒット時に再現されない点を理解する
Preview機能として扱い、本番ビルド基盤にいきなり固定しない

管理者・開発者向けの検証手順

.NET 11 Preview 4を安全に試すには、既存環境を壊さない導入手順が重要です。.NETのメジャーリリースは以前のメジャーリリースと並行してインストールされ、アプリは既定では別のメジャーバージョンへ自動ロールフォワードされません。(Microsoft Learn)

検証用ブランチとglobal.jsonを用意する

まず、検証用ブランチを作成し、SDKバージョンをglobal.jsonで固定します。

{
  "sdk": {
    "version": "11.0.100-preview.4.26230.115",
    "rollForward": "disable"
  }
}

Preview 4のSDKバージョンは、公式ダウンロードページで11.0.100-preview.4、フルバージョンは11.0.100-preview.4.26230.115として示されています。(Microsoft)

現在の環境を棚卸しする

作業前に、開発者PC、CIエージェント、ステージングサーバーで現在のSDKとランタイムを確認します。

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

確認結果は、少なくとも次の観点で記録しておくとトラブルシュートが楽になります。

記録する項目	理由
SDKバージョン	CIとローカルでビルド結果が変わる原因を追いやすくするため
Runtimeバージョン	ステージングと本番の差を明確にするため
ワークロード	MAUI、WebAssembly、Android/iOS関連の差分を確認するため
OSとアーキテクチャ	x64、Arm64、Linux Alpineなどで依存関係が変わるため

テスト用にTargetFrameworkを変更する

Preview 4を試すブランチで、対象プロジェクトをnet11.0へ変更します。

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
</PropertyGroup>

複数ターゲットにする場合は、既存のnet8.0やnet10.0を残したまま追加します。

<PropertyGroup>
  <TargetFrameworks>net10.0;net11.0</TargetFrameworks>
</PropertyGroup>

ライブラリを公開している場合は、net11.0を追加する前に、利用者が本当に必要としているかを確認してください。Preview段階で不用意にターゲットを増やすと、パッケージテストやサポート範囲が広がります。

ビルド・テスト・差分確認を順番に実行する

次の順番で確認すると、問題の切り分けがしやすくなります。

手順	コマンド例	確認内容
復元	`dotnet restore`	NuGet依存関係が解決できるか
ビルド	`dotnet build -c Release`	警告、破壊的変更、Analyzerの変化
テスト	`dotnet test -c Release`	単体テスト、統合テスト、非同期処理の失敗
発行	`dotnet publish -c Release`	自己完結型、AOT、単一ファイル発行の挙動
実行	`dotnet run`またはステージング配置	ログ、メトリクス、ヘルスチェック
性能	既存ベンチマーク、負荷試験	レイテンシ、スループット、メモリ、GC

EF Coreを使っている場合は、dotnet ef migrations addを本番DBに向けて実行しないでください。必ずテストDBまたは空の検証環境で、生成されるマイグレーションとSQLを確認します。

展開時の注意点

Preview 4をステージング環境へ入れる場合でも、運用手順を明確にしておく必要があります。

項目	注意点
本番サーバー	Preview SDKやRuntimeを共有本番環境に入れない
IIS / Hosting Bundle	ASP.NET Core Runtimeを検証サーバーに限定して入れる
Docker	Previewタグを使う場合は、検証専用のイメージとして扱う
CI/CD	Preview SDKを使うジョブと通常ジョブを分ける
ロールバック	SDK、Runtime、コンテナイメージ、DBマイグレーションを戻せる状態にする
監視	Runtime Async、Kestrel TLS、MemoryCacheメトリクスの変化を観察する
セキュリティ	Preview導入によるテレメトリ、ログ、認証・認可設定の変化を確認する

特にDBマイグレーションとモバイルアプリのビルド設定は、ロールバックが難しくなりやすい領域です。EF CoreのマイグレーションやMAUIのランタイム切り替えは、アプリ本体のアップグレードとは別の検証項目として扱ってください。

よくある失敗と回避策

Preview SDKを入れたらCIのビルド結果が変わる

Preview SDKをインストールしただけで、環境によって使われるSDKが変わることがあります。回避策は、global.jsonでSDKを固定し、CIジョブごとに利用するSDKを明示することです。

OpenAPI 3.2未対応のツールでQUERYが扱えない

QUERYはOpenAPI 3.2では標準的に表現できますが、OpenAPI 3.0/3.1では拡張として出力されます。クライアント生成ツール、API管理ツール、ドキュメント生成ツールが対応していない場合は、既存のPOST /searchなどを維持する判断も必要です。(GitHub)

MAUIでCoreCLRにしたらデバッグできない

Preview 4時点では、モバイル向けCoreCLRのデバッガーがまだ利用できないと案内されています。デバッグが必要な期間はUseMonoRuntimeでMonoを使い、CoreCLRは実行検証・性能検証用に分けるのが現実的です。(GitHub)

dotnet-ef.jsonに機密情報を入れてしまう

.config/dotnet-ef.jsonは便利ですが、チーム共有されやすい設定ファイルです。接続文字列や認証情報は環境変数、User Secrets、Key Vaultなど別の仕組みで管理し、dotnet-ef.jsonにはプロジェクト名やDbContext名など安全な既定値だけを入れてください。

Process API移行で終了判定が変わる

新しいProcess.RunAndCaptureTextAsyncは便利ですが、既存コードがstderrの特定文字列、終了コード、タイムアウト、プロセスツリー終了などに依存している場合は、置き換えだけでは不具合になります。既存の失敗パターンをテストケース化してから移行してください。

今すぐ試すべきチーム、待つべきチーム

チームの状況	判断
.NETライブラリを公開している	早めに`net11.0`互換性を確認する価値が高い
ASP.NET Core / Blazorを本番運用している	ステージングでOpenAPI、Kestrel、Blazor運用を検証する
SQL Server 2025でAI検索を検討している	EF Coreのベクトル検索を早期検証する価値が高い
.NET MAUIアプリを開発している	CoreCLR既定化とdotnet watchを検証する
安定運用中のLTSシステム	本番導入は待ち、検証環境で情報収集に留める
厳格な監査・規制環境	Preview導入範囲を限定し、テレメトリとログ方針を先に確認する

.NET 11 Preview 4は、正式版への移行準備を始めるには十分に具体的な変更がそろっています。一方で、Previewである以上、本番投入を急ぐ必要はありません。

まずやるべきことは、検証ブランチを作り、global.jsonでSDKを固定し、既存アプリをnet11.0でビルド・テストすることです。そのうえで、ASP.NET Core、EF Core、MAUI、CI/CDのどこに影響が出るかを記録してください。Preview 4の段階で差分を把握しておけば、2026年11月予定の正式リリース時に、移行判断をかなり短時間で行えるようになります。

この記事を書いた人

佐藤健司

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

.NET 11 Preview 4の変更点まとめ｜開発者・管理者が確認すべき移行ポイント

.NET 11 Preview 4の位置づけ

変更点の全体像

Runtime AsyncとJIT最適化で何が変わるのか

Process APIの大幅拡張はCLI・バッチ処理で効果が大きい

ライブラリ更新で確認したい実務ポイント

System.Text.JsonとF#連携

RateLimiterのRetryAfter改善

MemoryCacheのOpenTelemetryメトリクス

SDKとCLIの変更で管理者が確認すべきこと

dotnet watchがMAUI・モバイル開発で使いやすくなる

CLIテレメトリはOpenTelemetryベースへ

dotnet runのstdout依存スクリプトは確認が必要

ASP.NET Coreの変更点：OpenAPI、Blazor、Kestrelを重点確認

HTTP QUERYがOpenAPI生成に対応

Blazor Serverのサーキット停止要求はデプロイ時に役立つ

Virtualizeのスクロール安定化

KestrelのTLS診断とレスポンス圧縮

AI/Copilot開発の観点ではMCPとベクトル検索が注目点

.NET MAUIはCoreCLR既定化が最大の確認ポイント

EF CoreはSQL Server 2025とAI検索の検証価値が高い

JSONマッピングは内部改善だがマイグレーション確認が必要

dotnet-ef.jsonでEFコマンドの既定値を管理できる

C#とビルド環境の変更点

管理者・開発者向けの検証手順

検証用ブランチとglobal.jsonを用意する

現在の環境を棚卸しする

テスト用にTargetFrameworkを変更する

ビルド・テスト・差分確認を順番に実行する

展開時の注意点

よくある失敗と回避策

Preview SDKを入れたらCIのビルド結果が変わる

OpenAPI 3.2未対応のツールでQUERYが扱えない

MAUIでCoreCLRにしたらデバッグできない

dotnet-ef.jsonに機密情報を入れてしまう

Process API移行で終了判定が変わる

今すぐ試すべきチーム、待つべきチーム

この記事を書いた人

コメント

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

.NET 11 Preview 4の変更点まとめ｜開発者・管理者が確認すべき移行ポイント

.NET 11 Preview 4の位置づけ

変更点の全体像

Runtime AsyncとJIT最適化で何が変わるのか

Process APIの大幅拡張はCLI・バッチ処理で効果が大きい

ライブラリ更新で確認したい実務ポイント

System.Text.JsonとF#連携

RateLimiterのRetryAfter改善

MemoryCacheのOpenTelemetryメトリクス

SDKとCLIの変更で管理者が確認すべきこと

dotnet watchがMAUI・モバイル開発で使いやすくなる

CLIテレメトリはOpenTelemetryベースへ

dotnet runのstdout依存スクリプトは確認が必要

ASP.NET Coreの変更点：OpenAPI、Blazor、Kestrelを重点確認

HTTP QUERYがOpenAPI生成に対応

Blazor Serverのサーキット停止要求はデプロイ時に役立つ

Virtualizeのスクロール安定化

KestrelのTLS診断とレスポンス圧縮

AI/Copilot開発の観点ではMCPとベクトル検索が注目点

.NET MAUIはCoreCLR既定化が最大の確認ポイント

EF CoreはSQL Server 2025とAI検索の検証価値が高い

JSONマッピングは内部改善だがマイグレーション確認が必要

dotnet-ef.jsonでEFコマンドの既定値を管理できる

C#とビルド環境の変更点

管理者・開発者向けの検証手順

検証用ブランチとglobal.jsonを用意する

現在の環境を棚卸しする

テスト用にTargetFrameworkを変更する

ビルド・テスト・差分確認を順番に実行する

展開時の注意点

よくある失敗と回避策

Preview SDKを入れたらCIのビルド結果が変わる

OpenAPI 3.2未対応のツールでQUERYが扱えない

MAUIでCoreCLRにしたらデバッグできない

dotnet-ef.jsonに機密情報を入れてしまう

Process API移行で終了判定が変わる

今すぐ試すべきチーム、待つべきチーム

この記事を書いた人

関連記事

コメント

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

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