Unity 7では、C#スクリプティングの実行基盤がMonoから.NET CoreCLRへと切り替わります。これはエンジン全体を書き換えるものではなく、マネージドランタイム層の刷新という位置づけです。本記事では、JITやGCの近代化がプレイモード起動や開発イテレーションにどう効いてくるのかを、一次情報を基に技術的に読み解きます。

数値の断定を避けつつ、Unity社が公表した事実と、一般に確立された.NETランタイムの技術知識を切り分けながら整理していきます。ランタイムという言葉は普段あまり意識されにくい領域ですが、ここが変わることで日々の開発体験や最終的な実行性能にじわじわと効いてきます。まずは発表の要点を押さえ、続いて技術的な差分と影響範囲、そして開発者が備えるべき実務観点へと進んでいきます。

Unity 7が発表したランタイム刷新の要点

Unity社は、代表的なゲームエンジンの1つである「Unity」の次世代版となる「Unity 7」を発表しました。これまでUnityは、マイクロソフトの.NET Frameworkのオープンソース実装であるMonoを実行基盤として構築されてきました。Unity 7ではそのMonoから脱却し、マイクロソフト自身がオープンソースとして開発を進めている.NETの実行基盤であるCoreCLRを採用することが発表されています。

ここで押さえておきたいのは、今回の移行がC#スクリプティングの実行基盤、すなわちマネージドランタイム層の置き換えである点です。エンジンのネイティブな部分を含めた全体の書き換えではなく、あくまでスクリプトを動かす土台が刷新されると理解するのが正確です。この区別を意識しておくと、後述する影響範囲や互換性の話題を正しく捉えやすくなります。

あわせて発表された成果として、シェーダービルドが90％高速になったこと、プレイモードがほぼ瞬時に起動するようになったこと、そしてよりリアルで豊かな照明効果を実現するリアルタイムのグローバルイルミネーションが挙げられています。リリース計画としては、2026年12月にアーリーベータテストを開始し、2027年第1四半期に正式リリースを予定しているとされています。以下に発表された主なポイントを整理します。

MonoとCoreCLRの技術的な違いを整理する

MonoとCoreCLRは、いずれもC#を動かすマネージドランタイムですが、成り立ちと現在の位置づけが異なります。CoreCLRは現行の主力ランタイムであり、継続的に性能改善が取り込まれています。一方でMonoは保守を中心に据えたランタイムであるとされ、モダンな最適化への追随という点で差が生じやすいと一般に語られています。

JITコンパイラの観点では、CoreCLRはRyuJITを採用し、起動を素早くするTier0と、ホット経路を再最適化するTier1を段階的に切り替えるTiered Compilationや、実行時プロファイルを活用するDynamic PGOといった仕組みを備えています。Monoの歴史的なJITは、こうしたモダンな最適化と比べるとコード生成品質で劣るとされてきました。GC（ガベージコレクション）についても、CoreCLRは世代別GCにConcurrent/Background GCなどの運用手段を組み合わせられ、一般に高スループットと低ポーズの両立に寄与しうるとされます。

下表は両ランタイムの特性を一般論として対比したものです。いずれもUnity固有のベンチマーク値ではなく、.NETランタイムとしての定性的な傾向を示す整理である点にご留意ください。

CoreCLRの採用により、モダンなC#の言語機能や現行の.NETライブラリエコシステムへ追随しやすくなる方向性が示されています。これまでMono世代では取り残されがちだった新しい言語機能やNuGetの資産を活用できる余地が広がることは、ライブラリ選定の自由度という点でも大きな意味を持ちます。ただし、JITやGCの一般的な利点がそのままUnity固有の性能改善率として保証されるわけではないため、具体的な数値は公式のベンチマークを待つのが妥当です。ここでは、ランタイムとしての世代交代が起きているという構図を押さえておけば十分です。

スクリプティング実行基盤の置き換えが影響する範囲

今回の移行で置き換わるのは、C#スクリプティングのJIT実行基盤です。Unityの公式ガイドでは、IL2CPPはこの変更の影響を受けないと明記されています。IL2CPPはILをC++へ変換してネイティブコンパイルするAOT経路であり、下層のC++コンパイラに依存するため、マネージドランタイムの刷新とは切り離して扱われるためです。

