blog.monotalk.xyz日々の書き込み

GitHub Copilotを2週間程度使ったふりかえり

Cover Image for GitHub Copilotを2週間程度使ったふりかえり
monotalk
monotalk

GitHub Copilotを使用して思うこと:YWT形式でのふりかえり

私はNotion AIを2023年から2024年度まで個人契約していましたが、2025年2月からはGitHub Copilotの個人契約に切り替えました。契約してからは惰性で触っていたのですが、仕事でも本格的に利用することになりそうで、直近2週間程度、GitHub Copilotをそれなりに触っていました。
使用感や、使用して分かったこと、今後実施してみたいことを、YWT形式でまとめてみようと思います。
※YWT自体もGitHub Copilotの提案を参考に編集してまとめました。


前提情報

以下、前提となりそうな情報を記載します。

なぜ、Notion AIからGitHub Copilotに切り替えたのか?

一言でいうと、自分のユースケースにはGitHub Copilotのほうがあっていそうだからです。
Notion AIは以下の点が便利だとは感じていました。

  • 【😊】Webの記事のリーディングリストを作るとカスタムAIで要約や、タグ付けを自動でしてくれて、記事の整理に便利
  • 【😊】文章作成は強い(GitHub Copilotとの比較)
  • 【😊】くだらない質問にも答えてくれる(GitHub Copilotとの比較)
  • 【😊】Q&Aでワークスペースの文書検索ができる
  • 【😊】プログラムの生成や、プログラムのレビューにも使える(何もないよりかなりマシ)

Notion AIの利用で逆に不便に感じていた点は以下になります。

  • 【💀】2025年3月時点では、複数の文書を利用してAIを利用することができない。
  • 【💀】ツールがないとMarkdown化するのにひと手間かかる。
  • 【💀】プログラム生成、プログラムのレビューに特化した生成AIではない。
  • 【💀】VS Codeからの利用が難しい。

個人的に、ブログと個人開発でVS Codeを利用しており、VS Codeと相性が良さそうな、GitHub Copilotを利用してみたかったというのが切り替えた理由となります。

利用期間

2025年3月17日〜2025年3月30日で利用した使用感になります。

YWT形式でのふりかえり

