🤖

GitHub Copilotをうまく使う「後輩くん」思考のススメ

2023/07/12に公開

はじめまして、4月に入社したばかりのバクラク事業部 電子帳簿保存のエンジニアリングマネージャーをしている菊池 (@kichion)です。7月はLayerX エンジニアブログを活発にする期間なので、気になる記事をチェックしてもらえると良いと思います! 7/11は@makoga (小賀昌法) さんの「入社してから事業部執行役員(VPoE)になるまでの3ヶ月間に考え、実施したこと」でした。

本記事では、私がここ数ヶ月GitHub Copilotを使って得た知見を共有したいと思います。

GitHub Copilotをうまく使うための基本的なガイド

GitHub Copilotは、プログラミングにまつわる作業支援をしてくれる非常に有効なツールですが、以下のようなストレスポイントもあると思います。

  • 思ったより意図通りのコードを吐いてくれない
  • 存在しない属性値参照をしていて結局書き直す

少しでもストレスポイントを解消するような方法があるので、紹介します。

GitHub Copilotの気持ちになる

GitHub Copilotは、一般に公開されているソースコードと自然言語で学習されているため、学習データのみを使う場合には、privateなソースコード(所属企業などのソースコード)に関連するサジェストを出すのが難しくなってしまいます。

しかし、お仕事で書いたClassやstructのfieldが正しくサジェストされることはありますよね?あれは、GitHub Copilotがサジェストの際に動的に記載しているコードやその他関連するコンテキストを理解するようなプロンプトが作成されていると、GitHub Copilotのブログでも綴られています。

https://github.blog/2023-05-17-how-github-copilot-is-getting-better-at-understanding-your-code/

しかし、ブログでも6000文字と限界があるため、全てのコードを参照してサジェストできるわけではありません。なんとなく、GitHub Copilotは視野の狭い優秀な後輩であり、一緒にモブプロしながらドライバーで参加してくれているとしてみると、良いような気がします。

さて、 視野の狭い後輩くんにどうやってうまくモブプロのドライバーを務めてもらいましょうか? と考えると、後の方法論が単純に見えてきます。

編集に必要な情報を持っているファイルタブを1、2つだけ開く

たくさんのタブを開いて作業するのをやめましょう。後輩くんがたくさんの情報の海で溺れてしまいます。GitHub Copilotが、開発者が作業しているIDEで開いているすべてのファイルを処理できるようにする技術として「Neighboring tabs 隣接するタブ」という考え方をブログでも書いています。

https://github.blog/2023-06-20-how-to-write-better-prompts-for-github-copilot/#2-keep-a-couple-of-relevant-tabs-open

この提言に則るのであれば、作業ファイルとは別に1つか2つの重要なファイルタブを開いておいて、他は閉じるといいでしょう。

適切な書き出しでヒントを与える

いきなり適当な名前の関数から書き始めるのをやめましょう。後輩くんがその後に何を書けばいいか迷ってしまいます。プロンプト テクニックのOne-Shot、Few-Shotに近い考え方で、関数・変数名やコードコメントでやりたいことなどを書き始めるのが良いとされており、特に開発言語の体系に沿った一貫した書きぶりを提示してあげると、精度高く多くのサジェストが出るようになります。

改修作業でも時には新規ファイルから始める

改修対象のファイル行数が1000行以上になっているのであれば、一旦新規ファイルから始めましょう。後輩くんは、同じファイル内にある書きぶりを優先度高く参照して使う可能性が高いです。もし、責務が膨らみすぎたファイルの改修を行う場合は、コンテキスト範囲を狭めてあげると、正しく採用できるサジェストを返してくれるようになります。

経験と感想

このノウハウに準じてやれば、いい感じにGitHub Copilotが使えて、ほとんど書かなくていいじゃん!となるかもしれませんが、現実は甘くありません…。筆者の体感では、以下のような点があります。

  • 的はずれなサジェストが少なくなった
  • field参照などの精度が飛躍的に上がった
  • golangの一般的に良いとされる書きぶりのサジェストが多くなった

一方、以下のような本質的ではない状態にもなっていると感じる時があります。

  • GitHub Copilotのために思考を使う時間が増えた
  • GitHub Copilotがいいサジェストされるように、「頑張れ…!」と思いすぎる
  • コードが完成される前に、GitHub Copilotがいいサジェストされることで満足してしまう瞬間がある

また、GPT-4ベースになったり、もっと大きなコンテキストを把握できるモデルが採用された際にはまたこのノウハウも陳腐化するかもなぁという虚無感は一定あります。

LayerXでのGitHub Copilotの使用

開発者の好みに合わせてIDEを選択できる等の理由もあって、現状では個人が任意で使用しても良い状態です。(もちろん、ソースコードを学習に使わせない設定を行った上で)

有志で簡単にアンケートを取った結果、やはり大半の開発者はGitHub Copilotを使用しています。

今回のノウハウであった、「隣接するタブ」については、知らなかった方も多く、今回の内容は参考になるところがあると思いました。

最後に

GitHub Copilotはプログラミングにおいて非常に強力なツールである一方でLLMの特性を有しており、使用における細かな配慮が必要なのも事実です。エンジニアとして背景にある内容を掴みつつ、有効な使用をできればより良い開発活動に貢献できると思います。この記事の内容がその一助になれば幸いです。

LayerX

Discussion