.NET 11の新機能とリリース日｜サポート期限・C# 15・.NET 10との挙動差を実測【RC1】

.NET 11は2026年9月8日にRC1（リリース候補1）が公開され、正式版（GA）は2026年11月10日の予定です。サポートはSTS（標準期間サポート）で、2028年11月9日まで受けられます。この記事では、2026年10月13日時点の公開状況とサポート期限、C# 15とランタイムの新機能を、dotnet/coreの.NET 11リリースノートとMicrosoft Learnの「.NET 11の新機能」に沿って整理します。.NET 10から上げたときに結果が変わるコードは、.NET 10.0.12と11.0.0-rc.1で実際に動かして比べました。

まとめ：.NET 11の要点（2026年10月時点）

• 現在の版：11.0.0-rc.1（SDK 11.0.100-rc.1.26425.128）。RC1のGo-Liveサポートは2026年10月13日までで、次のビルドへの更新が前提です。
• 正式版：2026年11月10日予定。同日から3日間の.NET Conf 2026でリリースされます。
• サポート期限：LTSではなくSTSで、2028年11月9日まで。.NET 10（LTS）の2028年11月14日と5日しか違いません。
• C# 15：net11.0の既定言語バージョン。共用体型（union）、closed階層、コレクション式の引数などがLangVersion指定なしで使えます。
• 上げる前に確認：doubleからdecimalへの変換、Math.Roundの桁指定、byteやshortへの変換で、.NET 10と結果が変わります。x86/x64の最低CPU要件もx86-64-v2に上がりました。

.NET 11のリリース日と現在の版

.NETは毎年11月にメジャー版を出し、その前の2月から月1回のペースでプレビューを重ねます。.NET 11の公開履歴は次のとおりです（dotnet/coreのreleases.jsonより）。

Preview 8は出ておらず、Preview 7の次がRC1でした。dotnet/coreのreleases.mdは、RC1のサポート終了日を2026年10月13日としています。2026年10月13日時点のreleases.jsonでは、最新はまだRC1です。Go-Liveで本番に入れた場合は、次に出るビルドとGA版へ順に上げる計画を立ててください。

GA日は、.NETチームの.NET Conf 2026の告知で、11月10日から12日のオンライン開催の中で.NET 11を出すと書かれています。

.NET 11のサポート期限：STSで2028年11月9日まで

.NET 11はLTSではなくSTSです。.NETのリリースポリシーではSTSのサポート期間が2年、LTSが3年と定められており、.NET 11は2026年11月10日から2028年11月9日までサポートされます。

.NET 8・9・10・11のサポート終了日

STSが2年になったため、1年後に出た.NET 11の終了日は.NET 10より5日早いだけです。「STSはサポートが短いから避ける」という判断は、この組み合わせでは成り立ちません。.NET 8と.NET 9は.NET 11のGA日と同じ2026年11月10日に終わるので、GAを待ってから移行を始めると、検証期間を取らずに期限切れの版で動かすことになります。.NET 10側の期限と新機能は.NET 10（LTS）とは？サポート期限・新機能・C# 14と.NET 8/9からの移行を解説にまとめています。

C# 15の新機能：RC1で既定になった言語機能

RC1のC#リリースノートによると、net11.0を対象にしたプロジェクトではC# 15が既定の言語バージョンになりました。以下のコードは、SDK 11.0.100-rc.1.26425.128で作ったコンソールプロジェクトにLangVersionを追加せずに書き、ビルドと実行を確認したものです。コメントは実行時の出力です。

コレクション式の引数 with(…)

コレクション式の先頭にwith(...)を置くと、コンストラクターへ容量や比較子を渡せます。new HashSet<string>(StringComparer.OrdinalIgnoreCase)のように書き分けていた初期化を、コレクション式にまとめられます。

string[] values = ["one", "two", "three"];
List<string> names = [with(capacity: values.Length * 2), .. values];
HashSet<string> set = [with(StringComparer.OrdinalIgnoreCase), "Hello", "HELLO", "hello"];
Console.WriteLine($"{names.Count} {names.Capacity} {set.Count}"); // 3 6 1

共用体型（union）とclosed階層による網羅性検査

