「GitHub Copilot」の普及によって、新しいものが生まれにくくなる？
司会者：先ほど、ただただしさんから「（「GitHub Copilot」の普及によって）新しいものが生まれにくくなるんじゃないか」みたいな話があったので、まずはそこをフックに、服部さんからアンサー的な感じで話してもらえればいいかなと思います。よろしいでしょうか？
服部佑樹氏（以下、服部）：はい、ありがとうございます。これはCopilotという話ではなくて、たぶん全体的な話で、Large Language Modelの話になると思います。おっしゃるとおり、やはり新しい言語をどうやって学ばせるのかは非常に難しい問題だとは思います。
フレームワークに関しても、例えば Python のFastAPIについて、すごくポンポン提案してくれるなと思う一方で、これは新しいフレームワークができた時にどうなるんだろうなとは思っています。このソリューションとして私たちもベクターデータベースなどを使いながら、いわゆるコードベース全体のリポジトリを見て、スニペットをインクルードするところも実験しています。
ですが、それだけだと学習していないのできっと限界があります。やはりお客さまからも「学習させたい」という話を多くいただくんですよね。ただ、Large Language Modelとして追加で学習をさせたところで、その背後にある数万行のデータに対して、追加分がどれだけ効果があるのかみたいなところは、けっこう課題なんじゃないかなとは思います。
正直私からは、あまりアンサーがないんですけれども（笑）。ただやはり、そこの学習がどのように行われるのかは、「GitHub Copilot」や開発者に対するものだけじゃなく、もう少し全体的なパラダイムというか、Large Language Modelがどうなっていくのかなというところに最終的に行くはずです。なので、エンジニアとしては最終的にそこのエンジニアリングを極めるだけじゃなくて、もう少し全体を見る。
先ほど、たださんからも「好奇心」というお話がありましたが、結局のところものすごく好奇心があれば、GitHub Copilotは何でも答えてくれます。「ChatGPT」もそうですね。
いかにそのループを回せるのかが、エンジニアとしてだけじゃなく、人間としての成長にもかかってくるのかなと思います。けっこうこの好奇心は重要だと私も常日頃から感じていますし、スライドに出てきて「あぁ、そうだよね」と思いながら見ていました。
司会者：ありがとうございます。
顧客適用モデルは出てくるのか？
司会者：たださん、今のお話を聞いていかがですか？
ただただし氏（以下、ただただし）：おっしゃるとおりだと思います。うちのアプリケーションエンジニアは、Copilotをめちゃくちゃ喜んでいるのですが、インフラチームは「いまいち使えない」と言っているんです。なぜかというと「Terraform」のソースは、ほとんどパブリックではないんですよ。ほぼ企業のプライベートリポジトリにしか、サンプルがないはずなんです。
なので「これを学習させたい」と思うのは、それはそうだよなと思うんですよね（笑）。おそらく今後もインフラチームはCopilotの恩恵を受けられない可能性が高くて、そのあたりの、要はカスタマイズされたモデルみたいな方向性は、どうなんでしょう？ 今のLLMでは難しいとは思うのですが、LLMもどんどん最適化が進んでいて軽量化が進んでいるじゃないですか。「お金を出せば顧客適用モデルも作ります」みたいな、そういうプランはありえますかね？
服部：今の段階でやってはないのですが、やはりトークン数もどんどん増えています。あと、GitHub Copilotは一時期Codexというモデルを使っていたのですが、今は使っていません。それは精度と速度の問題もあるのですが、もう1つ、データセンターキャパシティの課題もあるんですよ。
快適な提案をなるべく多くのユーザーに対して、少ないリソースコストで提案するという理想にどんどん近づく過程でモデルも軽量化され、学習コストも下がってくる可能性はあります。
一方で、「新しいことを学習させたい」みたいなところは本当に多いんですよね。GitHubのプロダクトチームを常にいただいておりますので、そこに対する解は、出てくると思います。
ただただし：ありがとうございます。
類似性の参照元としてどこまで見ているのか
司会者：登壇者のみなさんはすでにGitHub Copilotをお使いですが、「この際だから聞いておきたいぜ」みたいなことはありますか？ すみませんね、準備していないとこうなるんですよ（笑）。
（会場笑）
司会者：「反省ですね」という感じです。（笑）。では会場はいかがでしょう？ 「使っているよ」という人もいると思うんですけど。ちなみにGitHub Copilotを使っていますという人は手を挙げてもらっていいですか？
（会場挙手）
司会者：ほとんどですね。オンラインの方も「使ってます！」というので「ノ」とね。古き良き「ノ」でリアクションをいただけるといいのかなと思います。大半の方は使っているということで、服部さんもいるのでフィードバックとか、「ここを頼みます！」みたいな嘆願も請願も、今この場でしてもいいんじゃないかなと思いますが、会場にはいますか？
（会場挙手）
司会者：ありがとうございます。じゃあ、マイクを。
質問者1：ありがとうございます。Copilotのどこまでを見ているのか。類似性の参照元の話で、先ほど直近に開いたタブとか、そういう「定義ファイルとかいいよね」とか。先ほどデモをしていただいた時は、ほぼテストコードまで見ていたと思っていて、たぶん実装する時にポロッと出てきちゃっているじゃないですか。
あと他に見ている部分というか……僕はターミナルは「VS Code」上で使っていないのですが、例えばVS Code上でターミナルを使ったほうが、この先参考情報になるのかとか。あとはこれはたぶんちょっと違うと思うのですが、プラグインでVS Code上でCopilot for Chatを使っていて、それも参考情報になっているのかどうかをおうかがいしたいです。
服部：ありがとうございます。まず、基本的に見るのはファイルだけです。なので、例えばターミナルの情報をGitHub Copilot が読み取るというのは基本的にはありません。
セミナーの中でお伝えしたとおりで、現在の参照順番は Language Markerや、 Path Marker があって、多くの場合はファイルの上からコードを書いていきますが、そういったファイルにおけるカーソルの位置も参考にされます。の。それらの情報が特に重要です。最終的に横のタブが最大20個読み取られますが、トークン制限の関係もあり20個読み取られることはほぼありません。
1つ言えるとしたら、結局過去に開いた数個のファイルの参照だけでプロンプトの中に埋め込めるトークンがだいたい終わってしまいます。それ以上に読み込む必要がないと言うとアレですが、今のところはそこのプライオリティは下がっています。
ただ、プロンプトに含める情報をどうやって取るのかというアルゴリズムは、こういうところで明言しても、本当にどんどん変わっていってしまって、1ヶ月前に私が知った情報がもう違っているというのは、すでに起きているので、そこはあまり気にしないでもいいのかなとは思います。本当に、直近開いた3、4個のファイルを気にしてもらうぐらいでいいのかなと思います。
司会者：ありがとうございます。
生産性の向上メトリクスを手軽に確認する方法は？
司会者：オンラインからも質問が入っています。1つが「GMOペパボさんのような生産性の向上メトリクスを手軽に確認する方法はあるのでしょうか？」ということだったので、これは黒瀧さんにお答えいただければなと思います。
黒瀧悠太氏（以下、黒瀧）：手軽に確認する方法……うちはけっこう自前でやっています。「Google Cloud」や「GitHub Enterprise」を使っていて、そこで最初にコミットしてからプルリクを出すまでの時間、プルリクを出してからマージされるまでの時間、マージされてからデプロイされる、そのデプロイしてプロダクトリリースされるまでの時間などは計測できます。
それらを全部社内でシステム構築して可視化したというのは、データ基盤チームでやっています。2022年に「可視化したよ」というブログが公開されていて、そちらにアーキテクチャが書いてあるので、参照いただければと思います。現在はそれを運用して、各サービスで定点観測をして、自分たちの生産性がどう変わっているかを見て改善するアクションをするというフェーズになっています。
うちはけっこう自前で作っているのですが、最近はそういうFour Keysを基にした生産性を可視化するSaaSがあると思うので、そちらを活用するのもいいかもしれません。
ただただし：先ほどの効果測定のところで、サジェストを受け入れるというやつは今のやり方だと測定できないと思うのですが、それはどうやって測定したんですか？
黒瀧：サジェストのAcceptsのRatesですよね？ あれはGitHub Copilotの管理画面からダウンロードできる状態ですよね？
服部：今はエンタープライズのお客さまに限り営業経由でお渡ししています。
黒瀧：営業経由でもらえます（笑）。
服部：あのダッシュボードは開発途中で私たちしか見られないのですが、次第にみなさんのお手元でも見られるようになりますので少々お待ちください。
ただただし：営業に聞いてみます。
黒瀧：私も営業に聞いていきます。ありがとうございます。
（一同笑）
（次回へつづく）
