ロバストに繋ぐ、WindowsアプリのAIコーディング - 質を上げる工夫色々

ロバストに繋ぐ、 WindowsアプリのAIコーディング - 質を上げる工夫色々 2026/1/21 須藤（suusanex）

自己紹介  ID：suusanex（ connpass・X・GitHub・Zennなど共通）  名前：須藤圭太  サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属 o  自社製品開発・継続保守する製品開発を12年ほど・受託開発は5年ほど 小規模開発チームでPM・プログラマ・プラットフォームエンジニア・テック リード的な事まで何でもやってます o C#・Windows開発がメインでC++もいける o Windowsアプリ開発のネタが多い  Developer Technologies .NETでMicrosoft MVPを受賞しました  C# Tokyoコミュニティでイベント開催

• https://csharp-tokyo.connpass.com/

Windowsアプリ開発でも、 ガンガンAIコーディングチャレンジ  「AIコーディング」はGitHub＋Webアプリ開発向けのもの・・・ではない  オンプレ環境でのWindowsアプリ開発でも使っていける o （インターネットなし環境などは別として）  色々コツはあるが、 Windowsアプリ開発向けの情報が少ない  使ってみて効果があったものを 紹介していきます。  このセッションでは浅く広く  深い話はQiitaブログ等で書いていく予定です  興味あれば覗いてみてください！

• https://qiita.com/spc_ksudoh

経験から見つけた重要ポイント  E2E（エンドツーエンド）の処理が揃っていることを、ド キュメントとテストコードで保証させる  1，E2Eテストコードで、処理接続漏れを防ぐ  プロセス間通信もカバーする例を紹介  2，ドキュメントで、やることを一貫させる  spec-kitのドキュメントを、もっとロバストに  色々テクニック集

ポイント1:E2Eテストコードで、処理接 続漏れを防ぐ

ポイント1:E2Eテストコードで、処理接 続漏れを防ぐ   o AIは放っておいても多少はテストコードを書くが、たいてい不十分 o メソッド1つのテストなど、危なそうなところのバグ有無のテストがメイン o それはそれで必要だが・・・ AIコーディングで重要なのはバグ有無よりも、「全ての実装が揃っているか」 o ロジックはあるが画面に繋がってない o サーバー・クライアント型で片方のコードが無い・繋がってない o などなど、人間視点であり得ない欠けが普通に起きる これをテストコードで潰すには、そういうテストを指示するべき o o 画面からファイルまで、クライアントからサーバーまで・・・つまりE2Eのテスト 一つの工夫を紹介（次ページ

プロセス間通信をスタブでシーケンス通 過させるテストコード  プロセス間通信が入ると、だいたいAIは見落とす  Windowsサービスを使うようなアプリではプロセス間通信は珍しくない  どうする？ こういう全体のシーケンスをAIに作らせたい

E2Eのテストプロジェクト を作る   テストプロジェクトを手動で作っておく  両方をテストプロジェクトから参照  プロセス間通信部をスタブで直接呼び出しに  関数呼び出し関係があるのでAIが追いやすい 簡単な説明ドキュメントも用意しておく  AIへのコーディング指示に含める  これがあることがAIに伝わるので、利用され やすくなる

ポイント2: ドキュメントで、やることを 一貫させる  AIのコンテキストだけでは全体像を保持しきれないし、次回には忘れている  一貫して使ってほしい全体像は、メモリではなくファイルへ、ドキュメントを 書かせた方がいい  その工夫の一つで割とメジャーなのが spec-kit さらに、 PlanとTasksの間を 埋める工夫も！

spec-kitの基本を軽く  一連のフェーズでドキュメント・ソースコードを書かせるInstruction集  Spec:必須のゴールとなる要求仕様を書く  Clarify:Specの曖昧な点を見つけて埋める  Plan:実現のための具体的な仕様を書く（フレームワーク等もここ）  Tasks:Planを、実装の具体的なタスク一覧に落とす  Analyze:Spec～Tasksの対応付けに漏れ・矛盾・曖昧などがないかチェック   Implementation:Tasksに従って実装する 一見良い感じだが、PlanとTasksの隙間が問題を起こしやすい

spec-kitでは足りない隙間  普通に作ったplanだけで実装すると、シーケンスの実装欠けが多くなりがち o Windowsアプリで多発 o 「画面がない」「プロセス間通信の処理が繋がっていない」など  ドキュメントを見ると、PlanとTasksの間の空白が広すぎる  Plan:実現したい機能が書かれている  Tasks:クラス名やファイル名のレベルで箇条書きされている  全体的な処理の流れが読み取れない！  このまま実装すると、コーディング時のコンテキストだけで、全体の処理の流 れを設計する o LLMでそこまでやると、見落としが出がち

