# Windows App Development CLI（winapp）で何ができるか｜Windowsアプリ開発をコマンドラインで完結させるMicrosoft公式ツール解説｜株式会社テクノスフィア

> Microsoftが2026年1月に公開したWindows App Development CLI（winapp）を出典付きで解説。SDKセットアップ・パッケージ識別・MSIX化・証明書と署名・ストア申請・WinUI 3の雛形作成・UIオートメーションまで、コマンドラインで何ができるかを整理。Electron/Rust/Tauri/Flutter対応とAIエージェント連携（Claude Code/GitHub Copilotプラグイン）も紹介。

URL: https://technosphere.co.jp/blog/windows-app-development-cli

** 目次
1. はじめに：Windowsアプリ開発に「公式CLI」が来た
2. winapp CLIとは何か
3. インストール方法と対応フレームワーク
4. コマンド全体マップ：何ができるか一覧
5. できること①：開発環境の構築が1コマンド（init）
6. できること②：パッケージ識別の付与とデバッグ実行（run）
7. できること③：MSIX化・署名・ストア申請（pack / sign / store）
8. できること④：WinUI 3アプリの雛形作成とサンプル検索（new / find-ui）
9. できること⑤：UIオートメーションと画面録画（ui）
10. AIエージェントとの組み合わせ：公式プラグイン同梱
11. 導入前に知っておくべき注意点
12. 受託開発の現場でどう効くか
13. よくある質問（FAQ）
14. まとめ
15. 参考文献・出典
   ** 本記事のスコープ

本記事は**2026年8月26日時点**のMicrosoft Learn公式ドキュメント（2026年8月19日更新版）、Windows Developer Blogの発表記事、GitHubリポジトリ（microsoft/WinAppCli）に基づく解説です。掲載しているコマンドはすべて公式リファレンスからの引用で、弊社環境での実測レポートではありません。winapp CLIは**パブリックプレビュー**段階のため、機能・コマンドは今後変更される可能性があります。導入前に末尾の一次情報をご確認ください。

## はじめに：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とは何か  （図: SDK・証明書・マニフェスト・パッケージなど散らばった開発ツールが1つのコマンドラインツールに集約されるイメージイラスト） バラバラだったSDK管理・マニフェスト・証明書・パッケージングを1本のCLIに集約する（イメージ）

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

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

 重要なのはターゲット層です。発表記事では**「クロスプラットフォームフレームワークと、Visual StudioやMSBuildの外で作業する開発者向け」**と明言されています[1]。つまりVisual Studioの置き換えではなく、**これまでWindowsネイティブの作法から距離があった開発者に、コマンドライン経由の正規ルートを用意する**ツールです。
| 項目 | 内容 |
| 提供元 | Microsoft（公式ツール） |
| 発表日 | 2026年1月22日（Windows Developer Blog）[1] |
| 提供形態 | オープンソース（MITライセンス）。GitHub `microsoft/WinAppCli` で開発[4] |
| ステータス | **パブリックプレビュー**。「機能とコマンドは最終リリース前に変更される可能性がある」と明記[2] |
| 最新版 | v0.6.0（2026年8月公開。執筆時点）[6] |
| カバー範囲 | SDK管理／パッケージ識別／MSIXパッケージング／マニフェスト・証明書・署名／ストア申請／WinUI雛形／UIオートメーション |      ** なぜ今CLIなのか

発表記事は、Windows開発が「複数のSDKの管理、複数のマニフェストの作成と編集、証明書の生成、複雑なパッケージング要件」を伴うことを課題として挙げ、開発者が「設定と格闘するのではなく、良いアプリを作ることに集中できる」ことを目標に掲げています[1]。もうひとつの背景として見逃せないのがAIコーディングエージェントとの相性です。GUIのIDE操作はAIに任せにくい一方、CLIに揃った操作はエージェントがそのまま実行できます。リポジトリにはClaude CodeとGitHub Copilot向けの公式プラグインまで同梱されています[4]。

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

 インストールは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色のブロックがそれぞれのレールから1本のレールに合流してターミナル型のゲートを通過する、複数フレームワーク対応のイメージイラスト） フレームワークごとに違う道を、パッケージングと署名の段階で1本にまとめる（イメージ）

 対応フレームワークは公式ガイドとして次の6つが用意されています[2]。GitHubのREADMEでは**.NET MAUI**のガイドも追加されています[4]。
