Beyond Resolved Rate: A Non-Functional Quality Study
この研究は、新しいAIモデルは以前のバージョンよりも多くのリポジトリレベルのコーディングタスクを解決しているものの、両方の世代が共に解決したタスクにおいて、静的解析、コードの複雑性、あるいはリソース使用量といった非機能的な品質指標については、一貫した改善を示していないことを明らかにしている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
コンピューターがコードを書くことを学習し、バグを修正し、機能を構築し、さらにはソフトウェアプロジェクト全体をリファクタリングさえできる、疲れを知らないジュニアプログラマーとして振る舞う世界を想像してみてください。これが、ソフトウェアエンジニアリングにおける大規模言語モデル（LLM）の領域です。長い間、私たちはこれらのデジタルコーダーを評価する際、「彼らはバグを修正できたか？」という単純な質問をするだけでした。もしコードがテストに合格すれば、金メダルが与えられました。これは「機能的正確性」と呼ばれます。しかし、車のエンジンがかかったからといって、ブレーキが効いているか、塗装が耐久性に優れているか、あるいは燃費が良いとは限りません。現実の世界では、ソフトウェアは安全であり、後で更新しやすく、コンピューターをクラッシュさせないほど高速である必要があります。これらは「非機能的品質」です。研究者たちが今投げかけている大きな疑問は、これらのAIモデルがより賢く新しくなるにつれて、単に目の前の問題を解決するのが上手くなっているだけなのか、それともよりクリーンで安全で効率的なコードを書けるようになっているのか、ということです。
「Beyond Resolved Rate（解決率を超えて）」と題されたこの論文は、まさにその謎に切り込んでいます。スウェーデンのリンショーピン大学の研究チームは、AIが修正したバグの数を数えるのをやめ、どのように修正したかを検査することに決めました。彼らはAIモデルを、料理コンテストの出場者のように扱いました。審査員（研究者）は彼らに特定のタスクを与えました。それは、壊れたレシピ（ソフトウェアプロジェクト内のバグ）を直すことです。古いモデルはベテランであり、新しいモデルは期待の新人でした。目標は、単に正しい味の料理を提供できたか（テストに合格したか）を見るだけでなく、新しいシェフがより良い食材を使い、無駄を減らし、次の料理人のためにキッチンをより安全にしているかを確認することでした。
研究者たちは、実世界のソフトウェア修復タスクを含む、SWE-bench Liteと呼ばれる人気のあるベンチマークを使用して、厳格な実験を設定しました。彼らは、商用モデルの「Claude」ファミリーとオープンソースの「DeepSeek」ファミリーという、2つの異なる系統の2世代のモデルを対決させました。彼らは、生成されたパッチ（コードの修正）を取り出し、一連のハイテクな検査にかけました。CodeQLやCodeSceneのようなツールを使用して、セキュリティリスク、乱れたコード構造、およびメンテナンス性の問題をスキャンしました。また、コードの実行時間を計測し、メモリをどれだけ消費したかを測定しました。これは、コンピューターを、効率的に餌を与えなければならない飢えた獣のように扱うものです。
結果は、ちょっとしたどんでん返しとなりました。新しい「より賢い」モデルは、間違いなくより多くのバグを修正しました。彼らは以前の兄弟たちよりも多くの事例を解決し、より高い「解決率」を獲得しました。しかし、両方のモデルが解決できたタスクについてコードの品質を調査したところ、物語は変わりました。新しいモデルは、非機能的品質において一貫した改善を示さなかったのです。実際、データは、新しいモデルが古いモデルと同様に、コードの臭い（コードスメル）、セキュリティリスク、またはパフォーマンスの不具合を導入する可能性があることを示唆していました。
具体的には、本研究では、両方のモデルが解決したタスクにおいて、新しいモデルがよりクリーンなコードを生成したわけではないことが判明しました。静的解析ツールによれば、新たに導入された問題の数は、両方の世代でほぼ同じでした。パフォーマンスの面では、新しいモデルの方がわずかにリソースに対して「強欲」でした。共通のタスクにおいて、新しいClaudeモデルは、古いものよりも約0.048秒長くCPU時間を消費し、ピークメモリを約4.5 MiB多く使用しました。新しいDeepSeekモデルは約0.5 MiB多くのメモリを使用しました。これらの数値は小さいものですが、バグを修正することに長けていることが、必ずしも効率的なコードを書くことに長けていることを意味しないことを示しています。
著者らはまた、コードの「風味」についても調査しました。彼らは、紛らわしい変数名や乱れたインポートといった、特定の悪い習慣を新しいモデルが避けているかどうかをチェックしました。結果は混在しており、一貫性がありませんでした。ある時は新しいモデルの方が特定のルールにおいて優れており、またある時は古いモデルの方が優れており、新しい世代が普遍的に優れているという明確な傾向は見られませんでした。
結局のところ、この論文は、AIモデルは「何をするか」（バグを直すこと）については上手くなっているものの、単に新しくなったという理由だけで、「どのようにするか」（高品質でメンテナンスしやすいコードを書くこと）については必ずしも上手くなっているわけではないことを示唆しています。著者らは、バグ修正の成功率が高いことは、ソフトウェアエンジニアリング全体の質を保証するものではないと警告しています。彼らは、デジタルアシスタントが現実世界でどのように機能しているかを真に理解するためには、単純な合格/不合格のスコアを超えて、セキュリティリスクやメンテナンスの負担といった「隠れたコスト」を測定する必要があると主張しています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。