C# 15の目玉は、値が「いずれか1つの型」であることを表す共用体型です。unionで宣言すると各ケース型からの暗黙変換が付き、switch式がすべてのケースを扱っているかをコンパイラが検査します。closedを付けたクラスは宣言したアセンブリ内でしか派生できないため、直接の派生型をすべて扱うswitch式では既定アーム（_）が要りません。

Console.WriteLine(Describe(new Failure(404)));  // Error 404
Console.WriteLine(Show(new Open(40)));          // 40% open

static string Describe(Result result) => result switch
{
    Success(var message) => message,
    Failure(var code) => $"Error {code}",
};

static string Show(GateState state) => state switch
{
    Closed => "closed",
    Open(var percent) => $"{percent}% open",
};

public record Success(string Message);
public record Failure(int ErrorCode);
public union Result(Success, Failure);

public closed record class GateState;
public record class Closed : GateState;
public record class Open(float Percent) : GateState;

closedクラスは暗黙的にabstractになり、sealedやstaticと併用できません。派生の制限は1段だけで、closedでない子クラスは他のアセンブリから派生できます。孫の代まで網羅性検査を効かせたいときは、中間のクラスにもclosedを付けます（C# 15の新機能）。

unionの保存形式と値型ケースのボックス化

公式の紹介では見えにくいのが、unionの保存方法です。言語リファレンスのUnion typesによると、union宣言はコンパイラがstructに変換し、中身はobject?型のValueプロパティ1つに入れます。ケース型がintなどの値型なら、代入のたびにボックス化が起きます。

Console.WriteLine(typeof(IdOrName).IsValueType); // True
IdOrName v = 42;
Console.WriteLine(v.Value?.GetType().Name);       // Int32

long before = GC.GetAllocatedBytesForCurrentThread();
for (int i = 0; i < 1000; i++) { IdOrName x = i; _ = x; }
Console.WriteLine(GC.GetAllocatedBytesForCurrentThread() - before); // 24000

public union IdOrName(int, string);

1,000回の代入で24,000バイト、1回あたり24バイトのヒープ割り当てが出ました（Releaseビルド・x64）。影響は「1回24バイト×作る回数」で見積もれます。1秒に100万回作る処理なら毎秒約24MBの割り当てになり、GCの回数に直接響きます。ホットパスで値型を多く入れる用途では、事前に割り当て量を測ってください。そうした箇所では、[Union]属性を付けた自作の型にHasValueとTryGetValueを実装する「非ボックス化アクセスパターン」を使うと、パターンマッチ時のボックス化を避けられます。ボックス化そのものの仕組みと計測方法はC#のボックス化とは？起きる場面と割り当てバイト数を.NET 10で実測・回避方法まで解説で扱っています。

System.Text.Jsonもunionに対応しました。既定ではJSONのトークンの種類（数値か文字列か）でケースを選ぶので、intとstringのunionは追加設定なしで往復できます。

using System.Text.Json;

Console.WriteLine(JsonSerializer.Serialize(new Sample("s1", 35))); // {"Id":"s1","Value":35}
var r = JsonSerializer.Deserialize<Reading>("\"offline\"");
Console.WriteLine(r.Value?.GetType().Name);                         // String

public union Reading(int, string);
public record Sample(string Id, Reading Value);

ケースが2つともオブジェクトの場合はトークンの種類で区別できません。.NET 11のライブラリの新機能によると、この場合はJsonUnionAttributeとJsonUnionTypeStructuralClassifierでプロパティ名から判別させます。該当するケースが0個か複数ならJsonExceptionになります。

ラベル付きbreak/continueと拡張インデクサーの記述例

入れ子のループを抜けるためにフラグ変数やgotoを使っていた箇所は、ループにラベルを付けてbreak outer;と書けます。C# 14で入ったextensionブロックには、インデクサーも宣言できるようになりました。

int[,] grid = { { 0, 1, 0 }, { 0, 0, 2 } };
int found = -1;
outer: for (int row = 0; row < 2; row++)
{
    for (int col = 0; col < 3; col++)
    {
        if (grid[row, col] == 1) continue outer;
        if (grid[row, col] == 2) { found = row * 10 + col; break outer; }
    }
}
Console.WriteLine(found);       // 12

