10月17日、Simon Mendelsohnが「"About a quarter of them contained bugs": Gemini 4's ML R&D benchmark」と題した記事を公開した。この記事では、Gemini 4 ArgonのML R&Dベンチマーク(GRB)の約25%のタスクにバグが含まれていたという問題と、それがAI能力評価の信頼性に与える影響について詳しく紹介されている。
問題の核心:ベンチマークの4分の1がそもそも解けない
Google DeepMindは2026年10月、Gemini 4 Argonの安全性レポートを公開した。このレポートの67ページに、見過ごしにくい記述が埋め込まれている。
「今回の評価サイクルで、現在のスイートに残っているオリジナルの課題のサブセットを監査した。約4分の1に、いかなる提出物もパスできないバグが含まれていた(検証器のクラッシュ、不正解の正答例など)。さらに数問は、タスクに明記されていない詳細に基づいて採点されていた。」
— Gemini 4 Argon Safety & Security Report, p.67
つまり、モデルがいくら優秀でも物理的に合格できないタスクが4分の1存在した。しかも採点基準すら問題文に書かれていないケースも複数あった。
RSI評価の仕組みと「90%ルール」
GoogleのFrontier Safety Framework(FSF)は、AIが研究開発を自律的に加速・自動化できるかどうかを判断するための枠組みだ。FSFはその判断基準として「Critical Capability Level(CCL)」を設けている。CCLとは、AIが特定の危険な能力に到達したとみなす閾値であり、到達と判定された場合は追加の安全対策が義務づけられる。言わば「このラインを超えたら危険」という社会的・組織的な合意点だ。
また、FSFが特に注視するのがRSI(Recursive Self-Improvement)、すなわちAIが自分自身の能力をさらに高めるAIを生み出す、あるいはAI開発プロセスそのものを自動化・加速させる能力だ。ML R&D領域のCCLは以下の2軸で評価される:
- ML R&D acceleration:AIがAI開発を加速させ、歴史的なペースを大幅に超えているか
- ML R&D automation:GoogleのAI研究チームの業務を完全に自動化できるか
この判断に使われるのが、GRB(Google RE-Bench)という内部ベンチマークだ。74タスクで構成され、サンドボックス環境内でエージェントを動かし、1タスクあたり2時間のタイムアウトで採点する。
合否判定のルールはシンプルで、パス率が90%を超えたらCCL到達と判断する。「100%でなく90%にしているのは、テスト環境のバグへの保守的な配慮」とレポートは説明している。
しかし、その「保守的な10%のバッファ」が、実際には25%のバグ率に対して全く不十分だったわけだ。
Argonの実際のスコアは「報告不能」
レポートが開示するArgonの成績は以下のとおりだ:
- 全体スコアは報告なし:インフラのタイムアウトで多くの実行が完了しなかったため
- 完了した実行の中では約半数を解けた
- ただし完了した実行は短いタスクに偏っており、この「半数」は実力を過大評価している
- 同じ完了済み実行で比較すると、Gemini 3.7 Flash(GRB全体で27%)と同程度の成績
Haydn Belfield氏がXへの投稿で「27%から半数へと大幅な向上」と述べたが、実際には比較対象が異なる(短タスク中心の完了済み実行 vs 全タスクの27%)として、別のユーザーから訂正が入った。
「完了した実行は短いジョブに偏っており、その同じ実行では旧モデルと同等の成績だ。27%はそのモデルのベンチマーク全体のスコアだ。『半数』が27%からの大幅な向上とは言えない。」
— Rakesh Sahni (@rakeshsahni_), X, Oct 14 2026
さらに情報が拡散するにつれて「完了済み実行」の注釈すら消え、「74タスク中約半数を解いた」という単純な表現に置き換わっていった。
バグは常に「安全寄り」に誤魔化す
Mendelsohnが指摘する構造的な問題がある。GRBのバグ(検証器のクラッシュ、不正解の正答例)はタスクを解けなくする方向にしか作用しない。つまりスコアを常に下押しする。モデルが実際には解けるのに「解けなかった」と判定されるリスクは存在するが、その逆(解けないのに「解けた」と判定される)は起きない。
これは「False Alarm(偽の警報)」はなく、「False Reassurance(偽の安心)」しか生まれない構造だ。
ベンチマークのバグは業界全体の問題
この問題はGoogleに限ったことではない。記事中では複数の事例が挙げられている:
- **SWE-bench**(コード修正ベンチマーク):OpenAIの監査で68.3%のサンプルが問題ありとして除外された
- TheoPhysEval(物理学ベンチマーク):専門家が提供した正答例に誤りがあり、改訂前後でモデルのスコアが「80%台後半→98%」まで跳ね上がった
Zhu et al.(NeurIPS 2025)は「こうした問題がエージェントの性能の過大・過小評価を相対値で最大100%引き起こしうる」と指摘している。
Googleの結論自体は妥当か
Mendelsohnは最終的に、「Gemini 4 ArgonがCCLに達していない」というGoogleの結論自体は支持できるとしている。根拠は:
- バグタスクをすべて「解けた」と仮定しても、スコアは90%閾値を下回る
- タイムアウトで未完了の実行をすべて成功と数えても、やはり閾値以下
- 完全委任のプルリクエストは2026年4月の7.5%から9月に11.9%へ増加したが、約88%はまだ人間の介入が必要
ただし問題は、この評価プロセスの透明性と再現性だ。ベンチマークは内部非公開、監査されたサブセットのサイズも非開示、採点が「バグあり除外後」なのか「込み」なのかも明確でない。
AIモデルの安全性評価が、そのモデル自身に匹敵するほど難しいエンジニアリング課題になりつつある現実を、今回の一件は改めて示している。
詳細は"About a quarter of them contained bugs": Gemini 4's ML R&D benchmarkを参照していただきたい。