SonarQube AdventCalendar の 5 日目の記事です。遅れて公開ですみません。。

AdventCalendar 向けの記事書くにあたって、何か面白いネタはないかなと考えていた際に、以前 Sonar ブログで面白い記事／レポートがあるよと教えてもらっていたのを思い出し、読んでみました。非常に興味深かったので、SonarQube の How to 的な内容ではないですが、紹介してみたいと思います。

参照した Sonar ブログの記事およびレポートは以下となります。

The Coding Personalities of Leading LLMs（記事とレポートのURL）

タイトルを直訳すると主要な LLM のコーディングにおける性格で、記事の趣旨としては LLM の能力は 問題を解く能力 だけじゃないはずと問題提起し、その性質を LLM ごとに紐解こうというものです。

イントロダクションの章では、これらの性質を理解することで、AIを活用した開発を行う際、より良い成果につながるのではとされています。

なぜ Sonar がこのレポートを作ったか

Sonar が開発した SonarQube は静的解析ツールとして、脆弱性の問題検出だけではなく、不具合につながる信頼性の問題や、コードスメルなど保守性に関わる問題を検出できるものとなっています。

Sonar であれば、この SonarQube の解析エンジンを利用し、世に出ている様々なベンチマーク課題に対して、それぞれの LLM が解法を掲示した際、正しく機能したかどうかだけではなく、その解法にどのような性質が含まれるかが評価できます。

おそらくですが、生成 AI を活用した開発がメインストリームとなってきている中で、その品質評価の必要性と、製品としての有用性のアピールが狙いになっているのかなと思います。

評価の対象・方法

評価の対象としては以下の LLM が代表として選ばれていました。少し古めの LLM が中心になっていますね。GPT-5-minimal はレポートに後日追加実験行い追記されたようです。

GPT-5-minimal
Claude Sonnet 4
Claude 3.7 Sonnet
GPT-4o
Llama 3.2 90B
OpenCoder-8B

解かせるベンチーマーク課題は以下みたいです。合計で 4,442 件の課題となっているとのこと。

MultiPL-E-mbpp-java: 問題文+入出力例から回答コードを作る課題
MultiPL-E-humaneval-java: 関数ドキュメント＋シグネチャから本体生成といった課題
ComplexCodeEval: 仕様文からコードを作る課題、複雑度高め
etc...

SonarQube 自体はメジャーな開発言語は軒並み対応していますが、今回は Java を対象としているようです。Java 向けの静的解析エンジンとして開発がスタートし、一番解析の機能も充実しているからかと思います。

測定項目としては、以下のようなものを行い評価行ったようです。

課題のテストケースにクリアできたか
コード生成 1 回目でクリアできたか
冗長性（機能実装に対しての LOC で判定）
コメント量
循環的複雑度
認知的複雑度
信頼性
脆弱性
保守性

結果

レポートは以下のような流れでまとめられていました。

共通の強み
共通の弱み
個別の特性

それぞれ紹介していきます。

共通の強み

共通的な強みとして以下の 3 点があげられていました。

正しい構文での出力精度の高さ
アルゴリズム問題での正解率の高さ
他の開発言語への翻訳能力の高さ

測定結果引用します。

表 1: MultiPL-E Java ベンチマークでの LLM の性能

複数ベンチマーク GPT-5-minimal Claude Sonnet 4 Claude 3.7 Sonnet GPT-4o Llama 3.2 90B OpenCoder-8B

HumanEval（158 課題） 91.77% 95.57% 84.28% 73.42% 61.64% 64.36%

MBPP（385 課題） 68.13% 69.43% 67.62% 68.13% 61.40% 58.81%

加重平均 Pass@1 (テスト) 75.37% 77.04% 72.46% 69.67% 61.47% 60.43%

