+++
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に解かせて30秒で満点が返ってくるコーディングテストが測っているのは、候補者の実力ではなくAIの性能だ。"

[[extra.faqs]]
question = "AIエンジニア採用でコーディングテストは今でも有効ですか？"
answer = "設計次第では有効です。「動くコードを書けるか」を測定するテストはAIツールで解けてしまうため機能しませんが、「問題をどう分解するか」「AIの出力を評価できるか」「反復して改善できるか」を測定する設計なら有効です。テスト問題をAIツールに解かせて高品質な答えが30秒で出るなら、テスト設計の見直しが必要です。"

[[extra.faqs]]
question = "AIを使っていいコーディングテストはどう設計すればよいですか？"
answer = "3つのポイントがあります。①問題にコンテキストを入れる（実際のコードベースへの統合など、AIが単純に解けない状況を作る）。②プロセスを提出させる（完成コードだけでなく手順・詰まった点・アプローチ選択の理由を書かせる）。③制限時間を短くする（完璧なコードより優先順位の付け方を見る）。AIを相棒に走らせながら判断能力を評価できる設計が実務に近く有効です。"

[[extra.faqs]]
question = "コーディングテストを廃止した場合の代替評価方法は何ですか？"
answer = "ポートフォリオレビュー（GitHubリポジトリや実際に動くプロダクト）と面接での深掘りの組み合わせが代替として機能します。また「実際に一緒に仕事をしてみる」有償の短期タスクを導入する企業も増えています。コーディングテストは候補者の時間コストが高く、人気候補者の辞退率が上がる副作用もあるため、廃止によって採用競争力が上がるケースがあります。"

[[extra.faqs]]
question = "AIエンジニアにコーディングテストを出す前に採用担当者が試すべきことは何ですか？"
answer = "そのテスト問題をClaude Code・GitHub Copilot・ChatGPTなどのAIツールに解かせてみることです。AIが高品質なコードを30秒で出力できる問題なら、そのテストで測定できるのは「AIをパートナーにしてテストをパスする能力」です。これが測定したいことなら問題ありませんが、そうでなければテスト設計を変える必要があります。採用担当者自身がAIと組んでみる経験が、評価設計の改善につながります。"
+++

そのコーディングテスト、出す前にあなた自身がAIに解かせましたか。

30秒で満点の答えが返ってきたなら、あなたが測っているのは候補者の実力ではなく、AIの性能です。

---

## まず、月曜の朝にこれをやる

出題予定の問題をそのままClaude CodeやCopilotに貼って、解かせる。出力を5分だけ読む。

判定はシンプルだ。**AIが30秒で満点を出したら、その問題は差し替える。** これだけで「測れていないテスト」を採用フローから1問減らせる。

顧問として採用設計を横で見ていると、ここを飛ばしたまま去年の問題を使い回している現場が多い。出題者が一度も自分で解いていないテストは、たいてい候補者ではなくAIを測っている。

---

## AIがいる時代、テストで測れなくなったこと

**「動くコードを書けるか」**：AIを相棒にすれば多くの問題は解ける。LeetCode形式のアルゴリズム問題も、単純な機能実装も、高い確率で正解が出る。

**「特定のデザインパターンを知っているか」**：AIに聞けば分かる知識は、テスト問題として機能しない。

知識量と実装速度は、もう差がつかない指標になった。

---

## では何を測るか——AIと「組める」人か

測りたいのは、AIを操れるかではない。AIを相棒として迎え、その仕事を評価し、一緒に直していけるかだ。

**問題をどう分解するか**：AIに渡す指示を書く力は、漠然とした要件を「何をどの順番で解くか」に構造化する力と直結する。ここはまだ人間が握っている。

**AIの出力を評価できるか**：返ってきたコードの危うさを指摘できるか。バグを見つけ、「なぜここで壊れるか」を自分の言葉で説明できるか。

**反復して改善できるか**：最初の出力から、要件に合わせて何往復で仕上げられるか。この往復のプロセスを追えるテストなら、AIを走らせたまま判断力を評価できる。

---

## AIを使わせる前提で設計する

禁止して人間だけで解かせるより、AIと組ませた状態で出す方が、実際の業務にずっと近い。

- **問題にコンテキストを入れる**：「この既存コードベースに、このAPIを統合してください」。AIが文脈ごと飲み込めない状況を作ると、単純な一発解答が効かなくなる。
- **プロセスを提出させる**：完成コードだけでなく「どんな手順で、どこで詰まり、なぜこのアプローチを選んだか」を書かせる。
- **制限時間を短くする**：「完璧なコード」より「短時間でどこまで作り、何を後回しにしたか」を見る。優先順位の付け方に人柄が出る。

---

## 廃止して、隣で一度組んでみる

テスト自体を畳む選択もある。代わりにポートフォリオレビュー（GitHubや実際に動くプロダクト）と面接の深掘りに切り替えた現場がある。

コーディングテストは候補者にとっても重い。選考の終盤で長時間のテストを課すと辞退率が上がり、引く手あまたの候補者ほど他社を優先する。

いちばん実態に近いのは、有償の短期タスクで「一度、隣で一緒に手を動かしてみる」こと。評価のために飛ばせて見るより、横に座って渡し合う方が、その人の仕事が見える。

---

## 関連記事

- [AIエンジニア採用でテイクホームアサインメントをどう設計するか](/n/ai-engineer-takehome-assignment/) — コーディングテストの代替として機能するアサインメント設計
- [AI時代にエンジニアの評価軸が変わった具体的な3つのポイント](/n/ai-era-engineer-evaluation-shift/) — 知識量から抽象化・設計力への評価シフトの詳細
- [Claude CodeをHRや採用データ分析に使う方法](/n/claude-code-build-hr-tool-from-scratch/) — AI採用プロセスにAIツールを活用する方法