.NET 11 Preview 4 には何があるのか

Posted at 2026-09-04

.NET 11 のプレビュー版が再び更新されました。今回は Preview 4 です。公式の大量のリリースノートを読み込みたくないなら、この記事はそのためのものです。平易な言葉でざっと見て、実際に日常の開発体験を変えるものだけを拾って紹介します。

1. いちばん注目すべき点: MCP Server テンプレートが SDK に標準搭載された！

これは Preview 4 の中でも、最も意味の大きい変更です。

まず簡単に説明すると、MCP（Model Context Protocol）は Anthropic が提唱したプロトコルで、ざっくり言えば大規模モデルに外部ツールを接続するための「標準インターフェース」です。今では OpenAI や各種 AI クライアントもこれをサポートしており、AI に業務を呼び出させたり、データベースを読ませたり、システムを操作させたりしたいなら、MCP Server を作ればよいわけです。

以前は .NET で MCP Server を作るには、追加で Microsoft.McpServer.ProjectTemplates というテンプレートパッケージをインストールする必要がありました。ところが Preview 4 では、このテンプレートが .NET SDK に直接組み込まれ、一行のコマンドで作成できます。

dotnet new mcpserver -o MyMcpServer

dotnet new list にも表示され、console や webapi と同じ扱いになりました。見た目は小さな変更ですが、意味は大きいです。これは Microsoft が「.NET 開発者が AI ツールを簡単に書けるようにする」ことを、もはやオプションではなく標準機能として扱っていることを示しています。.NET 8 からの Microsoft.Extensions.AI、Semantic Kernel、そして今回の MCP Server テンプレート標準搭載まで、.NET が AI エコシステムに本気で力を入れているのがはっきり分かります。もしあなたの会社が既存の .NET システムを AI Agent に接続しようとしているなら、今はちょうどよいタイミングです。

2. Blazor の更新は本当にうれしい

Blazor は Preview 4 で最も多く変更された部分で、どれもかなり実用的です。

1. Virtualize がついに「揺れ」なくなった

<Virtualize> コンポーネントで長いリストを扱ったことがある人なら、古くからの問題を知っているはずです。リスト上部のコンテンツの高さが変わると（たとえば項目が展開されたり、非同期読み込みが終わったりしたとき）、今見ている下の内容が突然ジャンプしてしまい、体験がかなり悪くなっていました。

Preview 4 でこの問題が解消されました。内部ではブラウザ標準の scroll anchoring を使い、<table> や Safari のような特殊ケースでは ResizeObserver で補っています。コードを変更する必要はなく、アップグレードするだけで有効になります。

2. AnchorMode が追加され、チャットやメッセージ流に便利に

新しく AnchorMode パラメーターが追加され、リストの前後にデータが挿入されたときにビューポートをどう扱うかを解決できるようになりました。

Beginning（既定）: 前に新しいデータが挿入されたとき、ビューポートは先頭に維持される — ニュースフィードや通知リスト向け
End: 末尾に新しいデータが追加されたとき、自動で最下部までスクロールする — チャット画面やログビューア向け
Beginning | End の組み合わせも可能

<Virtualize Items="@messages"
            AnchorMode="VirtualizeAnchorMode.End"
            ItemComparer="@_byId">
    <ItemContent Context="msg">@msg.Text</ItemContent>
</Virtualize>

チャット UI を作ったことがある人なら分かるはずですが、以前はスクロール制御のために大量の JavaScript を自前で書く必要がありました。今ではパラメーターひとつで済みます。

3. `[SupplyParameterFromTempData]` 属性

[SupplyParameterFromQuery] に慣れていれば、これもすぐ分かります。TempData をコンポーネントのプロパティに直接バインドでき、特に「送信後にリダイレクトして成功メッセージを表示する」といった場面に向いています。

@page "/account/manage"
<StatusMessage Message="@StatusMessage" />
@code {
    [SupplyParameterFromTempData]
    public string? StatusMessage { get; set; }
}

代入すると書き込みになり、次のリクエストで自動的に読み出されます。Blazor Identity テンプレートはすでにこれを使っており、従来の cookie hack は不要になりました。

4. サーバー側から Blazor Server の回線を一時停止できるように

Circuit.RequestCircuitPauseAsync() が追加され、サーバー側からクライアントに「一時停止」を促せるようになりました。デプロイや負荷分散の再配置時に、接続を優雅に片付けるのに役立ち、ユーザーが突然切断されたような体験をしなくて済みます。

5. Blazor Web Worker テンプレートの更新

