2026年5月アップデート：.NET 11 Preview 4より.NET MAUIのデフォルト実行基盤がCoreCLRへ移行

2026年5月14日

アップデート情報

2026年5月、マイクロソフトは .NET 11 Preview 4 のリリースを発表しました。

今回のアップデートにおける最大の注目点は、.NET MAUI アプリケーションのデフォルト実行基盤が CoreCLR へと統合された ことです。

これにより、Android、iOS、および Mac Catalyst 上で動作するモバイルアプリは、ASP.NET Core や Azure サービスを支えるものと同じランタイムで動作することになります。

長年 .NET のクロスプラットフォーム展開を支えてきた Mono からの歴史的な転換点について、詳細に解説します。

目次 [ close ]

Mono が築き上げた 15 年以上の功績と歴史

今回の移行を語る上で、これまでモバイル環境の .NET を支え続けてきた Mono プロジェクトの存在を欠かすことはできません。

Mono は 2001 年に Miguel de Icaza 氏によって開始され、本来 Windows 専用であった .NET を Linux などの他プラットフォームへ持ち出すという野心的な目標から始まりました。

2009 年には MonoTouch (後の Xamarin.iOS) が登場し、2011 年には MonoDroid (後の Xamarin.Android) がリリースされました。

これらの技術は Xamarin というプラットフォームに進化し、2016 年にマイクロソフトが買収したことで、現在の .NET MAUI の基礎が形作られました。

Mono の影響範囲はマイクロソフト製品に留まらず、Unity や Godot といったゲームエンジン、さらには Avalonia UI や Uno Platform といった広大なエコシステムを構築してきました。

今回の CoreCLR への移行は Mono の終わりを意味するものではなく、Mono が証明した「.NET はどこでも動く」というビジョンを次の章へ進めるもの です。

.NET 11 Preview 4 における具体的な変更点

.NET 11 Preview 4 以降、.NET MAUI プロジェクトをビルドすると、デフォルトで CoreCLR がランタイムとして選択されます。

この変更は、Android、iOS、Mac Catalyst、および tvOS のすべてのリリースビルドおよびデバッグビルドに適用されます。

これまで Windows や Linux 上で動作するデスクトップ・サーバー向けアプリが CoreCLR を使用していたのに対し、モバイル環境だけが Mono という別個の基盤で動作していた「ランタイムの分裂」が解消されます。

ただし、現時点ですべての環境が移行するわけではなく、一部の例外も存在します。

移行の対象となるプラットフォーム一覧

今回のアップデートで CoreCLR がデフォルトとなる対象と、引き続き Mono が維持される対象を以下の表にまとめました。

プラットフォーム	新しいデフォルトランタイム	備考
Android	CoreCLR	x86 アーキテクチャは非サポートへ
iOS / tvOS	CoreCLR	Apple の制限により AOT コンパイルを継続
Mac Catalyst	CoreCLR	デスクトップ版 CoreCLR との親和性が向上
Blazor WebAssembly	Mono	.NET 11 でも変更の予定なし

なぜ CoreCLR への移行が必要なのか

マイクロソフトが多大なリソースを投じてランタイムを統合する背景には、主に 3 つの強力な理由があります。

1. ランタイムの統一による開発体験の向上

これまで .NET 開発者は、バックエンドの Azure 関数とモバイルアプリで異なる JIT 特性や GC (ガベージコレクション) の挙動に直面することがありました。

ランタイムが統一されることで、バグの発生傾向が共通化され、診断ツールやプロファイリング手法をすべてのプラットフォームで一貫して利用できるようになります。

2. 最新のパフォーマンス基盤の導入

CoreCLR は、階層型 JIT コンパイル (Tiered Compilation) や Profile-Guided Optimization (PGO) といった高度な最適化技術を備えています。

.NET 11 では、これらのインフラストラクチャをモバイル向けに最適化し、アプリのコードを変更することなく起動速度の向上を実現しています。

3. NativeAOT への道のり

CoreCLR は、バイナリを完全にネイティブ化する NativeAOT コンパイルの基盤でもあります。

Android において NativeAOT を実現するための道筋が、今回の CoreCLR デフォルト化によって明確になりました。

iOS や Mac Catalyst においても、既存の AOT ツールチェーンを CoreCLR 基盤へ統合することで、より効率的なビルドプロセスが期待されています。

開発者が直面する可能性のある課題と対策

基盤の変更はメリットばかりではありません。

特に大規模で複雑なアプリケーションにおいて、いくつかの懸念事項が報告されています。

コミュニティからの報告によると、一部の Android アプリケーションでは起動時間の増加やパッケージサイズの肥大化といったリグレッション (性能改悪) が確認されています。

開発者は自身のアプリにおいて、.NET 10 ベースと比較したパフォーマンス測定を必ず行う必要があります。

具体的には、物理デバイスを用いたコールドスタートの計測や、AAB (Android App Bundle) / IPA ファイルのサイズ比較が推奨されます。

問題が発生した場合に Mono ランタイムへ戻す方法

もし移行によって解決できない互換性の問題や、許容できないパフォーマンスの低下が発生した場合は、一時的に Mono ランタイムへ戻すことが可能です。

プロジェクトファイル (.csproj) に以下のプロパティを追加することで、従来の動作を維持できます。

XML

<!-- .NET 11 で一時的に Mono ランタイムを強制する設定 -->
<PropertyGroup>
  <UseMonoRuntime>true</UseMonoRuntime>
</PropertyGroup>

この設定は、Android、iOS、および Mac Catalyst のすべてで有効です。

ただし、このオプトアウト設定は将来的に廃止される可能性があるため、問題が発生した場合は速やかに GitHub のリポジトリへ報告することが求められます。

モバイルでも利用可能になった強力な診断ツール

CoreCLR への移行による実用的な利点の一つに、高度な診断ツールのサポートが挙げられます。

これまでサーバーサイドやデスクトップ開発で重宝されていた dotnet-trace や dotnet-counters が、Android デバイスや iOS ワークフローでも利用可能になりました。

これにより、メモリリークの特定や CPU 使用率の詳細な分析が、モバイルアプリ開発においても容易になります。

Shell

# モバイルデバイス上のプロセスをトレースする例（概念）
dotnet-trace collect --name Com.YourCompany.YourApp

実行結果

Provider Name                           Keywords            Level               TagName
Microsoft-DotNETCore-SampleProfiler     0x0000F00000000000  Informational(4)    ThreadID
Microsoft-Windows-DotNETRuntime         0x0000001100000100  Informational(4)    GC
...