コード品質：LLM は人間より優れているのか？

AI生成コードに関する最近の実証研究を批判的に見る

生成AIや大規模言語モデル（LLM）を巡る盛り上がりの中で、「ソフトウェア開発者は不要になる」、「AIは人間より良いコードを書く」、「人間のプログラマの時代は終わりに近づいている」といった大胆な主張が数多く語られています。しかし、それらの主張のどれほどが、実際に実証的な証拠に裏付けられているのでしょうか。2025年に IEEE/ACM International Conference on Mining Software Repositories（MSR）で発表された研究は、この問いに対して本格的な実証的アプローチを試みています。MSR は、ソフトウェア工学研究分野におけるトップクラスの国際会議の一つです。

この論文は、Jamil、Abid、Shamail による「Can LLMs Generate Higher Quality Code Than Humans? An Empirical Study」¹⁾ です。本記事では、彼らが何を行い、どのような結果を得たのか、そしてより重要な点として、その結果から「分からないこと」は何かを整理します。

なお、以下では一つの研究に深く踏み込むことを目的としています。この分野に関するすべての論文を要約することを目指しているわけではありません。そのような試みは、どうしても表面的な内容になってしまうためです。

この研究が目指したこと

研究者たちは、次の2つの問いを設定しました。

• GPT モデルは、人間より高品質なコードを生成できるのか？
• どのプロンプト形式と GPT モデルの組み合わせが、最も良い結果を生むのか？

彼らは ChatGPT の2つのバージョン、GPT-3.5-Turbo と GPT-4 を比較しました。また、プロンプトの詳細度を3段階に分けて評価しました。

• Basic：関数のタスク説明と docstring のみ
• Intermediate：テストケースと構造上のヒントを追加（例：関数名を変更しない、構文エラーを避ける）
• Detailed：さらに、最適化、可読性、セキュリティに関する要求を追加

これにより、合計6種類の組み合わせが作られました。比較対象となったのは、HumanEval ベンチマークに含まれる、人間が記述した Python コードです。HumanEval は OpenAI が LLM のコーディング能力評価のために作成したデータセットで、164個の Python 関数から構成されています。

「品質」をどのように測定したのか

ここからが興味深く、同時に少し難しい部分です。

この研究では、「品質」を2つの観点から定義しています。

• 機能的正しさ（functional correctness）
  コードが実際に正しく動作するか
• 保守性（maintainability）
  コードが読みやすく、扱いやすいか

正しさについては、HumanEval に付属するテストケースを実行することで測定しています。保守性については、Radon、Complexipy、Bandit、Pylint などのツールを用いて、標準的なコードメトリクスを計算しています。

• LOC（Lines of Code） – コード行数
• Cyclomatic Complexity（CC） – 分岐の複雑さ
• Maintainability Index（MI） – 可読性・保守性を総合的に評価する指標
• Cognitive Complexity（CogC） – 人間が理解する難しさ
• Halstead metrics – 演算子やオペランドに基づく指標
• Bandit warnings – 潜在的なセキュリティ問題
• Pylint violations – スタイルやコーディング規約違反

 なお、Maintainability Index を除き、基本的には値が低いほど良いとされています。

これら複数のメトリクスを単一の評価結果にまとめるために、著者たちは TOPSIS（Technique for Order of Preference by Similarity to Ideal Solution）という意思決定手法を使用しています。これは、すべてのメトリクスにおいて理論上の「最良解」に最も近く、「最悪解」から最も遠い解を選ぶという考え方です。合理的なアプローチではありますが、「理想的な最良値・最悪値」をどう定義するかが必要になります。特に LOC のような指標では、それは簡単ではありません。

実際に研究結果は何を示していたのか

正確性について HumanEval に含まれる人手で書かれた関数は、定義上、すべてのテストに合格しています。そうでなければ、そのベンチマークには含まれません。一方、最も高い性能を示した LLM の組み合わせ（GPT-4 と最も詳細なプロンプト）であっても、164 個中 21 個の誤った関数を生成しており、失敗率はおよそ 18% でした。これは決して小さな数字ではありません。結論として、LLM が生成したコードにはバグが含まれている可能性が高いと言えます。テストやレビューは省略できません。

保守性について 研究者たちが「正しく生成された関数」のみに限定して比較を行ったところ、詳細なプロンプトを使用した GPT-4 は、多くのケースで優位な結果を示しました。具体的には、人手で書かれたコードと比較して、以下のような特徴を持つ関数を生成しています。

• 約 47% のケースで、コード行数（LOC）が少ない
• 約 34% のケースで、サイクロマティック複雑度が低い
• 約 39% のケースで、語彙数（Halstead V）が低い
• 約 54% のケースで、保守性指数（Maintainability Index）が低い
• 約 46% のケースで、認知的複雑度が低い

 著者らは、GPT-4 が「評価したすべての指標において優れた性能を示した」と説明しています。しかし、ここには注意すべき微妙な点があります。 

これらの数値をもう少し詳しく見る

この研究では、「生成コードが人手コードを上回ったケースの割合」が報告されています。しかし、「下回ったケースの割合」は示されていません。たとえば LOC（コード行数）を例にすると、生成コードが 47% のケースでより短かったということは、（両者が完全に同じであるケースを除けば）53% のケースではむしろ長かったことを意味します。このロジックで考えると、コード行数については、人手で書かれたコードのほうがより多くのケースで優れていたとも言えます。

