HumanEvalは終了しました：コードLLMのベンチマークを理解する方法は 2026

#HumanEval がなぜ死んだのか

HumanEvalはLLMの歴史において最も引用されるコードベンチマークです。2021年にOpenAIによって公開され、4年間参照基準として機能しました。問題は、2026年時点で飽和状態にあることです。最高のオープンウェイトコードモデルは「pass@1」で96〜98%を達成しており、つまりほぼすべての演習を初回で解決します。全員が20/20を取っている場合、スコアはもはや誰もランキングできません。

飽和したベンチマークはもはや進歩を測定していません。主にノイズを測定しているだけです。2つのモデル間の96%から98%という差は、100問中3問、しばしば曖昧な表現や不適切な設問によるものかもしれません。これは能力の差ではなく、誤差の範囲です。2026年にHumanEvalのスコアだけでコードLLMを選ぶことは、10メートルの短距離走で2人の長距離走者を比較するようなものです。

HumanEval自体が悪くなったわけではありません。モデルが、HumanEvalで測定できる範囲を超えたのです。性能の後退を確認する回帰テストとしては今も有用です。スコアが70%に落ちるモデルには実際に問題があります。ただし、最上位のモデル間に差をつけるためには、もはや役立ちません。

#HumanEvalが実際に測定する内容

HumanEvalのスコアが飽和する理由を理解するには、具体的に何をテストしているのかを確認する必要があります。このベンチマークには、Pythonの小規模なプログラミング問題が164問含まれています。各問題には、関数のシグネチャと、期待される動作を説明するdocstringが与えられます。モデルは関数の本体を書く必要があり、その本体が非公開の一連のユニットテストで検証されます。

フォーマット

実装を完成させる164個の独立したPython関数。それぞれにdocstringとユニットテストが付いています。

タスクの性質

基礎的なアルゴリズム: リスト、文字列、少しの数学を扱うだけです。各問題は外部依存なしで 1 つの関数に収まります。

テストする内容

短く明確な仕様を正確なコードに翻訳できる能力。学校の課題のようなもので、現場でのタスクではありません。

テストで確認していない点

既存のリポジトリ内を探索する、複数のファイルを読む、すでに書かれたコードを理解する、実際のバグを修正する、テストを書く、依存関係を管理する。つまり、実際の開発業務です。

違いはここにあります。明確な課題の説明に基づいて単独の関数を書くことは、2026年のモデルが得意とする作業です。開発者、あるいはエディターに接続したローカルのコードアシスタントの実際の仕事は、数千行に及ぶ既存のリポジトリを変更することです。新しいベンチマークは、この能力を測定しようとしています。

#SWE-bench Verified の説明

SWE-benchは、信頼できる評価基準としてHumanEvalに取って代わったベンチマークです。その考え方は根本的に異なります。単純な練習問題ではなく、人気のあるオープンソースのPythonプロジェクト（Django、scikit-learn、Flask、sympyなど）から取り出した、実際のGitHubの「issue」を用います。モデルにはリポジトリ全体と修正対象のバグの説明文が与えられます。モデルは、問題を実際に解決するパッチ、つまり差分（diff）を生成しなければなりません。

修正を判定するのは、人間でも別のモデルでもありません。パッチをリポジトリに適用し、その後、プロジェクトのテスト一式を実行します。それまで失敗していたテストが通り、通っていたテストが失敗しなければ、問題は解決したと判定されます。これは客観的で、実際の作業に近い基準です。

SWE-bench Verified

手作業で検証された500件の問題。実際のバグ修正能力についてモデルを比較するための、現在の標準です。

SWE-bench Lite

比較的簡単で、評価コストの低い300問です。素早くテストするには便利ですが、性能差を見分ける力は弱くなります。

SWE-bench full

2,000問を超える問題があり、一部には不備があります。スコアは比較的低く、ノイズも含まれるため、比較には使わないほうがよいでしょう。

