はじめに
エンジニア採用に関わる人が知っておくべき不都合な事実がある。
Anthropicの公式Engineering Blogによると、Claude Opus 4.5は2026年初頭の時点で、多くの企業のテイクホーム技術課題を「最高レベルの人間候補者と同等」の品質で2時間以内に解いてしまうことが明らかになった。候補者がAIを使って課題を解いてくる時代は、すでに来ている。
「コードが書けるか」を評価の中心に置いた従来の採用プロセスのままでは、AIを上手に使う凡庸なエンジニアを優秀と誤認し、本当に採りたい人材を取り逃すリスクがある。levtechの調査によると、採用担当者の約40%がエンジニアに求めるスキルが変化したと回答しているという報告もある。
この記事は、採用業務の効率化という話と、採用評価基準そのものの再設計という二つの軸で構成する。両方とも今すぐ動けることだ。
まず「採用業務」を効率化する
採用における地味な時間泥棒の筆頭は、JD（職務記述書）の作成だ。毎回ゼロから書いているチームは少なくなく、似たようなポジションでも数時間かかることがある。
Claude Codeへのプロンプトはこう書ける。
以下の情報でシニアバックエンドエンジニアのJDを作成して。
- チーム規模: 8名、マイクロサービスアーキテクチャ - スタック: Go / PostgreSQL / Kubernetes - 求めるレベル: 設計判断ができる、メンタリング経験あり - 魅力ポイント: フルリモート、技術的意思決定に裁量あり
AIと協働できる能力を要件に含めて。候補者が自分事化できる言葉で書いて。
herohunt.aiのレポートでは、こうしたアプローチでJDを改善した後に応募者が25%増加した事例が報告されている。
書類スクリーニングの段階でも、候補者のGitHubリポジトリや技術ブログをClaude Codeに分析させると、面接前の技術調査にかかる時間が劇的に変わる。hiretruffle.comやherohunt.aiの報告では、技術候補者の事前調査が20時間から30分に短縮されたケースや、書類スクリーニング時間が50〜70%削減されたケースが示されている。
この候補者のGitHubを分析して。
使用技術スタック、コードの品質、貢献パターン（実装重視かドキュメント重視か等）、 最近のコミット傾向を採用判断に使える形式でまとめて。
複数の候補者を同じ目線で比較するルーブリックをClaudeに生成させ、チーム全員が共通の評価基準でスクリーニングできる仕組みを作ることもできる。「なんとなく良さそう」という属人的な判断が構造化されるのは、採用チームの意思決定品質を上げる。
ただし、これらの効率化はあくまで「準備」の話だ。本当に重要なのは次の問いだ。
「AIが解けてしまう技術課題」問題と、その対処法
Anthropicは自社の採用プロセスで直接この問題に直面した。Claude Opus 4.5が従来のテイクホーム試験を最高レベルの人間候補者と同等の品質で解いてしまった。「コードを書かせてみる」系の評価は、差別化の機能を失いつつある。
Anthropicの公式Engineering Blog（Designing AI resistant technical evaluations）では、AI耐性のある評価設計として3つの原則が示されている。
問題の深さと複雑性の拡大: 候補者がAIの出力をそのまま提出できない、理解して超える必要がある課題にすること。単純な実装ではなく、複雑な設計判断を要する問題だ。
分布外の問題設計: AIの訓練データに含まれない、非典型的・制約の強い問題を使う。よくあるパターンを外すことで、暗記やコピーアンドペーストが通用しなくなる。
ツール構築能力の評価: デバッグツールを用意せず、限られた時間をどう投資判断するかを見る。環境整備の判断そのものを評価対象にする。
そして最も重要な方向転換が「AI利用を禁止する」のではなく「AIを使いながら問題を解かせ、その過程でどう考えるかを評価する」への移行だ。AIを禁止したところで実際の使用を確認できないし、禁止自体がAIを日常的に使いこなす人材の採用から遠ざかることになる。
会話ログで「AIとの協働能力」を評価する
この方向転換を実践として体現しているのが、Claude Codeの開発者であるBoris Chernyが実践している採用手法だ。候補者に技術課題を与え、コードだけでなくClaude Codeとの会話ログも提出させる。
評価するのは、会話の流れを把握しているか（後から振り返れるか）、脱線したAIを適切に軌道修正できるか、Plan modeを使って計画的にアプローチしているか——要するに「Claudeをどう使うか」ではなく「Claudeと共にどう考えるか」だ。
この採用パラダイムを象徴する事例として、Daisyというエンジニアの話がある。異動希望で採用されたDaisyが最初に出したPRは、新機能の直接実装ではなかった。「Claude Code自身が任意のツールを動作確認できる汎用テストツール」をまず作り、そのテストツールで新機能を実装させた。「自分でコードを書く」ではなく「Claudeがより良く動ける環境をまずClaudeに作らせる」という発想が採用の決め手になった。
会話ログに加えて、複数の面接官の評価データをClaude Codeで統合する実践も有効だ。SubstackライターのElse van der Bergは50件の面接記録をClaude Codeで分析し、構造化CSVを生成してHTMLダッシュボードで可視化した。複数の面接官の評価の合意・不一致を即座に確認できる仕組みだ。成功の鍵として本人が強調しているのは「全面接で同じ評価フォーマットを事前統一すること」だった。個別の評価メモがバラバラな形式だと、統合しても比較できない。
EMが今すぐできる3つのアクション
採用基準の再定義: 今使っている技術課題がAIで解けるかどうか、一度自分で試してみることをすすめる。Claude Opus 4.5に課題を渡して、どのレベルまで解けるかを確認する。「これはAIでも解ける」と気づいた瞬間に、何を評価すべきかの議論が始まる。「AIと協働しながらどう考えるか」を採用基準に加えることが急務だ。
課題提出方法の変更: 技術課題の提出形式に「Claude Codeとのやり取りのログも含める」を追加するだけで、AI時代の評価が今日から始まる。大がかりなプロセス変更は不要だ。ログを見ると、候補者がどこで詰まり、どう軌道修正したかが分かる。コードの完成度だけでは見えない「思考の質」が見えてくる。
スクリーニング効率化で浮いた時間の再投資: 書類スクリーニングや技術調査の時間が減ることで生まれた時間を、候補者との深い対話に使ってほしい。効率化の目的は作業量削減ではなく、EMが本来投資すべき場所への時間移動だ。
一点、注意として加えておく。候補者データをClaude Codeに渡す際は、自社のプライバシーポリシーとデータ取り扱い規定を確認すること。個人情報の扱いには慎重さが必要だ。AI生成の評価基準に既存のバイアスが含まれる可能性もあるため、最終判断は必ず人間が行う体制を崩さないようにしてほしい。
まとめ
「AIが技術課題を解けてしまう」という現実は、脅威でもあり採用の再設計チャンスでもある。
従来の「コードが書けるか」評価から「AIと共にどう考えるか」評価への移行は、一夜で変わることはない。ただ、一番簡単なのは、手元にある技術課題をClaudeに解かせてみることだ。5分で自社の評価基準の現実が分かる。次の採用サイクルに「会話ログも提出してください」を加えるだけなら10分もかからない。GitHubスクリーニングのプロンプトは一度作れば使い回せる。
小さな一歩から、AI時代の採用基準への移行が動き出す。
コメント