LLMのコーディング能力を正しく測るのは難しい。ベンチマークの結果が実務と一致しないことも多い。しかし、評価ハーネスを正しく使えば誤読を減らせる。そこで今回は、LLMコーディング評価の現状と安定運用の手順を解説する。
LLMコーディング評価の現在地
LLMの評価手法は2025年から大きく変わった。以前はHumanEvalが主流だった。しかし、これは孤立した関数のテストだ。実務のコーディングとはかけ離れている。そのため、新しい評価基準が次々と登場した。
特に注目されているのがSWE-bench Verifiedだ。実際のGitHubリポジトリにモデルを投入する。そして本物のバグを修正させる。つまり、実務に近い環境で能力を測れる。実際、Claude OpusやGPT-5 Codexが80%超えのスコアを出している。
また、LiveCodeBenchも広まっている。これは競技プログラミングから新問題を追加し続ける。そのため、学習データに含まれる問題での「カンニング」を防げる。さらに、aiderのPolyglotベンチマークも225問の実践的な評価を提供する。加えて、複数言語に対応している点が実務向きだ。
LLMコーディング評価ハーネスとは
評価ハーネスは複数のベンチマークを統一的に実行するフレームワークだ。代表格がEleutherAIのlm-evaluation-harnessだ。60以上の学術ベンチマークに対応している。数百のサブタスクも含まれている。実際、Hugging FaceのOpen LLM Leaderboardの裏側で使われている。
なぜハーネスが必要なのか。それは再現性と一貫性のためだ。プロンプト形式やトークン制限が変わるとスコアが変動する。温度設定が違うだけでも結果が変わる。しかし、ハーネスならこれらの条件を統一できる。そのため、モデル間の公平な比較が可能だ。
さらに、最近のハーネスは思考トレース除去にも対応した。CoT推論を行うモデルは回答前に長い思考過程を出力する。したがって、それを除去しないと評価が狂う。最新版はこの処理を自動化している。なお、OpenAIのevals libraryでも同様の機能がある。
ベンチ結果の誤読を防ぐポイント
結果を読む際の注意点を整理しよう。まず、単一ベンチマークだけで判断しないことだ。たとえば、HumanEvalが高くてもSWE-benchが低いケースがある。短い関数は書けるがバグ修正ができない。そういうモデルは実在する。
次に、データ汚染のリスクだ。公開ベンチマークのテストデータが学習データに含まれる場合がある。そのため、継続更新型の評価を重視すべきだ。具体的にはLiveCodeBenchのような仕組みだ。新しい問題が定期的に追加される。だからこそ汚染の影響を受けにくい。
また、スコアの差が実務の差を意味するとは限らない。80%と82%のモデルでは体感差がほぼない。しかし、60%と80%なら明確に違う。つまり、微小な差に振り回されるのは非効率だ。大きなカテゴリの違いに注目するべきだ。
実務でのLLMコーディング評価の運用手順
実務で評価を回すなら、手順を決めておくことが大切だ。まず、自社のタスクに近いベンチマークを選ぶ。Web開発ならSWE-benchが適している。アルゴリズム系ならLiveCodeBenchがいい。とはいえ、既存のベンチマークだけでは足りない場面もある。
そこで、社内専用の評価セットを作るのがおすすめだ。自社のコードベースから実際のバグや課題を抽出する。それをハーネスにカスタムタスクとして登録する。そのため、モデルの入れ替え時に迅速な判断ができる。特に、自社固有のフレームワークやルールを含めると精度が上がる。
さらに、評価は一度きりで終わりではない。モデルは定期的にアップデートされる。したがって、CI/CDに評価を組み込むのが理想だ。新モデルのリリース時に自動で評価が走る。結果はダッシュボードに表示される。この仕組みがあれば判断が格段に速くなる。
加えて、評価軸は複数組み合わせたい。コード品質だけでなく生成速度やコストも重要だ。実際、最速のモデルが最も正確とは限らない。また、セキュリティ面の評価も忘れてはいけない。このように、ハーネスで体系化すればモデル選定の精度は格段に上がる。感覚ではなくデータで判断できるようになる。