Microsoft Build 2025のガイド - Iron Softwareを使用する開発者が見るべきもの

.NET 11は、2026年11月のGAの約6ヶ月前に3番目のプレビューリリースに到達し、プレビュー1と2とは違って、大部分は下水設備でありましたが、プレビュー3はリリースの形を実際に感じる場所です。

Runtime Asyncは"プレビューフィーチャーゲート"の実験を中止し、JITは無料のお得な最適化の新しいバッチを取得し、ASP.NET CoreがZstandardを標準で取得し、C# 15の聯合型 - 人々がほぼ10年にわたって質問してきた言語機能を導入します。

これはLTSリリースではなく、.NET 11は次の標準サポートバージョンであり、24ヶ月のサポートが提供され、既にアップグレードするかどうかの計算を変えます。 以下は、開発者として実際に注意を払う価値があり、まだ荒削りな部分のある場所です。

C# 15聯合型: 大きなもの

もしあなたがOneOf<T1, T2>ライブラリを書いていたり、シールドされたレコード階層を手作りしていたり、単にF#開発者を羨んでいる場合、これは見逃せません。C# 15は、一連の固定されたタイプのいずれかである値を宣言するためのunionキーワードを導入します。コンパイラによって完結性が強制されます。 聯合型はプレビュー2で登場しました; プレビュー3はそれに関連するIDEサポートを磨きました。

C#チームのアプローチは、F#の判別聯合よりも聯合型に近い: メンバー型はあなたが別に定義した既存の型であり、聯合宣言内にネストされたタグケースではありません。 聯合は本質的に、オブジェクトを包み込み、それに入るものを制限する構造体です。 呼び出しサイトから見ると、それはネイティブのように感じられます - 成員タイプからunionへの暗黙の変換、Pet.Valueを使った徹底的なswitch式、そしてコンパイラがすべてのケースを見られるときはデフォルトの腕は必要ありません。

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

<Union>
Public Partial Structure Pet
    Implements IUnion

    Public Sub New(dog As Dog)
    End Sub

    Public Sub New(cat As Cat)
    End Sub

    Public Sub New(bird As Bird)
    End Sub
End Structure

Function Describe(pet As Pet) As String
    Return pet.Value Select Case
        Case d As Dog
            Return $"Dog named {d.Name}"
        Case c As Cat
            Return $"Cat ({c.Color})"
        Case b As Bird
            Return $"Bird, {b.Species}"
        ' no default - compiler knows the set is closed
    End Select
End Function

<Union>
Public Partial Structure Pet
    Implements IUnion

    Public Sub New(dog As Dog)
    End Sub

    Public Sub New(cat As Cat)
    End Sub

    Public Sub New(bird As Bird)
    End Sub
End Structure

Function Describe(pet As Pet) As String
    Return pet.Value Select Case
        Case d As Dog
            Return $"Dog named {d.Name}"
        Case c As Cat
            Return $"Cat ({c.Color})"
        Case b As Bird
            Return $"Bird, {b.Species}"
        ' no default - compiler knows the set is closed
    End Select
End Function

利点は本物です：閉じたタイプ、無効な状態がなく、コンパイル時の完全性がNotImplementedExceptionat午前3時ではなく保証されます。 ペットを聯合に追加し、それに対するすべてのスイッチが警告を点灯し、あなたがそれを処理するまで。

短所も実であり、誠実なレビューでフラグを立てる価値があります。 公開されたオブジェクト値のプロパティが臭い - タイプセーフなものの背後に隠していることについてGitHubでの公開討論があります。 公のコンストラクターは、聯合が受け入れる型を暗に定義しているが、それは発見可能でも明示的でもありません。 F#の相互運用性は未解決です（2つのモデルは根本的に異なります）。 そして、より広範な包括性の物語にはまだギャップがあります: 閉じた階層と閉じた列挙型、完全な絵を完成させる2つの提案は、まだ提案です。 聯合だけでも素晴らしいですね。 聯合と閉じた列挙型と閉じた階層とがあれば、それは世代交代のシフトとなるでしょう。 私たちはそこにまで到達していません。

Runtime Async V2およびJITの改善

Runtime Asyncは、非同期/待機が実際にどのように実行されるかについて for .NETの静かな書き換えです。 C#コンパイラーが非同期メソッドごとに状態マシンのクラスを発行する代わりに、ランタイム自体が中断と再開を管理します。 目に見える成果: クリーンなスタックトレース、小さい割り当て、そしてMoveNextフレームをスクロールして自分のコードを見つけなくてもいいデバッガー。

プレビュー3では、ランタイム非同期がEnablePreviewFeaturesの要件を削除します。 あなたはまだ機能スイッチを切り替えます - <Features>runtime-async=on</Features> - しかしもはやすべてのAPI呼び出しをプレビュー領域にオプトする必要はありません。 また、このプレビューではNativeAOTとReadyToRunのサポートも追加されており、JITとAOTのシナリオ間のギャップを埋めます。 継続オブジェクトがより積極的に再利用され、変更されていないローカルは中断後にも保存されません。 非同期が頻繁に使用されるコードパス - 例えば、KestrelパイプラインやEF Coreクエリワーカー - では、割り当ての圧力が実質的に減少します。

