.NET 11 Preview 5 がリリースされました。まだ正式版ではありませんが、今回の更新を見ると、Microsoft は .NET を引き続きいくつかの方向へ推進していることが分かります。Web 開発をより扱いやすくし、C# の表現力をさらに高め、基盤クラスライブラリをより実際の業務シナリオに近づけ、ランタイム性能も引き続き下層で磨き込んでいます。簡単に言えば、これは「見た目が派手な」更新ではなく、非常にエンジニアリング志向で、実用性の高い更新です。
一、ASP.NET Core：Blazor と Minimal API が実プロジェクトの能力をさらに補完
ASP.NET Core では、重点は主に Blazor、フォーム検証、OpenAPI、Kestrel といった、実際の開発で頻繁に遭遇するポイントに置かれています。たとえば Blazor SSR がクライアント側の検証をサポートするようになりました。つまり、フォーム入力に誤りがある場合でも、必ずしもサーバーの応答を待つ必要はなく、ブラウザー側ですぐにユーザーへフィードバックできます。この体験はユーザーにとってより自然であり、開発者にとっても従来の MVC やフロントエンドフレームワークにおけるフォーム体験により近いものです。
さらに、Blazor は非同期フォーム検証能力も強化されました。これは分かりやすく言うと、たとえば登録時のユーザー名を確認する際に、データベースやリモート API へアクセスして「そのユーザー名がすでに存在するか」をチェックするようなケースです。この種の検証は本質的に非同期です。以前はこうしたシナリオの実装がやや複雑でしたが、今ではフレームワークがより明確なサポートを提供し始めています。
今回の更新では検証エラーのローカライズ機能も追加され、Blazor フォームと Minimal API のどちらでも、異なる言語に応じてエラーメッセージを返しやすくなりました。国際化システムを扱う人にとっては非常に実用的です。たとえば、中国語ユーザーと日本語ユーザーの両方をサポートするシステムなら、フォームのエラーメッセージをすべて英語固定にしておくべきではありません。
QuickGrid にも、かなり実務的な変更があります。ページがインタラクティブレンダリングでなくても、ソートとページングが動作するようになりました。状態はクリックイベントに依存せず、URL のクエリパラメータで保持されます。これによりページは軽量になり、リンクの共有もしやすくなります。
また、Blazor WebAssembly Gateway が追加され、旧 WebAssembly DevServer の代わりになります。本質的にはローカル開発サーバーを、より本物の ASP.NET Core Host に近づけるものです。特に SPA のルーティングリフレッシュ問題、たとえば /orders/42 に直接アクセスするようなケースでは、より自然に処理できるようになり、開発者が多くの fallback ロジックを追加する必要がなくなります。
Kestrel もセキュリティ面で強化され、HTTP/2 と HTTP/3 の trailer header にタイムアウト保護が追加され、接続が長時間終了しないまま残り続けるのを防ぎます。OpenAPI の生成もより正確になり、特に enum、配列 schema、複数のレスポンスタイプの部分で改善されています。総じて、ASP.NET Core は今回は新概念を積み上げるのではなく、実プロジェクトにおける細かな問題を解決しています。
二、C#：言語は「状態モデリング」と「型安全性」をより重視し始めた
今回の C# 更新で最も注目すべきなのは、closed class hierarchies と union declarations です。簡単に言えば、C# は「有限な状態」と「有限な型の集合」を表現するのに、より適した言語へと進化しています。
closed class は「閉じた継承体系」と理解できます。たとえば、あるドアの状態が「閉じている」と「開いている」の 2 種類しかない場合、基底クラスを closed と宣言できます。そうするとコンパイラは、その直接のサブクラスが同じアセンブリ内にしか定義できないことを理解します。これにより、switch 式を書く際に、すべてのケースを処理しているかどうかをコンパイラがチェックしてくれます。この能力は、ステートマシン、業務フロー、ドメインモデルに非常に価値があります。
union declarations はさらに一歩進んでいます。これは union 型を定義できる機能で、その値はあらかじめ決められた複数の型のうちのいずれかしか取れません。たとえば Pet は Dog でも Cat でもよい、という具合です。これにより、コード内で「この値はこれらの型のいずれかだけである」と表現しやすくなり、ラッパークラスや複雑な継承構造を大量に手書きする必要がなくなります。
こうした特性は、業務システムにおいて非常に重要です。多くの業務上の問題は本質的に「状態は有限だが、分岐処理は多い」というものです。たとえば注文状態、支払い結果、審査フロー、エージェントの実行結果などは、こうした方法でモデリングするのに非常に適しています。コードは動くだけでなく、コンパイラが安全網となって、分岐漏れのリスクを減らしてくれます。
Unsafe Evolution はやや低レベル寄りです。その方向性は unsafe の境界をより明確にすることです。ポインタが出てくるすべての場所を unsafe コンテキストで囲む必要はなく、本当に危険な操作、たとえば unmanaged メモリの逆参照や、明示的に unsafe とマークされたメンバーの呼び出しに重点を置きます。これは一般的な業務開発者への影響は大きくありませんが、高性能ライブラリ、低レベルコンポーネント、Interop コードを書く人にとっては、コードの意味をより正確に表現できるようになります。
全体として、今回の C# 更新のキーワードは「型の表現力がさらに高まり、コンパイラが開発者のためにより多くの検査を担えるようになった」です。大規模プロジェクトにとっては、単に数行コードが減ることよりも、こちらのほうがはるかに重要です。
三、.NET Libraries：基盤ライブラリが実際の業務にさらに近づく
ライブラリ更新は非常に実用的で、普段の業務コードでそのまま使える機能が多く含まれています。
まず System.Text.Json が JSON Lines のシリアライズをサポートしました。JSON Lines は非常によく使われており、各行が独立した JSON オブジェクトです。ログ、メッセージストリーム、バッチデータ、AI データセット処理などに特に適しています。以前は自分で一行ずつ書く必要がありましたが、今ではフレームワークレベルで IAsyncEnumerable<T> の JSON Lines 出力を直接サポートしており、ストリーミングデータ処理に便利です。
LINQ にも FullJoin、つまり完全外部結合が追加されました。これはデータ照合、データ同期、在庫照合、設定比較などに非常に有用です。たとえば左側に商品カタログ、右側に販売記録がある場合、マッチしたデータだけでなく、左にあって右にないもの、右にあって左にないものも見たいとき、FullJoin はとても自然です。
EqualityComparer には key-selector による生成機能が追加されました。この種の更新は小さく見えますが、定型コードをかなり減らせます。比較器に対して「オブジェクト全体を直接比較するのではなく、あるフィールドに基づいて比較したい」と、より簡単に伝えられます。
Random にはジェネリック数値 API が追加され、StringBuilder はコピーなしで chunk を移動できるようになりました。これらは性能と使いやすさを高める基盤機能です。一般の開発者は毎日意識することはないかもしれませんが、フレームワークや高性能ライブラリには大きな恩恵があります。
ネットワーク、暗号、リフレクション、Options Validation、Syndication などにも更新があります。たとえば暗号部分では X25519 の鍵合意が追加され、リフレクションでは nullable の underlying type を公開でき、Options の検証では validator 型を受け入れられるようになりました。これらの機能は一見すると驚くようなものではありませんが、具体的なプロジェクトでは回り道のコードをかなり減らしてくれます。
つまり、ライブラリ部分の価値は一言で言えば、「.NET は、これまで開発者が自分でラップしていた小さなツールやテクニックを、標準ライブラリへ少しずつ取り込んでいる」ということです。
四、Runtime：性能最適化が引き続き下層で磨き込まれる
Runtime の今回の核心キーワードもやはり性能です。特に async、JIT、GC、Arm、WebAssembly といった方向です。
今回は runtime-async の suspension と resumption がさらに高速化されました。平たく言うと、非同期メソッドが中断・再開される際に、ランタイムが行う処理が少なくなり、経路が短くなり、オーバーヘッドが低くなったということです。大量に async/await を使うアプリケーションにとって、この最適化は非常に重要です。現在の Web API、データベースアクセス、メッセージキュー、ネットワーク I/O は基本的に非同期に依存しているため、下層の最適化は上位のアプリケーションに自然と影響します。
JIT でも多くの最適化があります。たとえば不要な Span の範囲チェックや null チェックをさらに削除できるようになりました。開発者のコードを変更しなくても、生成されるマシンコードはより短くなり、実行経路もよりすっきりします。こうした最適化は、「コンパイラがこっそりコードをより賢く書き換えてくれる」ようなものです。
Arm intrinsics も引き続き強化されており、.NET が Arm プラットフォームへの対応を継続して進めていることが分かります。現在、クラウドサーバー、モバイルデバイス、エッジコンピューティングでは Arm がますます一般的になっているため、これは決してニッチな方向ではありません。
GC も trimming と compaction の改善が続いています。簡単に言えば、メモリ管理がより精密になり、ランタイムが無駄を減らし、安定性を高めるよう努めているということです。長時間稼働するサーバーアプリケーションでは、GC の挙動がレイテンシ、スループット、リソースコストに直接影響します。
Browser/WebAssembly CoreCLR enablement も注目に値します。WebAssembly の方向は、.NET がブラウザーやクロスプラットフォーム実行のシナリオへ引き続き投資していることを意味します。すべての業務で今すぐ必要になるわけではありませんが、.NET ランタイムの境界がさらに広がっていることを示しています。
Runtime の更新は、通常 Web フレームワークや言語機能ほど直感的ではありませんが、非常に重要です。なぜなら、すべての .NET アプリケーションの土台となる挙動を決めるからです。コード自体は変わらなくても、ランタイムをアップグレードすることで、より良い性能、より低いオーバーヘッド、より安定した挙動を得られる可能性があります。
まとめ：.NET 11 Preview 5 は「工程品質のアップグレード」に近い
全体を見ると、.NET 11 Preview 5 は単発の爆発的な更新ではなく、Web フレームワーク、言語、ライブラリ、ランタイムの 4 つの層を同時に押し進めています。
ASP.NET Core は Web 開発をより扱いやすくし、特に Blazor と OpenAPI を実プロジェクトに近づけています。C# は状態モデリングと型安全性を強化し、複雑な業務表現をより明確にします。ライブラリは JSON Lines、FullJoin、比較器、乱数、暗号など、高頻度で使うツール能力を補い続けています。Runtime は async、JIT、GC、Arm、WebAssembly における下層最適化を引き続き進めています。
業務開発者にとって最も注目すべきなのは ASP.NET Core と Libraries です。これらは日々のコーディング体験に直接影響します。フレームワーク、基盤インフラ、高性能サービスを扱うなら、C# の新機能と Runtime の最適化をさらに深く研究する価値があります。
一言でまとめると、.NET 11 Preview 5 は「技を見せる」ためではなく、.NET をより実際のエンジニアリング、大規模プロジェクト、そして将来のクロスプラットフォーム・高性能・クラウドネイティブ開発シナリオに適したものへと進化させるための更新です。
(Translated by GPT)
元のリンク：https://mp.weixin.qq.com/s/OZzfF6NfOKsYuujC8Eua2A?token=639931501&lang=zh_CN&wt.mc_id=MVP_325642