自社のAIモデルに、自社の採用試験を何度も破られる——。そんな奇妙な苦闘をAnthropicのエンジニアが経験している。同社のパフォーマンス最適化チームリーダーであるTristan Humeが設計した採用用テストは、1,000人以上の候補者が受け、数十人のエンジニアを採用するための重要な評価手段として機能してきた。しかし、Claudeモデルが進化するたびにテストの有効性が失われ、三度にわたる再設計を余儀なくされた。本稿では、その過程で得られた「AIに負けない評価を設計する」という教訓を紹介する。
2023年11月、AnthropicはClaude 3 Opusの訓練に向けてGPU、TPU、Trainiumのクラスター拡大を進めていた。計算資産への投資は急増していたが、それを最適化するパフォーマンスエンジニアが圧倒的に不足していた。
Tristan HumeはTwitter（現X）で応募を呼びかけ、予想を上回る数の候補者が殺到した。しかし、従来の面接プロセスではスタッフの時間を大量に消費するため、効率的な評価方法が急務となった。その結果、2週間かけて設計されたのが「シミュレートされたアクセラレータのコード最適化」を課すテイクホームテストである。
テストの内容は本格的だった。TPUに似た仮想アクセラレータをPythonでシミュレートし、候補者はその上でコードを最適化する。スクラッチパッドメモリの手動管理、VLIW（1クロックで複数の実行ユニットを並列駆動）、SIMD（ベクトル演算）、マルチコア分散といった、実際のアクセラレータ最適化に直結する要素が盛り込まれていた。制限時間は当初4時間（後に2時間に短縮）。候補者はシリアル実装から出発し、並列性を段階的に引き出していく。
このテストは高い成果を上げた。最も高得点だった候補者は入社後すぐにカーネル最適化に貢献し、32ビットオーバーフローが原因のコンパイラバグの回避策を発見した。紙面上の経歴が乏しい学部卒の候補者であっても、テストで高いスキルを示せば採用につながった。約1年半で1,000人が受験し、現在のパフォーマンスエンジニアリングチームの大半を採用する基盤となった。
2025年5月、状況が変わり始めた。Claude 3.7 Sonnetは、すでに人間の候補者の50%以上を上回るスコアを出せるようになっていた。さらに、リリース前のClaude Opus 4は、4時間制限内においてほぼ全人間のスコアを上回る最適解を導き出した。
対策として、Tristanはテストをバージョン2（v2）に再設計した。Claude Opus 4自身を使って「どこで躓くか」を特定し、そこを新たな出発点とした。初期コードをクリーンアップし、マルチコア要素を削除（Claudeがすでに解決済みであり、開発サイクルを遅くするだけだったため）、より深い最適化の余地を残した。制限時間も4時間から2時間に短縮し、デバッグよりも洞察に重きを置く構成になった。v2は数ヶ月間、良好に機能した。
しかし、次の波が来た。リリース前のClaude Opus 4.5をテストしたところ、Claude Code上で2時間かけて少しずつ改善を続け、1時間以内に合格ラインをクリアした。
興味深いのは、Claude Opus 4.5も人間と同様に「メモリ帯域のボトルネック」で一旦停止した点だ。ほとんどの人間はここが限界だと結づけるが、実際には問題構造を利用した巧妙な回避策が存在する。Tristanが「このサイクル数まで到達可能だ」と伝えたところ、Claude Opus 4.5はしばらく考えた後にそのトリックを発見し、さらに最適化を進めた。2時間後のスコアは、同じ時間制限での人間のベスト記録に並んだ——しかも、その人間はClaude 4を活用していた。
採用試験において最善の戦略が「Claude Codeに丸投げすること」になる事態は、評価として致命的だった。
Tristanはまず、自身がAnthropicで経験した難易度の高いカーネル最適化——2次元TPUレジスタ上での効率的なデータ転置とバンクコンフリクトの回避——をベースにした新問題を設計した。Claude Opus 4.5の助けを借りて1日で実装を終えた。
しかしClaude Opus 4.5は、Tristanすら思いつかなかった最適化を発見した。データを転置するのではなく「計算全体を転置する」という発想だ。問題を修正してこのアプローチを封じた後も、Claudeは進展を見せた。さらに長い思考時間を与える「ultrathink」機能でテストした結果、バンクコンフリクト解決のトリックも含めて完全に攻略された。
振り返れば、この問題の選択自体が誤りだったと考えられる。データ転置やバンクコンフリクトは多くのプラットフォームでエンジニアが苦闘してきた領域であり、Claudeの学習データに豊富に含まれていたのだ。
次にTristanが着想を得たのは、Zachtronicsゲームだった。このプログラミングパズルゲームは、極めて制約の強い奇妙な命令セットを使ってコードを書くことを強いられる。例えば『Shenzhen I/O』では、プログラムは複数の通信チップに分割され、各チップはわずか10命令程度しか格納できず、状態レジスタも1〜2個しかない。巧妙な最適化には、命令ポインタやブランチフラグに状態をエンコードするような発想の転換が必要になる。
Tristanは、こうした「極めて制約の強い小さな命令セット」によるパズルを複数設計し、命令数の最小化を競う形式のテストを作成した。Claude Opus 4.5はこのパズルに敗北した。
成功の鍵は「分布外」の問題であることだった。現実の仕事に似ている問題はAIの経験域に近く、強い。しかし、斬新で奇妙な問題はAIの経験域の外にあり、人間が有利になる。
AnthropicはオリジナルのテイクホームテストをGitHubで公開しており、AIと人間のスコア（シミュレートされたマシンのクロックサイクル数、低いほど良い）を直接比較できる。
人間のベストスコア（無制限時間）は、これら全てを上回る。AIの研究機関であるMetrの研究でも、十分な時間が与えられれば人間の専門家が現在のモデルを凌駕することが示されている。ただし、2時間という制限内では、その優位性を発揮する余裕がない。
Tristanはこの経験から、技術評価の設計原则が根本的に変化したと指摘する。
従来、面接設計の常識は「実際の仕事に似た問題を出す」だった。しかし「現実的」な課題は、おそらくAIの学習データにも近い。データ転置やバンクコンフリクトのような、多くのエンジニアが取り組んできた領域では、AIが人間を上回る経験ベースを活用できる。
一方で、「変な」課題——誰も見たことのない制約条件や、既存のパラダイムに当てはまらない問題——は、AIの経験域の外にある。ここでは人間の初見での推論力が有利に働く。
評価の本質が「知識の深さ」から「分布外推論の力」へとシフトしたと言えるかもしれない。また、TristanはAIの利用を禁止する選択肢をとらなかった。実際の仕事でもAIを使うのであり、AIと共存しつつ人間のスキルを識別できる評価を目指した姿勢は注目に値する。
「現実味がある」という前提は、今や評価設計においてはluxury（贅沢）な条件になりつつあるのかもしれない。Tristan自身、「リアリズムはもう贅沢なのかもしれない。オリジナルのテストは実際の仕事に似ていたから機能した。新しいテストは斬新な仕事をシミュレートするから機能する」と述懐している。
AIの能力向上は、面接設計者にとって永遠の課題となった。「今日通用するテストが明日も通用する」という前提はもはや成立しない。Anthropicのケースでは、モデルの進化ごとに評価の再設計を迫られ、最終的にはパズルゲームからの着想に頼ることになった。
それでも、人間には「初見の問題を創造的に解く」力がまだある。制約が奇妙であればあるほど、既存の知識に頼れない分、人間の発想力が輝く。Metrの研究が示すように、十分な時間が与えられれば人間の専門家はAIを凌駕できる。
Anthropicは新しいテストのAI耐性について「あとどれくらい持つか、好奇心がある」と結んでいる。読者への問いかけも明確だ——あなたの面接問題は、AI耐性がありますか？