Anthropic採用試験はなぜ3度もClaudeに解かれたか

Anthropic採用試験はなぜClaudeに解かれ続けたか

Anthropicのパフォーマンスエンジニアリングチームは、2024年初頭から候補者選考にテイクホーム(持ち帰り)課題を使ってきました。仮想アクセラレータ上でコードを最適化する課題で、1,000人以上が挑戦し、数十人がここから採用されています。その中には、Trainiumクラスタの立ち上げを担い、Claude 3 Opus以降の全モデルの出荷に関わったエンジニアも含まれます。

ところが、新しいClaudeモデルが出るたびに、この課題は解かれてしまいました。同じ制限時間で走らせると、Claude Opus 4は大半の人間の応募者を上回る成績を出しました。それでも最上位の候補者とは区別できていましたが、続くClaude Opus 4.5はその最上位候補者にすら追いついてしまいます。人間が無制限の時間をかければまだ上回れるものの、テイクホームの制限時間内では、最も優秀な候補者の出力と最も優秀なモデルの出力を区別する手立てがなくなりました。

この記事は、Anthropicのパフォーマンス最適化チームを率いるTristan Hume氏が2026年1月に公開したエンジニアリングブログをもとに、課題がどう設計され、どう突破され、どう作り直されたかを追います。同社の採用の現場で実際に何が起きたかを示す、数少ない一次情報です。

最初のテイクホームはどう設計されたか

発端は2023年11月です。ClaudeのTPU/GPUクラスタが拡大する中でパフォーマンスエンジニアが不足し、Hume氏はX(旧Twitter)で協力を呼びかけました。想定を超える応募が集まり、通常の面接パイプラインでは選考しきれなくなったため、2週間かけてテイクホーム課題を設計しました。

課題の舞台は、TPUに似た特性を持つ仮想アクセラレータのPythonシミュレーターです。手動管理のスクラッチパッドメモリ、VLIW(複数の実行ユニットを1サイクルごとに並列動作させる方式)、SIMD(1命令で多要素を処理するベクトル演算)、マルチコア(複数の演算コアを同時稼働させる並列方式)という4つの並列化要素を備え、候補者はホットリロード対応のPerfettoトレースを見ながら最適化を進めます。課題そのものは並列木構造の走査で、深層学習に寄せない題材をあえて選びました。当時のパフォーマンスエンジニア候補の多くは深層学習の実務経験がなく、必要な知識は現場で学べば十分と判断したためです。

設計の狙いは4つありました。実務で起きる4時間規模の作業時間を確保すること。監視や実況を求めない現実的な環境にすること。システム理解とツール構築の両方に時間を割けるようにすること。そしてAI支援を明示的に許可することです。Anthropicが候補者向けに公開しているAI利用ガイドラインでは、テイクホーム課題は原則「ClaudeなどAIツールを使わずに完了する」ことを求め、AI利用を認める場合はその都度明示するとしています。このパフォーマンス最適化課題は、その「明示的に認める」側の例外です。長時間の課題はAIが完全解決しにくく、候補者は実務同様にAIを使いながら自分の実力を示せると考えたためです。

初期の結果は上々でした。1年半で約1,000人が挑戦し、現在のパフォーマンスエンジニアリングチームの大半をここから採用しました。特に、経歴上の実績が薄い候補者を見極める場面で効果を発揮し、学部卒業直後で入社した何人かの優秀なエンジニアは、この課題での成績が決め手になっています。制限時間の4時間を超えて没頭する候補者も多く、寄せられた最適化案の中には、Hume氏自身が想定していなかった工夫を含む本格的な最適化コンパイラもありました。

Claude Opus 4が最初の壁を崩した

2025年5月までに、Claude 3.7 Sonnetの実力はすでに、候補者の過半数がClaude Codeに丸投げした方が良い結果を出せる水準に達していました。Hume氏がプレリリース版のClaude Opus 4でこの課題を試したところ、4時間の制限内でほとんどの人間候補者を上回る最適化解を出しました。

対処自体は単純でした。課題には4時間で探り切れないほどの深さがあったため、Claude Opus 4がどこで行き詰まるかを特定し、そこを新バージョンの出発点にしました。スターターコードを整理し、深みを増す新しい機械特性を追加し、Claudeがすでに解いてしまっていたマルチコア要素は開発サイクルを遅らせるだけと判断して削除しました。制限時間も4時間から2時間に短縮しています。もともと4時間にしていたのは、候補者がバグで詰まるリスクを考慮したためでしたが、日程調整のオーバーヘッドが選考全体を数週間単位で遅らせていたため、週末に収まりやすい2時間へ切り詰めました。

