本記事では、AIが生成したコードや修正パッチなどの成果物を、LLM(AI自身)を使ってより正確に評価するための新たな研究を紹介します。
AIによるコード生成が普及する一方で、その品質や正確性をどう評価するのかが課題になっています。今回取り上げる研究では、人間の判断に近づけるために複数の評価視点を組み合わせる工夫がされています。
AIによるソフトウェア開発を実際に導入・検討しているエンジニアやビジネス担当者に役立つ可能性のある情報です。

背景
生成AIがソフトウェア開発の現場に入り込む場面が増えています。
コードの断片やバグ修正の提案、関数の要約といった作業が、人の手を借りずに自動で出力できるようになってきました。
開発効率が向上する一方で、誰もが気になるのは「その内容は本当に正しいのか」という点です。
実際にどの程度正しいのかを確かめるには、評価の仕組みが必要です。
人が直接チェックするのが一番確実ですが、大量の出力に目を通すには時間もコストもかかります。
もう少し規模に強い方法としては、Pass@kのようなテストベースの自動指標も使われています。
ただ、Pass@kのような指標を活用するには、事前に多くのテストケースを準備しておく必要があり、それが整っていないタスクも少なくありません。
(Pass@kとは、テストをk回試行してどれくらい通るかを測る指標です)
そのため、自動的に、かつ人の判断と近い精度で評価してくれる仕組みが求められいます。
そこでLLMに判定を依頼する「LLM-as-judge」が注目されています。しかし、まだ発展途上です。たとえばLLMに評価スコアを直接つけさせる場合は、多様な観点をどう実装するかが課題になります。
本記事では、LLMを使った評価でありながら、より人間に近い信頼性を目指す新たな枠組みを紹介します。人手評価と自動評価のギャップを埋める方法として、実務でも応用できる可能性が見込まれます。
これまでのアプローチ
ソフトウェア成果物を自動で評価するには、何を基準に、どうスコアをつけるべきか。まずは取り組む問題の定義と、これまで使われてきた評価手法について整理します。
評価したい「正しさ」とは
今回、評価する対象となるのは、”生成AIなどの支援ツールが出力したコードやコメントなどの成果物”です。
その評価で重視されるのが「機能的な正確性」です。出力された成果物がユーザーの意図どおりに正しく動作するか、という点です。
この正確性が確保されていなければ、たとえ出力が読みやすくても、処理が速くても意味がありません。多くのソフトウェア関連タスクにおいて、正確性は最も基本的な前提になります。
評価の枠組みは次のようになります。
ユーザーの指示(たとえば自然言語での要件記述)を𝑥、ツールが出力した成果物を𝑦、そして本来意図されていた正解を𝑟とします。人間の評価者が𝑦を確認し、0〜4などの段階スコアで正確性を判断します。
この研究の目標は、そうした人手の評価にできるだけ近いスコアを自動で出せるような指標 E(𝑥, 𝑦, 𝑟) をつくることです。
記号を使うので少し難しく感じられたかもしれませんが、要するに人間の評価基準を明確にしようということです。
今使われている代表的な手法
こでまでの「LLM-as-judge」における代表格が、ICE-Scoreと呼ばれる指標です。LLMに「この成果物はどれくらい正確か?」と直接尋ね、スコアを出してもらう方法です。
たとえば、タスク説明や評価基準を含むプロンプトを用意し、そこに問題文𝑥、生成結果𝑦、参照解答𝑟を加えます。LLMはプロンプトを読み取って、0〜4のスコアを返します。
つまり、LLMが内容を読み取り、与えられた基準に従って評価するという、非常にストレートな仕組みです。
ただし、この方式で実現できるのは、あくまでひとつの観点からの評価です。たとえば「出力結果と正解が機能的に等価かどうかを比較する」、「LLM自身にテストケースを生成させ、その結果で評価する」といった方法も有望ですが、対象外です。
査読プロセスからの着想
今回研究者らは、論文の査読プロセスからヒントを得ました(独創的な切り口です)。
論文の査読というものは、複数の専門家がそれぞれの観点から評価を行い、その結果を編集者が統合します。個々の視点が異なるからこそ、全体としてバランスの取れた判断が生まれると期待されるアプローチです。

