7月1日、Microsoftが「What AI benchmarks are not telling you」と題した記事を公開した。AIコーディングエージェントの評価において公開ベンチマークが抱える構造的な限界と、自チームのスタックに合った正しいモデル評価方法について詳しく解説している。
「SWE-benchで高スコア」が自分のコードベースで機能しない理由
「新しいモデルが出た。リーダーボードでSWE-benchのスコアが高いから最良の選択だ」——そう判断してモデルを切り替えたが、結果は変わらない、むしろ悪化した。この経験に覚えがあるエンジニアは少なくないはずだ。
記事はその理由をズバリ「分布のギャップ（distribution gap）」と表現する。ベンチマークはある分布からサンプルを取り、自分の業務は別の分布に存在する。この2つの分布の距離が、ベンチマークスコアの有用性を決定する。
SWE-benchは、GitHubのIssueと人気OSSリポジトリのスナップショットを与え、テストをパスするパッチを生成させるという形式で評価する。有効なタスクではあるが、以下のような要素は一切含まれない：
- 自社の非公開SDK
- チームのコーディング規約やアーキテクチャパターン
- 12本の拡張機能が競合するワークスペース
- エージェントの挙動を制御するAGENTS.mdなどのインストラクションファイル
- エラーを読んで自己修正する複数ターンにわたる反復ワークフロー
ベンチマークが「劣化していく」メカニズム
さらに問題なのは、この分布ギャップが世代を経るごとに拡大する点だ。記事はGoodhart's Law（「ある指標が目標になった瞬間、それは良い指標ではなくなる」）を引用してこの構造を説明する。
データの重複：SWE-benchのタスクはすべて公開リポジトリ由来であり、モデルの学習データとの重複は避けられない。新世代のモデルほどベンチマーク近傍のコードを大量に学習している。
フォーマット最適化：「リポジトリ内のIssueを解決する」という形式に特化したファインチューニングが進む。だが自チームのタスクは「3つの内部ライブラリを使いつつチーム規約に従って機能を実装する」といった、まったく異なる形式かもしれない。
結果として、ベンチマークスコアは実際の性能改善より速く上昇する。スコアの上昇の一部は真の能力向上だが、一部はフォーマット特化の最適化にすぎない。
もう一つの盲点：ハーネスの差
仮にベンチマークのタスク分布が完璧だったとしても、別のギャップが残る——ハーネス（評価の実行環境）だ。
多くのベンチマークは「リポジトリとIssueを渡してパッチを出力させる」という最小限のハーネスで動く。MCPサーバーも、インストラクションファイルも、カスタムスキルも、50ファイルのワークスペースコンテキストもない。記事はこれを「完璧な天候と他機ゼロの状態でパイロットを評価するフライトシミュレーター」と表現している。
長いコンテキストが苦手なモデルは最小ハーネスでは好成績を出すが、実際の複雑な環境では失速する。逆に、ツールが多い環境でのコンテキスト処理が得意なモデルはベンチマークのスコアが低くても実業務で優れるケースがある。
ベンチマークの正しい使い方
記事はベンチマークを完全否定しているわけではない。スコアは「必要条件だが十分条件ではないフィルター」として機能する。
使うべき場面：
- 明らかに性能不足なモデルを除外する
- 新バージョンへの更新が退行（regression）かどうかを確認する
- 小型モデル・大型モデル、コード特化・汎用といった「能力クラス」の大まかな把握
使ってはいけない場面：
- 自チームのスタックに最適なモデルを決定する
- 数ポイントのスコア差が自分の成果に直結すると予測する
- 自分のevalを実施せずにモデル切り替えを正当化する
自チームで評価を回す方法
では何を判断基準にすべきか。答えは「自分のシナリオで比較する」だ。
同一のプロンプト・ワークスペース・拡張機能・評価基準を使い、モデルAとモデルBを比較する。変数をモデルに絞り、他の条件を固定することが肝心だ。
必要なシナリオ数は5〜10個で十分。条件は3つある。
- 開発者が毎日行う現実のタスクであること（合成した演習問題は不要）
- 「全モデルが解ける簡単すぎるタスク」でも「全モデルが解けない難しすぎるタスク」でもないこと
- 測定軸は「アウトカムの質・コスト（トークン数）・一貫性・インストラクションファイルへの追従性」の4つ
また、モデルのバージョン更新やハーネスの変更が頻繁に起きるため、evalは繰り返し実行できるプロセスとして整備しておくことが重要だ。
組織レベルの落とし穴
記事が最後に警告するのは「組織のトラップ」だ。リーダーシップがリーダーボードを見て最高スコアのモデルへの移行を命令し、チームのワークロードに対する実評価なしで意思決定が下される。その後、インストラクションファイルが機能しなくなりツール選択の挙動が変わっても、「スコアが高かった」という事実がバグの原因究明を妨げる。
この罠は前述の分布ギャップやハーネスの問題とも連動しており、組織がベンチマークスコアを自チームの現実の代替指標として扱い続ける限り、モデル選定の精度は上がらない。5〜10シナリオを2モデルで実行するコストは、チーム全体を「実業務で劣るモデル」に切り替えるコストと比べれば無視できる規模だ。
詳細はWhat AI benchmarks are not telling youを参照していただきたい。
