.NET JITコンパイラの仕組みを徹底解説！実行プロセスと最新の最適化技術

2026年3月1日

.NET Coreから現在の.NETへと進化を遂げる過程で、アプリケーションの実行性能は飛躍的に向上しました。

その中心的な役割を担っているのがJIT（Just-In-Time）コンパイラです。

ソースコードがコンピュータ上で動く機械語に変換されるまでの仕組みや、最新の.NETが採用している高度な最適化技術を理解することは、パフォーマンスの高いコードを書くための第一歩となります。

本記事では、初学者から中級者向けに、JITコンパイラの基礎から最新の動的PGOまでを徹底的に解説します。

目次 [ close ]

.NETコンパイルプロセスの全体像

.NETアプリケーションが実行される際、ソースコードがいきなり機械語に変換されるわけではありません。

まず「ビルド」という過程を経て中間言語に変換され、実行時に初めて特定のCPUに最適化された機械語へと変換されます。

ソースコードからMSILへの変換

C#やF#などの言語で記述されたプログラムは、まずRoslyn（.NETコンパイラプラットフォーム）によってMSIL（Microsoft Intermediate Language）と呼ばれる中間言語にコンパイルされます。

この段階では、CPU（x64やARM64など）の種類に依存しない共通の命令セットとして定義されています。

このMSILを格納したファイルが、私たちがよく目にする.dllや.exeといったアセンブリファイルです。

MSILからネイティブコードへのJITコンパイル

アプリケーションが起動し、特定のメソッドが呼び出される瞬間に、JITコンパイラが動き出します。

JITコンパイラは、実行環境のCPUアーキテクチャやOSの情報を読み取り、その場でMSILをネイティブコード（機械語）に変換します。

これにより、同じアセンブリであっても、Intelのプロセッサ上ではIntel用の命令に、Apple Silicon上ではARM用の命令に、それぞれ最適化された状態で実行されるのです。

JITコンパイラの基本メカニズム：RyuJIT

現在の.NETで採用されているJITコンパイラの名称はRyuJITです。

RyuJITは非常に高速なコンパイルと、高度な最適化を両立させています。

メソッド単位のコンパイル

JITコンパイラは、プログラム全体を一度にコンパイルするのではなく、メソッドが呼び出されたタイミングでそのメソッドだけをコンパイルします。

これを「遅延コンパイル」と呼ぶこともあります。

一度コンパイルされた内容はメモリ上のコードキャッシュに保存されるため、2回目以降の呼び出しではコンパイルの手間がなく、ネイティブコードが直接実行されます。

なぜJITが必要なのか

事前にすべてを機械語にする「AOT（Ahead-of-Time）」方式と比較して、JIT方式にはいくつかの大きなメリットがあります。

ハードウェアへの最適化：実行中のCPUが持つ最新の命令セット（AVX-512など）を判別し、そのCPUで最も速く動くコードを生成できます。
動的な情報の利用：プログラムが実際にどのように動いているかという「統計情報」を元に、後述する再最適化を行うことができます。
移植性：中間言語であるMSILを配布するため、配布先がWindowsかLinuxか、x64かARMかを問わずに動作させることが可能です。

2段階の最適化：階層型コンパイル（Tiered Compilation）

近年の.NETにおいて、起動速度と実行速度を両立させるための最重要技術が階層型コンパイル（Tiered Compilation）です。

Tier 0：クイックJITによる高速起動

アプリケーションの起動直後、すべてのメソッドをフルパワーで最適化しようとすると、コンパイル時間が長くなり起動が遅くなってしまいます。

そこで、最初はTier 0（Quick JIT）と呼ばれるモードでコンパイルを行います。

Tier 0では複雑な最適化をスキップし、とにかく早くMSILをネイティブコードに変換して実行を開始します。

Tier 1：最適化されたコードへの昇格

CLR（共通言語ランタイム）は、各メソッドが何回呼び出されたかを内部でカウントしています。

呼び出し回数が一定のしきい値を超えたメソッドは、「頻繁に使われる重要なコード（Hot Method）」であると判断されます。

この時、バックグラウンドのスレッドでJITコンパイラが再び動き出し、時間をかけてTier 1としての高度な最適化を施したネイティブコードを生成します。

生成が終わると、実行パスがTier 0からTier 1へと差し替えられ、以後は高速なコードが利用されます。

最新の最適化技術：動的PGO

.NET 7以降で本格的に導入され、.NET 8、.NET 9と進化を続けているのが動的PGO（Dynamic Profile-Guided Optimization）です。

PGOとは何か

PGOとは、プログラムの実行時のプロファイル情報（どの分岐が選ばれやすいか、どの型が頻繁に使われるかなど）を収集し、そのデータを元に最適化を行う手法です。

従来のPGOは開発時にデータを収集する「静的PGO」が主流でしたが、.NETの動的PGOはこれを実行中に自動で行う点が画期的です。

インライン化と仮想呼び出しの解消

動的PGOの代表的なメリットは、インターフェースや仮想メソッドの呼び出しを直接呼び出しに書き換えることです。

通常、インターフェース経由のメソッド呼び出しは「仮想メソッドテーブル」を参照するためオーバーヘッドが発生します。

