.NET on LinuxをUbuntuで開発・運用している場合、2026年4月の重要ポイントは明確です。Ubuntu 26.04では.NET 10が標準的な選択肢になり、.NET 8／9はbackports PPA経由、コンテナはresoluteタグへの移行確認が必要です。Microsoftは2026年4月23日に公式.NET BlogでUbuntu 26.04向けの.NETサポートとパッケージ変更を詳しく説明しており、開発者だけでなくDevOpsエンジニア、プラットフォームチームもビルド環境・CI・コンテナベースイメージ・サポート期限を見直すべきタイミングです。(Microsoft for Developers)
.NET on Linuxの最新動向: Ubuntu 26.04で何が変わったか
Microsoft公式ブログ「What’s new for .NET in Ubuntu 26.04」の中心は、Ubuntu 26.04 LTSにおける.NETの扱いがよりUbuntuネイティブな形に整理されたことです。Ubuntu 26.04には.NET 10が含まれ、Microsoftは.NET 10のインストール例、コンテナイメージのresoluteタグ、Native AOT、.NET 8／9のPPA導入方法を示しています。(Microsoft for Developers)
実務上は、次のように捉えると分かりやすいです。
| 更新ポイント | 何が変わったか | 取るべき対応 |
|---|---|---|
| .NET 10 | Ubuntu 26.04の主要な.NETバージョンとして利用可能 | 新規開発・長期運用は.NET 10を第一候補にする |
| .NET 8／9 | Ubuntu 26.04ではbackports PPA経由で利用 | 既存アプリはサポート期限とPPA運用を確認する |
| コンテナ | .NET 10+向けUbuntu 26.04イメージでresoluteタグを使用 | Dockerfileのnoble固定を見直す |
| Native AOT | dotnet-sdk-aot-10.0とclangでAOTビルドを扱いやすくなった | CLIツール、小型API、起動速度重視のサービスで検証する |
| OS基盤 | Linux kernel 7.0、PQC、cgroup v1削除などが関連 | CI、監視、コンテナ実行基盤の互換性を確認する |
Ubuntu 26.04では.NET 10が本命になる
Ubuntu 26.04で.NETを使う場合、まず押さえるべきは.NET 10です。Microsoftの公式記事では、Ubuntu 26.04で.NET 10をインストールする基本コマンドとして、次の手順が示されています。(Microsoft for Developers)
sudo apt update
sudo apt install -y dotnet-sdk-10.0インストール後は、次のコマンドでSDKの認識状態を確認します。
dotnet --version
dotnet --infoASP.NET Coreアプリを実行するだけなら、SDKではなくランタイムを入れる構成も選べます。
sudo apt update
sudo apt install -y aspnetcore-runtime-10.0ASP.NET Coreを使わないコンソールアプリやワーカーだけであれば、より小さい.NET Runtimeを選べます。
sudo apt install -y dotnet-runtime-10.0開発端末やCIのビルドジョブにはSDK、本番サーバーやランタイム専用コンテナにはRuntimeまたはASP.NET Core Runtimeを使い分けるのが基本です。SDKを本番実行環境に入れると、不要なパッケージが増え、イメージサイズや攻撃対象領域も広がりやすくなります。
.NET 8／9はbackports PPA経由で扱う
既存システムでは、すぐに.NET 10へ移行できないケースもあります。その場合、Ubuntu 26.04では.NET 8／9をbackports PPAから導入する流れになります。Microsoft公式記事とLaunchpadのPPA説明では、Ubuntu 26.04向けに.NET 8.0と.NET 9.0がbackports PPAで提供されることが示されています。(Microsoft for Developers)
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository ppa:dotnet/backports
sudo apt update
sudo apt install -y dotnet-sdk-8.0.NET 9を使う場合は次のようにします。
sudo apt install -y dotnet-sdk-9.0ここで重要なのは、backports PPAは「使える」ことと「長期サポートされる」ことを分けて考える必要がある点です。.NET 8と.NET 9のサポート終了日は2026年11月10日、.NET 10のサポート終了日は2028年11月14日とされています。長期運用するサービスでは、Ubuntu 26.04 LTSだからといって.NET 8／9を数年間そのまま使えると考えないほうが安全です。(Microsoft)
| 利用バージョン | Ubuntu 26.04での位置づけ | 向いているケース | 注意点 |
|---|---|---|---|
| .NET 10 | 標準的な選択肢、LTS | 新規開発、長期運用、基盤刷新 | アプリ互換性テストは必須 |
| .NET 9 | STS、PPA経由 | 既に.NET 9で稼働中の短期運用 | サポート期限が近い |
| .NET 8 | LTSだがPPA経由 | 既存LTSアプリの延命 | .NET 10移行計画を並行して作る |
パッケージフィードの混在に注意する
Ubuntuで.NETを管理するときに失敗しやすいのが、Ubuntuの組み込みフィード、backports PPA、Microsoftフィード、手動インストールを混ぜてしまうことです。Microsoft Learnでは、複数のパッケージリポジトリから.NETパッケージを混在させると、アプリが特定バージョンの.NETを解決する際に問題が起きる可能性があると説明しています。(Microsoft Learn)
特にプラットフォームチームは、次の方針を明文化しておくと運用トラブルを減らせます。
| 環境 | 推奨方針 | 理由 |
|---|---|---|
| Ubuntu 26.04の新規環境 | Ubuntu標準フィードで.NET 10 | 依存関係と更新管理をaptに寄せやすい |
| .NET 8／9が必要な環境 | backports PPAを追加 | Ubuntu標準フィードにないバージョンを補える |
| Dockerイメージ | Microsoft公式.NETイメージのタグを固定 | ビルド再現性を確保しやすい |
| 手動配置 | 原則避ける | パッチ適用と棚卸しが難しくなる |
| Microsoftフィードとの混在 | 慎重に扱う | フィード混在による解決問題を避けるため |
既存サーバーでは、まず現在のインストール元を確認しましょう。
apt-cache policy dotnet-sdk-10.0 dotnet-sdk-9.0 dotnet-sdk-8.0
apt list --installed 'dotnet*' 'aspnetcore*'
dotnet --list-sdks
dotnet --list-runtimes古い手順書にMicrosoftパッケージリポジトリの追加コマンドが残っている場合は、Ubuntu 26.04向けに更新する必要があります。
コンテナはnobleからresoluteへの移行を確認する
.NET on Linuxをコンテナで運用しているチームにとって、今回の更新で最も実務影響が大きいのはベースイメージです。Microsoftは.NET 10+向けのUbuntu 26.04コンテナイメージを提供しており、Ubuntu 26.04ではresoluteタグを使います。Ubuntu 24.04系のnobleタグから更新する場合は、Dockerfile内のタグを見直します。(Microsoft for Developers)
例として、次のようなDockerfileはUbuntu 24.04ベースです。
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0-noble AS build
FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseledUbuntu 26.04ベースへ移行する場合は、次のようにresoluteへ変更します。
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0-resolute AS build
FROM mcr.microsoft.com/dotnet/aspnet:10.0-resolute-chiseledただし、Dockerfileのタグ変更だけで「すべてUbuntu 26.04相当になった」と考えるのは危険です。コンテナはホストOSのカーネルを使うため、Ubuntu 26.04コンテナをUbuntu 24.04ホスト上で動かす場合、実際のカーネルはホスト側のものになります。Microsoft公式記事でも、26.04コンテナを24.04ホストで動かす例ではLinux kernel 6.xを使うと説明されています。(Microsoft for Developers)
本番移行前には、最低限次の確認を行います。
docker run --rm mcr.microsoft.com/dotnet/aspnet:10.0-resolute dotnet --info
docker run --rm mcr.microsoft.com/dotnet/aspnet:10.0-resolute cat /etc/os-release
docker info | grep -i cgroupKubernetesで運用している場合は、アプリコンテナだけでなく、ノードOS、containerd、runc、監視エージェント、サイドカーの互換性も確認対象に含めてください。
cgroup v1削除は監視・制限・サイドカーに影響しやすい
Ubuntu 26.04ではsystemd 259への更新に伴い、cgroup v1のサポートが削除されています。Ubuntuのリリースノートでは、legacyおよびhybrid階層のcgroup v1サポート削除が明記されています。(Ubuntu Documentation)
.NET自体は以前からcgroup v2に対応しているため、Microsoft公式記事ではcgroup v1削除は大きな問題にならない見方を示しています。とはいえ、実際の障害は.NETランタイムそのものではなく、周辺ツールで起きがちです。(Microsoft for Developers)
確認すべき対象は次のとおりです。
| 対象 | 確認内容 |
|---|---|
| コンテナランタイム | cgroup v2でCPU・メモリ制限が正しく反映されるか |
| APM／監視エージェント | cgroup v1のパスを前提にしていないか |
| サイドカー | /sys/fs/cgroupを直接読んでいないか |
| 自社スクリプト | メモリ制限やCPU制限の取得方法が古くないか |
| Kubernetes設定 | ノードOS更新後もリソース制限・HPA・ログ収集が正常か |
現在の環境がcgroup v2かどうかは、次のコマンドで確認できます。
stat -fc %T /sys/fs/cgroupcgroup2fsと表示されればcgroup v2です。CIや検証環境で先にUbuntu 26.04ノードを用意し、メモリ制限付きでASP.NET Coreアプリを動かして、GCやスレッドプール、監視メトリクスに異常がないかを見ると安全です。
Native AOTは小型ツールや高速起動APIで試す価値がある
今回のMicrosoft公式記事では、Native AOTも具体例付きで扱われています。Ubuntu 26.04ではdotnet-sdk-aot-10.0パッケージを使い、AOTビルドに必要なツールとしてclangもインストールします。(Microsoft for Developers)
sudo apt update
sudo apt install -y dotnet-sdk-aot-10.0 clang通常のプロジェクトでNative AOTを試す場合は、次のように発行できます。
dotnet publish -c Release -r linux-x64 --self-contained true /p:PublishAot=trueNative AOTは、次のような用途と相性が良いです。
| 向いている用途 | 理由 |
|---|---|
| CLIツール | 起動が速く、単一バイナリ配布に向いている |
| 小型API | コールドスタートを短縮しやすい |
| バッチ処理 | ランタイム依存を減らしやすい |
| エッジ環境 | 配布物を小さくしやすい |
一方で、反射、動的コード生成、トリミング非対応ライブラリを多用するアプリでは、Native AOT化でビルドエラーや実行時の不具合が出ることがあります。いきなり本番適用するのではなく、まずは小さな内部ツールや限定的なAPIから検証するのが現実的です。
Linux kernel 7.0とPQCは「すぐ書き換え」ではなく検証テーマとして扱う
Ubuntu 26.04のリリースノートでは、Linux kernel 7.0、OpenSSLにおけるポスト量子暗号（PQC）アルゴリズム対応など、セキュリティと基盤に関わる更新も示されています。Microsoft公式記事でも、Ubuntu 26.04の関連変更としてLinux 7.0、PQC、cgroup v1削除が取り上げられています。(Ubuntu Documentation)
ただし、アプリ開発者が今すぐ大規模なコード変更をする必要があるとは限りません。現実的には、次のように分けて対応します。
| 変更 | すぐやること | 中長期でやること |
|---|---|---|
| Linux kernel 7.0 | CI・ステージングで起動確認 | ノードOS更新計画に組み込む |
| PQC | TLS終端、OpenSSL依存、外部接続の棚卸し | セキュリティ要件に応じて検証環境を作る |
| cgroup v1削除 | 監視・制限・サイドカー確認 | cgroup v2前提の運用へ統一する |
| systemd 259 | サービス定義と起動スクリプト確認 | 古いSystem V系スクリプトを移行する |
プラットフォームチームは「Ubuntu 26.04へ上げる」だけでなく、「.NET 10へ上げる」「コンテナタグを変える」「ノードOSを変える」「監視エージェントを変える」を別々の変更として扱うと、障害時の切り分けがしやすくなります。
DevOpsチーム向け移行チェックリスト
Ubuntu 26.04と.NET 10への移行では、コードのビルド可否だけで判断しないことが重要です。次の順序で確認すると、影響範囲を整理しやすくなります。
| 手順 | 確認内容 | コマンド・観点 |
|---|---|---|
| 現状把握 | 使用中の.NET SDK／Runtimeを確認 | dotnet --info、dotnet --list-runtimes |
| フィード確認 | Ubuntu標準、PPA、Microsoftフィードの混在確認 | apt-cache policy |
| ビルド検証 | .NET 10で復元・ビルド・テスト | dotnet restore、dotnet test |
| コンテナ検証 | resoluteタグでビルド | Dockerfileのタグ確認 |
| ランタイム検証 | CPU・メモリ制限下で実行 | docker run -m、Kubernetes limit |
| 監視確認 | メトリクス・ログ・APMの継続性 | cgroup v2、サイドカー |
| サポート確認 | .NET 8／9継続可否 | EOL日と移行計画 |
| 本番展開 | ロールバック可能な段階展開 | Canary、Blue/Green |
CIでは、少なくとも次のようなジョブを追加しておくと安心です。
dotnet restore
dotnet build --configuration Release
dotnet test --configuration Release --no-build
dotnet publish --configuration Releaseコンテナアプリなら、ビルド後に簡単なスモークテストも入れます。
docker build -t myapp:ubuntu2604 .
docker run --rm -p 8080:8080 myapp:ubuntu2604
curl -f http://localhost:8080/healthヘルスチェックがないサービスでは、Ubuntu 26.04移行を機に/healthや/readyを用意しておくと、Kubernetesやロードバランサーでの運用が楽になります。
既存アプリは.NET 10移行を前提にロードマップを作る
.NET 8はLTSですが、サポート終了は2026年11月10日です。.NET 9も同日にサポート終了が予定されています。一方、.NET 10はLTSとして2028年11月14日までサポートされる予定です。長期運用を前提にするなら、Ubuntu 26.04への移行と.NET 10への移行を同じロードマップ上で考えるのが自然です。(Microsoft)
おすすめの進め方は次のとおりです。
- 新規サービスは.NET 10とUbuntu 26.04を標準にする
- .NET 8の既存サービスは、まずUbuntu 26.04上で動作検証し、次に.NET 10移行を計画する
- .NET 9のサービスは、STSであることを前提に早めに.NET 10へ寄せる
- コンテナは
nobleとresoluteを同時に検証し、差分を記録する - 本番移行前に、監視・ログ・バックアップ・ロールバック手順を更新する
特にグローバルに複数リージョンで運用しているサービスでは、OS、.NET、コンテナランタイム、クラウドVMイメージの更新タイミングがずれます。すべてを同日に切り替えるのではなく、リージョン単位またはワークロード単位で段階的に進めると安全です。
よくある失敗と回避策
Ubuntu 26.04と.NET on Linuxの更新では、次のようなミスが起きやすくなります。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| .NET 10を入れたのに古いSDKでビルドされる | global.jsonでSDKが固定されている | global.jsonとCIログを確認する |
resoluteに変えたら本番だけ挙動が違う | ホストOSやカーネルが開発環境と違う | コンテナ内OSとホスト情報を両方記録する |
| .NET 8／9を長期運用できると思い込む | Ubuntu LTSと.NETサポート期限を混同 | .NETのEOL日を運用台帳に入れる |
| aptの依存関係が壊れる | 複数フィードを混在 | インストール元を統一する |
| 監視値が取れなくなる | cgroup v1前提のエージェント | cgroup v2対応版へ更新する |
| Native AOTで実行時エラー | 反射・動的生成・トリミング非対応 | 小さいサービスから段階検証する |
移行時は「アプリが起動した」だけで完了にしないことが大切です。メモリ制限、TLS通信、ログ出力、APM、Graceful shutdown、スケールアウト時の挙動まで確認して初めて、本番移行の判断材料になります。
まず何をすべきか
.NET on LinuxをUbuntuで使っているチームは、最初に次の3点を確認してください。
dotnet --info
apt-cache policy 'dotnet*' 'aspnetcore*'
docker image ls | grep dotnetそのうえで、次の判断を行います。
| 状況 | 次のアクション |
|---|---|
| 新規開発を始める | Ubuntu 26.04 + .NET 10を標準にする |
| .NET 8で運用中 | Ubuntu 26.04検証後、.NET 10移行計画を作る |
| .NET 9で運用中 | サポート期限を前提に.NET 10移行を優先する |
Dockerfileでnoble固定 | resoluteタグでビルド・テストする |
| 独自監視や古いエージェントがある | cgroup v2対応を確認する |
| 複数フィードを使っている | パッケージ取得元を整理する |
今回の更新は、単なる「Ubuntuの新バージョン対応」ではありません。.NET 10を中心に、パッケージ管理、コンテナ、Native AOT、cgroup v2、サポート期限をまとめて見直す機会です。まずは検証環境でUbuntu 26.04と.NET 10のビルド・実行・監視を通し、問題がなければDockerfile、CI、運用手順書、サポート台帳の順に更新していくのが現実的な進め方です。
コメント