知識マップ: .NET Native AOTとは - JITやtrimmingとの違い

記事「.NET Native AOTとは - JITやtrimmingとの違い」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

.NET Native AOTは、実行時JITを使わずpublish時にネイティブコードへ事前コンパイルする発行方式で、起動時間とメモリ占有を改善しやすく、.NETランタイム未インストールの環境にも配りやすい。ReadyToRunがILを残しつつJITを一部前倒しする方向であるのに対し、Native AOTは実行時JIT自体を前提にしない分、trimmingがほぼ前提になり、自由なリフレクションや動的コード生成、built-in COMとは相性が悪くなる。WindowsのNative AOTにはbuilt-in COMが無く、WPFはtrimmingとの相性の悪さから、WinFormsはbuilt-in COM marshallingへの依存の重さから、いずれも.NET SDK側でtrimmingのサポートが無効化されており、最初のNative AOT候補としては慎重に扱うべきとされる。COMが必要な場合は、ComWrappersを前提に設計し直すことが有力な選択肢になる。

flowchart LR
    accTitle: .NET Native AOTの知識マップ
    accDescr: Native AOTがJITやReadyToRunとどう違い、trimmingやリフレクション・built-in COMとどのように衝突し、WPFやWinFormsがなぜ慎重な扱いになるのかを示す図
    native_aot["Native AOT"]
    jit_compilation["JIT(Just-In-Time)コンパイル"]
    readytorun["ReadyToRun"]
    trimming["trimming(トリミング)"]
    reflection_dotnet["リフレクション"]
    dynamic_code_generation["動的コード生成(Reflection.Emit等)"]
    builtin_com_interop["built-in COM interop"]
    comwrappers["ComWrappers / source-generated COM"]
    wpf["WPF"]
    windows_forms["Windows Forms"]
    source_generator["source generator"]
    system_text_json_source_gen["System.Text.Jsonのsource generation"]
    self_contained_deployment["self-contained発行"]
    single_file_deployment["single-file発行"]
    dotnet[".NET(Core以降)"]
    native_aot -.->|"両立しない"| jit_compilation
    readytorun -.->|"前提とする"| jit_compilation
    native_aot -->|"前提とする"| trimming
    native_aot -.->|"両立しない"| reflection_dotnet
    native_aot -->|"両立しない"| dynamic_code_generation
    native_aot -->|"両立しない"| builtin_com_interop
    comwrappers -->|"推奨される対応"| native_aot
    wpf -->|"両立しない"| trimming
    windows_forms -->|"前提とする"| builtin_com_interop
    wpf -->|"用いるのは非推奨"| native_aot
    windows_forms -->|"用いるのは非推奨"| native_aot
    native_aot -->|"利用する"| source_generator
    system_text_json_source_gen -->|"軽減する"| reflection_dotnet
    native_aot -->|"前提とする"| self_contained_deployment
    native_aot -.->|"利用する"| single_file_deployment
    native_aot -->|"前提とする"| dotnet

概念間の関係(全16件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• Native AOTはJIT(Just-In-Time)コンパイルと両立しません。publish時に生成されるNative AOTのネイティブバイナリは実行時JITを使わない。ただし通常のdotnet runや開発時の実行は引き続きJITのままである / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ReadyToRunはJIT(Just-In-Time)コンパイルを前提とします。ReadyToRunはILを残したままJITの仕事の一部を前倒しするが、実行時JITもまだ使う場面がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTはtrimming(トリミング)を前提とします。Native AOTはtrimmingとほぼ前提として結びついた発行モデルである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはリフレクションと両立しません。実行時に見て決める自由なリフレクションは、publish時に必要コードを確定しにくくNative AOTと相性が悪い / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTは動的コード生成(Reflection.Emit等)と両立しません。System.Reflection.Emitのような実行時コード生成はNative AOTでは使えない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはbuilt-in COM interopと両立しません。WindowsのNative AOTにはbuilt-in COMが無い / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ComWrappers / source-generated COMはNative AOTに対する本記事の推奨です。COM相互運用がどうしても必要な場合、built-in COMの代わりにComWrappers/source-generated COMを前提に設計し直すことがNative AOTでは有力な選択肢になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WPFはtrimming(トリミング)と両立しません。WPFはreflectionと実行時のコード検査への依存が強くtrimming後にほぼ動かないため、.NET SDK側でtrimmingサポートが無効化されている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Windows Formsはbuilt-in COM interopを前提とします。WinFormsはbuilt-in COM marshallingへの依存が重い / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WPFをNative AOTに用いることは推奨されません。trimmingとの相性が悪いため、WPF本体を最初のNative AOT候補にするのは慎重に見るべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Windows FormsをNative AOTに用いることは推奨されません。built-in COM marshallingへの依存が重いため、WinForms本体を最初のNative AOT候補にするのは慎重に見るべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはsource generatorを利用します。Native AOTはsource generatorと相性がよく、実行時の動的処理をビルド時へ寄せる設計と噛み合う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• System.Text.Jsonのsource generationはリフレクションを軽減します。System.Text.Jsonのsource generationは、reflectionに頼らずシリアライズコードをビルド時に生成することで、Native AOTとの相性問題を避けやすくする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはself-contained発行を前提とします。Native AOTはself-contained系の発行モデルとして考える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはsingle-file発行を利用します。single-fileの本質とは別だが、Native AOTの発行結果はsingle-fileに近い1本の実行ファイルになりやすい / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTは.NET(Core以降)を前提とします。Native AOTは.NET 8以降のSDKでサポートされる発行方式である / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

Native AOT

.NETアプリを単一のネイティブバイナリへ事前コンパイルする発行方式。非対応リストにC++/CLIが明記されている。

ReadyToRun

ILを残したまま、JITの仕事の一部をpublish時に前倒しする発行方式。実行時JITもまだ使う場面がある。

ComWrappers / source-generated COM

built-in COMを使わずにCOM相互運用を実現する、source generatorベースの仕組み。

WPF

XAMLでUIを宣言的に記述する、Windows専用のデスクトップUIフレームワーク。ベクターベースの描画とデータバインディングを特徴とする。

Windows Forms

デスクトップGUIアプリケーションを構築するための.NET/.NET FrameworkのUIフレームワーク。

System.Text.Jsonのsource generation

reflectionに頼らずJSONのシリアライズ・デシリアライズコードをビルド時に生成する仕組み。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。