- それでも、WPFで“新しく作る”という選択
- 2025年仕様で再構築するWPF UIアーキテクチャ
- 実践設計──「2025年型WPFアプリ」を組み立てるリアル例
- WPFから世界へ──設計力を“ポートフォリオ言語”に翻訳する
- 🧭 まとめ：あなたのWPFは、“語れる設計”になっているか？
それでも、WPFで“新しく作る”という選択
「WPFアプリをこれから新規で作るんです」
そう言うと、驚かれることもある。
多くの開発者は「今さらWPF？」と疑問を投げかけてくるだろう。
でも、僕はこう思っている。
今だからこそ、**“WPFを知り尽くした目線で、今のユーザー体験に応える設計”**をもう一度やってみたい。
そして、その設計力を他のUI技術にも“持ち出せる武器”にしておきたい。
これは、過去に戻る話ではない。
WPFで再び“攻めるUI設計”を行うという、現在進行形の挑戦だ。
WPFは終わっていない。むしろ“熟し切った設計プラットフォーム”である
確かに、WPFは2006年に登場した歴史あるフレームワークだ。
だが、それはバグもノウハウも洗い出され、UI設計の理論が一巡した状態とも言える。
- 変化しないAPI
- 豊富な実装例と実績
- 完全に理解されたMVVMパターン
- スタイリングとバインディングの高い自由度
これは、**業務アプリにおける最適な「設計訓練の場」**として、いまだに大きな価値を持っている。
2025年、WPFアプリを作るということ
WPFを取り巻く環境は変化している。
- .NET 8でのサポート継続（長期的視点での投資価値）
- Visual StudioによるXAMLツール群の強化
- MAUIやBlazorでは扱いにくい複雑な業務UIへの適性
- クライアントアプリのパフォーマンス／オフライン要件の回帰
そして何より、「社内業務アプリケーション」の世界では、WPFは今でも“堅実で信頼されている選択肢”なのだ。
なぜ「今、WPFアプリを新規で設計する」のか？
僕が2025年に入り、あえてWPFアプリを“再設計”しはじめた理由は、以下の3つだった。
① UI設計の基礎力を再確認したかった
ReactやMAUIでは、“コンポーネントを組み合わせる”感覚が強く、設計全体を考える機会が減ってしまう。
一方WPFは、レイヤー分離、状態管理、バインディング、アニメーション、ビヘイビアの設計など、UIの全要素を自分で設計できる。
だからこそ、自分の設計力を“解像度高く”見直せるフレームワークだった。
② 他のUI技術への“設計移植力”を鍛えたかった
WPFでしっかりと設計してみると、それをそのままReactやBlazorに持ち込むことができる。
たとえば：
| WPFの設計経験 | ReactやMAUIでの応用 |
|---|---|
| ViewModelの状態分離 | useState/useReducer構成の最適化 |
| コンポーネントとバインディング分離 | props/drillを避けた構造化設計 |
| ValidationRuleとCommand | フォームバリデーションの抽象化 |
これはWPFが“古い”のではなく、“抽象化された設計思考の原点”を持っているからこそできること。
③ 「設計力」をグローバルで語れるようにしたかった
WPFは、まだまだ海外企業でも使われている。
だが、技術名だけではなく、「UI設計ができる人材」だと伝えるには、何をどう設計してきたかを説明できる必要がある。
それを鍛えるには、設計そのものに深く向き合う必要があった。
“今、WPFで作る”ために再定義した設計要件
2025年の今、WPFアプリを新規に設計するにあたって、僕は次の要件を掲げた。
- レスポンシブ性：単なる解像度対応ではなく、情報密度に応じてUI構成を変化させる設計
- ユニットテストしやすい構造：ViewModelとロジックの完全分離とモック注入
- テーマ・スキン変更の柔軟性：ブランドごとのルック＆フィール切替
- コンポーネントの再利用性：1つの画面だけで終わらない構造と責務の分離
- UI/UXレビューに耐える構成：社内外のデザイナー・PMにも共有しやすい構造と命名規則
これらを満たすことで、「実務性」と「ポートフォリオ性」を両立したアプリに仕立てられる。
2025年仕様で再構築するWPF UIアーキテクチャ
今どきWPFで使うべき設計パターンはこれだ
WPFといえばMVVMパターン。
でも、2025年のUI開発には“純粋なMVVM”だけでは不足している。
理由は明確で、現代のアプリは：
- コンポーネント化の粒度が細かい（再利用性重視）
- 状態が非同期かつ複雑（REST, SignalR, IoT対応）
- UX要件が高度（アニメーション、マルチスキン、アクセシビリティ）
これに応えるために、WPFでは以下の進化系パターンやアーキテクチャ技法を取り入れる必要がある。
🔹 1. “Composable MVVM”：部品単位で設計を完結させる
従来のMVVMは、1画面＝1ViewModelの構成が多かった。
でも、今は**「UIの再利用」が価値を生む時代**。
✅ 実装例：
- 各セクション（例：ヘッダー、サイドメニュー、フォームエリア）を
UserControl + PartialViewModelとして独立管理 - 依存関係をDIで注入し、親子ViewModelの密結合を避ける
- サブコンポーネントもテスト可能にするため、
ICommandやINotifyPropertyChangedを徹底
設計ポイント：
FormSectionViewModelやDialogViewModelを量産できると、UIは“組み合わせ設計”で回る- ユニットテストも部品単位ででき、CI/CDも強くなる
🔹 2. “State-Driven UI”：状態を中心に組み立てる
MVVMでもっとも見落とされがちなのが状態設計。
- 単純なプロパティのOn/Offではなく、**状態の遷移モデル（State Machine）**を意識
enum + state contextやRecord型で、状態変化を明確に追える設計へ
✅ 例：
public enum FormState
{
Idle,
Editing,
Saving,
Error
}
public record FormStatus(FormState CurrentState, string? ErrorMessage);
UIはこの
FormStatusをバインディングし、状態ごとの表示・アクション制御を担う。
🔹 3. “Design-Time First”：設計から始める実装戦略
今どきのWPF開発では、“コードを書く前に設計する”のが勝ちパターン。
✅ 実践ポイント：
DesignTimeData.jsonやDesignTimeViewModelで、Figmaなしでも仮UIを設計DataContextにモックデータを差し込むことで、XAMLデザインとViewModelの整合を高める- デザイナーツール（Blend, VS Designer）での「見た目→設計逆算」が可能に
XAMLの“レスポンシブ設計”はここまでできる
Webほどではないが、WPFにもレスポンシブ対応の知恵と工夫はある。
✅ 対応戦略：
| 要素 | 対応方法 |
|---|---|
| ウィンドウサイズ変更 | ViewBox, GridLength="Auto, *", VisualStateManager |
| 解像度に応じたレイアウト切り替え | DataTrigger + ActualWidthで表示構成の変更 |
| DPI対応 | .NET Core WPF 以降は自動対応、UI要素の最小サイズを意識 |
✅ コード例：
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="WindowStates">
<VisualState x:Name="Narrow">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="500"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="Sidebar.Visibility" Value="Collapsed"/>
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
ユニットテストしやすいWPF ViewModel設計の3原則
- 依存注入を前提にViewModelを作る
- HttpClient、NavigationServiceなどはすべてインタフェースで注入
- コンストラクタの責務を限定
- UI状態を“切り出す”
FormState,IsBusy,IsError,StatusMessageなどは専用クラスにまとめてバインドすることで、テストもしやすくなる
- ビヘイビアはCommandに閉じ込める
- UIイベントの処理はすべて
ICommand内に集約し、トリガーから独立させる
- UIイベントの処理はすべて
UXアニメーションも、設計の一部にする
WPFにはStoryboardやTrigger、VisualStateManagerがあり、UX向上のための表現がまだまだ有効。
- 遅延表示（フェードイン）：ユーザーの注意を誘導
- エラー入力フィードバック：一瞬のシェイクで誤入力に気づかせる
- ローディングインジケータの制御：
IsBusy状態に連動
✅ UXアニメーションの設計方針
<Storyboard x:Key="FadeInStoryboard">
<DoubleAnimation Storyboard.TargetProperty="Opacity"
From="0" To="1" Duration="0:0:0.3" />
</Storyboard>
“UIの反応”は設計項目である。ユーザー体験をガイドする設計に組み込むべき。
設計の粒度をコントロールする：UI設計レビューの観点
最後に、チームで設計レビューをする前提でのUI設計についても触れておきたい。
✅ レビューで共有すべき資料
- UIコンポーネント構成図（XAMLツリー図）
- 状態遷移チャート（主要ViewModel単位）
- DataTemplate構成一覧（再利用可視化）
- バインディングマップ（どのViewがどのVMプロパティに依存しているか）
これを揃えることで、WPFは「属人技術」から「再利用可能な設計資産」へと昇華する。
実践設計──「2025年型WPFアプリ」を組み立てるリアル例
UI設計を“分解”から始める：プロジェクト構成の骨格
まず僕は、従来の“1画面＝1ファイル”のような構造ではなく、責務単位の分割からUIを設計し直した。
✅ ディレクトリ構成（抜粋）：
📂 MyApp.UI
├── Views
│ ├── DashboardView.xaml
│ ├── UserFormView.xaml
│ └── Components
│ ├── SearchBox.xaml
│ └── Sidebar.xaml
├── ViewModels
│ ├── DashboardViewModel.cs
│ ├── UserFormViewModel.cs
│ └── Components
│ ├── SearchBoxViewModel.cs
│ └── SidebarViewModel.cs
├── Models
│ └── UserModel.cs
├── States
│ ├── UserFormState.cs
│ └── UIFlowState.cs
🎯 ポイント：
ComponentsフォルダでUI部品を明確に区切る- 各 ViewModel が状態 (
Stateクラス) を扱い、UIの構成と動的振る舞いを分離 - DI コンテナ（SimpleInjector など）を使って ViewModel 間の依存を注入管理
状態とUIの“二層モデル”を明示する設計
従来のWPFでは、bool IsBusy や string ErrorMessage を ViewModel にベタ書きしていた。
しかし、それでは状態が散らばり、UXの整合性が保てない。
✅ 新しいアプローチ：
public record UserFormState(
bool IsBusy,
bool HasError,
string? ErrorMessage,
string CurrentStep
);
ViewModel側ではこの状態をラップし、INotifyPropertyChanged として UI に渡す。
public class UserFormViewModel : ViewModelBase
{
public UserFormState State { get; private set; }
public async Task SubmitAsync()
{
State = State with { IsBusy = true };
// 処理...
State = State with { IsBusy = false };
}
}
🎯 効果：
- 状態の変更履歴が追いやすくなる（DIでMockしやすい）
- UIの条件分岐が単純になる（DataTriggerやVisualStateManagerとの相性◎）
UI反応性と再利用性の両立：部品設計のキモ
WPFの柔軟なバインディングと XAML 構成力を使えば、「再利用できるUI」が可能。
ここでは、よくある“検索ボックス”を例に設計してみた。
✅ SearchBoxView.xaml（部品）
<TextBox Text="{Binding Query, UpdateSourceTrigger=PropertyChanged}" />
<Button Content="Search" Command="{Binding SearchCommand}" />
✅ SearchBoxViewModel.cs
public class SearchBoxViewModel
{
public string Query { get; set; }
public ICommand SearchCommand { get; }
public SearchBoxViewModel(ISearchService service) { ... }
}
このように、UI要素と責務（検索）の分離を徹底しておけば、ダッシュボードにも、ユーザーフォームにも流用可能。
実装しながら“学び直す”：設計レビューで得た発見
このアプリは、ポートフォリオ兼業務効率化用に社内でも共有され、コードレビューを英語で受ける機会も多かった。
そこで得たのが、“設計の意図を明示すること”の重要性だった。
例）海外エンジニアからのレビュー：
“Why did you separate the UI state into its own record? It seems verbose.”
これに対して僕はこう答えた：
“Because we expect state transitions to grow as the form evolves.
Using a record structure allows us to manage state immutably and consistently.”
結果、「なるほど、それは堅実な設計判断だ」と評価された。
テスト可能性とCI/CD：ViewModelの自動テスト戦略
このWPF設計のもう1つの柱がテストファースト。
✅ テスト対象：
- ユーザー操作 → 状態変化（State更新）
- 非同期処理後のエラーハンドリング
- 状態に応じたコマンド有効/無効の切替
✅ テスト例（NUnit + Moq）：
[Test]
public async Task SubmitAsync_ShouldSetIsBusyToTrue()
{
var vm = new UserFormViewModel(MockService());
await vm.SubmitAsync();
Assert.IsFalse(vm.State.IsBusy);
}
🎯 効果：
- UI操作の裏側にある設計判断を明文化できる
- 海外チームでも自動テストのレビューがしやすい
UI設計の再学習を促す「設計辞書」のすすめ
僕はこのプロジェクトを通じて、“設計の選択”をすべてNotionで記録した。
| 機能 | 設計意図 | 選択した手法 |
|---|---|---|
| 入力フォームの検証 | Viewとの責務分離 | IDataErrorInfo + Service層 |
| 多段階フォーム構造 | ステップごとの状態明示 | FormStep enum + State Object |
| 非同期エラーハンドリング | UI操作中の混乱防止 | CommandLocking + LoadingOverlay |
🎯 こうした記録があることで：
- 面接での「なぜこの設計にしたか？」に即答できる
- 他フレームワーク（MAUI, Blazor）に設計を移植しやすい
WPFはもう古くない。「設計練習の最強フィールド」だ
今のWPFは、“技術名としての旬”は過ぎているかもしれない。
でも、設計力・UI構造・状態管理の実践場としては、最適解に近い。
- View層とロジックの分離
- 状態を意識したUXの設計
- 再利用可能な部品構造の実装
- それを英語で語る力をつける
WPFを使ってこれらを身につけたことは、どんなモダンUI技術にも応用できると、実感している。
WPFから世界へ──設計力を“ポートフォリオ言語”に翻訳する
WPF経験を“英語で価値に変える”視点を持つ
WPFアプリを今あらためて設計・構築することの意味は、
「ただアプリを完成させること」ではない。
それは、設計の引き出しを整理し、構造化して、英語で語れる形に変える訓練でもある。
なぜか？
UIアーキテクチャは、どんな国でも通じる“技術思想”の共通言語だからだ。
たとえば、以下のように英語で明快に説明できるかどうかで、あなたの設計力は“ローカルスキル”から“グローバルスキル”へと進化する。
✅ Before：ただの機能紹介
“This app has a user registration form with input validation and search features.”
✅ After：設計意図が伝わる説明
“This WPF application showcases form design with isolated validation logic, reusable components, and centralized UI state control — a structure easily portable to MAUI or React environments.”
この違いは、設計を語れるか否かだ。
UI設計を英語ポートフォリオに落とし込む方法
📁 GitHub構成の工夫
📂 MyWpfPortfolioApp
├── README.md
├── Architecture.md
├── Components/
│ ├── SearchBox/
│ └── StepForm/
├── States/
├── ViewModels/
├── Tests/
└── Docs/
├── DesignDecisions.md
└── StateDiagram.png
📄 README.md の例
# WPF Portfolio App – UI Architecture Showcase
This project demonstrates my approach to UI design and architecture using WPF in 2025.
The focus is on:
- Component-based MVVM architecture
- Explicit state modeling
- Testable ViewModels with injected services
- Responsive layout using XAML techniques
- UX enhancements via animation and transitions
### Target Scenario
A user management system with a step-based registration form, stateful interactions, and component reuse.
### Architecture Highlights
- Form state modeled as immutable record (FormState.cs)
- SearchBox as an independent, testable MVVM component
- XAML-based visual state transitions for dynamic UX
- State-first design enabling test coverage before UI implementation
英語面接・プロフィールでの“伝え方テンプレ”
設計の良し悪しを直接問われるケースは少ないが、「その設計判断、なぜそうしたの？」という質問は必ずくる。
以下は、そうしたときに使える説明テンプレート：
🔹 状態管理の説明
“I structured UI logic around explicit state models using record types.
This helped reduce complexity and made unit testing more predictable.”
🔹 再利用部品の説明
“I built independent components like SearchBoxViewModel with injected services,
which can be reused across different views with minimal modification.”
🔹 UI/UX設計の説明
“I used VisualStateManager and animation storyboards for user guidance,
ensuring the interface provides clear feedback and transitions.”
🔹 設計レビューでのスタンス
“Each design decision is documented and tied to a user scenario or scalability requirement.
I also welcome async peer reviews to validate architectural choices.”
「次世代UI」への設計橋渡し
このWPFアプリは、単なるゴールではなく、**他技術へと繋がる“設計の出発点”**でもある。
💡 MAUIに展開すると…
- ViewModelはほぼそのまま移植可能（DI、状態設計も同様）
- XAMLのスタイルは異なるが、Visual State や Command バインディングは引き継げる
- アニメーションは MAUI の
VisualStateManagerで類似の構成に
💡 Reactに応用すると…
useReducerによる状態遷移管理が FormState 設計と一致- コンポーネント分割の考え方が共通（責務分離・再利用志向）
custom hook= ViewModel 的な設計パターンを再現可能
つまり、**WPFの設計力は、技術を超えて“持ち運べる武器”**になる。
最後に：WPF設計を再定義する３つの問い
このVol.7で描いてきたように、今あらためてWPFアプリを作ることで、僕自身のUI設計力は以下の問いで再定義された。
① なぜその設計にしたのか？
→ 意図を説明できることが、設計者の証明になる。
② 状態はどこにあり、どう変化するのか？
→ UIの振る舞いを説明するために、状態モデルが必要だ。
③ この設計は他の技術でも通じるか？
→ “再利用できる構造”こそが、キャリアを支える資産になる。
🧭 まとめ：あなたのWPFは、“語れる設計”になっているか？
- 技術名だけではなく、「設計の工夫」「選定理由」「構造の工夫」を言語化しよう
- WPFだからこそ実現できる“全方位的UI設計”を、ポートフォリオに残そう
- それを英語で話す練習を通じて、“設計アーキテクト”としての視座を持とう
コメント