生成系AIが発展する中で必要なスキルセットとは　「GitHub Copilot」を活用するエンジニアたちが考える、それぞれの生存戦略

アルゴリズムの変化に伴い、Tipsが陳腐化する可能性はある

司会者：次にオンラインで来ているのは、「GitHub Copilotの裏側のアルゴリズムが変わっていっているということですが、アルゴリズムが変わることで今回ご紹介いただいたTipsが陳腐化することもあるのでしょうか？」

服部佑樹氏（以下、服部）：はい、あります。端的に言えるのは、結局良いコードを書くという（のが目指す）ところなので、最終的にTipsはツールの使い方ではないということです。隣のタブで開いているものを開いたからCopilotの質がちょっと上がったね、というぐらいでは、全体的な生産性に影響があるかというとそんなにないんですよね。

それをやるぐらいだったらちょっと書き方を変えてみる。1回提案されるところを、Ctrl＋Enterを押すと10個ぐらい提案してくれるので、その中から自分で考えて選んだほうがいいですし、あとは何回か書き換えてみてCopilotの提案を待ったほうがいいというところなので、基本的に「ツールがあるからこういう書き方をしなきゃいけない」というのはある意味ナンセンスです。

最後のスライドに入れましたが、「あまり気にし過ぎない」。一応条件があってツールとしては取ってくるので、そこで差は生まれる可能性はありますが、「なんとなくこんなものなんだな」ということを頭の中にちょっと入れてもらって、少し（生産性が）上がればいいなというところで紹介しています。なので、質問の答えとしては陳腐化する可能性は非常にあります。

司会者：ありがとうございます。

プロンプトによって結果の精度はけっこう変わってくる

司会者：ちょっとオンラインのほうにいったのですが、登壇者側でなにかあれば。

新谷哲平氏（以下、新谷）：先ほどの話でもあったようにTerraformだとなかなか補完が難しい。Android・iOSでもこれより難しいと思っていて、そこはデータがないからだと思っているのですが、今後望みはありますか？　というのを聞いてみたいなと思いました。

服部：そうですね。モデル自体はものすごく質が上がっています。そういう意味では望みはありますし、必ずしも学習データだけから提案する必要があるかというと、やはりそうじゃない可能性もありますよね。

「COBOLのマイグレーションをしたい」とか「COBOLからJavaに変えたい」とか「もう少し最先端なものに変えていく」とか、エンタープライズのお客さんからよくお声をいただきます。

そうした時に、ロジックをマイグレーションするところをそのままGitHub Copilotに頼るかというと、それは無理があります。例えばインフラの文脈でいうと、インフラエンジニアが昔からのシステムにマイグレーションする時に、古いシステムから本当にリアーキテクトしてクラウドにぜんぜん仕様も変えて持っていくのか、それともただ単に差し替えるだけでソースコードは変えないのか。

それと同じで、ちょっと話から外れていますが、例えばCOBOLのコードを移す時に、COBOL側の日付計算に関するすばらしいライブラリがなかった場合、冗長に書いているところをそのままJavaに移植するのかというと、Javaにはメチャクチャすばらしい日付関連を扱うライブラリがありますという話になってくると思います。

そうした時に精度を上げる可能性があるのが、CopilotやLarge Language Modelの提案だけの、学習だけによるものかというとそうではなくて、どうやってハンドリングするのか、どういうプロンプトで、どういうかたちのロジックを1回通してやってあげるのかという命令の仕方は、実はけっこう精度が変わるところです。

なので、Large Language Modelの学習モデル・学習データの向上だけを期待するのであれば、（それが）いきなり上がることはないので、そういうところから精度向上を狙うのはちょっと難しいというのが1つ目の答えです。ただ、GitHub Copilotの実装面や、実際のLarge Language Modelのあり方、ベストプラクティスみたいなものが少しずつ確立されていくに連れて、精度が上がっていく可能性は十分あるかなと思います。

新谷：ありがとうございます。

自分たちのライブラリを作って発信をしていく人は増えていく

司会者：逆に服部さんからユーザー側に向けて「これ、どうです？」と聞いておきたいことはありますか？

服部：あります。ちょっとした知識を持っていたり、地頭が良かったりすると、GitHub CopilotやLarge Language Modelを使って、ものすごくいろいろなことが書けるという世界が今やってきていると思うんですね。

先ほどのお話の中に「好奇心」とありましたが、エンジニアとしてのスキルセットとして、もう少しソフトスキル的なところや、いわゆる学習意欲も含めてどうやって育成していくのかが課題になる気がしています。

そうした時に育成者の立場、もしくは「自分自身はこういう考えをしています」みたいなところで、ちょっとこれは難しい抽象的な質問ですし、自分自身の結果がチームメンバーのキャリアかもしれないですが、どうやって生き抜いていこうかみたいなところも含めて考えているのかを聞きたいなと思いました。

司会者：なるほど。これは発表順にいきましょうか。トピック的に司会者として、これはたださんにトリを飾ってほしいという気持ちがあるので、新谷さんには申し訳ないのですが、発表者順に。トップバッターに自社の社員に振りやすいという心理的安全性もあるので（笑）。お願いします。

