WPF 開発で AI を活用する方法｜XAML・MVVM の生成からテスト・移行まで

WPF 開発で AI に任せる範囲を決める

検索欄の追加、入力内容に応じたボタンの有効化、古い画面を保った実行環境の更新など、WPF の業務アプリ開発で AI を使うなら、最初に決めたいのは「どのコードを書かせるか」と「何をもって完了とするか」です。

XAML の見た目が整っていても、入力が ViewModel に届かなければ業務では使えません。ビルドが成功していても、配布先の Windows で操作や帳票を確かめる工程は残ります。本記事では、AI に作業を指示し、生成結果を検証し、旧環境の移行を判断する手順を扱います。WPF アプリの内部にチャットや生成 AI を組み込む方法は対象外です。

AI 駆動開発の全体像 を WPF に当てはめると、コード生成だけでなく、設計の読み取りと検証記録にも AI を使えます。まずは次の分担から始めてください。

以下の製品仕様とサポート情報は、2026 年 9 月 17 日に公式資料を確認した内容です。コード例は説明用に作成したもので、Windows 上での動作確認は行っていません。採用する際は、自分の SDK・パッケージ・実行端末で検証してください。

Claude Code・Cursor・GitHub Copilot の実行環境を揃える

AI ツールを選ぶときは、既存の開発環境からビルドとテストへつなげられるかを確認します。製品全体の比較は Claude Code・Cursor・GitHub Copilot の比較記事 に譲り、ここでは WPF の検証に関わる条件を整理します。

根拠は Claude Code のセットアップ資料、Cursor Agent の概要、Visual Studio のエージェントモード です。導入手順から確認したい場合は、Claude Code の導入ガイド と Cursor の始め方 を参照してください。

WPF は Windows 専用です。Microsoft の WPF 概要 は、.NET 自体がクロスプラットフォームでも WPF は Windows 上でのみ実行すると説明しています。Mac や Linux のエージェントがコードを編集できることと、WPF の画面を起動して検証できることは別です。

画面操作・検査ツールを接続していないエージェントには、現在の表示状態を確認する手段がありません。ホットリロードで手元の画面が更新されても、その結果が自動的にエージェントへ伝わるわけではないため、再現手順やログを渡します。画像を入力できる環境なら、顧客名や実データを除いたスクリーンショットも補助になります。

FIXIT

AI がビルドまで終えたら、画面も完成したって考えていいの？

Tsukasa

完了にはできません。入力と表示のつながりは、Windows 上の操作でも確かめます。

FIXIT

じゃあ、最初に何を決めればいい？

Tsukasa

合格とする操作です。「入力したら何が変わるか」を、コードを書く前に決めます。

XAML と MVVM を生成する前に渡す情報

MVVM は、画面を担う View、表示状態や操作を担う ViewModel、業務処理やデータを担う Model に責務を分ける考え方です。WPF では XAML の Binding と ViewModel のプロパティ・コマンドを対応させます。AI に「MVVM で作って」とだけ頼むより、現在の責務分担と命名規約を渡すほうが、レビュー対象を絞れます。

最初の依頼は、変更ではなく調査にします。対象の XAML、対応する ViewModel、プロジェクトファイル、近い機能のテストを読ませ、どのファイルの記述を根拠にしたかまで報告させてください。AI の推測とコードから確認できた事実を分けるためです。

ランタイムと既存の作法を指定する

たとえば、すでに独自のコマンド実装を使っているプロジェクトなら、AI が CommunityToolkit.Mvvm を追加する理由を確認します。属性で短く書けることだけを理由に、保守中の画面の設計まで変更する必要はありません。

小さな画面変更の指示例

次は検索語を入力し、プレビュー結果を表示する画面を想定した指示例です。実際に渡すときは、冒頭の環境とファイル名を自分のプロジェクトに合わせます。機密データではなく、架空の入力例で合格条件を書いてください。

対象は既存 WPF アプリの検索プレビュー画面です。
最初に csproj、対象 XAML、ViewModel、近いテストを読み、
対象フレームワーク、MVVM ライブラリの版、DataContext の設定場所を報告してください。
不明点を推測で埋めず、この段階ではコードを変更しないでください。
 
確認後、既存の設計を維持して次の変更を行います。
- 入力が空または空白だけなら、プレビューボタンを無効にする
- 文字を入力すると、フォーカスを外す前にボタンを有効にする
- 押すと前後の空白を除いた文字列を結果欄に表示する
- DB 接続、パッケージ更新、他画面の変更は行わない
 
