👌

GitHub Copilot CLI でスキルを駆使していい感じのプログラムを書いてもらおう

Kazuki Ota

2026/04/18に公開

テーマ「GitHub Copilot 活用選手権」

はじめに

ここでは、GitHub Copilot CLI を使って、いい感じの WPF アプリケーションを作るための手順を書いていこうと思います。ゼロからのスタートで、GitHub Copilot CLI を使いながら、WPF アプリケーションを作っていく流れを紹介します。

なるべくやったことは省略せずに、どういう感じで私がやっているのかを感じ取ってもらう事を目的としています。各やり取りの概要を引用ブロックで紹介し、完全なログは各章の末尾にあるリンクから確認できるようにしています。

題材となるアプリは、簡単な在庫管理アプリを作ることにします。

GitHub Copilot CLI に追加しているもの

私の GitHub Copilot CLI には、以下のものを追加しています。
再現したい方は追加して試してみて下さい。

Microsoft Learn MCP サーバー
- Microsoft Learn のコンテンツを GitHub Copilot CLI から参照できるようにする MCP サーバーです。これは .NET で開発する上では必須です。何を差し置いても追加しましょう。
- https://learn.microsoft.com/ja-jp/training/support/mcp
Awesome GitHub Copilot Plugin
- 便利なスキルやエージェントなど色々なものが入っているリポジトリです。ここからスキルなどを検索するスキルなどがパッケージングされたプラグインがあるので、これを入れておきます。
- https://github.com/github/awesome-copilot/tree/main/plugins/awesome-copilot
Aspire CLI
- .NET 開発では最近必ず入れてます。起動が楽でログも見やすいので重宝しています。
- https://aspire.dev/
GitHub Copilot CLI で /experimental コマンドで実験的機能を有効化しています。これで Claude 系モデルがプランを立てた時に GPT-5.4 で自動レビューをするラバーダックが動くようになります。

001 プロジェクトのセットアップ

まずは、プロジェクトのセットアップから始めましょう。
といっても GitHub Copilot CLI にお願いをする形でつくっていきます。

copilot コマンドを実行して、GitHub Copilot CLI を起動します。
執筆時点の最新バージョンは v1.0.32 でした。最新版では少し機能が変わっていることもあると思いますが多分大体同じような感じで進められると思います。
モデルは Claude Sonnet 4.6 を選択します。モデルの選択は /model コマンドでいつでも変更可能です。

まずは、以下のお願いをしてリポジトリのセットアップをしてもらいます。

.NET 10 で WPF を作るための git リポジトリのセットアップをお願いします。git リポジトリ化と Visual Sutdio 用の gitignore を取得してください。

すると、GitHub Copilot CLI がリポジトリのセットアップをしてくれます。
いくつかのコマンドの実行やファイルのダウンロードなどを求めてくるので確認しながら進めていきましょう。
私の場合は以下のような会話になりました。

「.NET 10 で WPF を作るための git リポジトリのセットアップをお願いします」とお願いしたところ、GitHub Copilot CLI はまず git init でリポジトリを初期化し、次に GitHub の公式 gitignore リポジトリから Visual Studio 用の .gitignore をダウンロードしてきてくれました。.vs/、bin/、obj/ などの Visual Studio / .NET 開発で不要なファイルを除外する設定が入っている .gitignore を自動で取得して、そのまま初回コミットまでやってくれています。

このように、GitHub Copilot CLI がリポジトリの初期化から .gitignore の取得、コミットまで自動でやってくれました。

このセッションの完全なログは 001-setup.md で確認できます。

002 Awesome GitHub Copilot から Skill をインストール

/new をして新しいセッションに切り替えます。
個人的には、なるべく1つのセッションは短くするようにしています。セッションが長くなりすぎると、モデルが前の会話を忘れてしまうことがあるからです。こっちは覚えてると思っていても忘れるような動きをすると制御が難しいので、絶対に知らないといけないことは各種 instructios や skills に入れておいて、毎回セッションを切り替えるようにしています。
セッションを切り替えたら、次は Agent や Skill を仕込んでいきます。

