💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「Java ではないもう一つのエンタープライズ」

2026年5月。あるシニアエンジニアが半分冗談でこう言った。「.NET を使っていない、と言う人は多いです。ただ、自分のカード会社のバックエンドが .NET で動いていることを知らない人も多い」。冗談ではあるが、半分は本気だ。

カンファレンスのステージは今でも TypeScript、Go、Rust のものだ。だが、決済・銀行・製造・公共・ゲームバックエンドの一角は .NET で動いている。そして .NET 自身も 2020年の .NET 5 統合以降、毎年11月に新メジャーを出して、勤勉に姿を変えてきた。

2024-2026年の出来事を並べると:

- **.NET 9 (2024年11月)** — STS (Standard Term Support、18か月)。パフォーマンスと CLR が中心。

- **.NET 10 (2025年11月、LTS)** — Long Term Support 3年。新しい既定。

- **ASP.NET Core 10** — Minimal API の成熟、OpenAPI 内蔵。

- **Aspire (2024年11月 GA)** — クラウドネイティブ・オーケストレーション + テレメトリ。

- **Blazor United** — Server / WASM / SSR / streaming を一つのモデルに。

- **.NET MAUI** — 安定化。iOS/Android/Mac/Windows を単一の C# コードで。

- **Avalonia 11** — Linux を含む真のクロスプラットフォームデスクトップ。

- **EF Core 9** — JSON、complex types、primitive collections。

- **C# 13 (2024)** — params collections、lock object、escape sequences。

- **C# 14 (2025)** — field accessor、partial members、null-conditional assignment。

この記事は **2026年の .NET 陣営の地図** を一度に整理する。どのバージョンを選ぶか、ASP.NET Core 10 と FastEndpoints のどちらを使うか、Aspire は本当に必要か、MAUI vs Avalonia 11、EF Core vs Dapper、MediatR が商用化された後の CQRS パターン、NativeAOT の現実的な限界 — そして誰が .NET を選ぶべきかまで。

最初に一つだけ言っておく。**.NET は死んでいない。** むしろ韓国・日本の enterprise・金融・政府システムでは、ますます深く根を下ろしている。JVM・Go・Node とは違う質感を持つ道具で、その質感が合うドメインは明らかに存在する。

1章 · 2026年の .NET 地図 — 一枚の表

| 領域 | 2026年の事実上の標準 | 備考 |

| --- | --- | --- |

| ランタイム | **.NET 10 LTS** (2025-11) | .NET 9 は 2026-05 EOL 直前 |

| 言語 | C# 13 / C# 14 | F# 9、VB は stable 維持 |

| Web バックエンド | ASP.NET Core 10 + Minimal APIs | + FastEndpoints / Carter |

| データ | EF Core 9 / Dapper / Marten | 選択肢が広い |

| メッセージング | MassTransit / NServiceBus / Wolverine | MediatR 商用化の影響大 |

| CQRS | Wolverine / Brighter / 自前 | MediatR 8.x は paid |

| クラウドオーケストレーション | **.NET Aspire** | Bicep + OTel 内蔵 |

| Web UI | **Blazor United** | Server + WASM + SSR |

| モバイル / デスクトップ | .NET MAUI | iOS/Android/Mac/Win |

| クロスプラットフォームデスクトップ | **Avalonia 11** | Linux 含む |

| ゲーム | Unity (.NET 8 ベース)、Stride、MonoGame | Unity は独自ランタイム |

| デプロイ | コンテナ + NativeAOT | self-contained は縮小 |

| パッケージ | NuGet 6 + Central Package Management | global.json 標準化 |

| 解析 | Roslyn analyzers + StyleCop + Sonar | nullable enforcement |

要点を一文ずつ:

- **ランタイムの議論は .NET 10 LTS で落ち着いた。** .NET 9 は通過する短い STS。

- **Web は Minimal APIs が default になり**、FastEndpoints / Carter が「もう少し構造化された Minimal API」として定着。

- **Aspire は .NET 版の docker-compose + Kubernetes + OpenTelemetry 統合**になった。

- **UI は三つに分かれた。** Web は Blazor United、モバイル/デスクトップは MAUI、Linux 含む真のクロスは Avalonia 11。

- **CQRS は MediatR 商用化後、Wolverine / Brighter / 自前**に分散した。

2章 · .NET 10 LTS (2025-11) — フラッグシップリリース

.NET 10 は 2025年11月に GA となり、Long Term Support 3年だ。つまり 2028年11月までパッチ対応。.NET 6 (2021-11)、.NET 8 (2023-11) に続く正式 LTS で、.NET 9 はその間の STS。

主な変更点:

- **CLR / GC**: DATAS (Dynamically Adapting To Application Sizes) GC が default に。メモリフットプリントの小さいサービスで 30-40% 削減。

