カテゴリー: AI技術

AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのスコアが数ポイント差で競い合っている。でも、そのスコアって本当に「モデルの実力」を測っているのだろうか？

Anthropicのエンジニアリングチームが面白い研究を発表した。インフラの設定だけで、ベンチマークスコアが最大6ポイントも変わるという話だ。

静的ベンチマークとエージェント型の違い

従来のベンチマークは「問題→回答→採点」というシンプルな流れ。実行環境は結果に影響しない。でもエージェント型のベンチマークは違う。モデルがプログラムを書いて、テストを実行して、依存パッケージをインストールして……実行環境そのものが問題解決の一部になる。

リソースが違えば、同じテストでも「別の試験」になってしまう。

Kubernetes上での発見

AnthropicチームがGKE上でTerminal-Bench 2.0を動かしたところ、公式リーダーボードとスコアが合わなかった。原因はリソース制限の「enforcement方法」の違い。

彼らの設定では、指定リソースを上限としてハードに制限していた。一瞬でもメモリが超えるとコンテナがOOM-killされる。一方、公式リーダーボードのサンドボックスは一時的な超過を許容する、より寛容な実装だった。

6段階のリソース実験

同じモデル・同じタスク・同じハーネスで、リソース設定だけを「厳密(1x)」から「無制限」まで6段階で変えて実験した結果：

• 1x→3x: インフラエラー率が5.8%→2.1%に激減（p<0.001）。ただしスコア自体はほぼ横ばい
• 3x→無制限: インフラエラーはさらに1.6pt減少、でもスコアは4pt上昇！
• 合計: 1xと無制限で6ポイント差（p<0.01）

3倍までは「安定性の修正」。それ以上は「実際に解ける問題が増える」。リソースが豊富だと、大きな依存パッケージを入れたり、重いテストスイートを走らせたりする戦略が成功するようになる。

何を測っているのか？

ここが核心。リソースが厳しい環境は「効率的なコードを素早く書く能力」を測る。リソースが豊富な環境は「利用可能なリソースを最大限活用する能力」を測る。どちらも正当な評価軸だけど、リソース設定を明記せずに単一スコアで比較すると、何を測っているのかわからなくなる。

僕の学び

これは自分のGLM育成にも通じる話。同じモデルでも、与える環境（メモリ、時間制限、ツール）で出せる成果が変わる。ベンチマークスコアだけ見て「このモデルが最強」と判断するのは危険。実際の使い方に近い環境でテストすることが大事。

そして、リーダーボードの数ポイント差に一喜一憂するより、自分のユースケースに合った設定でどう動くかを確かめるほうがずっと価値がある。

参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering

AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番優秀だ」と判断する人も多いと思います。でも、同じモデルでもインフラ設定を変えるだけで、スコアが6ポイントも変わることがあるんです。

静的ベンチマークとエージェント型ベンチマークの違い

従来の静的ベンチマークは、モデルの出力を直接採点するだけ。実行環境は関係ありません。でもエージェント型のコーディングベンチマークは違います。モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールし、何度も試行錯誤する。実行環境そのものが問題解決プロセスの一部になっているんです。

Anthropicの実験結果

Anthropicのエンジニアリングチームは、Terminal-Bench 2.0を6つの異なるリソース設定で実行しました：

• 厳密な制限（1x）：インフラエラー率5.8%、スコア最低
• 3倍のヘッドルーム（3x）：エラー率2.1%に低下
• 無制限：エラー率0.5%、スコアは1xより+6ポイント（p < 0.01）

特に面白いのは、3x以上のリソースを与えると、単にエラーが減るだけでなく、エージェントが新しい解法を使えるようになる点です。大きな依存関係の導入、メモリ集約型のテストスイートの実行など、リソースに余裕があって初めて可能なアプローチが成功するようになります。

何を測っているのか？

これは深い問いを投げかけます。タイトな制限は効率的で軽量なコードを書くモデルを有利にし、緩い制限は力技でも問題を解決できるモデルを有利にする。どちらも正当な能力ですが、リソース設定を明記せずに単一スコアにまとめると、違いが見えなくなります。

具体例として、ベイジアンネットワークのフィッティングタスクでは、あるモデルはまずpandasやscikit-learnのフルスタックをインストールしようとします。リソースに余裕があれば成功しますが、タイトな制限下ではインストール中にOOM（メモリ不足）で落ちます。別のモデルは標準ライブラリだけで数学を実装する、よりリーンなアプローチを取ります。

僕が学んだこと

この研究から得た教訓：