先に合格条件をテストにして、変更前の失敗を確認してください。
XAML と ViewModel を変更し、ビルドとテストを実行してください。
最後に変更ファイル、実行したコマンド、結果、未実施の画面確認を分けて報告してください。

この段階で「画面を作り直したほうがよい」という提案が出たら、要求を満たすのに必要な変更かを人が判断します。変更理由を確認しないまま範囲を広げると、元の不具合と新しい設計変更の影響を分けにくくなります。

CommunityToolkit.Mvvm の生成結果を確認する

ここからは、CommunityToolkit.Mvvm を採用する場合の確認例です。導入済みの WPF プロジェクトで、フィールドに属性を付けてプロパティを生成する記法を使います。別の MVVM 基盤を採用しているプロジェクトでは、その基盤の方式に読み替えてください。

属性名だけでなく、生成される名前を見る

ObservableProperty の公式資料 では、属性を付けたフィールドを partial な型に置き、変更通知の基盤を用意します。以下では ObservableObject を継承します。query フィールドからは Query プロパティが生成されます。

RelayCommand の公式資料 に従うと、Preview メソッドからは PreviewCommand が生成されます。XAML が参照するのは、属性を付けたフィールドやメソッドではなく、生成後のプロパティです。

using CommunityToolkit.Mvvm.ComponentModel;
using CommunityToolkit.Mvvm.Input;
 
namespace WpfAiExample;
 
public partial class SearchViewModel : ObservableObject
{
    [ObservableProperty]
    [NotifyCanExecuteChangedFor(nameof(PreviewCommand))]
    private string query = string.Empty;
 
    [ObservableProperty]
    private string result = string.Empty;
 
    private bool CanPreview() => !string.IsNullOrWhiteSpace(Query);
 
    [RelayCommand(CanExecute = nameof(CanPreview))]
    private void Preview()
    {
        Result = Query.Trim();
    }
}

この例には、保存や通信を含めていません。入力とコマンドと表示のつながりを確認するためのコードです。実際の業務処理を足す際は、既存のサービス呼び出しや例外処理の方針に合わせます。

XAML 側の更新タイミングを揃える

次の XAML は MainWindow.xaml の例です。SearchViewModel を同じアセンブリの WpfAiExample 名前空間に置き、MainWindow.xaml.cs は同じ名前空間の MainWindow クラスで InitializeComponent() を呼ぶ通常の構成を前提とします。既存の DI で DataContext を渡している場合は、二重に生成せず、その設定を維持してください。

<Window x:Class="WpfAiExample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:WpfAiExample"
        Title="検索プレビュー" Width="420" Height="240">
    <Window.DataContext>
        <local:SearchViewModel />
    </Window.DataContext>
    <StackPanel Margin="24">
        <TextBox Text="{Binding Query, Mode=TwoWay,
                       UpdateSourceTrigger=PropertyChanged}" />
        <Button Content="プレビュー"
                Command="{Binding PreviewCommand}" Margin="0,12,0,12" />
        <TextBlock Text="{Binding Result}" />
    </StackPanel>
</Window>

WPF のデータバインディング資料 によると、TextBox.Text の既定の更新タイミングは LostFocus です。入力中に実行可否を変えたい例なので、ここでは UpdateSourceTrigger=PropertyChanged を明示しています。

流れをたどると、TextBox の変更が Query に届き、NotifyCanExecuteChangedFor によってコマンドの再評価が要求され、CanPreview が入力値を判定します。プロパティの変更通知だけ用意しても、実行可否の再評価まで自動的に済むとは限りません。前掲の RelayCommand 資料も、条件が変わったことをコマンドへ通知する責任は開発者にあると説明しています。

同じ考え方で、入力から実行までの合格条件を表にできます。これは実測結果ではなく、例を採用するときに実施する検証項目です。

こうした確認を毎回同じベテラン担当者だけが担っているなら、チームで指示とレビューの手順を揃える余地があります。たとえば、この表を共通の確認項目にし、AI に渡す条件と人が確認する操作を全員で練習します。自社のコードで取り組みたい場合は、実リポジトリを使う AI 駆動開発研修 も選択肢です。

ビルド・テストと画面確認を分ける

検証は、コンパイル、ロジックのテスト、Windows 上の画面確認に分けます。AI にログを読ませて修正させる場合も、どの段階が失敗したかを伝えてください。画面の不具合をビルド設定だけで解決しようとする、といった調査の取り違えを避けられます。