IEnumerable<int> numbers = Enumerable.Range(1, 10);
Console.WriteLine(numbers[2]);  // 3

public static class SequenceIndexer
{
    extension(IEnumerable<int> sequence)
    {
        public int this[int index] => sequence.ElementAt(index);
    }
}

メモリ安全性の新ルールはpreview指定が必要

C# 15の新機能一覧にある「Memory safety」は、RC1でも既定の言語機能に入っていません。ポインター型の宣言やfixedをunsafeなしで書ける緩和とunsafe(式)は、<LangVersion>preview</LangVersion>と<AllowUnsafeBlocks>true</AllowUnsafeBlocks>の両方を指定すると使えます。呼び出し側にunsafeを求める新ルールまで使うには、さらにupdated-memory-safety-rules機能フラグが要ります。本番コードで前提にする段階ではありません。

ランタイムの変更：Runtime AsyncとCPU要件

Runtime Asyncの仕組みと有効化・無効化の設定

Runtime Asyncは、コンパイラが生成していたasyncのステートマシンを、ランタイム側の中断・再開の仕組みに置き換える機能です。.NET 11のランタイムの新機能によると、ランタイムライブラリ自体がruntime-async=onでビルドされ、ステートマシンを含まなくなりました。自分のコードで使う場合はプロジェクトファイルで有効にします。

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <Features>runtime-async=on</Features>
</PropertyGroup>

位置付けはプレビュー機能のままですが、net11.0ではEnablePreviewFeaturesの指定が要らなくなりました。以前のDOTNET_RuntimeAsync環境変数は削除されたので、無効にしたいときはプロジェクトファイルに<UseRuntimeAsync>false</UseRuntimeAsync>を書きます。

CPU要件：x86/x64の最低要件とArm64のReadyToRun対象

見落とすと起動しなくなるのがこの変更です。最低ハードウェア要件の変更によると、.NET 11はx86/x64の最低要件をx86-64-v1からx86-64-v2へ上げました。満たさないx86/x64のCPUでは「The current CPU is missing one or more of the baseline instruction sets.」のようなメッセージを出して起動に失敗します。Arm64の最低要件は変わらず、変わったのは事前コンパイル（ReadyToRun）の対象だけです。

x86-64-v2はSSE4.2やPOPCNTを含む水準で、Learnは「Windows 11が要求する水準で、2013年ごろにサポートが終わった旧型チップ以外は該当する」と説明しています。CPU機能を絞った仮想マシンや古いエミュレーター、組み込み機器では事前に確かめてください。Arm64では、LSEを持たないWindows 10 IoT機器なども引き続き動きます。ReadyToRunの対象に届かないCPUでは、事前コンパイル済みのコードの代わりにJITが働くぶん起動が遅くなることがあります。

JITの性能改善とMAUI・WebAssemblyのCoreCLR対応状況

JITは境界チェックの除去や脱仮想化を進め、対応CPUではHalfの演算にハードウェアFP16命令を使います。性能改善の全体は、2026年9月15日公開のPerformance Improvements in .NET 11が分野別のベンチマーク付きで解説しています。RC1ではUnix上でクラッシュ時の診断情報をプロセス内で記録する仕組みも入りました。

.NET MAUI 11の新機能によると、.NET 11を対象にしたMAUIアプリではCoreCLRが既定のランタイムです（Preview 4で全プラットフォームの既定になり、Preview 7からNativeAOTが公開時の選択肢に加わりました）。CoreCLR on WebAssemblyはライブラリのテストスイートを通す段階です。Blazor WebAssemblyの既定ランタイムがMonoから切り替わったとは、Learnには書かれていません。JITとAOTの違いはJITコンパイラとは？仕組み・AOTとインタプリタとの違いと主要言語の実装で解説しています。

ライブラリ・SDKの主な追加

ライブラリ：FullJoin・Zstandard・10進浮動小数点型・Process

