ホーム
BLOG
【AI】
【Gemini CLI】Windowsアプリ開発における…

【Gemini CLI】Windowsアプリ開発における共通ルールの検討

自己紹介
はじめに
AIコーディングの歴史
冒頭の分析
運用ルールの追求
さいごに

自己紹介

はじめまして、2025年9月からisubで働かせていただくことになりました、村松です。
エンジニア歴は4年ほどで、主にC#を用いてWindowsアプリ開発を行っていました。

高専時代は、制御学科でありながらC言語にのめり込んでしまい、1年生の時に5年生までの内容を学習していました。
また、学生ロボコンに参加しておりプログラム・回路などを担当していました。

最近はC言語からはめっきり遠のいて、仕事でも趣味でもC#のアプリ開発や、Pythonなどを学習しています。

はじめに

近年、AIを用いたコーディングが目覚ましい成長を遂げています。
しかし、それでも各AIシステムの理念に則った開発手法を用いないと効率的な開発はできません。

例えば、最近発表されたGoogle Julesのサービスを用いてWindowsアプリ開発を行ってみたのですが、あまり成果は良くありませんでした。

ではなぜそのようになってしまったのか、またWindowsアプリ開発に最適なAIツール選び・使いかたなどを検討していきます。

AIコーディングの歴史

私なりのAIコーディングの歴史を見ていきます。

チャット型

私が最初にAIを触り始めたのは、ChatGPTのGPT-3(2020年あたり)でした。
今の最新AIと比べると性能は格段に劣っていますが、使い方によっては業務で活かせるほどの性能はありました。

当時はコーディング面での活用はあまり本格化されておらず、チャットにコードを打ち込んで、返ってきたチャットをコードに書き写すような作業をしていました。

エディタ統合型

続いて2021年あたりから、コーディングエディタとAIを組み合わせたシステムが登場するようになってきました。
GitHub Copilot、Cursor、Windsurfなど…
これらは主に2つの機能があり、「コーディング補助」と「プロンプトによるコード生成」です。

コーディング補助は、変数名・関数名の考案や、後に続くコードのサジェスト(補完)などがあります。
プロンプトによるコード生成は、生成したいコード内容のプロンプトをAIに渡し、それに沿ったコードを自動生成するというものです。

これらのサービスが革新的だったのは、AIをエディタに直接組み込んだ点です。
これにより、今までのようにチャット画面とエディタを往復してコピー＆ペーストする手間がなくなり、開発効率が格段に向上しました。
また、どの行に追加すべきかなども考えてくれるため、人間の作業はプロンプト作成と内容の確認だけのように思われました。

しかし、それでもこれらのサービスには不十分な点もありました。
それはコードの整合性・動作検証は人間が行うということです。

生成してもらったコードがデタラメで、エラーが頻発した！という人も大勢居たでしょう。

自律駆動型

続いて出てきたサービスがAIの自律駆動です。
Cline、Devinなど…
これらはAIにコマンド実行権を渡すことで、新しいファイルの追加・削除から環境構築、コードの実行など様々なことができるようになりました。
また、コマンドを実行できるとともにその結果も取得できるため、「コードの作成→実行→エラー文の取得→それに伴う修正→…」や、「単体テストの作成→実行→失敗→単体テストの修正→…」など自律駆動的に自己改善を行うサイクルを作成できるようになりました。

もう完璧に見えますが欠点はまだあり、UIなどの結合テストを行うことができません。
「ボタンを押すとメッセージが表示される」ようなUIを作成しても、アプリの実行はしてくれますが、ボタンを押したり、メッセージが出るかなどの確認は行えません。

実行環境提供型

続いて出てきたのは、Web上などで開発が完結する実行環境を提供してくれるサービスです。
CodexやGoogle Julesなど…
ChatGPTやGeminiでもCanvas機能としてWebページはチャット上で実行できるようになりましたね。

これの良い点は、実行環境を用意する必要がないことであり、そして複製することが簡単ということです。
CodexやJulesなどのサービスは、タスクごとにブランチを分け作業するため同時並列的に開発することができます。
GitHubを用いているためコードのマージなどの機能を使うことができます。
そして実行環境も用意してくれているため単体テストを用いて自己改善的な開発も行っていくことができます。

これらの欠点としては、実行環境が限られるということです。
これらは主にWeb開発を目的としておりそれらの環境がそろっていますが、Windowsアプリ開発などの環境は整っていません。
なのでコード生成はできても、自己改善ができないということですね。

冒頭の分析

これらのことから冒頭のことを振り返ってみましょう。
「Julesの成果が良くなかった」と「最適なツールはどれか」ということでした。

まず「Julesの成果が良くなかった」点です。
これは上記で書いている通り、Windowsアプリの実行環境がないため、コードを生成できても実行できない・エラーも認識できない状態です。
なので、性能としては「ただのAIチャットに聞いただけ」になっているわけですね。