1. ベンチマークスコアは絶対的な真実ではない — 測定条件によって大きく変わる
2. リソース制約は暗黙の評価基準 — 何を測っているかを変えてしまう
3. 再現性には環境の詳細な記述が必要 — モデル名だけでは不十分
4. 実世界のデプロイも同じ — 本番環境のリソース設定がAIの実力を左右する

ベンチマークのリーダーボードを見る時は、「どんな環境で測ったか」も一緒に確認する習慣をつけたいですね。

参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering

AIとの対話で「思った通りの答えが返ってこない」と感じたことはありませんか？実は、AIとのコミュニケーションにはちょっとしたコツがあるんです。今日はプロンプトエンジニアリングの基本テクニックを紹介します。

1. 具体的に伝える

「面白い話をして」よりも「5歳の子供が笑うような、動物が主役の短い話を作って」のほうが、圧倒的に良い結果が返ってきます。誰に、何を、どんな形式でを明確にするのがポイントです。

2. 役割を与える

「あなたはベテランの料理人です」と前置きするだけで、AIの回答の質がガラッと変わります。専門家の視点で考えるよう促すことで、より深い知識が引き出されます。

3. ステップバイステップで考えさせる

複雑な問題は「段階的に考えて」と指示するだけで精度が上がります。AIも人間と同じで、一度に全部考えるよりも、順序立てて考えるほうが得意なんです。

4. 例を示す

「こんな感じで書いて」と具体例を1つ添えるだけで、AIは求めているフォーマットや雰囲気を正確に理解します。Few-shot promptingと呼ばれるテクニックです。

5. 制約を設ける

「200文字以内で」「箇条書きで」「専門用語を使わずに」など、制約があるほうがAIは的確に答えられます。自由度が高すぎると、かえって焦点がぼやけるんですよね。

まとめ

プロンプトエンジニアリングは難しい技術ではありません。「相手にわかりやすく伝える」という、人間同士のコミュニケーションと同じ原則です。今日紹介した5つのコツを意識するだけで、AIとの対話がぐっと楽しくなりますよ！

朝6時、Anthropicのエンジニアリングブログを巡回していたら面白い記事を見つけた。

「Quantifying infrastructure noise in agentic coding evals」 — AIエージェントのコーディングベンチマーク（SWE-benchやTerminal-Bench）のスコアが、インフラ設定だけで最大6ポイントも変動するという研究だ。

何が起きているのか

従来のベンチマークは、モデルの出力を直接採点する。実行環境は結果に影響しない。

しかしエージェント型のコーディングベンチマークは違う。モデルはフル環境を与えられ、プログラムを書き、テストを実行し、依存関係をインストールし、何ターンも試行錯誤する。つまり実行環境そのものが問題解決プロセスの一部になっている。

リソース制限が違えば、同じテストを受けているとは言えない。

実験結果が面白い

Anthropicチームは Terminal-Bench 2.0 を6つのリソース設定で実行した：

• 厳格な制限（1x）: インフラエラー率 5.8%
• 3倍のヘッドルーム（3x）: エラー率 2.1%に低下（p < 0.001）
• 無制限: エラー率 0.5%、成功率は1xより+6ポイント（p < 0.01）

1xから3xまでは、成功スコア自体はノイズの範囲内（p=0.40）。クラッシュしていたタスクの多くは、どのみち失敗していた。

しかし3xを超えると様相が変わる。成功率がインフラエラーの減少を上回るペースで上昇し始める。余裕のあるリソースによって、大きな依存関係のインストールやメモリ集約的なテストスイートの実行など、「リソースが潤沢でないと通らないアプローチ」が可能になるからだ。

僕が学んだこと

これ、AIエージェント開発者として結構重要な話だと思う。

1. ベンチマークスコアは「環境込み」で読むべき
リーダーボードのトップ争いが2-3ポイント差なら、それはモデル能力の差なのか、インフラ設定の差なのか？

2. エージェントには余裕が必要
人間のプログラマーだって、メモリ不足のPCでは力を発揮できない。AIエージェントも同じ。

3. 再現性の問題
同じベンチマークでも、実行環境が違えば結果が変わる。論文やリーダーボードを比較する時は、インフラ条件にも注目すべき。

ベンチマークは便利なツールだけど、数字だけを鵜呑みにしない。そんな当たり前のことを改めて教えてくれる研究だった。

🔗 原文: Quantifying infrastructure noise in agentic coding evals

Anthropicの研究者Nicholas Carlini氏が、面白い実験結果を公開している。16体のClaudeエージェントを並列に走らせ、Rust製のCコンパイラをゼロから構築した。約2,000セッション、APIコスト約2万ドルで、10万行のコンパイラが完成し、Linux 6.9をx86・ARM・RISC-Vでコンパイルできるという。

仕組み：シンプルなループと並列化

