はじめに
かなり前に「C# で出来ること一覧」という記事を書いて、その後も何度か更新版を書いてきました。一番最初の版が以下です。
.NET 10 がリリースされてから半年以上が経ったので、2026 年時点で C# / .NET を使うとどんな種類のアプリケーションが作れるのかを、あらためてまとめてみようと思います。
.NET 10 は 2025 年 11 月 11 日にリリースされた LTS（Long-Term Support）で、2028 年 11 月までサポートされます。長く使えるバージョンなので、これから新しく何かを作り始めるなら、まずは .NET 10 を土台に考えておくと良いと思います。
あと、最近の時流の話も少しだけ。GitHub Copilot や Claude Code、Codex といった AI コーディングツールがすっかり普及してきて、自分の手で 1 行ずつコードを書く機会はだいぶ減ってきました。そんなご時世でも、C# / .NET はいい感じに合っているなと感じています。理由は主に次の 2 つです。
- 静的型付けなので、AI が書いたコードでも、型の不整合や存在しないメンバーの呼び出しといった間違いはコンパイラーがチェックしてくれる。生成されたコードは、少なくとも型の間違いなどがないことが確認できる。
- .NET チーム自身も AI 時代への対応を進めている。たとえば
dotnet/skillsという .NET 開発向けの agent skill をまとめたリポジトリを公開していて、プラットフォームを作っているチーム自身が実際に使っているワークフローを配布している（GitHub Copilot CLI / Visual Studio / VS Code / Claude Code など Agent Skills 仕様に対応したツールから使える）
.NET チームのスキルについては以下の公式ブログで紹介されています。この記事の後半で触れる WinUI 向けの開発スキルも、こうした流れの 1 つです。
例によって、ここに書いてあるのはあくまで私個人の認識です。知識に偏りはあると思いますし、間違って理解しているものもあるかもしれません。そういうものを見つけたら、コメントなどでバンバン指摘してもらえると嬉しいです m(_ _)m
そもそも C# とは
C# は 2002 年に .NET Framework 1.0 上で開発するための言語として登場しました。最初に見たときの感想は「Java はメソッド名が小文字始まりだけど、これは大文字始まりになってる言語なんだな」くらいのものでした。当時の自分は、正直マイクロソフトが作った Java だと思っていました。
そこから約 20 年、主な機能追加だけを並べると次のような感じです。
- 2005 年 C# 2.0 でジェネリクス / Nullable 型
- 2007 年 C# 3.0 で LINQ
- 2010 年 C# 4.0 で動的型付け
- 2012 年 C# 5.0 で async/await（14 年前から async/await が使えていたのは今考えると凄い）
- 2015 年 C# 6.0 で null 条件演算子
- 2017 年 C# 7.0 でタプルや型スイッチ（.NET Framework はここら辺。厳密には C# 7.3）
- 2019 年 C# 8.0 で null 許容参照型や switch 式、パターンマッチ系
- 2020 年 C# 9.0 でトップレベルステートメントや init-only プロパティ、target-typed new など
- 2021 年 C# 10 で global using や System.Text.Json のソースジェネレーター、record struct など
- 2022 年 C# 11 で raw string literals、list patterns、required メンバー、ジェネリック数値計算など
- 2023 年 C# 12 でプライマリコンストラクターやコレクション式
- 2024 年 C# 13 で params コレクションや新しい
lock型 - 2025 年 C# 14（.NET 10 で対応）で field キーワードによる field-backed properties、extension members、null 条件代入（
x?.Prop = value）、partial なコンストラクター / イベントなど
特に C# 14 の extension members は、自分が所有していない型に対して、拡張メソッドだけでなく拡張プロパティや静的メンバーまで extension ブロックの中でまとめて定義出来るようになっていて、地味だけど嬉しい機能だと思っています。
こうして並べてみると、最初に抱いていた「Java クローン」という印象はすっかり消えて、自分の中では最高に書きやすい言語になりました。さらに、前回も言いましたが、このあと書いていく守備範囲の広さと合わせて、まだしばらくは C# メインでやっていこうと思える感じです。
.NET 10 について
かつては .NET Framework、.NET Core、Xamarin、Mono のように .NET 系のプラットフォームが乱立していました。今はそれらが .NET という 1 つのプラットフォームに統合されていて、C# で作れるものというのは、ほぼ .NET 10 で作れるものと言い換えても良い状況になっています。
名前が紛らわしいので、ここで .NET と .NET Framework の違いにも軽く触れておきます。ざっくり並べると次のような感じです。
| 観点 | .NET（現行 / .NET 10） | .NET Framework（4.8 / 4.8.1） |
|---|---|---|
| 系譜 | .NET Core 系の流れをくむ .NET 5 以降 | Windows と共に歩んできた従来の .NET |
| 対応 OS | Windows / Linux / macOS のクロスプラットフォーム | Windows 専用 |
| 機能追加 | 毎年新機能・パフォーマンス改善が入り続けている | 2019 年の 4.8 以降は凍結され、新機能は来ない |
| サポート | バージョンごとのライフサイクル | 載っている Windows のライフサイクルに紐づく |
| 新規開発 | 基本はこちらを選ぶ | それでしか動かない資産がある等の事情がある場合のみ |
個人的な整理としては、これから新規で作るなら基本は現行の .NET（.NET 10）を選んで、.NET Framework はそれでしか動かない資産があるとか移行しきれない事情がある場合に付き合うもの、というくらいに考えておくと良いと思っています。
.NET 10 は C# 14 に対応していて、Native AOT や JIT まわりの改善も継続的に入っていてパフォーマンスも上がり続けています。JIT（Just-In-Time コンパイル）は、アプリの実行中に必要なところをその都度ネイティブコードに変換していく従来からの方式です。一方の Native AOT を使うと、アプリを事前にネイティブコードにコンパイルして、起動が速く実行時のメモリ使用量も抑えたバイナリを作ることが出来ます。CLI ツールやコンテナー上で動かすサービスなど、こうした起動の速さや軽さが効いてくる用途で便利です。
.NET 10 の新機能まとめは公式ドキュメントにまとまっているので、ざっと眺めておくと良いと思います。
リリースのサイクルと LTS / STS
.NET は、統合されてからは毎年 11 月にメジャーバージョンアップするサイクルになっています。バージョン番号がそのままリリースされる年に対応していて、たとえば .NET 8 は 2023 年、.NET 9 は 2024 年、.NET 10 は 2025 年の 11 月にリリース、という感じで覚えやすいです。
そして、それぞれのバージョンには LTS（Long-Term Support）と STS（Standard-Term Support）の 2 種類があります。ざっくり言うと次のような違いです。
- LTS: 偶数バージョン（.NET 8、.NET 10 など）。リリースから 3 年間サポートされる。
- STS: 奇数バージョン（.NET 9、.NET 11 など）。リリースから 2 年間サポートされる（以前は 18 か月でしたが、.NET 9 から 24 か月に延長されました）。
毎年出るので「奇数だから STS、偶数だから LTS」で 1 年ごとに交互に来る、というイメージです。長く安定して使いたいなら LTS、最新の機能をいち早く試したいなら STS、という使い分けになります。個人的には、業務でしっかり運用するものは LTS を土台にしておくと、サポート期間を気にする頻度が減って楽だと思っています。
リリースとサポートのタイムラインを図にすると、こんな感じです。
こうして並べてみると、LTS を追いかけていけば常にサポート期間が重なった状態でバージョンアップしていけるのが分かります。.NET のサポートポリシーの詳細は公式ドキュメントにまとまっています。
開発可能なもの
ここから順に見ていきますが、その前に 1 つだけ前提を置いておきます。.NET Framework 4.8 は、どうしても .NET が使えないというケース以外では選択肢に入れない方が良いと思います。2019 年に 4.8 が出たあとメジャーバージョンアップはしないと宣言されているプラットフォームなので、新しい機能はもう来ません。
サポート自体は OS に紐づくので使えなくなるわけではないのですが、開発者としては、これから新規で作るものを機能追加が止まったプラットフォームに載せたくはないですよね。何かしがらみがあるなら別ですが、基本は現行の .NET を選んでいきましょう。
コンソール / CLI ツール
余計な要素を省いて、やりたいことだけをサクッと検証したいときは、やっぱりコンソールアプリケーションが最強だと思います。dotnet tool install -g でグローバルツールとしてインストールして CLI から叩けるツールも作れるので、npm でやっていたようなことが C# でも出来ます。
そして .NET 10 / C# 14 の目玉の 1 つが file-based apps です。プロジェクトファイル（csproj）を用意しなくても、.cs ファイル 1 つを直接実行出来るようになりました。
例えば、こんな app.cs を書いて、
Console.WriteLine("Hello from 広島!");
以下のように実行するだけで動きます。
dotnet run app.cs
実行すると以下のように表示されます。
Hello from 広島!
ちょっとした検証コードやスクリプト的な用途で、いちいちプロジェクトを作らなくてよくなったのは地味に便利だと思っています。file-based apps は #:package のようなディレクティブで NuGet パッケージの参照も書けるので、単一ファイルのまま結構いろいろ試せます。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| .NET 10 コンソールアプリ | とりあえずコンソールアプリを作るなら、これで良さそう。グローバルツールとして CLI から使えるツールも作れる | .NET ツールの管理 |
file-based apps（dotnet run app.cs） |
プロジェクトなしで .cs 1 ファイルを実行出来る。検証やスクリプト用途に便利 |
ファイルベースアプリ |
| .NET Framework | .NET Framework にしか対応していないものがあるならこっちでも。基本は選ばない | .NET Framework |
Web アプリケーション
サーバー側で HTML を組み立てて返す、いわゆる普通の Web アプリは ASP.NET Core で作れます。Windows でも Linux でも macOS でも動きますし、Docker イメージにするのも簡単です。ベースイメージも用意されていて、Visual Studio が Dockerfile を生成してくれたりもするので、コンテナー化のハードルも低めです。
とはいえ、最近は SPA じゃない、サーバーサイドで HTML を返して完結する Web アプリを新規で作る機会自体がだいぶ減ってきた印象です。管理画面やちょっとした社内ツールなど、ページ主体で十分なものはまだあるので選択肢としては押さえておきたいですが、フロントエンドをしっかり作るなら次に紹介する SPA 系の方に寄っていくことが多いと思います。
なお、.NET Framework 時代には ASP.NET MVC（MVC 5）や ASP.NET Web Forms といった選択肢がありました。今の ASP.NET Core MVC は前者の流れをくむものですし、Web Forms に至っては現行の .NET には移植されていません。どちらも新機能の追加は止まっていて、載っている Windows がサポートされている間はそのまま動く、という状態です。既存アプリの保守で触ることはあっても新規で選ぶものではないので、そこは注意しておきたいところです。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| ASP.NET Core MVC | コントローラーとアクションを起点に組み立てる定番のスタイル。従来からの作り方に慣れているならこれでも | ASP.NET Core MVC の概要 |
| ASP.NET Core Razor Pages | View と 1 対 1 で対応するページクラスにロジックを書くスタイル。コントローラーをどう分割するか悩まなくてよいので、SPA じゃないページ主体のアプリだと個人的にはこっちの方が作りやすいと感じます | Razor ページの概要 |
| ASP.NET MVC 5（.NET Framework） | .NET Framework 時代の MVC で、今の ASP.NET Core MVC の前身にあたる。新機能はもう来ないので、新規では選ばず既存資産の保守用 | ASP.NET MVC |
| ASP.NET Web Forms（.NET Framework） | さらに前の世代の、イベントドリブンでページを組む方式。.NET Framework でしか動かず現行の .NET には移植されていない。完全にレガシー扱いで新規開発では選ばない | ASP.NET Web Forms |
SPA・Web フロントエンド
いわゆる SPA（Single Page Application）や、C# でフロントエンドを書きたいときは Blazor です。SPA というのは、最初に 1 枚のページを読み込んだあとは、ページ全体を再読み込みせずに画面の中身だけを切り替えていく作りの Web アプリのことです。Blazor なら HTML/CSS で画面を作って、ロジックを C# で書けます。JavaScript との相互運用の仕組みもあるので、既存の JS ライブラリを呼び出すことも出来ます。
.NET 8 以降、Blazor は「Blazor Web App」として統合されて、レンダーモードをコンポーネント単位で選べるようになりました。レンダーモードは Static SSR / Interactive Server / Interactive WebAssembly / Interactive Auto の 4 つです。ここで出てくる SSR（Server-Side Rendering）はサーバー側で HTML を組み立てて返す方式、WebAssembly はブラウザ上でネイティブに近い速度でコードを動かす仕組みだと思っておけば大丈夫です。最初はサーバー側でレンダリングしておいて、あとから Interactive Server に切り替えることもできます。残りの Interactive Auto は、初回は Interactive Server で素早く動かしつつ、WebAssembly のダウンロードが終わったらそちらに切り替わる、両者のいいとこ取りをするモードです。この「1 つのアプリの中でコンポーネントごとに動き方を選べる」というのがなかなか強力だと思っています。しかし、Interactive Auto は Static SSR, Interactive Server, Interactive WebAssembly 全てで動くように作らないといけないので開発負荷は高いです。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Blazor Web App | レンダーモード（Static SSR / Interactive Server / Interactive WebAssembly / Interactive Auto）をコンポーネント単位で選べる。今から Blazor で作るならまずこれ。ASP.NET Core のチームが今一番投資しているプラットフォームの1つ。 | ASP.NET Core Blazor |
| Blazor WebAssembly | WebAssembly 上で C# が動く。初回ロードが重くなりがちだったが、.NET 10 でプリロードなどの改善が入った | Blazor のレンダー モード |
| Uno Platform 🔸 | Microsoft 製ではなくサードパーティー製の OSS（オープンソースソフトウェア）。XAML ベースの UI をクロスプラットフォームで作れる。WebAssembly にも対応 | Uno Platform Documentation |
| Avalonia 🔸 | こちらも Microsoft 製ではなく OSS。XAML ベースのクロスプラットフォーム UI。WebAssembly にも対応 | Avalonia Docs |
表の中で 🔸 を付けたものは Microsoft 製ではないサードパーティー製・OSS の選択肢です（以降の表でも同じ意味で使います）。
とはいえ、SPA やフロントエンドを作る人の母数でいうと、やっぱり React / Vue / Angular / Svelte といった JavaScript 系のライブラリの方が圧倒的に多いというのが正直なところなので、そこは押さえた上で C# という選択肢もあるよ、くらいの感覚で捉えておくと良いと思います。
Web API
Web API も基本は Web アプリケーションと同じく ASP.NET Core です。REST API の作成から OpenAPI ドキュメントの生成まで一通りそろっているので、迷ったらここから始めるのが良いと思います。.NET 9 以降は OpenAPI ドキュメント生成が標準で組み込まれていて、Swagger 系のパッケージを別途足さなくても定義を出せるようになっています。
新規で作るなら、今は Minimal API が第一候補です。Microsoft の公式ドキュメントでも新規プロジェクトには Minimal API を推奨する書き方になっていて、コントローラーベースは高度なモデルバインディングや検証、OData などが必要なときの選択肢という位置づけになっています。数年前は「コントローラーベースでしっかり作る」のが定番でしたが、そのあたりの空気はだいぶ変わってきた印象です。
なお、.NET Framework 時代には ASP.NET Web API（Web API 2）という専用のフレームワークがありましたが、今は ASP.NET Core 側に統合されています。こちらも新機能は来ないので、新規で選ぶものではなく、既存資産を触るときに出てくる名前という位置づけです。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Minimal API | 数行で REST エンドポイントが書けるくらいコード量が少なく、パフォーマンス面でも有利。マイクロサービスから本格的な API まで対応できて、新規で作るなら第一候補 | Minimal API の概要 |
| ASP.NET Core Web API（コントローラーベース） | MVC ベースでしっかり作り込める。高度なモデルバインディングや検証、OData などが必要なとき、あるいは既存資産や慣れを活かしたいときはこちら | Web API の作成 |
| ASP.NET Web API 2（.NET Framework） | .NET Framework 時代の Web API 用フレームワークで、今の ASP.NET Core の Web API に統合された前身にあたる。新機能は来ないので、新規では選ばず既存資産向け | ASP.NET Web API |
OpenAPI まわりについては以下も参考になります。
サーバーレス
C# はサーバーレスプラットフォーム上でも動かせます。Azure Functions は当然ネイティブで対応していますし、AWS Lambda も早くから C# に対応しています。.NET の Azure Functions は現在 isolated worker model が現行のモデルで、Functions のランタイムとアプリのプロセスが分離されているぶん、使う .NET のバージョンを自分で選びやすくなっています。
Azure Functions まわりでもう 1 つ触れておきたいのが Durable Functions です。これは、通常はステートレス（呼び出しごとに状態を持たず、その回の処理だけで完結する）な Functions の上で、状態を持った長時間実行のワークフローを書けるようにする拡張です。オーケストレーター関数で処理の流れをそのままコードとして書けて、途中でクラッシュしたり再起動したりしても状態が保持されます。承認待ちや外部イベント待ちで何日も止まるような処理でも、待っている間はコンピューティングリソースを消費せずに済むのが嬉しいところです。
そして最近おもしろいのが、この Durable Functions と Microsoft Agent Framework を組み合わせて、長時間実行できる AI エージェントのワークフローを組めるようになってきていることです。エージェントのセッションの状態を永続化して、人間の承認をはさんだり複数のエージェントを協調させたりといった、時間のかかるワークフローを作れます。ただし、この組み合わせ（Durable Task extension for Microsoft Agent Framework）は 2026 年 7 月時点ではまだプレビューなので、そこは踏まえた上で試すのが良いと思います。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Azure Functions（isolated worker model） | Azure のサーバーレスで動かしたいならこれ。現行は isolated worker model | .NET 分離ワーカー モデル |
| Durable Functions | Functions 上で状態を持った長時間実行のワークフローを書ける拡張。Agent Framework と組み合わせて長時間の AI エージェントワークフローも組める（この組み合わせは現時点でプレビュー） | Durable Functions の概要 |
| AWS Lambda | AWS のサーバーレスで動かしたいならこれ | C# による Lambda 関数のビルド |
HTTP で受けてメッセージキューに投げて、その裏でごにょごにょやるような処理だと、Web API 部分も Functions で作ってしまうのもアリだと思います。
デスクトップ
Windows デスクトップアプリの選択肢は少し整理が必要です。2026 年時点で、現代的な Windows デスクトップ開発の第一候補は WinUI（WinUI 3 / Windows App SDK）です。最近は WinUI 3 のことを単に「WinUI」と呼ぶことも増えてきました。
ちなみに 2026 年 5 月に、AI エージェントで WinUI アプリを開発するための「WinUI 用の開発スキル」が公開されました。GitHub Copilot CLI や Claude Code といったエージェントに WinUI / Windows App SDK 開発の知識を持たせるプラグインで、プロジェクトのひな形作成からビルド・実行・テスト・パッケージングまでの一連の流れをエージェント自身で回せるように作られています。GitHub Copilot CLI なら /plugin install winui@awesome-copilot でインストール出来ます。実はこの記事も Copilot CLI で書いているのですが、こういうエージェント向けのスキルが公式から出てくるのは面白い流れだなと個人的には思っています。
一方で WPF や Windows Forms も .NET 上で今なお現役でサポートされています。特に WPF は .NET 9 以降で Fluent 系のモダンなテーマが入ったので、既存の WPF 資産を活かしつつ見た目を今風に寄せる、といったこともやりやすくなっています。UWP や WinUI 2 はレガシー扱いで、新規開発ではおすすめしません。
WPF も Windows Forms も、もともとは .NET Framework 上の技術で、.NET Framework 版も今なお動きます。ただし .NET Framework 側は前述のとおり機能追加が止まっているので、新規で作るなら現行の .NET 版を選んでおいた方が、新しい言語機能やパフォーマンス改善の恩恵を受けられます。既存の .NET Framework 製の WPF / WinForms アプリがあるなら、.NET へのアップグレードを検討すると良いと思います。
XAML ベースの UI をクロスプラットフォームで動かしたいなら、Uno Platform や Avalonia も有力な選択肢です。どちらも Microsoft 製ではなくサードパーティー製・OSS のフレームワークなので、そこは押さえておくと良いと思います。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| WinUI（WinUI 3 / Windows App SDK） | 現代の Windows デスクトップ開発の第一候補。新規はまずこれを検討 | WinUI 3 |
| WPF（.NET） | .NET 上で現役。.NET 9 以降で Fluent 系のテーマが入ってモダンな見た目にしやすくなった | WPF |
| Windows Forms（.NET） | こちらも .NET 上で現役。手早く業務向けのフォームを作るには依然として強い | Windows Forms |
| WPF（.NET Framework） | .NET Framework 版の WPF。今も動くが機能追加は止まっている。新規は .NET 版を、既存資産は .NET へのアップグレードを検討 | WPF (.NET Framework) |
| Windows Forms（.NET Framework） | .NET Framework 版の WinForms。こちらも動くが機能追加は止まっている。方針は WPF と同じ | Windows Forms (.NET Framework) |
| Uno Platform / Avalonia 🔸 | Microsoft 製ではなくサードパーティー製・OSS。XAML ベースでクロスプラットフォーム対応。Windows 以外でも動かしたいならこちら | Uno Platform / Avalonia |
| UWP / WinUI 2 | レガシー扱い。新規開発では選ばない | Windows App SDK への移行 |
モバイル・クロスプラットフォーム
Android / iOS 向けのアプリを C# で作るなら、今の第一候補は .NET MAUI です。1 つのコードベースで Android / iOS / macOS / Windows 向けのアプリを作れて、UI は XAML で書けます。Blazor Hybrid と組み合わせれば、ネイティブアプリの中に Blazor で作った UI をホストすることも出来るので、Web の資産を活かしたい場合にも選択肢になります。
ここで 1 つ注意点として、かつてモバイル開発の定番だった Xamarin は 2024 年 5 月 1 日にサポートが終了（EOL）しています。新規開発で選ぶものではないので、これから作るなら .NET MAUI を選びましょう。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| .NET MAUI | モバイル・クロスプラットフォームなら今はこれ。UI は XAML で、Blazor Hybrid にも対応 | .NET MAUI のドキュメント |
| Uno Platform 🔸 | Microsoft 製ではなくサードパーティー製・OSS。XAML ベースでモバイルにも対応。Web まで含めて 1 つのコードで狙いたいときに | Uno Platform |
| Avalonia 🔸 | こちらも Microsoft 製ではなく OSS。クロスプラットフォームでモバイル対応も進んでいる | Avalonia Docs |
| Unity 🔸 | Microsoft 製ではなくサードパーティー（Unity Technologies）製。ゲーム向けが主だが、モバイルアプリ用途で使うことも出来る | Unity |
| Xamarin | 2024 年 5 月 1 日で EOL。新規では使わず .NET MAUI へ | .NET MAUI への移行 |
ゲーム / MR
ゲーム開発では Unity がやはり定番です。C# でゲームロジックを書けますし、Mixed Reality（MR）や AR 系のアプリでも Unity を使うと楽が出来る場面が多いです。2D の UI も作れるので、ゲーム以外の用途で使うこともあります。
ただ、Unity で使う C# のバージョンには少し注意が必要です。Unity は長らく Mono ベース（.NET Standard 2.1 プロファイル）で動いていて、2026 年時点の Unity 6 でも使える C# は C# 9 相当と、通常の .NET と比べるとかなり古めです。record が素直に使えなかったりと、最新の言語機能を前提にしたコードはそのままだと動かないことがあります。とはいえここは動きがあって、Unity は Mono から CoreCLR への移行（.NET モダナイゼーション、通称「Path to CoreCLR」）を進めています。これが入ると、モダンな .NET（.NET 10 世代）と新しい C# が Unity でも使えるようになる見込みで、個人的にはかなり期待しています。
もう 1 つ、オープンソースのゲームエンジンとして Godot も C# に対応しています。Godot は独自の GDScript がメインの言語ですが、.NET エディションを使えば C# でゲームロジックを書けます。ここ数年で存在感が増してきたエンジンで、Unity とはまた違った軽量さが魅力です。バージョンの対応関係でいうと、Godot 4.4 以降は C# を使う場合の下限が .NET 8（LTS）で、.NET 10 対応は Godot 4.6 で入る予定になっています。ちなみに 2026 年時点では C# プロジェクトの Web（HTML5）エクスポートはまだ未対応で、そこは GDScript を使う必要がある、といった違いもあります。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Unity 🔸 | Microsoft 製ではなくサードパーティー（Unity Technologies）製。ゲームや MR / AR 開発の定番。ロジックは C# で書ける。現状は Mono ベースで C# 9 相当と古めだが、CoreCLR への移行（.NET モダナイゼーション）が進行中 | Unity |
| Godot（.NET エディション）🔸 | Microsoft 製ではないオープンソースの軽量なゲームエンジン。.NET エディションなら C# でゲームを書ける。Godot 4.4 以降は .NET 8 が下限で、.NET 10 対応は 4.6 で予定 | C#/.NET（Godot Docs） |
機械学習
いわゆる従来型の機械学習を C# で行いたいときは ML.NET が使えます。学習済みモデルを使った推論はもちろん、自分でモデルを学習させることも出来ます。C# のアプリケーションにそのまま機械学習の処理を組み込めるので、既存の .NET アプリに予測機能を足したい、といったケースで便利です。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| ML.NET | .NET 向けの機械学習フレームワーク。学習・推論を C# のアプリに組み込める | ML.NET のドキュメント |
AI アプリ・AI エージェント開発
ここ数年で一気に存在感が増したのが、生成 AI や LLM を使ったアプリ、そして AI エージェントの開発です。LLM（Large Language Model、大規模言語モデル）は、ChatGPT のような生成 AI の中身になっている、文章を理解して続きを生成するモデルのことです。前述の ML.NET が従来型の機械学習向けなのに対して、こちらは LLM を呼び出したり、エージェントを組んだりする世界の話です。この分野は .NET でもかなり整ってきていて、個人的にはいま一番おもしろい領域だと思っています。
まず土台になるのが Microsoft.Extensions.AI です。これは .NET 標準の AI 抽象化ライブラリで、IChatClient や IEmbeddingGenerator といった共通インターフェースを通して、OpenAI / Azure OpenAI / ローカルモデルなどを同じような書き味で扱えます。AI アプリのビルディングブロックという位置づけで、どの AI ライブラリを使うにしても、この抽象化の上に乗っていることが多いです。
そのうえで AI エージェントを本格的に作るなら、Microsoft Agent Framework が本命です。これは Semantic Kernel と AutoGen を統合・進化させた後継のフレームワークで、単一エージェントからマルチエージェントのワークフローまで扱えます。2025 年 10 月にパブリックプレビューが公開され、2026 年 4 月 2 日に .NET 版の V1（1.0.0）が正式リリースされました。すでに安定版が出ているので、プレビュー時代のような破壊的変更を気にせず使い始められるのも嬉しいところです。
AI 抽象化の上に AI エージェントのフレームワークが乗る、という関係になっているので、まず Microsoft.Extensions.AI を押さえておくと、その先の理解もしやすいと思います。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Microsoft.Extensions.AI | .NET 標準の AI 抽象化ライブラリ。IChatClient / IEmbeddingGenerator などで各種モデルを共通の形で扱える |
Microsoft.Extensions.AI |
| Microsoft Agent Framework | AI エージェント開発の中心。単一エージェントからマルチエージェント・ワークフローまで。2026/4/2 に .NET 版 V1（1.0.0）リリース済み | Microsoft Agent Framework |
クラウドネイティブ・オーケストレーション
複数のサービスを組み合わせた分散アプリを作るときに便利なのが Aspire です。以前は .NET Aspire という名前でしたが、v13（2025 年 11 月、.NET Conf 2025 で発表）で「.NET」が取れて、正式名称が Aspire になりました。
Aspire は、API やフロントエンド、DB やキャッシュといったミドルウェア、外部サービスなどを組み合わせた分散アプリを、ローカル開発からデプロイまで扱いやすくするためのオーケストレーションや開発体験を提供するものです。AppHost にアプリ全体の構成を C# で書いておくと、それを起動するだけで必要なものが一通り立ち上がります。個人的には、ローカルで複数サービスやミドルウェアを立ち上げる用途で、これがかなり便利だと感じています。
v13 では対応する言語の幅も広がっていて、.NET だけでなく Python や JavaScript / Node.js といった他の言語で書かれたアプリも、まとめて構成・起動できるようになりました。「.NET」が名前から取れたのは、まさにこのあたりの流れを反映したものだと思います。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Aspire（以前は .NET Aspire） | 複数サービスを組み合わせた分散アプリのローカル開発〜デプロイを支援。v13 で .NET だけでなく Python / JavaScript など他の言語のアプリも扱えるようになった | Aspire Docs |
IoT・その他
最後に、ここまでのカテゴリに収まりきらないものをまとめて紹介します。.NET IoT ライブラリや Azure IoT を使えば、C# でセンサーやデバイスを扱う IoT 開発が出来ます。サービス間通信では gRPC が ASP.NET Core でサーバー・クライアントの両方を作れて、WCF の移行先としても案内されています。マイクロサービス的な構成も、これまで挙げてきた ASP.NET Core や Aspire を組み合わせれば C# で組んでいけます。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| .NET IoT / Azure IoT | Raspberry Pi などのデバイス制御やクラウド連携を C# で書ける | .NET IoT ライブラリ / Azure IoT |
| gRPC（ASP.NET Core） | サーバー・クライアントとも C# で作れる。WCF の移行先としても案内されている | ASP.NET Core の gRPC |
C# が向かないこと
ここまで守備範囲の広さを書いてきましたが、もちろん C# が最適解ではない領域もあります。
例えば iOS / Android のネイティブ機能をとことん使い倒したい、最新の OS の新機能をいち早く使いたいといったケースでは、Swift や Kotlin でネイティブに書いた方が素直なことが多いです。クロスプラットフォームのフレームワークは、どうしても各 OS の最新機能への追従に少しラグが出ることがあります。
機械学習・AI の研究開発まわりも、エコシステムやサンプルの厚みでいうと今は Python が主流です。C# からも Microsoft.Extensions.AI などで LLM を使ったアプリは十分作れますが、モデルそのものの研究や最新手法の実験だと Python の資産に乗った方が速い、という場面は多いと思います。
このあたりは「C# でも出来なくはないけど、無理に寄せなくてもいい」くらいの温度感で捉えておくと良いと思います。
.NET Framework から .NET への移行について
新規開発は現行の .NET でいこう、という話をここまでしてきましたが、現実には .NET Framework で動いている既存資産を抱えているケースも多いと思います。ということで、移行についても少し触れておきます。
まず前提として、移行の難易度は「何を移行するか」でかなり変わります。個人的な感覚だと、現行の .NET に同じものが用意されているかどうかが一番大きな分かれ目だと思っています。
移行が比較的楽なのは WPF と Windows Forms です。どちらも現行の .NET（Windows 専用のワークロードとして）にそのまま載っていて、同じ API が使えます。もちろんプロジェクトファイルの形式を SDK スタイルに直したり、一部の依存ライブラリを .NET 対応のものに差し替えたりといった作業は必要ですが、UI フレームワークとして同じものが存在するので、相対的には素直に移行しやすい部類だと思います。
やっかいなのが Web まわりです。ASP.NET Core は、名前こそ ASP.NET を引き継いでいますが、中身は一から再設計して作り直されたものです。似ているんだけど別物、という表現がしっくりきます。
分かりやすいのが HttpContext で、クラス名は同じなのにプロパティの戻り値が違う、というものがちょこちょこあります。例えばこんな感じです。
-
HttpContext.Session: .NET Framework ではSystem.Web.SessionState.HttpSessionStateが返ってきて、任意のオブジェクトをそのまま出し入れ出来ました。ASP.NET Core ではMicrosoft.AspNetCore.Http.ISessionが返ってきて、扱えるのは基本 byte 配列（GetString/SetStringなどの補助メソッドはある）で、オブジェクトを入れたいなら自前でシリアライズする必要があります。しかもセッションのミドルウェアを有効にしていないとそもそも使えません。 -
HttpContext.User: .NET Framework ではSystem.Security.Principal.IPrincipalでしたが、ASP.NET Core ではSystem.Security.Claims.ClaimsPrincipalになっています（ClaimsPrincipalはIPrincipalを実装しているのでクレームベースに寄せた形です）。
名前が同じだからコピペで動くだろう、と思って持ってくると普通にコンパイルエラーになったり、挙動が違ったりするので、ここは要注意ポイントです。
こういう事情があるので、Web アプリの移行は「行き先が何か」で難易度が大きく変わります。
- ASP.NET Web Forms: そもそも現行の .NET に行き先がありません。公式には Blazor への移行が案内されていますが、Web Forms のイベントドリブンなページモデル（ViewState やポストバック）と Blazor のコンポーネントモデルは考え方からして違うので、素直に変換出来るものではなく、実質は作り直しに近いです。
- ASP.NET MVC 5: こちらは ASP.NET Core MVC という行き先があるぶん Web Forms よりはマシです。ただ前述のとおり、似ているだけの別物なので、そっくりさんに向けて書き直していく感覚になります。コントローラーやアクションといった概念は引き継がれているので、Web Forms よりは移行のイメージが付きやすいと思います。
データアクセスまわりも同じ構図です。Entity Framework 6（EF6）と Entity Framework Core（EF Core）も、EF Core が一から書き直されたものなので、EF6 の単純なアップグレードではありません。モデルの構成方法もマイグレーションの仕組みも違いますし、一部の機能は挙動が変わっていたり未対応だったりするので、それなりに書き換えとテストが必要になります。
こうして見ていくと、手作業でぜんぶやるのはなかなか骨が折れます。そこで現実的な選択肢になってくるのが AI を使った移行です。最近は GitHub Copilot app modernization という .NET 向けの仕組みがあって、既存コードのアセスメント（現状把握）→ アップグレードの計画 → 実際のコード変換、という流れを AI エージェントに手伝ってもらえます。変更内容も追えるようにドキュメント化されるので、レビューしながら進めやすいです。
個人的には、単純な置き換えで済む部分は AI にどんどん任せて、別物になっている箇所（先ほどの HttpContext のようなところ）を人間が重点的に確認する、という分担で進めるのが今どきの現実解かなと思っています。
まとめ
ということで、2026 年 / .NET 10 時点で C# / .NET を使って作れるものをざっと並べてみました。
コンソールや Web、API、デスクトップ、モバイル、ゲーム、機械学習、そして AI エージェントやクラウドネイティブなオーケストレーションまで、1 つの言語でこれだけ広くカバー出来るのは、あらためて見るとなかなか凄いことだと思います。
チームやプロジェクトをまたいでも C# / .NET で統一しておけると、言語やエコシステムの学び直しが減って、知識を横に流用しやすくなります。個人的には、この守備範囲の広さこそが C# を使い続けている一番の理由だったりします。
それでは、良い C# / .NET ライフを！
Discussion