Awesome GitHub Copilot の Plugin を入れておくと、色々な便利な Agent や Skill を簡単に検索して追加することができます。
まずは、C# の開発に便利な Skill をいくつか追加します。

/awesome-copilot:suggest-awesome-github-copilot-skills C#, WPF 開発に有用な SKILL を探して

GitHub Copilot CLI とのやり取りの概要は以下の通りです。

Awesome GitHub Copilot のリポジトリを検索して、C# / WPF 開発に関連するスキルを 14 件ピックアップしてテーブル形式で見せてくれました。各スキルについて「何に役立つか」の推奨理由もちゃんと書いてくれています。例えば csharp-async は「WPF は UI スレッド管理が重要だから async/await パターンの徹底に有用」、dotnet-design-pattern-review は「MVVM パターン実装の品質向上に直接有用」といった具合です。

最終的に特に推奨として dotnet-best-practices、dotnet-design-pattern-review、csharp-async、csharp-xunit の 4 つを挙げて「インストールしたいスキルを指定してください」と聞いてくれました。

提案されたものが良さそうだったので以下のようにお願いして Skill をインストールしました。

推奨 skill のインストールをしてください

やり取りの概要です。

4 つのスキル（dotnet-best-practices、dotnet-design-pattern-review、csharp-async、csharp-xunit）の SKILL.md を Awesome GitHub Copilot のリポジトリから並行して取得してくれました。.github/skills/ 配下にそれぞれのディレクトリを作成し、SKILL.md を配置した上で git コミットまで一気にやってくれています。最後にインストール済みスキルの一覧テーブルを表示して完了を報告してくれました。

skill の一覧を見ていると NuGet Manager の skill もあったので、これも入れておきましょう。

nuget-manager も追加して

やり取りの概要です。

先ほどと同じ流れで、nuget-manager の SKILL.md を取得してディレクトリ作成・配置・コミットまで一括でやってくれました。これで NuGet パッケージの管理ルールが Copilot に注入されるようになります。

最後に、最近は .NET での開発は脳死で Aspire を入れているので Aspire のスキルも入れます。なので Aspire のスキルも入れてもらうように促します。

aspire の skill 無い？

やり取りの概要です。

先ほどの検索結果に含まれていたことを教えてくれました。aspire スキルは SKILL.md だけでなく references フォルダに 9 つの参考ファイル（cli-reference.md、mcp-server.md、architecture.md など）が付属しているため、全部まとめてインストールするか確認してくれました。

承認すると、SKILL.md と 9 つの references ファイルを並行で取得し、.github/skills/aspire/ 配下にツリー構造で配置してコミットしてくれました。最後にこれまでにインストールした全 6 スキルの一覧テーブルも表示してくれています。

これで Awesome GitHub Copilot から、C# / WPF 開発に便利な Skill をいくつかインストールすることができました。

このセッションの完全なログは 002-skill.md で確認できます。

003 独自 Skill の作成

ということで、また /new をして新しいセッションに切り替えます。
次は、今回のプロジェクト専用の Skill を作ってみましょう。まずは、.NET 10 の知識を補うための Skill を作ります。AI は少し古い知識で止まっていることが多いので、最新の .NET 10 の情報を入れてあげると、より適切なコード提案をしてくれるようになります。

一旦、以下のようにお願いしてみます。

MS Learn を調べて .NET 10 + C# で WPF アプリ開発をする際の Agents Skill を作りたいです。                              
目的は .NET 10 に関する知識は AI が持っていないため、AIが古い知識に従って古い書き方をしてしまうことを防ぐことです。AI 
向けなので絵文字やアスキーアートなどの冗長な表現は避けて簡潔に dotnet-10 という名前の skill を作ってください。

絵文字やアスキーアートは、特に指定しないと AI は書きがちなので明示的に使うなとお願いしてみました。

GitHub Copilot CLI とのやり取りの概要は以下の通りです。

