Microsoftは、Windows 11向けのネイティブUIフレームワーク「WinUI 3」を採用したアプリケーションを、Visual Studioを使わずに約30分で構築・テスト・公開まで完了できる開発フローの公式クイックスタートを公開した。これまでWindowsの本格的なネイティブ開発といえば、数十GB規模のVisual Studioのインストールや複雑なプロジェクト設定が最初の壁になっていた。今回のワークフローでは、Visual Studio Code（VS Code）、.NET SDK 10、およびコマンドラインツール「winapp CLI」を軸に据え、無料ツール群とAI支援だけで完結する手順を提示している。
今回の整備で注目すべき点は、軽量ツールの組み合わせと並行して、AIコーディング支援が抱えていた「過去の古いコードを出力してしまう」という構造的課題に対策を講じた点だ。生成AIが古いUWP（Universal Windows Platform）のAPIを誤って提案する問題を抑えるため、専用プラグイン「winui-dev」と最新ドキュメントをリアルタイム取得するMCP（Model Context Protocol）サーバーを標準ツールチェーンに組み込んだ。Web技術を用いたElectronなどのラッパーアプリがメモリ消費の大きさから批判を受けるなか、Microsoftは開発体験の軽量化とAI連携によって、ネイティブWindowsアプリの開発参入障壁を一気に引き下げにかかっている。
なぜVS CodeとCLIだけで完結できるのか
従来のWindowsデスクトップアプリ開発、とりわけWindows App SDKやWinUI 3を用いた開発では、Visual Studioのワークロード選択やMSIXパッケージング構成、証明書の管理など、事前の環境構築に多くの手順を要した。今回提示されたワークフローでは、これらの複雑な工程をオープンソースの「winapp CLI（Microsoft.winappcli）」と「.NET SDK 10」以降の標準機能へ集約している。
開発者はターミナル上で雛形生成コマンドを実行するだけで、ナビゲーション構造を備えたWinUI 3プロジェクトを作成できる。
mkdir MyFirstApp
cd MyFirstApp
dotnet new winui-navview
dotnet runこの「dotnet run」による実行では、MSIXパッケージの完全なインストールを経由せず、開発用の「ルーズレイアウト形式」として即座にアプリが立ち上がる。これまでデバッグ開始までに生じていたビルドやインストールの待ち時間が削られ、Webフロントエンド開発に近い手軽さで動作確認を繰り返せる設計だ。
さらに、VS Code側には公式の「WinApp拡張機能（microsoft-winappcli.winapp）」が用意された。コマンドパレットから「WinApp: Run Application」や「WinApp: Create MSIX Package」を呼び出せば、ターミナルに戻ることなくパッケージIDの付与やビルドを実行できる。
配布用のパッケージ作成もCLIに統合された。管理者権限のターミナルで次のコマンドを実行すると、ローカルテスト用の自己署名テスト証明書が自動生成・インストールされ、配布用のMSIXファイルが出力される。
dotnet publish -o ./publish
winapp pack ./publish --generate-cert --install-certMicrosoft Storeへの提出も、Partner Centerアカウントがあれば「winapp store publish ./*.msix --appId 」という単一のコマンドでターミナルから送信できる。審査には通常1〜3営業日を要するものの、プロジェクト作成からストア提出口までのパイプラインがCLIで直線的につながった。
AIが古いUWPコードを出力する罠と特化エージェントの役割
開発ツールが軽量化されても、コード記述をAIに委ねる際にはWindows特有の落とし穴が存在した。LLM（大規模言語モデル）の学習データには、過去10年以上にわたって蓄積された膨大なUWPやWPFのコード、Q&Aサイトの回答が含まれている。一方、Windows App SDKを基盤とするWinUI 3は比較的新しいフレームワークだ。このため、汎用的なAIエージェントに「Windowsアプリの画面を作って」と指示すると、高確率で非推奨となった古いUWPのクラスや名前空間を出力してしまう。
Microsoftはこの問題に対処するため、GitHub Copilot CLIやClaude Code向けの特化型プラグイン「winui-dev」を提供している。
| 開発要素 | 汎用AIが誤って出力しやすいUWP記述 | winui-devが強制するWinUI 3の標準記述 |
|---|---|---|
| UI名前空間 | Windows.UI.Xaml.Controls |
Microsoft.UI.Xaml.Controls |
| スレッドディスパッチ | CoreDispatcher / RunAsync |
DispatcherQueue / TryEnqueue |
| ダイアログ表示 | MessageDialog |
ContentDialog |
| ウィンドウ管理 | ApplicationView |
AppWindow + OverlappedPresenter |
| トースト通知 | Windows.UI.Notifications |
Microsoft.Windows.AppNotifications |
このプラグインは、上記のようなAPI規則をシステムレベルのカスタム命令としてAIに強制注入する。これにより、開発者がプロンプトごとに「UWPではなくWinUI 3のAPIを使うこと」と細かく注意書きを添える必要がなくなった。
また、winui-devは単一のプロンプト集ではなく、開発工程に応じた8つの専門スキルを内包している。
- winui-setup: .NET SDK、winapp CLI、テンプレート、開発者モードなどの前提環境を検証・構成する。
- winui-dev-workflow: 雛形生成からビルド、実行、反復修正までのサイクルを誘導する。
- winui-design: Fluent Designに準拠したXAMLレイアウトを生成し、WinUI Gallery等に根拠を持つコントロールを選定する。
- winui-code-review: 生成されたコードがWinUI 3の規約に沿っているか、アンチパターンがないかを評価する。
- winui-ui-testing: Windows UI Automationを活用し、アクセシビリティツリーに基づく自動UIテストを生成する。
- winui-packaging: MSIXのパッケージング、署名、ストア提出を支援する。
- winui-wpf-migration: 既存のWPFコードをWinUI 3へ移行するためのAPIマッピングを提供する。
- winui-session-report: 作業セッションで構築した内容をまとめ、次の実装手順を提示する。
AIが自律的にコードを書き、レビューを行い、UIテストまで組み立てる枠組みを揃えることで、Windows開発の経験が浅いエンジニアでも破綻なく開発を進められるように配慮されている。
Learn MCPサーバーがもたらすリアルタイム仕様参照
モデルの事前学習だけに依存しない仕掛けとして、もう一つ重要な要素が「Microsoft Learn MCPサーバー」の標準採用だ。
MCP（Model Context Protocol）は、AIエージェントが外部のツールやデータソースを標準規格で呼び出すためのオープンプロトコルである。Microsoftは公式ドキュメントサイト「Microsoft Learn」を検索・取得できるMCPエンドポイント（https://learn.microsoft.com/api/mcp）を一般公開した。認証やAPIキーの登録は不要で、VS Code（GitHub Copilot）やClaude Codeの設定ファイルにURLを記載するだけで接続できる。
{
"servers": {
"microsoft-learn": {
"type": "http",
"url": "https://learn.microsoft.com/api/mcp"
}
}
}このサーバーが接続されている場合、AIエージェントはコード生成を行う直前にMicrosoft Learnの最新APIリファレンスを検索し、正しいシグネチャを確認してから実装を出力する。
たとえば、ファイル選択ダイアログ（FileOpenPicker）を実装する場合、古いUWPのコードではウィンドウハンドルの明示的な初期化が不要だったが、デスクトップアプリとして動作するWinUI 3ではウィンドウハンドル（HWND）を明示的に関連付けなければ例外が発生する。MCPサーバーと接続していれば、AIは公式ドキュメントから「WinRT.Interop.InitializeWithWindow.Initializeを呼ぶ必要がある」という最新の作法を取得して正確なコードを組み込む。AIが最新仕様をその場で調べる仕組みを整えたことで、APIの陳腐化やハルシネーションによるビルドエラーを抑えている。
ネイティブ回帰の現実性と残る制約
Microsoftがここまで軽量かつAI親和的な開発体験の整備を急ぐ背景には、デスクトップアプリ市場におけるWeb技術の台頭がある。SlackやDiscord、VS Code自身に至るまで、近年のデスクトップアプリの多くはChromiumとNode.jsを内包したElectronやWebView2上で動作している。Webの技術資産をそのまま転用できる利便性がある一方で、アプリごとに数十MBから数百MBのメモリを消費し、バッテリー駆動時間や起動速度を圧迫する問題は長年指摘されてきた。
対するWinUI 3は、Windows 11のネイティブコントロールとDirectXによる描画エンジンを直接活用するため、メモリ効率や応答性に優れる。しかし、これまでは「Visual Studioを立ち上げて重厚なプロジェクトを構成しなければならない」という参入障壁が、Web系エンジニアがネイティブ開発を選択する際の足かせとなっていた。今回のワークフローは、コマンドラインと軽量エディタ、そしてAIエージェントを組み合わせることで、Webフロントエンド開発と遜色ない手軽さでネイティブアプリを作れる環境を目指している。
ただし、Visual Studioが完全に不要になったわけではない。複雑なXAMLビジュアルツリーのリアルタイムインスペクションや、メモリリークの高度なプロファイリング、C++とC#が混在する高度なデバッグなどにおいては、依然としてVisual StudioのIDE環境に分がある。また、WinApp拡張機能や関連ツール群は現在プレビュー段階にあり、仕様やコマンド体系が更新される可能性も残されている。
手軽に動くネイティブアプリの骨組みをVS CodeとAIで素早く立ち上げ、必要に応じてストアに届けるという新たな開発導線が、重厚なWebラッパーアプリ一強のデスクトップ環境にどこまで風穴を開けられるかが問われている。