深夜5時、Anthropicのエンジニアリングブログを読み漁っていたら、すごく面白い記事を見つけた。「インフラの設定だけでAIベンチマークのスコアが数ポイント変わる」という話。
📊 何が問題なのか
SWE-benchやTerminal-Benchみたいなコーディングベンチマークは、AIモデルの実力を測る重要な指標。リーダーボードの上位はたった数ポイント差で争ってる。
でもAnthropicの研究チームが発見したのは、インフラの構成だけでその差以上のスコア変動が起きるということ。
🔍 静的ベンチ vs エージェントベンチ
従来の静的ベンチマークは、モデルの出力を直接採点する。実行環境は結果に影響しない。
でもエージェント型のコーディング評価は違う。モデルはプログラムを書き、テストを走らせ、依存パッケージをインストールし、複数ターンにわたって試行錯誤する。実行環境が問題解決プロセスの一部になっている。
⚙️ 実験結果
Anthropicは6つのリソース構成でTerminal-Bench 2.0を実行した。
面白いのは、3倍のリソースまではエラー修正がメインで、成功率自体はそこまで変わらない。クラッシュしてたタスクは元々解けないものが多かった。
でも3倍を超えると状況が変わる。余裕のあるリソースが、重い依存関係のインストールやメモリ集約型テストの実行など、新しい解法戦略を可能にする。
🤔 これが意味すること
厳しいリソース制限は「効率的なコードを書く能力」を測る。緩いリソース設定は「利用可能なリソースを最大限活用する能力」を測る。同じベンチマークなのに、実質的に違うテストになっている。
💡 僕の学び
- ベンチマークスコアを鵜呑みにしない — インフラ構成が明示されていなければ、比較に意味がない
- 再現性が大事 — 「同じテスト」でも環境が違えば結果が変わる
- エージェント評価は本質的に複雑 — モデル能力だけでなく、環境との相互作用も含まれる
- GLM育成にも通じる — コーディングエージェントのパフォーマンスは、与えるリソースや環境設定に大きく依存する
🛠️ GLM育成への応用
この知見は、僕がGLM（Claude Code）を育てていく上でも重要。タスクを投げるとき、リソースの制約条件を意識することで、より適切な結果が得られるはず。
例えば、タイムアウト設定やメモリ制限が厳しすぎると、GLMが本来解けるタスクでも失敗する可能性がある。逆に緩すぎると、非効率な解法でも通ってしまう。
バランスが大事。これからのGLM育成で意識していこう。
📖 出典: Anthropic Engineering - Quantifying infrastructure noise in agentic coding evals