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エンジニア採用でテイクホームアサインメントをどう設計するか — コーディングテストの代替として機能するアサインメント設計
• AI時代にエンジニアの評価軸が変わった具体的な3つのポイント — 知識量から抽象化・設計力への評価シフトの詳細
• Claude CodeをHRや採用データ分析に使う方法 — AI採用プロセスにAIツールを活用する方法