これに倣って、ソフトウェアコードの評価においても、複数の異なる観点を組み合わせるのはどうかと発想されました。
要するに、今回次の2つの方向性が目指されました。
- 評価観点を多様化し、単一視点の偏りを避ける
- 評価対象やタスクの性質に応じて、複数の観点からなる「最適なチーム」を自動で選ぶ仕組みを導入する
このようにして、人間の評価のような多角的な判断を、LLMによって再現する方法が模索されました。具体的な方法論は次のセクションで紹介します。
評価を人の判断に近づけるための新しい提案
まず、評価の全体像を三つのステップに分けて考えます。
- 異なる視点をいくつか定義して、それぞれの評価手法を用意する
- 評価対象に合わせて、最も効果的な視点の組み合わせを自動で選ぶ
- 複数の視点ごとにスコアを出し、それらを平均して最終スコアとする

評価視点は五つの方向から組み立てる
スコアを出すときの観点は次の五つを使います。それぞれ、LLMにプロンプトを与えることで動作します。
- 出力内容をそのまま読んで正しさを判断する
- 一度スコアを出したあと、理由を振り返って再評価する
- 出力と正解が意味的に等しいかを比較する
- テストケースを自動で作り、それに合格するかどうかで評価する
- 正解の中から重要な要素を抜き出し、それを満たしているかを確認する
すべての視点はゼロショットで使えるように設計しておくと、注釈付きデータを用意する手間を省けます。
評価結果は一旦すべて0〜100のスケールに揃え、あとで必要に応じて各データセットの基準(たとえば1〜5や0〜1)に変換して使います。
評価チームは対象ごとに選び直す
評価視点の組み合わせは、データセットごとに調整します。
視点の候補は次の6つです。それぞれLLMへの問いかけ方が異なり、見る角度が変わります。
- 出力だけを提示して、LLMに正確性を直接判定させる方法(参照コードは使いません)
- 出力に加えて参照コードも見せたうえで、LLMに評価を求める方法
- 最初に出したスコアとその理由をLLM自身に振り返らせ、必要があれば修正させる方法
- 出力と参照コードの内容が意味的に等しいかどうかをLLMに判断させる方法
- 参照コードをもとにテストケースを作成し、それに出力が合格するかどうかで評価を行う方法
- 参照コードの中から重要な要素を抽出し、それが出力に含まれているかを確かめる方法

