Skip to content

MS_WinAppCLI

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Windows App Development CLI（winapp CLI）

概要

コーディング・エージェント（GitHub Copilot Coding Agent）対応の
（Windows の GUI アプリ開発 SDK の）CLI バージョンと言われている。

  • そりゃ、Claude Code ＋ SPA 開発の UX を見て体感すれば
    「開発しなきゃマズイ。」って思いはするよね♨。
  • なんで？と言うと、Windows の GUI 開発って
    「Visual Studio 20XX」モノリシック（ロックイン）じゃん？
    今日日、アレがダメなんよ。

補足（原文の指摘は的確）: 「Visual Studio モノリシック（ロックイン）」
という診断は、技術的にも産業的にも正しい。整理しておく。

【Windows GUI 開発の従来の構造】

   プロジェクト作成   → Visual Studio のウィザード
   画面設計           → Visual Studio のデザイナ
   ビルド             → Visual Studio（内部で MSBuild）
   パッケージ化       → Visual Studio の発行ウィザード
   署名・証明書       → Visual Studio のダイアログ
   マニフェスト編集   → Visual Studio のエディタ

     → 【すべてが GUI 操作】★
     → 自動化できない、CI に載せにくい
     → 【人間が画面を押す前提】

これがなぜ今問題になったのか——
原文が挙げる AI コーディング エージェントが理由である。

【エージェントに操作させられるか】
   ・CLI      → 【叩ける】★
   ・GUI      → 押せない（画面操作の自動化は脆い）

 → [自作CUI（CLI）の話](MS_BuildingYourOwnCLI) で述べた
   「AI に操作させられるかがインターフェイス設計の評価軸に入った」
   という変化が、Microsoft 自身の製品戦略に及んだ ★

Web / SPA 側との対比が分かりやすい。

Web / SPA 従来の Windows GUI
プロジェクト作成 npm create vite@latest VS のウィザード
ビルド npm run build VS（または MSBuild）
配布 npm publish / 静的配信 VS の発行ウィザード
CI そのまま動く 工夫が要る
エージェント 操作できる ★ 困難

winapp CLI は、この差を埋めようとするものである。

詳細

サポ―トは（、現時点で）、以下と言われている

  • .NET / WPF / WinForms
  • C++ (CMake)
  • Rust
  • Electron
  • Flutter
  • Tauri

補足（対応フレームワークの顔ぶれが示すもの）: この一覧は
winapp CLI の設計思想をよく表している。

【注目点】
   ・Microsoft 純正（.NET / WPF / WinForms / C++）だけでなく
   ・【Rust、Electron、Flutter、Tauri】が入っている ★
      → いずれも Microsoft 製ではない
      → 「Windows 向けアプリを作るなら何で書いてもよい」
        という立場

【つまり】
   winapp CLI が担うのは【アプリの中身】ではなく、
   【Windows に配るための共通の手続き】である
     ・アプリ ID の生成
     ・マニフェスト（Package.appxmanifest）の生成
     ・MSIX へのパッケージ化
     ・証明書の作成・署名
     ・Windows SDK の取得・管理

この切り分けが妥当である。
「どう作るか」は自由にし、「どう配るか」を標準化する——
という設計であり、
.esproj（JavaScript・TypeScriptプロジェクトシステム） で
見た「フロントは npm に任せ、.NET 側は薄く繋ぐ」
という判断と同じ方向を向いている。

MSIX について（背景知識）:

【Windows のパッケージ形式の変遷】
   MSI          … 従来のインストーラ。柔軟だが複雑
   ClickOnce    … .NET 向け。手軽だが制約が多い
   APPX         … UWP 用
   【MSIX】     … 現在の標準 ★
                   ・クリーンなインストール/アンインストール
                   ・自動更新
                   ・Microsoft Store / 独自配布の両方に対応
                   ・Win32 アプリも包める（デスクトップ ブリッジ）

MSIX 化には従来、証明書・マニフェスト・パッケージ化の
手順が煩雑であり、これが winapp CLI の主な解決対象である。

補足（実際の使い方の概形）: 原文は詳細が薄いため、
公式が示すコマンド体系の概要を補っておく
（プレビュー段階のため、コマンド名は変わり得る）。

# SDK の管理
winapp sdk list
winapp sdk install

# アプリ ID・マニフェストの生成
winapp identity create
winapp manifest create

# 証明書（開発用の自己署名）
winapp cert create

# パッケージ化・署名
winapp package
winapp sign
【CI での価値】★
   従来： Windows のビルド エージェント上で
          VS の発行ウィザード相当を再現するのが困難
            → 手作業、あるいは MSBuild の複雑な引数

   winapp： 【1 行ずつのコマンド】に分解できる
            → GitHub Actions / Azure Pipelines の
              ステップとしてそのまま書ける
            → 【差分・レビュー・再現ができる】

注意点（プレビュー段階）:

・バージョンが 0.x 系であり、【破壊的変更があり得る】★
   → 原文の参考リンクも v0.3.2 の記事
・本番の配布パイプラインに載せる際は
  バージョンを固定し、変更を追跡する
・Visual Studio の機能をすべて置き換えるものではない
   → デザイナは依然として VS が必要

参考

補足（「VS Code に統合する拡張機能」の意味）: 2 つ目の窓の杜の記事が
示す動きは、本ページの主題を裏付けている。

【流れ】
  ① CLI を作る（機械が叩ける形にする）★ 本質はここ
  ② その CLI を VS Code の拡張から呼ぶ（人にも使いやすくする）

 → 【逆ではない】点が重要である
   ・従来： GUI が本体で、CLI は後付け（あるいは無い）
   ・現在： 【CLI が本体で、GUI はその上の薄い層】

 → [.esproj（JavaScript・TypeScriptプロジェクトシステム）](MS_ESProj) の
   「VS は npm を呼ぶだけ」という構造とまったく同じ ★
 → [Web Essentials](MS_WebEssentials) が 2015 年に
   「コンパイラを削除して外部ツールに委ねた」のと同じ判断

この設計であれば:

・VS Code でも Visual Studio でも Vim でも同じ結果になる
・CI で同じコマンドが動く
・AI エージェントが操作できる ★
・ドキュメントがコマンドとして書ける（再現性がある）

原文の「Claude Code ＋ SPA 開発の UX を見て体感すれば」
という指摘は、まさにこの点を捉えている。

Microsoft Learn

Tags: 移行, .NET開発, UIサブシステム, Windows Forms

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally