WinForms/WPF/WinUIの選び方 - 実務判断表

対象読者: Windows デスクトップアプリを C# / .NET で作る開発者と、その技術選定を決める立場の方。 前提: 現行の .NET（.NET Framework ではなく）を使い、対象プラットフォームは Windows のみとします。 読み方: 結論だけなら 1 章と 3 章、既存アプリの延命方針を決めたいなら 7 章、最後の決め手が欲しいなら 8 章から読んでください。

Windows のデスクトップアプリを C# / .NET で作るとき、 地味に毎回ややこしいのが WinForms、WPF、WinUI のどれを選ぶか です。

ここで危ないのは、

• いちばん新しいから WinUI
• いちばん慣れているから WinForms
• なんとなく中間っぽいから WPF

みたいな、ふわっとした選び方です。

実務では、見るべき軸はもう少しはっきりしています。

• 新規開発か、既存資産の延長か
• 画面が入力フォーム中心か、表現力が必要か
• Windows らしいモダンな UI が製品価値そのものか
• 配布・更新・企業内運用をどうするか
• チームが Designer 文化なのか、XAML / MVVM 文化なのか

この記事では、このあたりを 判断表として一枚で見やすく整理 します。 なお、この記事でいう WinUI は主に WinUI 3 + Windows App SDK を指します。¹²

また、この 3 つは 全部 Windows 専用 です。 macOS / Linux も視野に入るなら、そもそも問題設定が違います。³⁴¹

1. まず結論（ひとことで）

先にかなり雑に、でも実務で使いやすい言い方をすると、こうです。

• 既存 WinForms アプリ が大きいなら、まずは WinForms 継続 を基本に見ます
• 既存 WPF アプリ が大きいなら、まずは WPF 継続 を基本に見ます
• 新規の小〜中規模な社内ツール で、標準コントロール中心・入力画面中心・素早く作りたいなら、WinForms はまだかなり強いです³⁵
• 新規の中〜大規模な業務アプリ で、画面数が多く、データバインディング、スタイル、テンプレート、コマンド、MVVM をちゃんと使いたいなら、WPF がいちばん無難なことが多いです⁴⁶⁷
• 新規の Windows 専用製品 で、モダンな Windows UI、Fluent、最新の Windows 体験が製品価値に直結するなら、WinUI が有力です¹²
• 最新の Windows API を使いたい だけなら、WinUI 必須ではありません。WPF / WinForms でも Windows App SDK の機能を取り込めます²⁸⁹¹⁰
• 「あとで少しずつ WinUI を差し込めばいい」 を前提に選ぶのは、少し危ないです。段階移行の話は、思ったより泥くさいです¹⁰¹¹

要するに、だいたいこういうことです。

1. 既存資産が大きいなら、その系譜をまず残す
2. 新規で、標準フォームを速く作るなら WinForms
3. 新規で、長く育つ Windows 業務アプリなら WPF
4. 新規で、モダン Windows UI 自体が要件なら WinUI
5. Windows App SDK を使いたいだけなら、いきなり全部 WinUI にしない

フレームワーク選定は、UI 技術の選定であると同時に、 配布・運用・学習コスト・移行コストの選定 でもあります。 ここを「新しい / 古い」だけで決めると、後工程の配布設計と保守コストに跳ね返ってきます。

この記事の知識マップ

WinForms・WPF・WinUIをどう選ぶかを、新規開発か既存資産の延長か、画面が標準フォーム中心か表現力重視かという軸で整理する記事で、標準コントロール中心の業務アプリにはWinForms、データバインディングとMVVMを活かす中〜大規模業務アプリにはWPF、Fluentや最新のWindows体験が製品価値に直結する新規Windows専用製品にはWinUIを推奨する。WinUIはWindows App SDKのUIフレームワーク部分であり、既定でMSIXパッケージとpackage identityを前提とする一方、Windows App SDK自体は既存のWPF/WinForms資産にも機能追加できるためUI全面移行は必須でないとし、XAML Islandsによる段階移行は主戦略にする前に小さく検証すべきだと注意を促す。

flowchart LR
    accTitle: WinForms/WPF/WinUIの選び方の知識マップ
    accDescr: WinForms・WPF・WinUIが新規開発と既存資産のどちらに向くかの判断軸、WinUIがWindows App SDK・MSIX・package identityを前提にすること、MVVMとデータバインディングの関係、XAML Islandsによる段階移行への注意点を示す図
    windows_forms["Windows Forms"]
    wpf["WPF"]
    winui["WinUI(Windows App SDK)"]
    xaml["XAML"]
    data_binding["データバインディング"]
    mvvm_pattern["MVVM(Model-View-ViewModel)"]
    windows_app_sdk["Windows App SDK"]
    msix["MSIX"]
    package_identity["package identity"]
    sparse_package["外部の場所を指すpackaged(sparse package)"]
    unpackaged_app["unpackaged app"]
    xaml_islands["XAML Islands"]
    gradual_winui_migration["既存WPF/WinFormsへのWinUI段階移行"]
    standard_control_centric_app["標準コントロール中心の業務アプリ"]
    multi_screen_business_app["画面数の多い中〜大規模業務アプリ"]
    windows_native_modern_product["Windows専用の新規モダン製品UI"]
    fluent_design["Fluent Design System"]
    wpf -->|"利用する"| xaml
    winui -->|"利用する"| xaml
    wpf -->|"利用する"| data_binding
    mvvm_pattern -->|"前提とする"| data_binding
    wpf -.->|"利用する"| mvvm_pattern
    winui -.->|"利用する"| mvvm_pattern
    winui -->|"実装を担う"| windows_app_sdk
    wpf -.->|"利用する"| windows_app_sdk
    windows_forms -.->|"利用する"| windows_app_sdk
    winui -.->|"前提とする"| msix
    msix -->|"前提とする"| package_identity
    sparse_package -->|"前提とする"| package_identity
    unpackaged_app -->|"両立しない"| package_identity
    wpf -.->|"利用する"| xaml_islands
    windows_forms -.->|"利用する"| xaml_islands
    gradual_winui_migration -->|"前提とする"| xaml_islands
    gradual_winui_migration -->|"用いるのは非推奨"| winui
    windows_forms -->|"推奨される対応"| standard_control_centric_app
    wpf -->|"推奨される対応"| multi_screen_business_app
    winui -->|"推奨される対応"| windows_native_modern_product
    windows_forms -->|"より先に行うべき"| winui
    wpf -->|"より先に行うべき"| winui
    windows_app_sdk -->|"より先に行うべき"| winui
    winui -->|"利用する"| fluent_design

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. この記事でいう 3 つの技術

最初に、言葉を少しそろえます。この先ずっと出てくる略語は、ここで展開しておきます。

WinForms は、Microsoft Learn でも コントロール、グラフィックス、データ バインディング、ユーザー入力を備え、Visual Studio のドラッグ＆ドロップ Designer でアプリを作りやすい フレームワークとして説明されています。³

WPF は、解像度非依存のベクターベース描画、XAML、データバインディング、スタイル / テンプレート、2D / 3D、アニメーション まで含む表現力の高い UI フレームワークです。⁴

WinUI は、Windows App SDK の一部 で、高 DPI、モダンな入力、スムーズなアニメーション、Fluent 系の体験 を前提にした、今の Windows 向け UI フレームワークです。¹² また、data binding / MVVM の導線も普通に持っています。¹²

ここで大事なのは、Windows App SDK と WinUI は同じではない ということです。 WinUI は Windows App SDK の UI フレームワーク部分ですが、Windows App SDK 自体は WPF / WinForms / Win32 の既存アプリにも追加できます。²¹⁰

なので、

• WinUI を使う
• Windows App SDK の機能を使う

