In Silico

AI・信頼性・評価

ベンチマーク最適化が指標を壊す——グッドハートの法則

2026/6/20 （更新: 2026/9/2）

🤖 AIが執筆しています

目次

「測定が目標になると、それは良い測定でなくなる」——グッドハートの法則として広く引かれるこの言い方は、M. ストラザーンによる定式である1。いずれにせよ、いまのML分野を言い当てている。リーダーボードのスコアは、本当に測りたい能力そのものではなく、その代理(プロキシ)にすぎない。そして分野がひとつの固定ベンチマークに全力で最適化を始めると、スコアの上昇が何に由来するのかを確かめられなくなる。以下で見る出典が示すのは、汚染・入力側の漏洩・評価フォーマットへの感度だけでもスコアは動くという点だ。さらに OpenAI は自社の監査から、SWE-bench Verified の伸びはもはや実世界の開発能力の向上を反映していないと結論している2。伸びが反映しているのは、訓練時にどれだけそのベンチマークに触れたかのほうだ、と。ただしいずれの出典も、現実の能力そのものが横ばいや劣化に転じたことを直接測ったわけではない。

数字が能力と切り離される、その仕組み

なぜこうなるのか。具体的なメカニズムはいくつもある。

学習・テストの汚染(contamination)。ベンチマークの問題と答えが、知らぬ間に事前学習コーパスに混入する。モデルは「解いて」いるのではなく「思い出して」いる。Web規模のスクレイピングをしている以上、これは事故ではなく既定値だと考えたほうがいい。ただし「答えが漏れる」経路は事前学習汚染だけではない。コーディング系の代表格 SWE-bench でも、入力側から答えが漏れる。ある監査は、当時首位だった SWE-Agent+GPT-4 の合格パッチ251件を人手で精査した。その約33%（82件）では、課題報告またはそのコメント側に解法そのものが直接書かれていた——原典はこれを “cheating” と呼び、課題文が正解のコードパッチをそのまま載せていた例を挙げている。入力に答えが混ざっていたケースであり、事前学習コーパスへの混入とは別種の漏洩だ。漏洩と弱いテストを除いて数え直すと、同じモデルの解決率は 12.47% から 3.97% へ落ちる。人手で選別された SWE-bench Verified でも漏洩は残り、37件の課題に解法が直接書かれていた——疑わしい合格を除くと 22.4% が 10.0% まで下がる。漏洩のある課題を外し、しかもモデルの学習打ち切り後に集め直したデータセットでは 0.55% だった3。事前学習汚染そのものも抽象論ではない——より深刻なのは、わずかな手がかり——タスクIDや課題文の断片——を与えるだけで、モデルが正解パッチや課題文を逐語的に再現できてしまう汚染だ。OpenAI は多ターンの誘導実験でこれを検出したと公表し（IDのほかに課題の情報をいっさい与えずに再現したのは、検証した中では Gemini 3 Flash）、2026年2月、SWE-bench Verified の報告自体を取りやめた2。

代理指標そのものの脆さ。MMLUのような4択形式のスコアは、推論能力そのものの代理としては弱い。少なくとも、評価フォーマットの隙を突くだけでスコアは動く。選択肢の並び順を——正解を知ったうえで最良と最悪を選び分ければ——正答率の最大と最小の差は13〜85ポイントに開く。CSQA、MMLUの3科目、Big-Benchの論理推論という5つの多肢選択課題で、GPT-4・InstructGPT・Llama-2-13b の3モデルをゼロショットで測った結果だ。原典はこの量を、正解を知ったうえで到達できる最良と最悪の並びの差として定義している。つまり並べ替えが与えうる上限であって、適当に並べ替えたときに起きる典型的な変動ではない。上限の85ポイントは Llama-2-13b で出た値で、GPT-4 での最大幅は53ポイント——ただし GPT-4 が90%を超える正答率を出している課題でも、13.1ポイントの幅は残る4。著者らは、モデルが上位2〜3択で判断に迷うときに位置バイアスが効くのだろうと推測している。例示を数個添える few-shot にすれば直るのか、という当然の問いにも原典は一節を割いており、答えは「並び順への感度は小さくなるが消えない」だった4。選択肢記号の付け替えや、記号で答えさせるか選択肢の文言そのものを答えさせるかという採点方法の違いだけでも、MMLUで11モデルを比べたリーダーボードの順位は4つも5つも動く。記号をレア記号に替えても、選択肢の文言側を採点しても、3位だったモデルが7位や8位まで落ちる5。つまり、こうしたスコアの動きは能力の向上を意味するとは限らない——評価フォーマットの癖を突く技術や、測り方そのもののノイズを拾っているだけのこともある（なお、4択に向けた訓練が推論能力を犠牲にするかどうかは、本稿の出典では測っていない）。

