【ITニュース解説】PVS-Studio team invites you to share examples of errors related to vibe coding

システムエンジニアを目指す初心者の皆さん、こんにちは。最近「vibe coding」という言葉が耳に入ってくるようになりました。これは、AIアシスタントを活用してコードを生成する新しい開発スタイルのことを指します。AIが瞬時にコードを生成してくれるため、ソフトウェア開発の現場では大きな注目を集めています。しかし、この新しいアプローチには期待と同時に、いくつかの重要な課題も存在します。

AIによるコード生成に対しては、二つの異なる見方があります。一つは、経営層や人事、効率化を重視するマネージャーたちの間で広まっている見方で、「ChatGPTのようなAIがすぐに全てのコードを書き、開発者は不要になるだろう」というものです。彼らは、数人の「プロンプトエンジニア」がいれば十分だと考え、AIに「オンラインストアを作って」と指示するだけで済む未来を想像しています。もう一つは、現場のシニア開発者たちの見方です。彼らは、AIが全てのコードを書くという考えに対して、現状では笑ってしまうほど現実離れしていると感じています。これは、ソフトウェア開発が単にコードを書く以上の複雑なプロセスであるという現実を知っているからでしょう。

私たちがAIによって生成されたコードを使う上で特に懸念されるのは、プログラマー自身がそのコードの仕組みを十分に理解しないまま利用してしまうことです。このような状況は、アプリケーションの安全性やセキュリティを損なう可能性があります。そのため、静的コードアナライザのようなツールにとって、AIが引き起こす可能性のある新しいタイプのエラーを見つけ出すことが、新たな挑戦となっています。AIが生成するコードにどのような種類のエラーが含まれるのかを理解し、特定するためには、まず具体的なエラー事例を収集することが不可欠です。

AIは、例えばソート関数のような単純で独立したタスクであれば、ほとんどエラーなくコードを生成できます。しかし、実際のプロジェクト開発は、個々の小さな機能の組み合わせだけでは済みません。プロジェクトが大規模で複雑になるにつれて、異なる機能やモジュール間の相互作用が複雑化し、エラーが発生する頻度が高まります。

先日、私の同僚がAIとの実験中に見つけた興味深いバグの事例を共有してくれました。彼は、Warningというクラスの比較メソッド（EqualsとGetHashCode）の実装をAIに依頼しました。Warningクラスには、エラーコード、メッセージ、レベルの他に、List<Position>というリスト型のメンバーが含まれています。

AIが生成したGetHashCodeメソッドのコードに問題がありました。特にhash = hash * 23 + (Trace?.GetHashCode() ?? 0);という行です。ここでTraceはList<Position>型であり、これは「参照型」と呼ばれるものです。参照型の場合、GetHashCode()メソッドを呼び出すと、リストの中身ではなく、そのリストがメモリ上のどこに存在するか（メモリアドレス）に基づいてハッシュコードが計算されてしまいます。

その結果、たとえ二つのWarningオブジェクトが全く同じ内容のErrorCode、Message、Level、そしてList<Position>（リスト内のPositionオブジェクトが全て同じで、同じ順序で並んでいる状態）を持っていたとしても、それらのList<Position>がメモリ上の異なる場所に存在していれば、異なるハッシュコードが生成されてしまうのです。これでは、論理的に「同じ」であるべき二つのオブジェクトが、プログラムからは「異なる」ものと判断されてしまいます。この問題により、リストのソート、重複の除去、フィルタリングといった標準的なアルゴリズムが正しく機能しないというバグが発生しました。

このようなエラーは、実は人間がコードを書く際にも起こしうる「古典的な」バグです。AIが生成するコードにも、人間が犯しがちなミスが含まれる可能性があることを示しています。PVS-Studioのような静的アナライザは、まだこのようなAI生成コード特有のエラーを検出するための診断ルールを全て持っているわけではありませんが、この事例を元に、新しいルールの実装を検討しています。

