3,800件超の分析で見えた「レビュアーが見落としがちな、AI生成コードの改善点」

LLMエージェントが自律的にプルリクエストを作成・提出するケースが増えています。しかし、長期的な保守性の観点ではどうなのでしょうか。そして、人間のレビュアーはAI生成コードをどのように受け止めているのでしょうか。

背景

ソフトウェア開発の現場では今、大きな変化が起きています。

少し前までは「人間が書いたコードをAIが補完してくれる」くらいの立ち位置でした。それが今では、GitHubのIssueを読んで、コードを書いて、プルリクエストまで出してくれるLLMエージェントが登場しています。

となると気になるのが、「AIが書いたコードは、品質的にどうなのか？」という話です。よく使われる評価方法は、テストが通るかどうか。でも、テストが通ることと、後から読みやすいか・直しやすいかは、また別の問題です。

なかでも厄介なのが「コードの重複」です。プロジェクト内にすでに似たような処理があるのに、AIがそれを知らずに同じようなコードを新しく書いてしまう。こういう重複があると、あとでバグを直すときに片方だけ修正してもう片方を見落とす、といったことが起きやすくなります。

そこで本記事では、AIが書いたコードにどんな特徴があるのか、そして人間のレビュアーがそれをどう受け止めているのかを大規模に調べた研究を紹介します。

研究の進め方

分析対象は3,858件のPythonプルリクエスト

今回の研究は「AIDev」という公開データセットが使われています。LLMエージェントが自律的に提出したプルリクエスト（PR）を集めたものです。

分析対象になったのは、500スター以上の人気PythonリポジトリにあるPRです。PRは「人間が作ったもの」と「AIエージェントが作ったもの」に分けられています。

データは目的によって2種類に分けられています。1つ目は3,858件のPRを含む全体データで、基本的な品質チェックやレビュアーの反応分析に使われています。2つ目は「crewAI」というリポジトリに絞った617件のPRで、計算コストの重い冗長性分析に使われています。crewAIはこのデータセットの中で最もPRが多く、AIエージェントも活発に動いているリポジトリです。

品質は「従来指標」と「新しい冗長性指標」の両面から測定

コード品質の測定は2つの方向性で進められました。

1つ目は昔からある指標で、コードの行数や「循環的複雑度」を見ています。if文やループなど分岐の多さを数値にしたもので、高いほど処理の流れが入り組んでいる、ということになります。

2つ目が、この研究ならではの指標、「冗長性」です。背景で触れたように、LLMは既存コードをコピペするのではなく、同じ処理を違う書き方で生成しがちです。見た目は違うけど意味は同じ。こういう重複は「Type-4クローン」と呼ばれていて、従来のツールでは検出しにくいのが難点です。

この研究では、コード専用の埋め込みモデル「CodeSage-Large」が使われて、新しく追加された関数が既存の関数とどれくらい似ているかを測っています。

なお、関数の移動やリネームは重複ではないので、リファクタリング検出ツールで除外されています。最終的なスコアは「平均」ではなく「最大」で取られています。たった1つでも深刻な重複があれば保守が大変になる、という考え方です。

レビュアーの感情は7種類に分類

もう1つの軸が、人間のレビュアーの反応です。

PRに寄せられたレビューコメントを感情分析AIにかけて、怒り・嫌悪・恐れ・喜び・悲しみ・驚き・中立の7種類に分類しています。ボットの自動コメントは除外して、人間のコメントだけが対象です。PRごとに感情スコアを平均して、人間のPRとAIのPRで反応がどう違うかを比べています。

結果

コード行数や複雑度ではAIと人間にほとんど差がない

まずはコード行数や循環的複雑度といった、昔からある指標での結果です。

コードの追加量は、人間もAIもだいたい同じでした。ただ、削除量には差があります。人間のほうがより多くのコードを消していて、特に複数行のコメントやドキュメントの削除は、人間が26.26行に対してAIは8.47行。けっこうな差です。