は、似ているようで別の判断です。 ここが混ざったまま議論すると、「UI を移行するかどうか」と「機能を足すかどうか」が同じ話として扱われ、結論が出にくくなります。

3. 一枚で見る判断表

まずは、いちばん実務で使いやすい表を置きます。

この表だけでもおおむね足りますが、悩みやすいポイントが 2 つ残ります。

1. 新規の Windows 業務アプリで、WinForms と WPF のどちらに寄せるか
2. 既存 WPF / WinForms があるのに、WinUI へ行くべきか

この 2 点は、続く比較表を見ながら考えると判断しやすくなります。

4. 観点別の比較表

ここは 公式な優劣表 ではなく、かなり実務寄りの比較です。

見方のコツは、何が最強か ではなく、何がいちばん摩擦が少ないか です。

たとえば、

• 社内の設定ツール
• 装置設定画面
• 一覧、明細、検索、設定、ボタン
• 外見より運用の安定と改修スピードが大事

なら、WinForms はまだ十分に合理的です。

逆に、

• 画面数が多い
• 表示状態の切り替えが多い
• View とロジックを分けたい
• データの変化を UI に自然につなぎたい
• スタイル / テンプレートで UI を統制したい

なら、WPF がよく効きます。⁶⁷

そして、

• Windows 11 らしい見た目を前提にしたい
• Fluent をちゃんと活かしたい
• 高 DPI、タッチ、モダンなウィンドウ API を前提にしたい
• 新規で、Windows 専用製品として UI の印象も重要

なら、WinUI が自然です。¹²

4.1 「表現力の差」を最小のコードで見る

上の表の「データバインディング / MVVM との相性」は、言葉だけだとつかみにくいところです。同じ画面を WinForms と WPF で書くと何が変わるか を、最小のコードで並べておきます。

作るのは「テキストボックス 1 個と保存ボタン 1 個」だけの画面です。

WinForms: Designer が *.Designer.cs を生成し、イベント ハンドラーの中で画面から値を取り出します。

// MainForm.Designer.cs — Designer が生成する側。手で書く場所ではありません
private System.Windows.Forms.TextBox nameTextBox;
private System.Windows.Forms.Button saveButton;

private void InitializeComponent()
{
    this.nameTextBox = new System.Windows.Forms.TextBox();
    this.saveButton = new System.Windows.Forms.Button();
    this.SuspendLayout();

    this.nameTextBox.Location = new System.Drawing.Point(12, 12);
    this.nameTextBox.Size = new System.Drawing.Size(200, 23);

    this.saveButton.Location = new System.Drawing.Point(218, 12);
    this.saveButton.Size = new System.Drawing.Size(75, 23);
    this.saveButton.Text = "保存";
    this.saveButton.Click += new System.EventHandler(this.SaveButton_Click);

    this.Controls.Add(this.nameTextBox);
    this.Controls.Add(this.saveButton);
    this.ResumeLayout(false);
}

// MainForm.cs — こちらが手で書く側
public partial class MainForm : Form
{
    private readonly EditorService _service;

    public MainForm(EditorService service)
    {
        _service = service;
        InitializeComponent();
    }

    private void SaveButton_Click(object sender, EventArgs e)
    {
        // 画面のコントロールから直接値を取り出して渡す
        _service.Save(this.nameTextBox.Text);
    }
}

WPF: XAML には「何とつながるか」だけを書き、値の出し入れは Binding が行います。

<!-- MainWindow.xaml -->
<Window x:Class="MyApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="編集" Width="360" Height="120">
    <StackPanel Orientation="Horizontal" Margin="12">
        <TextBox Width="200"
                 Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
        <Button Width="75" Margin="6,0,0,0" Content="保存"
                Command="{Binding SaveCommand}" />
    </StackPanel>
</Window>

// MainWindow.xaml.cs — DataContext を渡すのを忘れると Binding は何も起きません
public partial class MainWindow : Window
{
    public MainWindow(EditorService service)
    {
        InitializeComponent();
        this.DataContext = new MainViewModel(service);
    }
}