• LINQのFullJoin：.NET 10のLeftJoin／RightJoinに続き、完全外部結合が加わりました。EF Core 11はこれをSQLのFULL OUTER JOINに変換します。LINQの基本はLINQの読み方は「リンク」｜C#・.NETの統合言語クエリを基礎から解説を参照してください。
• Zstandard圧縮：ZstandardStreamなどがSystem.IO.Compression名前空間に入り、GZipStreamやBrotliStreamと同じ使い方ができます。
• 数値型：IEEE 754の10進浮動小数点型Decimal32／Decimal64／Decimal128と、ジェネリックなComplex<T>が追加されました。
• プロセス操作：Processに実行して出力を受け取るヘルパー、TryGetProcessById、シグナル送信と終了状態の確認が加わりました。
• System.Text.Json：前述のunionに加え、closed階層の派生型を推論して多態シリアル化する機能と、JSON Lines出力に対応しました。

SDK：dotnet run -e・#:include・MCPサーバーテンプレート

• dotnet run -e ASPNETCORE_ENVIRONMENT=Developmentのように、環境変数をコマンドラインから渡せます。
• ファイルベースアプリ（dotnet run app.cs）で#:include helpers.csと書き、複数ファイルに分割できます。RC1ではNativeAOTのビルド結果の再利用にも対応しました。
• コンテナーの公開（dotnet publishでのイメージ作成）は、SOURCE_DATE_EPOCHを固定すれば同じ入力から同じダイジェストのイメージを出力します。送信先に同じマニフェストが既にあれば、レイヤーの処理を省いてタグだけ付けます。
• MCPサーバーのテンプレート（mcpserver）とBlazorのWeb Worker用テンプレート（blazorwebworker）がSDKに同梱されています。RC1 SDKのdotnet new listで両方が表示されることを確認しました。C#でのMCP実装はMCP C# SDKの使い方｜v2.2でサーバー・クライアントを作る手順と1.xからの移行で扱っています。

ASP.NET Core・Blazor・EF Core 11・MAUI 11の変更点

• Blazor：相対パスで遷移できるNavigateTo、QuickGridのOnRowClick、全レンダリングモードでの非同期フォーム検証が加わり、RC1では実験的なBlazor AIコンポーネントも出ました。採用判断はBlazorの将来性は？2026年の採用判断と.NET 10時代のWeb開発を解説で扱っています。
• Minimal API／OpenAPI：共用体型の入出力と非同期検証に対応しました。生成されるOpenAPIドキュメントは既定で3.2になります。3.2に未対応のツールを使う場合はOpenApiVersionで3.1を指定してください。
• EF Core 11：TPT／TPC継承での複合型とJSON列、SQL ServerのVECTOR_SEARCH()とベクトルインデックス（実験的機能）、Cosmos DBのトランザクションバッチに対応しました。
• .NET MAUI 11：Androidでマテリアル3が使えるようになり、地図のピンのクラスタリングにも対応しました。対応Androidは後述のとおりAPI 24以上に上がります。MAUIの採用判断は.NET MAUIの将来性は？サポート期限・Xamarin後継・Flutter比較から2026年の採用を判断するを参照してください。

.NET 10と.NET 11で結果が変わるコード（実行して比較）

Microsoft Learnの「.NET 11の破壊的変更」には、例外にならずに値だけが変わる「動作の変更」が多く並びます。コンパイルが通るので、テストの期待値か本番の出力で初めて気づく種類です。数値まわりの4件を、同じコードを.NET 10.0.12と11.0.0-rc.1（macOS x64）で実行して比べました。

double d = 1.23, big = 298, neg = -42, s = 65578;
Console.WriteLine((decimal)d);
Console.WriteLine(Math.Round(655.925, 2, MidpointRounding.AwayFromZero));
try { Console.WriteLine(Math.Round(1.5, 16)); }
catch (ArgumentOutOfRangeException) { Console.WriteLine("ArgumentOutOfRangeException"); }
Console.WriteLine(unchecked((byte)big));
Console.WriteLine(unchecked((ushort)neg));
Console.WriteLine(unchecked((short)s));

decimal変換とMath.Roundの丸め方式の変更

decimalと2進浮動小数点型の相互変換は、元の値を正確に1回だけ丸める方式になり、互換スイッチはありません。1.23はdoubleでは1.229999…として保存されているので、.NET 11はその値をそのままdecimalへ移します。Math.Round(655.925, 2)も同じ理由で、保存値655.92499…から正しく丸めた655.92になりました。Math.Roundの変更によると、旧方式はランダムな入力の約5%で誤った結果を返しており、桁数の上限（doubleは15、floatは6）も撤廃されました。