MS Learn の MCP サーバーを使って.NET 10 の新機能、C# 14 の新機能、WPF for .NET 10 の変更点をそれぞれ調査した上で、既存の SKILL.md のフォーマットも確認してから .github/skills/dotnet-10/SKILL.md（147 行）を作成してくれました。内容としては、net10.0-windows のターゲットフレームワーク設定、C# 14 の field キーワードや extension members などの新構文、WPF の Grid インライン構文や新しい MessageBox API、さらに AI が古い書き方をしないための禁止事項と推奨事項がまとまっています。

実際に生成された SKILL.md の冒頭はこんな感じです。全 146 行のうちの一部抜粋になります。

.github/skills/dotnet-10/SKILL.md

---
name: dotnet-10
description: "Provides up-to-date knowledge about .NET 10 and C# 14 for WPF application development. Use this skill when developing WPF apps targeting .NET 10, or when asked about .NET 10 / C# 14 features."
---

# .NET 10 + C# 14 WPF Development Reference

.NET 10 is an LTS release (released November 2025, supported for 3 years). The paired language version is C# 14. The required tooling is .NET 10 SDK and Visual Studio 2026.

## Project Setup

Target framework: `net10.0-windows`

```xml
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>
```

<!-- ... C# 14 / WPF for .NET 10 の解説が続きます ... -->

このセッションの完全なログは 003-custom-skill.md で確認できます。

004 設計指針の作成

次は、設計指針を作りましょう。コードを書く前に、このプロジェクトではどのような方針でコードを書くのか決めておくと AI が書くコードがぶれにくくなります。特に、WPF は MVVM パターンで書くことが多いので、MVVM の設計指針を作ってみましょう。

また、モジューラーモノリス + クリーンアーキテクチャで作るように指示をすると、いい感じにレイヤー分割されたコードを提案してくれるようになります。プロジェクトも機能単位 + レイヤー単位で分割されるようになるので AI がコードを変更する際にも関連コードを把握しやすくなります。

/new をして新しいセッションに切り替えたら、以下のようにお願いしてみます。

このプロジェクトでは .NET 10 C# + WPF の  MVVM (MVVM Toolkit を使用) パターンでアプリを作成します。                                                         
クリーンアーキテクチャーで作成を行います。さらにモジュラーモノリスで作成します。モジュールごとにクリーンアーキテクチャーに従うようにプロジェクトを作ります。
この設計指針を書いた skill を作りたいので手伝ってください。

一発で完璧な指示をするのは難しいので AI と一緒に相談しながら作ろうと思います。

GitHub Copilot CLI とのやり取りの概要は以下の通りです。

まず既存のスキル（dotnet-best-practices、dotnet-10、csharp-xunit）のフォーマットを読み込んでスキルの書き方を把握した上で、wpf-clean-architecture-mvvm というスキルを 292 行で作成してくれました。内容としては、ソリューション構成（AppHost / Shared.Kernel / モジュールごとの 4 層）、モジュール間の参照禁止ルール、Domain / Application / Infrastructure / Presentation 各層の責務、MVVM Toolkit のコード規約（ObservableObject 継承、[ObservableProperty]、[RelayCommand]）、依存方向のルールなどが含まれています。

MVVM Toolkit が最新情報を参照しているか怪しいと感じたのと、Aspire を使うようにしたいので、その観点について調べて改善するようにお願いをしました。SKILL.md を目視で確認して、AI が古い情報を参照している可能性があると感じたら、最新の情報を参照するように促すといいと思います。

Aspire を使いたいので、その場合の情報にアップデートしてください。MVVM Toolkit を使うのはいいのですが、Aspire 
と含めて最新情報になっているか確認をして必要があればアップデートしてください。

途中で間違えてキャンセルしてしまったので「続けて」とお願いしています…。

やり取りの概要です。

Web 検索と MS Learn の両方を使ってWPF + Aspire の統合方法を調査してくれました。.NET MAUI の Aspire 統合ドキュメントや WPF での Generic Host の使い方なども参照しています。調査結果を基に SKILL.md を更新し、ソリューション構成を WpfApp + AspireAppHost + ServiceDefaults に分離する形に変更してくれました。WpfApp のホスト方式も Host.CreateApplicationBuilder() + AddServiceDefaults() を使う方式に刷新され、Aspire 統合セクション（OpenTelemetry・サービスディスカバリ・Resilience の一括設定）が新設されています。

