この記事はNTTコムウェア AdventCalendar 2024 25日目の記事です。
こんにちは、NTTコムウェアの高鶴です。昨年のアドカレ(2023)では、Rustの記事を書きました。
最近、身の回りの話題はソフトウェア開発用AIの話が結構な割合を占めていて(開発手法を全社に展開するお役目なのでこのご時世ならそりゃそうなる)、アマノジャクの私としては全然違う話題でやってみたい気持ちもあるのですが、ちょっとでも注目してもらえる記事を書きたいという欲に負けて(笑)、AIのことを書きます。
あまり科学的な根拠があるわけではないポエムですよ、と最初に言い訳しておきますので、気楽に読んでください。
いろんな人が研究したり意見を述べたりしている分野ですし、思うところがある人もたくさんいるのではないかと思います。皆さんの考えをコメントして盛り上げていただけるとありがたいです。
AIコーディングアシスタント
私の担当は、開発手法の中でも、プログラミング技術に焦点を当てた活動をしているので、その中でAIコーディングアシスタントのGitHub Copilotの社内展開もしています。
ChatGPTなどのチャット式のものと比べ、エディタを立ち上げるだけでカーソル位置からのコード提案が始まるので、「よーし、AIを使ってやろう！」と頑張って意識しなくても使えるところが素晴らしいと思っています。アクティブスキルよりもパッシブスキルの方が強い、みたいな感じです。
さて、AIコーディングアシスタントには肯定的な意見の方が多い感じがしますが、否定的な意見もあります。ただし、肯定的な意見は、Qiitaを見に来るような人には釈迦に説法だと思いますので、この記事では省きます。
影の部分
否定的な意見としてはどのようなものがあるでしょうか？私が感じていることや、聞いたことがあるものを挙げてみます。
主に、コードアシスト機能(チャットでのコード生成ではなく)にフォーカスを当てた内容を書きます。
提案されたコードが本当に合っているかどうかがわからない
提案内容が本当に合っているか、結局検証を自力でやらないといけない
型推論等のルールベースのコードアシストの方が、確実で頼りになる
これらの原因は、AIについてよく言われる「ハルシネーション(幻覚)」によるものだけとは限りません。コードを提案するとき、(提案の性能を上げるため等で)関連するコードや周辺の情報を十分に与えていないために、的外れな提案をする、というのも原因の一つです。
また、提案の元ネタは過去に公開されたコードであるため、例えばAPI呼び出しなどのコードは、APIの仕様をキッチリ調べた上での提案でないかもしれないことにも注意を要します。よくある間違いをそのままなぞってしまいそうです。
むしろ、型情報等からルールベースで推論されるコードの方が、提案内容は少ないものの、調べなくても正確であることがわかっているため、頼りになることが多いような気もしてきます。
勝手に表示されるコード提案がむしろ目障り
提案されたことでむしろ気が散る
提案が的外れでだんだん腹が立ってくる
実際、イヤイヤ書いているときにはコード案をグレーの文字で提案してくれるのは大変ありがたいのですが、ゾーン状態に入っているときに余計な提案をされると、邪魔だなと感じます。
クローンコードを量産するハメになる
さっき書いたのと似たコードばかり出てくる
AIは周囲のコードを参考にして提案してくるので、さっき書いたのと似たようなコードを書くときに有利です。ということは、逆に考えると、保守性を考えた場合に本来避けるべきクローンコードを提案しがちになります。
クローンコードというのは、本来一つにまとめるべき似たようなコードを繰り返し書いてしまうことです。そうすると、何か一つの要素を変えたくなった時に、多数の箇所を修正する必要が生じるため、仕様変更のハードルが上がってしまいます。
プログラミング言語を設計するときの重要なテーマのひとつに、「まとめるべきコードをいかにうまくまとめられるか」というのがあります。誤解を恐れずに言えば、〇〇指向とか関数型とかそういったプログラミングパラダイムは、その願望を満たすために賢い人たちが一生懸命いろんな概念を考え出しているのです。
クローンコードを量産してしまうということは、そういった努力に反する方向に作用すると言えるかもしれません。
自分の頭で考える機会をもてない
(主にビギナー開発者が)AIで書いたコードを吟味せずにレビュー(PR)に上げてくる
これは、レビューさせられるベテラン開発者にとっては頭が痛い話かもしれません。
ビギナー開発者はとにかく動くものを作るのに必死なので、「AIに提案してもらって、とりあえず動くものができた」状態でコードを提出してきます。そのコードは、標準ライブラリを使えば不要なコードであったり、APIの仕様を勘違いしたものであったり、エラーの想定が漏れていたりします。
AIに書いてもらったコードの問題は、レビューアであるベテラン開発者が「なぜこのようなコードを書いたのか？」を質問した時、レビューイ（コードを提出した人）がちゃんと答えられない（自分が考えてないので）という問題があります。
ただでさえ、ビギナー開発者の生産性はマイナスなのが実態とも言われて(誰が?)いる中で、レビューを通じた育成がやりにくくなってしまったら、ベテランにとっては徒労感があるのではないかと思います。
ビギナー向け？ベテラン向け？
ビギナー向けか？
前述の通り、ビギナーに使ってもらう場合は注意が必要です。正確さが求められるコードでは、まずAIの出力を疑ってセルフレビューさせるところからの意識づけが必要だと思います。
何も考えずに使ってもらってよいのは、とりあえず今使えればよいだけの使い捨てのコード（データ解析など）に限られるのではないかと思います。
ベテラン向けか？
中級者以上になると、そもそもAIを使って時短できる部分がそれほど大きくないと思います。
コードをカタカタ書いている時間はむしろ少なく、大半がAPIリファレンスを調べたり、（オープンソースであれば）ライブラリのソースコードを眺めながら、自分がやろうとしていることに対する正しいやり方が何かを調べている時間だからです。
欲しい処理に対してみんなが良く書きがちなコード例を提案させ、そこを調査の入り口にするような使い方が良いかもしれません。やる気が起きないときに、とりあえずコード例を示してもらうことで作業のやる気を引き起こしてもらうなどの心理的な効果も考えられます。
まとめ
AIコーディングアシスタントの悪い面ばかり書いた気がしますが、もちろん、良い点の説明をこの記事では省略しただけで、基本的には有用なツールだと思っています。
ただ、AIの利用に対する考え方を開発者とある程度ディスカッションしておかないと、いろんなモヤモヤが起きそう気がしています。
そういったものを、皆さんと共有できることに少しでもお役に立てればうれしいです。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。