コードのずさんさを測る：冗長性と侵食の指標

LLMはテストに合格するコードを生成するのが非常に上手くなりました。しかし、正確なコードでも雑になることがあります。重複した行、不要な抽象化、悪い設計判断でいっぱいになるのです。著者が指摘するように、「コードが形式的に正確だからといって、不要な抽象化を導入したり、重複を作成したり、全体的に悪い決定を下したりしていないわけではない」のです。その結果、コード行数（LOC）が爆発的に増え、人間が追いつくのが難しくなります。そして、一部の主張に反して、エージェントもこの雑さを管理できません。

LLMを審判として使うのがうまくいかない理由

この記事は、AIを使ってコード品質を判断するという一般的な業界アプローチを否定します。モデルにコードを1～10で評価させるのは「基本的に乱数生成器と同じ」です。ペアワイズ比較（A対B）は不安定で、ソリューションの名前を変えるだけでモデルの好みが反転することがあります。ルーブリックやLLMが書いたテストは役立ちますが、「実際に雑さを取り除くにはほど遠い」のです。

最も単純な指標：LOCの変化

驚くほど効果的です。単にコード行数の変化を追跡するだけです。著者は皮肉を込めてこう述べています。「もしそれを最適化し始めたら、意味のある指標ではなくなるだろう」と。

冗長性

重複した行や不要に冗長な行を測定します。AST-Grepでフラグが立てられた行またはクローンとしてマークされた行の割合を、総LOCで割ったものです。

冗長性 = |AST-Grepでフラグが立てられた行 ∪ クローン行| / LOC

侵食

コードベースの質量が、いくつかの大きく複雑な関数にどれだけ集中しているかを測定します。まず関数の質量を定義します。

質量(f) = CC(f) * sqrt(SLOC(f))

ここでCC(f)は循環的複雑度、SLOC(f)はソースコード行数です。次に侵食は、循環的複雑度が10を超える関数が総質量に占める割合です。

侵食 = ∑_{f: CC(f) > 10} 質量(f) / ∑_f 質量(f)

論文SlopCodeBenchで導入されたこれら2つの指標は、著者のテストでは、レガシーコードベースとLLMが生成した雑なコードをかなりうまく区別しました。

要点

• LLM審判はコード品質に対して信頼できない。名前を変えると好みが反転する。
• LOCの変化は驚くほど強力な雑さのシグナルだが、直接最適化すると壊れる。
• 冗長性はAST-Grepフラグとクローン検出をLOCで割ったものを組み合わせる。
• 侵食はCC > 10の関数における複雑度の質量を捉える。

LLM生成コードを大規模に提供するチームにとって、これらの指標は感覚に基づく評価に代わる定量的な選択肢を提供します。