| フレームワーク | 備考 |
| .NET（WPF / WinForms） | `.csproj` を自動検出し、NuGet参照の追加まで自動化 |
| C++（CMake） | C++/WinRTヘッダの生成に対応 |
| Electron | npm版限定の専用コマンド群あり（後述） |
| Rust | `Cargo.toml` を自動検出 |
| Tauri | `tauri.conf.json` を自動検出 |
| Flutter | `pubspec.yaml` を自動検出 |

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

 公式CLIリファレンス（2026年8月19日更新版）に掲載されているコマンドをカテゴリ別に整理すると、winapp CLIの守備範囲が一望できます[3]。
| カテゴリ | コマンド | できること |
| セットアップ | `init` / `new` / `restore` / `update` | SDK導入と環境構築、WinUI 3雛形作成、依存の復元・更新 |
| 識別・デバッグ | `run` / `create-debug-identity` / `embed-identity` / `unregister` | パッケージ識別付きでのビルド・登録・起動、後片付け |
| パッケージング | `pack` | MSIX / MSIXバンドルの作成（署名まで一括） |
| マニフェスト | `manifest generate` / `manifest update-assets` / `manifest add-alias` | マニフェスト生成、1枚の画像から全アイコンアセット生成、実行エイリアス追加 |
| 証明書・署名 | `cert generate/info/install` / `sign` / `az-sign` / `create-external-catalog` | 開発用証明書の生成・確認・導入、ローカル署名、Azure Trusted Signingによるクラウド署名 |
| ユーティリティ | `tool` / `store` / `get-winapp-path` / `find-ui` / `complete` | SDKツール（signtool等）呼び出し、ストア申請CLI、WinUIサンプル検索、シェル補完 |
| UIオートメーション | `ui`（inspect / screenshot / record / click / send-keys ほか） | 起動中アプリのUI検査・操作・スクリーンショット・MP4録画 |
| Node.js / Electron | `node create-addon` / `node generate-bindings` / `node add-electron-debug-identity` ほか | ネイティブアドオン雛形、Windows API のJSバインディング生成、Electronへの識別付与（npm版限定） |

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

## できること①：開発環境の構築が1コマンド（init）  （図: ターミナルの1コマンドからプロジェクトツリーが育ち、SDKやマニフェスト、証明書が自動で組み込まれていくイメージイラスト） winapp init 一発でSDK取得からマニフェスト・証明書の生成までが揃う（イメージ）

 最初の目玉が `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]。   ** .NETプロジェクトは専用フローに切り替わる

`.csproj` が見つかった場合は.NET専用の流れになり、`TargetFramework` をWindows対応のもの（例：`net10.0-windows10.0.26100.0`）へ検証・更新し、`Microsoft.WindowsAppSDK` と `Microsoft.Windows.SDK.BuildTools` をNuGet参照として直接 `.csproj` に追加します。この場合 `winapp.yaml` は作られず、パッケージ復元は通常どおり `dotnet restore` を使います[3]。既存の.NET開発フローを壊さない設計です。

 地味に効くのがアイコン類の量産です。`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）  （図: アプリウィンドウがIDバッジを掲げ、通知ベル・パズルピース・AIチップの3機能が解錠されるパッケージ識別のイメージイラスト） パッケージ識別（Package Identity）が通知・OS統合・オンデバイスAIなどの扉を開ける（イメージ）

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

 従来、この識別は「MSIXとして完全にパッケージしてインストールする」ことで得るのが基本で、開発中のデバッグの障害でした。winapp CLIはここに複数の解決策を用意しています[3]。