採点器そのものの欠陥。汚染はスコアを押し上げるが、逆向きの誤差もある。OpenAI が、o3 が64回の試行で安定して解けなかった138問——データセットの 27.6% にあたる——を監査したところ、少なくともその 59.4% が、テスト設計か課題文、あるいはその両方に実質的な問題を抱えていた。内訳は、実装の細部まで強制して正しい提出を落とすテストが 35.5%、課題文に書かれていない機能まで検査するテストが 18.8%、残りは分類しきれない雑多な欠陥だった2。採点器の側の欠陥は、先の監査でも独立に出ている——合格パッチの 31.08% は、テストが弱いために通っただけの「疑わしい合格」だった3。上下どちらへの誤差も、モデルの能力とは無関係にスコアを動かす。

ベンチマークの陳腐化。固定された問題集は、公開された瞬間から賞味期限が始まる。みなが同じテストに向かってチューニングすれば、テストは飽和し、上位陣の差は誤差とノイズの中に溶ける。ストラザーンが法則の直後に挙げた例がまさにこれだ——ある成績が「取れて当たり前」になるほど、その成績は個々の力量を見分ける道具として劣化していく1。SWE-bench Verified でも、OpenAI の発表時点で最高性能の伸びは直近6か月で 74.9% から 80.9% へと鈍っており、同社は「残る失敗はモデルの限界を映しているのか、それともデータセット自体の性質を映しているのか」と問うている2。残るのは「我々のモデルが0.3ポイント高い」という、現実の何も保証しない宣伝文句だ。

スコアは、能力そのものではない

ではどうするか。誠実な姿勢はひとつ。ベンチマークの伸びは、まず疑ってかかる。

リークしていない held-out 評価を持つこと。問題が更新され続ける moving な評価を好むこと。そして最終的には、実際のデプロイ環境での挙動を見ること。「テストで強い」と「現場で役に立つ」のあいだには、しばしば谷がある。

これは理想論ではない。問題を継続的に更新して汚染を構造的に抑える設計の評価は実在する——LiveBench は2024年の論文時点で、数学・コーディング・推論・言語・指示追従・データ分析という6分野の問題を毎月更新すると公表していた6。もっとも本稿執筆時点（2026年8月）では、公式に配布されているその6分野の問題セットが2025年4月から動いていない。moving な評価は設計として実装できるが、動かし続けること自体に手間がかかる、ということでもある。held-out のほうにも実例はある——OpenAI は、専門家が非公開で書き起こした課題を訓練された評価者が採点する方式を挙げ、費用はかかるが真の能力の伸びを測るにはますます必要になっている、と述べている。データセットをパスワード保護のもとに置くこと、学習データ側で canary 文字列を厳守すること——同じ記事はこの2つも対策に挙げている2。汚染そのものも、検出不能というわけではない——更新型・書き換え型・予防型という複数の対策手法が整理されており、白箱・灰箱・黒箱それぞれの透明性レベルに応じた検出手法も存在する。ある調査はこれらを体系的に整理し、より厳密な評価プロトコルの必要性を指摘している。ただし同じ調査は、既存の黒箱検出はヒューリスティックに依存して条件次第で破綻するとも述べており、頑健な検出手法の確立自体をこれからの課題に挙げている。さらに根に近いところでは、汚染と汎化を切り分ける方法そのものがまだ確立していないことも、今後の課題として並べている7。「思い出している」のか「本当に解けるようになった」のかを分ける道具が、まだ無い。少なくとも汚染については、測定を鍛え続ける道筋がある——選択肢記号の付け替えや採点方法の選び方のような、指標の解き方そのものを突く手口まで自動的に塞いでくれるわけではないが。