- **JIT**: PGO (Profile-Guided Optimization) on by default。devirtualization と inlining がより積極的に。

- **NativeAOT の成熟**: より多くのフレームワークライブラリが AOT-safe。ASP.NET Core minimal API + EF Core 一部が AOT 可能。

- **JSON**: System.Text.Json が polymorphism、snake_case naming、IAsyncEnumerable streaming を正式サポート。

- **threading**: TimeProvider、PriorityQueue 改善。async LINQ が stable。

- **C# 14 同時リリース**: field accessor、partial properties/methods、null-conditional assignment。

- **NuGet 6 + Central Package Management**: ソリューション全体のパッケージバージョンを Directory.Packages.props 一つに統一。

- **dotnet CLI 統合**: `dotnet run app.cs` 単一ファイル実行が正式サポート。

LTS の意味は単に「パッチ期間が長い」ことではない。**エコシステムのライブラリが最も追従する**ことを意味する。EF Core 10、ASP.NET Core 10、Aspire 安定チャネル、MassTransit、MediatR フォーク群 — ほぼすべての主要ライブラリが .NET 10 を first-class target としている。

アップグレードの目安:

- .NET 6 (LTS、2024-11 EOL): 即時 .NET 10 へ。

- .NET 8 (LTS、2026-11 EOL): EF Core、MediatR などの互換性確認のうえ徐々に .NET 10 へ。

- .NET 9 (STS、2026-05 EOL): 急ぎ .NET 10 へ。どうせ終わる。

3章 · .NET 9 (2024-11) — STS との比較

.NET 9 は STS、つまり 18か月サポートなので 2026年5月に終わる。この記事が書かれている時期がちょうどそれだ。.NET 9 は「次の LTS、.NET 10 のための実験ノート」のような役割を果たした。

.NET 9 で入って .NET 10 で磨かれたもの:

- **DATAS GC** — .NET 9 で opt-in、.NET 10 で default。

- **System.Text.Json polymorphism** — 9 で alpha、10 で stable。

- **OpenAPI 内蔵** — .NET 9 で Swashbuckle 依存を捨て `Microsoft.AspNetCore.OpenApi` に。.NET 10 で UI まで統合。

- **Kestrel HTTP/3** — .NET 9 で production-ready。

- **NativeAOT 拡大** — .NET 9 でより多くのライブラリ対応。

要点: **.NET 9 を運用しているチームは 2026年中盤までに .NET 10 へ移動**する必要がある。.NET 8 (LTS) に戻る意味はない — .NET 8 自身も 2026年11月で終わる。

LTS / STS のリズムは今や明確だ:

- **LTS** — 偶数メジャー (8、10、12...)、3年サポート、エンタープライズの既定。

- **STS** — 奇数メジャー (7、9、11...)、18か月、速い実験サイクル。

エンタープライズは STS を丸ごとスキップするのが普通だ。つまり .NET 6 → 8 → 10 が標準ルート。

4章 · C# 13 / C# 14 — params collections、field accessor

C# は毎年11月、.NET と同時に新メジャーを出す。C# 13 は 2024年、C# 14 は 2025年に .NET 10 と一緒にリリースされた。

**C# 13 の核**:

- **params collections** — `params Span<int>`、`params IEnumerable<int>` などコレクション型に params 可能。「params int[] のみ」ではない。

- **lock 用専用型** — `System.Threading.Lock` が入り、`lock(myLock)` に適したモナディックな使い方。一般 object を lock に使うパターンはアナライザが警告。

- **新しい escape sequence `\e`** — ANSI escape (ESC 0x1B)。ターミナル ANSI カラーコードがきれいに書ける。

- **partial properties** — partial method に続いて partial property も可能。source generator フレンドリー。

- **`field` キーワードのプレビュー** — getter/setter 内で backing field に `field` で直接アクセス。

**C# 14 の核**:

- **`field` キーワードの正式化** — getter/setter 内で `field` が自動的な backing field を提供。明示的な backing field 宣言が消える。

- **partial members 拡大** — コンストラクタ、演算子、インデクサまで partial 可能。

- **null-conditional assignment** — `obj?.Prop = value` — obj が null なら代入をスキップ。

- **拡張された nameof** — 未解決の型引数を受け取っても nameof 可能。

- **拡張メンバの進化** — 拡張メソッドに加え、拡張プロパティのプレビュー。

`field` キーワードを一目で見ると:

// 旧来 — backing field を明示

private string _name = string.Empty;

public string Name

{

get => _name;

set => _name = value?.Trim() ?? throw new ArgumentNullException();

}

// C# 14 — field で直接

public string Name

{

get;

set => field = value?.Trim() ?? throw new ArgumentNullException();

} = string.Empty;

`_name` を手で宣言しなくてもコンパイラが作ってくれる。もう `_camelCase` backing field のネーミング論争はいらない。

