AIニュースまとめ ブログへ戻る
AIニュースまとめへ

WinUI4K登場：Kotlin・JavaからWindows 11のネイティブUIを直接使えるOSS

NTTレゾナントテクノロジーが公開したWinUI4Kの仕組み、Java 8対応、60超のコントロール、Electronとの違い、AIデスクトップアプリ開発での可能性と制限を整理します。

WinUI4K登場：Kotlin・JavaからWindows 11のネイティブUIを直接使えるOSSのアイキャッチ画像

NTTレゾナントテクノロジーは、Kotlin・JavaからMicrosoftの「WinUI 3」を直接利用できるオープンソースライブラリ「WinUI4K」を公開しました。C#、Visual Studio、.NET SDK、独自のブリッジDLLを用意せず、JVM系言語の資産を活かしたままWindowsネイティブの画面を構築できます。

60を超えるコントロール、Java 8以降で利用できる複数のFFIバックエンド、WebView2、Kotlinコルーチン向け拡張などを備えています。一方、Windows専用であること、XAMLではなくコードでUIを組み立てること、COMとJVMのメモリ管理をまたぐ制約もあります。

WinUI4K自体に生成AI機能はありません。ただし、Java・Kotlinで作られたローカルAIツールや業務向けAIクライアントへ、Windows 11らしいネイティブUIを与える選択肢として注目できます。

WinUI4Kとは

WinUI4Kは、Windows Runtime（WinRT）のABIをJVM側のFFIから直接呼び出し、Kotlin・JavaでWinUI 3のコントロールを扱えるようにするライブラリです。Apache License 2.0で公開され、商用・非商用を問わず利用できます。

MicrosoftはWinUI 3を、新しいWindowsデスクトップアプリ向けに推奨するネイティブUIフレームワークと位置付けています。Fluent Designに基づくコントロールやスタイルを持ち、Windows App SDKの一部として提供されています。

通常のWinUI 3開発ではC#またはC++とXAMLを使う構成が中心です。WinUI4Kは、これまでWinUIへ入りにくかったJVM系の開発者に別の入口を用意します。

C#やブリッジDLLを挟まずにWinUIを呼び出す

異なる言語からWindowsのネイティブAPIを利用する場合、独自のDLLを作り、そのDLLをJNIなどから呼び出す構成が考えられます。この方式では、JVM側だけでなくC/C++側のビルド、配布、アーキテクチャ対応、デバッグも必要です。

WinUI4Kは独自のブリッジDLLを置かず、WinRTのABIをFFI経由で直接扱います。オブジェクト生成、HSTRING、COMのvtable呼び出し、KotlinオブジェクトをCOM側へ公開するupcallなどもJVM側で実装されています。

ABI呼び出しに必要なIIDやvtable位置は、Windowsの型情報ファイルであるWinMDから機械的に抽出されています。開発者が推測した定数を手作業で並べる方式を避けている点も特徴です。

3種類のFFIバックエンド

WinUI4Kには、Javaのバージョンや対象環境に応じて選べる3種類のFFIバックエンドがあります。

バックエンド対応Java主な特徴
PanamaJava 22以降標準のForeign Function & Memory APIを利用。利用可能な場合の既定候補
JNAJava 8以降導入しやすい既存FFI。WinUI4Kではx64向け
JNRJava 8以降x86・x64・arm64向け実装を用意

リポジトリそのものをビルドしてサンプルギャラリーを動かすクイックスタートでは、JDK 25 x64が案内されています。一方、ライブラリのコアはJava 8以降で動作し、JNAまたはJNRを使う実行例も用意されています。

「JDK 25が必須のライブラリ」ではなく、「リポジトリのビルドにはJDK 25、利用側はバックエンド次第でJava 8以降」という区別が必要です。

60を超えるWinUIコントロール

公式READMEでは、ButtonやTextBoxといった基本部品から、NavigationView、TeachingTip、AppNotification、AppWindowまで、60を超えるコントロールが案内されています。

APIはWFrame、WButton、WTextFieldのようなW*クラスとして包まれ、Swingに近い感覚でコードから組み立てられます。既存のSwing・JavaFXアプリを保守してきた開発者にとって、考え方を移しやすい設計です。

サンプルとして、次のアプリが同梱されています。

  • 収録コントロールを確認できるGallery
  • タブ、パンくず、表示切り替えを備えたファイルマネージャー
  • シンプルなメモ帳
  • MigLayoutを使った入力フォーム

単純なボタン表示だけでなく、実際のデスクトップアプリに近い構成を確認できます。

WebView2とKotlinコルーチンにも対応

WWebViewを使うと、Microsoft EdgeベースのWebView2をアプリ内へ埋め込めます。画面全体をWeb技術で作るElectronとは異なり、ネイティブ画面の一部だけへWebコンテンツを置く構成も選べます。

Kotlin向けにはwinui4k-extension-coroutinesが用意され、Dispatchers.WinUiを通してUIスレッドへ切り替えられます。ネットワーク通信、ローカルLLMの推論待ち、ファイル処理など、時間のかかる処理とUI更新を分離しやすくなります。

OS標準のWinUIコントロールを使うため、スクリーンリーダーなどWindows側のアクセシビリティ機能を活用できる点も、独自描画のUIフレームワークに対する利点です。

Electronより軽いのか

WinUI4Kの公式READMEは、Electronのようにブラウザーエンジンを同梱する方式より、配布サイズやメモリ使用量を抑えたいケースを適した用途として挙げています。

