+++
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エンジニアのテイクホームアサインメントで「動くものを作ること」を求めると、LLMに全部生成させたものが来る。確認すべきは判断の跡だ。"

[[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エンジニアのテイクホームアサインメントは、設計を間違えると意味がなくなる。

LLMを使って仕事をするエンジニアが増えた今、「動くコードを提出させる」だけでは何も確認できない。

---

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

以前のテイクホームアサインメントは「一定の技術力があれば解けるが、LLMに丸投げすると動かないコード」を前提に設計されていた。

今は「LLMに正しく指示すれば、動くコードが出てくる」のが前提だ。

「このAPIを使って音声認識システムを作ってください」という課題を出すと、LLMが生成したコードをそのまま提出する候補者が出てくる。そのコードが動いていても、候補者がそのコードを理解しているとは限らない。

---

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

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

**具体例**：
「この仕様に対してシステムを作ってください。合わせて以下を提出してください：
1. 作る前に検討した選択肢（3つ以上）とそれぞれの長所・短所
2. 最終的に選んだ理由
3. 実装後に「もっと早く知りたかった」と思ったこと」

コードではなく「なぜそのアプローチを選んだか」を見る。LLMにコードを生成させることはできても、「自分がなぜそのアプローチを選んだか」の記録は自分でないと書けない。

---

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

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

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

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

### RAG設計を確認する場合

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

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

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

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

---

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

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

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

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

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

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

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

---

## 関連記事

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