概要
GitHub Copilotのエージェントモードが、Visual StudioでもGAして使えるようになりました。どんなことが出来るのかを知りたいのもあってちょっと触ってみたので、紹介します。出来上がった結果では無く、途中経過をいくつか抜き出して、どんな感じだったかが伝わるように書いてみます。
作成したのはC#のコンソールアプリです。
最初に結論まとめ
ポイントとしては次のような感じでした。
- 最初に仕様（ReadMe）を書いてという指示に対しては、それなりにちゃんとしたものが出てきて、書き換えたらちゃんとその後のコーディングに反映された
- 指示する側の理解度がふんわりしていると、ふんわりそれっぽいが全然動かないコードとか、ダミー実装のような役に立たないものが出てくる
- 理解して具体的に指示すれば、割と面倒な要求でもちゃんとしたコードを書いてくれる。レビュー指摘すればちゃんと指摘通りに直してくれる。
- バグ修正もできるが、これも指示する側が理解浅いまま「直して」と丸投げすると場当たり的な修正が返ってくる。理解して的確に指摘すればちゃんと直してくれる。
全体的な印象としては、あまりスキルの高くないメンバーに対して、細かく指示を出して結果をレビューしながら、課題をこなしてもらう。そういった作業と同じようなことをやっている感じです。
説明
GitHub Copilotのエージェントモードでどんなことが出来るのか。確実に知っている物を作るのではつまらないので、せっかくですから自分でも作ったことのない物をGitHub Copilotと共同開発してみました。結果から言うと、ちゃんと指示していけば動く物が出来上がりました。ではそれを紹介します・・・といっても、出来上がったコードだけを紹介してもエージェントモードの紹介にはなりません。
なので、どういう段階を踏んでコーディングしていったかが分かりやすいように、GitHubにログを残しました。入力したプロンプトとそれによって生成されたコードを、まとめてコミットする、というやり方です。
次のような感じです。コミットログが「エージェントモードでの変更」になっているところが、GitHub Copilotの仕事です。そのうち「PromptHistory.md」というファイルが、GitHub Copilotへ送ったプロンプトのログです。
つまり読み方としては、「PromptHistory.mdの差分にあるプロンプトを送ったら、それ以外の差分の変更をGitHub Copilotがやってくれたよ」ということになります。
これを使って、いくつかポイントを抜き出して紹介していきます。
まずReadMe（仕様）作成
まず最初に、ざっくりした要求内容を書いて、それを理解しているか確認するために、仕様書（ReadMe）を書いてもらうことにしました。次の結果です。
機能・非機能の一覧に構成図と技術スタックと、作ろうとしているものを判断するのに最低限必要なネタは揃っているように見えます。ざっとレビューしたところシーケンスがちょっとイメージと違っていて、データソース作成とチャットは分けて欲しかったので、そのようにReadMeを手動で書き換えました。次の差分です。これで、大きく違うものができることはないはずです。
初回のソースコード生成
それでは、ReadMeに従ってソースコードを作るように指示してみます。こんな感じになりました。
まず雛形としてはちゃんとしていそうです。このまま実装を進めてもらったところ、「”Embedding処理はダミーの物を入れる”とコメントして固定値を返している」とか「SharpVectorという同名の別のライブラリっぽい変なコードを書き始める」とか色々変なことを始めました。ReadMeの時点で、もう少し実現方式を掘り下げた方が良かったのかもしれません。とりあえず、その都度調べ物をしたりしながら指示を出していったら、だんだんそれっぽい実装になってきました。次のコミットにまとめて入れています。
しかしいっこうにビルドが通るものにならないので、書こうとしているコードを推測して手動で埋めました。次の程度の変更なので、たいした手間ではありません。
といったところで、とりあえずビルドが通る状態にはなりました。バイブコーディングとはよく言ったもので、指示する側が曖昧だと、やっぱり雰囲気それっぽい程度のコードにしかならないようです。とはいえ、ちゃんとその都度レビューしてコメントしていくことで、ちゃんと改善していきました。
具体的な指示で機能追加
反省して、もっと具体的な指示で機能を追加してもらうことにします。
コマンドライン引数で処理を分岐するようにしてもらいました。
ほぼ空っぽだったLLMとのチャット部分を実装してもらいました。コードを見る限り忘れられていそうだったので、「ベクトルDBの類似検索も実装して」という補足付きです。
どちらもけっこうちゃんとしたコードが出てきました。使えそうです。LLMの方はどこかのサンプルのパクリ臭いですが、まあそれでも動く物を調べて作ってくれるのは助かります。
プチ・リファクタリング
1ファイルに全クラス突っ込まれすぎて見通しが悪かったので、改善してもらいました。リファクタリングというほど複雑な物では無く指示も具体的に出したので成功して当然という感じではありますが、この作業を手動でやったらもっと時間がかかったと思うので、この程度の指示で作業をしてくれるのはやはり助かります。
都合上、コンストラクタで処理をせずに、別のInitializeメソッドで処理をするように変えてもらいました。これも、指示通りにちゃんとやってくれています。
バグ修正
実行したら例外が出たので、例外をそのまま「直して」と丸投げしてみました。ベストなやり方かどうかはともかく、ちゃんと例外を理解して直しているようです。
調子に乗ってガンガンと同じように丸投げしていったのですが・・・繰り返しても全然動くコードになりません。あまり知らない処理ですが、処置内容を見ていても場当たり的に雰囲気で修正しているだけに見えます。これは、やはり丸投げしているだけだとダメですね。
というわけでちょっと調べ物をして、サンプルに合わせて作り直してという指示に変えました。
まあまあそれっぽいコードは書いてくれたようですが、あちこちおかしいです。けっきょく手動で直しました。
つまり、例外内容を理解してそれを防ぐ修正をするといったことはやれているものの、問題解決に向かって直していくようなことは難しい雰囲気です。といっても、今回はそもそも指示する側が理解せずに丸投げしているのが悪いので、ちゃんと理解して指示を出せば上手く行ったかもしれません。
その他
めんどくさい処理
Markdownの分割方法について、だいぶめんどくさい指示を出していますが、内容が明確ならちゃんとやってくれるようです。
このように、やりたいアルゴリズムが明確にあるが、実装めんどくさい・・・という時にはとても頼りになりそうです。
プロンプトエンジニアリング（？）
何度か、特定モデルのLLMへ渡すプロンプト・パラメータの作成や改善を依頼してみましたが、毎回出てくる内容がバラバラで、LLMやその特定モデルの特性を理解している様子はありませんでした。LLMへのプロンプトはLLM自身に作らせると良いといった話も聞きますが、GitHub Copilotではその辺は上手く行かないようです。
他にも色々ありましたが、だいたいポイントは紹介したと思います。
まとめ
GitHub Copilotのエージェントモードは、指示する側がちゃんと理解してレビューして的確に指示を出せば、かなりちゃんと仕事をしてくれるようです。しかし知らないことを丸投げするには向いていないようです。
この辺りの特性をちゃんと分かって使えば、要フォローのメンバーが一人増えたくらいの働きはしてくれそうな印象です。使えるところではどんどん使っていきましょう！