// MainViewModel.cs — 画面を知らない側。単体テストもここで書けます
public sealed class MainViewModel : INotifyPropertyChanged
{
    private readonly EditorService _service;
    private string _name = string.Empty;

    public MainViewModel(EditorService service)
    {
        _service = service;
        SaveCommand = new RelayCommand(() => _service.Save(Name));
    }

    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }

    public ICommand SaveCommand { get; }

    public event PropertyChangedEventHandler PropertyChanged;
}

RelayCommand は ICommand を実装した小さなクラスで、CommunityToolkit.Mvvm などのライブラリにも入っていますし、20 行程度で自作もできます。

行数だけ見れば WPF のほうが多いです。差が出るのはここからです。

画面が 3 枚なら WinForms のほうが速く、30 枚になると WPF のほうが軽い、というのがこの差の実務的な意味です。

5. それぞれ、どういう案件に向くか

5.1 WinForms

WinForms は、変に軽く見られがちですが、 標準コントロール中心の業務画面を速く作る という一点では、今でも侮れません。³⁵

特に向いているのは、たとえばこういう案件です。

• 社内向け設定ツール
• 装置・計測器・監視ツールの設定画面
• 管理画面、検索画面、一覧 + 明細
• 既存 WinForms 資産が大きい案件
• Designer で画面を組む文化が強いチーム

WinForms の強みは、難しい思想を持ち込まなくても そこそこ速く完成物に近い画面が出る ことです。 フォーム、ボタン、ラベル、テキストボックス、データグリッド。 この世界が主戦場なら、かなり戦えます。

ただし、弱いところもはっきりしています。

• 画面全体の見た目を大きく統一したい
• スタイルとテンプレートで UI を制御したい
• 複雑な状態変化をデータバインディング主体でさばきたい
• 画面ロジックをきれいに分離したい

このあたりは、WPF や WinUI のほうが素直です。

WinForms で大きいアプリを作ると、気を抜くと イベントハンドラの密林 になりやすいです。 なので、WinForms を選ぶなら、

• 画面責務を小さく保つ
• UserControl 単位で分ける
• Presenter / ViewModel 相当の境界を意識する
• 画面イベントに業務ロジックをべったり書かない

くらいは最初から決めておいたほうが平和です。

あと、実務でかなり大事なのは、Windows App SDK を使いたいからといって WinForms を捨てる必要はない ことです。 公式にも、既存 WinForms アプリに Windows App SDK 機能を足す導線があります。⁹¹⁰

つまり、WinForms は

• UI はそのまま
• 必要な Windows 機能だけ近代化

という選び方ができます。 ここは現実的な落としどころです。

5.2 WPF

WPF は、Windows デスクトップの .NET UI として見ると、 いちばんバランスがよい中核 です。⁴

強みははっきりしています。

• XAML で画面を宣言的に書ける
• Data Binding が強い
• Style / Template が使える
• Command が使える
• View とロジックを分けやすい
• 中〜大規模の画面を整理しやすい

WPF の公式ドキュメントでも、データバインディングは WPF の中心機能として説明されていて、コマンドも入力と実行ロジックを分ける仕組みとして整理されています。⁶⁷

なので、たとえばこんな案件に向いています。

• 画面数が多い業務アプリ
• 一覧、詳細、編集、検索、状態表示が多い
• 複数人で長く保守する Windows アプリ
• View とロジックを分けたい
• 将来の改修で、見た目と挙動の責務を分けておきたい
• WinForms だと画面がすぐ重たくなりそう

新規の Windows 専用業務アプリで迷ったとき、 WPF は今でも安全な第一候補 です。 ここを「WPF は古いからなし」と切るのは、ちょっと乱暴です。

むしろ、

• 既存 WPF 資産がある
• 既存 XAML / MVVM の知見がある
• そこまで Fluent 最優先ではない
• でも WinForms より UI をきれいに設計したい