金額や数量をdoubleで受けてからdecimalへ変換している箇所は、テストの期待値が一致しなくなります。1.23mのように最初からdecimalリテラルやdecimal.Parseで扱う形に直すのが、Learnの推奨する対処です。Math.Roundのうちdecimalを受け取るものと、桁数を取らないMath.Round(double)は変更されていません。

浮動小数点からbyte・short・charへの変換の飽和処理

浮動小数点から小さい整数型への変換の変更により、sbyte・byte・short・ushort・charへのunchecked変換は、範囲外の値を最小値か最大値に揃える（飽和させる）ようになりました。これまで範囲外の値の変換結果は保証されておらず、ランタイム・CPUアーキテクチャ・命令セットによって違いました。今回の.NET 10（macOS x64）ではintを経由して下位ビットだけが残る動きになり、298が42になっています。.NET 11ではNaNは0になります。以前の結果に近づける候補として、公式はdouble.ConvertToIntegerNative<ushort>(x)と、unchecked((ushort)(int)x)のように中間の型を明示する書き方を挙げています。ただし、どちらも過去のすべての実行環境と同じ結果になる保証はないため、実際の入力値と実行環境で確かめてください。checked変換は従来どおりOverflowExceptionを投げます。この変更はCoreCLRとNativeAOTが対象で、Monoは含まれません。

Microsoft.Extensionsの9パッケージが共有フレームワーク入り（NU1510）

上げて最初にビルドしたとき出やすいのがこの警告です。Microsoft.Extensions.Options、Logging.Abstractions、DependencyInjection.Abstractionsなど9つのパッケージが.NET 11の共有フレームワークに含まれ、PackageReferenceで明示しているとNU1510警告が出ます。net11.0のプロジェクトにMicrosoft.Extensions.Options 10.0.0を参照させてビルドすると、実際にwarning NU1510が出ました。net11.0だけを対象にするならPackageReferenceを削除します。net10.0;net11.0のように複数を対象にするプロジェクトでは、古い側に参照が必要なのでNU1510は出ず、対応は不要です。警告をエラー扱いにしているCIでは、ここでビルドが止まります。

BackgroundServiceの例外伝播と終了コードの変更

BackgroundServiceExceptionBehavior.StopHostの設定でBackgroundServiceが例外を投げたとき、これまでIHost.RunAsyncは正常に戻り、プロセスは終了コード0で終わるのが普通でした。.NET 11では例外が再スローされ、通常は0以外の終了コードになります。終了コードで再起動を判断するコンテナーやsystemdの設定は見直してください。ホストの構成は.NET Generic Host（汎用ホスト）とは？CreateApplicationBuilderでDI・設定・ログ・常駐化【.NET 10】で解説しています。

和暦・Android API 24・日付解析・アーカイブ検証の互換性変更

• JapaneseCalendar.MinSupportedDateTimeが1868-09-08から1868-10-23に訂正され、その間の日付は無効になりました。明治改元前後の日付を和暦で扱う処理は確認が必要です。
• .NET MAUIの最低対応がAndroid API 24（Android 7.0）に上がり、API 21〜23の端末にはインストールできません。
• DateOnly／TimeOnlyのTryParse系は、不正なDateTimeStylesや書式指定子を渡すとfalseではなく例外を投げます。
• ZIPのエントリー読み込みでCRC32を、TARの読み込みでヘッダーのチェックサムを検証するようになり、壊れたアーカイブはこれまでより早い段階でエラーになります。

.NET 10と.NET 11の採用判断

終了日がほぼ同じになった以上、選ぶ軸はサポート期間ではなく「リリースからの経過時間」と「必要な機能」です。

.NET 8／9からの移行先は、2026年10月時点では.NET 10を勧めます。GAから11か月分の修正が積み上がり、Visual Studioの安定版も対応済みだからです。.NET 11はGA前で、Visual Studioの対応もInsiders版に限られます。.NET 8／9の終了まで1か月を切っているので、GAを待ってから.NET 11へ移る計画は検証期間が足りません。