隙間を埋めてロバストにする  Plan:ユースケース（文章）  Tasks:詳細クラス・メソッド  この2つの間の解釈余地が広すぎる（弱い、ロバストではない）  これを埋めるには？  ICONIXプロセスでいうところの、「ロバストネス分析」が足りない

参考:ICONIXプロセスのロバストネス分析  ユースケース（文章）を、「AがBをCする」という図に変えていく過程で、文 章の曖昧さを潰す  Actor,Boundary,Entityという境界の名前を一意に決めて  繋がり(Control)を文章と図の両面からレビュー 文章: ユーザーが ログイン画 面でログイ ン操作をす ると、認証 情 報・・・・ ・・

AI向けのロバストネス分析  AIには文章+図よりも、用語+シーケンスの方がたぶん分かりやすい  独自定義をグダグダ説明するより、「GOF的に」のように既知の単語が良い  ↓  「arc42 Runtime View × C4」で、粒度粗めの全体シーケンスを書かせる  arc42 Runtime Viewは、シーケンス図で何を書くかの枠に使える ▪  （元々は、主要シナリオの"実行時の相互作用"を書くもの） C4は、システムの用語にどの粒度で名前を付けるかの枠に使える ▪ （元々は、複数段階の抽象度で名前を分けるもの）  これらの用語で、書かせたい粒度がピタリと伝わる  Planに対してそういうドキュメントを書くという指示を書いて、PlanとTasksの 間に実行  spec-kitの形式に合わせて、Instructions, Agentsを作成しておくと使いやすい

AIが作成したドキュメントの一例

上手く回すための小さな工夫がたくさん  他にも工夫はたくさんある  ありすぎて説明しきれないので、概要だけ

モデル使い分け  GitHub Copilotでは、Claude系のモデルと、GPT系（Codex系）のモデル、どち らも使える  以下、スライド作成時点での感触（個人差があると思います）  環境が整ってないプロジェクトのピンチヒッターはClaude系優位   自走しやすいように整えたプロジェクトではGPT系   考えは広いが浅く、抜けや矛盾もけっこう出る 狭いが深く、考慮漏れが少ない 組み合わせて使うのもけっこうアリ、例えば  まず1から全体を作るspec,plan,tasksなどはClaude系  分析して漏れを埋めるclarify,analyze,今回紹介したロバストなドキュメント等はGPT 系

VC++混在のビルドやテストを確実に実行 する  Windowsアプリだと、VC++混在ソリューション等で、.NETで完結出来ない問題 も多い  dotnet buildが使えず、msbuildのパスが通ってないので探して右往左往する  dotnet testを使おうとしてVC++のエラーでコケる  ビルドやテストのやり方を、リポジトリ内のInstructionsファイルに書いておく と良い  Agent.Skillsだともっと良い  見つけてくれない場合があるが、スキル名をプロンプトに書けばたいてい使う

VS Codeの（Copilot Chatの） auto-approve  VSCodeではデフォルトだと、コマンド実行の度に確認を求めてくる  安全だが、自走させたい時は不便  VSCodeの chat.tools.terminal.autoApprove 設定をプロジェクトに合わせて作 ると良い  正規表現指定で、自動許可して良いコマンドを決める  正規表現なので、同じ目的のコマンドを色々な書き方で打たれると上手く行かない 難点有り  別ページのmsbuildのように、決まったコマンドの打ち方をInstructions, Agent.Skills 等に書いて、autoApproveと組み合わせると良い

日本語の文字化けや英語混在問題のTIPS  GitHub Copilotの回答が急に英語になったり韓国語になったりする  ↓  VS Code の設定 github.copilot.chat.localeOverride でロケールを日本語固定 o ある程度解決する（確実に日本語固定を約束する設定ではない）  GitHub Copilotが使っているPowerShellで日本語文字化けエラー  ↓  PowerShellのプロファイルに、コンソールのエンコード設定を追加

worktreeで複数AIエージェントの併走  ローカルのファイルを直接編集するので、複数エージェント併走が難しい  git worktree が相性ピッタリ  worktree1つに付き1エージェントで働いてもらえば併走出来る  詳しくはブログ記事をどうぞ！  Copilot渋滞を解消：git worktree×複数VS Codeで"1人並列開発" #C# - Qiita

• https://qiita.com/spc_ksudoh/items/9868598d166b5045d54c

まとめ  Windowsアプリ開発で、GitHub Copilotを使ってAIコーディングをするのは、 十分に実用的  ただ、Webアプリほど環境が整備されておらず、色々工夫が必要でもある  どんどん使ってみて工夫して情報発信していくので、皆さんもぜひ使ってみま しょう！