Windows App Development CLI
（winapp）で何ができるか

はじめに：Windowsアプリ開発に「公式CLI」が来た

Windowsのデスクトップアプリ開発には、長らく独特の「儀式」がありました。複数のSDKを揃え、マニフェストXMLを手で書き、署名用の証明書を用意し、MSIXパッケージングの複雑な要件をひとつずつ乗り越える——。Visual Studioを使っていればIDEがある程度は面倒を見てくれますが、ElectronやFlutter、RustといったVisual Studioの外の世界から来た開発者にとって、この儀式は大きな参入障壁でした。

2026年1月22日、Microsoftはこの問題への回答としてWindows App Development CLI（winapp CLI）をパブリックプレビューとして発表しました[1]。SDKの管理、パッケージ化、アプリ識別（Package Identity）の付与、マニフェスト生成、証明書、ビルドツールの呼び出し——これらを単一のコマンドラインツールに集約するものです[2]。

発表からわずか半年あまりでリリースを重ね（執筆時点の最新版は2026年8月公開のv0.6.0）、現在ではWinUI 3アプリの雛形作成やAzureクラウド署名、UIオートメーションまで守備範囲が広がっています[5]。本記事では「結局、何ができるのか」を、公式ドキュメントに基づいて機能別に整理します。

winapp CLIとは何か

winapp CLIは、Microsoftが公式に開発・提供するWindowsアプリ開発用のコマンドラインツールです。Microsoft Learnでは次のように定義されています[2]。

「Windows SDKの管理、パッケージング、アプリ識別・マニフェスト・証明書の生成、あらゆるアプリフレームワークでのビルドツール利用のための、単一のコマンドラインインターフェース。クロスプラットフォーム開発とWindowsネイティブ機能のギャップを埋めるツール」（弊社訳）

重要なのはターゲット層です。発表記事では「クロスプラットフォームフレームワークと、Visual StudioやMSBuildの外で作業する開発者向け」と明言されています[1]。つまりVisual Studioの置き換えではなく、これまでWindowsネイティブの作法から距離があった開発者に、コマンドライン経由の正規ルートを用意するツールです。

インストール方法と対応フレームワーク

インストールは4通り用意されています[2]。通常はWinGet、ElectronプロジェクトならnpmでプロジェクトのdevDependenciesに入れる方法が案内されています。

# WinGet（推奨）
winget install Microsoft.winappcli --source winget

# npm（Electronプロジェクト向け）
npm install @microsoft/winappcli --save-dev

# 動作確認
winapp --help      # WinGet版
npx winapp --help  # npm版

CI/CD向けには、GitHub Actions / Azure DevOps用のセットアップアクション setup-WinAppCli が公式提供されており、ランナーへ自動インストールできます[2]。手動ダウンロード（GitHub Releases）も可能です。

対応フレームワークは公式ガイドとして次の6つが用意されています[2]。GitHubのREADMEでは.NET MAUIのガイドも追加されています[4]。

コマンド全体マップ：何ができるか一覧

公式CLIリファレンス（2026年8月19日更新版）に掲載されているコマンドをカテゴリ別に整理すると、winapp CLIの守備範囲が一望できます[3]。

以下、実務インパクトの大きい順に「できること」を見ていきます。

できること①：開発環境の構築が1コマンド（init）

最初の目玉が winapp init です。プロジェクトのルートで実行するだけで、公式リファレンスによれば次が一括で行われます[3]。

• Windows SDK / Windows App SDK パッケージのダウンロード
• C++/WinRT ヘッダ・バイナリの生成（C++系プロジェクト）
• Package.appxmanifest（アプリマニフェスト）の作成
• ビルドツールのセットアップと開発者モードの有効化
• .gitignore の更新、バージョン管理用 winapp.yaml の作成

さらに便利なのがプロジェクトの自動検出です。ディレクトリを指定せずに実行すると、カレントディレクトリ配下を探索して Tauri（tauri.conf.json）、Electron（package.json）、Flutter（pubspec.yaml）、.NET（.csproj）、Rust（Cargo.toml）、C++（CMakeLists.txt）を識別し、そのフレームワークに合ったセットアップを行います[3]。

地味に効くのがアイコン類の量産です。winapp manifest update-assets は1枚の元画像（SVG推奨）から、MSIXが要求する全アセットを自動生成します。スケール別5種、タスクバー用のtargetsize 14サイズ×2系統（通常／unplated）、マルチ解像度の app.ico まで一括です[3]。手作業なら数十枚の画像を書き出す作業が1コマンドになります。

