GitHub Copilotをかれこれ１年以上プログラミングに使っているが、その中で行き着いたオレ的イケてるCopilotの使い方を紹介してみようと思う。
要するに
既にコードが大量に存在する大規模PJに於いて、私達が実現したいこと（追加機能のシステム要求。例：僕のWebシステムのマイページに好きなアイコン画像が使えるようにしたい）をCopilot Chatに伝えつつコードを生成してもらう。CopilotのWorkspaceエージェントを使うと、既存のコード全体を解析した上で、それに見合う変更提案をしてくれるので超強い。ChatGPTやClaudeにはできない芸当。
動機
生成AIが登場したことで、システム要求を人間がちまちま要件・設計・実装に変換していく時代はそろそろ終焉かもしれない。というのはバズ狙いでひところ毎日のようにXでChatGPTやClaudeに驚愕していたAIプログラマーの皆さんのおっしゃるとおりだと思っている。が、彼らの紹介する方法が成り立つのはちょっとしたアイディアを実現してみる小規模PJやPoCでの話で、要はPJ全体をAIが記憶できる程度の規模、言い方を変えるとPJ全部をトークン変換してもChatGPTやClaudeのトークン数制限にらくらく収まる程度のPJでの話だと理解している。
然るに、大多数を占めるであろう現場のエンジニアが日々格闘しているプロジェクトはもっと巨大で、驚愕を生業とするエンジニアが想定するプロジェクトとは規模が全く異なる。でも私だって彼らと同じように驚愕したい。驚愕するためにはChatGPTのプロンプトに全ファイルをちまちまコピペして「で、どこをどう変更すればよい？」と聞くのが良いが、超絶面倒な上に文字数制限(トークン数制限)をOverする。が故に、どのファイルを変更すべきかは人間が判断して、具体的な変更作業でCopilotの力を借りることが多いが、そんなの驚愕とは言えない。ではどうすれば良いのだろうか？
前提
- 既に一定の量のソースコードが存在するプロジェクトで、新たにコードの追加やバグフィックスするシチュエーションを想定する。
- GitHub Copilotの導入方法や基本の使い方は他の記事をみてくれよな！この記事は脱初心者って人向けだ。
- VSCode
注釈
- この界隈は状況変化のスピードが速いので、記事執筆の時点（2024/8時点）ではイケてるかもしれないが、１ヶ月後はどうかわからないという点。特に、現在GitHubがTechnical Preview中のCopilot WorkspaceがGAしたら状況も一変するかもしれない。
やりかた
- Step 1
- Copilot ChatでWorkspaceエージェント（@workspace）を使ってCopilotに現状のコード全体をざっくり認識させつつ、
- 要求/要件（追加したい機能や解決したいバグの詳細）を伝えつつ、
- 変更すべきファイルを列挙してもらう。
- Step 2
- 引き続き@ workspaceを使いつつ、
- Copilotに列挙してもらったファイルを全てFileチャット変数（#file:xxx）で全てChatプロンプトに読み込ませつつ、
- 各ファイルをどう変更すればよいか聞く。
- （要求/要件はチャット履歴から読み込めるので再度伝えなくても大丈夫）
基本はこれだけ。2回目のCopilotの回答をファイルに貼り付ければOK。うまくハマる時は自分で全くコードを書かなくてもイケる。チャット２往復でALL OKになることは稀だが、エラーログや気に入らない点を再度Copilotに投げればだいたいなんとかしてくれる。
Key Points
- Workspaceエージェントを使うと既存のコード全体をなんか良い感じに解析してPromptに含めてくれる。解析対象はREADME、docsディレクトリ以下にあるコーディングルールや用語集、PJルートディレクトリ直下のLinter等の設定ファイル等、ディレクトリ構造、各ファイルの概要（細かいことはわかりません！）等、多岐に渡る。Codebaseチャット変数（#codebase）も似た効果を持つが、違いは不明。
- もちろんCopilotを全面的に信頼するのはNGなので、プログラマー側でコードレビューはした方がよい。
Tips
- より手堅く進めるならTest Driven Development (TDD)的なアプローチの方が良い。つまり、Step 2でいきなりソースを作成するのではなく、代わりにテストコードを作成し、Step 3でテストファイルを#file:で参照しつつソースコードを生成してもらう。すると、結構な精度でテストをPassするようにソースを考えてくれる。特にテストコードの妥当性は人間のチェックが必要。
- Copilot Chatパネルを使ったチャットだと、生成されたコードは人間がコピー＆ペーストしなければならず面倒。Macなら⌘+IでCopilotをコードエディタ上でダイレクトに起動でき、ここで生成される修正案はダイレクトにコードに反映されるので早い。ここではWorkspaceエージェントが使えないが、#codebaseと#file:xxxがあれば事足りるはず。なおWindowsのことは知らない。
- CopilotのCode Completion（コード補完）でも@workspace相当の情報をちょっと使っている、らしい。また、Completionでは現在開いているファイルやImport元ファイルを自動で読み込むらしいので、この仕組みをうまく使うことで、よりこちらの意図に沿った補完を実現してくれる。特にCompletionの精度はContextに左右されるので、Contextを意図して調整する作業が必要(参考：Qiita: GitHub Copilotを上手に活用するために知っておきたいこと)。
- 規模が小さいプロジェクトであれば@workspaceは、#file:xxxで全ファイルを列挙するのとほぼ同じとCopilot自身が言っていたので、その場合は１回のチャットで全て完結できる。
雑感１
多くの人が関わるPJで、初心者が要件・設計・実装を担ってもロクなことにならない。要求（例：カスタムのアイコン画像を使えるように改造したい！）だけ考えて、あとはAIに任せよう。AIの使い方だけマスターすればおｋ。という時代がもうすぐ来る。
雑感2
VSCodeに統合されたCopilotは@workspaceという魔法の一言で、なんか良い感じにプロジェクト全体をやんわり認識する（コードベース全体をRAGのナレッジベースとして使う機能だと私は理解している）。全ファイルを正確に読み込むわけではなく概要を抽出しているっぽいが、「こういうコトを実現したいんだけど、ざっくり既存のコードのどのあたりを変更すれば良さそう？」と聞く分には十分だ。この応答を元に、次のチャットで#file:xxxを使って対象ファイルを一言一句正確に読み込ませた上で、テストコードとソースコードを追記してもらうのである。
加えて、@workspaceや#codebaseはREADME等も読み込むので、MarkdownファイルにPJ概要や企画書、アーキテクチャ、コーディング規約、用語集などを整備しておけば、そいつらもよしなに解釈してくれる（画像やPDFを正しく解釈してくれるかは知らん）。もちろん、Linterの設定ファイルやGitHub ActionsのYAMLもだ。