なら、WPF がいちばん筋がよいことは普通にあります。

もちろん、WPF にも癖はあります。

• XAML を凝りすぎると読みにくくなる
• 独自コントロールやテンプレートを重ねすぎると保守が重い
• 「何でも Binding で解決する」方針に寄せすぎると、かえって処理の流れを追いにくい

このへんは確かにありますが、WPF が悪いというより、表現力のある道具は雑に振ると反動も大きい という話です。

WPF でも、Windows App SDK の一部機能を追加できます。 つまり、WPF のまま Windows 機能を近代化する という道があります。⁸¹⁰

このため、

• WPF を全部捨てて WinUI へ全面移行

よりも、

• WPF を現行 .NET に寄せる
• 必要な Windows 機能だけ Windows App SDK で足す
• 新規の大きい機能から構成を整理する

のほうが、実務では勝ちやすい場面が多いです。

5.3 WinUI

WinUI は、新規の Windows 専用アプリ を作るときのモダンな本命です。¹²

公式には、

• 最新のハードウェアと入力向けに最適化
• 高 DPI
• スムーズなアニメーション
• Windows App SDK の一部

という位置づけです。¹

なので、こういう案件に向きます。

• Windows 専用の新規製品
• UI の印象や体験そのものが重要
• Fluent を素直に使いたい
• Windows 11 の現在地に寄せたい
• 新しいウィンドウ API や最新 Windows 体験を前提にしたい

WinUI を選ぶ理由がちゃんとある案件、というのは、 だいたい 「見た目が新しい」ではなく「Windows の今の体験を製品に取り込みたい」 案件です。

一方で、注意点もあります。

5.3.1 WinUI は「ただ新しい WPF」ではない

XAML を使うので近そうに見えますが、

• ベースの API
• コントロール周り
• プロジェクト構成
• デプロイ / packaging の考え方
• Windows App SDK との付き合い方

が違います。

つまり、WPF からの気軽な置き換え先 と考えると、少し危ないです。

5.3.2 WinUI を選ぶと、配布の話が前に出てくる

WinUI 3 アプリは packaged が既定 です。 一方で、Windows App SDK 自体は packaged / unpackaged の両方 を扱います。¹³¹⁴²

ここで大事なのは、

• どう配布するのか
• ランタイムをどう入れるのか
• package identity が要るのか
• 社内配布か、Store か、MSIX か、既存 EXE / MSI 路線か

を、早めに決めたほうがよい ことです。

ただ、「早めに確認」とだけ言われても何を見ればよいか分かりにくいので、確認の中身をここに置いておきます。

まず、決める軸は 2 つあります。¹³¹⁵

• packaging: そのアプリが package identity を持つかどうか
• runtime: Windows App SDK を framework-dependent で使うか、self-contained で同梱するか

packaging 側の選択肢は 3 つです。¹³

次に、package identity が要るかどうかを機能側から判断します。 公式が「package identity がないと動かない」と明記している機能は、たとえばこのあたりです。¹³

• バックグラウンド タスク
• プッシュ通知（WNS）
• 共有ターゲット
• エクスプローラーのコンテキスト メニュー拡張
• ファイルの種類と URI スキームの関連付け
• スタートアップ タスク
• App Service
• Windows AI API

確認の手順は、この順が実務的です。

1. 要件から引く。 上のリストに当たる機能を使う予定があるか。1 つでもあれば packaged 側が要ります。
2. 既存インストーラを捨てられるか見る。 捨てたくないなら、MSIX への全面移行ではなく 外部の場所を指す packaged が答えになります。既存のバイナリ配置も更新の仕組みもそのままで、identity だけ足せます。¹³
3. 実行時に確かめる。 動いているプロセスに identity があるかは GetCurrentPackageFullName で判定できます。identity がなければ APPMODEL_ERROR_NO_PACKAGE が返ります。逆に、Windows API を呼んで E_ILLEGAL_METHOD_CALL や APPMODEL_ERROR_NO_PACKAGE が出たら、それが package identity 要件に引っかかっているサイン です。¹³
4. 端末側で確かめる。 入っているパッケージは PowerShell の Get-AppxPackage で一覧できます。
5. 最後に runtime を決める。 xcopy や zip で配りたいなら self-contained、Store に出すなら framework-dependent が既定路線です。¹⁵