# SVGから全アイコンアセットを生成（ベクターなので全サイズくっきり）
winapp manifest update-assets mylogo.svg

# ライトテーマ用の画像を別に指定することも可能
winapp manifest update-assets mylogo.png --light-image mylogo-light.png

できること②：パッケージ識別の付与とデバッグ実行（run）

winapp CLIを理解する鍵がパッケージ識別（Package Identity）です。Windowsの多くのモダンAPIは、アプリが識別を持っていることを前提にしています。Microsoft Learnは「識別を持つことで、通知、OS統合、オンデバイスAIといった機能へのアクセスが得られる」と説明しています[2]。

従来、この識別は「MSIXとして完全にパッケージしてインストールする」ことで得るのが基本で、開発中のデバッグの障害でした。winapp CLIはここに複数の解決策を用意しています[3]。

v0.6では winapp run がプロジェクトモードに対応し、.csproj や .sln を直接指定（または省略してカレント実行）すると、dotnet build でのビルドから登録・起動までを一気に行えるようになりました。dotnet run の感覚でパッケージアプリを回せます[3][5]。

# カレントのプロジェクトをビルドして識別付きで起動
winapp run

# ビルド出力フォルダを登録して起動（PIDが返るのでデバッガをアタッチできる）
winapp run ./bin/Debug

# クラッシュ解析つきで起動：OutputDebugStringと例外を捕捉し、
# クラッシュ時はミニダンプを自動解析してスタックトレースを表示
winapp run . --debug-output

# CI/自動化向け：起動後すぐ制御を返し、PIDをJSONで出力
winapp run ./bin/Debug --detach --json

Electron向けには、npm版限定で npx winapp node add-electron-debug-identity が用意されており、開発中の electron.exe プロセスに識別を付与して通知などのAPIをテストできます。なお公式リファレンスには、スパースパッケージ化したElectronアプリが起動時にクラッシュする既知の問題（Windows側で修正済みだが全デバイスに未展開）と、デバッグ用途での --no-sandbox による回避策が明記されています[3]。この手の「ハマりどころが公式に書いてある」点は、プレビュー段階のツールとしては誠実です。

できること③：MSIX化・署名・ストア申請（pack / sign / store）

配布まわりはwinapp CLIが最も力を入れている領域です。winapp pack は、ビルド出力フォルダを渡すだけでストア申請可能／サイドロード可能なMSIXパッケージを作ります[1][3]。

# フォルダをMSIX化（マニフェストは自動検出）
winapp pack ./dist

# 証明書の生成・インストール・署名・ランタイム同梱まで一括
winapp pack ./dist --generate-cert --install-cert --self-contained

# x64とarm64のビルドを渡すとマルチアーキテクチャの .msixbundle に
winapp pack ./publish/x64 ./publish/arm64

マニフェスト内の $targetnametoken$ プレースホルダの解決、フレームワーク依存関係の注入、Win2DのようなサードパーティWinRTコンポーネントの自動検出・登録まで、パッケージングの細かい落とし穴を自動処理します[3]。複数アーキテクチャを渡した場合はPEヘッダから各フォルダのアーキテクチャを自動判定し、整合性を検証したうえでバンドル化します。

署名：ローカル証明書からクラウド署名まで

開発用は winapp cert generate で自己署名証明書を作り、winapp sign で署名。本番配布用にはv0.6で追加された winapp az-sign が使えます。これはAzure Trusted Signingによるクラウド署名で、公式リファレンスが強調するとおり「秘密鍵（PFX）がローカルマシンに一切存在しない」運用になります[3][5]。証明書ファイルの持ち回りと漏洩リスクをなくせるのは、受託開発の納品フローでも大きな利点です。

# 開発用：自己署名証明書を生成して署名
winapp cert generate --publisher "CN=My Company" --output ./mycert.pfx
winapp sign MyApp.msix --cert ./mycert.pfx

# 本番用：Azure Trusted Signing でクラウド署名（CI向けに全指定）
winapp az-sign ./app.msix --subscription <sub-id> --resource-group <rg> --account <account> --profile <profile>

ストア申請も winapp store からMicrosoft Store Developer CLI（msstore）を呼び出せます。初回実行時に自動ダウンロードされるため、別途の導入は不要です[3]。