5章 · ASP.NET Core 10 — performance + DX

ASP.NET Core 10 は .NET 10 と同時に登場した。2026年5月時点で、モダン .NET Web の基本形は次のとおり。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenApi();

builder.Services.AddDbContext<AppDbContext>(opts =>

opts.UseNpgsql(builder.Configuration.GetConnectionString("Default")));

var app = builder.Build();

app.MapOpenApi(); // /openapi/v1.json

app.MapScalarApiReference(); // Scalar UI 統合

app.MapGet("/users/{id:guid}", async (Guid id, AppDbContext db) =>

{

var user = await db.Users.FindAsync(id);

return user is null ? Results.NotFound() : Results.Ok(user);

})

.WithName("GetUser")

.WithOpenApi();

app.MapPost("/users", async (CreateUserDto dto, AppDbContext db) =>

{

var user = new User(dto.Name, dto.Email);

db.Users.Add(user);

await db.SaveChangesAsync();

return Results.Created($"/users/{user.Id}", user);

});

app.Run();

**変わった点**:

- **OpenAPI 内蔵** — Swashbuckle を別に入れない。`Microsoft.AspNetCore.OpenApi` が default。

- **Scalar UI 統合** — Swagger UI より軽くきれいな OpenAPI viewer。

- **JSON streaming** — IAsyncEnumerable が chunked transfer encoding として自然に流れる。

- **HTTP/3 default** — Kestrel が production-ready で HTTP/3 サポート。

- **Compiled routing** — エンドポイントのディスパッチが reflection ではなくコンパイル時コード生成。

- **OpenTelemetry first-class** — `AddOpenTelemetry()` が標準パターン。

**パフォーマンス数値** (TechEmpower 系マイクロベンチ):

- ASP.NET Core 10 Minimal API + Kestrel: 700k+ req/s (Plaintext)。

- ASP.NET Core 10 + EF Core 9 + Postgres: 80-100k req/s (Fortunes)。

- 同等の Go (net/http): 600k req/s。

- 同等の Node (Fastify): 200k req/s。

2026年でも ASP.NET Core は、最も速いメインストリーム Web フレームワークの一つだ。

6章 · Aspire (2024-11 GA) — クラウドネイティブ・オーケストレーション

Aspire は 2024年11月に GA となった、.NET 陣営のクラウドネイティブ・オーケストレーション + ローカル開発環境 + テレメトリ統合ツールだ。名前は大袈裟だが、本質はシンプル。

**Aspire が解決する問題**:

- ローカルで `docker-compose up` の代わりに .NET コードで依存を定義。

- マイクロサービス複数 + Postgres + Redis + RabbitMQ を一つのソリューションに。

- OpenTelemetry の自動注入 + ダッシュボード内蔵。

- クラウドデプロイ時に Bicep / Terraform / Kubernetes マニフェストを自動生成。

**AppHost プロジェクトの形**:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("db")

.AddDatabase("appdb");

var redis = builder.AddRedis("cache");

var rabbitmq = builder.AddRabbitMQ("messaging");

var apiService = builder.AddProject<Projects.ApiService>("api")

.WithReference(postgres)

.WithReference(redis)

.WithReference(rabbitmq);

builder.AddProject<Projects.WebFrontend>("web")

.WithReference(apiService);

builder.Build().Run();

このコードを `dotnet run` すると:

1. Postgres / Redis / RabbitMQ コンテナが自動で起動。

2. API サービスと Web Frontend が .NET プロセスとして起動。

3. 接続文字列が環境変数として自動注入。

4. OpenTelemetry データが Aspire Dashboard に流れる。

5. 分散トレース、ログ、メトリクスが一画面で見える。

**Aspire Dashboard**:

- 分散トレース (waterfall view)。

- 構造化ログ。

- メトリクス (CPU、memory、request rate、latency)。

- コンテナ / プロセス状態。

- 環境変数インスペクタ。

**クラウドデプロイ**:

- Azure Container Apps へ `azd up` 一行でデプロイ可能。

- 他クラウドは Aspire マニフェスト → Kubernetes / Bicep / Terraform に変換。

**docker-compose vs Aspire**:

| 基準 | docker-compose | Aspire |

| --- | --- | --- |

| 定義言語 | YAML | C# |

| デバッグ | コンテナアタッチ | .NET プロセスを直接デバッグ |

| テレメトリ | 別途インストール | 内蔵 |

| クラウドデプロイ | 変換ツール別途 | 内蔵 generator |

| .NET 以外のサービス | 良好 | 良好 (Postgres、Redis、OS image など) |

.NET マイクロサービスを運用するチームには Aspire が事実上 default となった。ただし、.NET 以外のサービスが多いポリグロット環境では docker-compose が依然として自然だ。

7章 · Blazor United — Server + WASM + SSR + streaming