.NET 10で安定しているシステムを.NET 11へ上げる利点は、終了日が5日早まることを考えると薄く、上の実測のように数値の結果が変わるリスクもあります。次のLTSを待つほうが改修回数を減らせます。反対に、新規開発でC# 15の共用体型を設計に組み込みたいなら、GA後の.NET 11から始めるのが自然です。Runtime Asyncはプレビュー機能の位置付けなので、GA時点での提供状態と、依存ライブラリでの動作を確かめてから使ってください。古い.NETや.NET Frameworkからの移行計画そのものを外部に任せる場合は、システムマイグレーション・リプレイスの支援内容も参考にしてください。

.NET 11 SDKのインストールと.NET 10との共存設定

RC1は、Windowsでは最新のVisual Studio 2026 Insidersに同梱されています。VS Codeの場合はC# Dev Kit拡張と組み合わせます。SDKだけ入れる場合は、.NETのダウンロードページか公式のインストールスクリプトを使います。次はmacOS／Linuxで、既存のSDKと分けて入れる例です。

curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
bash dotnet-install.sh --version 11.0.100-rc.1.26425.128 --install-dir ~/dotnet11
~/dotnet11/dotnet --version

出力は11.0.100-rc.1.26425.128です。既存のリポジトリで.NET 10と共存させるときは、ルートのglobal.jsonでSDKを固定しておくと、RC版のSDKが選ばれるのを防げます。次の例は.NET 10側の設定です。.NET 11で試すプロジェクトは別ディレクトリに置き、そこのglobal.jsonでRC版SDKを指定したうえで、TargetFrameworkをnet11.0に変えます。

{
  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestFeature",
    "allowPrerelease": false
  }
}

RC版の間もセキュリティ修正は月例で入り、RC1には6件のCVE修正が含まれていました。本番でGo-Liveを使う場合は、更新・回帰テスト・ロールバックの手順を先に整えてください。.NET 10のパッチ対応の実例はCVE-2026-40372とは？.NET 10.0.7で修正されたASP.NET Core権限昇格の影響範囲と対応手順を参照してください。

よくある質問

.NET 11のリリース日はいつですか？

正式版は2026年11月10日の予定で、11月10日から12日の.NET Conf 2026でリリースされます。2026年9月8日にRC1が公開済みです。

.NET 11はLTSですか？サポート期限はいつまでですか？

LTSではなくSTS（標準期間サポート）です。サポート期間は2年で、2026年11月10日から2028年11月9日までです。.NET 10（LTS）の終了日2028年11月14日と5日しか違いません。

.NET 11の最新版はどれですか？RC2は出ていますか？

2026年10月13日時点の最新は11.0.0-rc.1（SDK 11.0.100-rc.1.26425.128）で、dotnet/coreのreleases.jsonにRC2は載っていません。RC1のGo-Liveサポート終了日は2026年10月13日とされています。最新の版はreleases.jsonかダウンロードページで確認してください。

C# 15はいつから使えますか？

net11.0を対象にすれば、RC1からC# 15が既定の言語バージョンです。共用体型やコレクション式の引数はLangVersionの指定なしで使えます。メモリ安全性の新ルールだけは、RC1でもpreview指定が必要です。

Visual Studio 2022で.NET 11を使えますか？

RC1の公式発表が対応環境として挙げているのは、Visual Studio 2026 Insidersと、VS Code＋C# Dev Kitです。Visual Studio 2022で.NET 10を対象にする構成も公式サポート外（ビルド時に警告が出ます）のため、.NET 11の開発にはVisual Studio 2026系かVS Codeを使ってください。

関連記事

• .NET 10（LTS）とは？サポート期限・新機能・C# 14と.NET 8/9からの移行を解説
• C#のボックス化とは？起きる場面と割り当てバイト数を.NET 10で実測・回避方法まで解説
• .NET Generic Host（汎用ホスト）とは？CreateApplicationBuilderでDI・設定・ログ・常駐化【.NET 10】
• Blazorの将来性は？2026年の採用判断と.NET 10時代のWeb開発を解説
• .NET MAUIの将来性は？サポート期限・Xamarin後継・Flutter比較から2026年の採用を判断する