したがって実行経路は、プラットフォームによって棲み分けられます。デスクトップなどJITを利用できる環境ではCoreCLRのJITが担い、iOSやコンソールのようにAOTが求められるプラットフォームでは引き続きIL2CPPがデプロイを担う想定です。エンジンのネイティブなC++層は今回の主対象ではありません。次の表に影響範囲を整理します。

この棲み分けを理解しておくと、自分のターゲットプラットフォームがどの実行経路に載るのかを見極めやすくなります。JITとAOTでは同じC#コードでも最適化のかかり方や実行時の挙動が完全に一致するとは限らないため、ターゲットごとの検証は引き続き重要です。とりわけ、デスクトップで動作確認したコードをAOT必須のプラットフォームへ持ち込む際には、実行経路が切り替わることを前提に動作を確かめておくと安心です。

プレイモード起動と開発イテレーションが変わる理由

プレイモード起動が速くなる背景には、Domain Reloadの扱いの変化があります。従来はスクリプトを変更するたびにAppDomainを再構築するDomain Reloadが走り、エディタが数秒からときに10秒超ブロックされることもあったとされます。Unity 7の系譜では、このDomain Reloadを廃止し、より軽量な仕組みへ置き換えることでプレイモードがほぼ瞬時に起動する方向へ向かいます。公式ロードマップでも、Fast Enter Play Modeが新規プロジェクトでデフォルトになる段階が示されています。

ここにCoreCLRのTiered JITが加わります。起動時はTier0で素早くコード実行を開始し、実行を続けながらホット経路をTier1で再最適化するため、一般に起動レイテンシとピーク性能を両立しやすいとされます。エディタを触ってから結果を確認するまでのループが短くなることは、試行回数を増やし、開発イテレーション全体の質を押し上げます。

なお、プレイモード起動については一次情報が「ほぼ瞬時」という定性表現にとどめており、何倍高速といった定量値は公表されていません。本記事でも倍率や秒数の断定は避け、体感として起動待ちが大きく縮むという方向性の理解にとどめておくのが安全です。実際の効果はプロジェクトの規模やスクリプト構成によっても変わり得るため、自分の環境でどの程度短縮されるかは技術プレビューで確かめるのが確実です。とはいえ、待ち時間が縮むこと自体が試行錯誤の心理的なハードルを下げ、より多くのアイデアを試せる開発フローへとつながっていく点は見逃せません。

Unity開発者が移行に備えるための実務ポイント

移行は段階的に進みます。公式ガイドによれば、Unity 6.7 LTS Alphaで実験的なCoreCLR Desktop Playerがオプションとして提供され、Unity 6.8でCoreCLRが必須となりMonoの提供が終了します。Unity 6.8では.NET 10ベースのツールチェーンとBCLが唯一のターゲットフレームワークとして採用されるとされています。早い段階で技術プレビューを触り、自分のプロジェクトで検証しておくことが安全につながります。

実務面で最初に確認したいのは、破壊的変更の棚卸しです。.NET Standard 2.1以外をターゲットにしたプリコンパイル済みアセンブリはUnity 6.8で壊れ得るとされ、プラグインやネイティブ相互運用の再検証が必要になります。あわせて、削除や非推奨となるAPIへの依存も洗い出しておく必要があります。以下に主な確認観点をまとめます。

• 非.NET Standard 2.1をターゲットにしたプリコンパイル済みアセンブリは壊れ得るため、依存プラグインを事前に洗い出しておくと安心です。
• BinaryFormatterはセキュリティ上の理由から非推奨となるため、シリアライズ処理の代替手段を検討しておく必要があります。
• ManagedDebugger APIやMonoのP/Invokeライブラリ（MonoPosixHelper.dllなど）への依存があれば、早めに置き換えを計画しておきましょう。
• 静的初期化のタイミング差やバックグラウンドスレッド起因の挙動差が生じ得るため、初期化順序に依存したコードは重点的に検証すると安心です。
• Domain Reloadの廃止に伴いAssembly.Locationが空文字を返す、一部のAssembly.Loadバリアントが制限されるといった挙動変化にも注意が必要です。

これらは一度に対応しようとすると負担が大きくなります。移行期の段階提供を活かし、実験提供の時点で影響範囲を可視化し、必須化までに順を追って解消していく進め方が現実的です。ランタイム刷新の恩恵を安心して受け取るためにも、早期の検証を計画へ組み込んでおくことをおすすめします。