Blazor は 2018年の WebAssembly hype から8年が経った 2026年現在、「一つのコンポーネントが複数のレンダーモードを選べる」単一モデルとして定着した。Microsoft 公式ドキュメントはこれを Blazor United と呼ぶ。

**四つのレンダーモード**:

1. **Static SSR** — サーバで一回描いて終わり。最速、インタラクションなし。

2. **Streaming SSR** — 非同期データ読み込み結果を chunked でストリーミング。

3. **Server interactive** — SignalR ベース、サーバでイベント処理。

4. **WebAssembly interactive** — クライアント WASM、オフライン可能。

一つのページがコンポーネント単位でモードを混ぜられる。

@page "/dashboard"

@rendermode InteractiveAuto

`InteractiveAuto` は初回アクセス時に Server モード (SignalR) で速く立ち上がり、WASM ダウンロード完了後は WASM に切り替える。最初のインタラクション遅延を隠すパターン。

**Blazor の強み**:

- フルスタック C#。JavaScript なしで SPA 可能 (または最小化)。

- ASP.NET Core との統合。同じ認証、DI、ミドルウェアを使用。

- SignalR が安定。双方向通信が自然。

- WASM AOT ビルドで初回ロードサイズが徐々に縮小。

**Blazor の弱点**:

- WASM 初期バンドルは今でも 1-3MB。圧縮後でも重い。

- エコシステムは React/Vue に比べて小さい。

- モバイルブラウザの WASM 性能はデスクトップより遅い。

- デザイナー / コンポーネントマーケットが不足。

**誰が使うか**: 社内ツール、B2B 管理画面、フルスタック .NET チームの SPA が sweet spot。公開マーケティングサイトや SEO 中心ページは Static SSR に限定。

8章 · .NET MAUI — クロスプラットフォームネイティブ

.NET MAUI (Multi-platform App UI) は 2022年に Xamarin.Forms の後継として登場し、2024-2026年に安定化した。iOS / Android / macOS / Windows を単一の C# コードで。

**MAUI の構造**:

- 単一プロジェクト、単一コードベース。

- XAML または C# マークアップで UI。

- プラットフォーム別ハンドラがネイティブコントロールを描画。

- Hot reload 対応。

**MAUI Hybrid + Blazor Hybrid**:

MAUI の中に BlazorWebView を載せると、Razor コンポーネントをネイティブアプリとして再利用できる。Web 用に作った Blazor UI をモバイルアプリにもほぼそのまま。

このパターンは **フルスタック .NET チームがモバイルアプリまで持つ** ときに魅力的だ。React Native よりビルド/デプロイパイプラインが単純で、Flutter より .NET バックエンドとの統合が自然。

**MAUI の弱点**:

- iOS / Android ネイティブ SDK の進化を100%は追従できない。

- Linux デスクトップは公式サポートなし (コミュニティ GTK バックエンドあり)。

- 複雑なアニメーション / 性能 critical 部分は依然ネイティブが優位。

**2026年の推奨**: 社内モバイル / Windows デスクトップ限定。公開アプリストア向けコンシューマアプリは Flutter、SwiftUI/Compose、React Native と比較してから決める。

9章 · Avalonia 11 — 真のクロスプラットフォーム UI

Avalonia はコミュニティが作り .NET Foundation で運営されるオープンソースのクロスプラットフォーム UI フレームワークだ。2023年11月に 11.0 が、2024-2025年に 11.1 / 11.2 / 11.3 が順次リリース。

**MAUI との違い**:

| 基準 | .NET MAUI | Avalonia 11 |

| --- | --- | --- |

| ガバナンス | Microsoft | コミュニティ + 商用 (AvaloniaUI 社) |

| プラットフォーム | iOS/Android/Mac/Win | iOS/Android/Mac/Win/**Linux**/WebAssembly |

| レンダリング | プラットフォームネイティブコントロール | 独自レンダラ (Skia ベース) |

| UI 一貫性 | プラットフォームごと | 全プラットフォーム同一 |

| デザインパターン | XAML + handlers | XAML + 独自コントロールツリー |

| Hot reload | 対応 | 対応 |

| デスクトップ重視度 | 弱い | 強い |

**Avalonia が光るケース**:

- **Linux デスクトップが本当に必要なチーム**。(MAUI は不可。)

- **全プラットフォームでピクセル単位に同じ UI** が必要なケース。

- **デスクトップ中心アプリ** (IDE、グラフィックスツール、音声/映像ソフト)。

**実例**:

- **JetBrains Rider** が一部 UI で Avalonia を試行 (全面採用ではない)。

- **WasabiWallet、Camelot、AvaloniaEdit** など OSS .NET デスクトップツール。

- **多くの enterprise 社内ツール** が WPF から Avalonia へ移行中。WPF が Windows 専用のため、Mac/Linux クライアントのために。

