.NET Native AOT and Node.js interopを今からどう標準化するか。結論から言うと、2026年4月20日にMicrosoftが公開した事例は「Node.jsと.NETを全部同じプロセスに寄せよう」という話ではありません。実際には、C++/node-gypで持っていた狭いネイティブ境界を、Node-APIと.NET Native AOTで置き換え、開発体験と運用コストを下げる現実的なパターンを示したものです。大きい業務ロジックは引き続きプロセス分離を基本にし、OS依存機能や短いホットパスだけをNative AOT addon化するのが、2026年時点ではいちばん堅い判断です。 (Microsoft for Developers)
理由は明快です。.NET 10はLTSで3年サポートされ、AOT互換性の分析や依存関係検証が進みました。一方で、Native AOTには動的ロードやReflection.Emitが使えないなどの制約が残り、.NET 11 Preview 3でも改善は進むものの、Unix出力名の変更や最低ハードウェア要件の更新といった運用面の注意点が増えています。この記事では、4月20日のMicrosoft発表を起点に、今後12〜24か月のロードマップの読み方と、実際にどう運用方針を決めるべきかを整理します。 (Microsoft Learn)
2026年4月20日のMicrosoft発表は何を意味するのか
Microsoftが示したのは、VS Code向けC# Dev Kitの実例として、TypeScript/Node.jsフロントエンドから使うネイティブアドオンをC++からC# + Native AOTに置き換えたケースです。もともとはWindows Registryの読み取りなどでC++アドオンを使い、インストール時にnode-gypでビルドしていましたが、チームにとっては特定の古いPythonや追加ツールの維持が負担でした。そこで、すでに前提として持っている.NET SDKを使う方向へ寄せています。 (Microsoft for Developers)
技術的な肝は、Node.js側の安定したC境界であるNode-APIを使うことです。Microsoftのサンプルは、C#の[UnmanagedCallersOnly]でnapi_register_module_v1を公開し、[LibraryImport]とNativeLibrary.SetDllImportResolverでホストのNodeプロセスが持つN-API関数を解決し、dotnet publishでOSごとの共有ライブラリを作って.nodeとして読み込ませています。Node-APIはNode.jsバージョン間でABI安定性を持ち、ほかの言語からのバインディングも可能ですが、V8やlibuv、NodeのC++ APIにはその安定性がありません。 (Microsoft for Developers)
重要なのは、Microsoftが強調した価値が「劇的なベンチマーク勝利」ではなく、開発者体験と運用の単純化だった点です。彼らは、リポジトリ参加者が特定Pythonを用意しなくてよくなり、CIも簡素化され、少なくとも自分たちの文字列マーシャリングとレジストリアクセスの範囲ではC++実装と実用上同等の性能だったと説明しています。さらに、現在はパイプ越しの別プロセスで動かしている一部の.NETワークロードを、将来的にはNode.jsプロセス内に寄せられるかもしれない、という見通しまで示しました。 (Microsoft for Developers)
ただし、ここを過大評価してはいけません。ブログの例は「狭い境界」のRegistry addonであり、[UnmanagedCallersOnly]のメソッドで未処理例外が出るとホストプロセスごと落ちると明記されています。つまり、この方式は“何でもin-processにする銀の弾丸”ではなく、“落としてはいけない境界を小さく保てるチーム向けの実務パターン”として読むのが正しいです。 (Microsoft for Developers)
ロードマップとして読むと、何が固まりつつあるのか
第一に、Native AOTはもはや「自己完結型の高速な実行ファイルを作る仕組み」だけではありません。公式ドキュメントは、.NETクラスライブラリをNative AOTで公開し、非.NET言語から消費されるネイティブ共有ライブラリを作るシナリオを正式に説明しています。これは、MicrosoftがNative AOTを“配布方式”ではなく“埋め込み可能な実行基盤”として扱い始めていることを示します。 (Microsoft Learn)
第二に、安定境界として固まりつつあるのはV8直結ではなくNode-APIです。Node.js公式は、Node-APIだけがNode.jsメジャーバージョンをまたぐABI安定性を提供し、ほかの言語でもアドオンを書けると説明しています。逆に、V8、libuv、NodeのC++ APIはABI安定を保証しません。今後の中期計画で“Nodeバージョン更新時の再ビルド負債”を減らしたいなら、Node-APIだけに閉じる方針はかなり筋が良いです。 (Node.js)
第三に、運用ガバナンスの道具が.NET 10でかなり揃ってきました。PublishAotをプロジェクトファイルに置くと、公開時だけでなくビルドや編集時にも動的コード使用の分析が有効になり、IsAotCompatibleはTrim/AOT系アナライザーの既定値もまとめて有効にします。さらに.NET 10ではIsAotCompatibleメタデータ自体が導入され、VerifyReferenceAotCompatibilityで依存アセンブリ側の明示的なAOT対応表明まで検査できます。AOT適合性を“気合い”ではなくCIルールに落とし込みやすくなった、ということです。 (Microsoft Learn)
第四に、改善は続いていますが、プラットフォーム依存は消えません。Native AOTはRIDごとの配布が前提で、クロスOSコンパイルはサポートされず、Linuxバイナリは一般に同一またはそれ以降のディストリビューションでしか動きません。デバッグ用シンボルもWindowsは.pdb、Linuxは.dbg、macOSは.dSYMとして別管理が必要です。Native AOTを採るなら、コードより先にビルド基盤とアーティファクト管理を設計すべきです。 (Microsoft Learn)
そして、今見るべき次の波は.NET 11 Preview 3です。NativeAOT/ReadyToRun向けのRuntime Async対応でライブスタックトレースとデバッグ体験が改善し始めた一方、Unixではネイティブライブラリ出力にlibプレフィックスが既定で付き、x86/x64やWindows Arm64の最低ハードウェア要件も引き上げられました。今すぐ本番標準にする話ではありませんが、2026年後半以降のアップグレード計画には必ず入れておきたい監視項目です。 (Microsoft Learn)
加えて、Native AOTは公開時にすべての実行コードを生成するため、JIT禁止環境やコード署名を重視する環境とも相性が良く、不要な反射面も狭まります。企業内の制限環境では、性能よりもこの統制面が採用理由になるケースもあります。 (Microsoft Learn)
2026年時点での現実的な選択肢
実務での選び分けは次の3つです。下の表は公式資料を踏まえた判断整理で、行ごとの“位置づけ”は仕様ではなく運用上の私見です。 (Microsoft for Developers)
| 選択肢 | 向いているケース | メリット | いまの位置づけ |
|---|---|---|---|
| 薄い custom addon（Node-API + Native AOT） | OS依存API、短いホットパス、既存C++ addon置換 | 安定境界、依存が少ない、配布しやすい | 本命 |
| node-api-dotnet | 型定義生成、クラス公開、JS↔.NET双方向呼び出し | 開発生産性が高い、機能が豊富 | 限定採用 |
| 別プロセスの .NET worker / service | 重い業務ロジック、依存が多い、隔離重視 | 障害分離、Native AOT制約を回避 | 既定路線 |
いちばん堅いのは、Microsoftが実際に採ったのと同じく、Node-APIに閉じた薄いcustom addonです。Node-APIというABI安定境界に閉じ、必要なN-API関数だけを薄く宣言して使う構成なら、余計な依存を増やさず、Nodeバージョン追随コストも抑えやすいからです。既存C++ addonの置き換え、インストール時ビルドの簡素化、短いin-process呼び出しには最も相性がいいです。 (Microsoft for Developers)
node-api-dotnetは、よりリッチな相互運用が欲しいときに魅力があります。公式情報では、同一プロセス内でのJS↔.NET呼び出し、自動マーシャリング、TypeScript定義生成、Native AOT対応が打ち出されています。また、Node moduleをビルドする経路ではコンパイル時コード生成を使うため、AOTと両立しやすい設計です。とはいえ、GitHubリポジトリ自身は状態をPublic Previewとしており、現行ドキュメントの要件はNode.js 18+、OSサポートはWindows/macOSのx64/arm64とLinux x64で、Linux arm64はまだ“coming soon”です。PoCや製品限定導入には魅力がありますが、全社標準の初手にするには少し早い、というのが2026年4月時点の現実です。 (Microsoft GitHub)
一方で、“.NETで書きたい”と“in-processに入れるべき”は別問題です。Microsoft自身が、いま substantial な.NETワークロードは別プロセスで動かしていると書いており、in-process化は長期的な探索と位置づけています。障害分離、独立リリース、ホットスワップ、動的ロード、Reflection依存のライブラリ活用が重要な領域では、別プロセスのまま残す方が運用負荷は小さいことが多いです。 (Microsoft for Developers)
今後の運用方針はこう決めるとブレにくい
本番標準は .NET 10 LTS、.NET 11は検証枠
本番の基準線は.NET 10で十分です。LTSで3年サポートされ、AOT互換メタデータや依存関係検証が使えます。.NET 11 Preview 3は、NativeAOTのデバッグ/非同期体験を前進させていますが、現時点ではあくまで評価対象です。プロダクト標準を動かすより、CIの影響確認と命名・ハードウェア要件の差分洗い出しに使うのが無難です。 (Microsoft Learn)
Addonの境界は「小さく、狭く、落ちても説明できる」範囲に限定する
Addonの公開APIは、小さく、同期的で、説明責任を持てる範囲に限定します。Microsoftの実例も、文字列を受けて文字列を返す狭いRegistry操作でした。.NETのネイティブ相互運用ガイドも、[LibraryImport]、正確なシグネチャ一致、関数ポインタ、UnmanagedCallersOnlyの利用を推奨しています。境界が広くなるほど、マーシャリング、ライフタイム、クラッシュ時の責任分界が難しくなります。 (Microsoft for Developers)
特に次は境界の外に出した方が安全です。
- 動的ロードやプラグイン発見に依存する処理
- 反射やランタイムコード生成を前提にした処理
- 汎用的すぎるオブジェクトグラフや巨大な双方向コールバック
- 失敗時にNodeホストごと巻き込みたくない重要処理
これらは、Native AOTが動的ロードやランタイムコード生成を許さず、例外逸脱がホストを落としうるからです。とくに、既存のmanaged assemblyをあとから読み込んで拡張するモデルは相性が良くありません。node-api-dotnetのAOTドキュメントも、Native AOTコードはruntimeを載せないためmanaged .NET assembliesを呼び出せないと説明しています。 (Microsoft Learn)
配布はRID単位で設計する
配布はRID単位で設計します。Windows/macOS/Linuxごとに成果物を分け、Linuxは“最古で保証したいディストリビューション”相当のビルド環境やコンテナで作るのが基本です。Native AOTはクロスOSコンパイルができず、Linux成果物も同一または新しい環境での実行が前提だからです。 (Microsoft Learn)
npm公開時は、ネイティブアドオンをrequire系の経路で出し、ESM中心のパッケージではmodule.createRequire()を使う薄いJSラッパーを用意しておくと事故が減ります。Node.js公式は、native addonsはrequire()で読み込め、ES moduleのimportでは現在サポートされないと説明しています。さらに、exportsのnode-addons条件はネイティブ版の分岐に使え、--no-addonsで無効化されうるため、任意機能ならdefault側にJS/WASMなどのフォールバックを残す設計が安全です。 (Node.js)
ランタイム不要の代わりに、成果物サイズも見ておく必要があります。node-api-dotnetのドキュメントはAOTバイナリがプラットフォームごとに少なくとも4〜10MBと説明し、Native AOT公式ドキュメントも必要なruntime librariesが同梱される分、framework-dependentより大きくなると述べています。インストール時の依存解消と引き換えに、npmパッケージや拡張機能のアーティファクトは数MB単位で増える前提で見積もるべきです。 (Microsoft GitHub)
依存関係はCIでAOT互換を監視する
依存関係のルールは早めに固定します。PublishAotはプロジェクトファイルに常設し、内製ライブラリにはIsAotCompatibleを付け、重要プロダクトではVerifyReferenceAotCompatibilityをCIで有効化する。これで“本体はAOT前提なのに、依存が静かにJIT/Reflection前提へ戻る”事故を減らせます。ただし、Microsoft自身が明記している通り、まだすべてのライブラリがAOT互換メタデータを持つわけではないので、警告は段階的に厳格化するのが現実的です。 (Microsoft Learn)
障害対応は「アンロード不可」を前提にする
障害対応はアンロード不可を前提に設計します。公式ドキュメントでは、Native AOTライブラリはdlcloseやFreeLibrary経由のアンロードをサポートしていません。加えて、未処理例外はNodeホストを落としえます。実運用では“アドオンだけ差し替える”より、“Nodeプロセスを安全に再起動する”を回復戦略の基準にし、.pdb/.dbg/.dSYMを成果物保管庫に必ず残す方が事故後の解析が速いです。 (Microsoft Learn)
セキュリティや統制の観点では追い風もある
セキュリティや統制の観点では、Native AOTには追い風もあります。実行コードは公開時に生成され、実行時の新しいコード生成は不要で、反射可能な面も制限されます。JITが許されない環境や、実行コードの署名・固定化を好む環境ではプラスに働きます。ただし、in-process化そのものはNodeホストとの障害連鎖を強めるので、セキュリティ上の利点だけで境界を詰めすぎない方がいいです。 (Microsoft Learn)
失敗しやすいポイント
.NET 11でUnixの出力名が変わる
今はWindowsだけ見ていても、将来のmacOS/Linux対応でビルドスクリプトが壊れます。.NET 11ではUnixのネイティブライブラリ出力にlibプレフィックスが既定で付きます。最終的に.nodeへコピー/改名するスクリプトを持つなら、いまのうちにファイル名をハードコードしないよう見直すべきです。必要ならUseNativeLibPrefix=falseでオプトアウトできます。 (Microsoft Learn)
Linuxは「どこでビルドしたか」で動作範囲が変わる
Linuxは“どこでも同じバイナリが動く”と思いがちですが、Native AOTではそうなりません。Ubuntu 20.04で作ったバイナリが18.04で動かない、という例を公式ドキュメントがそのまま挙げています。配布責任を持つなら、サポート最下限のコンテナでビルドする方針を先に決めておくべきです。 (Microsoft Learn)
ESMから直接ロードしようとして詰まる
パッケージをESM化した途端にネイティブロードで詰まるのも定番です。Node.js公式は、addonsはES moduleのimportでは現在サポートされず、module.createRequire()かprocess.dlopenを使うよう案内しています。フロントをESMに寄せる計画があるなら、最初から読み込みラッパーを分離しておくのが安全です。 (Node.js)
「不具合が出たらアドオンだけ再読込すればよい」は通らない
もうひとつ多い誤算が、“不具合が出てもアドオンだけ再読込すればよい”という発想です。Native AOTライブラリはアンロード非対応で、未処理例外はホストプロセスを落としうるため、実運用の回復戦略はホットスワップではなくプロセス再起動側に寄ります。VS Code拡張やCLI統合でも、この前提を早めに共有しておくと設計がぶれません。 (Microsoft Learn)
まず決めるべき3つのアクション
- 現状棚卸しをする。C++/node-gyp addon、別プロセスの.NET helper、OS依存API呼び出しを一覧化し、境界の広さと障害影響を見える化する。
- 1件だけPilotを作る。レジストリ、キーチェーン、証明書ストア、圧縮、暗号のような“狭くて測りやすい”機能を選び、Native AOT addon化する。
- 標準を明文化する。.NET 10 LTSを本番基準にし、npmの読み込み規約、シンボル保管、AOT互換CI、フォールバックの有無をチーム標準にする。
この順番なら、Microsoftが示した“狭い境界から始める”流れと、Native AOTの制約に無理なく沿えます。 (Microsoft for Developers)
4月20日のMicrosoft発表をロードマップとして読むなら、メッセージはひとつです。.NET Native AOT and Node.js interopは、いきなり全面移行する領域ではなく、Node-APIで安定化できる狭い境界から段階的に中へ寄せる領域です。C++ addonの置き換え、Nodeバージョン追随コストの削減、CI/開発体験の単純化には強い追い風があります。一方で、配布、診断、ファイル命名、ハードウェア要件、ホスト障害連鎖は引き続き運用課題です。今やるべきことは、賛否の議論ではなく、どの境界をin-process化し、どの境界をプロセス分離のまま残すかをプロダクト方針として明文化することです。 (Microsoft for Developers)
コメント