そうすると必然的に「Windowsアプリ開発に最適なツールはどれか」という問いには、ローカルの実行環境を利用できるエディタ統合型や自律駆動型となるわけですね。

運用ルールの追求

今回はGemini CLIを用いたWindowsアプリ開発を検討していきます。
Gemini CLIはClineよりも自律性が追求されているように感じました(ユーザーの操作を必要としない)。

そのまま使用することもできるのですが、Gemini CLIでは共通ルール(GEMINI.md)を課すことでAIの動作を指示できるので、より効率的な開発を行えるような条件を考えていきます。

単体テストを重視し、最終的なUIや結合テストの確認のみユーザーに任せる
こまめなコミットを行う
やることをちゃんと理解させておく

単体テストを重視する

やはり自律駆動してくれることを考えると人間がやるタスクは最小限にしたいものです。
なので基本的なプログラムの評価は単体テストで行うことにしましょう。
そうすればAI自身でプログラムがちゃんと動いているかを把握し、自己改善していけるようになります。
このサイクルが本当に強みなので！

しかし、完全に単体テストだけでは確認できないこともあります。
結合テストやUIのテストです。
これらは仕方がないので人間が対処しましょう。

それまでの段階すらも自動化したいので、ビルド→実行→起動までしてもらい、どのようにテストすればいいのかの要件も書いてもらうと楽です。

こまめなコミットを行う

AIに全任せで開発していると、たまに破壊的変更を行う場合があります。
これはUI開発であればもっと頻度が高いことでしょう(UIがぐちゃぐちゃになっている…)。

このような場合、変更前のプログラムに戻してもらいたいわけですが、AIはすべての内容を覚えているわけではありません。
なので「戻して」と指示しても「すみません」と言いながら新しいプログラムを書いてきます。

そこで、一旦開発していたことをリセットして、新たなプロンプトで開発し直すことで慎重な開発を促します。
そのリセットがコミットへの巻き戻しです。

このコミットの粒度は、上記の1サイクルごとに行うことがおすすめです。
単体テストが全て成功し、結合テストもクリアして次のタスクに移る前にコミットしてもらいましょう。
こうすることで常にクリーンな履歴を残しておくことができます。

「そんな頻繁にコミットするのは現場的なGitの使い方から異なる」という意見もあると思います。
しかし、私的にAIと付き合っていくにはこれくらいの姿勢が良いのかなと思いました。

やることを理解させておく

これは長期的にも、短期的にも有効な手段です。
こうすることでAIが暴走的な開発をすることを抑えます。

短期的には、今回のサイクルでどのような機能をどのように実装するのかをプラン建てします(Clineで言うPlanモード)。
それに対してユーザーが賛成か反対かのアクションをとり、サイクルが起動します。
プランから大きく外れる場合はまたユーザーアクションを求めても良いですね。

長期的には、各サイクルで何をやるべきかを決定するのに役立ちます。
AIにとっても有益であり、ユーザーにとっても何をしていくべきかが整理されているので開発が進むことでしょう。
やりたいことをつらつらと並べて、AIに要件定義書を作ってもらいましょう。

タスク管理は最近のAI開発での王道ですね。
人間にもAIにもいい点があります。

実際に使っていたルール

以下は私が実際にGemini CLIに課していたルールです。
上記のことを書いていったあと、「このことを共通ルール(Gemini.md)に追加してください」とお願いしました。

## 共通ルール
- **言語**: **日本語で話すこと。**
- **開発サイクル**:
    1.  **プラン作成**: 指示を受けたら、それに対してどのような行動を行っていくべきかプランを立てる。
    2.  **プラン確認**: 立てたプランをユーザーに伝え、賛成か反対かユーザーアクションを求める。
    3.  **開発**: ユーザーが賛成した場合、プランを実行していく。この際、**テスト駆動開発（TDD）を徹底する。**GUIアプリのデバッグは単体テストを駆動させることでのみ可能であることを常に念頭に置き、開発を進める。
    4.  **テスト**: プランの終盤工程（機能が完成した段階）では、必ずテストを行う。単体テストで十分な場合は単体テストを実施し、それだけでは把握できない場合はユーザーにGUIの確認（ビルドから実行までを自動で行い、アプリケーションが起動した状態でお渡しする）を求める。
    5.  **ログ作成**: テストが成功したら、開発ログを更新する。
    6.  **コミット**: 開発ログの更新後、Gitをコミットする。
- **徹底**: 上記のサイクルを**必ず徹底して守る。**
- **Git運用**:
    - **コミット**: 開発サイクルに従い、こまめにコミットを行う。
    - **ブランチ**:
        - 大きな機能開発を行う際は、機能ごとにブランチを作成する。
        - 機能開発が完了し、テストが成功したら、main（またはmaster）ブランチにマージする。