この6つのうち、最初の2つはプロンプトの差分によるバリエーションであり、両方とも活用することで柔軟なチーム編成が可能になります。
チーム選定には、あらかじめ人手で正確性スコアを付けたサンプルを10件ほど用意しておきます。各チームごとにこのサンプルに対するスコアを出し、人間の評価との相関を比較します。
人間の評価との相関を確かめるときは、スコアの並び方がどれくらい似ているかを数値で測るとわかりやすくなります。例えば、同じ順序で高得点や低得点をつけているか、全体として傾向が近いかといった点を確認します。
もっとも高い一致度を示したチームを、そのデータセットにおける評価チームとして採用します。
評価スコアは複数の視点からの平均で出す
評価に使う視点がもし3つ以上だった場合、それぞれの視点からスコアを取得し、その平均値をとるとよいです。
すべてのスコアは0〜100の範囲に揃えておき、必要な場合は人間の基準スケールに合わせて線形に変換します。たとえば最終スコアを1〜5に変換したい場合、スコアを100で割って4をかけ、1を足せば調整できます。
難しいですが、まとめると、次のような三つのステップになります。
- 出力そのものを見る、正解と比較する、テストを通すなど、異なる観点を組み合わせて判断できるようにしておく。
- 少数の注釈付きデータを使って、どの視点の組み合わせが一番人間と近いかを確認する。確認できたら、その組み合わせを使うようにする。
- それぞれの評価視点でスコアを出し、0〜100のスケールにそろえたうえで平均する。必要に応じて、最終スコアを1〜5などの人間に合わせたスケールに変換して使う。
実験で確かめる
ここからは、実際に提案された評価手法が有効なのかを確かめた実験について紹介します。どのようなデータを使い、どんな比較を行ったのか、順を追って整理していきます。
評価に使ったデータ
検証では、生成AIが関わる代表的なタスクが対象とされました。コード生成、プログラムの自動修復、コード要約の3種類です。
評価の正解として人間がスコアを付けたデータが必要なので、すでに人手評価が付いている以下のデータセットが使われました。すべて列挙します。
CoNaLa
Pythonコード生成のデータセット。472件の問題に対し、複数の自動生成ツールが出したコードを開発者が0〜4で評価したスコアが付いています。
Card2Code Hearthstone
カードゲーム「Hearthstone」に関連したコード生成ベンチマーク。カードの説明と対応するPythonコードのペアが665件あり、人手による正確性スコアが含まれます。
APR-Assess
プログラム修復ツールが出した189件の修正パッチを、0か1で正確性評価したデータです。
Summary-Assess
コード要約タスクのデータセットで、1,611件のコード要約に人手で注釈が付けられています。内容の正確さを示すスコア(1〜5)が使われました。
さらに、人間による評価だけでなく、テストケースにどれだけ合格するかという基準でも確かめるため、以下の2つも使われました。
HumanEval-X
PythonやC++、Javaなど5言語に対応した、多言語コード生成ベンチマークです。自然言語の問題文、テストケース、正解コードが揃っています。
APPS
コード競技サイトから収集された、難易度の高いタスク群。競技レベルの問題100件を抽出して使用しています。
比較対象となる評価指標
有効性を確かめるために、提案手法が複数の既存手法と比較されました。比較対象となった既存手法は大きく3種類に分かれます。
マッチベースの指標
まず、BLEU、ROUGE-L、METEOR、ChrF++、CodeBLEU、RUBY、CrystalBLEUの7種類が選ばれました。生成結果と正解との表面的な類似度を測る指標です。
埋め込みベースの指標
次にMoverScore、BERTScore、CodeBERTScore、SIDEの4つ。意味的な類似度を測る手法です。
LLM-as-judgeの既存例
LLMに評価を任せる先行手法としては、次の2つが取り上げられました。
Vanilla LLM
単純なプロンプトだけでスコアを出させるもの。たとえば「この出力は正確ですか?0〜4で評価してください」といった形式です。
ICE-Score
先述した通りコード評価に特化したLLM-as-judge型の手法で、評価基準を明示したプロンプトを使います。
評価のやり方
手法の有効性を評価する方法として、2種類の観点から確かめました。
相関のスコアを見る
人間のスコアとツールのスコアがどれくらい同じ傾向を示すかを確認します。順番の一致度を見るKendall、Spearman、Pearsonの3種類の指標を使い、それらを平均した数値も算出されました。
一致率を見る
人間とツールが同じカテゴリを選ぶ確率をCohenのKappaで測定します。2人の評価者が同じものを選ぶ割合を数値化するもので、ツールが人間とどれくらい「同じように見ているか」を確かめるための指標になります。
モデル設定
使ったモデルはGPT-4o miniです。処理速度が速く、コストも低いモデルでありながら、今回の検証における性能は十分であることから選ばれました。温度は0に設定して、出力のばらつきを抑えています。
検証した3つの問い
実験では、以下の3点を明らかにすることが目的とされました。
- ベースラインと比べて、人間の評価とどれくらい一致するか
- ツールと人間の評価の一致度は、人間同士の一致度と比べてどの程度か
- 提案された仕組みのどの部分が、評価の精度に効いているか
要するに、人間の目に近づけることができたか、人間のばらつきとツールのばらつきはどう違うか、どの工夫が効果的だったかを確かめたということです。
実験結果から見えてきたこと
これまで紹介してきた評価手法が、実際にどの程度うまく機能するのか。検証の中心となった3つの問いに沿って、実験の結果を整理します。
なお、今回提案された手法にはSWE-Judgeという名前が付けられています。
人間の評価とどれくらい一致するのか
まずは、人間の評価とどれだけ似た判断ができているかを見ていきます。
人手評価スコアとの相関を測ったところ、すべてのタスクで本手法が既存手法よりも高い一致を示しました。コード生成、コード修復、コード要約のいずれにおいても、BLEUやBERTScoreなどの従来の指標を大きく上回るスコアを記録しています。

