WinUI 3（Windows App SDK）のプロジェクトを作ったのに、Visual Studio 2022で「Design」タブや画面デザイナーが見当たらず困っていませんか？本記事では、未対応である理由と最新の公式情報、そしてデザイナー無しでも破綻しない開発フローを具体的に解説します。
WinUI 3でXAMLデザイナーが見当たらない結論
まず結論から整理します。WinUI 3（Windows App SDK）プロジェクトでは、Visual Studio 2022のXAMLデザイナー（いわゆる画面デザイナー／Designビュー）は現時点で提供されていません。そのため、WPFやUWPのように「XAMLとDesignのタブを切り替えて、アートボード上でドラッグ＆ドロップする」体験は前提にできません。
また「いつ追加されるのか？」については、明確な提供時期（ETA）は公開されていないのが実情です。Microsoft LearnのFAQでは、WinUI向けのUIデザイナーは「まだ無い（Not yet）」という位置づけで、既知のギャップであり、Windows App SDK 1.7で作業が開始されたもののリリース時期は示されていない、と説明されています。
したがって、いま実務で取れる現実解は次の2つに集約されます。
- 状況を追う：Developer Communityの要望チケットや、GitHubのWinUI関連Issue（代表例：microsoft-ui-xamlの #5917）をウォッチして更新を追いかける
- 開発を進める：XAML Hot ReloadやLive Visual Treeなど、実行しながら調整するワークフローに寄せて設計・運用する
「デザイナーが無い」は設定ミスではなく仕様
検索すると「Tools > Options > XAML Designerを有効化すれば出る」といった情報も見かけます。しかしWinUI 3のケースでは、そもそもDesignビュー自体がサポート対象外のため、設定で復活する類の話ではありません。Microsoftのドキュメントでも、WinUI 3のXAMLデザイナーはVisual Studio 2022でサポートされない旨が明記されています。
| 項目 | WPF | UWP | WinUI 3（Windows App SDK） |
|---|---|---|---|
| Visual StudioのDesignタブ（アートボード） | 利用できる | 利用できる | 現時点では未対応 |
| ドラッグ＆ドロップ（Toolbox→画面） | 可能 | 可能 | 現時点では不可 |
| XAML Hot Reloadで実行中に反映 | 可能 | 可能 | 可能（制約あり） |
| Live Visual Tree / Live Property Explorer | 利用できる | 利用できる | 利用できる |
WinUI 3の開発を始めた直後にハマりやすいのは、「デザイナーが開けない＝環境構築が失敗した」と思い込んで時間を溶かすことです。ここは割り切って、以降の章で紹介する“デザイナー無し前提”の運用に切り替えるのが最短ルートです。
なぜWinUI 3だけXAMLデザイナー未対応なのか
公式には「既知のギャップ」「作業は始まっているが時期は未定」といった表現が中心で、技術的な詳細理由が長文で説明されているわけではありません。
ただ、一般論としてXAMLデザイナーは単なるエディタ機能ではなく、設計時にXAMLをレンダリングし、プロパティ編集やイベント配線、ツールボックス連携まで含めた“別の実行環境”をIDE内に構築する必要があります。WinUI 3はUWPとはアプリモデルや依存関係（Windows App SDKとしての配布、Win32アプリとしての起動形態、パッケージ／非パッケージなど）が異なるため、従来のUWP用デザイナーをそのまま流用しにくい、という背景は理解しやすいポイントです。
実際、Microsoft Learnの「WinUI向けのUIデザイナーはまだ無い」というFAQは、代替としてXAML Hot Reloadの活用を推奨しています。つまり現時点のプロダクト方針としては、“設計時のデザイナー”よりも“実行時に編集して反映する”方向に寄せていると捉えるのが現実的です。
いつ追加される？公式情報を時系列で整理
「結局いつ来るの？」は全員が知りたいところですが、現時点で確定日を示す公式発表は見当たりません。そこで、確認できる一次情報（Microsoft Learn / GitHub / Microsoft Q&A）を時系列で並べて、現状の温度感を把握できるようにします。
| 時期 | 出来事（要点） | 読み取れること |
|---|---|---|
| 2021-09 | WinUI 3のXAML Designerに関する議論（GitHub Issue #5917）が開始 | 早期から要望が強い“既知の課題”として継続 |
| 2023-04 | Microsoft Q&Aで「機能は検討中（considered）」と案内 | 要望は把握されているが、確定した提供時期は出ていない |
| 2024-09 | Windows App SDK 1.7の計画スレッドで「WinUI 3 Designer progress」が改善項目として言及 | 少なくとも“検討”から一歩進み、作業・進捗という形で扱われている |
| 2025-07 | Microsoft Learnで「Windows App SDK 1.7時点でDesignタブはWinUI 3をサポートしない」と明記 | 少なくとも当該版では“未対応”が公式ドキュメントに残っている |
| 2025-12 | Windows developer FAQで「Not yet」「作業は始まったがタイムラインは無い」と明記 | “いつ頃”は明示されず、追跡が必要な状態が継続 |
この表から言える現実はシンプルで、「いつ頃」の答えを待って手を止めるより、デザイナー無しで成立する運用に切り替えるほうがプロジェクトが前に進むということです。次章から、実際に困らないための具体策に落とします。
代替ワークフローの中心：XAML Hot Reloadで“実行しながら詰める”
WinUI 3でUIを作るときの基本は、アプリを起動した状態でXAMLを編集し、差分を反映しながら見た目を詰めるスタイルです。MicrosoftのXAML Designer関連ドキュメントでも、WinUI 3ではXAML Hot Reloadを使って実行中にUIを見ながら編集することを案内しています。
Hot Reloadを効かせるための準備
- デバッグ実行（F5）でアプリを起動し、編集対象の画面まで遷移しておく
- Visual Studioの設定で、XAML Hot Reloadが有効になっていることを確認する（メニュー階層は「Debugging」配下にある）
- 反映を速くするため、起動直後に対象ページが開く導線（起動引数、開発用メニュー、デバッグ専用の初期ページなど）を用意する
実務で効く“ホットリロード前提”の編集手順
次の順番で作業すると、デザイナー無しでもUI調整のストレスが減ります。
- まずレイアウトの骨格を作る（Grid / StackPanel / RelativePanelなど）
- 余白・配置・サイズの最小セットを決める（Margin/Padding/Alignment/Spacing）
- テンプレート化が必要な領域（リスト、カード、フォーム）を先に固める
- 最後に色・フォント・角丸などの“装飾”を寄せる
ポイントは、UIを一気に作り込まず、崩れやすいレイアウト→繰り返し要素→装飾の順に段階を踏むことです。ホットリロードは“反映のしやすさ”に偏りがあるため、骨格が固まってから装飾をやるほうがリトライ回数が減ります。
Hot Reloadで反映されない時に疑うこと
| 症状 | よくある原因 | 実務的な対処 |
|---|---|---|
| 保存しても見た目が変わらない | 変更がホットリロード対象外／実行中の画面が別ページ | 対象ページまで遷移し直す、またはアプリを再起動して状態を揃える |
| Bindingの変更が効かない | DataContextやViewModelの生成タイミングに依存 | 画面再表示、必要ならデバッグ再実行。UIだけ先に固め、Bindingは後回しにする |
| リソース（Styles/ThemeResource）変更が効きづらい | 辞書の読み込み順／キャッシュ | 小さく分割したResourceDictionaryで影響範囲を限定し、再起動コストを下げる |
Live Visual Treeで“なぜ崩れたか”を可視化する
デザイナーが無いと、レイアウト崩れの原因を推測で直しがちです。ここで威力を発揮するのがLive Visual Tree / Live Property Explorerです。実行中のUIツリーを辿って、どのコンテナがどのサイズでレイアウトされ、どのプロパティが最終値として効いているかを確認できます。
特にWinUI 3は、コントロールテンプレートやVisualStateで見た目が変わるケースが多く、XAMLの記述だけ見ていると「どこで上書きされたか」が分かりにくい場面があります。Live Visual Treeを使うと、
- 実際に適用されているStyle/Template
- 期待と違うWidth/Height/Min/Maxの値
- 余白（Margin/Padding）やAlignmentの衝突
- VisualStateの遷移状態
などを“実測”できます。デザイナーが無い不安を埋める道具として、まずここに慣れるのが得策です。
デザイナー無し開発を楽にする設計パターン
UIデザイナーが無い環境で詰まりやすいのは「画面全体を一枚のXAMLに詰め込み、調整対象が広すぎる」ことです。WinUI 3では、UIを小さく切って、実行しながら差し替える設計に寄せると生産性が上がります。
プレビュー専用ホスト画面を作る
たとえばUserControl単位で作り、デバッグ時は“プレビュー用の画面（PreviewHost）”にそのUserControlだけを配置して起動できるようにします。すると、アプリ全体の遷移やログイン状態に引きずられず、UI調整のループが短くなります。
<!-- PreviewHostの例（概念） -->
<Grid>
<local:CustomerCard />
</Grid>ここで重要なのは、プレビュー用にダミーデータを流し込み、状態（通常／空／エラー／長文／多件数）を切り替えられるようにすることです。デザイナーが無い環境では、見た目の検証は“実行時の状態”で決まります。
スタイルを集中管理し、変更点を減らす
色・フォント・余白・角丸などを各画面に散らすと、ホットリロードが効かない時の再起動コストが跳ね上がります。ResourceDictionaryに集約し、影響範囲をコントロールできる形にしておくと、変更の粒度が揃い、修正も追いやすくなります。
WinUI Galleryを“実質的なデザイナー代わり”に使う
「このコントロール、どんな見た目で、どんなプロパティがある？」を確認したい時、WinUI Galleryが非常に役立ちます。WinUI GalleryはWinUIのコントロールやスタイルを対話的に確認でき、サンプルのマークアップやコードも参照できます。
実務的には、
- まずGalleryで目的のコントロールの見た目と挙動を確認
- 必要なXAMLの骨格を自分のプロジェクトに持ち込み
- Hot Reloadで自分の画面に馴染ませる
という流れにすると、ドラッグ＆ドロップが無いデメリットをかなり相殺できます。
よくある勘違いとチェックリスト
| 勘違い・悩み | 実際のところ | 最短の対処 |
|---|---|---|
| 「Designタブが無い。インストール失敗？」 | WinUI 3はDesignタブ未対応 | Hot Reload + Live Visual Tree前提で進める |
| 「Blendなら出せるのでは？」 | BlendのXAML Designerも同様にWinUI 3ではDesignビューが前提にしづらい | 設計時デザイナーに依存しないUI分割を行う |
| 「将来すぐ追加されるはず」 | 作業開始の言及はあるが、提供時期は明示されていない | 要望チケットをフォローしつつ、現行フローで開発を進める |
それでもGUIデザイナーが必須なら検討すべき選択肢
業務アプリなどで「ドラッグ＆ドロップで画面を組めないと開発体制が回らない」というケースもあります。その場合、フレームワーク選定の段階で“設計時デザイナー必須”を要件として扱うほうが安全です。
現実的な落としどころとしては、
- UIはWPFで作り、必要に応じてWindows App SDKのAPIを取り込む（既存アプリへの導入も可能）
- WinUI 3にこだわる場合は、デザイナー無し運用を前提に、UIを部品化してHot Reloadで回す
のどちらかになります。Windows App SDK自体は、WinUIだけでなく既存のWPF/WinForms/Win32アプリにも追加できる、と公式に説明されています。
今後の追加に備えて“追いかける”具体的な手順
デザイナーの追加時期が不明な以上、情報の取りこぼしを減らす運用が重要です。おすすめは次の3点です。
- Developer Communityの該当フィードバックをフォロー／投票して、優先度が上がるように意思表示する
- GitHubの議論（microsoft-ui-xaml Issue #5917）をSubscribeし、ステータスや関連Issueの動きを追う
- Windows App SDKのリリースノートやFAQを定期的に確認し、「Not yet」が更新されたタイミングを逃さない
最後にもう一度まとめると、WinUI 3でXAMLデザイナーが見当たらないのは“あなたの環境の問題”というより、現時点の公式サポート範囲の問題です。だからこそ、プロジェクトを止めずに進めるために、Hot Reload＋検証しやすい設計＋ツリー可視化の3点セットを早めに整備しておくことが、いちばんの近道になります。
コメント