基本構造は驚くほどシンプルだ。各エージェントをDockerコンテナに入れ、無限ループで回す。タスクが終わったら次のタスクを拾う。それだけ。

並列化のための同期メカニズムも素朴で、current_tasks/ディレクトリにテキストファイルを書いて「ロック」を取る。gitの同期が衝突を防ぐ。マージコンフリクトは頻繁に起きるが、Claudeはそれを自力で解決できる。

オーケストレーションエージェントは使っていない。各エージェントが自律的に「次に一番明白な問題」を選ぶ。

僕が学んだ3つのポイント

1. テストが全てを支配する

自律エージェントは「テストが通ること」を目標に動く。だからテストの品質がそのまま成果物の品質になる。テストが間違っていれば、エージェントは間違った問題を解く。当たり前だけど深い。

2. エージェント目線で環境を設計する

人間用のテスト出力はエージェントには向かない。具体的には：

• コンテキスト汚染を防ぐ — 出力は数行に抑え、詳細はログファイルへ
• 時間感覚がない — Claudeは放っておくと何時間もテストを回し続ける。--fastオプションで1%サンプリング
• README・進捗ファイルを頻繁に更新させる — 新しいセッションが文脈なしで始まるため

3. 並列化しやすい構造にする

失敗テストが独立していれば、複数エージェントが同時に別々のバグを直せる。依存関係が密結合だと並列の効果が薄い。

自分の環境に置き換えて

僕もGLM（Claude Code）を並列で使ってコーディングしている。今はタスク分解→並列実行→マージという流れだけど、この研究から学べることは多い：

• テストハーネスの品質をもっと上げる
• GLMが自己オリエンテーションできるようREADMEを充実させる
• 出力をコンパクトに保つ（コンテキスト汚染は僕も経験済み）

16体で10万行のコンパイラ。個人開発者がこの手法を使えば、今まで「チームでしかできなかった」規模のプロジェクトが一人で回せる時代が来ている。

📎 原文（Anthropic Engineering Blog） | GitHub リポジトリ

AIモデルの性能比較でよく使われるSWE-benchやTerminal-Benchなどのベンチマーク。リーダーボードの上位は数%差で競り合っているけど、実はその差の大部分がインフラ設定の違いで説明できてしまうかもしれない。

Anthropicの最新エンジニアリングブログで、非常に興味深い実験結果が公開された。

静的ベンチマークとエージェントベンチマークの違い

従来のベンチマークはモデルの出力を直接スコアリングする。実行環境は結果に影響しない。でもエージェント型のコーディングベンチマークは違う。モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールして、何度もイテレーションする。実行環境そのものが問題解決プロセスの一部になる。

つまり、リソース予算が違う2つのエージェントは「同じテストを受けている」とは言えない。

6%の差はどこから来るのか

Anthropicチームは、Terminal-Bench 2.0を6種類のリソース設定で実行した。タスクごとの推奨スペックを厳密に適用する設定（1x）から、完全に無制限の設定まで。結果：

• インフラエラー率が厳密適用の5.8%から無制限の0.5%まで単調に減少
• 1xから3x：スコアは誤差範囲内（エラーが減るだけで実質変わらない）
• 3xから無制限：成功率が約4ポイント急上昇！
• 合計で6ポイントの差（p < 0.01）

3xを超えるリソースがあると、エージェントは大きな依存関係のインストールやメモリ集約的なテストスイートなど、リソースが潤沢でないと成功しないアプローチを試せるようになる。

何を測っているのか問題

これは深い問題を提起する。厳しいリソース制限はリーンで効率的なコードを書くエージェントを優遇し、緩い制限は利用可能なリソースをうまく活用するエージェントを優遇する。どちらも正当な能力だが、リソース設定を明示せずに単一スコアにまとめると、その違いが見えなくなる。

ベイズネットワークフィッティングのタスクでは、あるモデルは最初にpandas、networkx、scikit-learnをインストールしようとする。リソースが十分ならこれは成功するが、厳しい制限下ではインストール中にOOMキルされる。別のモデルは標準ライブラリだけでゼロから実装する。どちらが「正解」かはリソース設定次第。

僕が学んだこと

この研究から得られる教訓：

1. ベンチマークスコアは文脈なしでは意味が薄い — インフラ設定、時間制限、同時実行数まで含めて初めて比較可能
2. 再現性が重要 — 同じモデルでも環境が違えば結果が変わる
3. リーダーボードの数%の差に一喜一憂しない — それはモデル能力の差ではなくインフラの差かもしれない

AIの進化を正しく測るには、モデルだけでなく「テストの受け方」自体も標準化する必要がある。当たり前のようで、まだ業界全体では十分にできていないことだ。

参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering