AIと組めば動くものは誰でも作れる時代に、テイクホームで測るべきはコードではなく、その人が残した判断の跡だ。

AIエンジニア採用でテイクホームアサインメントをどう設計するか

思考版1 AI執筆

「動くものを作ってください」と課題を出したら、応募者が全員ほぼ満点を取ってきた——。喜ぶ前に気づいてほしい。それは候補者ではなく、候補者の隣にいるAIを採点しているだけかもしれない。

エンジニアがAIと組んで仕事をするのが当たり前になった今、「動くコードを提出させる」設計はもう、何も見分けられない。

従来の設計が機能しなくなった理由

昔のテイクホームは「技術力があれば解けるが、雑なやり方では動かない」コードを前提にできた。

今は違う。優秀なAIという相棒が、候補者全員の隣に座っている。正しく対話すれば、動くコードはまず出てくる。

だから「このAPIで音声認識システムを作ってください」と出しても、差がつくのは出力されたコードではない。AIと並走しながら、その人がどこで立ち止まり、何を選び、何を捨てたか。個性はそこにしか残らない。コードが動いていることと、その人がコードを理解していることは、もう別の話だ。

「判断の跡」を確認する設計

有効なテイクホームアサインメントは「判断を記録させる」構成にする。

具体例： 「この仕様に対してシステムを作ってください。合わせて以下を提出してください：

  1. 作る前に検討した選択肢（3つ以上）とそれぞれの長所・短所
  2. 最終的に選んだ理由
  3. 実装後に「もっと早く知りたかった」と思ったこと」

コードではなく「なぜそのアプローチを選んだか」を見る。顧問先の採用で何度も見たのは、コードは完璧なのに「なぜこうしたか」が一行も書けない提出物だ。AIが書けるのはコードまで。判断の跡は本人にしか書けない。ここが評価の分水嶺になる。

AIエンジニア採用に特化した課題の設計

プロンプトエンジニアリングを確認する場合

「このユーザーフィードバック100件を分類して要約するプロンプトを設計してください。プロンプトの変遷も記録してください」

確認するのは、最初に試したプロンプトと、どう改善したかのプロセスだ。

RAG設計を確認する場合

「100ページのPDFから特定の情報を正確に抽出するシステムの設計書を書いてください（実装不要）。精度とコストのトレードオフについて考慮した内容を含めること」

設計書は実装より判断が見えやすい。

LLMコストの最適化を確認する場合

「同じタスクを処理するコードを、コスト優先と精度優先の2パターンで設計してください。それぞれの想定コストと精度の見積もりを付けてください」

設計で避けるべきパターン

避けるべき1：時間をかければ誰でも解けるもの

「完璧な解答を作る能力」ではなく「限られた時間でどう判断するか」を見る。提出期間は2-3日が適切だ。

避けるべき2：採用候補者の本番業務に使えるもの

実際の業務課題に近いテイクホームアサインメントは、無料の労働力になる。候補者もそれを察して「使われると思うとやる気が出ない」という感想になる。

避けるべき3：評価基準が曖昧なもの

採用チームが「良い提出物」について事前に合意していない課題は、評価時に「なんとなく好き/嫌い」で判断になる。評価基準を先に書いてから課題を設計する。

月曜からできること

新しい課題を一から作る必要はない。今ある課題文の末尾に、この3行を足すだけでいい。

提出時に以下も書いてください。

  1. 着手前に検討した選択肢を3つ以上、それぞれの長所・短所つきで
  2. 最終的にそれを選んだ理由
  3. やってみて「もっと早く知りたかった」と思ったこと

そして評価する側は、コードを開く前にこの3つを先に読む。順番が逆になった瞬間、また出力の見た目に引きずられる。手を動かすのは候補者だが、判断を読み取るのは採用側の仕事だ。設計を渡せば、評価は勝手に深くなる。

関連記事