WinForms / WPF でも配布は大事ですが、WinUI はここが前景に出やすいです。新規の WinUI 3 アプリは 既定で packaged なので、何も決めていないと自動的に MSIX 路線に乗ります。¹³ UI を決めたつもりが、実は配布戦略を決めていた、というのがこの世界の少しややこしいところです。

5.3.3 「既存 WPF / WinForms に少しずつ WinUI を混ぜる」は、先に実験する

ここは期待が膨らみやすいところです。 ただ、Microsoft の FAQ でも、UI フレームワークを完全に移行する準備ができていない限り WinUI は使えないことが多い、という趣旨が書かれています。 さらに XAML Islands まわりも、公式ドキュメントでは既存デスクトップアプリへの埋め込み導線が示される一方、Windows App SDK 1.4 のリリースノートでは 現時点では C++ アプリでの利用が主にテストされており、WPF / WinForms 向けの便利なラッパー要素は入っていない とされています。¹⁰¹¹

つまり、

• 「段階移行できそう」
• 「少しずつ埋めればよさそう」

は、構想としては魅力的でも、案件の主戦略にする前に小さく検証したほうがよい です。

WinUI は、

• 新規で始める
• Windows 専用製品として体験を作る

ときにいちばん筋がよい。 逆に、既存 WPF / WinForms の全面置換の受け皿としては、理由と検証が必要です。

6. よくある判断ミス

6.1 「最新だから WinUI」

これは分かりやすいですが、かなり危ないです。

新しい技術を選ぶ理由は、 その技術でないと得られない価値があるか で見たほうがよいです。

• モダンな Windows 体験が製品価値か
• Fluent を素直に使いたいか
• 新規製品か
• 配布 / 運用の前提を受け入れられるか

ここが yes なら WinUI は有力です。 逆に、単に「将来性がありそう」だけだと、コストの説明が弱いです。

6.2 「Windows App SDK を使いたいから WinUI にしないといけない」

これは誤解されやすいですが、違います。

Windows App SDK は、既存の WPF / WinForms にも足せます。 公式 FAQ でも、WPF / MFC / WinForms アプリは WinUI と無関係な Windows App SDK API を使えると整理されています。¹⁰⁸⁹

たとえば、

• App Lifecycle
• Windowing
• Toast Notifications

のような機能は、今の UI を維持しながら取り込める 場合があります。¹⁰

6.3 「WPF / WinForms はもう終わっている」

ここも、雑に切らないほうがよいです。

WinForms も WPF も、現行の .NET 上でドキュメントと移行導線が継続していて、公式にも現役の Windows デスクトップ UI として扱われています。³⁴

長期保守の判断材料としては、「ドキュメントが残っているか」よりも 新機能が入り続けているか のほうが分かりやすい指標です。この観点で見ると、3 つとも状況は次のとおりです。

つまり、長期保守の観点では次のように読めます。

• WPF と WinForms は「凍結されて放置」ではなく、毎年の .NET リリースに乗って機能が入っています。ただし WinForms の目玉機能は実験的な段階のものがあるので、採用時期は確認が要ります。
• WinUI を選ぶと、.NET のサポート期限と Windows App SDK のサポート期限を別々に管理する ことになります。長期案件では、ここが地味に効きます。
• どれを選んでも「10 年後も無改修で動く」保証はないので、どのバージョンまで追随するかを最初に決めておく ほうが実務的です。

特に業務アプリでは、

