GitHub・服部氏が語る「GitHub Copilot」の裏側　“エンジニアの開発生産性を上げる”ために重視している2つのポイント

開発者の生産性向上にフォーカスする「GitHub Copilot」

服部佑樹氏：ギットハブ社の服部です。本日は、「開発生産性をあげるGitHub Copilotを徹底解剖！」というところで、ちょっと裏側の実装的なところも含め、どうなっているのかも少しお話できたらなと思います。

その前に、もしかしたらまだ「GitHub Copilot」を「触ったことがないです」という方もいらっしゃると思うので、復習になってしまう方もいるかもしれませんが、「GitHub Copilotとは？」というお話から始めたいと思います。

まず、GitHub Copilotですが、「AI pair programmer」というところで、「Visual Studio Code」のエクステンションとして入れると、AIがコード生成を助けてくれるというものです。

ただ、生成系AIの話で一般的な話ではありますが、静的解析に基づいて出しているわけではないので、もしかしたら間違う可能性がある。もしかしたら文脈と合っていないものが出る可能性もあります。

そういったところも含めて、やはりエンジニアのスキルや知識や諸々の経験みたいなところを、いかに一緒にペアプログラミングしていく中で表せるかになるかなと思います。

開発者の生産性向上というところで、やはりコードを書いているところだけがプログラマーがやるところじゃないですよね。ドキュメントを作成したり、プルリクエストのコメントを書いたり、調査をしたりというところも含めて、けっこう重いタスクだと思うんです。

そうした時にGitHub Copilotだと、コーディングももちろんだいぶ書いてくれるのですが、例えば調査のタスクをする中で、「ChatGPT」じゃないですが、GitHub Copilotに聞いて問題解決していくとか。

あとはその中で、コンテキストスイッチをなるべく減らす。例えば、ブラウザに行ったらエディターに戻って、エディターに行ったらエクセルを開いてみたいなところをなるべく少なくして、マルチタスキングを減らすことで生産性を向上させる、というところも我々はかなりフォーカスしています。

なので、GitHub Copilotで重要なところは2つあって、開発の時にはもちろん精度も大事ですが、反応、スピードもかなり大事にしているところです。

やはり、ChatGPTやチャット系のソリューションでやっていると、けっこう待ちますよね。そうしている間に頭の中からアイデアが抜け落ちてしまうということもなるべく避けたいところです。なので、GitHub Copilotとしては、そういったスピードもなるべく重要視しています。

GitHub Copilotをいじると、けっこう小さいチャンクというか少ない量で返ってくることがあると思いますが、それも実際はその理由があるからです。あまり長いものを返すよりは、どんどん提案してもらって、略すなら略してということをプログラマー側にやらせたほうがいい、そういったところでやっています。

フロントエンド・バックエンド・LLM　3レイヤーで作成されている

いわゆるオープンソースでもそういう同様のソリューションは出ていて、それらを試したという声も「Twitter（現X）」などで上がっていると思いますが、我々のGitHub Copilotは、実はもう2年ほどの歴史があって、かなりカリカリにチューニングしています。

今の精度にするまでに、GitHubはお金を投資して、人を雇ってやっているので、やはりそういう精度の違いと実装の差は（あります）。

GitHub Copilotはみなさんにエディターの中で使っていただいていますが、バックエンドはもちろんあります。そもそもLLMに対して直接叩くというよりは、その中間層でAPI側がきちんとフィルタリングをしたり、本当に適切なものを返したりという処理をしている実装になっています。

なので、クライアント、バックエンド、あとはLLMと、その3レイヤーでGitHubは GitHub Copilotを作成しています。

やはり、このGitHub Copilotはエディターの中で完結させると。それこそ新しいモデルが出てきたり、いろいろ変わりゆくので、なるべくお客さんには長く使っていただきたい、プログラマーの方、エンジニアの方にも、長く使っていただきたいなということで、このエコシステムの中でいかに全体的な開発者体験、デベロッパーエクスペリエンスを上げるのかをものすごくGitHubは気にしています。

なので、チューニングをしてどんどんどんどん精度を上げていくだけというよりは、例えばプルリクエストを上げた時に、そのコメントを代わりに書いてくれたり、CLIの中で「??」というコマンドを書いて、自然言語で「このコマンドって正規表現も含めどうやって書いたらいいんだっけ？」みたいなことを書くと、少し提案してくれたりなど、そういったところの未来があります。

あと、ドキュメンテーションを見ていろいろ調査するなどのタスクがあると思います。

例えばJavaScriptやTypeScriptの中で調べたり、Googleでとりあえず検索するみたいな（ことをすると思います）。

もちろん、ドキュメントがわかる人、ないし、ここを見たらわかるという勘所がある人はそこを見に行けるのですが、そうではない場合もある。その時にAIがある程度ベクターデータベースですが、まとめて提案してくれる。ドキュメントの中にこういうデータがあったよというところの証跡というか、URLも含めてくれるものも開発しています。

なので、先ほどちょっと出しましたが、GitHub Copilotは、この全体のライフサイクルの中でいかに開発者体験を良くするのかというところを狙っています。

「Copilot Voice」「GitHub Copilot for *Your* Codebase」の紹介

あとは、「Copilot Voice」という、音声でGitHub Copilotを使えるものも開発しています。これはもちろんアクセシビリティの観点もあって、やはりGitHub Copilotも Copilot Chatでもいろいろコンテキストやプロンプトの話をするのですが、条件、ないし、または情報を多く与えてあげれば与えてあげるほど精度がいい提案が返ってくるんですね。

そうした時に、いちいち全部をタイプするのは大変ですよね。もちろんそのコードベースを読んでくれますが、それ以外の情報を提供したい時は、やはり音声の入力がものすごく重要になります。

あとは、「GitHub Copilot for *Your* Codebase」というところで、今のところGitHub Copilotは、Saharaという3.5系のモデルを使っています。

実際にこのGitHub Copilotを使う中で、例えば新しいライブラリや、自分自身のチームのコードは読んでくれないよね、と思う方も多いかもしれません。

例えばチームで書いた共有ライブラリみたいなところも含めて提案してくれるという機能を開発中です。

もちろんエコシステムというお話もありますが、それ以外にも、精度というかたちでも上がっていきます。

（次回へつづく）