SDK 形式のプロジェクトでコマンドを固定する

以下は、Windows の開発環境で SDK 形式の WPF プロジェクトとテストプロジェクトを検証する例です。ファイル名は例示であり、対象の構成に合わせて置き換えます。

dotnet build src/WpfAiExample/WpfAiExample.csproj -c Release
dotnet test tests/WpfAiExample.Tests/WpfAiExample.Tests.csproj -c Release

dotnet build と dotnet test の公式資料を基にしています。テストランナーによって対応オプションが異なるため、既存の設定を読み取らせてから実行します。旧形式の .NET Framework プロジェクトにも、この例をそのまま適用できると考えず、現在のビルド手順を起点にしてください。

非 Windows で Windows 向けにビルドするときは、EnableWindowsTargeting が必要になる場合があります。ただし、NETSDK1100 の説明 にある設定は、Windows ターゲットのビルドを許可するものです。Windows 専用の依存部品が使える保証でも、WPF をその OS で実行する方法でもありません。

テストの成功件数と未実施を残す

ViewModel のテストでは、値の変化だけでなく、コマンドの実行可否と通知も確かめます。たとえば Query を変更した後の CanExecute が正しくても、CanExecuteChanged が通知されなければ、ボタンの表示に反映されない可能性があります。

AI にテストを先に書かせる際は、人が決めた合格条件を使います。AI 駆動 TDD の進め方 と同様に、変更前に期待どおり失敗することを確認し、その後に実装を進めます。実装に合わせてテストの期待値まで変更していないかもレビューしてください。

完了報告にはコマンドと終了コードに加え、テストの件数、失敗・スキップ、実行環境を残します。「テストコマンドが終了した」と「対象のテストが実行された」は同じ意味ではありません。Windows 専用のテストを実行できなかった場合は、未実施として記録します。

Binding のエラーと業務操作を実機で確認する

Microsoft の XAML Binding 診断資料 は、Binding の不備がビルド時ではなく実行時に現れることを説明しています。Visual Studio の XAML Binding Failures ウィンドウなどで、ソースやプロパティ名の不一致を調べます。

さらに、業務端末では表示と操作を確認します。検証対象は、画面サイズ、表示倍率、キーボード移動、日本語入力、連続操作、エラー表示です。帳票・プリンター・ファイル出力があるアプリでは、その処理も独立した確認項目にします。全項目を一度に試すより、変更が影響する操作を先に絞るとレビューしやすくなります。

不具合を AI に戻すときは、再現した版、操作手順、期待結果、実際の結果、関連ログをセットにします。画像があるだけでは入力の順序や通信の状態まで分からないため、短い再現手順を添えてください。修正後には同じ操作を再実施し、直った理由と確認結果を残します。

WPF のサポート終了を調べる前に、実行環境を分ける

「WPF サポート終了」と検索していても、調べる対象は 1 つではありません。2026 年 9 月 17 日に確認した資料からは、WPF 全体に共通する一律の終了日を示す根拠は確認できませんでした。WPF の .NET 版と .NET Framework 版、実行先の Windows、UI 部品の保守期限を分けて調べます。

.NET と .NET Framework の期限を混同しない

Microsoft Learn の .NET ライフサイクル は、.NET を版ごとに管理しています。以下の日付は、同じ Microsoft の .NET サポートポリシー の表示に基づきます。

.NET Framework については、ライフサイクル FAQ と 製品別のライフサイクル を照合します。4.8 や 4.8.1 の終了日欄が空いていることを、どの Windows でも無期限に使える保証とは解釈しないでください。また、現行 .NET も期限内の版を選ぶだけでなく、最新パッチの適用がサポート条件に含まれます。

この整理をすると、「WPF を捨てる必要があるのか」と「実行環境を更新する必要があるのか」を分けられます。期限が近い場合も、直ちに Web アプリへ全面刷新する結論にはなりません。業務上の要件と移行対象を先に特定します。

AI を使った .NET 移行は台帳から始める

Microsoft の WPF 移行ガイド を参照し、AI にはまず互換性の調査対象を列挙させます。対象フレームワークを書き換えるだけで済むと決めず、参照パッケージ、古い API、配布方法、外部機器との接続を確認してください。