スコアの水準を見ると、難しさがよく分かります。HumanEvalでは98％が上限となっている一方、最も優れたエージェント型モデルでもSWE-bench Verifiedでは60〜70％に達する程度で、ローカルにインストールできる優秀なオープンウェイトモデルは、おおむね40〜55％にとどまります。ようやく改善の余地が生まれ、モデル間の優劣を見極められるようになったのです。

#LiveCodeBenchとデータ汚染

SWE-benchは、実際のコードでのバグ修正を評価します。LiveCodeBenchが取り組むのは、別の問題であるデータ汚染です。その仕組みは名前の「live」に表れています。このベンチマークは、競技プログラミングの新しい問題（LeetCode、AtCoder、Codeforces）を継続的に収集し、タイムスタンプを付けます。これにより、モデルの学習日より後に公開された問題だけを使って評価できます。

これは極めて重要です。モデルの学習前に問題がインターネット上に存在していた場合、そのモデルは学習中に解答を見ていた可能性があります。その場合、スコアが反映するのは推論ではなく、記憶です。LiveCodeBenchは日付で絞り込むことで、モデルが取り組む問題が、それまでに目にする機会のなかった問題であることを保証します。

性質

タイムスタンプ付きで、継続的に更新される競技プログラミングの問題。

時間的分割

テスト対象のモデルの学習後にあたる期間を選びます。データリークの可能性はありません。

何を測っているか

未知の問題に対する純粋なアルゴリズム的推論 — HumanEvalの趣旨に近いものの、飽和も汚染もありません。

結果を読む際の注意点

公表されている評価対象期間を必ず確認する。モデル登場前の期間を対象としたLiveCodeBenchのスコアには価値がありません。

LiveCodeBenchとSWE-benchは競合するものではなく、互いに補完するベンチマークです。前者は新しい問題に対するアルゴリズム的な推論能力を、後者は実際のリポジトリで作業する能力を測ります。優れたコーディング用LLMには、両方で十分な性能が求められます。アルゴリズムに強くても、プロジェクト内の構成やコードを把握できないモデルは、日常的に使うアシスタントとしては役に立ちません。

#データ汚染の問題を分かりやすく解説

データ汚染こそ、公表されているスコアを警戒すべき最大の理由です。LLMは、GitHubを含むウェブ上の膨大なデータで学習されています。ベンチマークの問題とその解答がオンラインに出回っていれば、学習データに取り込まれる可能性が高いのです。モデルはもはや問題を解いているのではなく、覚えた内容をそのまま答えているだけです。

注意すべき兆候は、古い静的なベンチマークでは他のモデルを圧倒するのに、「ライブ」のベンチマークや公開されたばかりのベンチマークでは並の成績に戻るモデルです。両者の差は、スコアのうちどれだけが暗記によるものかを測るよい指標になります。LiveCodeBenchは、まさにそれを明らかにするために設計されました。

#ローカルモデルのスコアを読む

オープンウェイトモデルのモデルカード（Hugging Face上、または提供元の発表内）を見ると、コーディングのスコアがほぼ必ず強調されています。惑わされないために、以下の読み解き方を参考にしてください。

1. 01
   ベンチマークの正確なバージョンを確認してください

   「SWE-bench」という表記だけでは意味がありません。「Verified」の表記を探してください。LiveCodeBenchでは、バージョン（v5、v6など）と対象の日付範囲の両方を確認してください。これらが明示されていない数値は、ほかの数値と比較できません。
2. 02
   pass@k を確認してください

   pass@1とpass@10を比較してはいけません。モデルの提供元は、この二つのうち見栄えのよい方を表示することがあります。どちらなのか明示されていない場合は、実際の利用では最も不利なケースを想定してください。日常的な利用で重要なのは、最初の回答です。