著者らはこの逆の見方を強調していないため、結果の解釈がやや難しくなっています。この論文自体が誤解を招いているわけではありませんが、比較結果の一方だけを強調すると、実態以上に楽観的な印象を与える可能性があります。 

さらに、より本質的な方法論上の疑問もあります。そもそも、これらの指標は本当に保守性の適切な代理指標なのでしょうか。ソフトウェア工学の研究は数十年にわたって行われていますが、これらの指標の多くが「実際にコードの保守がどれだけ難しいか」を信頼性高く予測できることは、まだ決定的には証明されていません。コードが短いからといって、必ずしも優れたコードとは限りません。複雑度が低いからといって、常に読みやすいとも限りません。また、静的解析ツールによるセキュリティ検出についても、誤検知（False Positive）と見逃し（False Negative）の両方が一般的に存在します。

さらに、複数の指標を集約して評価する場合、それらが独立しているかどうかも重要です。複数の指標が強く相関していて、実質的に同じ性質を測定している場合、TOPSIS においてそれらを同じ重みで扱うと、同じ観点を二重・三重にカウントしてしまい、結果を歪める可能性があります。

この研究から分かること、分からないこと

この研究のサンプルは、すべて HumanEval から取得されています。HumanEval は、短く独立した Python 関数で構成されるベンチマークであり、いわばコーディング面接で出題されるようなタイプの問題です。しかし、これが現実のコードベースを代表している保証はありません。実際のソフトウェアは通常、より長く、複雑に絡み合い、多くのコンテキストに依存しています。HumanEval が選ばれた理由は、単純に利用可能だったからです。研究分野では、これを convenience sampling（便宜的サンプリング）と呼びます。これは実務上よくある選択ですが、結論を一般化できる範囲を制限します。

また、HumanEval 自体が OpenAI によって作成されたベンチマークであり、その OpenAI が GPT を開発しています。この点も念頭に置く必要があります。LLM は、この特定のベンチマークで良い結果を出しやすい形で訓練されている可能性があります。その結果が、別のコード、別の言語、あるいはより複雑なソフトウェアシステムにも当てはまるかどうかは、依然として未解決の問題です。

結論

研究論文自身のまとめが、この点をうまく表現しています。「GPT モデルは、一部のケースでは内部品質の高いコードを生成できるが、常に正しい、あるいは信頼できるコードを生成するわけではない。」

これは、非常にバランスの取れた誠実な結論です。小規模で明確に定義された Python 関数に対して、適切なプロンプトを使用した場合、GPT-4 は複数の指標において、人手で書かれたコードと同等、あるいは場合によってはよりクリーンなコードを生成できます。しかし、およそ 5 個に 1 個の割合で生成関数は機能的に誤っており、保守性に関する優位性も限定的で、状況依存です。

 実務的な観点では、これは次のことを意味します。 

• LLM が生成したコードは、必ずレビューとテストを行うこと。18% のエラー率は、無条件に信頼するには高すぎます。
• 詳細なプロンプトは重要です。この研究では、最も詳細なプロンプトが一貫して最良の結果を示しました。
• GPT-4 は GPT-3.5 を全体的に上回っています。
• 保守性に関する主張は慎重に受け止めるべきです。使用されている指標は完全ではなく、その差も多くの場合は小規模です。

AI が開発者を完全に置き換える時代は、まだ到来していません。しかし、すでに到来しているのは、「コード生成に役立つ実用的なツール」の時代です。それは、時間を節約し、ときにはよりクリーンな結果を生み出してくれるツールですが、完成品としてではなく、あくまで出発点として扱う必要があります。

では、LLM は人間より優れたコードを生成できるのか？

場合によっては可能です。しかし、それは安定的ではなく、多くの注意点があります。この研究によれば、適切に設計されたプロンプトを使用した GPT-4 は、一定数のケースにおいて、人手で書かれたコードよりも高い保守性指標を示す Python コードを生成できます。その限定的な意味では、LLM が「より良い」コードを生成できると言えるでしょう。しかし、詳細に検証すると、その見方はすぐに揺らぎます。生成された関数の約 18% は完全に誤っており、保守性向上も限定的で指標依存です。さらに、この比較自体が、短く独立したコーディング課題に限定されており、現実のソフトウェア開発の複雑さとは大きく異なります。

率直に言えば、「より良い」という評価は、何を基準に測定するか、どの種類のコードを書くか、そして生成結果をどう扱うかに大きく依存します。LLM は、明確に定義された問題に対して、クリーンで簡潔なコードを生成する能力を持っています。しかし、人間より一貫して優れているわけではなく、人間によるレビューなしに信頼できる段階には達していません。

また、この問い自体が適切ではない可能性もあります。LLM と人間を競争相手として捉えるよりも、「LLM は開発者の生産性を向上させるのか？」という観点で考えるほうが有益です。そして少なくとも現時点では、その点を支持する証拠のほうが、はるかに強いと言えるでしょう。

 ¹⁾Jamil, Abid & Shamail, "Can LLMs Generate Higher Quality Code Than Humans? An Empirical Study," MSR 2025. 元論文およびデータは  Github.com で公開されています。