+++
title = "LLMエンジニアの採用実技テスト — 何を出して、どう採点するか"
date = 2026-06-08
description = "「LLMが使える」ことをどう測るか。実際に使っているテスト設計と採点基準を公開する"
[taxonomies]
tags = ["エンジニア採用", "LLM", "採用実務", "技術評価", "AI×HR"]
[extra]
public = true
belief_version = 1
ai_written = true
one_true_sentence = "LLMを「使える」エンジニアと「使いこなせる」エンジニアの差は、プロンプトの量でなくプロンプトの設計意図にある。"

[[extra.faqs]]
question = "LLMエンジニアの採用実技テストで何を測るべきですか？"
answer = "「プロンプト設計の構造的思考」「出力の批判的評価」「ハルシネーションへの対処」の3点です。コーディング速度や知識量ではなく「LLMと人間の協働の質」を測ります。採用担当者向けの職務経歴書評価プロンプト設計・LLM出力の問題点指摘・書類選考ワークフロー設計の3問構成が実用的です。"

[[extra.faqs]]
question = "LLMテストのバイアス感度はどう評価すればいいですか？"
answer = "学歴・年齢のバイアスが含まれたLLM出力サンプルを見せて、問題点を指摘させてください。「東京大学卒業というトップレベルの学歴を持ち」「若手にしては豊富な経験」という出力に対し、法的・倫理的問題に気づいて建設的な改善案を出せるかを確認します。批判のための批判でなく採用判断の質を上げる批判ができるかが評価基準です。"

[[extra.faqs]]
question = "LLMのハルシネーション対策をテストで確認するにはどうすればいいですか？"
answer = "「LLMを使った書類選考ワークフローを設計してください。ハルシネーションのリスクを最小化することを前提として」という課題が効果的です。高評価の回答は「LLMがキーワード抽出→人間確認→確認済みキーワードでLLMが評価→原文引用付きコメント→人間が最終判断」というように人間確認のゲートを複数設計しています。"

[[extra.faqs]]
question = "LLM採用テスト後のフォローアップ面接で何を確認すべきですか？"
answer = "テスト提出後に「なぜその設計にしたか」「もし実装するなら何から始めるか」「過去に似た問題に取り組んだことがあるか」を口頭で確認してください。テスト結果が良くても口頭で説明できない場合は要注意です。ツールの出力をそのまま提出している可能性があります。"

+++

「LLMを扱えるエンジニアを採りたい」という相談が増えた。と同時に、「どう評価すればいいか分からない」という悩みもセットで来る。コーディングテストは整備されているが、LLM活用能力のテストはまだ手探りの企業が多い。

実際に使っているテスト設計と採点の考え方を整理する。

---

## そもそも何を測りたいのか

LLM採用テストで測るべきは3つ:

1. **プロンプト設計の構造的思考** — 曖昧な要件を適切に分解してLLMに渡せるか
2. **出力の批判的評価** — LLMの出力を鵜呑みにせず、問題点を見抜けるか
3. **ハルシネーションへの対処** — 誤りを検出し、適切に検証するワークフローを持っているか

コーディング速度や知識量ではない。それはGitHubや既存のコーディングテストで測れる。LLMテストで見るのは「LLMと人間の協働の質」だ。

---

## テスト設計 — 3問構成

### 問1: プロンプト設計（制限時間20分）

**課題**: 以下の要件から採用担当者向けの職務経歴書評価プロンプトを設計してください。

```
要件:
- 評価対象: バックエンドエンジニア（5年以上）
- 評価軸: 技術力・チームへの貢献・学習意欲
- 出力: 100字以内のサマリー + 推薦/見送り判断
- 注意: 年齢・性別・学歴は評価に含めない
```

**採点のポイント**:
- ペルソナ（評価者の役割）の明示があるか
- バイアス排除の指示が具体的か（「含めない」だけでなく「言及しない」まで）
- 出力フォーマットを制約しているか
- Few-shot例を入れているか（入れていなければ理由があるか）

**高評価の例**: プロンプトに「もし情報が不足している場合は判断を保留し、追加すべき情報を指摘してください」のような不確実性処理が入っている

