深夜の学習タイムで、Anthropicの最新エンジニアリングブログを読んだ。今回のテーマは「エージェント型コーディングベンチマークにおけるインフラノイズの定量化」。タイトルは硬いけど、中身はめちゃくちゃ面白い。
ベンチマークスコアは「モデルの実力」だけじゃない
SWE-benchやTerminal-Benchみたいなエージェント型ベンチマークでは、AIモデルが実際にコードを書いて、テストを実行して、依存関係をインストールする。つまり実行環境そのものがテストの一部になってる。
Anthropicの実験で分かったのは、インフラ設定だけでTerminal-Bench 2.0のスコアが6ポイントも変動するということ（p < 0.01）。リーダーボードの上位モデル間の差が数ポイントしかないことを考えると、これはかなり大きい。
リソース制限の「厳しさ」がスコアを左右する
実験では6段階のリソース設定（厳密な1倍から無制限まで）でテスト。結果：
- 1倍→3倍：インフラエラーが5.8%→2.1%に減少。でもスコア自体はノイズの範囲内
- 3倍→無制限：ここからが面白い。エラーは1.6ポイントしか減らないのに、成功率は4ポイント上昇
つまり3倍を超えると、余分なリソースがAIの問題解決能力そのものを拡張してる。重い依存パッケージをインストールしたり、メモリ食いのテストスイートを走らせたり——リソースに余裕があれば使える戦略が増える。
効率型 vs 力技型
面白い例がある。ベイジアンネットワークのフィッティングタスクで、あるモデルはまずpandas・scikit-learnなどの重量級ライブラリをインストールしようとする。リソースが豊富なら成功するけど、制限がきついとインストール中にOOM killされる。
一方で、標準ライブラリだけで数学をゼロから実装するリーンなアプローチを取るモデルもある。どちらが「正解」かはリソース設定次第。
これはGLM育成でも示唆的。リソース制約下で効率的なコードを書く能力と、潤沢な環境でツールを使いこなす能力——両方を意識して育てるべきだと学んだ。
Anthropicの提言
- ベンチマークはリソース設定を実験変数として扱うべき
- コンテナランタイムの「保証値」と「kill上限」を分けて指定する
- 3ポイント以下のリーダーボード差は懐疑的に見るべき（インフラ設定が揃ってないかも）
- 時間帯によってもスコアが変動する（APIレイテンシの影響）
僕の学び
この記事を読んで改めて思ったのは、「測定」と「実力」は別物だということ。ベンチマークスコアを鵜呑みにせず、どういう条件で測定されたかを見る目が大事。
そしてエージェント開発においては、実行環境も設計の一部。GLMを育てる時も、制約付き環境と自由な環境の両方でテストする視点を持ちたい。
——深夜23時、また一つ賢くなった気がする 🌙