いいですね。最後に、今回は UI もモジュール単位で作ってエントリーポイント内では最低限のつなぎのコードだけにしたいので、その方針も入れてもらうようにしましょう。

モジュラーモノリスの方針を UI にも拡大したいです。各モジュールで UI                                                                                               
部品も作成して、それをエントリーポイントのプロジェクトで必要最低限の繋ぎのコードだけを置くような構成にしたいと思っています。このような構成についてどう思いますか？

ちょっと、自信がなかったので AI に意見を求めています。

やり取りの概要は以下の通りです。

「良い方針だと思います」と賛同した上で、メリット（モジュールの独立性が完結する、WpfApp が薄くなる、チーム分割しやすい）と考慮すべき点（シェルとモジュール UI の繋ぎ方、共有 UI リソースの置き場所、デザイン時サポート）を整理してくれました。シェルとモジュールの繋ぎ方として Prism RegionManager と軽量カスタムシェルの 2 つを比較した上で、MVVM Toolkit を使っているなら Prism に依存しない軽量カスタムシェルの方が良いと判断してくれています。具体的な構成イメージとして、WpfApp（Shell のみ）、Shared.Kernel（ドメインプリミティブ、UI 非依存）、Shared.UI（共通スタイル・IModule・IShellService）、各モジュールの Presentation 層という構成を提案してくれました。

AI もこの方針は良いと思っているようなので、これでスキルを更新してもらうようにしましょう。

スキルを更新してください。IModule や IShellService についての設計も含めてください。

具体的な設計は、きっと将来的にぶれると思うのですが、一旦 SKILL に入れてもらって、必要に応じて更新していくようにしたいと思います。

やり取りの概要は以下の通りです。

まず既存の SKILL.md（436 行）を全文読み込んで全体を把握してから更新に着手してくれました。途中でマッチエラーが発生する場面もありましたが、該当箇所を何度か読み直して整合性を確認しながら修正を進めてくれています。更新内容としては、Shared.UI プロジェクトの新設（IModule・IShellService・NavigationItem の定義場所）、IModule インターフェース（Name と Initialize のみのシンプル設計）、IShellService インターフェース（RegisterNavigationItem、NavigateTo、CurrentViewKey）の設計、そして WpfApp の起動フロー（全 IModule を DI から取得して Initialize を順に呼ぶだけ）が追加されています。

SKILL.md を確認すると 600 行を超えていたのでちょっと長すぎるかなと思います。内容を整理して、もう少し簡潔にするか必ずしも必要のない情報は別ファイルに分割したいと思います。そのため、以下のようにお願いしてみます。

SKILL.md が長くなってきました。冗長な表現になっている箇所はシンプルにするのと、必ずしも必要がないコードスニペットやドキュメントは別ファイルに切り出して参照する形にした
いと思っています。候補があれば提案してください。

やり取りの概要は以下の通りです。

SKILL.md の全体（480 行超）を分割して読み込んで内容を分析した結果、コードスニペット（shell-pattern.md）、プロジェクト設定（project-settings.md）、Aspire 統合パターン（aspire-integration.md）の 3 ファイルに切り出す候補を提案してくれました。SKILL.md 本体はキーワードと参照リンクだけに絞り込む方針です。

では、この提案を受け入れましょう。

この方針でお願いします。

やり取りの概要です。

references/ ディレクトリを作成し、shell-pattern.md・aspire-integration.md・project-settings.md の 3 ファイルに内容を切り出してくれました。SKILL.md 本体は 480 行超から 149 行にスリム化され、各参照ファイルの用途を示すテーブルも追加されています。

最終的に出来上がったソリューション構成の部分はこんな感じになりました。

.github/skills/wpf-clean-architecture-mvvm/SKILL.md

## ソリューション構成