作り直した2番目のバージョンは、デバッグやコード量よりも巧妙な最適化の着想を重視する設計です。この形で数か月にわたり、選考の実務に耐えました。

Claude Opus 4.5が2番目のバージョンも突破した

プレリリース版のClaude Opus 4.5でテストしたとき、Hume氏はClaude Codeが2時間かけて解を段階的に改善していく様子を見ていました。初期のボトルネックを解消し、一般的な微小最適化をひととおり実装し、1時間足らずで合格ラインに到達します。

そこでいったん止まり、メモリ帯域幅のボトルネックが乗り越えられないと判断しました。人間の候補者の多くも同じ結論に達します。しかし実際には、問題の構造を突いた抜け道が存在します。Hume氏が到達可能なサイクル数をClaudeに伝えると、しばらく考えた末にその抜け道を見つけ出し、デバッグとチューニングを重ねました。2時間経過時点でのスコアは、2時間制限内での最良の人間の成績と並びます。しかもその人間候補者は、Claude 4を積極的に使いこなしながら誘導していた人物でした。

社内のテスト時計算量ハーネス(test-time compute harness、モデルに割く計算時間を変えて性能を測る社内評価基盤)でも同じ結果が再現し、2時間で人間に並ぶだけでなく、時間をかけるほどスコアが伸び続けます。Hume氏は、このモデルをリリースすればテイクホームでの最適戦略が「Claude Codeに丸投げすること」になってしまう問題に直面しました。

AI利用を禁止せず、課題の中身を変える方向を選んだ理由

社内では、AI支援を禁止する案も出ました。Hume氏はこれを避けました。運用上の取り締まりが難しいことに加え、業務と同じようにAIが使える環境の中でも、人間が自分の力を示す方法を見つけられるはずだという考えがあったからです。「人間が優位に立てるのは数時間を超える長期タスクだけ」という前提には、まだ屈したくなかったといいます。

「Claude Codeの成果を大きく上回ることを合格基準にする」という案も検討されましたが、これも見送られました。人間は2時間のうち半分近くを課題の理解に費やすため、Claudeを操縦しようとする候補者は常に一歩遅れる展開になりがちです。その場合、支配的な戦略は「Claudeに任せて眺めているだけ」になりかねません。

パフォーマンスエンジニアの仕事の中身自体も変わってきました。いまの仕事は、難しいデバッグ、システム設計、性能分析、正しさの検証方法の考案、そしてClaudeが書いたコードをよりシンプルで洗練された形に整えることに近づいています。こうした要素は、長い時間や共通の文脈なしに客観的なテストへ落とし込みにくく、実務を反映した面接を設計する難易度はこれまで以上に上がっています。

2回の再設計で何を試し、何が失敗したか

1回目の試みは、別の最適化問題への切り替えでした。2次元TPUレジスタ上でのバンクコンフリクト(複数の演算が同じメモリバンクに同時アクセスして競合する現象)を避けながらデータを転置する、Hume氏が実務で扱った難所を単純化した課題です。Claudeに実装を手伝わせ、1日足らずで課題化できました。

ところがClaude Opus 4.5は、Hume氏が想定していなかった最適化を見つけます。データそのものを転置する代わりに、計算全体を転置し直すという発想でした。この抜け道を塞ぐよう課題を修正すると、Claudeは順調に進みつつも最も効率的な解には届きませんでした。ただし不安が残ったため、Claude Codeの「ultrathink」機能で思考予算を伸ばして再試行したところ、バンクコンフリクトを解消するコツも含めて解き切ってしまいました。振り返れば、データ転置とバンクコンフリクトは多くのプラットフォームのエンジニアが長年苦しんできた定番の難所で、Claudeが参照できる訓練データが豊富にある領域でした。Hume氏は原理から解を導きましたが、Claudeはより広い経験の蓄積から解に近づけたことになります。

2回目の試みは、人間の推論がClaudeの経験の広さに勝てるだけの、十分に分布外な問題を探すことでした。それでいて実務らしさも保ちたいという、相反する条件です。行き着いた先はZachtronics系のパズルゲームでした。極端に制約された命令セットで非定型のプログラミングを強いるジャンルで、たとえば『Shenzhen I/O』では、各チップが10命令程度とレジスタ1〜2個しか持てず、命令ポインタや分岐フラグに状態を埋め込むような工夫が求められます。