**低評価の例**: 「職務経歴書を評価してください」という1文。試みているが設計意図が読めない。

---

### 問2: 出力批判（制限時間15分）

**課題**: 以下のLLM出力を評価し、問題点を指摘してください。

```
[候補者プロフィール]
田中健太、35歳、東京大学工学部卒、ベンチャーA社でバックエンド6年

[LLM出力]
この候補者は東京大学工学部卒業というトップレベルの学歴を持ち、
6年間の実務経験があります。推薦度: ★★★★☆

特に注目すべきは、若手にしては豊富な経験です。ベンチャーでの
経験はスタートアップ環境への適応力を示しています。
```

**採点のポイント**:
- 学歴バイアスの指摘ができるか（「東京大学」を肯定的評価に使っている）
- 年齢バイアスの指摘ができるか（「若手にしては」）
- 評価根拠の欠如を指摘できるか（なぜ★4なのかが不明）
- 追加で必要な情報を提示できるか（技術スタック、具体的実績など）

**注意**: この問は「批判のための批判」でなく、「採用判断の質を上げる批判」ができるかを見る。建設的な改善案も評価する。

---

### 問3: ワークフロー設計（制限時間25分）

**課題**: LLMを使った書類選考ワークフローを設計してください。ただし、LLMがハルシネーション（事実誤認・でっち上げ）を起こした場合のリスクを最小化することを前提としてください。

**採点のポイント**:
- ハルシネーション発生箇所の特定（どのステップでリスクが高いか）
- 人間が確認するゲートの設計
- 出力のグラウンディング（入力情報に基づいた評価になっているか検証する仕組み）
- フィードバックループ（誤評価が起きた場合の修正プロセス）

**高評価の例**:
```
Step1: LLMが職務経歴書からキーワードを抽出（事実の列挙のみ）
Step2: 人間が抽出結果を確認・修正（5分）
Step3: 確認済みキーワードを元にLLMが評価コメント生成
Step4: 評価コメントに原文への引用を付与（根拠の可視化）
Step5: 人間が最終判断
```

---

## 採点表

| 評価項目 | 配点 | 基準 |
|---|---|---|
| プロンプト構造 | 30 | ペルソナ・制約・出力形式の三要素が揃っているか |
| バイアス感度 | 25 | 問2で法的・倫理的問題に気づいているか |
| リスク設計 | 25 | 問3でハルシネーションを単なるバグでなくシステム設計問題として扱えているか |
| コミュニケーション | 20 | 説明の明瞭さ、提案の実装可能性 |

---

## テスト後のフォローアップ面接

テスト提出後、必ず口頭で設計の意図を聞く。

確認すること:
- なぜその設計にしたか（理由の説明ができるか）
- もし実装するなら何から始めるか
- 過去に似た問題に取り組んだことがあるか

**重要**: テスト結果が良くても、口頭で説明できない場合は要注意。ツールの出力をそのまま提出している可能性がある。

---

## 採用レベルの基準

- **75点以上**: 即戦力。LLMを道具として適切に使える
- **55〜74点**: ポテンシャル採用。伸びしろが大きい
- **54点以下**: LLM活用よりも基礎技術力の評価を先にすべき

---

## よくある誤解

**「プロンプトエンジニアリングは誰でも学べる」**  
確かに学べる。ただし、問題分解・リスク設計・批判的思考は短期では身につかない。これらを持っているエンジニアがLLMを使うと劇的に強くなる。

**「ChatGPTを使えればいい」**  
ツールの知識より設計思想を見る。GPT-4でもGeminiでもClaudeでも、設計思想が正しければ成果が出る。

---

*このテスト設計について意見や改善案があれば kenny@atsume.io へ。エンジニア採用の相談も受けている。*

---

## 関連記事

- [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — 採用後に活かすために実技テストで見るべきポイント
- [AI採用スクリーニングと人間判断の境界線](/n/ai-screening-human-judgment-line/) — 実技テストとAIスクリーニングの適切な組み合わせ
- [プロンプトエンジニアリングの面接で実際に出すべき課題](/n/ai-hiring-culture-fit-limits/) — 面接当日のライブ課題設計との使い分け方