循環的複雑度（if文やループなど分岐の多さを数値にしたもの）のほうはというと、あまり面白い結果にはなっていません。全体の85%がスコアゼロ、つまりシンプルな変更ばかり。高リスクな複雑コードの追加はたった11件で、人間とAIで目立った違いは見られませんでした。

冗長性ではAIが人間の約1.87倍

従来指標では差がなかったものの、冗長性を測ると景色が変わります。

低めのスコア帯では、人間とAIの分布はほぼ同じです。API呼び出しやよくあるパターンなど、誰が書いても似るような部分でしょう。ところが、中程度のスコア（0.3〜0.8あたり）になると、AIのほうが明らかに多い。

数字にすると、AIの平均スコアは0.2867、人間は0.1532。AIは人間の約1.87倍、冗長なコードを書いているということです。この差は統計的にも有意と確認されています。

レビュアーはAI生成PRにむしろ好意的

続いて、レビュアーの感情分析です。

一番多かった感情は、人間PRでもAI PRでも「中立」でした。レビューは基本的に淡々と進んでいる、ということですね。

ただ、内訳を見ると違いが出てきます。AI生成PRには「中立」「喜び」「悲しみ」が多め。人間PRには「嫌悪」「怒り」「恐れ」「驚き」が多め。要するに、レビュアーはAIが書いたコードに対してネガティブな感情を持ちにくいようなのです。

考察

冗長なのにレビュアーは好意的。この「ズレ」はなぜ起きる？

結果をまとめると、ちょっと不思議なことが起きています。AIが書いたコードは人間の約1.87倍も冗長なのに、レビュアーはむしろ好意的に受け止めている。品質と評価が噛み合っていないわけです。

この「ズレ」の原因として、LLMの学習方法が挙げられています。現在のLLMの多くは「RLHF（人間のフィードバックによる強化学習）」という手法で調整されていて、人間が「良い」と感じる応答を出すように最適化されています。その結果、正確さや品質よりも「もっともらしさ」を優先しがちになる、という指摘があります。

つまり、AI生成コードは見た目がきれいで、テストも通る。パッと見では問題なさそうに見えるのです。レビュアーも「動いてるし、まあいいか」となりやすい。でも、既存コードとの重複まではチェックしていない。これがレビュアーの「盲点」になっているのでは、と論じられています。

気づかないうちに技術的負債が積み上がる

この状況が続くとどうなるか。論文では「静かな技術的負債の蓄積」と表現されています。

AIが同じ処理を別の場所に書いてしまうと、あとでバグが見つかったときに片方だけ直してもう片方を見落とす、ということが起きやすくなります。重複があることにレビュアーが気づいていないので、こうした負債は知らないうちに溜まっていく。コードベースはどんどん膨らみ、長期的には読みにくく、直しにくくなっていく、というわけです。

エージェント開発者と現場の開発者、それぞれへの示唆

最後に、この研究から得られる教訓が2つの立場に向けて整理されています。

AIエージェントを作る側に対しては、「パス率だけでなく、コードの再利用度も評価指標に入れるべき」という提言がなされています。現状のエージェントは既存コードを無視しがちなので、そこを改善する余地がある、と。

一方、現場でAIを使う開発者に対しては、「短期的にはスピードが上がっても、長期的な保守コストを意識すべき」というメッセージが送られています。AIが書いたコードはもっともらしく見えるけれど、隠れた重複があるかもしれない。レビュー時には重複ロジックがないか積極的にチェックしたほうがいい、と呼びかけられています。

まとめ

本記事では、AI生成コードの品質とレビュアーの反応を大規模に分析した研究を取り上げました。

従来の指標では人間とAIにほとんど差がない一方、冗長性を測るとAIは人間の約1.87倍。それなのに、レビュアーはAI生成PRに対してむしろ好意的。この「ズレ」が、技術的負債を静かに積み上げるリスクにつながると指摘されています。

AIエージェントの活用が広がるなか、テストが通るかどうかだけでなく、既存コードとの重複にも目を向けることが大切になりそうです。

本記事の関連研究