やったこと(Y)

  • Next.jsのブログの機能拡張
    • このブログのインクリメンタルサーチをGitHub Copilotを利用して作成
  • 異なるLLMモデル(Claude 3.7 Sonnet Thinking、GPT-4oなど)の切り替え試行
  • copilot-instructions.mdの作成と利用`
  • 個人開発プロジェクト開発での利用
    • GmailのKindleハイライトをNotionに登録するGASアプリケーションの新規作成
    • 既存のGASアプリケーションのアップデート作業とテストケース追加
  • ブログ執筆スタイルのガイドラインをAIに生成してもらう

わかったこと(W)

  • 効率化と適切な使い方

    • 実装方式が自分で理解できているケースは確実に効率が向上する
    • 実装方式が自分で理解できていないケースは、GitHub Copilotと相談しながら決めていくアプローチが有効。
    • copilot-instructions.mdでコンテキストを提供すると回答精度は上がる
    • 状況の絞り込みを行うと回答品質が改善される
  • 課題と制限

    • 最新のNext.js技術仕様は理解していないので、実装提案は外れることが多かった
      • Claude 3.7 Sonnet Thinkingで改善される傾向があった
    • 外部依存のあるテストケース生成はコンテキスト把握に課題
    • copilot-instructions.mdにファイルパスを記載していても、ナレッジファイルへの直接アクセスは現状(2025年3月時点)ではできない
    • 古いMac環境ではCPU負荷が高くなり、応答が遅くなることがある
    • GitHub Copilot Editsのログは現状(2025年3月時点)では保持されない
    • ファイルの保存を忘れると、期待通り動かずハマる
  • モデルの使い分け

    • 難しい質問はClaude 3.7 Sonnet Thinkingが適している
      • 回答には時間がかかる
    • それ以外の一般的な質問はGPT-4oで良さそうに思った

次にやること(T)

  • プロンプト管理の改善

  • 開発フローの最適化

    • GitHub Copilot Editsのログを記録するMarkdownファイル生成の仕組み構築
    • 環境依存に注意したコード生成依頼の工夫
    • claspのTypeScript開発環境の移行は「新環境構築→旧コード移植」アプローチで実施してみる
  • より効果的な活用方法の模索

    • プロジェクト特有のコンテキストを効率的に提供する方法の確立
    • 最新技術に対する回答精度を向上させる方法を試行錯誤してみる
    • 別のプログラミング言語でも試してみたい

以上がGitHub Copilotを使用感のふりかえりです。
適切に活用すれば開発効率は向上しますが、その特性を理解して使い分けることが重要だと感じています。


詳細補足

Next.jsのブログの機能拡張

このブログのインクリメンタルサーチ機能をGitHub Copilot Editsを活用して実装しました。Next.jsの最新仕様については、 GitHub Copilot Editsの理解が不十分なケースがあり、実装提案が外れることもあり、こういった場合はClaude 3.7 Sonnet Thinkingで質問すると解消される傾向にありました。実装パターンを自分で理解できているケースでは、コーディング効率が確実に向上しました。

具体的な話になりますが以下のケースで自動生成があまりうまく動いていなかった記憶があります。

  • remarkのテストケースをjestで実装しようとして、ハマる。

  • Next.jsのApp Routerでの実装が欲しいケースで、Page Routerの処理で実装が提案される。

    • このケースは、copilot-instructions.mdにルール記載して縛った方が良かったかもしれない。

GmailのKindleハイライトをNotionに登録するGASアプリケーションの新規作成

Kindleのハイライトを活用するために、Gmailに送られてきたKindleハイライトのHTMLをparseして、Notion APIを使って登録するGASアプリケーションを作成しました。詳細な仕様をプロンプトで指定して、Copilotに生成してもらいました。 プロンプトに興味がある方はgas-kindle-to-notion の作成に利用した。GitHub Copilot Edits のプロンプトをご確認ください。

数回のデバッグ作業を経て完成したものをGitHubリポジトリとして公開しています: kemsakurai/gas-kindle-to-notion: Gmailに添付したKindleハイライトのHTMLをNotionに登録するGAS

NotionのAPIのブロックサイズ制限に引っかかってエラーメッセージをプロンプトに入力して、修正した記憶があります。
APIの叩くというところは1回の生成でうまくいっていました。

既存のGASアプリケーションのアップデート作業とテストケース追加

PageSpeedInsights v5 API用のGASライブラリのアップデート作業とテスト追加を行いました。

作業プロセスと結果:

  1. TypeScriptとwebpackのアップデート(失敗)

    • GitHub Copilotの提案にしたがってアップデートを実施しましたが、GASへのデプロイがうまくいかず断念
      • 古いclaspのTypeScript開発環境を更新するよりも、新しいclaspのTypeScript環境を作って移植する方がベターだという教訓を得た ※これは、GitHub Copilotがダメというか、claspの開発環境のマイグレーションが難しいのではという気がしている
  2. 最小限のバグ修正とライブラリアップデート(成功)

    • 範囲を絞ってGitHub Copilot Chatで実装修正
    • npm installの問題もCopilotのアドバイスで解決
      • 以前はlegacy-peer-depsを指定して解消していたが、GitHub Copilot Chatに聞いたら解決できた
  3. テストケース追加とcopilot-instructions.md活用(成功)

    1. copilot-instructions.mdの生成をCopilotに依頼
    2. Jest関連のライブラリアップデートとテストケース生成
    3. ログを選択して.github/copilot-instructions.mdに追記すべき内容を提案してもらう
    4. 生成したcopilot-instructions.mdはGitHubリポジトリ gas-PageSpeedInsights-v5にPush

テストケース追加とcopilot-instructions.md活用(成功)の作業時に、.github/copilot-instructions.mdの生成、編集に利用したプロンプトは、.github/copilot-instructions.mdの生成、編集に利用したプロンプトに置いてありますので、興味があればご確認ください。

ブログ執筆スタイルのガイドラインをAIに生成してもらう

過去記事をGitHub Copilot Chatに読み込ませ、私風のブログ執筆スタイルガイドラインを生成してもらいました。以下のようなプロンプトを使用しました:

選択した記事は過去に私が書いた記事です。これら記事の内容を参考に、GitHub Copilot Editsが私風のブログを書くためのガイドラインを生成してください。

生成されたガイドラインは基本方針、構成と形式、文体と表現、コンテンツ内容、実践的なヒント、執筆プロセスなどをカバーしており、.github/prompts/blog-style.prompt.mdとして保存し、今後のブログ執筆や編集に活用できるようにしました。

.prompt.mdファイルは、Reusable Prompt Filesという名前がついているようで、カスタムインストラクションの一歩先!GitHub Copilot への指示を分割管理しようを参考に作成しました。

古いMac環境ではCPU負荷が高くなり、応答が遅くなることがある

2018-2019年製のMacを使用しているため、GitHub Copilotを使用中にCPU負荷が高くなり、応答が遅延する場合がありました。スペックは以下の通りです:

2.2 GHz 6コアIntel Core i7
Intel UHD Graphics 630 1536 MB
16 GB 2400 MHz DDR4

とくに複雑な処理や長い応答を生成している場合に問題が発生しやすい傾向があるように感じました。

copilot-instructions.mdにファイルパスを記載しても、ナレッジファイルへの直接アクセスは現状(2025年3月時点)では制限がある

この件について、GitHub Copilot Chatに尋ねたところ以下のような回答が返ってきました。

現在の状況では、実際にはナレッジファイルへの直接アクセスができていません。
現在のコンテキストでは、添付された`copilot-instructions.md`ファイルは見えていますが、実際の_notion/reading-list-*ディレクトリ内のファイルにはアクセスできません。
ナレッジを利用するためには、以下のいずれかの方法が必要です:
* 特定のナレッジファイルを直接添付する
* 関連するファイルパスを指定して、そのファイルを参照する
* ターミナルやファイル検索機能を使って該当するファイルを特定し共有する

この点については、パフォーマンスへ悪い影響を与える可能性がありますが、ドキュメント参照機能が実装されると個人的にはうれしく思います。

状況の絞り込みを行うと回答品質が改善される

質問時にGitHub Copilot Chatに具体的なエラーメッセージや状況を詳細に提供すると、回答の品質が向上します。以下は具体例です:

基本的な質問

Netlify上で、以下のエラーが発生します。原因を教えてください。 
7:46:20 PM: > prebuild 
7:46:20 PM: > npm run generate-index 
7:46:20 PM: > generate-index 
7:46:20 PM: > node src/tasks/generateSearchIndex.js 
7:46:20 PM: node:internal/modules/cjs/loader:1143 
7:46:20 PM: throw err; 
7:46:20 PM: ^ 
7:46:20 PM: Error: Cannot find module '/opt/build/repo/src/tasks/generateSearchIndex.js'

回答

Netlifyビルドエラーの原因について
このエラーは、src/tasks/generateSearchIndex.js というファイルが見つからないために発生しています。

追加コンテキストを付与した質問

Netlify上で、以下のエラーが発生します。原因を教えてください。
[同じエラーメッセージ]
これはlocalではファイルが存在し、実行でき、GitHub のリポジトリ上にも存在します。

改善された回答

Netlifyビルドエラーの原因と解決策
原因
このエラーはファイル名の大文字/小文字の不一致が原因です。

現在のファイル名: generateSearchindex.js (小文字の i)
package.jsonで指定されている名前: generateSearchIndex.js (大文字の I)
Macなどのファイルシステムでは大文字/小文字を区別しないため、ローカルでは正常に動作しますが、Netlify(Linux環境)では区別されるため、ファイルが見つからずにエラーになっています。

このように、問題の具体的な状況や環境情報を追加することで、より的確で実用的な回答を得られました。

ファイルの保存を忘れると、期待通り動かずハマる

GitHub Copilot Editsでファイルを編集しても実際のファイルへの更新が行われず、テストを再実行しても結果が変わらない状況が多々ありました。 VS Codeの操作方法に問題があった可能性もありますが、ファイルが追加された時は、明示的にファイルを選択して保存する必要があるようです。


参考

GitHub Copilot利用の試行錯誤中に参考にした記事は以下の通りです。

まとめ

GitHub Copilotを2週間活用してみて、開発生産性の向上に大きく寄与すると感じました。一方で、作業手順を誤ると、手作業と同様に行き詰まることがあります。 新規でアプリケーションを作るときは、そこまで意識しなくても良いかもしれません。しかし、既存のアプリケーション修正時は、GitHubのIssueの作業単位を細かくし、テストで担保しながらこまめにcommitすることが重要に思えました。リファクタリングで動かなくなった場合に、正常動作するポイントまで小さく戻せるようにしておく必要があります。
また、プロンプト整備の楽しさと重要性に気づいたため、今後はプロンプトの管理方法や活用方法の改善を進めていきたいと考えています。
以上です。