🔧

ライブラリ開発にGitHub Copilotを使ってみて得られた知見

に公開
テーマ「GitHub Copilot 活用選手権」
GitHub
GitHub Copilot
agents
Skills
tech

はじめに

これは何

プライベートで開発しているライブラリにGitHub Copilotを導入して半年近く経ったので、得られた知見を雑多にまとめた記事です。

結論

忙しい人のための3行要約。

  • 多くの開発者が使い慣れているVSCodeと統合されていることから、初めてAIアシスタントを使う方にもおすすめできる
  • skills, agents, prompts…どれから整備すべきか迷ったらまずはpromptsから小さく整備し始めるのがおススメ
  • /reviewコマンドはデフォルトでも強力ですが、プロジェクト特有の知識が必要なら専用のエージェントを用意するとレビューの品質が上がる

特に目新しいことはありません。普通にエージェントを使っていたら「まあそうなるよな」くらいの知見です。

具体例

プライベートでHugoのテーマを作ったり、AlgoliaというSaaSに関連したライブラリを作っています。

いずれのプロジェクトでもcopilotを導入しており、実際の構成は以下の通りです（2026-04-29時点）。

/root
┣ .github/
┃  ┣ copilot-instructions.md
┃  ┣ prompts/ # ある時もあればないときもある
┃  ┣ agents/
┃  ┗ skills/
┗ docs/ # 人間向けのドキュメント

補足すると、copilot-instructions.mdはドキュメント類へのインデックスにしていて、たまに使うプロンプトとスキルを別々に用意しています（が、まだまだ整備しきれていないのが現状）。

最初から全部そろえようと思ったりもしましたが、「毎回同じことを説明している部分」だけを copilot-instructions.md やskillに抜き出し、必要に応じて分割していくところから始めました。

VSCode + Copilotで助かっているところ

  • 開発フローに自然に乗る

普段どおりVSCodeを開いたまま使えるのが想像以上に大きかったです。

  • 実装中にそのまま質問できる
  • 差分を見ながら修正案を依頼できる
  • テスト失敗時にエラー文脈を渡して原因切り分けできる

AIを使うための準備や、開発中の別ウィンドウへのコンテキストスイッチがほぼないので、チームでも個人でも開発しやすいなと思ってます。

  • ドキュメントがそのまま出力の品質に直結する

最初の1〜2週間は「ちょい便利」くらいでしたが、copilot-instructions.md を小さく整備し始めてから安定感が増しました。例としては次のようなものです。

  • 新機能追加時の観点を言われなくても理解している（新規の仕様、テスト観点、後方互換）

  • バグ修正時の観点を提案してくれる（再現手順、原因、再発防止）

  • リリース前チェックをやってくれる（タグ、ドキュメント整合など）

  • セルフレビューが格段に楽になる

/review だけでもかなり実用的ですが、プロジェクト特有の知識を追加すると精度がもう一段上がります。例えばHugoのテーマでは、以下のような知識を与えています。

  • スコープ外の作業が追加で行われていないかのチェック
  • フォルダ構成に見合った箇所にファイルが配置されているかのチェック

困っているところ

便利すぎて思考を省略しがち

コード生成だけでなく、なまじ設計判断までできてしまうので、適当に丸投げして痛い目にあいそうだなと思っています。

ありがちですが、特に会話が長くなると、以前却下したはずのアイディアを「良かれと思ってやっときました！」みたいな形で勝手に実装し始めることが何度かあり、これに気付かないとおかしな実装が含まれそうだなぁと思いました。

このあたりの対策はまだできていませんが、生成されたコードを採用する前に「この変更は今回のスコープ内か」「前回の指示から外れた実装が含まれていないか」のレビュワーをサブエージェントとして用意すべきだなと思っています（ほかにいい感じの対策があれば教えてください）。

ドキュメントの更新頻度

仕事でのチーム開発でもそうですが、どの情報をcopilot-instructions.mdなどのドキュメントに含めるかの基準が少し難しいですね。本来は以下のようなフローが必要ですが、まあ個人開発なんで面倒でやれてません。

  • 使わなくなったルールを削除する
  • 実際の開発フローに合うように簡潔化する
  • 失敗事例を反映して改善する

ここも今後対策したいなと思っていますが、上記フローで定期的（ただし頻度が高くなり過ぎないよう）にチェックするエージェントを用意したいなと思っています。

その他

promptsから始めるのがおすすめな理由

skills/agentsは強力ですが、最初から触るとドキュメント作成コストが高いです(/create-系のコマンドで作成が楽になっていはいますが)。

一方でpromptsは、各単純作業をテンプレート化するだけで即効性があるので、まずはここからおススメしたいです(特に/create-promptコマンドがおススメ)。

  • 導入が簡単
  • 効果検証がしやすい
  • （個人開発だとあまりないですが）チームに共有しやすい

そのため、個人的には次の順序がしっくり来ました。

  1. よく使う作業のpromptsを徐々に加える
  2. 定期的に使って、重複・不要項目を削る
  3. ある程度安定して使えそうになってきたらskills/agentsに変換する（not必須）

/review 専用エージェントは「後から」で十分

最初から専用エージェントを作るより、まずは通常の /review でどんな指摘が欲しいかを徐々に明確にしていくのが良いかなと思います。

（仕事ではやったりしてますが）以下のような情報をまとめてルール化すると、専用エージェントの品質が上がりやすくなります。

  • どの指摘が役に立ったか
  • どの指摘がノイズだったか
  • どの観点が不足していたか

まとめ・蛇足

GitHub Copilotのようなツールに限らずですが、最初から完璧を目指さず、小さく始めて継続するのが一番効果的だと思います。

なんだかんだ整備の第一歩はpromptsかなと思ったりしています。ここが一番費用対効果が高いと思いました。意外とデフォルトの/reviewコマンドが割と強力でした。

次はとあるVSCodeの拡張機能を作りたいなぁ～と思ってるので、そちらでも活用していきたいです。

Discussion