1. AI にプロジェクトと参照関係を読み取らせ、根拠ファイル付きの一覧を作ります。
2. 人が配布先 Windows、部品ベンダーの対応状況、維持する業務操作を確認します。
3. 代表的な画面を選び、現行環境の入力と結果を回帰テスト・操作記録として残します。
4. 別ブランチで AI に移行差分を作らせ、ビルドと Windows 上の検証を行います。
5. 差分の原因を整理してから移行対象を広げ、切替と切り戻しの手順を合意します。

台帳には「確認済み」「要調査」「対応不可」を分けて記載します。AI がパッケージ名から対応状況を推測した場合は、確認済みにせず、ベンダーの対応表を調べる項目に戻してください。ランタイムの更新と画面の全面再設計を同時に行うと、挙動が変わった理由を追いにくくなるため、検証単位を分ける方針が有効です。

WinForms から WPF へ画面を書き換える判断も、.NET Framework から新しい .NET へ更新する判断とは別です。既存操作を残すのか、画面構成自体を改善するのかによって受け入れ条件が変わります。AI に一括変換を頼む前に、必要な成果を発注者と開発者で揃えてください。

発注者と開発者で受け入れ条件を決める

発注者が知りたいのは、生成されたコードの量よりも、業務で使える状態まで確認されたかどうかです。見積もりや納品物では、実装と検証をまとめて「AI で対応」と書かず、何を確認する工程なのかを具体化します。

たとえば、帳票出力を含む改修では「画面からボタンを押せた」だけで検収せず、出力結果、保存先、業務端末からの印刷まで、必要な範囲を決めます。AI が実施した検査と、人が実施した検査を別々に記録すれば、残っている確認も把握できます。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、AI を活用したプロダクト開発 と システム刷新・リプレイス の相談を受け付けています。WPF の相談では、利用中の .NET、配布先 Windows、外部部品、残したい業務操作を共有いただくと、対応範囲と検証条件を整理しやすくなります。

個人の AI 活用を、チームの開発手順にする

「AI を使える人だけが作業を進め、生成結果の確認はベテランに集中する」「研修を受けても、自社の WPF アプリでは試せず元の手順に戻る」。こうした課題がある場合は、自社のコードを使い、指示・テスト・レビューまでをチームで練習する研修を検討できます。

AI 推進担当がいない、あるいは担当者が通常業務で手いっぱいで、社内への展開が進まないこともあります。ツールの選定、利用ルールの整理、教材作りまで社内で担おうとすると、練習を始める準備にも時間がかかります。

FIXIT の AI 駆動開発研修は、自社リポジトリを題材に、テストを先に書き、AI に実装させ、人がレビューする流れを扱います。研修後にも使えるよう、リポジトリに適用した設定と、チーム共通のレビュー基準を残します。教材やカリキュラムを社内だけで一から作る必要はありません。FIXIT が開発環境と課題を聞き取り、実際のコードやテスト・レビューの状況に合わせて研修内容を設計します。

WPF 開発を題材にする場合は、利用中の .NET、MVVM ライブラリ、Windows の検証環境を確認し、扱う範囲を相談します。たとえば本記事の入力画面なら、次の内容が練習の候補になります。

• 既存の設計と変更対象を AI に伝え、XAML と ViewModel の差分を作る。
• 入力値とコマンドの実行可否をテストし、Windows で確認する操作を決める。
• 生成差分と検証結果を別のメンバーがレビューし、未確認事項を記録する。

受講後に目指すのは、次の改修でもメンバーが共通の手順で AI に依頼し、確認結果を引き継げる状態です。相談時には、変更したい画面と、現在レビューで時間がかかっている箇所をお聞かせください。推進担当が不在の場合や、担当者が準備の時間を確保できない場合も、その状況からご相談いただけます。教材に使うコードの範囲も、事前に確認します。

まとめ｜まず 1 画面の変更で検証方法を確かめる

WPF 開発で AI を使う第一歩は、小さな画面変更に対して、既存の設計と合格条件を渡すことです。XAML と ViewModel の生成結果を読み、ビルド・単体テスト・Windows の画面確認まで一続きで確かめます。未実施の項目を残すことも、完了報告の一部です。

保守中のアプリなら、最初に対象フレームワーク、Windows、依存部品の一覧を作ってください。サポート期限と業務上の変更要求を分けると、実行環境の更新で足りるのか、画面刷新まで必要なのかを判断できます。

チームで取り組みたい方は、自社の WPF 開発を題材に、研修内容を相談する ところから始めてください。利用中の開発環境とチームの課題を基に、題材と研修で扱う範囲を一緒に整理します。