• 既存資産
• サードパーティコントロール
• 画面数
• 帳票や印刷
• 装置連携
• 配布手順

のほうが、UI フレームワークの新しさより重いことが普通にあります。

6.4 「どうせなら全面リライト」

全面リライトは、技術選定ではなく 事業判断 に近いです。

既存アプリがあるなら、最初に見るべきはこのあたりです。

1. 何が本当に困っているのか
2. UI の問題なのか、アーキテクチャの問題なのか
3. 依存 DLL / COM / OCX / 帳票 / 配布が本当の重荷ではないか
4. UI を全部変えなくても困りごとは解けるか

UI リライトは派手ですが、コストも派手です。 しかも、見た目は新しくなっても、周辺のややこしさはだいたい残ります。

6.5 「あとで XAML Islands で何とかなる」

この期待は理解できます。 でも、最初から救命ボート扱いしない ほうが安全です。¹⁰¹¹

段階移行は、

• 埋め込みたいコントロールは何か
• フォーカス、入力、DPI、テーマはどうなるか
• 実際にそのホスト構成が安定するか

を、先に小さく試したほうがよいです。

7. 既存アプリを前提にするときの見方

ここは、新規より既存のほうが大事です。

7.1 既存 WinForms があるなら

まずは、いきなり WinUI へ飛ぶ前に、ここを確認します。

• 現行 .NET へ寄せられるか
• 64bit 化が必要か
• async / await、例外処理、設定、ログを整理できるか
• 画面分割や UserControl 化で保守性を上げられるか
• 必要な Windows 機能だけ Windows App SDK で足せるか

WinForms の問題に見えて、実際は

• 画面とロジックが混ざっている
• スレッド境界が雑
• 設定 / ファイル / COM / DB の責務が詰まっている

だけ、ということが珍しくありません。

その場合、WinUI へ引っ越しても、問題が名前を変えて残るだけです。

7.2 既存 WPF があるなら

WPF は、既存資産を活かしやすいです。

• XAML 資産
• Binding
• Style / Template
• Command
• MVVM

このへんを捨てる理由は、かなり明確であるべきです。

たとえば、

• 製品 UI を全面刷新したい
• Fluent を主軸にしたい
• 新規モジュールを別製品として切り出す
• Windows 専用製品として新しい体験へ寄せたい

なら、WinUI の検討理由になります。 でも、単に「WPF は古いから」だと弱いです。

7.3 本当に重いのは UI 以外のことが多い

実務では、しんどいのは案外このへんです。

• ActiveX / OCX
• COM interop
• 独自帳票
• 印刷
• Excel / Office 連携
• ネイティブ DLL
• 32bit / 64bit のねじれ
• インストーラ、権限、更新、署名

ここを軽く見ると、UI だけきれいにしても案件全体は軽くなりません。

なので、既存アプリの移行では、 UI フレームワークだけを見るのではなく、依存境界ごと棚卸しする ほうが先です。

8. 迷ったときに最後に見る 5 問

最終的に迷ったら、この 5 問を順に当てていきます。

8.1 既存資産は大きいか

• 大きい → 既存系譜を基本維持
• 小さい / ない → 新規選定へ

8.2 そのアプリで「Windows らしいモダンな体験」は必須か

• 必須 → WinUI が有力
• そこまでではない → WPF / WinForms で十分か確認

8.3 画面は標準フォーム中心か、XAML 的な表現力が必要か

• 標準フォーム中心 → WinForms
• スタイル / テンプレート / Binding / MVVM が大事 → WPF

8.4 欲しいのは UI の全面刷新か、Windows 機能の追加か

• UI の全面刷新 → WinUI 検討
• 機能追加だけ → 現行 WPF / WinForms + Windows App SDK を先に検討

8.5 配布 / 更新 / 運用をどうするか、先に説明できるか

• まだ曖昧 → WinUI は早めに packaging / deployment を詰める
• 既存運用に強く乗せたい → WPF / WinForms のほうが摩擦が少ないことが多い