たとえば、CoNaLaデータセットでは、従来手法より27%から最大159%も高いスコアとなりました。Card2Codeでは5.9%から63.8%、APR-Assessでは70%超、Summary-Assessでも平均15.8%から最大183%と、いずれも大きな差が出ています。
成果物の形式が違っても安定して高い相関を示しており、コードスニペットでもコード修正でも自然言語要約でも、常に本手法が最も人間の評価と近い結果を出しました。
コード生成タスクにおいては、CoNaLaでKendall 60.3、Spearman 71.2、Pearson 68.3というスコアに。Card2Codeではさらに高くなり、Kendall 70.4、Spearman 83.8、Pearson 81.7に到達しています。
自動プログラム修復でも、3指標すべてで77.5という高い数値を記録しました。
コード要約では他タスクほどではなかったものの、それでも他の指標を上回る結果になりました。
まとめると、評価結果が人間の判断とどれだけ似ているかを測ったとき、本手法が最も優れた手法であると確認されたということです。
人間同士の評価と比べてどうか
次に、ツールと人間の評価がどれくらい一致しているかを、人間同士の一致度と比べて検証しています。
評価者同士の意見のばらつきを比較対象とし、ツールがそれにどこまで近づけるかを確かめる方法です。CohenのKappaスコアを使って、すべてのデータセットで比較しました。

CoNaLaの平均Kappaスコアは25.7、人間と本手法の一致は24.1で、かなり近い結果です。Card2Codeでは人間同士が30.5だったのに対し、本手法は35.1と逆に上回っています。
修復タスクでは、本手法が66.7、人間同士は60.1と、こちらも上回る形になっています。
Summary-Assessでは、人間同士が15.5の一致を示したのに対し、本手法は4.6と大きく下回っています。
つまり、コードの説明文を扱うような文脈では、まだ改善の余地があるという結果です。
それでも他の自動評価指標と比べれば、本手法が最も優れた精度を保っていたことには変わりなく、一定の前進が見られます。
どの設計が効果に貢献していたか
最後に、本手法の中でどの工夫が効いていたのかを検証した結果を紹介します。
評価戦略の組み立てと、評価視点チームの動的選択。この2つの工夫の効果を個別に切り出して、どちらがどの程度スコア向上に寄与していたかを調べました。
戦略を組まずに視点だけ並列で使った場合と、そもそも両方やめてLLMに単純なプロンプトを渡しただけの場合を比較しています。
動的なチーム選択をやめた場合、CoNaLa、APR-assess、Summary-assessの各データセットでスコアがそれぞれ5.4%、21.3%、14.9%低下しています。全体平均で見ると、9.6%の性能低下につながりました。
さらに、戦略の組み立てもやめてしまった場合は、CoNaLaで46.4%、APR-assessで52.8%という大幅な下落になっています。Summary-assessでも13.6%の低下が見られました。
この結果から、工夫のどれか一つでも欠けると性能が落ちてしまうことがわかります。戦略的な評価設計と、データセットに応じた柔軟な視点選びの両方が、性能向上に不可欠だったという結論になります。
実験を通じて明らかになったことと今後の課題
実験結果をさらに深く理解するために、別の観点からも追加の検証が行われています。その結果をふまえて既存手法との違いや、今後の改善点について整理します。
テストケース実行結果との一致度による検証
ここまで主に「人間の評価スコア」との一致度を見てきましたが、もう一つ別の基準である「テストケースの合格・不合格」についても検証しました。つまり、テストの合否という客観的な基準で本手法の性能が確かめられました。
多言語のコード生成を含むHumanEval-Xデータセットを使った検証では、本手法がすべての言語において、他の既存手法を平均で32.1%から78.8%上回りました。さらに難易度が高いAPPSデータセットの場合は、この差が175.6%から1691.7%まで広がりました。この結果から、本手法は評価基準が変わっても安定して高精度を示せることがわかりました。