# Partner Centerのアプリ一覧
winapp store app list

# パッケージをストアへ申請
winapp store publish ./myapp.msix --appId <your-app-id>

つまり「ビルド成果物 → パッケージ → 署名 → ストア申請」の全行程がコマンドで完結し、そのままCI/CDパイプラインに載せられます。makeappxやsigntoolなどのSDKツールを直接触りたい場合も winapp tool signtool verify /pa MyApp.msix のように呼び出せるため、既存スクリプトからの移行も段階的に行えます[3]。

できること④：WinUI 3アプリの雛形作成とサンプル検索（new / find-ui）

v0.6.0で加わった winapp new は、Windows App SDK公式の dotnet new テンプレートからWinUI 3アプリの雛形を作ります。テンプレートパックの導入・更新もコマンド側が面倒を見るため、「正しいNuGetやワークロードを探して回る」必要がありません[5]。

# テンプレート一覧（blank / navigation view / tab view / MVVM / ライブラリ / テスト）
winapp new --list

# NavigationView構成のアプリを作成
winapp new --name MyApp --template winui-navview

# 作ったらそのままビルド・起動（マニフェストや識別は雛形に同梱済み）
winapp run

ユニークなのが winapp find-ui です。WinUI 3 GalleryとWindows Community Toolkitの実サンプルコードを、意図ベースの検索語で横断検索し、コピー&ペースト可能なXAML＋C#を返します[3][5]。

# 「タブ切り替えのレイアウト」に合うコントロールを探す
winapp find-ui "tabbed layout"

# 見つかったシナリオIDを指定して実装コードを取得
winapp find-ui --id gallery-tabview-1

「このUIどう書くんだっけ」をブラウザでドキュメントを彷徨わずターミナル内で解決できる——そして後述のとおり、この検索はAIエージェントにとっても「正しいWinUIコードの供給源」として機能します。

できること⑤：UIオートメーションと画面録画（ui）

v0.5系から入ったのが winapp ui サブコマンド群です。UI Automation（UIA）を使って、起動中のWindowsアプリを外から検査・操作できます[3]。

# 電卓を10秒間・15fpsでMP4録画
winapp ui record -a Calculator --duration-sec 10 --fps 15 -o demo.mp4

Webの世界でPlaywrightやSeleniumが担っていたE2Eテストの操作系を、Windowsデスクトップアプリに対して公式CLIで行えるようになったと考えると位置づけが分かりやすいはずです。タッチパネル業務端末のような「タッチ・ペン入力の再現が必要なテスト」に対応している点は、組込み・キオスク系の開発では特に価値があります。

AIエージェントとの組み合わせ：公式プラグイン同梱

弊社が注目しているのはここです。winapp CLIは設計の随所がAIコーディングエージェントから使われることを前提にしています。

• 主要コマンドが --json による機械可読出力に対応（run --detach --json でPID取得など。find-ui --json にはリファレンス上「agent-friendly」と明記）[3]
• ui record --frames は、MP4に加えてタイムスタンプ付き静止画フレームとインデックスファイルを出力。v0.6の発表ではエージェントによる解析用途が挙げられています[5]
• 非対話環境を自動検出し、プロンプト待ちで止まらずデフォルト値で進行[3]

そして、GitHubリポジトリのREADMEには次のように明記されています[4]。

「winappは（plugins/winapp/ に）エージェントとスキルからなる単一のプラグインを同梱している。Agent Plugins 1.0仕様に準拠し、GitHub CopilotとClaude Codeそれぞれのプラグインマーケットプレイス経由で配布される」（弊社訳）

# Claude Code に winapp 公式プラグインを導入
claude plugin marketplace add microsoft/WinAppCli
claude plugin install winappcli@winappcli

# GitHub Copilot CLI の場合
copilot plugin install microsoft/WinAppCli

これが揃うと何が起きるか。「WinUIでこういう画面のアプリを作って、パッケージして、起動して、スクリーンショットで確認して」という指示を、AIエージェントが雛形作成（new）→ 実装（find-ui で正しいサンプルを検索）→ ビルド・起動（run --detach --json）→ 画面検証（ui screenshot / ui click）まで、公式ツールだけで実行できる手順が成立します。Windowsデスクトップ開発は長年「GUIのIDEありき」でAI自動化と相性が悪い領域でしたが、その前提が変わりつつあります。