しかし、動的PGOによって「このインターフェースには実際にはクラスAしか渡されていない」ということが判明すれば、JITコンパイラはクラスAのメソッドを直接埋め込む（インライン化する）ことができ、パフォーマンスを劇的に向上させます。

JITコンパイラの動作をコードで確認する

JITコンパイラがどのように最適化を行うかを、簡単なループ処理のコードを例に考えてみましょう。

using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;

namespace JitOptimizationDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            // Tiered Compilationを観察するため、何度も呼び出す
            for (int i = 0; i < 1000; i++)
            {
                int result = CalculateSum(10, 20);
            }
            
            Console.WriteLine("計算が完了しました。");
        }

        // JITはこのメソッドをインライン化（呼び出し元に直接展開）することを検討する
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        static int CalculateSum(int a, int b)
        {
            // 非常に単純な処理。JITは「メソッドを呼ぶコスト」を嫌い、
            // 直接 a + b をメインループに埋め込む可能性がある。
            return a + b;
        }
    }
}

実行結果と解説

上記のプログラムを実行しても、コンソールには「計算が完了しました。」と表示されるだけですが、内部では以下のようなことが起きています。

初回実行時：CalculateSumがTier 0でコンパイルされます。
ループ中：呼び出し回数が多いため、JITは「このメソッドは重要だ」と判断します。
再コンパイル：Tier 1への昇格が発生し、さらにMethodImplOptions.AggressiveInliningの指定があるため、JITはメソッド呼び出しという手順を省き、int result = 10 + 20;というコードを直接ループ内に展開します。

このような「インライン展開」は、JITコンパイラが行う最も強力な最適化の一つです。

ハードウェアの力を引き出す：SIMDとIntrinsics

JITコンパイラのもう一つの強みは、CPUが持つSIMD（Single Instruction, Multiple Data）命令を自動的に利用できる点です。

ベクトル化（Vectorization）

現代のCPUには、一度に複数のデータを処理できる巨大なレジスタ（SSE, AVX, AVX-512など）が備わっています。

最新の.NET JITコンパイラは、配列のループ処理などを検知すると、可能であれば自動的にこれらの命令を使うように書き換えます。

これを自動ベクトル化と呼びます。

例えば、1000個の数値を足し合わせる処理がある場合、1つずつ足していくのではなく、8個や16個の数値をまとめて一気に加算するネイティブコードを生成します。

これにより、処理速度が数倍から数十倍に跳ね上がることがあります。

JITとNative AOTの使い分け

近年、.NETではJITを使用せず、ビルド時にすべてのコードを機械語にするNative AOTという選択肢も強力になっています。

しかし、JITが不要になったわけではありません。

特徴	JITコンパイラ	Native AOT
起動速度	Tiered Compilationにより改善中だが、やや遅い	非常に高速（即座に起動）
ピーク性能	実行時の情報（PGO）を使えるため、理論上最高	事前最適化のみのため、限定的
メモリ使用量	JITコンパイル用にメモリを消費する	消費メモリが少ない
プラットフォーム	実行環境を選ばない（MSIL配布）	ビルドターゲットに固定される

サーバーサイドのWebアプリケーション（ASP.NET Core）など、長時間稼働し続けるシステムでは、実行時の状況に合わせて最適化を繰り返すJITコンパイラの方が最終的なスループットで有利になることが多いです。

一方で、クラウドネイティブなLambda関数やCLIツールなど、一瞬で起動してすぐに終了するプログラムにはNative AOTが向いています。

JITコンパイラの最適化を支える主要な手法

RyuJITは、前述したインライン化やPGO以外にも、数多くの最適化を組み合わせています。

定数畳み込み（Constant Folding）

コード内で int secondsInDay = 24 * 60 * 60; のような計算がある場合、JITは実行時に計算を行うのではなく、あらかじめコンパイル結果を 86400 という定数に置き換えます。

ループ展開（Loop Unrolling）

小さなループ処理において、ループの終了判定（i < 4 など）を行うコストを減らすため、ループの中身をコピーして展開し、分岐命令を減らします。

不要コードの削除（Dead Code Elimination）

「絶対に実行されない条件分岐」や「計算結果がどこにも使われていない変数」をJITが検知すると、それらをネイティブコードから完全に削除します。

これにより、実行時のバイナリサイズが削減され、キャッシュの効率も向上します。

まとめ

.NETのJITコンパイラは、単なる「翻訳機」ではなく、実行環境に合わせてプログラムを最高の状態に磨き上げる「動的な最適化エンジン」です。

MSILからネイティブコードへの変換プロセスの中で、階層型コンパイルによる起動の高速化、動的PGOによる実行パターンの学習、そしてSIMDによるハードウェア性能の極限までの引き出しを行っています。

私たちが書いた1行のC#コードは、JITコンパイラの高度な知能によって、開発者が想像する以上の効率で実行されています。

Native AOTという選択肢が増えた現在でも、JITコンパイラは.NETのパフォーマンスを支える大黒柱であり、その進化は今後も止まることはありません。

最新の.NETが提供するこの強力な恩恵を意識しながら、よりクリーンで効率的なコードを目指していきましょう。