.NET のリリース周期は加速し続けています
Microsoft は 2024 年 11 月に .NET 9 を Standard Term Support (STS) リリースとして出荷しましたが、改善の勢いが衰える兆しはまったくありません。dotnet/runtime リポジトリだけでも 7,500 件を超えるプルリクエストがマージされており、.NET 9 はこのプラットフォーム史上最速かつ最も高機能なリリースとなっています。
とはいえ「最速」というのは抽象的です。開発者として私たちが知りたいのは、実際に何が変わったのか、それによってコードがどう良くなるのか、そしてアップグレードする価値はあるのかという点です。
本ガイドでは、C# 13 の言語機能からランタイムのパフォーマンス向上、AI 統合、ASP.NET Core の強化に至るまで、.NET 8 から .NET 9 への意味のある改善をすべて分解して解説し、チームにとって的確な判断ができるようにします。
C# 13: 実際に使う言語機能
C# 13 は .NET 9 SDK に同梱され、定型コードを減らし安全性を高めるいくつかの機能を導入しています。
params コレクション
これまで params は配列に限定されていました。C# 13 では params のサポートが、IEnumerable<T> を実装し Add メソッドを持つあらゆるコレクション型 — List<T>、Span<T>、ReadOnlySpan<T> を含む — に拡張されました。これにより、可変引数のメソッドを呼び出す際の不要な配列割り当てが解消されます。
新しい Lock 型とセマンティクス
System.Threading.Lock 型は、従来の lock (obj) { } パターンを、コンパイラが認識する専用の型に置き換えます。新しい lock キーワードは Lock オブジェクトと連携し、より効率的なコードとデバッグサポートの向上を実現します。
ref struct インターフェイス
ref struct 型がインターフェイスを実装したり、ジェネリクスの型引数として使用したりできるようになりました。これにより、型制約のためこれまで不可能だった高性能な span ベースの抽象化といったパターンが実現できます。
部分プロパティと部分インデクサー
部分型において部分プロパティと部分インデクサーが許可されるようになり、ソースジェネレーターの表現力が高まりました。ライブラリ作者は生成コード内で部分プロパティを宣言し、実装はユーザーコード側に置くことができます。これはソースジェネレーター駆動のアーキテクチャを劇的に簡素化するパターンです。
オーバーロード解決の優先順位
ライブラリ作者は [OverloadResolutionPriority] 属性を使って、あるオーバーロードを他より優先すると指定できるようになりました。これにより、既存 API に新しいオーバーロードを追加する際、利用者を壊すことなく、あいまいな呼び出しによるコンパイルエラーを解消できます。
オブジェクト初期化子での暗黙的なインデクサーアクセス
オブジェクト初期化子で ^ 演算子（末尾からのインデックス）を使えるようになり、シーケンスの末尾から要素を設定する際のコレクション初期化がより表現豊かになりました。
ランタイムのパフォーマンス: 1 サイクルも無駄にしない
.NET 9 のパフォーマンスは、実アプリケーションで積み重なる何百もの的を絞った改善の上に成り立っています。主なポイントは次のとおりです。
動的 PGO: キャストと分岐も最適化
.NET 8 で導入された動的なプロファイルガイド付き最適化 (PGO) は、仮想ディスパッチを超えてキャストの最適化にまで拡張されました。JIT は obj is T や (T)obj の操作中に最も頻繁に現れる型を追跡し、それらの型に対する高速パスを生成します。マイクロベンチマークでは、一般的なパスにおける型チェック操作が最大 4 倍高速に実行されます。
ループ最適化: 強度低減とダウンカウント
JIT は配列の反復ループに対して強度低減を実行し、インデックスベースのアクセスをポインタ演算に変換するようになりました。自動的なダウンカウント（cmp + jl を単一の jns に置き換える）と組み合わさることで、タイトなループは反復ごとに 1 命令を削減します。大規模なコレクションを走査するホットパスのループでは、これが急速に積み重なります。
境界チェックの除去: これまで以上に賢く
JIT の境界チェック解析は、これまで見逃されていたパターン — 逆方向のインデックス、複雑なループ条件、先行する長さチェックと相互作用する span ベースのアクセス — を扱えるようになりました。境界チェックが減れば、ループはより引き締まり、予測ミスの起こり得る分岐も減ります。
ガベージコレクション: 動的な適応
サーバー GC にはアプリケーションサイズへの動的な適応が既定で有効な状態で追加されました。GC は固定的なヒューリスティックではなく、アプリケーションの実際のメモリパターンに基づいて挙動を調整し、スループットを犠牲にすることなくメモリ集約型ワークロードのポーズ時間を短縮します。
ベクトル化と Arm64
Arm64 のコード生成には大きな注力がなされ、SIMD ベクトル化の拡張と Arm 固有命令のより良い活用が図られました。Graviton や Ampere プロセッサ上で動作するクラウドワークロードにとって、これは直接的なコンピューティングコストの低減につながります。
ASP.NET Core 9: 既定で安全、設計で高速
ASP.NET Core 9 はセキュリティの改善を自動化しつつ、パフォーマンスの上限をさらに押し上げます。
組み込みの OpenAPI ドキュメント生成
新しい Microsoft.AspNetCore.OpenApi パッケージは、Swashbuckle や NSwag を必要とせずに OpenAPI ドキュメントの生成を組み込みで提供します。minimal API、コントローラー、型注釈からのメタデータが自動的に生成された OpenAPI 仕様に反映され、依存関係の変動を減らし互換性を向上させます。
静的アセットのフィンガープリント
静的ファイル（JavaScript、CSS）のビルド時および発行時の最適化に、自動的なフィンガープリント付きバージョニングが含まれるようになりました。キャッシュバスティングが自動化され、古いアセットに起因するよくあるバグの原因が解消されます。
Blazor の改善
新しい Hybrid および Web App テンプレートがプロジェクトのセットアップを簡素化します。コンポーネントのレンダーモード検出がデバッグを改善します。Blazor Server の再接続体験は再設計され、ネットワーク接続が切断された際にもより滑らかな体験をユーザーに提供します。
Native AOT の拡張
ASP.NET Core における Ahead-of-time コンパイルのサポートが拡張され、コールドスタートのレイテンシとメモリフットプリントが削減されました。コンテナ化されたマイクロサービスにとって、Native AOT はより小さなイメージとより速いスケールアウトを意味します。
Linux の HTTPS 開発証明書
開発時の HTTPS 用に Linux 上で信頼された開発証明書をセットアップすることが大幅に容易になりました。Linux ワークステーションで開発するチームにとっての生活の質の向上です。
AI ビルディングブロック: .NET が AI にネイティブ対応
.NET 9 は統一された AI 抽象化レイヤーを導入し、.NET を AI 駆動アプリケーションのための一流のプラットフォームとして位置づけます。
Microsoft.Extensions.AI
AI サービス — 小規模および大規模言語モデル（SLM および LLM）、埋め込み、ベクトルストア — とやり取りするための一連の C# 抽象化です。これらのパッケージは、OpenAI、Azure OpenAI、あるいは ONNX Runtime を介したローカルモデルのいずれを呼び出す場合でも、一貫したプログラミングモデルを提供します。
Tensor<T> と TensorPrimitives
新しい Tensor<T> 型は、ML.NET、TorchSharp、ONNX Runtime とのゼロコピー相互運用を伴う効率的な多次元データ操作を提供します。TensorPrimitives は 40 から約 200 の SIMD 最適化された操作へと拡張され、推論と特徴量エンジニアリングに必要な数値プリミティブをカバーします。
ML.NET 4.0
ML.NET 4.0 は、Stream としての ONNX モデル読み込み、GPT・Llama・Phi・Bert モデル向けの新しいトークナイザーサポート、そして Llama および Phi モデルファミリーの実験的な TorchSharp 移植をもたらします。オンデバイスまたはインプロセスの AI 推論を必要とする .NET アプリケーションを構築しているなら、これはそれを実用的にするリリースです。
Tokenizers ライブラリ
Microsoft.ML.Tokenizers ライブラリは、Tiktoken（GPT-3/4/4o/o1）、Llama、CodeGen、Phi2、Bert のトークナイザーをすぐに使える形でサポートするようになりました。これはコンテキストウィンドウの管理、トークンコストの計算、ローカルモデル向けのテキスト前処理に不可欠です。
EF Core 9: Cosmos DB とプリコンパイル済みクエリ
Entity Framework Core 9 は 2 つの領域に注力しています。すなわち、Azure Cosmos DB for NoSQL とのより深い統合と、Ahead-of-time コンパイルに向けた基盤づくりです。
- Cosmos DB プロバイダー: NoSQL プロバイダーの大幅な更新。LINQ 変換の改善、階層パーティションキーのサポート、スループット管理の向上を含みます。
- プリコンパイル済みクエリ: ランタイムのクエリコンパイルのオーバーヘッドを解消する AOT コンパイル済みクエリへの一歩。サーバーレスおよびコンテナ化された環境でのコールドスタート性能にとって重要です。
- 複合型の改善: 所有エンティティと値オブジェクトの扱いが向上し、リッチなドメインモデルに必要な定型コードが削減されます。
.NET MAUI: パフォーマンスとデスクトップ統合
.NET 9 における .NET MAUI は、パフォーマンスとデスクトップ機能を優先しています。
- CollectionView と CarouselView は iOS および Mac Catalyst 上で、より高性能な新しい実装を受けました。
- HybridWebView により、React、Vue.js、Angular のコンテンツを MAUI アプリ内に埋め込むことがより容易になります。
- Windows デスクトップアプリケーション向けの TitleBar コントロールにより、ネイティブなタイトルバーのカスタマイズが可能になります。
- Native AOT とトリミングの改善により、モバイルでのアプリサイズと起動時間が削減されます。
.NET 8 と .NET 9: 項目別比較
| カテゴリ | .NET 8 | .NET 9 |
|---|---|---|
| リリース種別 | LTS（3 年サポート） | STS（2 年サポート） |
| C# バージョン | C# 12 | C# 13 |
| 動的 PGO | 仮想／インターフェイスディスパッチ | キャスト、分岐、整数プロファイリングを追加 |
| AI 抽象化 | なし（NuGet パッケージのみ） | Microsoft.Extensions.AI、Tensor<T> |
| OpenAPI | サードパーティ（Swashbuckle） | 組み込みの Microsoft.AspNetCore.OpenApi |
| GC モード | 固定のサーバー／ワークステーション | アプリサイズへの動的適応 |
| ref struct | インターフェイスを実装できない | インターフェイスを実装可能、ジェネリック引数として使用可能 |
| ループ最適化 | 基本的なループ認識 | 強度低減、ダウンカウント |
| LINQ | 標準演算子 | CountBy、AggregateBy を追加 |
| Native AOT | 限定的な ASP.NET サポート | 拡張された ASP.NET サポート |
アップグレードすべきか？
すぐにアップグレードすべきケース:
- パフォーマンスに敏感なワークロードを運用しており、JIT、GC、ループ最適化の恩恵を受けられる場合。
- AI 駆動の機能を構築している場合。新しい
Microsoft.Extensions.AI抽象化とトークナイザーサポートだけでも移行の価値があります。 - Arm64（Graviton、Ampere）にデプロイしている場合。Arm64 のコード生成の改善は直接的にクラウドコストを削減します。
- NuGet ライブラリを保守している場合。
[OverloadResolutionPriority]や部分プロパティといった C# 13 の機能はライブラリ作成の体験を向上させます。
スケジュールを検討すべきケース:
- LTS サポートが必要な場合。.NET 8 は 2027 年 11 月までサポートされます。組織がコンプライアンス上 LTS を必要とする場合は、新規プロジェクトには .NET 9 を採用しつつ、.NET 10（LTS）への移行を計画してください。
- まだ .NET 9 ターゲットを追加していないサードパーティパッケージに依存している場合。移行前に重要な依存関係が
net9.0をサポートしているか確認してください。
nopCommerce および Umbraco ユーザーの場合:
- nopCommerce 4.90 は .NET 9 をネイティブにターゲットしています。4.80 以前を使用している場合、4.90 にアップグレードすればこれらの改善がすべて自動的に得られます。
- Umbraco 14+ は .NET 9 上で動作します。SplatDev の 20 を超える Umbraco プラグインはすべて .NET 9 互換性のために移行・テスト済みです。
アップグレードの手順: 実践的なチェックリスト
- .NET 9 SDK をインストール: dotnet.microsoft.com からダウンロードします。
- ターゲットフレームワークを更新: すべての .csproj ファイルで
<TargetFramework>net8.0</TargetFramework>を<TargetFramework>net9.0</TargetFramework>に変更します。 - パッケージ参照を更新: すべての NuGet パッケージを、.NET 9 をサポートする最新バージョンにアップグレードします。
- 破壊的変更に対処: 公式の破壊的変更一覧を確認します。ほとんどのアプリケーションにとって影響範囲は小さいです。
- 新機能を有効化: C# 13 の機能を使うには
<LangVersion>13</LangVersion>を設定します。 - テストスイートを実行: 単体テスト、統合テスト、E2E テストにわたる完全な回帰テストを行います。
- 前後でベンチマーク: BenchmarkDotNet を使って、特定のワークロードにおけるパフォーマンス改善を定量化します。
結論
.NET 9 は見出しを飾るような革命的なリリースではありません。すべてを静かに良くするタイプのリリースです。ループはより少ない命令で実行され、型チェックは高速パスに当たり、GC はアプリケーションに適応し、API 仕様は自動的に生成されます。これらの改善は、あらゆる HTTP リクエスト、あらゆるデータベースクエリ、あらゆる Blazor のレンダーサイクルで積み重なります。
いまだ .NET 6 や .NET 7 を使っているチームにとって、.NET 6 から .NET 9 までの累積的な差分は劇的です。一般的なワークロードで 20〜40% のパフォーマンス向上、近代化された C# 言語、組み込みの AI 統合、そしてコンテナに最適化されたランタイムが得られます。
SplatDev では、2009 年のバージョン 1.0 以来 .NET 上で開発を続けてきました。Windows 専用から真のクロスプラットフォームへ、クローズドソースから完全なオープンソースへ、エンタープライズ専用からクラウドネイティブへと、このプラットフォームが成長するのを見てきました。.NET 9 は私たちがこれまで扱ってきた中で最も高機能なバージョンであり、すでに本番ワークロードを出荷しています。
.NET スタックをアップグレードする準備はできていますか？ SplatDev は、nopCommerce や Umbraco からカスタムのエンタープライズアプリケーションまで、.NET 移行サービス、パフォーマンス最適化、フルスタック開発を提供しています。
または直接お問い合わせください: [email protected]