.NET MAUIのモバイル向けランタイムが、長年使われてきたMonoからCoreCLRへと移り始めています。.NET 11ではAndroidのReleaseビルドがCoreCLRをデフォルトに採用し、サーバーやデスクトップと同じランタイムへの統一が一歩進みました。これはC#で開発するエンジニアにとって、実行基盤そのものが変わる節目といえます。
さらにUnityも2026年中にCoreCLRへ向かう計画を公表しており、.NETエコシステム全体がひとつのランタイムへ収束していく流れが見えてきました。本記事ではこの移行の背景と現在地、CoreCLRが備える技術的な強み、そしてMonoプロジェクトの今を、MicrosoftやUnityの一次情報をもとに正確に整理します。
なぜ今.NET MAUIがCoreCLRへ向かうのか
Monoはもともと、商用クロスプラットフォーム.NETランタイムとして発展してきました。MicrosoftがXamarinを2016年に買収したことでMonoは同社の傘下に入り、以後はAndroid、iOS、Mac Catalystといったモバイル系プラットフォームの実行基盤を支える役割を担ってきました。MAUIへ至るクロスプラットフォーム開発の歴史は、このMonoの上に積み上げられてきたといってよいでしょう。
一方で、サーバー、デスクトップ、クラウド向けの.NETは別のランタイムであるCoreCLRの上で動いてきました。WindowsのMAUIアプリも以前からCoreCLRです。つまり同じC#で書いていても、バックエンドやデスクトップはCoreCLR、モバイルはMonoという分断状態が長く続いていたわけです。Microsoftの.NET公式ブログも、これまでモバイルアプリはMono上で動き、サーバーやクラウドはCoreCLR上で動いていたと振り返っています。
ランタイムが二つに分かれていると、開発と運用の両面で摩擦が生まれます。実行時の挙動や最適化の特性がランタイムごとに異なり、診断ツールも揃いません。フロントエンドのモバイルとバックエンドのサービスで土台が違うため、性能特性やトラブルシューティングのノウハウを共有しにくいという課題があったのです。CoreCLRへの移行は、この分断を解消しようとする取り組みだと位置づけられます。
.NET 11で進む移行の現在地とtimeline
移行が具体化したのは.NET 11です。Microsoftの.NET公式ブログ記事「.NET MAUI Moves to CoreCLR in .NET 11」（2026年5月13日付）によると、.NET 11 Preview 4でAndroidのReleaseビルドのデフォルトランタイムがCoreCLRになりました。これまでAndroidはMonoが既定でしたから、ビルド構成の標準が切り替わったことになります。
ただし、ここは正確に押さえる必要があります。iOSとMac Catalystについては、.NET 11の時点ではCoreCLRは実験的（experimental）なオプションという扱いです。Microsoft Learnのドキュメント「Runtimes and compilation in .NET MAUI」も、.NET 10でAndroid向けにCoreCLRが実験的に登場し、.NET 11でAndroid ReleaseのデフォルトになりiOSでは実験的オプションとして利用できる、と記述しています。したがって「.NET 11で全プラットフォームがCoreCLRに統一済み」という完了形の理解は誤りで、あくまで統一に向かう途上だと捉えるのが妥当です。
もう一点、Blazor WebAssembly（WASM）はMonoのまま据え置かれます。Microsoftも.NET 11ではWASMをMonoから変更しないと明言しています。また移行を急ぎたくない場合に備えて、プロジェクトファイルにUseMonoRuntimeを指定すればMonoへ戻せるオプトアウト手段も用意されており、安全弁を残した段階的な移行になっています。
時系列を整理すると、.NET 8でCoreCLRの動的PGOが既定で有効化され、.NET 9でiOS/Mac CatalystのNativeAOTが安定化、.NET 10でAndroid向けCoreCLRが実験的に登場し、.NET 11 Preview 4でAndroid Releaseのデフォルトに至りました。そして.NET 11のGA（一般提供）は2026年秋、具体的には2026年11月が予定されています。なお.NET 11は標準期間サポート（STS）のリリースで、サポート期間はおよそ2年です。
CoreCLRがもたらす技術的メリット
CoreCLRはもともとサーバーやクラウドの世界で磨かれてきた、.NETの共通言語ランタイムです。モバイルがMonoからCoreCLRへ移ると、まずランタイムの統一という大きな利点が得られます。モバイルアプリがASP.NET CoreやAzure、デスクトップと同じCoreCLR上で動くようになるため、フロントエンドとバックエンドのランタイム差異が解消し、dotnet-traceやdotnet-countersといった診断ツールを共通して使えるようになります。
性能面を支える仕組みもいくつかあります。Tiered JIT（階層型JITコンパイル）は、まずTier 0で素早くコンパイルして起動を妨げず、頻繁に呼ばれるホットなメソッドだけを後からTier 1で高度に最適化し直す方式です。実行を続けるほど最適化が育っていきます。さらにReadyToRun（R2R、起動時のJITを省くためのAOTの一形態）は、ネイティブコード表現をアセンブリに同梱しておくことで起動時のJITを省き、起動を速める狙いがあります。MAUIではアプリサイズの増加を抑えるため、必要なメソッドだけを対象とするpartialやcompositeのR2Rが使われます。
- 静的PGOはMIBC（Managed Intermediate Binary Code）プロファイルを使い、起動時に頻出するメソッドをpartial R2Rの対象として事前に選定するもので、モバイルでは特に重要だとされています。
- 動的PGOは実行時にJITがコードを計測し、Tier 1の再コンパイルでそのデータを使ってより良い最適化を行う仕組みで、.NET 8から既定で有効です。
- NativeAOTはアプリ全体と最小ランタイムを単一のネイティブバイナリに事前コンパイルする方式で、MSBuildではPublishAotで指定します。iOS/Mac Catalystでは安定、Androidでは実験的という状況で、CoreCLR移行はAndroidでNativeAOTへ進むより明確な道筋になるとMicrosoftは説明しています。
ここで重要なのは表現の慎重さです。Microsoftは多くのアプリで特に起動時間の改善が期待できるとしつつ、大規模で複雑なAndroidアプリでは起動時間やアプリサイズの増加といったリグレッションの報告もあると注意を促し、自分のアプリで実際に計測することを推奨しています。アプリによって差があるため、数値での断定は公式にも示されていません。
Unityも続く、CoreCLRへ収束する.NETエコシステム
CoreCLRへ向かうのはMAUIだけではありません。ゲームエンジンのUnityも、2026年中にスクリプティングランタイムをMonoからCoreCLRへ移行する計画を公式に公表しています。Unity公式のDiscussions「Path to CoreCLR, 2026: Upgrade Guide」によれば、CoreCLRがデフォルトかつ唯一の選択肢になるのはUnity 6.8で、このバージョンではMonoが利用可能なオプションから外れるとされています。
ロールアウトは段階的です。Unity 6.7前後でCoreCLRをテクニカルプレビューとして、現状のMonoやIL2CPPの選択に似た独立したスクリプティングバックエンドの選択肢で提供し、Unity 6.8でMonoを引退させる流れが示されています。ツールチェーンとBCLは.NET 10ベースで、これが公開される唯一のターゲットフレームワークになる予定です。
ここでも数値断定は避けるべきです。Unity自身は6.8のゴールを「総合的なパフォーマンス同等（holistic performance parity）」と表現しています。速くなる部分もあれば遅くなる部分もあり、トータルでおおむね同等を目指す、という慎重なトーンです。したがって「Unityが確実に高速化する」と単純に書くと一次情報と食い違ってしまいます。移行はまず土台を揃える取り組みであり、本格的な性能向上はその先に期待される、と理解するのが正確です。
Monoプロジェクトの今、WineHQへの移管
CoreCLRへの収束が進む一方で、Monoが消えてなくなるわけではありません。2024年8月、Monoプロジェクトのアップストリームのsteward（管理者）がWineHQへ引き継がれることが告知されました。Wineは元来、Windowsの.NET実行ファイルを動かすためにMonoのフォークを保守し続けてきた経緯があり、停滞気味だった歴史的なMonoの受け皿としては自然な流れといえます。
注意したいのは、ここでいうMonoの区別です。WineHQへ移管されたのは歴史的なmono/monoプロジェクトであり、Microsoft自身はdotnet/runtimeリポジトリ内にモダンなMonoランタイムのフォークを維持しています。前述のとおりBlazor WebAssemblyは引き続きこのフォーク上で動いており、現役です。「WineHQ管理の歴史的Mono」と「dotnet/runtime内のMonoフォーク」は別物だと整理しておくと、混乱を避けられます。
したがって、「Monoは完全に終了した」と言い切るのは正確ではありません。アップストリームの管理がWineHQへ移り、Microsoftのフォークは特定のワークロードで使われ続けるという形で、Monoの役割が再配置されたと捉えるのが実態に近いでしょう。CoreCLRへの統一とMonoの存続は、矛盾なく並び立っています。
開発者が今から備えられること
最後に、C#/.NETでクロスプラットフォーム開発を行うエンジニアが、今から実務的にできる準備を整理します。移行はすでにプレビューで動き始めているため、早めに自分の手元で試しておくことが何より有効です。
- プレビューでの実測を習慣にしておくとよいでしょう。.NET 11 Previewで実際に自分のアプリをビルドし、起動時間やアプリサイズを計測しておけば、GA後の本番移行で慌てずに済みます。
- リグレッションの可能性も織り込んでおきます。大規模なAndroidアプリでは起動時間やサイズが増えることもあると報告されているため、問題が出た場合はUseMonoRuntimeでMonoへ戻せる安全弁があることを把握しておくと安心です。
- トリミング耐性のあるコードを意識しておくと、将来のNativeAOTへの移行がスムーズになります。リフレクションに過度に依存しない設計を心がけることが効いてきます。
- 診断と運用の標準化を進める好機でもあります。ランタイムがCoreCLRへ統一されることを前提に、dotnet-traceなどの共通ツールを用いた計測・監視の手順を整えておくと、知見を共有しやすくなります。
.NET MAUIのCoreCLR移行は、Androidがデフォルト化し、iOSとMac Catalystは実験的という段階にあり、統一に向けて着実に進んでいる途上です。Unityも同じ方向へ歩み始めました。数値での過度な期待は禁物ですが、ランタイムが揃っていく流れは、開発体験と運用の一貫性という確かな価値をもたらします。今のうちから手を動かして備えておくとよいでしょう。
