AIコーディングの品質はどう担保する？

こんにちは、横井です。

今回は、AIコーディングにおける品質担保についてです。以前の記事でも触れたように、LLM（大規模言語モデル）が学習済みのアーキテクチャやデザインパターン、アルゴリズムを活用すれば、人間が苦労して作業するよりも遥かに高速にコーディングが可能になります。しかしそれと、実際に要件や仕様を満たしたコードが得られているかどうかは、また別の問題です。

まず、LLMの種類によってもコーディングの品質は大きく異なります。私自身は(コーディングのさせ方にも影響されるのでしょうが)、Claude 3.5 Sonnet 一択です。最近リリースされ、評判の高いGemini 2.0 Proについては、私にはあまり合わない印象を受けました。いかにマネジメント方法でコーディングをコントロールできるように見えても、実際には要件を無視したコードや、途中で省略されたコードが生成され、期待外れとなるケースが多々ありました。無償なのでなんとか使いこなそうと試みるものの、金銭面では節約できても、結果として時間がかかり、満足度が低くなってしまうという現実もあります。

次に、仕様通りのコーディングが実現されているかどうかという点ですが、結局のところ、テストを行って確認するしかありません。幸い、現在では多様なテストツールが存在します。私も色々とテストコードをAIコーディングしてみましたが、実際に試してみると、ソースコードとテストコードの両方が作成された後、テスト実行でエラーが発生した際に、どちらに原因があるのか判断がつかなくなり、場合によってはテストコード自体を修正してしまうこともあるのです。こうなると、テストコードの実装が問題なのか、テストケースそのものが変わってしまっているのかが不明瞭となり、混乱を招きます。

また、以前にも書きましたが、テストエラー発生→エラー修正→テスト再実行→テストエラー発生と修正とエラーの無限ループも起きがちです。どうしても視野が局所的になり、局所的な修正になるので、あちらを直せばこちらがおかしくなる。みたいな事になってしまいます。

そこで、テスト実行後にいきなり修正を加えるのではなく、テスト結果をまずファイルに出力し、エラー(Test Fail)が発生した場合は原因と対応策もファイルに追記するテストレポートの作成を義務付けるなどのルールを設ける事で、いきなり修正→エラー頻発といった負の連鎖を防ぐ事ができます。

この様にコードを自動的に生成してくれるといっても、その品質を担保するためには色々な工夫が必要になってきます。

では。