JITは、"既存のコードが今はより速い、何もする必要はない"ということ新しいバッチを取得しました:

• xが0または1または2または3または4のようなマルチターゲットスイッチ式は、分岐なしチェックに統合されます。
• 値[^1] + 値[^2] パターンに対する境界チェックがより積極的に除去され、ループ内の一般的な i + cns < len ケースが綺麗に解消されます。
• 符号なし int から float や符号なし int から double へのキャストが、AVX-512 より前の x86 ハードウェアで高速化されます - これはニッチですが、古いマシンを使っている場合には現実的です。

WebAssemblyユーザーは、WebCILペイロードを直接ランタイムにロード、より良いデバッグシンボル、そしてラウンドトリップのオーバーヘッドなしのfloat[] / Span<float> / ArraySegment<float>マーシャリングを得られます。 これらのどれも個別には劇的ではありませんが、Blazor WASM を妥協と感じさせないようにするための積み重ね作業です。

問題はハードウェアの下限です。 .NET 11 は x86/x64 と Arm64 の最小命令セット要件を引き上げます。Apple Silicon とほとんどの Linux SBC は問題ありません - Arm64 の ReadyToRun ターゲットは LSE を追加するだけですが、非常に古い x86 ハードウェアは除外されます。 インプレースアップグレードを想定する前に、フリートを監査してください。

ASP.NET Core と Blazor

Zstandard is the headliner here. ASP.NET Core は、レスポンス圧縮とリクエスト解凍の両方で zstd をサポートし、ミドルウェアを追加するとデフォルトで有効になります。 設定は予想される形状と同じです:

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});

Imports Microsoft.Extensions.DependencyInjection

builder.Services.AddResponseCompression()
builder.Services.AddRequestDecompression()
builder.Services.Configure(Of ZstandardCompressionProviderOptions)(Sub(options)
    options.CompressionOptions = New ZstandardCompressionOptions With {.Quality = 6}
End Sub)

Imports Microsoft.Extensions.DependencyInjection

builder.Services.AddResponseCompression()
builder.Services.AddRequestDecompression()
builder.Services.Configure(Of ZstandardCompressionProviderOptions)(Sub(options)
    options.CompressionOptions = New ZstandardCompressionOptions With {.Quality = 6}
End Sub)

既に zstd に対応しているクライアントに JSON やテキストペイロードを提供する API では、サードパーティライブラリに依存せずに、測定可能な帯域幅の向上が得られます。モバイルや gRPC 近傍のエコシステムにおいて普及しています。 また、特筆すべきこととして、これは Microsoft 社内におけるものではなく、コミュニティの貢献であり、健全なシグナルです。

BlazorのVirtualize<TItem>はついにすべての行が同じ高さであると仮定することをやめます。 これは長い間イライラする要因でした: 可変コンテンツを含むリスト（コメント、チャットメッセージ、テキストを包むもの）が必要とされ、手動で回避策が必要でした。 今、コンポーネントはランタイムで項目を測定します。プレビュー3のリリースでも、以下のようなBlazorのバグが修正されました：Virtualizeのnull参照、オーバーフロー-xによるスクロールコンテナの検出、公開されたWASMアプリでのWeb Workerテンプレート、ResourceCollectionProviderのリーク。 個々には小さいですが、フレームワークが"新しいことが毎リリース出てくる"段階から成熟しつつあることを示す一種のクリーンアップです。

Kestrel は、新しい接続でコントロールストリームと SETTINGS フレームを待たずに HTTP/3 リクエストを処理し始め、初リクエストの待ち時間を短縮します。 HTTP/3 の P99s を測定し、奇妙なコールドスタートの尾部を見ている場合、これが役立ちます。

.NET MAUI

プレビュー 3 における MAUI は、しばらくの間ベータ版のように感じるギャップを埋めることに焦点を当てています。 Mapコントロールは、ピンクラスタリング、カスタムピンアイコン、カスタムJSONスタイリング、およびサークル、ポリゴン、ポリラインのクリックイベントを取得します - すべてのものが実際の制作用の地図UIが必要としており、以前はプラットフォームごとにカスタムハンドラを必要としていました。 組み込みの LongPressGestureRecognizer が利用可能になり、自分で作る必要がなくなりました。 暗黙の XAML 名前空間宣言がデフォルトでオンになり、すべてのファイルの一番上のボイラープレートを削減します。

プラットフォームの均等性が向上しました：Permissions.PostNotificationsがiOSで実装されました（以前はAndroid専用でした）、そしてAndroidはAndroid 17およびAPIレベル37へのプレビューサポートを追加します。

正直な評価: これは安定した、合理的な反復であり、再発明ではありません。 2026年の MAUI は 2023年の MAUI よりもはるかに良い状態ですが、その初期の時代にそれを去った場合、プレビュー 3 だけでは戻ってきません。 既に MAUI を使用している場合、これらは正確にあなたが望んでいる QoL の変更です。

