Microsoftは2026年7月27日、ElectronやNode.jsからWindows Runtime（WinRT）APIを直接呼び出す動的プロジェクションを公開プレビューした。JavaScript／TypeScriptでWindowsの通知やストレージ、ローカルAIなどを使う際に、APIごとのC++／C#製ネイティブアドオンを用意する負担を減らす。型情報はビルド時に生成し、実際のAPI呼び出しは共通ランタイムが動的に処理する設計だ。ただし、Windows固有機能を使うためのパッケージIDやマニフェスト、配布時の署名まで不要になるわけではない。
C++ブリッジを外す3層構成
従来のElectronアプリで新しいWinRT APIを使おうとすると、node-addon-apiを使ったC++アドオンか、node-api-dotnetを介するC#アドオンを組む方法が中心だった。前者はnode-gyp、MSVC、Python、対応するWindows SDKを揃え、Electronの版やCPUアーキテクチャに合わせてビルドを管理する。後者でも.NET SDKとプロジェクトのビルド工程が加わり、公開するAPIごとにラッパーを保守しなければならない。
公開プレビューを構成する3パッケージのうち、開発者が直接導入するのは@microsoft/winappcliである。残る2パッケージの版はCLIが揃える。
| 構成要素 | 担う処理 | アプリに残るもの |
|---|---|---|
@microsoft/winappcli |
マニフェスト、SDKメタデータ、バインディング生成、デバッグ用IDを管理 | Windows向け設定と生成コマンド |
@microsoft/dynwinrt-codegen |
.winmdを読み、JavaScriptとTypeScript宣言を生成 |
.jsと.d.tsの型付きバインディング |
@microsoft/dynwinrt |
実行時にWinRTメソッドを呼び出す | x64／arm64向け共通ランタイム |
npx winapp init . --use-defaults --add-js-bindingsを実行すると、CLIはPackage.appxmanifestやSDK設定を作り、生成物を.winapp/bindings/へ置く。アプリ側は#winapp/bindingsから必要なクラスを読み込める。つまり、なくなるのはアプリごとにネイティブの橋を書いて更新する工程であり、Windows SDKそのものではない。
型は生成時、呼び出しは実行時
WinRTのAPI定義はWindows Metadata（.winmd）に収められている。dynwinrt-codegenはこのメタデータから純粋なJavaScriptラッパーと.d.tsを生成するため、エディターの補完を保ちながら、APIクラスごとのネイティブコード生成を避けられる。Windows App SDKの版を上げたときも、対応するメタデータからバインディングを作り直すのが基本になる。
呼び出し時には、Rustで実装されたdynwinrtのネイティブランタイムがlibffiを介してCOMの仮想関数テーブルへ処理を渡す。WinRTのHSTRINGはJavaScriptの文字列へ、HRESULTの失敗は例外へ変換される。非同期処理はawaitでき、キャンセルや進捗通知にも対応する。コレクションと構造体に加え、列挙型やデリゲートも投影対象に含まれる。
この分割には、Windows App SDKの更新ごとにアプリ固有のネイティブ投影を作り直す組み合わせ問題を小さくする狙いがある。一方、実行時にはFFIと動的ディスパッチを通る。設計文書はその負荷が言語境界をまたぐ既存のマーシャリングに近いと見込むが、静的なC++／C#／Rust投影との一般的な性能差を保証してはいない。公開プレビューで確かめるべき項目の一つである。
通知とローカルAIを同じJavaScriptから
Microsoftが公開した2つのElectron例は、Windows App SDKのリッチ通知とPhi Silicaによるオンデバイス要約だ。通知では進捗バー、操作ボタン、入力欄など、Electron標準の基本通知より広いWindows機能をAppNotificationBuilderから扱う。サンプルは進捗値0.65を65％として表示している。
Phi Silicaの例では、LanguageModelとTextSummarizerを読み込み、生成途中の文字列を進捗コールバックで受け取る。MicrosoftのElectron on Windows Galleryには、テキスト生成、要約、書き換え、表への変換に加え、画像説明やOCRなど合計9種類のAI機能が並ぶ。ギャラリー自体も公開プレビューであり、Microsoft Storeではまだ配布されていない。
ただし、発表ブログのPhi SilicaサンプルはCopilot+ PCを実行条件とし、マニフェストへ制限付き機能systemAIModelsを追加する必要がある。Phi SilicaはLimited Access Featureでもある。さらにMicrosoft Learnは、2026年9月にAion Instructのテスト用パッケージを提供し、10月にWindows Insider、11月に一般向け端末へ展開してPhi Silicaを削除する計画を示している。
この移行予定は、動的プロジェクションの役割も明確にする。メタデータからAPIの型を作り直す作業は軽くできても、利用モデルの変更や対応機器、アクセス条件をアプリ側で検証する仕事は残る。Phi Silicaは新経路の能力を示す例であり、固定された長期基盤ではない。
パッケージIDとUIは残る境界
通知やWindows AIを含む多くのAPIは、アプリがWindowsのパッケージIDを持つことを要求する。開発中はnpx winapp node add-electron-debug-identityでElectron実行ファイルに一時的なIDを与えられるが、マニフェストの機能やID情報、実行ファイルの場所を変えたら登録し直す必要がある。通常のNode.jsプロセスでも、winapp runで一時パッケージを登録し、実行エイリアス経由で起動して終了時に解除できる。
本番配布では、どのパッケージ方式を採るか、マニフェストへ何を宣言するか、署名と更新をどう行うかを別に決める。WinApp CLIはMSIXの作成や署名まで扱うものの、プロジェクションを追加しただけでWindowsアプリの配布工程が完了するわけではない。サードパーティー製WinRTコンポーネントも.winmdからラッパーを生成できるが、実体のバイナリ配置とアクティベーション設定は開発者の責任である。
UIの扱いにも同じ境界がある。CLIは既定でデータ指向のWindows App SDK APIを生成し、Microsoft.WindowsAppSDK.WinUIやWebView2のようなUI専用パッケージを外す。WebView2は生成対象外だ。一方、dynwinrtのリポジトリは、WinUIのApplicationとWindowを明示的に選べば、JavaScriptからホストする手順も示している。その場合は呼び出し側がSTAのUIスレッド、パッケージID、ライフサイクルを管理する。UIを一律に呼べないのではなく、既定の簡便な経路が通知やAI、ストレージなどに絞られている。
Windows専用機能をどこまで保守できるか
クロスプラットフォームのElectronアプリにとって、今回の公開プレビューはWindows向けコードを消すものではない。macOSやLinuxでは同じWinRT APIを呼べないため、インストール処理と機能分岐はWindows用に分ける。それでも、プラットフォーム固有層をJavaScript／TypeScriptのプロジェクト内に保ち、SDK更新のたびにネイティブアドオンを組み直す範囲を狭められる意味は大きい。
成否を決めるのは、未対応の型やAPIが実際のElectronアプリでどれだけ出るか、動的呼び出しの負荷が用途ごとに許容できるか、パッケージIDと配布の手順をチームが安定して自動化できるかである。Microsoftも型の不整合や不足シナリオをGitHubで報告するよう求めている。一般提供へ進むまでに、Windows App SDKの更新をまたいだ互換性と、Phi Silicaを使うサンプルがAion Instructへの移行後にどう更新されるかが、実運用の判断材料になる。