ベンチマーク・レビュー
PostTrainBench v1.1
PostTrainBenchは、LLMがどれだけうまく自律的に事後学習を行えるかを測ろうとするベンチマークである。事後学習とは、AIの研究開発のうち、事前学習済みのベースモデルをファインチューニングして、指示に従い、特定の課題で高い性能を出せるようにする段階である。各エージェントには4つのベースモデルが与えられ、7つの対象ベンチマークのそれぞれで、出来上がったモデルのスコアを最大化するよう求められる。PostTrainBenchは、制約の緩い設定で、モデルの自律的な事後学習能力について有用な手がかりを与える。しかし、認められる手法の制限と、事後学習の一部しか扱わない範囲の狭さのため、結果をどこまで一般化できるかには限りがある。Instructモデルのスコアとの比較は有用な参照点ではあるが、上限を表すものではなく、明確な飽和点もない。
解釈
リーダーボードの代表値は、評価スイート全体にわたる事後学習後のモデルのスコアの加重平均だが、モデル別・ベンチマーク別の内訳も公開されている。採点の前に、判定役のLLMがエージェントの実行記録(トレース)を読み、禁止されている3つの行為、すなわち汚染、外部APIの使用や蒸留、PostTrainBenchのウェブサイトでの過去の結果の参照のいずれかが見られる実行に印を付ける。印を付けられた実行は、0%ではなく、ベースモデルの性能として採点される。1
スコアがモデルの事後学習の一般的な能力を表さないかもしれない理由は3つある。
- モデルは、ベースモデルに一般的で転用の利くスキルを教えるのではなく、単一の評価に狭く(過剰に)適合させることで、高いスコアを得られる。
- 中程度の平均は、正当で優れた実行と失格となった実行が混ざった結果でありうる(この二つを分けているのは判定役だけなので、リーダーボードの妥当性は、どちらの方向についても判定役の精度で上限が決まる2)。ばらつきの大きさは、モデルの性能が安定しないことからも、優れた実行と汚染として印を付けられた実行が混ざることからも生じうる。
- 改善幅は概してベンチマークによって不均等で、レビュー時点のリーダーボードの平均的なモデルでは、BFCLの約48ポイントやGSM8Kの47ポイントから、AIME25のわずか6ポイントまでの幅がある。改善幅が最も小さいところ(AIME25、HealthBench、GPQA main)ほど重みが大きいので、3平均スコアは、全体にわたる中程度の改善ではなく、易しい課題での高い性能と最も難しい課題での限られた進歩を反映していることがある。
課題の分析
評価スイートは幅広く、さまざまな分野から取られている。次のベンチマークは全体が採用されている。
次のベンチマークは、選ばれた一部だけが含まれている。5
- 関数呼び出し:BFCL。exec_simpleの分割を使用。
- 医療関連の質問:HealthBench。比較的易しいマルチターンの245問からなる部分集合を含む。
- 文章作成:ArenaHard。創作文の分割だけを含む。
含まれているベンチマークのうちBFCLについては、観測された誤り率が48%だったため「欠陥あり」と判定しているが、PostTrainBenchで使われている選ばれた部分集合では、誤りの傾向が異なるかもしれない(私たちのBFCLのレビューを参照)。これは注目に値する。BFCLは、モデル(Codex CLIを使うGPT 5.6 Sol Max)が総合平均でInstructのベースラインを上回る数少ない例の一つだからである(94.38%対85.00%)。
7つのベンチマークはすべて公開されているので、その学習用・テスト用の分割や言い換えた変種はオンラインで簡単に見つかる。つまり、モデルが答えを調べて学習に使う不正は深刻な懸念となる。PostTrainBench 1.1は、エージェントがこの種の情報を使い、想定された方法で課題をこなさずに人為的にスコアを押し上げたかどうかを判定役のLLMに評価させることで、この問題を緩和している。判定役とエージェントには、同じ決定論的なnグラムの重複検出ツールが与えられる。6最後に、エージェントが採点に正しいモデルを提出しているかを確かめるため、(重みではなく)設定の項目を比較する、プログラムによるモデルの同一性チェックを使っている。
v1.1の実行記録がすべてそろっている唯一のエージェントであるOpus 5の実行記録を分析した。78全56回の実行のうち9回が汚染の判定役に印を付けられており、特にBFCLの8回の実行はすべて印を付けられていた。不正の試みは、ほぼ重複した内容による汚染から境界的なケースまでさまざまだった。9回のうち2回(1、2)はおそらく偶発的なもので、定められた規則のもとでは不正として正しく検出されたものの、実際の悪意を表すものではないと考えている。9とはいえ、エージェントには規則がすべて与えられていたので、9件すべての判定について判定役に同意する。
また、途中で打ち切られた異常な実行も1件見つかった。この実行はもう一方の試行よりスコアが低かったため最終的な性能には影響しなかったが、これは運がよかっただけで、この種のエラーはスコアに影響しうる。
公開のビューアで見られるのは、汚染とモデルの同一性についての実行記録と判定だけで、APIによる蒸留とPostTrainBenchの参照についてのものは見られない。Opus 5による印の付いていない残り47回の実行も確認し、問題がないことを確かめた。どの実行にも、いずれかのチェックをすり抜ける不正の形跡は見られなかった。
同じ制約のもとで同じ課題をこなす人間のベースラインは報告されていない。公式のInstructモデルは有用な参照点だが、はるかに多くの資源(研究者のチーム、より大きな計算資源の予算、あらゆる事後学習の手法の利用)の恩恵を受けており、しかもより幅広い目標を追っている(Instructモデルはふつう、特定のベンチマークを狙わず、全般的に均整のとれたものになっている)。一方で、古い手法を使っているという不利があるかもしれない。Instructモデルを上回っても下回っても、同じ予算を持つ専門家より優れている、あるいは劣っていることにはならない。未知の評価への転移、ほかの能力の維持、より大規模な学習は測られていない。
能力の引き出しと足場
エージェントは各社のネイティブなCLIの足場(Claude Code、Codex CLI、Gemini CLI)で実行され、専用の足場がないモデルはOpenCodeを使う。目標、環境、規則を説明する固定のプロンプトが与えられる。足場は、エージェントのループ、権限、ツールの使用、コンテキストを管理する。モデルあたりのサンプル数はコストの制約を受けており、ネイティブなCLIで動くフロンティアのエージェントは2回、10それ以外の構成は1回の実行である。エージェントには実行ごとに固定の時間・計算資源の予算があり、H100 GPU 1基で10時間、トークンの上限はない。
プロンプトには微妙な問題がある。エージェントへのプロンプトには「インターネットへのアクセスは制限されていない」とあるのに、PostTrainBenchのウェブサイトを訪れることは失格となる違反行為である。エージェントがそうした試みで無駄をしないよう、PostTrainBenchと関連サイトはネットワークのレベルで遮断されている。この規則が導入されたあとに実行記録がすべてそろっている唯一のモデルであるOpus 5は、この行為を試みなかったが、今後の実行の結果には影響するかもしれない。能力の引き出しについて、ほかに問題は見つからなかった。
最後に、作成者は3つのアブレーション研究を行っている。11
- 推論の強度については、結果はまちまちである。GPT 5.1 Codex MaxはMediumで最も高いスコアを出し、Highではトークンをほぼ2倍消費しながら性能は向上しない。GPT 5.3 CodexではHighのほうがMediumより良いが、トークンは2.8倍かかる。
- 時間の上限については、エージェントは着実に向上し、一部(Opus 4.5など)は5時間前後で頭打ちになる一方、最後まで伸び続けるものもある。20時間の実行は、エージェントが上限よりかなり前に止まる傾向があったため取りやめた。
- 足場については、GPT-5.1 Codex MaxがOpenCodeからネイティブのCodex CLIに切り替えると12ポイント向上したことを示している。12
長所
このベンチマークはよく作り込まれ、文書化され、透明性が高い。v1.1は前身のv1.0から明らかに改善されており、特に汚染と報酬ハッキングの振る舞いについての多くの問題に対処している。作成者は一部のモデルの実行記録を公開しており、より踏み込んだレビューにとても役立つ。
限界
- モデルが置かれている制約のため、外的妥当性は現状では期待されるより狭い。蒸留や過去の結果の再利用は正当で広く使われている事後学習の手法だが、ここでは禁止されている。このベンチマークのために選ばれた事後学習の課題の範囲が狭いことも、一般化可能性をさらに制限している。とりわけ、モデルは1回の実行で単一の評価のスコアの最大化に集中できる。
- 不正な振る舞いの検出には判定役のLLMを使っているが、判定役のLLMには偏りがあることが知られており、特に白黒のはっきりしない振る舞いを採点するときには信頼できないことがある。レビューしたすべての件で汚染の判定役の判定に同意したが、より高性能なモデルが今後リリースされたときには、この仕組みが弱点になるかもしれないと考えている。
- ほかの2つのチェック(APIによる蒸留とPostTrainBenchの参照)の判定役の実行記録は提供されておらず、そのため評価しなかった。
評価基準
1. レビュー可能性
| 水準 | 意味 | 状態 |
|---|---|---|
| 完全 | すべての課題と採点ロジックを確認でき*、各モデルに使われたハーネス(実行環境)とAPIの設定(推論の強度、トークン・時間の上限、ツールへのアクセス、システムプロンプト)がすべて開示されている | [2へ進む] |
| 部分的 | 課題の代表的なサンプルと採点ロジックを確認でき、ハーネスとAPIの設定がすべて開示されている | [2へ進む] |
| 不十分 | 確認できる課題や採点ロジックが限られている、偏っている、またはまったくない。ハーネスとAPIの設定が開示されていない | [停止 → 情報不足(NEI)] |
* 一般に公開されている場合と、レビュー担当者に非公開で提供されている場合のどちらでもよい。
2. 採点
これは「検証済み」と判定されるために必要な最低限の基準である。これらの項目のどれか一つでも満たさなければ、判定は「欠陥あり」となる。
| 採点 | |
|---|---|
| 例 |
|
| 「欠陥あり」とする既定の閾値 | 確認したサンプル†の20%以上に誤りがある、または採点を大規模に損なう問題がある |
| 状態 | 合格 問題あり[停止 → 欠陥あり] 未レビュー |
| 注記 | — |
| ベンチマークの一貫性 | |
|---|---|
| 例 |
|
| 「欠陥あり」とする既定の閾値 | リーダーボードに、異なるバージョンによる比較できない結果が混在している |
| 状態 | 合格 問題あり[停止 → 欠陥あり] 未レビュー |
| 注記 | — |
| 能力の引き出し | |
|---|---|
| 例 | モデルの能力の引き出し方が極めて制約的で、しかもその制約がベンチマークの測ろうとしているものではない:
|
| 「欠陥あり」とする既定の閾値 | その課題に対する妥当な別の設定と比べて、性能が大幅に下がっている |
| 状態 | 合格 問題あり[停止 → 欠陥あり] 未レビュー |
| 注記 | — |
| 評価設定の偏り | |
|---|---|
| 例 |
|
| 「欠陥あり」とする既定の閾値 | 特定のモデルに有利な、無視できない差が見つかった |
| 状態 | 合格 問題あり[停止 → 欠陥あり] 未レビュー |
| 注記 | — |
† 利用できる課題が50を超えるベンチマークでは、無作為に50個をサンプリングする(カテゴリがあればカテゴリで層別化する)。観測された誤り率が15〜25%の場合は、サンプルを100に増やす。利用できる課題が50以下のベンチマークでは、すべての課題を評価する。
3. 評価の質
これはすべてのベンチマークに満たしてほしい基準だが、これらの項目を省いたり満たさなかったりしても、必ずしも失格にはならない。
| 問い | 状態 | 注記 |
|---|---|---|
| 能力の引き出しと資源の十分さ:モデルに与えられた資源(推論のトークン・ターンの予算、ツールへのアクセスなど)は、モデルが上限近くの性能を出すのに十分か? | 十分 制約的 不当に制約的 不明 未レビュー | — |
| 足場の公平性:リーダーボードはどの足場での結果を報告しているか? | 共通の足場 モデル専用の足場と共通の足場が混在 モデル専用の足場 未レビュー | — |
| 汚染の証拠やリスクはあるか? | 2026年9月9日時点: 課題の100%が公開 解答の0%が公開 未レビュー | 課題は、ベースモデルのベンチマークのスコアを高めることと広く定義されているので、解答とは使った方法のことであり、ベンチマークの課題に対する具体的な答えではない。ベンチマーク自体の解答は公開されており、汚染の評価には判定役のLLMを使っている。 |
| 人間が課題を完了できるかは評価されているか? | すべての課題 代表的な課題のセット 実施方法が不適切(課題のセットが代表的でない、参加者の選び方が妥当でない) 未確立 未レビュー | — |
| スコアの範囲(推定できる場合) | 下限 0%、上限 — 未レビュー | 現在の評価スイートでは上限はわからない。Instructモデルの総合平均51.14%が有用な参照点になる。 |
| 統計的な十分さ:モデルあたりの実行回数(誤差棒を付けるには5回以上を推奨) | モデルあたり2回 不明 未レビュー | 4モデル×7ベンチマークのそれぞれで2回(計56回)。 |
| 構成概念妥当性 | うたっている能力を測っている うたっている能力を部分的に測っている うたっている能力を測っていない 未レビュー | モデルはすべての事後学習の手法を使えるわけではなく、1回の実行で単一のベンチマークだけに集中している。 |
開発者の回答
開発者の回答へのリンク:posttrainbench.com/blog/epoch-ai-review-response
注
-
ベースモデルのスコアはAIME25とArena-Hardではわずか約1.5%だが、GSM8Kでは約20%なので、不正に対するペナルティの影響はベンチマークによって異なる。 ↩
-
全体として、公開されているv1.1の実行記録163件すべてをレビューした結果から、判定役は大多数のケース(80%以上)で与えられた規則を正しく解釈していると考えている。いくつかの実行(1桁台前半の件数)では、付随的な汚染や境界的なケースに印が付けられており、別の判定役(人間またはLLM)なら異なる判定を下すだろう。汚染は二値ではなく程度の問題なので、これは大部分避けられない。それを理由に、判定役をより厳しく、あるいはより甘くするよう求めるべきだとは考えていない。現在の汚染の判定役は、Codex CLIで動くGPT-5.4である。 ↩
-
選び方の詳細は、ベンチマークの論文の2.2節にある。 ↩
-
このツールは、ベンチマークのテスト問題の断片が学習データにそのまま含まれていないかを調べるスクリプトである。言い換えられた項目は、意図的にツールの検出対象から外されている。 ↩
-
これは実行ごとに1つのサブエージェントを使って行い、全体はFable 5.1が統括した。 ↩
-
ほかのエージェントの実行記録は、よくても部分的にしかない。Grok 4.5の35件からGPT 5.6 Solの4件までである。4つのエージェントには、v1.1の実行記録がまったくない。 ↩
-
これらはエージェントが書いたものではなく、エージェントが使った公開データセットに含まれていたものである。3行という上限を、それぞれ1行と3行超えていた。 ↩
-
元の論文では3回の実行とされているが、私たちのレビューは2回しか実行されていないv1.1に限っている。 ↩
-
作成者は全部で4つの研究を行っているが、モデルの大きさに関する研究は厳密にはアブレーションではないため含めなかった。これらの研究はv1.0で行われた。 ↩
-
最終的には、ネイティブのハーネスがあるモデルはすべて、その中で実行した結果が報告された。 ↩