Windows Development Skillsは、Windowsアプリ開発におけるAI/Copilot支援を「コードの相談相手」から「ローカル環境で開発作業を進めるエージェント型ワークフロー」へ近づける更新です。特に重要なのは、WinUI 3、Windows App SDK、WinApp CLIを前提に、スキャフォールド、ビルド、実行、テスト、パッケージ化までをAIエージェントに任せやすくなった点です。Microsoft LearnのWindows開発者向け更新ページでは、2026年6月のBuild発表としてWindows Development Skillsが紹介され、2026年6月3日に更新されています。(Microsoft Learn)
ただし、AIが作ったコードをそのまま本番投入してよい、という話ではありません。開発者は「繰り返し作業の自動化」に使い、管理者やIT部門は「どのツールを許可するか」「Developer Modeや証明書をどう扱うか」「AIに渡してよい情報の範囲はどこまでか」を事前に決める必要があります。
Windows Development Skillsで何が変わるのか
Windows Development Skillsは、AIエージェントにWindowsアプリ開発向けの構造化された知識を与える仕組みです。MicrosoftはBuild 2026で、Windows Development Skillsを「WinUI 3 skills」とWinApp CLIを使ってネイティブWindowsアプリをエンドツーエンドに構築するためのものとして説明しています。Windows Developer Blogでも、Windows Development Skillsは一般提供として案内されています。(Windows Blog)
実務上の変化は、次の3つに整理できます。
| 観点 | 従来のAI支援 | Windows Development Skills後の考え方 |
|---|---|---|
| AIの役割 | コード例や修正案を提示する | スキャフォールド、ビルド、実行、テスト、パッケージ化の流れを支援する |
| Windows固有知識 | 古いUWPやWPFの情報が混ざりやすい | WinUI 3とWindows App SDKに寄せた指示・スキルで補正する |
| 開発環境 | IDEでの手作業が中心 | CLI、VS Code、Copilot/Claude Codeなどと組み合わせてローカルで反復する |
| 管理ポイント | 個人のAI利用ルールが中心 | ツール配布、権限、データ持ち出し、証明書、依存関係まで含めて統制する |
特に重要なのは、Windows Development Skillsが単体の新しいIDE機能ではなく、AIエージェント、WinUI agent plugin、WinApp CLI、Microsoft Learn MCP Server、Dev Configsなどを組み合わせた開発体験の一部として位置付けられていることです。
Windows DeveloperのAI/Copilot更新で押さえるべき構成要素
Windows Development Skillsを理解するには、関連するツールの役割を分けて見ると分かりやすくなります。
| 構成要素 | 役割 | 確認すべきポイント |
|---|---|---|
| Windows Development Skills | AIエージェントにWindowsアプリ開発向けの手順・知識を与える | WinUI 3/Windows App SDK向けの開発に使うものとして理解する |
| WinUI agent plugin | GitHub Copilot CLIやClaude CodeにWinUI 3向けのスキルを追加する | 利用するAIホストと対応状況を確認する |
winui-dev agent | WinUI 3開発の流れを誘導する専用エージェント | 新規作成、機能追加、移行、テスト、パッケージ化のどこに使うか決める |
| WinApp CLI | Windows SDK、パッケージID、MSIX、証明書、UI自動化などをCLIで扱う | プレビュー機能である点、コマンド変更の可能性を考慮する |
| Microsoft Learn MCP Server | AIエージェントが最新ドキュメントを参照しやすくする | 古い学習データだけに依存しない運用にする |
| Dev Configs for Windows | 開発PCを宣言的な設定で準備する | 標準開発環境の展開や再現性確保に使える |
WinUI agent pluginは、8つの専門スキルとwinui-dev agentを含み、スキャフォールド、ビルド、実行、テスト、パッケージ化、移行までを支援するものとして説明されています。Microsoftのドキュメントでは、AIが古いUWPパターンを出しがちな問題に対し、WinUI 3のルールを注入して補正する目的も示されています。(Microsoft Learn)
開発者がローカルで自動化できること
Windows Development Skillsの実用価値は、日々の「面倒だが重要な作業」をローカルで短い反復にできる点にあります。AIに任せるべき作業と、人間が判断すべき作業を分けることが成功のコツです。
開発環境のセットアップを標準化する
新しいWindows PCや検証用環境を作るたびに、VS Code、.NET SDK、WinApp CLI、WinUIテンプレート、GitHub関連ツールを手作業で入れている場合、まずここが自動化の対象です。
Microsoftのクイックスタートでは、VS Code、.NET SDK、WinApp CLI、WinUIのdotnet newテンプレート、GitHub CLI、WinUI agent plugin、WinApp拡張機能などを前提ツールとして案内しています。(Microsoft Learn)
代表的な確認・導入コマンドは次の通りです。
winget install Microsoft.VisualStudioCode
winget install Microsoft.DotNet.SDK.10
winget install Microsoft.winappcli --source winget
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates
winget install GitHub.cliチームで展開する場合は、各開発者に手順書を渡すだけでなく、Dev Configs for Windowsのような宣言的な構成ファイルを使い、標準ツール、OS設定、ポストインストール処理を再実行可能な形にしておくと管理しやすくなります。Dev Configsは、Windowsマシンをready-to-code状態にするためのオープンソース構成として説明されています。(Microsoft Learn)
WinUI 3アプリのひな形作成と初回起動を自動化する
新規アプリでは、AIに「どのテンプレートを選ぶか」「どのファイルを作るか」「起動確認まで行うか」を任せられます。クイックスタートでは、次のような流れでWinUIアプリを作成し、実行する手順が示されています。(Microsoft Learn)
mkdir MyFirstApp
cd MyFirstApp
dotnet new winui-navview
dotnet runここで大切なのは、AIに「作って終わり」にさせないことです。最低でも次の3点をプロンプトに含めると失敗が減ります。
WinUI 3とWindows App SDKを使ってください。
Microsoft.UI.Xaml名前空間を使い、Windows.UI.Xamlは使わないでください。
作成後にビルドと実行確認を行い、エラーがあれば原因を説明して修正してください。AIは見た目だけ動くコードを作ることがあります。初回からdotnet runやwinapp runで確認させ、エラー出力をもとに修正する流れにすると、手戻りを減らせます。
機能追加を「生成」ではなく「検証付きの変更」にする
Windows Development Skillsの効果が出やすいのは、設定画面、一覧画面、検索、テーマ切り替え、簡単なファイル操作など、UIとロジックがセットになった小さな機能追加です。
たとえば、次のように依頼します。
このWinUI 3アプリに設定ページを追加してください。
NavigationViewにSettings項目を追加し、ダークモード切り替え用のToggleSwitchを配置してください。
MVVMパターンを崩さず、アクセシビリティ用のAutomationPropertiesも設定してください。
変更後にビルドして、変更したファイル一覧と確認方法を説明してください。ポイントは、単に「設定画面を作って」ではなく、設計制約、UI要件、確認方法をセットで渡すことです。AIが生成したコードは、レビュー可能な単位に分けて確認します。
UIテストや確認作業をCLI化する
WinApp CLIにはUI Automation関連のコマンドが含まれており、Microsoftのドキュメントでもwinapp uiによるUIツリーの検査、検索、スクリーンショット取得などがCIパイプラインで有用と説明されています。(Microsoft Learn)
ローカルで自動化しやすい確認は次の通りです。
| 確認対象 | 自動化の例 | 人間が見るべきポイント |
|---|---|---|
| 画面遷移 | NavigationViewの項目を操作してページ表示を確認 | 想定外の画面遷移や空白ページがないか |
| 入力欄 | TextBox、ComboBox、ToggleSwitchの値を確認 | 入力制限、エラー表示、初期値が妥当か |
| アクセシビリティ | AutomationIdやNameの有無を検査 | 読み上げ順序、キーボード操作、コントラスト |
| 回帰確認 | 主要画面を起動後にまとめてチェック | CIで落とすべき条件を明確にする |
AIにテストまで任せる場合も、「何を合格条件とするか」は開発者が定義する必要があります。スクリーンショットが取れた、要素が見つかった、というだけでは品質保証として不十分です。
MSIXパッケージ化とStore提出の作業を整理する
WinApp CLIは、Windows SDK、パッケージID、MSIXパッケージング、証明書、署名、Store関連作業などを扱うためのCLIです。ただし、公式ドキュメントではpublic previewであり、正式版までに機能やコマンドが変わる可能性があるとされています。(Microsoft Learn)
クイックスタートでは、パッケージ化の例として次の流れが示されています。(Microsoft Learn)
dotnet publish -o ./publish
winapp pack ./publish --generate-cert --install-certこのコマンドは検証用には便利ですが、--generate-cert --install-certはローカル開発用証明書を作成・インストールします。本番配布やStore提出では、組織で承認された証明書やPartner Centerの運用に合わせる必要があります。
影響を受ける開発チーム
Windows Development Skillsの影響が大きいのは、次のようなチームです。
| チーム・用途 | 影響 |
|---|---|
| 新規WinUI 3アプリ開発 | ひな形作成、画面追加、ビルド、実行確認を短時間で回しやすくなる |
| WPF/UWPからWinUI 3への移行 | API置換や名前空間の修正方針をAIに指示しやすくなる |
| Electron、Tauri、Rust、FlutterなどのWindows対応 | パッケージID、通知、AI API、MSIXなどWindows固有機能の導入支援に使える |
| CI/CD担当 | CLIベースのビルド、パッケージ、UI確認をパイプライン化しやすくなる |
| IT管理者・セキュリティ担当 | 開発者のローカルAI利用、権限、データ持ち出し、証明書管理の統制が必要になる |
一方、Webフロントエンドだけ、Linuxサーバーだけ、WindowsネイティブUIを持たないバックエンドだけを扱うチームでは、直接的な影響は限定的です。ただし、Copilotやエージェント型開発の社内ルール作りという意味では無関係ではありません。
管理者が確認すべき設定・展開上の注意点
Windows Development Skillsは便利ですが、開発者の端末上でAIエージェントがコマンドを実行し、ファイルを変更し、パッケージングまで進める可能性があります。IT部門は「使うかどうか」だけでなく、「どこまで任せるか」を決める必要があります。
Developer Modeを誰に許可するか決める
Windowsでアプリをビルド、展開、テストするにはDeveloper Modeが関係します。Microsoftのドキュメントでは、Developer ModeはWindowsでアプリを構築、展開、テストするためのツールや設定を有効にするものと説明されています。また、有効化には管理者権限が必要で、組織所有デバイスでは無効化されている場合があります。(Microsoft Learn)
確認すべき点は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| Developer Modeの許可対象 | Windowsアプリ開発者、テスト担当、CI用端末などに限定する |
| Device Discovery | リモート展開が必要な検証端末だけで有効化する |
| SSH関連機能 | 不要なら有効化しない。ネットワーク公開範囲を確認する |
| 管理方法 | Intune、グループポリシー、レジストリ、手動設定のどれで統制するか決める |
Developer Modeを全社一律で有効にするのは避けるべきです。開発用途がない一般業務端末では、不要な攻撃面を増やすだけになりかねません。
AIに渡してよい情報を明文化する
AIエージェントは、プロンプト、コード、エラーログ、ファイルパス、場合によってはコマンド出力を扱います。Microsoftの責任あるAI/セキュリティ向けドキュメントでは、秘密情報、認証情報、顧客データ、PII、社内の独自ロジックを不用意にAIツールへ送らないよう注意しています。(Microsoft Learn)
社内ルールでは、少なくとも次を決めておきます。
| 項目 | ルール例 |
|---|---|
| ソースコード | 社外AIサービスに送信できるリポジトリと禁止リポジトリを分ける |
| 顧客データ | 実データではなく匿名化・合成データを使う |
| 認証情報 | APIキー、接続文字列、証明書秘密鍵をプロンプトに貼らない |
| ログ | 個人情報、社内パス、トークンが含まれない形に加工する |
| セッション共有 | bug reportやsession reportを外部共有する前に内容をレビューする |
「AIが便利だから全部読ませる」ではなく、「AIに読ませてもよい最小限の文脈を渡す」方針にすると、安全性と再現性を両立できます。
プラグインやツールのバージョン固定を検討する
Windows Development Skills関連のGitHubリポジトリでは、v0.xのプレビューであり、スキル名、配置、エージェント設定、CLI表面などが予告なく変わる可能性があると明記されています。また、安定運用が必要な場合はリリースタグからインストールする選択肢も示されています。(aka.ms)
企業利用では、次の運用が現実的です。
| 環境 | 推奨運用 |
|---|---|
| 個人検証 | 最新版を試し、変更点を把握する |
| チーム内PoC | バージョンを固定し、同じ手順で再現できるようにする |
| 本番開発 | 許可済みバージョン、許可済み配布元、ロールバック手順を定義する |
| CI/CD | ビルドごとに最新版を取りに行かず、検証済みバージョンを使う |
特に、AIエージェントの挙動は小さなプロンプト変更やスキル更新で変わることがあります。昨日通った自動修正が今日違う結果になる、という前提で管理しましょう。
署名、証明書、Store提出を開発者任せにしない
ローカル検証用証明書を作ってMSIXを動かすことと、ユーザーに配布するアプリを署名することは別物です。クイックスタートでも、開発用証明書はテスト用であり、Store提出ではPartner Centerの証明書を使う旨が示されています。(Microsoft Learn)
管理者は次のルールを明確にします。
| 項目 | 注意点 |
|---|---|
| ローカル開発用証明書 | 検証用途に限定し、配布物には使わない |
| 信頼されたルートストア | 開発者が勝手に証明書を追加しないよう管理する |
| Store提出 | Partner Center権限を最小限にし、承認フローを設ける |
| CI署名 | 秘密鍵をパイプラインに直書きしない。安全なシークレット管理を使う |
| パッケージID | 開発用と本番用を混同しない |
AIに「公開までやって」と依頼できるようになっても、公開判断は人間と組織の承認プロセスに残すべきです。
依存関係とマニフェストの過剰権限をレビューする
AIが生成したコードは、もっともらしいパッケージや広めの権限を追加することがあります。Microsoftのセキュリティガイダンスでも、NuGetパッケージの発行元確認、脆弱性スキャン、不要なアプリ機能権限の削除が推奨されています。(Microsoft Learn)
レビュー時は、次の観点をチェックします。
| 対象 | チェック内容 |
|---|---|
| NuGetパッケージ | 発行元、更新状況、脆弱性、ライセンスを確認する |
Package.appxmanifest | broadFileSystemAccessなど過剰なCapabilityがないか見る |
| 入力処理 | TextBoxの値をファイルパス、シェル、SQLに直接渡していないか |
| 認証情報 | コード内にAPIキーや接続文字列がないか |
| ネットワーク通信 | HTTPS、エラー表示、タイムアウト、例外処理を確認する |
| アクセシビリティ | AutomationProperties、フォーカス順、キーボード操作を確認する |
AIが作ったから危険なのではありません。AIが作ったコードを、人間が理解しないまま通すことが危険です。
失敗しやすいポイントと回避策
Windows Development Skillsを導入する際は、次の失敗が起きやすくなります。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
AIがWindows.UI.Xamlを使う | UWPの学習データが多く、古い例に引っ張られる | WinUI agent pluginやMCP Serverを使い、Microsoft.UI.Xamlを明示する |
| 生成コードがビルドできない | API名、名前空間、パッケージ参照が不正 | 生成後に必ずdotnet runやwinapp runで確認させる |
| 画面は出るが使いにくい | アクセシビリティやキーボード操作が抜ける | プロンプトにAutomationProperties、Tab順、Narrator確認を含める |
| 権限が広すぎる | AIが安全側ではなく動作優先でManifestを書く | Capabilityを最小化し、レビュー項目に入れる |
| 開発用証明書で配布しようとする | 検証と本番配布の区別が曖昧 | 証明書とStore提出は承認フローに分離する |
| ツール更新で結果が変わる | プレビュー段階のスキルやCLIを常に最新版で使う | 検証済みバージョンを固定し、更新タイミングを管理する |
開発者向けのおすすめ運用フロー
最初から大規模リポジトリに導入するより、1つの小さなWinUI 3アプリや社内ツールで試すのが安全です。
| ステップ | やること | 成果物 |
|---|---|---|
| 検証環境を作る | Dev Configsや手順書で同じ環境を再現する | セットアップ手順、許可ツール一覧 |
| サンプルアプリを作る | dotnet new winui-navviewで最小構成を作る | 起動できるWinUI 3アプリ |
| 小さな機能を追加する | 設定画面、一覧、検索などをAIに依頼する | 差分、ビルドログ、確認手順 |
| レビュー基準を作る | セキュリティ、Capability、依存関係、アクセシビリティを確認する | チェックリスト |
| CIに一部組み込む | ビルド、パッケージ、UI確認を自動化する | 再現可能なパイプライン |
| 本番適用範囲を決める | 使うリポジトリ、使わないリポジトリを分ける | 社内利用ルール |
開発者個人としては、まず「AIに任せる前に合格条件を書く」習慣を付けることが重要です。たとえば、次のような依頼なら、生成結果をレビューしやすくなります。
WinUI 3アプリに検索機能を追加してください。
条件:
- Microsoft.UI.Xaml名前空間のみを使う
- MVVMパターンを維持する
- 入力文字列は長さ上限を設ける
- 検索結果が0件の表示を用意する
- 変更後にビルドし、変更ファイルと確認手順を箇条書きで説明するIT管理者が最初に聞くべきガバナンス質問
Windows Development Skillsの導入可否を判断する前に、IT部門は次の質問に答えられる状態にしておくべきです。
| 質問 | なぜ重要か |
|---|---|
| どのAIホストを許可するか | Copilot、Claude Code、その他エージェントでデータ送信先や管理機能が異なる |
| どのリポジトリで利用を許可するか | 機密度の高いコードや顧客データを含む案件では制限が必要 |
| Developer Modeを誰に許可するか | 管理者権限、リモート展開、SSH関連機能に影響する |
| WinApp CLIやプラグインの配布元をどう検証するか | プレビューやGitHub配布のツールを無条件に実行しないため |
| バージョン固定と更新検証を誰が行うか | スキルやCLIの変更によるビルド差異を防ぐため |
| 開発用証明書と本番証明書をどう分けるか | 誤配布、署名ミス、信頼ストア汚染を防ぐため |
| AI生成コードのレビュー責任者は誰か | 「AIが書いたから分からない」を許さないため |
| session reportやログを外部共有してよいか | プロンプト、ファイルパス、コマンド出力の漏えいを防ぐため |
この質問に答えずにツールだけ展開すると、開発スピードは上がっても、監査やセキュリティレビューで止まる可能性があります。
まず取り組むべきこと
Windows Development Skillsは、Windowsアプリ開発のローカル作業をかなり自動化しやすくする更新です。特に、WinUI 3アプリの新規作成、機能追加、ビルド確認、UIテスト、MSIXパッケージ化のような反復作業では効果が出やすいでしょう。
一方で、AIエージェントがローカル端末でコマンドを実行し、コードや設定ファイルを変更する以上、管理者はDeveloper Mode、証明書、依存関係、データ持ち出し、バージョン固定を見直す必要があります。
最初の一歩としては、次の順で進めるのがおすすめです。
| 立場 | 次にやること |
|---|---|
| 開発者 | 小さなWinUI 3サンプルで、生成、ビルド、実行、レビューまでの流れを試す |
| チームリーダー | AIに任せる作業と人間が承認する作業を分け、レビュー基準を作る |
| IT管理者 | 許可ツール、Developer Mode、証明書、AI利用範囲、ログ共有ルールを決める |
| セキュリティ担当 | AI生成コード向けのチェックリストを既存のコードレビューに組み込む |
Windows Development Skillsは、開発者を置き換えるものではなく、Windowsアプリ開発の「手を動かす部分」をエージェントに寄せるための仕組みです。開発者は設計判断とレビューに集中し、管理者は安全に使える境界線を作る。この分担ができれば、Windows DeveloperのAI/Copilot更新は、単なる新機能ではなく、開発プロセス全体を改善するきっかけになります。
コメント