先日、Hacker Newsで「LLMのコーディング性能はテストハーネスに大きく依存する」という議論が盛り上がっていました。私自身、Claude CodeやGPT-5を日常的にコーディングで使っているので、この話題にはかなり引き込まれたのが正直なところです。

テストハーネスとは何か

テストハーネスとは、LLMが生成したコードを自動評価するためのフレームワークのことを指します。具体的には、問題文の与え方、テストケースの構成、実行環境の設定など、評価プロセス全体を統括する仕組みのことです。

たとえば、同じコーディング問題でもプロンプトの与え方を微妙に変えるだけで、LLMの正答率が10〜20%も変動するケースがあるとされています。これは、モデルの能力そのものではなく、評価方法の設計が結果を左右しているわけです。

ベンチマークの「見えない罠」

SWE-benchやHumanEvalといった有名なベンチマークは、LLMのコーディング能力を測る指標として広く使われてきました。しかし、実際に触ってみると気づくのですが、ハーネスの微妙な差異がスコアに大きく影響する場面がしばしばあります。

ある開発者は、テストハーネスのタイムアウト設定を変えただけで、あるモデルのスコアが15ポイント上昇したとHacker News上で報告していました。別のケースでは、出力フォーマットの検証ルールを緩めたことで、本来は正解とすべきコードが「不正解」と判定されていたことが発覚しています。

私が検証で気づいたこと

自分でもClaude CodeとGPT系モデルで簡単な比較をしたことがあるのですが、同じタスクでもエディタの補完機能の有無で体感のパフォーマンスがまるで違いました。CLIから直接使う場合とVS Code拡張経由で使う場合では、コンテキストの渡し方が異なるため、結果にバラつきが出るのは当然といえるかもしれません。

この経験から、「ベンチマークのスコアだけでモデルを選ぶのは危険だ」と強く感じるようになりました。実際の開発ワークフローに組み込んでみて初めて、そのモデルの実力が見えてきます。

正しいLLM評価のために必要な視点

では、どうすればより公平な評価ができるのでしょうか。いくつかのポイントを挙げてみます。

  • 複数のハーネスで検証する — 単一のベンチマークに依存せず、異なる評価フレームワークで横断的にテストすることが重要になります
  • 実タスクでの評価を重視する — 人工的な問題セットだけでなく、実際のリポジトリのバグ修正や機能追加で試すべきでしょう
  • 環境設定を明示する — タイムアウト、メモリ制限、プロンプトテンプレートなど、再現に必要な条件をすべて公開することが求められます

AIコーディングツールの選び方に与える影響

Claude Opus 4.6とGPT-5.3を比較した記事でも触れましたが、モデル選定は数字だけでは語れない部分が大きいのが現実です。ハーネスの設計思想まで理解した上で数字を読まないと、ミスリードされてしまう危険性があります。

AIエージェント開発プラットフォームを選ぶ際にも同じことが言えるでしょう。ベンチマーク上位のモデルが、必ずしも自分のユースケースに最適とは限りません。

業界全体の課題として

この問題はLLM業界全体の信頼性にも関わってきます。各社が自社に有利なハーネス設定でベンチマークを公表する「ベンチマークハッキング」は以前から指摘されてきました。

最近では、SWE-benchの公式リポジトリでもハーネスの標準化に向けた議論が進んでいるようです。統一された評価基準が整備されれば、ユーザーがモデルを比較する際の混乱も減っていくはずです。

まとめ

LLMのコーディング性能を正しく理解するには、モデル自体だけでなく「どう測ったか」にも注目する必要があります。ベンチマークの数字に一喜一憂するのではなく、自分の開発環境で実際に試してみることをおすすめします。Pixel 4aをAIエージェント専用機にした話でも書きましたが、手を動かして初めてわかることは本当に多いものです。