こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(時間の関係で講演部分のみの参加でした)
会の概要
以下、イベントページから引用です。
株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。
今回の勉強会は「GitHub Copilot」についてです。 基調講演にGitHub社から服部さん（@yuhattor)をお招きしてGitHub Copilotの真のパワーについてお話をいただきつつ、GitHub Copilotを導入しているタイミー、GMOペパボ、freee、コミューンによる実践や導入に関するLTをお届けします。
会の様子
開発生産性をあげる GitHub Copilotを徹底解剖！
最初に服部さんから基調講演がありました。
最初にGitHub Copilotの開発思想のお話がありました。
GitHub Copilotは開発生産性に着目しているため、レスポンス速度に重点をおいたり、コーディング以外のサポート(例えばドキュメンテーション)にも力点を置いたりしている上に、高い精度を実現できるようにかなり大規模な投資をしてきたということでした。
今後の投資としては、今は音声認識(Copilot Voice)やTestPilot、自作の共有ライブラリも読み込めるようにするためのGitHub Copilot for "Your" Codebaseなどをメインに投資しているということです。
続いて、GitHub Copilotの設計にまつわる話がありました。
LLMを活用しているという話や、GitHub Copilotに与えると良いinputであるPrompt Crafting(Language Marker, Path Marker, Neighbording Tabs, Code Retrieval)の紹介、ファイル内検索の仕組み(文字の類似性でファイル内を検索するため、命名規則をしっかり定義しておくことが重要)、GitHub Copilotの制限(徐々に増加中だが、適切なトークン量は必ずあるので無限に増やすことはしない予定)...が紹介されました。
最後にGitHub CopilotのTipsやTricksの紹介がありました。
詳細はai-native.devを参照ということですが、便利なファイルのピン留めや一貫性のあるコーディングスタイル、テストコード生成方法の指定、リファクタリング前にテストコードを書く、が紹介されました。
GitHub Copilotを使って自作ライブラリを作ってみよう
続いて新谷さんからGitHub Copilotを使って自作ライブライを作っていく様子がデモ形式で紹介されました。
最初にGitHub Copilotでなぜ自作ライブラリを作るのか？というお話がありました。
これは、自作ライブラリはOSSなどで多数公開されていることと固有のドメインロジックが少ないことが理由だそうです。
その後は実装のデモがありました。
さすがにデモの様子はブログでは書けないのですが、以下に実装の内容があるため、詳細はこちらを見ていただければと思います。
コーディングだけじゃない！Github Copilotの活用法
続いて池田さんから、コメントやドキュメントでGitHub Copilotを活用する方法の話がありました。
池田さんは、コード生成以外でも、
- property定義だけ書いて後はコメントを自動生成
- コンテナの依存関係をコメント生成
- ブログや文章作成の補助
- 自然言語の翻訳
- 対訳データの作成
- 要約
といった形でGitHub Copilotを使用しているそうで、業務でめちゃくちゃお世話になっているということでした。
GitHub Copilotで開発生産性はどのように変わるのか
次に黒瀧さんから、Github Copilotを業務で利用してどのような変化が起きたのか？という話をしてくれました。
黒瀧さんが所属するGMOペパポさんでは、2012年からGitHubを使用していたそうですが、生成AIブームを皮切りに、Github Copilotを導入したそうで、結果的に35,000行のコードを作成するコストが削減された&four keysの指標が軒並みよくなった(デプロイ数が0.6-1.6回上がった...)そうです。
言語別に見ると、RubyはGitHub CopilotのコードがAcceptされる可能性が低いそうで、これはRubyの表現力の高さ故にプロジェクト規約や個人の好みにマッチしないことが原因なのではないかと考えているということでした。
エンジニアからも、GitHub Copilotを導入したことでめちゃくちゃ開発が便利になったという話があったそうで、具体的には以下のような声があがったということでした。
- よくわからないコードの説明が便利
- エラー内容を日本語で説明してくれる
- 結果的に命名がしっかりした
- テストコードを書いてくれるのが便利だった
- 賢すぎて補完を待つ癖がついた
- 一貫したコードが生成されるようになった
- 触る機会が少ない言語でも素早く実装できた
GitHub Copilot導入時に考えたセキュリティのあれこれ
最後はたださんから、セキュリティ観点でGitHub Copilotの導入をどのように検討していったのか？という話がありました。
最初にGitHub Copilotのセキュリティリスクを洗い出したそうで、以下の4点が挙げられたそうです。
- 学習に利用されないか？
- 情報漏洩しないか？
- 危険なコードを提案されないか？
- 他社の著作物は混じらないのか？
- いきなりの規約変更はないか？
- GitHub Copilotは新しいパラダイムを提案できるか？
その上で個々の要素を検討したそうです。以下に検討結果を記載していきます。
「学習に利用されないか？」「情報漏洩しないか？」...会社のセキュリティ定義に従うとエンジニアの生産性向上のメリットの方がソースコード漏洩リスクが上回ると判断したということです。
「危険なコードを提案されないか？」「他社の著作物は混じらないのか？」...AIベースの脆弱性フィルタリングシステムが組み込んであること、Public Codeにマッチする提案はしないようにできること、著作権は会社が所有できること*1を確認したということです。
「いきなりの規約変更はないか？」...規約変更のリスクは一定ある。ただ、これまでの実績を見る限り、たださん的に見てめちゃくちゃな変更はない。
「GitHub Copilotは新しいパラダイムを提案できるか？」...自身のコードを再帰的に強化学習することになるはずなので、人間がGitHub Copilotへの依存を強めていくと、新しいプログラミングパラダイムが生まれにくくなるリスクもある。
結果的には、開発者の生産性の方がリスクよりも重要だと判断したそうで、社内導入もしたということですが、「GitHub Copilotのコードを適切に判断できるだけの技術力を有すること」「GitHub Copilotに頼らずに新しいことにチャレンジし続ける好奇心を持ち続ける強さを持つこと」の2点は求めていくことも同時に決定したというお話でした。
会全体を通した感想
基調講演でGitHub Copilotに関してGitHubの服部さんから濃密に紹介をしてもらい、その後に事例講演が続くというスタイルは非常によかったですし、発表順が今回の順番だったお陰で楽しめた実感もありました。
事例講演の発表内容としても、ただ使ってみたという話ではなく、4者4様で発表観点の差異も良い意味で大きかったので、面白かったです。