Hume氏はこの発想で、極小の制約された命令セットを使い、命令数の最小化を競わせる新しいテイクホームを設計しました。中程度の難度のパズルを1つ実装してClaude Opus 4.5に試したところ、失敗しました。同僚に検証を依頼したところ、この問題に深く関わっていない人でもClaudeを上回れました。デバッグツールや可視化機能はあえて用意していません。用意したのは解の妥当性を判定するチェッカーだけです。適切なprint文を挿入するか、コーディングモデルに数分でインタラクティブなデバッガを生成させるか、その判断自体がテストの一部になっています。

Hume氏は新しいテイクホームに一定の手応えを感じています。独立した小問題の集合になった分、分散は小さくなったかもしれません。初期の結果は候補者の実力と相関し、社内で最も優秀な同僚の1人が、これまでのどの候補者よりも高いスコアを出しました。一方で、元の課題が持っていた実務らしさと深みを手放したことには未練も残ると述べています。元の課題は実務に似ていたから機能し、新しい課題は未知の作業を模擬しているから機能する、という違いです。

公開されたオリジナル版は今どれだけ解かれているか

Anthropicは、最初のバージョンのテイクホームを無制限の時間で挑戦できる公開課題として提供しています。無制限の時間があれば、人間の最速記録はいまもClaudeの到達点を上回るという判断からです。公開版は最初のバージョンと同じくゼロから始める形式ですが、命令セットとシングルコア設計は2番目のバージョンのものを使っており、サイクル数は2番目のバージョンと比較可能になっています。

Anthropicが公開したベンチマーク(サイクル数が少ないほど高性能)は次のとおりです。

1,487サイクルを下回れば、ローンチ時点のClaudeの最良成績を超えたことになり、Anthropicはコードと履歴書を専用メールアドレスへ送るよう呼びかけています。通常の採用プロセスに応募することもでき、その場合は現行の「Claudeに強いテイクホーム」が使われます。公開課題自体は、AnthropicのGitHub組織(anthropics/original_performance_takehome)から入手できます。

Claude Codeを使う開発者にとってこの話が示すもの

この記事が興味深いのは、Anthropic自身の採用現場という、利害関係のない場所でClaudeの実力の伸びを定点観測できる点です。2024年から2026年にかけて、パフォーマンス最適化という具体的なタスクで、Claudeは「人間より弱い」「大半の候補者を上回る」「制限時間内なら最上位候補者と並ぶ」の3段階を、テイクホームの寿命が数か月単位まで短くなるペースで駆け抜けました。

もう1つの示唆は、Claudeが強い領域と弱い領域の境界線です。データ転置やバンクコンフリクト回避のような、多くのエンジニアが過去に取り組んできた定番の最適化パターンでは、Claudeは訓練データの蓄積を生かして人間顔負けの解にたどり着きました。一方で、Zachtronics系パズルのような、極端に制約された分布外の問題では歯が立たず、人間の第一原理からの推論に軍配が上がっています。Claude Codeへの委任をどこまで広げるかを判断する際、対象タスクが定番パターンの延長線上にあるか、それとも本当に前例のない問題かという見極めは、実務でも参考になる視点です。Claude Opus 4.5以降の現行モデルの仕様はClaude Opus 5の使い方にまとめています。

デバッグツールを自分で書くか、Claudeに生成させるかという判断も同様です。Hume氏はこの判断そのものを評価対象に据えました。ツールを内製するか委任するかの見極めは、Claude Codeを日常的に使う開発者にとっても、地味だが実力差が出る技能だと言えます。モデル間の性能・料金の違いはClaudeモデル一覧で比較できます。

AnthropicのCEOであるダリオ・アモデイ氏の意思決定を含む背景はダリオ・アモデイとはで扱っています。

まとめ

Anthropicのパフォーマンスエンジニア採用試験は、2024年初頭の設計から2026年1月の公開までに3度作り直され、そのたびにClaude Opus 4、Claude Opus 4.5に突破されてきました。現行版はZachtronics風の極小パズルという、あえて分布外に振った設計に落ち着いています。Hume氏自身、この設計がいつまで持つかは「興味がある」と述べるにとどめており、次の突破が来ることを織り込んだ書き方になっています。定番パターンの最適化ほどClaudeの経験が生き、前例のない制約下の推論ほど人間が優位に立つという構図は、採用試験に限らず、Claude Codeへの委任範囲を考えるときの目安になります。