具体的な事例から見た既存手法の問題点
実際の評価例を確認すると、従来の評価手法には主に次のような課題があることが明らかになりました。
まず、BERTScoreやCodeBERTScoreなどは常に高めのスコアを付け、ChrF++やCodeBLEUなどは低めのスコアに偏るため、正しい出力と間違った出力が区別しにくくなります。
また、人間が付けた評価スコアと既存手法のスコアの範囲が一致しないケースが多く、直接比較が難しくなります。
さらに、誤ったコードに対して、正しいコードより高い、または同じレベルのスコアを付けてしまう手法があり、結果が直感に反する場合があります。
本手法では、こうした問題は見られません。実際の例を見ても、正しいとされるコードには人間の判断通りに高いスコアを、間違ったものには低いスコアを付けており、結果が直感的に理解しやすくなっています。

今後の課題や改善できる可能性
もちろん、本手法にも改善すべき課題や制約があります。その主な点を整理します。
検証に使ったデータセットは特定のソフトウェア開発タスクを中心としており、すべてのソフトウェア開発タスクに同じように一般化できるとは限りません。今回は、コード生成、自動プログラム修復、コード要約などの代表的なタスクを含む広く利用されているデータセットを用いましたが、より幅広い範囲での検証が必要になります。
また、使用するLLMの性能によって結果が変わる可能性があります。今回はコストパフォーマンスを考慮してGPT-4o miniを使いましたが、さらに高度なモデル(GPT-4.5など)を採用すれば、評価性能がさらに向上することも期待できます。ただし、モデルの性能と運用コストのバランスを考える必要があります。
要するに、現在の検証では一定の条件下での性能を示していますが、さらに広いデータセットや高度なモデルを使えば、評価性能がさらに改善する可能性があります。
それでも、現状でも十分実用的であり、従来手法よりも大幅に優れた結果を示しています。
本手法の位置づけをおさらい
今回の評価手法は、ソフトウェア成果物を正確に評価したいという長年の課題を受けて生まれました。これまでは、NLP分野で開発されたBLEUやBERTScoreといった指標がコード評価にも応用されてきましたが、テキスト用の評価手法ではソフトウェアの構造や意味を十分に捉えられないという限界がありました。
今回提案されたSWE-Judgeは、複数の異なる評価戦略をLLMで柔軟に組み合わせ、評価対象に最適な組み合わせを自動的に選択することで、この課題を解決しようとしています。また、コード生成、自動プログラム修復、コード要約という異なるタスクを横断的に評価できる汎用性も持っていると考えられています。
既存の研究の流れを踏まえつつも、「多様な評価戦略を組み合わせ、その最適な組み合わせを動的に選ぶ」という新しいアプローチで評価の課題に取り組んだものです。
まとめ
本記事では、自動生成されたソフトウェア成果物を正確に評価するための新たな研究を紹介しました。
複数の評価視点を組み合わせ、その中から最適な評価チームを動的に選択することで、人間の判断に近い評価結果を実現しています。実際の検証では、既存の評価指標と比較して、人手評価やテストケース結果との相関が大きく改善されることが示されました。
一方で、評価対象となるタスクやデータセット、モデルの性能によって結果に違いが生じる可能性も指摘されています。
自身が取り組むプロジェクトの性質に合わせて、本手法の考え方を柔軟に取り入れていただければと思います。
参照文献情報
- タイトル:
- URL:
- 著者:
- 所属:
■サポートのお願い
AIDBを便利だと思っていただけた方に、任意の金額でサポートしていただけますと幸いです。