ただし、「WinUI4Kなら必ずElectronより何倍も軽い」と断定できる共通ベンチマークは公開されていません。実際の差は、次の条件で変わります。

  • JVMをアプリへ同梱するか
  • jlinkなどで実行環境を小さくするか
  • WebView2を多用するか
  • 画像、モデル、ネイティブライブラリをどれだけ含めるか
  • 起動時に行う初期化やネットワーク処理
  • Electron側で使うChromium・Node.js・フレームワークの構成

ブラウザーエンジンをアプリごとに抱えない設計上の利点はありますが、製品として比較するなら、同じ機能を実装した配布物でサイズ、起動時間、アイドル時メモリ、操作時メモリを測る必要があります。

Electron・Compose Desktopとの違い

選択肢UI対応OS既存資産との相性向く場面
WinUI4KWindowsネイティブのWinUI 3WindowsJava・Kotlin資産を活用しやすいWindows専用の業務アプリ、社内ツール
ElectronHTML・CSS・JavaScriptWindows・macOS・LinuxWeb資産を活用しやすいクロスプラットフォーム、Webチーム中心
Compose Desktop独自描画のCompose UIWindows・macOS・LinuxKotlinとの相性が高いKotlinで複数OSへ展開
C# + WinUI 3WindowsネイティブのWinUI 3Windows.NET資産と最も自然に統合Microsoft標準構成を優先する製品

Windowsだけを対象にし、既存のJVMロジックを残しながらUIを刷新したい場合、WinUI4Kの位置付けは明確です。macOSやLinuxも同じコードベースで提供するなら、ElectronやCompose Desktopの方が自然です。

AIデスクトップアプリとの相性

ローカルAIアプリには、モデル管理、推論状況、会話履歴、ファイル選択、権限確認、ログ表示など、デスクトップUIが必要です。Java・Kotlin側に既存の業務ロジックや検索基盤がある場合、WinUI4Kを使えば処理層を大きく書き換えずWindows向けUIを追加できます。

想定しやすい用途には、次のようなものがあります。

  • 社内文書を検索・要約するWindowsクライアント
  • ローカルLLMや推論サーバーの管理画面
  • AIエージェントが実行する操作の承認UI
  • Java製の業務システムへ組み込むAI支援画面
  • ログ、トレース、評価結果を確認する開発者ツール

一方、WinUI4Kはモデル実行、RAG、エージェント、MCP、認証を提供するAIフレームワークではありません。UI層の選択肢であり、AI機能は別のライブラリやサービスと組み合わせる必要があります。

Windows App SDKランタイムは必要

WinUI 3の実行基盤であるWindows App SDKランタイムは必要です。現行READMEではWindows App SDK 2.2 runtimeを前提としています。WinUI4Kは起動時に必要なBootstrap DLLをJARから一時ディレクトリへ展開し、ランタイムが見つからない場合は、同梱したインストーラーの実行またはMicrosoftのダウンロード案内を試みます。

Visual Studioや.NET SDKを利用者のPCへ入れる必要はありませんが、何も追加せず単一JARだけで完結するわけではありません。公式のGradle taskで取得するruntime installerはx86・x64・arm64ごとに約104MBと案内されています。配布時には、対象アーキテクチャを絞ったうえで、JVMとWindows App SDKランタイムを同梱するか、事前導入を求めるかを決める必要があります。

公式READMEのサポート環境はWindows 11 x64で、Windows 10 version 1809以降も動作が見込まれるとされています。x86・arm64向けバックエンドも含まれますが、製品採用時には対象アーキテクチャごとの実機検証が必要です。

現時点で確認したい制限

WinUI4Kは公開直後のプロジェクトで、公式READMEにも技術的な制限が明記されています。

Windows専用

WinUI自体がWindows向けです。同じUIをmacOSやLinuxへ展開する用途には向きません。

XAMLではなくコードでUIを構築

一般的なWinUI開発で使われるXAML中心の設計とは異なり、WinUI4KではKotlin・JavaコードからUIを組み立てます。Visual StudioのデザイナーやXAML向けエコシステムをそのまま使う構成ではありません。

COM参照の解放タイミング

COMは参照カウント、JVMはGCでオブジェクトの寿命を管理します。WinUI4Kは両者を橋渡ししますが、解放のタイミングはGCと同期するため決定的ではありません。

循環参照は自動回収されない

ネイティブ側とKotlin・Java側をまたぐ循環参照は自動的に回収されません。不要になったイベントリスナーは、対応するremoveメソッドで明示的に解除する必要があります。

また、WFrameやWAppWindowなどWindow・Shell系のwrapperは自動解放の対象外で、参照を保持し続けるとREADMEに明記されています。長時間稼働するアプリでは、画面の生成と破棄を繰り返すシナリオでnative referenceの増え方を確認すべきです。

UIスレッドは1つ

W* APIは単一のUIスレッドで使う前提です。非同期処理からUIを更新する場合は、コルーチン拡張などを通してUIスレッドへ戻す必要があります。

導入判断

WinUI4Kが強く刺さるのは、Java・Kotlinで作られたWindows専用アプリを現代的な見た目へ更新したいチームです。C#への全面移行を避け、既存ロジックを活かしながらWinUI 3のネイティブコントロールとアクセシビリティを利用できます。

Electronの代替候補としても興味深いものの、クロスプラットフォーム対応とWebエコシステムを失うため、単純な上位互換ではありません。配布サイズやメモリの優位性も、JVMやWebView2を含めた実アプリで測るべきです。

AI分野では、Java・Kotlin資産を持つ企業がWindows向けAIクライアントを作る際のUI基盤として価値があります。公開直後であることとCOM連携の制約を踏まえ、まずは小規模な社内ツールや試作で、配布、メモリ、アクセシビリティ、長時間動作を検証するのが現実的です。

参照情報