生成AIができることできないことを理解する
森崎氏の説明を受けてやっとむ氏は、「生成AIは100％ではないが、できることはできる。網羅しているように見えていくつかこぼしている。生成AIに完全に任せるわけにはいかないので、第一次のアウトプットとして生成AIに出力してもらい、それを人間が手直しする使い方が良いのかもしれない」と感想を語った。
この意見を受けて森崎氏は、「今のところ、生成AIをどのように使えば最も良いのか、正解は、見付かっていない。騙されることを防ぐのが重要だ」と返し、「今の段階でできることとしては、類推がそれほど必要ないものを渡すということが挙げられる」と付け加えた。
さらに森崎氏は、「途中まで作られていると、つい信用してしまいがち。細部が良くできていると、全体が正しいと思ってしまうことがある。しかし生成AIの回答には間違いが入っていることもある。回答を採用するかどうかを注意して見極める目を養うことが現時点でできること」と、生成AIとの付き合い方を提案した。
和田氏は、すでに現場で生成AIを活用している立場から、「結果に対する期待値のコントロールはそれなりにできるようになってきたと思う」と感想を述べた。そして生成AIについて「正解を出すものではなく、人間が指示を出して生成AIが出してきたものを人間がレビューして、採用するか否か、あるいは修正するという業務の流れは変わらない。自分がほしいものを作ってもらったり、やりたいことを代わりにやってもらったりする。その後は手直しだけで済むので、面倒が少ないという感じで使うもの」と語った。
今後の人と生成AIとの付き合い方とは？
ここで、人間がコードを読むときに生成AIをどう使うのかを調べるために自身で計画、実施した実験について、森崎氏が説明を始めた。この実験には和田氏も協力している。この実験では、条件分岐が複雑で構造を把握しにくいコードと、命名に問題があるコードの2種類を用意し、実験の参加者が生成AIを利用してどのようにコードを読み解くのかを調べた。
実験に使ったコードは約400行のもので、実験には52名が参加した。生成AIを使ってコードの読解に挑戦した後の参加者にクイズを出題し、その回答から理解度を確認した。参加者には自身が使っている生成AIツールを持参するように依頼したため、使っているツールはそれぞれバラバラだ。そして参加者には、生成AIを使わなくても分かる場合は、使わずにそのまま回答するようにお願いしたとしている。
検証の結果、構造が複雑なコードと、命名に問題があるコードをそれぞれ読み解く時間の間には、統計的に有意な差はなかった。ただし、今回の実験では参加者数（サンプル数）が少ないため、小さな差は検出できないという。
とはいえ、先行研究から人間は構造に問題があるコードよりも、命名に問題があるコードに騙されやすいことが明らかになっている。この点を考えると、今回の実験では生成AIを使うことで、命名に問題があるコードで読み間違いにくくなったとも言えるそうだ。
森崎氏は総括として、「生成AIが間違うと人間も引っ張られやすい。クイズが難しいと、生成AIも間違いがち。そして、それに人間も引っ張られがち。クイズが簡単であれば人間が生成AIを使わずに自力で解答した方が速かった」とコメントした。
実験の説明を受けて和田氏は「現時点では生成AIに答えを求めようとすると大体失敗する。現場では生成AIを壁打ち相手や議論相手として使おうと言われている。壁打ち相手や議論相手には正しさは求めない。それよりも素早く所感を返してほしい。そうすることで初動が早くなる。そういう意味では、生成AIは支援なのだと思う」と感想を述べた。
さらに和田氏は、生成AIが「明らかに破壊的な技術」だとした上で、ソフトウェアエンジニアとしては破壊的な技術を無視してしまうとキャリアが終わってしまうと警告した。そして、ソフトウェアエンジニアは生成AIと付き合っていかなければならないし、上手く付き合う方法を考えていく必要があると語った。
また、破壊的な技術が登場すると、「これさえあればすべてが何とかなる」と極端な思考に陥る人がいることを指摘し、「プログラミングを勉強しなくても生成AIがやってくれるから大丈夫だろう」と考える人もいるかもしれないとした上で、生成AIは省力化の役には立つが、能力不足を補うものではないと指摘した。和田氏は現場で「労力は外注できるが、能力は外注できない」と言っているそうだ。
最後に和田氏は、ソフトウェアエンジニアはスキルアップから逃れることはできないが、生成AIによってスキルアップのスピードを上げることができる。これでイテレーションが圧倒的に早くなる。今後数年はこのような形で付き合っていくべきではないかと語り、セッションを締めくくった。
