はじめに
前回は、Windowsアプリ開発におけるGemini CLIの共通ルールの検討を行いました。
そこで今回は、実際にそのルールを用いてアプリ開発を行っていきます。
私はいつもWindows Formsでアプリ開発を行っているのですが、今回は学習も兼ねてWPFで構築してみることにしました。
WPF基礎学習
今回にあたりWPFを基礎から学習したのですが、そこで参考になったサイトを紹介します。
参考にしたサイトはいくつかありましたが、一番分かりやすかったのは以下のPDF資料でした。
WPFの機能が体系的に紹介されており、それでいて初心者向けにプロジェクトの構築から丁寧に説明してくれています。
MVVMのような設計思想については紹介されていませんが、これはMVVMがWPFの機能そのものではなく、あくまで設計パターンの一つだからでしょう。
そのため、純粋にWPFの機能を基礎から学びたいときに、とても役立つ資料だと思います。
要件定義
それでは、実際にアプリ開発を行っていきます。
まず最初に行ったのは要件定義です。
これが前回触れた、長期的なタスク設計ですね。
機能を追加していくにあたって、次に何をすればいいかを明確にする目的があります。
と言っても、きっちりとした資料を作成する必要はなく、必要な機能を大まかに考えてGemini CLIに清書してもらいました。
それでは、この要件定義に従って実装を進めてもらいます。
所感
早速ですが、実装が完了しました。
基本的な機能として、タイトル・著者・読書状態・評価・感想などを本ごとに保存・管理できるようにしました。
また、ISBNコードを入力するとGoogle Books APIからタイトルや著者の情報を取得する機能も実装しています。
所感としては、やはりGemini CLIは非常に優秀だと感じました。
制作中はまだWPFを学習中の段階で右も左も分からない状態でしたが、それでもアプリケーションを完成させることができました。
コミット数も9回ほどで済みました。
しかし、使ってみて分かった難点もいくつかありました。
自走性が高すぎるあまり、プランを提案してきたかと思えば、こちらの返事を待たずに実装を始めてしまったのには思わず笑ってしまいました。
また、コンテキストを使い過ぎると、モデルがGemini 2.5 ProからGemini 2.5 Flashに切り替わってしまうようです。
そうなると、事前に設定した共通ルールが守られなくなったり、コーディング能力が低下したりと、少し使いづらい印象を受けました。
コーディング能力が低下するとバグが発生しやすくなり、さらにそのバグを自己修正する能力も低いため、無限ループに陥ってしまうことがあります。
今回の開発では、SQLの単体テストで特に躓いていました。
テストの開始時と終了時に適切にデータベースの処理を行うだけで解決する問題だったのですが、なかなか問題の本質を見抜けず見当違いな修正を繰り返していました。
このように融通が利かない場面では、より細かな制御が可能なClineの方が適しているのかもしれませんね。
コード内容
それでは、実装されたコードの内容をいくつか見ていきましょう。
UI設計にはMVVMパターンが取り入れられており、その証拠にViewのコードビハインド（MainWindow.xaml.cs）には、コードが書かれていませんでした。
今回のModelは本の情報に相当します。ViewModelがその本の情報をUIで表示しやすい形に加工し、Viewがそれを画面に表示するという役割分担ですね。
ViewModelのプロパティとViewのUI要素がデータバインディングによって疎結合になっているため、UIに依存しない形でViewModelの単体テストがしやすくなっています。
ちなみに、Visual Studioの標準機能では、XAMLでのバインディングは「参照の検索」でヒットしないため、少し不便ですね。
データベースにはSQLiteが採用されていました。
将来的に別のデータベースへも切り替えられるように、依存性の注入（DI）の考え方に基づいた設計になっていました。
この仕組みは、単体テスト時にデータベース接続をモックに差し替える際にも活用できるため、合理的な設計ですね。
単体テストのフレームワークには、Visual Studio標準のMSTestが採用されていました。
個人的にはNUnitなども気になりますが、MSTestはテストの初期化・クリーンアップ処理を属性で簡潔に記述できるのが便利ですね。
単体テストは、ViewModel、データベースアクセス、Google Books API連携の3つが作成されていました。
今回、特に勉強になったのは、本のコレクションを単なる配列やListではなく、ObservableCollectionで定義していた点です。
私はこのクラスの存在を知らなかったのですが、これはコレクション内の項目が追加・削除された際に、自動的に変更通知イベントを発行してくれる仕組みのようです。
これにより、ViewModelのコレクションを変更するだけでUIが自動的に更新されるため、UI更新のコードを自分で記述する必要がなくなり、非常に簡潔ですね。
さいごに
今回は慣れないWPFでのアプリケーション開発に挑戦してみました。
そして、WPFはWinFormsに比べてAIと対話しながら開発を進めやすいフレームワークだと感じました。
WinFormsのUI変更は、デザイナーファイルで管理されるオブジェクトの親子関係が複雑に絡み合っており、AIがコードベースで構造を修正するのは困難な作業でした。
一方、WPFではUIの構造がXAMLの宣言的な構文で記述されるため構造が一目瞭然で、AIにとっても扱いやすいようです。
また、MVVMパターンを導入しやすく、そして従来のデータバインディング方式も残っているのも大きなメリットです。
私も今後趣味でWindowsアプリを開発する際には、WinFormsからWPFへ本格的に乗り換えようかと考えています。
投稿者プロフィール
最新の投稿
【AI】2025年12月26日RAG改良手法の学習
Python2025年12月25日StreamlitでRAGを作ってみた
Python2025年12月23日Pythonを学習するにあたってやったこと- 未分類2025年11月28日『Webを支える技術』を読んだ学び