**弱点**:

- モバイルは可能だがネイティブ感が不足。MAUI に譲るのが妥当。

- WPF に比べてコミュニティのコントロールマーケットが小さい。

**2026年の推奨**: WPF の自然な後継。Linux/Mac デスクトップ .NET アプリなら第一候補。

10章 · Entity Framework Core 9

EF Core 9 は 2024年11月に .NET 9 と一緒に出て、EF Core 10 が 2025年11月に出た。2026年5月の事実上の標準は EF Core 10。

**ここ 2-3年の変化**:

- **JSON columns 正式サポート** — Postgres `jsonb`、SQL Server JSON、SQLite JSON。LINQ で JSON 内部クエリ。

- **Complex types** — owned types をより軽量に。値オブジェクトのモデリングが自然。

- **Primitive collections** — `List<int>` をカラムにそのままマッピング。

- **Bulk operations** — `ExecuteUpdateAsync`、`ExecuteDeleteAsync` で N+1 なしの一括更新。

- **Query splitting デフォルト** — JOIN 爆発を防止。

**典型コード**:

public class AppDbContext : DbContext

{

public DbSet<Order> Orders => Set<Order>();

protected override void OnModelCreating(ModelBuilder mb)

{

mb.Entity<Order>(b =>

{

b.ToTable("orders");

b.ComplexProperty(o => o.ShippingAddress);

b.OwnsMany(o => o.Items);

b.Property(o => o.Metadata)

.HasColumnType("jsonb");

});

}

// 一括削除 - SQL 一発

await db.Orders

.Where(o => o.Status == OrderStatus.Cancelled && o.CreatedAt < DateTime.UtcNow.AddYears(-1))

.ExecuteDeleteAsync();

**EF Core vs Dapper vs Marten**:

| ツール | モデル | 強み | 弱み |

| --- | --- | --- | --- |

2026年の default は **EF Core + Dapper の併用** だ。CRUD とドメイン変更は EF Core、重い帳票 / 分析クエリは Dapper。

11章 · MediatR / MassTransit / NServiceBus — CQRS とメッセージング

2024年末、.NET CQRS 界隈が揺れた。**MediatR が 8.x から商用ライセンスへ移行** したからだ。同じ作者の AutoMapper も同時期に paid edition を導入。この決定は .NET コミュニティで大きな論争を呼んだ。

**現在の選択肢**:

| ツール | モデル | ライセンス | 備考 |

| --- | --- | --- | --- |

**Wolverine 例**:

// Handler — interface なしでメソッドシグネチャから認識

public class CreateOrderHandler

{

public async Task<OrderCreated> Handle(CreateOrder command, AppDbContext db)

{

var order = new Order(command.CustomerId, command.Items);

db.Orders.Add(order);

await db.SaveChangesAsync();

return new OrderCreated(order.Id);

}

// 呼び出し

var result = await bus.InvokeAsync<OrderCreated>(new CreateOrder(...));

interface 宣言なしでメソッドシグネチャを解析するのが Wolverine の特徴。MediatR の `IRequestHandler` ボイラープレートが消える。

**メッセージング (out-of-process)**:

| ツール | トランスポート | ライセンス | 強み |

| --- | --- | --- | --- |

| **NServiceBus** | 多様 | 商用 | エンタープライズ。saga が強い。 |

| **Rebus** | RabbitMQ、Azure Service Bus など | OSS | 軽量 |

**MassTransit の saga パターン**:

public class OrderSaga : MassTransitStateMachine<OrderState>

{

public State Submitted { get; private set; }

public State Paid { get; private set; }

public State Shipped { get; private set; }

public Event<OrderSubmitted> OnSubmitted { get; private set; }

public Event<PaymentReceived> OnPaid { get; private set; }

public OrderSaga()

{

InstanceState(x => x.CurrentState);

Initially(

When(OnSubmitted)

.Then(c => c.Saga.OrderId = c.Message.OrderId)

.TransitionTo(Submitted));

During(Submitted,

When(OnPaid)

.TransitionTo(Paid));

}

**2026年の推奨**:

- **シンプルな in-process mediator**: 自前実装または Wolverine。

- **CQRS + messaging 統合が必要**: Wolverine。

- **エンタープライズ + 商用サポートが必要**: NServiceBus。

- **既に MediatR + MassTransit を使うチーム**: MediatR 8+ ライセンス費用を計算してから乗り換えを判断。

12章 · FastEndpoints / Carter / Minimal APIs

ASP.NET Core 10 のルーティングスタイルは三つに分かれた。

**1. Minimal APIs (default)**:

app.MapGet("/orders/{id:guid}", async (Guid id, AppDbContext db) =>

{

var order = await db.Orders.FindAsync(id);

return order is null ? Results.NotFound() : Results.Ok(order);

});

長所: 軽量、起動が速い。短所: 大きな API では Program.cs が肥大化。

**2. Controllers (伝統)**:

[ApiController]

[Route("orders")]

public class OrdersController : ControllerBase

{

[HttpGet("{id:guid}")]

public async Task<IActionResult> Get(Guid id) { ... }

}

長所: 馴染みがある、クラス単位で整理。短所: ボイラープレートが多い。

**3. FastEndpoints / Carter (構造的なミニマル)**:

FastEndpoints は「Endpoint per class」パターンを強制する。

public class GetOrderEndpoint : Endpoint<GetOrderRequest, OrderResponse>

{

public AppDbContext Db { get; set; } = null!;

public override void Configure()

{

Get("/orders/{id:guid}");

AllowAnonymous();

}

public override async Task HandleAsync(GetOrderRequest req, CancellationToken ct)

{

var order = await Db.Orders.FindAsync([req.Id], ct);

if (order is null) { await SendNotFoundAsync(ct); return; }

await SendAsync(new OrderResponse(order), cancellation: ct);

}

**Carter** は Nancy の精神的後継で、モジュール単位ルーティング。

public class OrdersModule : ICarterModule

{

public void AddRoutes(IEndpointRouteBuilder app)

{

app.MapGet("/orders/{id:guid}", async (Guid id, AppDbContext db) =>

{

var order = await db.Orders.FindAsync(id);

return order is null ? Results.NotFound() : Results.Ok(order);

});

}

**比較**:

| --- | --- | --- | --- | --- |

| ボイラープレート | 極小 | 多い | 少ない | 極小 |

| 整理 | 弱い | 強い | 強い (per-class) | 中 (per-module) |

| OpenAPI | 自動 | 自動 | 自動 + 豊富 | 自動 |

| 学習コスト | 低 | 低 | 中 | 低 |

| 大規模 API 適性 | 弱い | 強い | 強い | 中 |

**推奨**: 50 エンドポイント以下は Minimal API、それ以上は FastEndpoints または Controllers。軽くモジュール分割したいなら Carter。

13章 · NativeAOT — 小さな単一実行ファイル

NativeAOT は .NET 7 で GA となり、.NET 9-10 で成熟した。核となる発想は **JIT の代わりに ahead-of-time コンパイルで単一のネイティブ実行ファイルを生成する** こと。

**長所**:

- **起動時間**: 通常 50-100ms (vs JIT の 200-500ms)。cold start に敏感なワークロード (serverless、CLI ツール) に好適。

- **メモリ**: 30-40% 小さい。JIT 関連メタデータがない。

- **単一実行ファイル**: 10-30MB の stand-alone バイナリ。CoreCLR / framework を別途同梱しない。

- **trim 済みバイナリ**: 未使用コード削除。

**制約**:

- **Reflection 制限**: 伝統的に reflection を多用するライブラリは動かない。Serializer、ORM、IoC コンテナはすべて source generator を使う必要がある。

- **動的コード生成不可**: Reflection.Emit が動かない。

- **JIT コンパイルなし**: ランタイムに新しいアセンブリをロードできない。

**AOT フレンドリーなライブラリ**:

- System.Text.Json (with source generator)。

- Minimal APIs / FastEndpoints。

- EF Core 一部 (8+ から段階的)。

- Dapper。

- Refit (HTTP client)。

- ASP.NET Core RequestDelegateGenerator。

**AOT 非フレンドリー**:

- 一部の IoC コンテナ (Autofac、Castle Windsor など)。

- Newtonsoft.Json (reflection 依存)。

- MediatR の一部パターン。

- AutoMapper。

**例 — AOT minimal API**:

dotnet publish -c Release -r linux-x64

単一ネイティブ実行ファイル → bin/Release/net10.0/linux-x64/publish/MyApi

サイズ: 通常 15-25 MB

**使うとき**:

- AWS Lambda、Cloud Functions などの serverless。

- CLI ツール (dotnet-tool の代替)。

- コンテナの cold start に敏感なマイクロサービス。

- 起動時間がビジネス的に重要なすべての場所。

**使わないとき**:

- Reflection 依存ライブラリが多いレガシー。

- ビルド時間 / デバッグの容易さが優先される開発フェーズ。

- レガシー EF Core / 複雑な IoC コンテナを持つモノリス。

14章 · Roslyn analyzers / NuGet / dotnet CLI

**Roslyn analyzers**:

.NET アナライザはコンパイル時にコード品質・セキュリティ・性能の問題を捕まえる。2026年にはほぼ default で以下を入れる:

- **.NET 組み込みアナライザ** (CA、IDE ルール)。

- **StyleCop.Analyzers** (コードスタイル)。

- **SonarAnalyzer.CSharp** (静的解析)。

- **Meziantou.Analyzer** (コミュニティのベストプラクティス)。

- **Roslynator** (リファクタリング + 解析)。

- **SecurityCodeScan** (セキュリティ脆弱性)。

`.editorconfig` でルールを制御:

[*.cs]

dotnet_diagnostic.CA1822.severity = warning # mark members as static

dotnet_diagnostic.IDE0005.severity = error # unused using

dotnet_analyzer_diagnostic.category-Style.severity = suggestion

**Nullable enforcement**:

この二行がモダン .NET プロジェクトとレガシーの最大の差だ。null 安全性をコンパイラが強制。

**NuGet 6 + Central Package Management**:

Directory.Packages.props 一つのファイルでソリューション全体のパッケージバージョンを制御:

各 csproj では `<PackageReference Include="MediatR" />` のみ、バージョン記述なし。バージョン衝突が消える。

**dotnet CLI の統合**:

2026年の標準ワークフロー

dotnet new aspire-starter -n MyApp # Aspire ソリューション生成

dotnet add package Serilog.AspNetCore # パッケージ追加 (CPM 有効時は Directory.Packages.props に記録)

dotnet ef migrations add InitialCreate # EF Core マイグレーション

dotnet aspire run # Aspire アプリ実行

dotnet test --collect:"XPlat Code Coverage" # テスト + カバレッジ

dotnet format # 自動フォーマット

dotnet workload install android ios # MAUI workload

dotnet run app.cs # 単一ファイル実行 (.NET 10)

**global.json**:

ルートに置くとソリューションが使う SDK バージョンを明示できる。

{

"sdk": {

"version": "10.0.100",

"rollForward": "latestFeature"

}

この一ファイルのおかげで、チームメンバごとに SDK バージョンが違うときに起きる微妙なバグが消える。

15章 · 日本 / 韓国 — 任天堂、ソフトバンク、トス

.NET は日本や韓国のテックメディアではあまり目立たないが、実際の enterprise / 金融 / ゲームバックエンドには広く敷かれている。

**日本**:

- **任天堂 (Nintendo)**: 一部の社内ツール / バックエンドに .NET。ゲーム本体は独自エンジンだが、管理・マネジメント・オンラインサービスの一部で使用。

- **ソフトバンク (SoftBank)**: モバイル事業部の一部バックエンド。通信インフラ管理ツールに .NET を使うという発表あり。

- **楽天 (Rakuten)**: バックエンドの中心は Java / Python だが、広告 / 分析システムの一部が .NET。

- **NTT データ / 富士通**: 日本の SI 大手が .NET ベースの政府・金融プロジェクトを多数運営。

- **サイボウズ (Cybozu)**: kintone の一部サービス、社内ツールで .NET 使用報告あり。

- **メルカリ (Mercari)**: 大半が Go バックエンドだが、決済・精算の一部に .NET。

**韓国**:

- **金融バックエンド**: 新韓銀行、KB 国民カード、現代カードなど大型金融機関のバックエンドの一部が ASP.NET / .NET 8+ の上にある。特にカード / 債権 / 資産管理システム。

- **公共システム**: 行政網の一部、国税庁システムの一部、郵便局の一部で .NET が使われる。(セキュリティ / 監査の観点で Microsoft との長期ライセンス関係が大きい。)

- **トス (Toss)**: 大半は JVM / Kotlin / Node.js スタックだが、一部の管理画面 / 社内ツールが .NET の上にあるという報告。公式カンファレンス発表は稀。

- **NCSOFT、Nexon、Pearl Abyss**: ゲームクライアントは Unity / Unreal だが、一部バックエンド / 社内ツールが .NET。Unity は独自の .NET ランタイムだが同じ C# コードベース。

- **Samsung SDS、LG CNS**: SI プロジェクトで .NET を選ぶケースが今でも多い。

まとめると: **日本も韓国も、enterprise / 金融 / 通信 / 政府ドメインで .NET は事実上の標準選択肢の一つ**。カンファレンスのステージには出にくいが、売上とシステム規模で見ると軽くない。

16章 · 誰が .NET を選ぶべきか

**.NET を選ぶべきケース**:

- **エンタープライズ / 金融 / 政府ドメイン**。Microsoft エコシステム (SQL Server、Azure AD、Office) との自然な統合。長寿命 LTS と監査適性。

- **フルスタック C# チーム**。Blazor + ASP.NET Core + MAUI で Web/モバイル/デスクトップを単一言語に。

- **高性能 Web バックエンド**。ASP.NET Core 10 + Minimal APIs は Go に迫るスループット。

- **Windows デスクトップ / .NET 統合ツール**。WPF、WinForms、MAUI、Avalonia から選択可能。

- **Unity ゲーム開発**。C# 単一言語でクライアント・サーバを統一。

- **AWS Lambda / Cloud Functions ワークロード (NativeAOT)**。cold start に優れる。

**.NET を避けるべきケース**:

- **PaaS / serverless 中心で JS / Python 優先の環境**。Vercel / Cloudflare Workers など。

- **データサイエンス / ML 優先チーム**。Python エコシステムが圧倒的。

- **モバイル優先 (ソーシャル / コンシューマアプリ)**。SwiftUI / Compose / React Native / Flutter のほうが自然。

- **JVM ライブラリ資産が多い組織**。Kafka、Spark、Hadoop、Flink が一級なら JVM が自然。

- **極端なシステムプログラミング**。Rust / C++ / Go の方が合う。

**意思決定ツリー (簡略化)**:

Q1. ドメインは?

├── エンタープライズ / 金融 / 政府 / 保険 / Windows 統合

│ └── .NET 10 + ASP.NET Core 10 + EF Core 10

├── 公開コンシューマ Web / SEO 中心

│ └── Next.js / Remix / SvelteKit を先に検討

├── ゲーム (Unity)

│ └── C# (.NET 互換ランタイム)

└── モバイルアプリ (コンシューマ)

└── Native または Flutter / RN を先に

Q2. チームの言語は?

├── C# が強い → .NET

├── Java/Kotlin が強い → Spring / Quarkus

├── TS/JS が強い → Node / Deno

└── Python が強い → FastAPI / Django

Q3. デプロイ環境は?

├── Azure / オンプレ Windows → .NET が自然

├── AWS / GCP / K8s → .NET 可、OpenTelemetry · Aspire を活用

└── Vercel / Cloudflare / Edge → .NET は合わない

**一行推奨 (2026年5月時点)**:

- 新規エンタープライズ / 金融 / 通信 / 政府システム: **.NET 10 LTS + ASP.NET Core 10 + EF Core 10 + Aspire**。

- 社内ツール / 管理画面フルスタック: **Blazor United**。

- .NET チームに追加負担としてのモバイル: **MAUI + Blazor Hybrid**。

- 真のクロスプラットフォームデスクトップ: **Avalonia 11**。

- 小規模 API: **Minimal APIs**。50 エンドポイント超: **FastEndpoints**。

- CQRS は **Wolverine**、メッセージングは **MassTransit**。

- 単一実行ファイル / cold start 優先: **NativeAOT**。

最も大事なメタ推奨: **.NET を使わないのが合理的なドメインも確かに存在する**。だが、自分がそのドメインにいると断定する前に、一度はモダン .NET がどこまで来たか自分で計測してみる価値がある。2026年の .NET は 2018年の .NET とほとんど別の道具だ。

参考 / References

- .NET 公式 — https://dotnet.microsoft.com/

- .NET 10 発表 — https://devblogs.microsoft.com/dotnet/announcing-dotnet-10/

- .NET 9 発表 — https://devblogs.microsoft.com/dotnet/announcing-dotnet-9/

- .NET リリースポリシー (LTS / STS) — https://dotnet.microsoft.com/platform/support/policy/dotnet-core

- C# 13 新機能 — https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-13

- C# 14 新機能 — https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-14

- ASP.NET Core 10 — https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-10.0

- .NET Aspire — https://learn.microsoft.com/dotnet/aspire/

- Aspire GA 発表 — https://devblogs.microsoft.com/dotnet/dotnet-aspire-general-availability/

- Blazor — https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

- .NET MAUI — https://dotnet.microsoft.com/apps/maui

- Avalonia UI — https://avaloniaui.net/

- Entity Framework Core — https://learn.microsoft.com/ef/core/

- EF Core 9 発表 — https://devblogs.microsoft.com/dotnet/announcing-ef9/

- MediatR — https://github.com/jbogard/MediatR

- MediatR 商用化発表 — https://www.jimmybogard.com/automapper-and-mediatr-going-commercial/

- MassTransit — https://masstransit.io/

- NServiceBus — https://particular.net/nservicebus

- Wolverine — https://wolverinefx.net/

- FastEndpoints — https://fast-endpoints.com/

- Carter — https://github.com/CarterCommunity/Carter

- Minimal APIs 概要 — https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis/overview

- NativeAOT ガイド — https://learn.microsoft.com/dotnet/core/deploying/native-aot/

- Roslyn analyzers — https://learn.microsoft.com/dotnet/fundamentals/code-analysis/overview

- NuGet Central Package Management — https://learn.microsoft.com/nuget/consume-packages/central-package-management

- dotnet CLI — https://learn.microsoft.com/dotnet/core/tools/

- Marten (Postgres + Event Sourcing) — https://martendb.io/

- Dapper — https://github.com/DapperLib/Dapper

- TechEmpower Web Framework Benchmarks — https://www.techempower.com/benchmarks/

- Cybozu Tech Blog — https://blog.cybozu.io/

- Mercari Engineering — https://engineering.mercari.com/