ここで、「なぜわざわざ静的アナライザを使うのか、別のAIにエラーを探させればいいのではないか」という疑問が浮かぶかもしれません。しかし、AIベースのツールが従来の静的アナライザを完全に置き換えることはないと考えられています。むしろ、静的アナライザの需要は今後さらに高まるかもしれません。その理由は、静的アナライザがソフトウェアの品質保証に対して「決定論的」なアプローチを提供できるからです。つまり、静的アナライザは、あらかじめ定義された明確なルールに基づいてコードを分析し、エラーを検出します。その検出メカニズムは人間にとって理解しやすく、診断ルールはドキュメントに記述されています。もし検出結果に疑問があれば、開発者に問い合わせたり、ツールの改善を提案したりすることも可能です。

一方、AIにコードレビューをさせることにはいくつかの大きな課題があります。一つは、多くの企業が自社のソースコードの外部流出を非常に懸念していることです。企業の機密情報であるコードを第三者のAIサービスに送ることは、セキュリティポリシー上許されない場合がほとんどです。この問題を解決するために、自社環境にAIシステムを導入する「オンプレミスAI」という選択肢もありますが、これは開発コストを大幅に増加させます。

二つ目の課題は、「誰が責任を負うのか」という問題です。もしAIが脆弱性のあるコードを生成し、別のAIがそれを検出できなかった場合、誰がその責任を取るのでしょうか。プログラマーはAIが生成したコードの原理を完全に理解していない可能性があり、AIシステムの開発者も生成コードの脆弱性について責任を負う立場ではありません。このような状況では、バグや脆弱性が発見されても責任の所在が不明確になってしまい、根本的な解決が難しくなります。また、AIがどのようなデータで学習されているのかも不透明であり、意図的に脆弱なコードが学習データに紛れ込んでいる可能性も否定できません。

このような状況を考えると、安全なソフトウェア開発を確実にするためには、静的コード分析のような「決定論的」で透明性の高いプロセスが不可欠です。静的アナライザは全ての脆弱性を検出できるわけではありませんが、その動作原理が明確であるため、開発プロセスに信頼性と安定性をもたらします。

PVS-Studioは現時点ではエラー検出にAIアルゴリズムを利用していません。しかし、将来的にこの分野での実験を検討しているのは事実です。仮にAIが導入されたとしても、それは既存のバグ検出技術に加わる「もう一つの技術」として位置づけられます。AIベースの検出は「経験的」、つまり統計的な性質を持つため、その特性はドキュメントで明確に説明されるでしょう。PVS-Studioは、AIによって既存の検出方法を全て書き換える意図はなく、むしろ「vibe coding」の時代においても従来の「古典的なアルゴリズム」の価値を高く評価しています。AIは、誤検知のフィルタリングなど、人間がすぐに誤りだと気づくようなケースをシステム的に排除するのが難しい場面で特に有効かもしれません。

私たちは、AIアシスタントを活用した「vibe coding」の過程で発生したバグの事例を皆さんから広く募集しています。AIが生成したコードを人間が手動で修正した際に生じたバグや、一見動作しているように見えても、少し変更を加えるだけで簡単に壊れてしまうような「コードの臭い（Code Smells）」に関する事例も大変興味深いです。静的アナライザは、単なるエラーだけでなく、このようなコード品質上の問題も指摘できるからです。皆さんの共有してくださる事例は、PVS-Studioチームが新しい診断ルールを開発する上で非常に貴重な情報源となります。そして、それが最終的には、プログラマーの皆さんがより高品質で安全なコードを開発するためのツールへと還元されることになります。これは、私たちチームとプログラマーコミュニティの双方にとって有益な協力関係だと考えています。

最後に、この解説文は、アンドレイ・カルポフ氏による元の記事の内容に基づき、AIの助けを借りずに人間が執筆したものです。