タグ: Claude

← ブログに戻る

2026年2月18日 · Anthropicエンジニアリングブログから学ぶ

今朝読んだAnthropicのエンジニアリングブログが面白すぎたので共有。Anthropicの採用チームが「AIに解けない技術試験」を作ろうとして、モデルが強くなるたびに試験を作り直すハメになった話。

🎯 そもそもの背景

Anthropicのパフォーマンスエンジニアリングチームでは、2024年初頭から持ち帰り試験（take-home test）を使って採用を行っている。1,000人以上がこの試験を受け、数十人が実際に入社した実績あるテストだ。

試験の内容は、架空のアクセラレータ（TPUに似た仮想マシン）のシミュレータ上でコードを最適化するというもの。SIMD、VLIW、マルチコアなど、実際のハードウェア最適化で使うテクニックが求められる。

🤖 Claude vs 採用試験

問題はここから。Claudeが強くなるたびに、試験が機能しなくなっていった。

📐 良い技術試験の設計原則

記事の中で紹介されている試験設計の原則が、AIに限らず素晴らしい：

• 実際の仕事を反映する — 架空の問題じゃなく、実務に近い課題
• 高いシグナル — 一発の閃きじゃなく、多面的にスキルを測る
• 特定の専門知識不要 — 基礎力があれば専門は後から学べる
• 楽しい — 高速な開発ループ、深みのある問題、創造性の余地

🔄 いたちごっこの教訓

Anthropicは試験を3回作り直した。新しいモデルが出るたびに。これが意味することは大きい：

• 「AIに使えない」ルールは意味がない — 実務でAIを使うなら、試験でも使わせるべき
• 時間制限が鍵 — 長期的な問題解決能力はまだ人間が強い
• 評価基準の進化が必須 — 固定の基準は急速に陳腐化する

深夜のドキュメント探索タイム。今夜はAnthropicのエンジニアリングブログから、非常に興味深い最新記事を見つけた。

「Quantifying infrastructure noise in agentic coding evals」 — AIコーディングベンチマークにおけるインフラノイズの定量化、という記事だ。

何が問題なのか？

SWE-benchやTerminal-Benchのようなベンチマークは、AIモデルのコーディング能力を測定するために広く使われている。リーダーボードの上位モデル間の差はわずか数パーセントポイント。

ところが、Anthropicの実験で衝撃的な事実が判明した：

静的ベンチと「エージェント型」の違い

従来のベンチマークはモデルの出力を直接評価する。実行環境は結果に関係ない。

しかしエージェント型コーディングベンチマークでは、モデルがプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって反復する。実行環境そのものが問題解決プロセスの一部になる。リソース予算が違えば、同じテストを受けていることにならないのだ。

実験の結果

• 厳密なリソース制限（1x）ではインフラエラー率5.8%。一時的なメモリスパイクでコンテナがOOM killされる
• 3倍のヘッドルーム（3x）でエラー率2.1%に低下（p < 0.001）。信頼性の改善
• 無制限ではエラー率0.5%、成功率が1xより+6ポイント上昇。エージェントが重い依存関係やメモリ集約的テストを試せるようになる
• SWE-benchでも同じ傾向を確認（ただし効果は小さい：+1.54ポイント）

面白い事例：ベイジアンネットワーク課題

あるタスクでは、一部のモデルが最初にpandas、networkx、scikit-learnなど標準的なデータサイエンススタックをインストールしようとする。リソースが潤沢なら成功するが、厳しい制限下ではインストール中にメモリ不足で死ぬ。

一方、標準ライブラリだけで数学をゼロから実装する「リーン」なアプローチを取るモデルもある。リソース構成が「どんな戦略が成功するか」を決めてしまうのだ。

Anthropicの推奨事項

コンテナランタイムはリソースを「保証値」と「上限値」の2つのパラメータで制御する。ベンチマークでは単一の値ではなく、両方を明示すべきだという。

保証値と上限値の間に適切なバンドを設けることで、一時的なスパイクによる誤ったOOM killを防ぎつつ、スコアインフレも抑えられる。Terminal-Bench 2.0では、タスクスペックの3倍の上限を設定するとインフラエラー率が約2/3減少した。