(引用元: https://www.sonarsource.com/resources/the-coding-personalities-of-leading-llms/ を LLM で日本語訳)

HumanEval 課題ではその正答に構文の正しさが必要なため、正答率＝構文の出力精度ととらえることができ、全体として非常に高い精度が見て取れる。

また課題の解決能力については、コード生成 1 回目でクリアできたかを示す Pass@1 指標が参考になり、これも全体的に精度高く GPT-5 や Claude Sonnet 4 などで特に高い精度が確認できた。

他の開発言語への翻訳能力の高さについては、レポート内で触れてはいるが、何を根拠にしたかの記述は見つからなかったです。（実際にはそういう課題が含まれていたのかな？。。。）ただ、私の感覚としても開発言語間でのマイグレーションは非常に高い精度で可能な印象ありますね。

共通の弱み

次に共通的な弱みについての内容について紹介します。

共通的な弱みについては主に以下の 3 点あげられていました。

セキュリティ意識の⽋如
ルールや規律から外れた実装
保守性の低いコードの生成

それぞれ SonarQube で解析対象の脆弱性、信頼性、保守性と対応していますね。

セキュリティ意識の⽋如

今回の検証の結果、すべての LLM において、セキュリティ的な配慮が少ないという傾向と評価されています。

特に GPT-5-minimal 以外の非推論モデルでは致命的な問題とされる BLOCKER レベルの脆弱性が多く検出されたとのこと。GPT-5-minimal では脆弱性の密度は 3-6 倍低くなったが、検出した問題の比率としては 不⼗分な I/O エラー処理 が飛びぬけて多く検出されたとのことで、特徴が出ています。

レポートでは、この原因を、ハルシネーションによるものではなく、設計と学習の構造的な欠陥に根ざしているとしていました。設計としては LLM は、局所的な実装には強いですが、インジェクションへの配慮などデータの流れを考慮した実装は難しいようすとのこと。また学習については、基本的にはインターネットで公開されているコードが利用されますが、コード例などではシンプルさを優先し、秘匿すべきデータがハードコードされることもあり、それを学習した LLM は問題として認識できなくなってしまうとのこと。

ルールや規律から外れた実装

脆弱性と同様にすべての LLM で見られた弱みとして、ルールや規律から外れたコードを書く傾向があったとのこと。

例えばですが「ファイルストリームを閉じない」「エラーの戻り値無視」などの API 利用の規約違反がありました。GPT-5-minimal だけの傾向も少しあり、並列処理／スレッド関連の問題の比率が高くなっていたとのこと。

レポートの中では、推論モデルの GPT-5-minimal ではーと説明されている箇所ありましたが、推論モデルであることが原因なのか、GPT-5 自体の特徴なのかまでは読み取れませんでした。

保守性の低いコードの生成

3 つ目の弱みは、保守性の低いコードを生成しがちというものです。SonarQube ではメンテナンスへの影響が示唆するコードスメルに関する問題も発見できるのですが、今回の検証では、コードスメルに関する問題が非常に多く検出されたとのこと。GPT-5-minimal では、正確性やセキュリティ考慮が他の LLM に比べ高い性能を示す代わりとして、コードが複雑化しやすく、結果としてこの保守性の観点では、深刻度の高いコードスメルを生んでいると評価されていました。

個別の特性

共通の強み／弱みで説明した通り、共通の傾向を見せているものの、実際のコードの印象ではしっかりと差が感じられるとのことで、レポートではその原因が冗長性／複雑性／コメントにあるとし、この 3 分類の傾向をまとめ、個別の特性としています。

冗長性

冗長性は今回使用した課題 4,442 に対するコード生成量を使い評価しています。非常に特徴が出ており、GPT-5-minimal は⾮常に冗⻑で、490,010 ⾏を生成したのに対し、OpenCoder-8B は 120,288 ⾏を生成したとのこと。

複雑性

複雑性の評価は、循環的複雑度や認知的複雑度を測定したとのこと。これも冗長性と同じく、GPT-5-minimal は⾮常に複雑性の高いコード生成となり認知的複雑度スコアは 111,133 となったとのこと、対して OpenCoder-8B では 13,965 にとどまったとのこと。

コメント

レポートでは、コメントの密度にも特性が出ているとしています。
Claude 3.7 Sonnet はコメント量が多く 16.4%、対照的に GPT-5-minimal は 2.1% となっていたとのこと。

LLM タイプと、まとめ

結果を受けレポートでは LLM をタイプ分けしています。特性含めた表でまとまっていたので引用します。

表 8: LLM コーディング・アーキタイプまとめ

LLM アーキタイプ機能スキル（合格率%）問題密度（Issues/KLOC）冗長性（LOC）認知的複雑度支配的な欠陥タイプ（全問題比）

GPT-5-minimal ベースライン・パフォーマー 75.37% 26.65 490,010 111,133 94.87% コードスメル

Claude Sonnet 4 シニアアーキテクト 77.04% 19.48 370,816 47,649 92.2% コードスメル

Claude 3.7 Sonnet バランス型の先代 72.46% 22.82 288,126 42,220 92.9% コードスメル

GPT-4o 効率的なゼネラリスト 69.67% 26.08 209,994 26,450 90.5% コードスメル

Llama 3.2 90B 未完の約束 61.47% 26.20 196,927 20,811 89.9% コードスメル

OpenCoder-8B 高速プロトタイパー 60.43% 32.45 120,288 13,965 92.0% コードスメル

(引用元: https://www.sonarsource.com/resources/the-coding-personalities-of-leading-llms/ を LLM で日本語訳)

レポートの各 LLM の特性について、抜粋しまとめます。

LLM	特性
GPT-5-minimal	高性能だが冗長複雑、クリティカルなコードスメル多発
Claude Sonnet 4	高度で洗練もリソースリークや並列バグが隠れる
Claude 3.7 Sonnet	コメント豊富で読みやすいが重大脆弱性を抱える
GPT-4o	汎用性高いが制御フロー誤りが多い
Llama 3.2 90B	潜在力ありも性能平凡、BLOCKER 脆弱性最多
OpenCoder-8B	最速生成だが不要コードと欠陥密度が最大

それぞれ得手不得手ありつつも、やはり手放しで安心して利用できるというものはないという結論のようです。

また、新しい LLM でも正答率は上がるが、複雑度も高くなる傾向が説明されており、これにどう対応していくかが、今後の LLM 活用のカギになりそうです。

今回のレポートに関連しての紹介ですが、SonarQube では LLM のコーディング品質を向上させる SonarSweep というサービスを始めるようです。

それぞれの LLM が学習に利用するインプットデータを、 SonarQube の解析エンジン使いクレンジングすることで、LLM の出力するコード品質を上げるという仕組みのようです。
自身が直接利用するものはないですが、間接的に恩恵を得られそうで、面白いサービスだなと感じました。

紹介としては以上です。今回の内容で少しでも SonarQube に興味湧いてもらえると嬉しいです。

クレスコでは、SonarQube の日本語化プラグインを作ったりしています。ぜひそちらもご参照ください。