以前は「NET Web Worker」と呼ばれていましたが、今回 Blazor Web Worker に改名され、名前がより分かりやすくなりました。さらに、みんなが欲しかった次の 2 つの機能が追加されています。

InvokeVoidAsync — 戻り値不要の fire-and-forget 呼び出し
CancellationToken とタイムアウトのサポート — 途中で固まった worker をきれいに終了できる

dotnet new blazorwebworker -o MyApp.Worker

3. HTTP QUERY メソッド対応（OpenAPI も追従）

これは少し新しい話です。HTTP QUERY は標準化が進んでいる新しいメソッドで、「body を持つ GET」のような位置づけです。検索条件が複雑で URL に収まらないときに使います。

app.MapMethods("/search", ["QUERY"], (SearchRequest request) =>
    SearchService.Run(request));

Preview 4 では OpenAPI ドキュメント生成が QUERY を正しく認識するようになり、クライアント SDK の自動生成ツール（NSwag や Kiota など）もそれに追従してサポートできるようになります。

小さいように聞こえますが、複雑な検索 API を作る人にはありがたい変更です。もう「この検索条件、こんなに多いけど GET にすべきか POST にすべきか」で悩まなくて済みます。

4. Process API が大幅拡張、「子プロセス起動の八工程」に別れを告げる

これは体験向上が最もはっきり感じられる変更のひとつです。以前はプロセスを起動して出力を取得するのに、こんな手順が必要でした。

var psi = new ProcessStartInfo("git", "status") {
    RedirectStandardOutput = true,
    RedirectStandardError = true,
    UseShellExecute = false
};
var p = Process.Start(psi);
p.OutputDataReceived += ...; // まだイベントを自分で受ける必要がある
p.BeginOutputReadLine();
await p.WaitForExitAsync();
// ...さらに stderr や終了コードを処理...

これを書いたことがある人なら、誰でも苦しんだことがあるはずです。Preview 4 では、次のような一行 API が用意されました。

var result = await Process.RunAndCaptureTextAsync(
    "git", ["status", "--porcelain"]);
Console.WriteLine(result.StandardOutput);
Console.WriteLine($"exit code: {result.ExitStatus.ExitCode}");

ほかにも新しい API がいろいろ追加されています。

Process.Run / Process.RunAsync — 起動して結果を待つ
Process.ReadAllText / Process.ReadAllBytes — 出力を一括で読む
Process.StartAndForget — 起動したら後は放置する（ハンドルを自動で detach）
ProcessStartInfo.KillOnParentExit（Windows）— 親プロセスが落ちたら子プロセスも終了
ProcessStartInfo.StartDetached — 子プロセスを親のセッションから切り離して独立して動かす

CLI ツール、DevOps 自動化、ビルドシステムを書く人には直接の恩恵があります。

5. `dotnet watch` が MAUI とモバイル開発で本当に使えるように

以前の dotnet watch は MAUI プロジェクトでいろいろ壊れていましたが、Preview 4 で重点的に修正されました。

dotnet watch --device <device-id>

ターゲットフレームワーク選択時に、検索可能なインタラクティブ一覧を表示するようになった（Spectre.Console 風）。複数デバイスがあるときに選べる
利用可能なデバイスを自動検出するようになった（Android デバイス／エミュレーター、iOS シミュレーターに対応）
iOS でのデッドロック問題、Ctrl+R 再起動時の例外、TFM セレクターが固まる問題を修正

iOS シミュレーターにはまだ既知の制限があり、csproj に <MtouchLink>None</MtouchLink> を追加する必要がありますが、全体としてエンドツーエンドのホットリロードの流れは通るようになりました。MAUI でクロスプラットフォーム開発をしている人は、再び使ってみる価値があります。

6. 小さいけれど気が利いている改善

単体では大きくなくても、まとめるとかなり快適です。

`dotnet reference` コマンドが賢くなった

cd ClassLib2
dotnet reference add ../ClassLib1/ClassLib1.csproj  # 以前はエラーになっていたが、今はそのまま動く

--project を指定しない場合、自動的に現在のディレクトリのプロジェクトを探すようになり、dotnet reference list の挙動と揃いました。

Console がついに `FORCE_COLOR` 環境変数をサポート

以前は dotnet run | tee build.log のようなパイプ操作をすると、彩色出力が消えていました（stdout がリダイレクトされたと検出されるため）。今は業界標準に従い、FORCE_COLOR=1 で色を強制的に保持できます。

FORCE_COLOR=1 dotnet run | tee build.log

F# の判別共用体（Discriminated Unions）が JSON シリアライズをネイティブサポート

