+++
title = "AIエンジニア採用でテイクホームアサインメントをどう設計するか"
date = 2026-06-08
description = "AI系企業がエンジニア採用のテイクホームアサインメントを設計する時の考え方と避けるべきパターン"
[taxonomies]
tags = ["HR×AI", "テイクホームアサインメント", "エンジニア採用", "採用設計", "AI採用"]
[extra]
public = true
belief_version = 1
ai_written = true
one_true_sentence = "AIと組めば動くものは誰でも作れる時代に、テイクホームで測るべきはコードではなく、その人が残した判断の跡だ。"

[[extra.faqs]]
question = "AIエンジニアのテイクホームアサインメントで「判断の跡」を記録させる方法を教えてください。"
answer = "提出物に「作る前に検討した選択肢3つ以上とそれぞれの長所・短所」「最終的に選んだ理由」「実装後にもっと早く知りたかったこと」の3点を必須にします。コードはLLMに生成させることができても「なぜそのアプローチを選んだか」の記録は自分でないと書けません。判断の質を見ることで、コードの生成方法に依存しない評価ができます。"

[[extra.faqs]]
question = "AIエンジニアのテイクホームアサインメントの適切な期間はどのくらいですか？"
answer = "2〜3日が適切です。時間をかければ誰でも解けるものではなく、限られた時間でどう判断するかを見るのが目的です。長すぎると「完璧な解答を作る能力」の測定になり、実務での判断速度が見えにくくなります。また採用候補者の本番業務に使えるような課題は無料の労働力になるため避け、実際の業務課題に近すぎない架空の設定を使うことを推奨します。"

[[extra.faqs]]
question = "RAG設計の能力をテイクホームアサインメントで確認するにはどうすればよいですか？"
answer = "「100ページのPDFから特定の情報を正確に抽出するシステムの設計書を書いてください（実装不要）。精度とコストのトレードオフについて考慮した内容を含めること」が有効です。設計書は実装より判断が見えやすく、ベクターDB選定・チャンク分割・検索精度の考え方が読み取れます。実装を求めると「LLMが生成したコード」の提出になりやすいため、設計書の方が評価精度が高いです。"

[[extra.faqs]]
question = "テイクホームアサインメントの評価基準はどう決めればよいですか？"
answer = "採用チームが「良い提出物」について事前に合意してから課題を設計することが重要です。評価基準なしに課題を設計すると「なんとなく好き/嫌い」で判断になります。具体的には「選択肢の検討が3つ以上あるか」「コスト・精度のトレードオフが明示されているか」「アプローチ変更の理由が説明されているか」のような採点基準を先に書いてから課題文を作ることを推奨します。"
+++

「動くものを作ってください」と課題を出したら、応募者が全員ほぼ満点を取ってきた——。喜ぶ前に気づいてほしい。それは候補者ではなく、候補者の隣にいる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つを先に読む。順番が逆になった瞬間、また出力の見た目に引きずられる。手を動かすのは候補者だが、判断を読み取るのは採用側の仕事だ。設計を渡せば、評価は勝手に深くなる。

---

## 関連記事

- [AIエンジニアのリモート面接設計：何が見えて何が見えないか](/n/ai-engineer-takehome-assignment/) — テイクホームアサインメントと組み合わせるリモート面接の設計
- [AIエンジニアにコーディングテストを出す前に確認すること](/n/ai-engineer-coding-test-before-checklist/) — コーディングテストとテイクホームの使い分け
- [AI時代にエンジニアの評価軸が変わった具体的な3つのポイント](/n/ai-era-engineer-evaluation-shift/) — テイクホームで何を測定すべきかの評価軸の変化