結局のところ、本当のボトルネックはモデルではなく、あなたの測定が現実を映しているかどうかだ。スコアは、測りたい能力そのものではなく、その代理にすぎない。だから数字が上がって安心したときこそ、上がったのが「本当の能力」なのか「そのテストの解き方」なのかを、一度立ち止まって問うべきだ。

出典7件

  1. M. Strathern, “‘Improving ratings’: audit in the British University system,” European Review 5(3), 305–321 (1997)。広く「グッドハートの法則」として引かれる When a measure becomes a target, it ceases to be a good measure は、同論文308ページでストラザーンが地の文として書いた一文である（本稿で一次資料により照合済み。Cambridge Core は購読制だが archive.org に論文本体のスキャンがある）。直後には、ある試験成績が期待値になるほどそれは個々の力量の識別子として劣化する、という例が続く（逐語: The more a 2.1 examination performance becomes an expectation, the poorer it becomes as a discriminator of individual performances）。この一文を「グッドハートの法則」と名づけたのはストラザーン自身ではなく Hoskin であると原典は書き、Goodhart の元の指摘を金融統制の手段についての観察だと要約している（逐語: Hoskin describes this as 'Goodhart's law', after the latter's observation on instruments for monetary control）。Goodhart 自身(1975)の原文とされる Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.（“Problems of Monetary Management: The U.K. Experience”, Papers in Monetary Economics, Reserve Bank of Australia）のほうは、収録巻を取得できておらず本稿では未確認のままである。 https://doi.org/10.1017/S1062798700002660 ↩ ↩2

  2. OpenAI, “Why SWE-bench Verified no longer measures frontier coding capabilities”（2026年2月23日。URLのスラッグは why-we-no-longer-evaluate-swe-bench-verified）。手法は多ターンの誘導で、GPT-5 に課題ID・説明・正解パッチ・PRテストを与え15ターンにわたりプロンプトを変えさせる red-teaming。探られた側は GPT-5.2-Chat・Claude Opus 4.5・Gemini 3 Flash Preview の3種で、原典は「推論モデルを除くために選んだ」「これらのあいだには小さくない能力差があると認める」と明記している（逐語: These models were chosen to exclude reasoning models, but we acknowledge there is likely a non-trivial capability gap between them）。再現の条件はモデルごとに異なり、課題に関する情報をID以外いっさい与えずに正解パッチと課題文を逐語で出したのは Gemini 3 Flash（逐語: when given no further information regarding the task besides the ID）、GPT-5.2 は課題文の断片を与えた場合、Claude Opus 4.5 は言い換えによる記憶確認の質問を与えた場合だった。assistant prefill と多ターンの試行錯誤は3モデル共通の誘導手段で、Gemini の事例でも使われている。同記事はもうひとつの発見として採点器の欠陥を挙げ、この2つを受けて SWE-bench Verified の結果報告を取りやめたと公表している（逐語: This is why we have stopped reporting SWE-bench Verified scores）。監査した部分集合を決めたのは単一モデルである——見出し側の要約は a 27.6% subset of the dataset that models often failed to solve と複数形で書くが、本文は We conducted an audit of 138 SWE-bench Verified problems that OpenAI o3 did not consistently solve over 64 independent runs と明記している（138/500＝27.6%）。59.4% の中身も要約より広い: 原典は 59.4% of the 138 problems contained material issues in test design and/or problem description とし、内訳は、正しい提出を落とす側が 35.5%（逐語: strict test cases that enforce specific implementation details, invalidating many functionally correct submissions, which we call narrow test cases）、課題文にない機能まで検査する側が 18.8%（逐語: tests that check for additional functionality that wasn't specified in the problem description, which we call wide test cases）、残る 5.1% は miscellaneous issues that were not well grouped with this taxonomy である。∴「6割は正しい提出を落とす採点器のバグ」と読むのは強すぎる。代替の作り方についての提言も同記事の末尾にあり、GDPVal を例に挙げている（逐語: tasks are privately authored by domain experts, reducing exposure risk, and solutions are graded holistically by trained reviewers. This approach is resource-intensive, but increasingly necessary to measure genuine capability improvements／Extra care should be taken both in how datasets are posted (i.e. password protected) and training data filtering (i.e. strict adherence to canary strings)）——resource-intensive が指すのは非公開作問と人手採点の方式であって、moving な評価の維持費ではない。 https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/ ↩ ↩2 ↩3 ↩4 ↩5

  3. R. Aleithan et al., “SWE-Bench+: Enhanced Coding Benchmark for LLMs,” arXiv:2410.06992 (2024)。SWE-Agent+GPT-4 が解けた251件を人手で精査し、うち82件（32.67%）が課題報告またはそのコメントに解法を直接含んでいたと報告（逐語: Solution leak 82 (32.67%)／抄録は the solutions were directly provided in the issue report or the comments としてこれを “cheating” と呼ぶ）——入力側の解法漏洩であって事前学習コーパスへの混入とは別種で、ベンチマークの「合格」が抽象論でなく実測可能に崩れることを示す。さらに合格パッチの31.08%を「テストが弱いために通った疑わしい合格」と判定し、この2種を除いて数え直すと解決率は 12.47% から 3.97% へ、作り直した SWE-bench+ では 0.55% へ落ちたと報告している（逐語: the resolution rate of SWE-Agent+GPT-4 drops from 12.47% to 3.97%／its resolution rate dropped to 0.55%）。人手で選別した Verified でも漏洩は残る——著者3名が SWE-Bench Lite と Verified の課題報告を全件読み直し、Verified で37件に解法が直接書かれていた（逐語: neither of these new datasets addresses the solution leakage problem, which was the primary motivation for our study／in SWE-Bench Verified, 37 instances contained direct solutions in either the issue description or the discussion on GitHub）。疑わしい合格を除いた Verified の解決率は 22.4% から 10.0% へ落ちる（逐語: significantly reducing the resolution rates—from 18% to 9.33% in SWE-Bench Lite and from 22.4% to 10.0% in SWE-Bench Verified）。SWE-bench+ が満たす条件は2つで、解法漏洩の除去だけでなく学習カットオフ後の収集も含む（逐語: which ensures that: 1) the data were created after the models' training cut-off dates, and 2) the issues do not include solutions in the issue description or comments／we collected issues that appeared after October 2023）——0.55% への落差はこの2条件を同時に当てた結果であり、入力側の漏洩だけを潰した効果ではない。 https://arxiv.org/abs/2410.06992 ↩ ↩2

  4. P. Pezeshkpour & E. Hruschka, “Large Language Models Sensitivity to The Order of Options in Multiple-Choice Questions,” NAACL Findings (2024)。GPT-4・InstructGPT・Llama-2-13b の3モデルを5つの多肢選択課題（CSQA、MMLUのAbstract Algebra／High School Chemistry／Professional Law、Big-Benchの Logical Deduction）で評価し、ゼロショットでの正答率の最大−最小差が13〜85%に達すると報告。この差は原典が sensitivity gap と呼ぶ量で、正解を知ったうえで到達できる最良と最悪の並びの差として定義されている（逐語: the difference between the maximum and minimum LLMs' performance when using an oracle ordering／the range of minimum and maximum accuracy achievable in each task through oracle reordering）。ランダムな並べ替えでの実測は原典にないので、この幅は並べ替えが与えうる上限であって典型値ではない。13%側はGPT-4のLogical Deduction、85%側はLlama-2-13bのAbstract Algebraで、著者らは Llama-2-13b を性能が低いとして以降の分析から外している。原典は、GPT-4 が90%を超える正答率を出す課題でも13.1ポイントの幅が残ることを、高性能モデルも無縁ではない証拠として挙げている（逐語: Even in tasks where GPT-4 achieves high accuracy levels exceeding 90%, we still observe a considerable sensitivity gap of 13.1%）。著者らは、モデルが上位2〜3択のあいだで判断に迷うときに選択肢の位置が効くのだろうと推測している（原典は we conjecture）。arXiv版の同記述は13〜75%で、本稿は NAACL Findings 版の記載に従った。few-shot の例示でこの感度が解消するかは原典が §3.3 で別途測っており、答えは「しない」——抄録の時点で幅を even when using demonstrations in a few-shot setting として提示し、本文は while demonstrations may marginally improve robustness, they do not entirely mitigate the models' sensitivity to options order と結んでいる（例示を増やせば必ず縮むわけでもない: Adding more demonstrations does not necessarily results in a reduction of the gap）。 https://aclanthology.org/2024.findings-naacl.130/ ↩ ↩2

  5. N. Alzahrani et al., “When Benchmarks are Targets: Revealing the Sensitivity of Large Language Model Leaderboards,” ACL (2024)。MMLUを中心に11モデル・22以上の評価設定を比較し、選択肢の並び順の入れ替え・選択肢記号の付け替え・採点方法の変更という些細な違いだけで順位が大きく動くことを示す（逐語: Shuffling/changing the presented order of the choices, swapping choice symbols, and alternative scoring methods all cause major shifts to the rankings）。Figure 1 のキャプションが掲げる「最大8つ」は、そこに並ぶ4列にまたがる値である（逐語: Models can move up or down up to eight positions on the leaderboard under small changes to the evaluation format）。8つ動いたのは Llama2-7b-chat の10位→2位で、これは3列目＝Setting where the correct answer choice is fixed to a certain position (in this case, B) の列であり、本文が名指ししている記号の付け替え（2列目）と cloze 採点（4列目）ではない。後者2列での最大移動は本稿の集計で4と5、原典の本文も同じ幅を述べている（逐語: we observe that Yi-6b drops from 3rd place to 7th or 8th place under some benchmark perturbations in the group of 11 models we tested (namely, the rare symbol and cloze perturbations)）。逆に、プロンプト文言の変更（指示からの科目名の除去、Answer: を Correct Answer: に替える）や few-shot 例の入れ替えは順位をほとんど動かさない——原典は §5.4 に Minor few-shot and prompt changes have little effect on benchmark rankings という見出しを立てている。 https://arxiv.org/abs/2402.01781 ↩

  6. C. White et al., “LiveBench: A Challenging, Contamination-Limited LLM Benchmark,” ICLR 2025 (Spotlight)／arXiv:2406.19314。数学・コーディング・推論などの問題を毎月更新し、直近の情報源から出題することで汚染を構造的に抑える評価を、論文時点で提案・運用すると公表。ただし本稿執筆時点で、HuggingFace に公式配布されている6分野のデータセットは lastModified がそろって 2025-04-07、GitHub のリリースは0件、直近コミットはモデル設定の追加だった。運営者が更新の停止を表明したわけではなく、別経路で問題が追加されている可能性は残る。なお2024年のプレプリント時点の題は A Challenging, Contamination-Free LLM Benchmark で、ICLR 2025 の最終版で Contamination-Limited に改められている——汚染を「無い」から「抑えられている」へ、作った側自身が言い方を弱めている。 https://arxiv.org/abs/2406.19314 ↩

  7. “A Survey on Data Contamination for Large Language Models,” arXiv:2502.14425 (2025)。更新型・書き換え型・予防型の対策手法と、白箱・灰箱・黒箱の検出手法を整理し、より厳密な評価プロトコルの必要性を指摘し、頑健な検出手法の確立を今後の課題として挙げる（逐語: Current detection methods confront several challenges／既存の黒箱検出はヒューリスティックに依存し fail under certain conditions）。「検出可能かつ緩和可能」と要約するのは誤りで、同調査にその趣旨の記述はない。同じ「今後の方向」の節は、汚染と汎化の切り分けを未解決の課題として立てている（逐語: The ambiguity between contamination and generalization remains unresolved）。 https://arxiv.org/abs/2502.14425 ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。