なお発表記事では、実験的機能としてNode.jsからWindows AI APIを直接呼ぶ @microsoft/winapp-windows-ai npmパッケージ（オンデバイスAIのPhi Silica連携）にも触れられています[1]。ElectronアプリからオンデバイスAIを叩く道筋も見え始めています。

導入前に知っておくべき注意点

受託開発の現場でどう効くか

Windowsの業務アプリケーションやタッチパネル端末ソフトの受託開発を手がける立場から、winapp CLIが効きそうな場面を整理します。

特に「既存アプリを捨てずに、通知やOS統合だけ足したい」という相談は実務で多く、スパースパッケージ3ステップ（init --sparse → pack → embed-identity）が公式手順として整備された意味は大きいと考えています。

よくある質問（FAQ）

Q. winapp CLIは無料で使えますか？

MITライセンスのオープンソースとしてGitHub（microsoft/WinAppCli）で公開されており、winget・npm・GitHub Releasesから無償で入手できます[4]。ただしパブリックプレビュー段階のため、仕様変更の可能性がある点は考慮してください[2]。

Q. Visual Studioは不要になりますか？

置き換えを狙うツールではありません。Microsoftは「Visual StudioやMSBuildの外で作業する開発者向け」と位置づけています[1]。ステップ実行などのデバッガやビジュアルデザイナは引き続きIDEの領分です。一方で、run --no-launch で識別だけ登録して任意のデバッガをアタッチする、といったIDE併用の使い方もリファレンスに記載されています[3]。

Q. どのフレームワークで使えますか？

公式ガイドがあるのは.NET（WPF/WinForms）、C++（CMake）、Electron、Rust、Tauri、Flutterの6つで[2]、GitHub READMEには.NET MAUIのガイドも追加されています[4]。WinUI 3は winapp new による雛形作成に対応しています[5]。

Q. 本番プロダクトの開発に使ってもよいですか？

「機能とコマンドは最終リリース前に変更される可能性がある」との公式注記[2]を踏まえ、弊社としてはバージョン固定・リリースノート追跡を前提に、まずCIの一部（パッケージング・署名）から段階導入する進め方をおすすめします。フィードバックはGitHub Issuesで受け付けられています[4]。

まとめ

テクノスフィアでは、WindowsデスクトップアプリやタッチパネルUIの受託開発、既存Windows資産のモダナイズ、AIエージェントを組み込んだ開発フローの構築をご支援しています。「古いWinFormsアプリに通知機能を足したい」「Electronアプリを社内配布したい」といったご相談もお気軽にどうぞ。

アプリ開発事業　｜ AIエージェント活用の実測記事　｜ 開発の相談をする

参考文献・出典

1. Microsoft「Announcing winapp, the Windows App Development CLI」Windows Developer Blog（2026年1月22日、発表の経緯・対象層・主要機能） — blogs.windows.com
2. Microsoft Learn「Windows App Development CLI (winapp CLI)」（定義、プレビュー注記、インストール方法、対応フレームワーク、パッケージ識別の意義） — learn.microsoft.com/…/winapp-cli/
3. Microsoft Learn「CLI Documentation and Usage」（全コマンドのリファレンス。本文中のコマンド例の出典） — learn.microsoft.com/…/winapp-cli/usage
4. GitHub「microsoft/WinAppCli」（MITライセンス、README、Agent Plugin、.NET MAUIガイド、Issue受付） — github.com/microsoft/WinAppCli
5. Microsoft「Announcing Windows App Development CLI v0.6.0」ifdef Windows blog（2026年8月、new / find-ui / run プロジェクトモード / az-sign） — devblogs.microsoft.com
6. GitHub「microsoft/WinAppCli Releases」（バージョン履歴） — github.com/microsoft/WinAppCli/releases

※本記事は2026年8月26日時点の公式ドキュメント・公式ブログ・GitHubリポジトリの記載に基づく解説であり、掲載コマンドは公式リファレンスからの引用です。winapp CLIはパブリックプレビューのため、仕様・コマンドは変更される可能性があります。本文中の図版はイメージイラストです。Microsoft、Windows、Visual Studio、AzureはMicrosoft Corporationの商標です。ClaudeおよびClaude CodeはAnthropic PBC、GitHubおよびGitHub CopilotはGitHub, Inc.の商標です。