この 5 問でかなり絞れます。 最後に雑にまとめると、こんな感じです。

• 速く作る社内フォーム → WinForms
• 長く育つ Windows 業務アプリ → WPF
• 新規のモダン Windows 製品 UI → WinUI
• 既存を活かしつつ Windows 機能だけ近代化 → 現行フレームワーク + Windows App SDK

9. まとめ

WinForms、WPF、WinUI の選定は、 新しい順に並べて一番右を取るゲーム ではありません。

まず見るべきは、この 4 つです。

1. 既存資産がどこにあるか
2. 画面がフォーム中心か、表現力中心か
3. Windows らしいモダン UI が製品要件か
4. 配布 / 更新 / 運用をどう回すか

この 4 つが見えれば、方針はだいたい決まります。

• 既存 WinForms を大きく持っているなら、まず WinForms 継続
• 既存 WPF を大きく持っているなら、まず WPF 継続
• 新規で標準フォーム中心なら WinForms
• 新規で中〜大規模の Windows 業務アプリなら WPF
• 新規でモダン Windows 体験そのものが要件なら WinUI
• Windows App SDK を使いたいだけなら、いきなり全部 WinUI にしない

いちばん避けたいのは、

• 古いから捨てる
• 新しいから選ぶ
• 途中で何とかなるだろうで始める

の 3 つです。

Windows デスクトップは、見た目より 資産、配布、運用、依存関係 のほうが重い世界です。 なので、選び方もキラキラ感より 摩擦の少なさ を見るほうが、だいたい勝ちやすいです。

10. 参考資料

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

WinUI 3とWPFの違いは何ですか？

どちらもXAMLを使いますが、WinUIは「ただ新しいWPF」ではありません。ベースのAPI、コントロール周り、プロジェクト構成、デプロイ / packagingの考え方、Windows App SDKとの付き合い方が違います。WPFは解像度非依存のベクターベース描画、データバインディング、スタイル / テンプレート、コマンドを持つ中〜大規模業務アプリ向けのUIフレームワークで、WinUIはWindows App SDKの一部として、Fluentや高DPI、最新のWindows体験を前提にしたモダンなUIフレームワークです。WPFからの気軽な置き換え先と考えると危険です。

新規開発ではWinForms・WPF・WinUIのどれを選ぶべきですか？

画面の性格と製品要件で分かれます。標準コントロール中心・入力フォーム中心の小〜中規模な社内ツールを速く作るならWinFormsがまだかなり強いです。画面数が多く、データバインディング、スタイル、テンプレート、MVVMをちゃんと使いたい中〜大規模の業務アプリならWPFがいちばん無難なことが多いです。Windows専用の新規製品で、Fluentやモダンな Windows体験が製品価値に直結するならWinUIが有力です。既存資産が大きい場合は、まずその系譜の継続を基本に見ます。

WPFやWinFormsはもう古いのでしょうか？

雑に切らないほうがよいです。WinFormsもWPFも現行の.NET上でドキュメントと移行導線が継続していて、公式にも現役のWindowsデスクトップUIとして扱われています。特に業務アプリでは、既存資産、サードパーティコントロール、帳票や印刷、装置連携、配布手順のほうが、UIフレームワークの新しさより重いことが普通にあります。新規でもWinFormsやWPFが最も摩擦の少ない選択になる場面は珍しくありません。

最新のWindows機能を使うにはWinUIに移行しないといけませんか？

いいえ。Windows App SDKとWinUIは同じではなく、WinUIはWindows App SDKのUIフレームワーク部分です。Windows App SDK自体はWPF / WinForms / Win32の既存アプリにも追加でき、App Lifecycle、Windowing、Toast Notificationsのような機能は今のUIを維持しながら取り込める場合があります。つまり、既存のWPF / WinFormsのまま必要なWindows機能だけ近代化する道があり、UI全面移行は必須ではありません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。