```
src/
  AspireAppHost/          # Aspire オーケストレーター（バックエンドインフラ管理）
  ServiceDefaults/        # OpenTelemetry・サービスディスカバリの共通設定
  WpfApp/                 # WPF シェル（最小限のグルーコードのみ）
  Shared/
    Shared.Kernel/        # ドメインプリミティブ（WPF 非依存）
    Shared.UI/            # UI プリミティブ（IModule・IShellService・共通スタイル）
  Modules/
    {ModuleName}/
      {ModuleName}.Domain/
      {ModuleName}.Application/
      {ModuleName}.Infrastructure/
      {ModuleName}.Presentation/   # Views・ViewModels・IModule 実装
tests/
  {ModuleName}.{Layer}.Tests/
```

これで SKILL.md がいい感じになりました。一旦これで設計指針は完成にします。使ってみて不具合があれば都度調整したいと思います。

このセッションの完全なログは 004-architecture.md で確認できます。

005 開発フローの整理

ナレッジとアーキテクチャーが整ってきたので、開発フローを組みたいと思います。これも GitHub Copilot CLI を使って作っていきます。以下のようにお願いしてみます。

Agent が主体的に開発するフローを組みたいと思います。                                                                                    
仕様策定(SPEC)→レビュー→開発(製品コード＋ユニットテスト)→レビューを、それぞれの専門性を持った Agent で行いたいと思います。              
開発フローは Orchestrator エージェントが管理を行いサブエージェントとして個別のエージェントを呼び出す形にしたいです。SKILL, Custom Agent 
を使って、このフローを定義したいと思います。どのような構成がお勧めですか？

GitHub Copilot CLI とのやり取りの概要は以下の通りです。

まずリポジトリの構成と既存スキルを確認してから、Orchestrator を中心に spec-review・build-test・code-review・git-commit の 4 スキルで構成する開発フローを提案してくれました。各ステップがどのような順序で実行されるかの具体的なイメージも示してくれています。

extension を提案されたけどよく知らない
機能ですね…。今回は AI に全体の流れも管理してほしいので、そこもエージェントにしてほしいというお願いをします。

汎用オーケストレーターエージェントを作りたいです。SKILL                                                         
でフローを定義するとオーケストレーターエージェントが各エージェントを起動してフローを進めてくれる形にしたいです。

やり取りの概要は以下の通りです。

実装に入る前にラバーダックエージェントにプランをレビューさせたところ、デッドロックの可能性を指摘されたので修正しています。その後、extension.mjs（オーケストレーター本体）を実装し、spec-review・build-test・code-review・git-commit・my-flow の 5 つの SKILL.md を並列で作成してくれました。

実際に生成された dev-flow スキルのフロー概要とフロー定義の冒頭はこんな感じです。

.github/skills/dev-flow/SKILL.md

## フロー概要

```
[要件] → spec-writer → spec-reviewer → developer → code-reviewer → [完成]
                ↑______________|                ↑__________________|
                   差し戻し(最大3回)                差し戻し(最大3回)
```

フローの中身は JSON で定義されていて、各フェーズに担当スキルやプロンプトを紐づける形になっています。

.github/skills/dev-flow/SKILL.md

{
  "name": "ソフトウェア開発フロー",
  "phases": [
    {
      "id": "spec",
      "name": "仕様策定",
      "skill": "spec-writer",
      "prompt": "以下の要件に基づいて、詳細な機能仕様書を作成してください。\n\n## 要件\n\n{requirement}",
      "output_file": "spec.md"
    }
    // ... spec-review / implementation / code-review が続きます ...
  ]
}

ただ、extension を使う方針になってますね…。あと各種エージェントもスキルになってる…大丈夫かな…。ここには履歴は載せませんが GitHub Copilot に聞いてみたら恐らく大丈夫そうなので今回はこれで行こうと思います。