SDK、CLI、.NET watch

これは小さなことが合計されるセクションです。日常のワークフローを本当に変えると思われるいくつかのこと:

.NET sln は、CLI から直接ソリューションフィルター（.slnf）を作成および編集できるようになりました。 モノリポや大規模な Microsoft スタイルのソリューションにおいて、200 プロジェクトの SLN を開いてその中の 3 つに取り組むのは真に費用がかかっています。今では端末からスコープを指定できます:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj

ファイルベースのアプリ（.NET run app.cs ワークフロー）は最終的に #:include をサポートし、これにより C# スクリプトはヘルパーを別々のファイルに分割できます。 Roslyn でのディレクティブのエディター補完と組み合わせて、.NET ベースのファイルアプリを"おもちゃ"から"実際のオートメーションツールに適すもの"に促します - PowerShell や小規模な Python スクリプトが何年もリードしてきたニッチです。

.NET run -e FOO=BAR は、シェルの状態をエクスポートしたり、起動プロファイルを編集せずに、環境変数をコマンドラインで渡すことができます。 小さいですが、異なるASPNETCORE_ENVIRONMENT値を持つ3つのターミナルを開いたことがあるなら、その苦痛がわかります。

.NET watch は、Aspire アプリホストと統合し、クラッシュ後にファイル変更ごとに自動で再起動し、WinForms や WPF において Ctrl+C をより優雅に扱います（永遠のペーパーカット）。 .NET format はマルチターゲットプロジェクト向けに --framework を受け入れます。 MTP モードでの .NET test は --artifacts パスをサポートします。 .NET tool exec / dnx はもはや追加の承認を求めず、ワンオフツールの実行の摩擦点を解消します。

痛点

バランスの取れたレビューが粗削りな面を説明し、プレビュー 3 はそれを有しています。

ツールの物語は粗いです。 Visual Studio 2026 は .NET 10 が出荷されてから 6 ヶ月が経過してもまだプレビュー段階にあり、Microsoft ホスティングビルドエージェントは安定した VS 2026 サポートをまだ提供していません。 .NET 10 SDK パッチリリースの変更で MSBuild 18（VS 2026）が必要とされ、Microsoft が宣伝する semver の保証に違反しています。 Microsoft ホスティングのエージェント上で CI を実行している人は SDK 10.0.4 をピン止めするか、プレビュー ビルド イメージに切り替える必要がありました。 .NET 11 プレビューへの CI パイプライン移行を検討している場合、同じことを期待してください - チーム自身の認識において、プレビュー SDK は 10.0.2 および 10.0.3 で物を壊し、それから安定します。

ランタイム非同期はまだオプトインです。 プレビューフィーチャーゲートがなくなっても、のruntime-async=on を切り替える必要があります。 これは、新しいフィールドコードでは問題ありません。 NuGet で出荷されるライブラリの場合、消費者がスイッチをオンにしていることを前提にできないため、機能のデフォルトがオンになるまでは実質上の利益は延期されます（.NET 11 ではありません）。

ハードウェア要件の増加。 最小 x86/x64 命令セット要件が上がりました。ほとんどのチームは気づかないでしょう。あるチームは - あらかじめ監査しなければデプロイ時間にそれを知ることになります。

STS、ではなく LTS。 .NET 11 は 24 ヶ月間サポートされます。 現在の LTS である .NET 10 は 36 ヶ月間サポートされます。 ゆっくりしたアップグレードのペースを持つショップにとって、.NET 10 は依然としてより保守的な選択であり、.NET 11 の採用は 2028 年にもう 1 つのアップグレードをコミットすることを意味します。STS の採用の理由は機能ですが、 理由に反対するものはカレンダーです。

プレビューとはプレビューを意味します。 これは安定性の否定ではありません - Microsoft のプレビュープロセスは良好です - しかし、プレビュー 3 はリリース候補ではありません。 最も早くて RC1 でプロダクション展開を待ちます。内部ツール、サイドプロジェクト、探求は今の段階で正しい範囲です。

評決

毎日 C# を書いているなら、.NET 11 プレビュー 3 は今週インストールして遊ぶ価値があります - 特に、何年も前の最も重要な言語の変化であるユニオンタイプを手にするために。 ライブラリをメンテナンスしているなら、JIT とランタイム非同期の作業は、編集なしで .NET 11 でコードが速くなることを意味し、これは最高のアップグレードです。 MAUI アプリを出荷しているなら、地図とジェスチャーの作業は本当に進展です。

製品 .NET ワークロードを実行しているなら、答えは退屈なものです: 計画を続け、ウォッチし、そして 11 月に GA をブックマークします。 興奮させるものは着陸していますが、ツーリングチェーン - VS、ビルドエージェント、SDK パッチのリズム - が実際には摩擦を引き起こしており、まだ解決されていません。

| --- |

ソース: .NET ブログの発表, .NET 11 の新機能 (Microsoft Learn), Runtime リリースノート, ASP.NET Core リリースノート, SDK リリースノート, C# 15 でのユニオンタイプの探求。