新谷：キャリアみたいな話でいうと、やはり自分の発表にあったように、アプリケーションコードベースのいろいろなライブラリを利用する側から作る側に、よりなりやすくなっていると自分は思っています。他のライブラリを使うというよりも、やりながら自分たちのライブラリを作って発信をしていくのはぜんぜんやっていけると思います。GitHub Copilotが出てきたことによって、そういうのをやる人の母数はどんどん増えていくのかなと思っています。

コードのバックグラウンドを知ることが必要になってくる

池田将氏（以下、池田）：私は今はSREなので、コードを書く機会は減ってきていて、どちらかというと読む機会が増えているんですよね。読解力がすごく求められるようになってきています。エクスプレインの例を紹介しましたが、「言っていることがわからない」となってしまうと結局意味がないのかなと思います。

なので、コードの書き方を学ぶというよりは、そのコードはどういうバックグラウンドで書かれたのかなとか、なぜこのコードは簡単そうなのに複雑な書き方をしているんだろうとか、Javaのバーチャルマシンを意識した、メモリを意識した書き方をしているんだなとか。

あとはCopilotなしでも人間が見た時に見やすくするように、ちょっと効率は悪そうなんだけど、こういうふうに書いているんだなというところで、今後は知識のインプットが非常に必要になってくるんだろうなと思っていますね。

コードをただ書いて動けばいいと許されてきた時代があったかなと私も思うのですが、「そこはもうあなたの仕事じゃないよ」と最近すごく言われているような気がしているので、そのために知識のアウトプットなどをしないといけないのかなと思っています。

なので、今後はエンジニアになる方も、そういうところを意識したほうがいいかもなとは思っていて、そういうふうに指導はすると思います。

倫理観を持って意思決定をすることが求められる

黒瀧：そうですね。やはりCopilotや生成系AIが全部自動生成してくれたとして、最終的に人間がこれはOKか・NGかだけを判断するような世界になっていく時に、その責任を負うのは最後は人間になると思います。

その責任を取るところ、意思決定をするところはとりあえず人間だとした時に、Copilotが提案してきたものに対して、そのCopilotが、すべての事象やコンテキストを理解しているかというと、まだこれからやっていかなければならないことがあるので、Copilotが前提としているコンテキストの外にあるものをきちんと見極めて責任を取る、意思決定をすることが人間に求められるかなと思っています。

例えば「こういう提案が来たけど、これはCopilotが知らないコンテキストとして倫理観の面で良くないよね」みたいなものが出てきた時に、きちんと「これは採用しません」みたいな判断をしないとけっこうヤバいことになるかなと思っています。

例えばAIでバイアスみたいなものがあった時に、「バイアスがかかっているけど、動くからいいじゃん」「ちゃんと動いているからいいじゃん」みたいな感じで採用するんだけど、実はけっこう良くないことが書かれている。でもコンテキストが理解できなかった、みたいなことがあると良くないなと思っています。エンジニアが意思決定する時の倫理観というか、そういうところをきちんと教育しないと間違った方向に進む可能性があるのかなと思ったりしていました。

Copilotが提案できないドメイン知識が必要になる

ただただし氏（以下、ただただし）：だいたい言われちゃったので、どうしようと思っているんですけど。

（会場笑）

ただただし：freeeのプロダクトには「freee会計」という、10年選手の巨大なモノリスRailsアプリがあります。すごく大きな課題になっているのは、新しく入ってきた人が会計のソースコードを把握するのにメチャクチャ時間がかかることなんですよね。なので、先ほど言われていたように、コードリーディングに関しても補助としてはメチャクチャ助けになるんです。

一方で、いわゆるドメインロジック、要は日本の会計システムとか法律に則したコードにならないといけないのですが、間違いなくCopilotはそこを提案してくれないんですよ。汎用的なものはきちんと吐き出してくれるけど、アプリケーションロジックやドメイン知識が必要な部分をきちんと検証できるだけのドメイン知識を開発者は求めています。

なので、これからはそういうところが必要になってくるだろうし、そこを人間がきちんと持っていればCopilotとかでも開発速度が上がると思います。やはり開発者にとっては、今開発しているものがどういうドメインのものなのかとか、どんな人が使うのかみたいな部分もすごく大事だと思うし、そういうコンピューターよりも人間の世界に起きていることにより興味を持たなきゃいけないだろうと思うし、そっちのほうにもっと比重を置いた開発教育みたいなものをやっていく必要があるなと思っています。

司会者：では、ひととおり聞いた上で感想をどうぞ。

服部：ありがとうございます（笑）。勉強になります。そうですね。先ほど「ドメイン知識」というのもありましたが、ハイレベルなAIを凌駕する技術を持つか、ドメイン知識でビジネスロジックを含めて戦っていくのかという、2方向がなんとなくあるなと思います。改めてものすごく腑に落ちたなと思いました。ありがとうございます。

司会者：ありがとうございます。では以上でディスカッションパートを終了としたいと思います。服部さん、登壇者のみなさんありがとうございました。

（会場拍手）