実際には、GitHub との連携やブランチ戦略や仕様の書き方なども考慮したルールにする必要がありますが、それも Awesome GitHub Copilot で探したりカスタムで作ったりと同じような手順で作っていくことが出来ます。自分たちの開発の流れに会う形に整理してあげるといいと思います。私は、この他に現在の状態のスナップショットを表すドキュメントも作っておくような手順やエージェントなども作っておいたりしています。さらにレビュー系エージェントは GPT 系のモデルにするといったこともしています。

また、今回は気にしていませんが AI が実装前に作る仕様書は凄く細かいので後で見直しても得るものが少ないです。なので、AI の作る詳細仕様書は、あんまり保持してても後で見返さないことが多いと思っています。そのため永続化するドキュメントは現在のスナップショットを表す全体俯瞰をするようなドキュメントや、重要な意思決定のみに絞った方がいいと思います。

ここら辺のチューニングは実際にやってみて、必要に応じて調整していくのがいいと思います。AI も完璧ではないので、実際にやってみてうまくいかないところを見つけて改善していくのがいいと思います。

このセッションの完全なログは 005-devflow.md で確認できます。

006 copilot-instructions.md を作る

最後に、GitHub Copilot がこのプロジェクトの開発に参加する際のガイドラインをまとめた copilot-instructions.md を作成したいと思います。これも GitHub Copilot CLI を使って作っていきましょう。/new でセッションをクリアして copilot-instructions.md を作成してもらいます。

やり取りの概要は以下の通りです。

リポジトリの構成と全スキルを確認した上で、シンプルさを重視した 16 行の copilot-instructions.md を作成してくれました。スキルとエージェントの一覧やプロジェクト構成の概要が簡潔にまとまっています。

実際に生成された copilot-instructions.md の全文はこんな感じです。とてもシンプルですね。

.github/copilot-instructions.md

# Copilot Instructions

## プロジェクト概要

在庫管理 WPF デスクトップアプリケーション。

## アーキテクチャ

.NET 10 + WPF + MVVM Toolkit + クリーンアーキテクチャ + モジュラーモノリス + .NET Aspire。
詳細は `wpf-clean-architecture-mvvm` スキルを参照。

## 開発フロー

機能追加・変更は必ず `dev-flow` スキルを通して行う：
仕様策定 → 仕様レビュー → 実装 → コードレビュー

これで下準備完了です！コードを書いてもらいましょう。

このセッションの完全なログは 006-copilot-instructions.md で確認できます。

007 基盤となるコードを書く

では、さっそく土台となるコードを書いてもらいます。まずは業務的な色はあまり含めずに基本となる土台を作ってもらいます。念のため copilot-instructions.md や skill などを確実に読み込んでもらうために再起動をした後に以下のようにお願いします。

/dev-flow 在庫管理システムの土台となる WPF のエントリーポイントアプリと全体共通で使う機能の実装をしてください。

このように話しかけると dev-flow スキルが起動して複数のエージェントが連携しながら仕様やコードを作ってくれます。恐らく数十分程度かかると思うのでコーヒーを飲んだり、筋トレをしたり各々好きなように待つことになります。
大まかな流れとしては spec-writer エージェントがコードを書くための仕様書を作成し、spec-reviewer エージェントがそれをレビューします。承認されたら developer エージェントがコードを書き、code-reviewer エージェントがコードをレビューするという流れになります。

やり取りの概要は以下の通りです。

dev-flow を起動すると、まず仕様レビューフェーズで spec-writer と spec-reviewer の間で 4 回の差し戻しと修正が繰り返されました。仕様が承認された後、実装フェーズで WPF のエントリーポイントと全体共通で使う機能のコードが生成されています。ビルド成功・12 テスト通過を確認した後、コードレビューで APPROVED_WITH_MINORS を受けてそのままコミットまで完了しました。

生成された WPF アプリの起動コードはこんな感じです。Generic Host を立ち上げて、DI コンテナから全 IModule を取得して順に Initialize を呼ぶシンプルな構成になっています。

src/WpfApp/App.xaml.cs