3. 03
   SWE-benchで使われたエージェントの構成を確認してください

   SWE-benchのスコアは、そのスコアを出したエージェントと切り離して考えることはできません。「OpenHandsで52％」と「Aiderで52％」は同じではありません。開発元がエージェントを明示していない場合、その数値は判断材料としてあまり役に立ちません。
4. 04
   提供元が自ら公開したスコアには注意してください

   モデルカードの数値は、良い印象を与えることに利害のある提供元が公表したものです。独立した再現結果（公開ランキング、第三者の記事）を探してください。一度も再現されていないスコアは、あくまで宣伝上の主張です。
5. 05
   少なくとも二つのベンチマークの結果を照らし合わせてください

   どのベンチマークでも高い性能を示すモデルは、良い兆候です。1つのベンチマークだけで突出し、ほかでは存在感のないモデルには、特化、あるいはデータ汚染の疑いがあります。

#コード用LLMを選ぶ際に参考にすべきベンチマーク

ローカルアシスタントに何を期待するかによって、重視すべきベンチマークは変わります。ここでは、用途に応じた優先順位の付け方を紹介します。

エージェント型アシスタント（Aider、Cline、Continue）

SWE-bench Verifiedを優先してください。これは「私のリポジトリを自律的に修正する」という作業に最も近いベンチマークです。エージェントの実際の有用性が問われるのは、まさにこの点です。

コードの自動補完と小さな関数

LiveCodeBenchを使い、補助的にHumanEvalもチェック用に使います。入力中のコード補完では、プロジェクト内を探索する能力よりも、アルゴリズムの推論能力が重要です。

スクラッチからコード生成

Python以外でもコードを書くなら、LiveCodeBench（新しい課題に対する推論）と複数のプログラミング言語を対象とするベンチマークを組み合わせること。HumanEvalとSWE-benchはPythonに大きく偏っています。

コードレビューおよびバグ検出

公開ベンチマークでは十分に評価されていません。SWE-benchは依然として最も適した代替指標ですが、この用途では、ご自身のコード差分を使った独自のテストが不可欠です。

#避けるべき落とし穴

異なるkを比較する

pass@1とpass@10の比較は、最もよくある間違いです。後者は仕組み上、スコアが高くなります。結論を出す前に、必ずkを揃えること。

量子化を考慮し忘れる

公開されているスコアはフル精度（BF16/FP16）で測定されています。ローカルでは、Q4_K_M や Q5_K_M を実行することになり、品質がわずかに低下します。FP16でSWE-bench 50%のモデルは、量子化されると一段下がります。

ベンチマークを最終目的にしてしまう

ベンチマークをクリアすることを目的に最適化されたモデル（「ベンチマークハッキング」）は、実際のコードを扱うと期待外れになることがあります。スコアは目安であり、保証ではありません。

ベンチマークの日付を無視する

モデルの学習より前の期間を対象としたLiveCodeBenchのスコアには、学習データの混入による汚染がある可能性が高いです。対象期間が学習より後であることを必ず確認すること。

モデルとエージェントの混同

「このモデルはSWE-benchで55％を達成する」という表現には、実際には「このモデルを、その特定のエージェント内で使った場合」という条件が隠れていることがよくあります。エージェントを変えると、数値も変わります。

#さらに詳しく

ベンチマークの見方を理解したら、次はモデルを選んでインストールし、ご自身のコードで試すのが自然な流れです：

2026年のコーディングに最適なローカルLLM

セルフホスト可能なコーディング用モデル（Devstral、Qwen3-Coder、その他の選択肢）を比較し、スコア、必要なVRAM、GPUに応じたモデルの選び方を紹介します。

量子化の選択（Q4、Q5、Q8、FP16）

モデルをQ4_K_Mに量子化すると品質がどれだけ低下するか、つまり公表スコアと実際に動かすモデルとの隔たりを理解するために。

Ollamaをインストール（Windows、macOS、Linux）

コード用モデルをローカルのポート11434で試し、数分でエディターに接続するための前提条件。