| コマンド | やること | 向いている場面 |
| `winapp run` | ビルド出力フォルダを「ルースレイアウトパッケージ」としてWindowsに登録し、そのまま起動。プロセスIDを返す | **ほとんどのフレームワークでの推奨**。実際のMSIXインストールと同じ状態を再現 |
| `winapp create-debug-identity` | 実行ファイル単体に一時的な識別を付与（スパースパッケージ登録） | exeがアプリコードと別の場所にある場合（例：Electronの `node_modules` 内の `electron.exe`） |
| `winapp init --exe --sparse` → `pack` → `embed-identity` | 既存の配布済みデスクトップアプリに「識別専用MSIX」を用意する3ステップ | **既存アプリのモダナイズ**。フルMSIX化せずに識別が必要なAPIを使う |

 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
```

   ** クラッシュ解析まで面倒を見る

`--debug-output` オプションは単なるログ表示ではありません。公式リファレンスによれば、アプリがクラッシュした場合**ミニダンプを自動取得して解析し、例外の種類・メッセージ・ソースファイル行番号つきのスタックトレース**を表示します（.NETのクラッシュは外部ツールなしで即解析）。WinUI 3アプリでは、原因特定が難しいことで知られるstowed exceptionの追跡パスまで自動実行されます[3]。

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

## できること③：MSIX化・署名・ストア申請（pack / sign / store）  （図: フォルダ内のファイルがベルトコンベアで箱詰めされ、クラウド上の鍵から降りる光で封緘されるMSIXパッケージングと署名のイメージイラスト） ビルド出力の箱詰め（MSIX化）から署名までを1本のパイプラインで（イメージ）

 配布まわりは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]。
| 操作 | コマンド例 |
| UI要素ツリーの検査・検索 | `ui inspect` / `ui search` / `ui get-property` |
| 操作の実行 | `ui click` / `ui invoke` / `ui send-keys` / `ui set-value` / `ui drag` |
| タッチ・ペン入力の注入 | `ui touch`（タップ・スワイプ・ピンチ）/ `ui pen`（筆圧・傾きつきストローク） |
| 証跡の取得 | `ui screenshot`（PNG）/ `ui record`（H.264 MP4録画） |
| 待機・同期 | `ui wait-for`（要素の状態変化を待つ） |

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

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

## AIエージェントとの組み合わせ：公式プラグイン同梱  （図: 小さなロボットがターミナルを操作し、JSONの流れがアプリ画面の操作へつながっていくAIエージェント連携のイメージイラスト） 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を叩く道筋も見え始めています。

## 導入前に知っておくべき注意点  ** ① パブリックプレビューである

Microsoft Learnの冒頭には「Windows App Development CLIは現在パブリックプレビューです。**機能とコマンドは最終リリース前に変更される可能性があります**」と明記されています[2]。実際、2026年1月の公開（v0.1.10）から8月のv0.6.0まで、ほぼ毎月コマンドが追加・変更されてきました[6]。CIに組み込むならバージョン固定とリリースノートの追跡を前提にすべきです。   ** ② 機能によって前提条件が異なる

たとえば `run` のプロジェクトモードは.NET SDK 8.0.100以降が、`winapp new` も.NET SDKの事前インストールが必要で、winapp自体はツールチェーン（.NET SDK等）をインストールしません。`az-sign` はAzure側のアカウント・証明書プロファイルに加え、ローカルにx64の.NET 8ランタイムとVC++再頒布可能パッケージが必要です[3]。npm版限定のコマンド（JSバインディング生成、Electron系）もあります。   ** ③ 既知の問題も公式リファレンスに集約されている

Electronのスパースパッケージ起動クラッシュ（前述）や、ポップアップ要素の録画制限など、既知の問題はGitHub IssueへのリンクつきでLearnに記載されています[3]。導入時は使いたいコマンドのページを一読することをおすすめします。

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

 Windowsの業務アプリケーションやタッチパネル端末ソフトの受託開発を手がける立場から、winapp CLIが効きそうな場面を整理します。
| 場面 | これまで | winapp CLIで |
| CI/CDでのMSIX配布 | makeappx / signtool を個別に叩く自前スクリプトを保守 | `setup-WinAppCli` ＋ `pack` / `az-sign` でパイプラインを標準化 |
| 既存WinForms/WPF資産のモダナイズ | 通知などのモダンAPIを使うには全面MSIX化が必要と思われがち | スパースパッケージで**既存exeのまま**識別を付与し、段階的に近代化 |
| Electron/Flutter製アプリのWindows配布 | Windows固有のパッケージ・署名要件が都度調査になりがち | フレームワーク別ガイドに沿って `init` → `pack` の共通手順に |
| タッチパネル端末のUIテスト | 手動テスト、または商用ツールの導入 | `ui touch` / `ui record` でタッチ操作の再現と証跡録画を自動化 |
| AIエージェント活用の開発フロー | デスクトップ開発はGUI前提でAIに任せにくい | 公式プラグイン＋`--json`出力で、実装〜画面確認までをエージェントに委任 |

 特に「既存アプリを捨てずに、通知や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]。

## まとめ  ** この記事のまとめ
- winapp CLI（Windows App Development CLI）は、Microsoftが2026年1月22日にパブリックプレビューとして公開した公式のコマンドラインツール。MITライセンスのOSSで、winget / npm / GitHub Actionsから導入できる
- `init` でSDK取得〜マニフェスト・証明書生成までの環境構築が1コマンド。Tauri / Electron / Flutter / .NET / Rust / C++ のプロジェクトを自動検出する
- 多くのモダンWindows API（通知・OS統合・オンデバイスAI）に必要な**パッケージ識別**を、`run` や スパースパッケージで開発中・既存アプリにも付与できる
- `pack` → `sign` / `az-sign`（Azure Trusted Signing）→ `store publish` で、MSIX化から署名・ストア申請までがコマンドで完結し、CI/CDに載せられる
- v0.5系で `ui`（UIオートメーション・MP4録画）、v0.6.0で `new`（WinUI 3雛形）・`find-ui`（公式サンプル検索）・`az-sign` が加わり、Claude Code / GitHub Copilot向け公式プラグインも同梱。**AIエージェントがWindowsアプリ開発を扱える土台**が整いつつある
- ただしパブリックプレビューであり、コマンド仕様は変更され得る。導入はバージョン固定と一次情報の追跡を前提に

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

 [アプリ開発事業](https://technosphere.co.jp/app-development) ｜ [AIエージェント活用の実測記事](https://technosphere.co.jp/blog/canva-mcp-claude-code) ｜ [開発の相談をする](https://technosphere.co.jp/contact)

## 参考文献・出典
1. Microsoft「Announcing winapp, the Windows App Development CLI」Windows Developer Blog（2026年1月22日、発表の経緯・対象層・主要機能） — [blogs.windows.com](https://blogs.windows.com/windowsdeveloper/2026/01/22/announcing-winapp-the-windows-app-development-cli/)
2. Microsoft Learn「Windows App Development CLI (winapp CLI)」（定義、プレビュー注記、インストール方法、対応フレームワーク、パッケージ識別の意義） — [learn.microsoft.com/…/winapp-cli/](https://learn.microsoft.com/en-us/windows/apps/dev-tools/winapp-cli/)
3. Microsoft Learn「CLI Documentation and Usage」（全コマンドのリファレンス。本文中のコマンド例の出典） — [learn.microsoft.com/…/winapp-cli/usage](https://learn.microsoft.com/en-us/windows/apps/dev-tools/winapp-cli/usage)
4. GitHub「microsoft/WinAppCli」（MITライセンス、README、Agent Plugin、.NET MAUIガイド、Issue受付） — [github.com/microsoft/WinAppCli](https://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](https://devblogs.microsoft.com/ifdef-windows/windows-app-development-cli-v0-6-create-new-winui-applications-sign-packages-with-azure-and-more/)
6. GitHub「microsoft/WinAppCli Releases」（バージョン履歴） — [github.com/microsoft/WinAppCli/releases](https://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.の商標です。

 AIエージェントにツールを操作させる実例は[Canva MCP × Claude Codeの実測記事](https://technosphere.co.jp/blog/canva-mcp-claude-code)で、アプリの配布方式の選び方は[社内アプリの配布方法まとめ](https://technosphere.co.jp/blog/inhouse-app-distribution)でも解説しています。   [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)