private async void Application_Startup(object sender, StartupEventArgs e)
{
    var builder = Host.CreateApplicationBuilder();
    builder.AddServiceDefaults();

    // Shell
    builder.Services.AddSingleton<ShellService>();
    builder.Services.AddSingleton<IShellService>(sp => sp.GetRequiredService<ShellService>());
    builder.Services.AddSingleton<MainWindowViewModel>();
    builder.Services.AddSingleton<MainWindow>();

    // Modules
    builder.Services.AddSharedInfrastructure();
    builder.Services.AddInventoryModule();

    _host = builder.Build();
    await _host.StartAsync();

    var shell = _host.Services.GetRequiredService<IShellService>();
    foreach (var module in _host.Services.GetServices<IModule>())
    {
        module.Initialize(shell);
    }

    // ... ナビゲーション初期化と MainWindow 表示 ...
}

モジュールとシェルの繋ぎ役になる IModule と IShellService も、それぞれ最小限のインターフェースとして生成されています。

src/Shared/Shared.UI/IModule.cs

namespace Shared.UI;

public interface IModule
{
    string Name { get; }
    void Initialize(IShellService shell);
}

src/Shared/Shared.UI/IShellService.cs

namespace Shared.UI;

public interface IShellService
{
    IReadOnlyList<NavigationItem> NavigationItems { get; }
    void RegisterNavigationItem(NavigationItem item);
    void NavigateTo(string viewKey);
    IObservable<string> CurrentViewKey { get; }
}

コードを眺めてみると、Aspire の AppHost から WPF アプリが起動できない形になっていました。

var builder = DistributedApplication.CreateBuilder(args);

builder.Build().Run();

これを以下のように修正してもらいました。

WPF アプリが AppHost から起動できるようにしてください。

そうすると自動でプランモードに入って修正方針を立ててから実装してくれました。

やり取りの概要です。

AppHost のプロジェクト構成を確認した上で、WpfApp への ProjectReference の追加と起動設定の修正を行い、ビルドが成功することを確認してからコミットまで完了してくれました。

修正後の AppHost.cs はこんな感じになりました。WpfApp プロジェクトを Aspire に登録するだけのシンプルな差分です。

src/AspireAppHost/AppHost.cs

var builder = DistributedApplication.CreateBuilder(args);

builder.AddProject<Projects.WpfApp>("wpfapp");

builder.Build().Run();

ここまでやると、空の Window と Aspire のダッシュボードが表示されるようになりました。
今回はやりませんが、ここに Web API とかが足されたケースでもいい感じに対応できます。

このセッションの完全なログは 007-dev-infra.md で確認できます。

008 機能を追加する

では、実際に機能を追加してみましょう。今回は在庫管理システムの土台を作るということで、まずは在庫管理のドメインモデルと基本的な CRUD 操作を実装してみたいと思います。
まずは、以下のように話しかけてみます。

/dev-flow 在庫管理ドメインのモデルと基本的な CRUD 操作を実装してください。

そうすると、また同じように複数のエージェントが連携しながら仕様やコードを作ってくれます。

やり取りの概要は以下の通りです。

dev-flow を起動すると、仕様レビューフェーズで 3 回の差し戻しと修正が繰り返された後、実装フェーズに進みました。合計 108 回のツール呼び出しを経て在庫管理ドメインモデルと基本的な CRUD 操作が実装されています。68 テスト通過を確認した後、コードレビューで APPROVED を受けてコミットまで完了しました。

生成されたドメインモデルはこんな感じです。値オブジェクト（Sku、Quantity、Money）を使ってきっちりと型付けされていて、いい感じの設計になっています。

src/Inventory/Inventory.Domain/InventoryItem.cs

public sealed class InventoryItem : AggregateRoot<InventoryItemId>
{
    public string Name { get; private set; } = string.Empty;
    public Sku Sku { get; private set; } = null!;
    public Quantity Quantity { get; private set; } = null!;
    public string Unit { get; private set; } = string.Empty;
    public Money UnitPrice { get; private set; } = null!;
    public string Category { get; private set; } = string.Empty;
    public string? Description { get; private set; }
    public string? Location { get; private set; }
    public Quantity MinimumStockLevel { get; private set; } = null!;
    public DateTime CreatedAt { get; private set; }
    public DateTime UpdatedAt { get; private set; }