以前は C# から F# API を呼ぶときにカスタム converter が必要でしたが、今は System.Text.Json が直接サポートします。F# 派にはうれしい変更です。

MemoryCache に OpenTelemetry 指標を内蔵

Microsoft.Extensions.Caching.Memory.MemoryCache が、OpenTelemetry 互換の指標を直接出力できるようになりました。dotnet.cache.requests（hit/miss タグ付き）、dotnet.cache.evictions、dotnet.cache.entries、dotnet.cache.estimated_size が含まれます。Grafana のダッシュボードにそのまま接続でき、運用観測のために自前でラッパーを作る必要がなくなります。

Kestrel の TLS ハンドシェイクで失敗理由を取得可能に

以前は TLS ハンドシェイクに失敗すると無味乾燥な IOException だけでしたが、今は ITlsHandshakeFeature.Exception で具体的な原因が直接分かります。本番で SSL 問題を調査するときに、もう手探りで推測する必要はありません。

`HttpClient` が Windows 認証シーンで自動的に HTTP/1.1 にフォールバック

NTLM や Negotiate といった Windows の認証機構は HTTP/2 をサポートしていないため、以前はそのまま失敗していました。今は HttpClient が自動的に HTTP/1.1 に落ちます。企業内ネットワークアプリには朗報です。

Configuration に新しい機能

[ConfigurationIgnore] 属性で、あるプロパティを設定バインドの対象から宣言的に除外できるようになりました。以前のような回避策よりずっときれいです。

public sealed class AppOptions
{
    public string Endpoint { get; set; } = "";

    [ConfigurationIgnore] // このプロパティはバインド対象にならない
    public string ComputedKey => Endpoint + ":default";
}

7. 基盤レベルで注目すべき 2 つの変更

パフォーマンスの細部までは掘り下げませんが、かなり大きめの変更が 2 つあります。

1. runtime-async の全面展開

.NET 11 では新しい async 実装方式を推進しています。C# コンパイラではなく、ランタイムが async 状態機械を生成する方式です。Preview 4 ではランタイムライブラリ全体と ASP.NET Core の共有フレームワークでこれが有効になりました。利用者側から見ると、async/await の書き方はそのままですが、内部的にはより効率的になり、デバッグ体験も改善されます。

もし Preview 4 上で奇妙な非同期の問題（例外スタック、AsyncLocal の挙動など）が出たら、チームにフィードバックする価値があります。そこは彼らが重点的に注視している領域です。

2. 1024 個を超える CPU を持つマシンをサポート

.NET が 1024 コア超のマシンで起動できないという報告がありましたが、今回修正されました。巨大サーバー上でも .NET が上限なく動くようになります。ほとんどの人には関係ありませんが、聞くだけで安心できます。

まとめ: 感じられるいくつかの傾向

今回の Preview 4 を全体として見ると、いくつか明確な方向性があります。

AI を本気で中核方向として進めている: MCP Server テンプレートを SDK に内蔵したことが何よりの証拠です。.NET は AI の波で遅れたくなく、しかもクローズドな仕組みではなくオープンなプロトコル（MCP）を受け入れる道を選んでいます。
Blazor は死んでいないどころか、ますます強くなっている: Virtualize 修正、Web Worker 改善、SSR フォームのパラメーターバインドなど、どれも実運用の体験を一段上げる改善です。
開発者体験の磨き込みが続いている: dotnet watch のモバイル対応から Process.RunAndCaptureTextAsync、そして FORCE_COLOR のような細部まで、日常でよく使う部分がどんどん扱いやすくなっています。
可観測性がフレームワークに内包されつつある: MemoryCache の OpenTelemetry 指標内蔵や、CLI 自体の OpenTelemetry 対応は、可観測性を「三方のライブラリを組み合わせて実現するもの」ではなく、フレームワーク標準の能力として扱っていることを示しています。

Preview 4 は全体としてかなりバランスのよいリリースです。「うわ、これはすごい」と叫ぶような単発の大型機能はありませんが、埋めるべき穴はきちんと埋め、追うべきトレンドにはしっかり追従しています。

もしあなたのプロジェクトがすでに .NET 10 上にあるなら、開発環境で Preview 4 を試してみるとよいでしょう。特に Blazor と MAUI のプロジェクトでは、体験の改善をはっきり感じられるはずです。

正式版は今年 11 月のリリース予定です。そのときにまた会いましょう。

(Translated by GPT)

元のリンク：https://mp.weixin.qq.com/s/0Nx0X6lSxTaXDBQK20pI9g?token=639931501&lang=zh_CN&wt.mc_id=MVP_325642

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up