Anthropicの採用責任者がコーディング面接をやめた理由 ── AI時代のエンジニア評価は「書く力」から「成果を出す力」へ
AIがコードを書く時代に、エンジニアの評価軸は「コードを書けるか」から「AIを使って事業成果を出せるか」へ移った。2026年10月、Anthropic・Google・Amazonの3社がほぼ同時に、採用と評価の仕組みをこの方向へ切り替えている。
- Anthropic:エンジニアリング・マネージャーのFelix Rieseberg氏が、自チームの採用からコーディング面接を外した。Claudeのほうが候補者よりうまく解くため、選考の判断材料にならないという理由である。
- Google:ソフトウェアエンジニアの面接でGeminiの利用を認め、「AIフルエンシー(AIを使いこなす力)」を評価する試験運用を広げている。
- Amazon:ソフトウェア開発エンジニア(SDE)の役割ガイドラインを改訂し、AIの利用量ではなく顧客・事業への成果で評価すると明言した。
Anthropic:コーディング面接を廃止した理由
Rieseberg氏は、Claude.ai、Claude Cowork、Claude Codeのデスクトップ版のエンジニアリングを率いてきた人物である。10月27日にXで自チームのコーディング面接の終了を宣言し、同日にブログ記事「Hunger beats tenure: Advice for junior engineers(ハングリーさは勤続年数に勝る:若手エンジニアへの助言)」で理由を説明した。
判断材料にならなくなった理由
コーディング面接は、問題を素早く定義して筋のよい解法にたどり着く様子を見ることで、入社後の活躍を予測する手段だった。精度は高くないが、使える指標ではあった。
この指標をAIが無効にした。面接で出す程度の小さなコーディング課題は、Claudeが大半の候補者より上手に解く。課題を出しても、候補者について分かることがほとんど残らない。加えて、Rieseberg氏のチームで最も大きな成果を出している人は、こうしたテストの点数とは関係なく成果を出している。
面接の代わりに見ているもの
代替手法はまだ確立していない。現時点では、履歴書やポートフォリオに載った小さなプロトタイプを見て、次の3点を確認している。
- センス(taste):何を作るべきかの選び方
- 共感:使う人の困りごとを捉えているか
- 筋の通った考え方:判断の根拠が一貫しているか
Rieseberg氏は、コーディング面接は戻らないと見ている。ソフトウェアエンジニアリングの抽象度が一段上がった結果であり、一時的な流行ではないという位置づけである。
なお、この変更はRieseberg氏が採用するチームに限った話で、Anthropic全社の方針ではない。ほかのチームに応募する場合は、従来どおりコーディング面接を受ける可能性が高い。
若手エンジニアへの5つの助言
Rieseberg氏は、AIが若手の仕事を奪うという見方を否定する。実際に、AIを使いこなす経験の浅いエンジニアが、コーディングの腕前も在籍年数も上の先輩を追い抜く場面を見ているという。フレームワークやライブラリの知識の蓄積が、成果を左右しにくくなったためである。
また、氏は「ジュニア」という言葉を不適切だとしている。助言の対象は、年次ではなく、社内での人脈・地位・権限を持たないエンジニアである。
| # | 助言 | 内容 |
|---|---|---|
| 1 | 事業インパクトに焦点を当てる | 会社や所属組織が何を達成しようとしているかを把握する。上司の上司の目標まで理解するのが望ましい。エンジニアの報酬はコードではなく事業価値に対して払われている |
| 2 | 大胆なアイデアを1つ選ぶ | その目標の達成確率を大きく引き上げるアイデアを選ぶ |
| 3 | 週末でプロトタイプを作る | 要件定義書、合意形成の会議、デザイナーやPMの手が空くのを待つ行列を、動く試作で飛ばす |
| 4 | 良いアイデア1つに絞る | 強いアイデア3つを弱いアイデアに混ぜると、全部が埋もれる。経営層が「この案と、この人」と一度で理解できる形にする |
| 5 | 新参者の視点を使う | 製品は外部ユーザーと同じ目で見られる。インフラでは「なぜそれが無理とされているか」をまだ知らないことが武器になる |
核心は「実行のコストはもう高くない」という一点にある。かつては実績や信頼を積んでから提案が通る順番だったが、AIで試作のコストが下がった今は、地位を得る前に動くものを見せられる。
事例:Claude Codeのデスクトップ版
Claude Codeはコマンドラインツールとして知られていた。比較的新しく入った2人のエンジニアが、グラフィカルなインターフェースの試作を週末1回で作り、約8日後に最初の公開版がリリースされた。Claude Codeの使いやすいGUIは、その後よく使われる製品になっている。助言の3(週末の試作)と5(新参者の視点)がそのまま当てはまる例である。
Google:面接でAIを使わせ、使い方を評価する
Googleは2026年5月、ソフトウェアエンジニア面接の新形式の試験運用を始めた。対象は米国の一部チームのジュニア〜ミッドレベル職である。
- コード理解ラウンド:白紙から関数を書かせる代わりに、既存の複数ファイルのコードを読み、デバッグし、最適化させる
- AIの利用:会社が承認したAIアシスタント(Gemini)を使ってよい
- 評価項目:AIフルエンシー。具体的にはプロンプトの組み立て、AI出力の検証、デバッグの力
社内文書はこの形式を「人間主導、AI支援」と表現し、生成AI時代のエンジニアの実際の作業手順に近づけることを目的としている。
10月20日のBusiness Insiderの報道では、この形式が社内のより多くの部門に広がった。ソフトウェアエンジニア職ではAIフルエンシーが必須要件になり、エントリーレベル以外の多くの職種ではAIを製品に組み込む力も要件になっている。Metaも同様の面接を導入しており、こちらは複数のAIモデルから候補者が選べる。
Amazon:AIの利用量ではなく成果で測る
Amazonは10月27日、SDEの役割ガイドライン改訂に関する社内メモを公開した。9月に社内で共有されたもので、Worldwide Amazon StoresのVP兼Distinguished EngineerであるTerk Terkowitz氏が発信している。主旨は、重要なのは成果であり、どのツールを使ったかではない、という点にある。
「ルネサンス・デベロッパー」の定義
メモは現在を「ルネサンス・デベロッパー」の時代と呼ぶ。AIツールと人間の判断力、業務領域の専門知識を組み合わせて、新しいものを作る開発者を指す。最も生産性の高いエンジニアたちは、開発者の役割も成果もAIの利用で定義されるものではないことを示している、とメモは述べている。
利用量の指標を「深い欠陥がある」と認めた
- トークン使用量やAIツールの採用率(入力指標)、コード変更数やレビュー数(処理量指標)は、本当に重要なものとのつながりが弱く「深い欠陥がある」
- これらを目標にすると、コスト増と不要な複雑化を招く。トークンを使うこと自体が目的化する「トークンマキシング」は、Amazonのリーダーシップ原則の「倹約(Frugality)」と矛盾する
- 一方で、現時点ではこれらの指標と有用な成果の間に相関があるため、慎重に判断しながら使う
分布の両端を見る
| 見る位置 | 目的 |
|---|---|
| 10パーセンタイル(利用が少ない側) | AIを効果的に使えていないチームを見つけ、理由を把握する |
| 90パーセンタイル(利用が多い側) | 大量の利用が、それに見合う提供成果につながっているかを確認する |
「AIが効かない」は失敗ではなく発見
特定の作業でAIが役に立たない場合、それは「失敗ではなく発見」と位置づけられる。エンジニアは理由を記録し、同僚と共有し、上司に伝える。AIがどこで効かないかを説明できること自体が、Amazonの求める判断力の表れとされている。
そのうえで、メモはAIの学習と実務への適用をできるだけ早く始めるよう求めている。リーダーにも自らツールを触り、AIが役立った作業と役立たなかった作業を具体的に語れることを求めている。
3社に共通する評価軸の変化
| 企業 | 変更内容 | 測るもの | やめたもの |
|---|---|---|---|
| Anthropic(Rieseberg氏のチーム) | コーディング面接を廃止 | プロトタイプに表れるセンス・共感・考え方 | 小さなコーディング課題 |
| コード理解ラウンドでGeminiの利用を許可 | AIフルエンシー(指示・検証・デバッグ) | AIなしで白紙からコードを書かせること | |
| Amazon | SDEの役割ガイドラインを改訂 | 顧客・事業・チームへの長期的な成果 | AI利用量を目標として扱うこと |
3社の動きから、評価軸の変化は次の3点に整理できる。
- コードを書く作業は差別化要因でなくなった。小さな課題ならAIが人より速く正確に解く。
- 評価対象は「問いを立てる・検証する・判断する」に移った。Googleの「出力の検証」、Amazonの「判断力」、Rieseberg氏の「センス」は、いずれもAIの出力の手前と後ろにある人間の仕事を指している。
- 事業課題から逆算した試作が、個人の最大の武器になった。実行コストが下がったことで、在籍年数や社内の地位がなくても、動くもので提案を通せる。
エンジニアが今からやること
- 事業課題を1つ特定し、週末で動く試作を作る:所属組織の目標から逆算して、達成確率を大きく上げる1案に絞る
- AIの出力を検証する力を鍛える:既存コードを読む、バグを特定する、AIの提案の誤りを見抜く訓練を積む
- AIが効かない作業を記録する:どの作業でAIが役立たないかを具体的に説明できるようにする
- ポートフォリオに試作を残す:何を、誰のために、なぜ作ったかが伝わる形で公開する
留意点
Rieseberg氏の変更は1人の採用責任者の判断であり、代替手法もまだ確立していない。The Registerの報道によれば、コーディングテストは業界全体では依然として一般的で、ZipRecruiterの労働経済学者もテック企業はコーディングスキルを試験する可能性が最も高い業種の一つだとしている。注目を集めた理由は、AIコーディングツールを作っている当のチームが、この判断を下した点にある。
出典
- Anthropic Manager Retires the Coding Interview: “Hunger Beats Tenure”(PBX Science)
- Anthropic manager drops coding interviews because Claude is better at them(The Next Web)
- Anthropic hiring manager says he stopped giving coding interviews(TechRadar)
- Google Is Testing a New Rule That Could Transform Job Interviews(Entrepreneur)
- Google Tests AI Fluency in Engineering Interviews(Let’s Data Science)
- An update from Amazon engineering leadership on the role of the developer in the age of AI(About Amazon)
- Amazon to Engineers: Not Using AI Can Be ‘a Finding, Not a Failing’(Reworked)