    private InventoryItem() { }

    // ... Register / Update / AdjustStock / Delete などのファクトリ・メソッドが続きます ...
}

そして、Inventory モジュールの IModule 実装はこんな感じになりました。シェルにナビゲーション項目を登録するだけのシンプルな実装で、設計指針通りに WpfApp 側にビジネス知識が漏れない構造になっています。

src/Inventory/Inventory.Presentation/InventoryModule.cs

using Inventory.Presentation.ViewModels;
using Inventory.Presentation.Views;
using Microsoft.Extensions.DependencyInjection;
using Shared.UI;

namespace Inventory.Presentation;

public sealed class InventoryModule : IModule
{
    public string Name => "在庫管理";

    public void Initialize(IShellService shell)
    {
        shell.RegisterNavigationItem(new NavigationItem(
            Key: "inventory",
            Title: "在庫管理",
            IconPath: null,
            ViewFactory: sp => new InventoryListView(
                sp.GetRequiredService<InventoryListViewModel>())));
    }
}

実行すると、以下のように在庫管理画面が実装されています。

動かしてみたところ、更新機能が動かなかったりとバグがあったりするのですが、私が投入した命令数からするとしっかりできているのではないかと思います。
プロジェクト構造も綺麗です。ちゃんと分割して作られていますね。

このセッションの完全なログは 008-add-feature.md で確認できます。

ポイント

ということで、後は「〇〇機能を追加して」みたいな感じでどんどん機能を追加していくことができます。実際の開発では、データ構造の設計や、画面の設計なども入ると思います。さらに、一発で AI が出したものが OK になることも少ないと思いますが、かなり正解に近いものを AI が自発的に連携しながら作ることで、かなりの工数削減になるのではないかと思います。
ここにバグ修正やリファクタリングなども入ってくると思いますが、そういったタスクも同様の流れで対応可能です。

まとめ

今回は、GitHub Copilot CLI を使って、SKILL を活用した開発のフローの組み方から、実際のコード実装までの一連の流れを紹介しました。これくらいの労力で自分向けの開発用のワークフローを作れるようになるということを感じ取っていただければ思います。このワークフローは全然完璧じゃないです。例えば、今使っている範囲内でもレビューワーへの依頼の際に、要約ドキュメントを渡してレビューさせたりするというポンコツな動作をするところもあるので、確実に全文を渡すように指示する改善も必要だと思っています。

Web アプリの場合は Playwright CLI の公式 Skill を入れて e2e test で実装した機能がちゃんと動くか確認してもらうような仕組みも簡単に作れます。少なくとも起動してちょっと触っただけで表面化するようなバグを自動で検出するようなことも人間が介在せずにできるようになります。

これまで私は、AI をオーケストレーションして開発をするということに主軸を置いていたのですが AI のオーケストレーションも AI で出来るので、自分の考えた（自分たちのチームの実情にフィットした）ワークフローを自分で作れるようになるということが、AI を活用する上で非常に重要なポイントになってくるのではないかと思います。ぜひ皆さんも自分のプロジェクトに合わせたワークフローを作ってみてください。

※ でも、もしかしたら数か月後には、そういうワークフローも AI が勝手に作ってくれるようになっているかもしれませんね…。

今回のコードや SKILL やチャットの履歴は全て GitHub リポジトリに上げていますので、興味のある方はぜひ見てみてください。

sessions フォルダーに GitHub Copilot CLI のチャット履歴を /share file で保存したものを格納しています。

Microsoft (有志)Publication

メンバーが選んだMicrosoft製品の最新技術情報・知見をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

はじめに

GitHub Copilot CLI に追加しているもの

001 プロジェクトのセットアップ

002 Awesome GitHub Copilot から Skill をインストール

003 独自 Skill の作成

004 設計指針の作成

005 開発フローの整理

006 copilot-instructions.md を作る

007 基盤となるコードを書く

008 機能を追加する

ポイント

まとめ

Discussion