はじめに
最近、自社のエンジニア採用で、技術面接に関わらせてもらえることになった。
Flutterエンジニアとして現場で開発してきた自分が、初めて「選ぶ側」に回る。
そこで選考フローについて部長やチームリーダーと話していたとき、コーディングテストを前にして、こんな議論になった。
「これ、今も同じやり方で測る意味ある？」
候補者がChatGPTやClaudeを使えば、以前なら一定の実装力が必要だった課題でも、動くコード自体はかなり簡単に作れる。
では、AIを禁止すればいいのか。
でも、在宅のコーディングテストで本当に使っていないことを確認するのは難しい。
仮に見抜けたとしても、実務ではAIを使って開発するのに、選考のときだけAIを取り上げて「素のコーディング力」を測ることに、どれだけ意味があるのだろう。
考えていくうちに、問題はAIを使われることではないと思うようになった。
問題は、候補者がAIを使うことではない。
「AIを使えば多くの人が解ける問題」で、人を選別しようとしていることではないか。
そこで私は、AIを締め出す方向ではなく、むしろ逆に、
「AIを堂々と使ってもらい、その使い方まで含めて評価する面接にした方がいいのでは？」
と考えるようになった。
この記事では、次の3点について、一面接官として考えてみる。
- なぜ「AI製コードを見抜く」という方向を諦めたのか
- AI時代にエンジニア採用で何を測るべきだと思うか
- 私なら「AI利用OK面接」をどう設計するか
あくまで個人的な私案であり、会社として決まった方針ではない。
そしてタイトルの通り、弊社がすでにコーディングテストを廃止したわけでもない。
まだ「やめた」ではなく、「やめたい」と考えている段階の話だ。
「AI製か見抜けばいい」は、なぜ無理筋か
最初に考えたのは、多くの人が思いつくであろう対策だ。
つまり、
「AIが書いたコードかどうかを見抜く」
という方向。
結論から言うと、私はこれを早々に諦めた。
理由は3つある。
理由1：判別の根拠が、もう存在しない
少し前なら「AIっぽさ」はあった。
たとえば、
- 過剰に丁寧なコメント
- 教科書通りの命名
- 妙に汎用的なエラーハンドリング
といったものだ。
でも今のAIは、指示ひとつで文体もコメント量も自在に変えられる。
「コメントは最小限で、現場っぽく書いて」
と一言添えれば、それらしい人間味のあるコードが出てくる。
逆もある。
丁寧なコードを書く人間はいくらでもいる。
つまり「AIっぽいコード」と「几帳面な人のコード」を区別する客観的な根拠が、判定する側に存在しない。
ここで判別を頑張ることは、根拠のない印象で候補者を落とすリスクと紙一重だと思う。
理由2：見抜けたとして、その候補者を落とすのは正しいのか
仮に100%の精度でAI利用を見抜けたとしよう。
それで、
「AIを使ったので不合格」
と判断するのは、果たして正しい採用なのか。
入社したら、その人は初日からAIを使って開発する。
少なくとも私の現場では、Claude CodeなりCopilotなりを使わずにコードを書く日は、もうほとんどない。
実務で毎日使うツールを、選考の場でだけ「使ったら減点」にする。
これは、電卓を使う経理を採用するのに、そろばんの腕前で合否を決めるようなものだと思う。
もちろん、基礎的なコーディング能力が不要になったと言いたいわけではない。
ただ、AIを使うこと自体を不正とみなすことで、本当に実務能力を正しく測れているのかは疑問が残る。
理由3：いたちごっこに勝者はいない
それでも見抜こうとするなら、監視を強化するしかない。
たとえば、
- 画面録画
- カメラ常時ON
- 監督付きの会場受験
などだ。
できなくはないが、候補者体験は悪くなるし、選考コストも上がる。
そこまでして守ろうとしているものは何か。
「AIなしで問題を解く力」だ。
その能力自体に一定の価値はある。
ただ、実務でAI利用が前提になっていくほど、その一点だけを守るためのコストは相対的に大きくなっていく。
こうして「見抜く」という方向を諦めたとき、ようやく本当の問いが見えてきた。
問題は、候補者がAIを使うことではない。
「AIを使えば誰でも解ける問題」で人を測ろうとしていることだ。
ライブコーディングも、もう逃げ場ではない
「じゃあ、その場で書かせればいい」
次に出てくるのは自然とこの案だ。
実際、オンラインの技術面接ではライブコーディング形式も広く使われている。
その場で問題を出して、画面共有しながらコードを書いてもらえば、持ち帰り課題よりは本人の思考過程を確認しやすい。
ただ、これも「AIを使わせないための仕組み」として考えると、完全な解決策ではない。
画面共有に映らないオーバーレイなどを使って、リアルタイムで面接を支援するAIツールも登場している。
技術面接向けのAI支援ツールを起点に生まれたCluelyは、2025年にAndreessen Horowitz主導で1,500万ドルの資金調達を行ったことでも話題になった。
つまり、
出題形式をどう変えても、「AIで解ける問題を出し、AIだけは禁止する」という前提のままでは、いたちごっこは終わらない。
変えるべきは形式ではなく、測る対象そのものではないか。
私が思う、いま測るべき3つの力
AIが「コードを書く」工程を大きく担うようになった今、エンジニアの仕事はその前後へ広がっている。
だとすれば、選考で見るべきなのは、次の3つではないかと私は考えている。
① 仕様把握能力（上流）
曖昧な要求を正しく理解し、確認すべき点を確認し、作るべきものを特定する力。
ここを間違えると、AIは間違ったものを高速に作ってくれるだけだ。
実務で致命傷になるのは、必ずしも文法ミスではない。
たとえば、
- 誰向けの機能なのか
- データはどこに保存するのか
- 例外時はどうするのか
- 既存仕様との整合性は取れているのか
といった、仕様の取り違えの方が大きな問題になることも多い。
② AIを使いこなす実装力（中流）
素のコーディング力だけではなく、AIを道具として低コストかつ最大限のアウトプットを引き出す力。
たとえば、
- タスクをどう分解するか
- どの情報をコンテキストとして渡すか
- どこまでAIに任せるか
- 出力が期待とズレたときにどう軌道修正するか
- AIの提案を採用するか捨てるか
同じAIを使っても、ここで生産性は大きく変わる。
それは日々の開発でも痛感している。
「AIを使えるか」ではなく、「AIをどう使うか」 に、すでに明確な個人差がある。
③ 出力を検証し、責任を持てる力（下流）
AIは、自信満々に間違える。
生成されたコードのどこが危ないのか。
Flutterなら、たとえば、
- 不要なrebuild
- 状態管理の破綻
-
dispose漏れ - 握りつぶされた例外
- lifecycleを考慮していない非同期処理
- iOS / Android固有設定の不足
などを見抜き、
「このコードを本番に出してよい」と自分の名前で言える力。
書く力の価値が相対的に下がった分、読む力・疑う力・判断する力の価値はむしろ上がっていると思う。
こうして並べると、ひとつ気づくことがある。
この3つは、実はAI以前から優秀なエンジニアに求められていた力だ。
AIは求める能力をまったく別物に変えたのではなく、
「コードが書けること」という分厚い覆いを剥がして、もともと本質だった部分を露出させただけ
なのかもしれない。
じゃあ、何をやるのか——選考私案「AI利用OK面接」
方針は一言で言える。
隠れて使われるものを禁止するのではなく、堂々と使ってもらい、その「使い方」ごと評価する。
先ほどの3つの力に対応させて、選考を3パートで構成する案だ。
① 仕様把握を測る：「あえて曖昧な要件」を渡す
完成された問題文は出さない。
代わりに、実務さながらに穴のある要件を渡す。
「このアプリに、お気に入り機能を追加してください」
これだけだ。
評価するのは、実装そのものだけではなく、実装前に何を確認するか。
たとえば、
- お気に入りはローカル保存か、サーバー同期か
- ログアウトしたら消えるのか
- 最大件数はあるのか
- 一覧の並び順はどうするのか
- 複数端末で同期するのか
- オフライン時はどうするのか
実務で事故るのは、コードの文法ではなく、こういう確認の漏れだったりする。
もちろん、AIに、
「実装前に確認すべき事項を洗い出して」
と頼めば、質問候補はいくらでも出せる。
だから評価したいのは、質問を何個思いつけるかではない。
AIが挙げた確認事項も含めて、
- 何を仕様上のリスクだと捉えるか
- 何を優先して人間に確認するか
- どこは自分で仮定を置いて進めるか
- その判断をなぜしたのか
を見る。
同じ質問リストを持っていたとしても、全部を機械的に聞く人と、重要度を判断して必要なものだけ確認できる人では、実務での進め方は大きく違う。
見るべきなのは「質問の数」ではなく、曖昧な情報の中から論点を見つけ、判断する力なのかもしれない。
② AI活用実装力を測る：AIごと画面共有するライブ実装
最初にこう伝える。
「AIを使ってください。むしろ使わないと時間内に終わらない分量です」
エディタもAIチャットも含めて画面共有してもらい、完成物だけではなく過程を見る。
見るポイントは、たとえば次のようなものだ。
- タスクをどう分解して、どの順で着手するか
- AIに何を任せ、何を自分で判断するか
- AIへの指示に必要なコンテキストを渡せているか
- 出力をそのまま採用していないか
- 期待とズレたときにどうリカバリーするか
- 不要な変更が入ったときに気づけるか
同じAIを使っても、ここで生産性は大きく変わる。
そして副産物として、少なくとも 「AIを使ったかどうか」を必死に監視する必要はかなり薄れる。
評価したいのはAI利用の有無ではなく、
どのAIを、どのタイミングで、何のために使い、その出力をどう判断したか
だからだ。
もちろん、替え玉や課題流出など、AI利用とは別の不正対策は必要になる。
ただ、「AIを使ったら不正」という前提を捨てるだけでも、終わりのない監視競争からは一歩抜け出せると思う。
③ 検証力を測る：「AIが書いた欠陥コード」をレビューしてもらう
こちらで用意した、
「動くけれど問題のあるコード」
をレビューしてもらう。
たとえばFlutterなら、こんなコードだ。
class UserPage extends StatefulWidget {
const UserPage({super.key});
@override
State<UserPage> createState() => _UserPageState();
}
class _UserPageState extends State<UserPage> {
List<Post> posts = [];
@override
void initState() {
super.initState();
postStream.listen((data) {
setState(() => posts = data); // (1)
});
}
@override
Widget build(BuildContext context) {
final sorted = posts.toList()
..sort((a, b) => b.createdAt.compareTo(a.createdAt)); // (2)
return ListView(
children: sorted.map((p) => PostTile(post: p)).toList(),
);
}
}
一見すると普通に動く。
でも、たとえば次のような論点がある。
-
(1)Streamの購読をdisposeで解除していない - Widget破棄後にイベントが来れば、
setState() called after dispose()を引き起こしうる -
(2)buildのたびにソートが走る - 件数が増えるほどrebuild時のコストも増える
- Stream側のエラーハンドリングがない
- 大量件数なら
ListView.builderなども検討余地がある
そして、
「AIにコードを貼ってレビューさせればいいのでは？」
と思うかもしれない。
それでいい。
むしろAIを使ってもらう。
AIは10個、20個と指摘を返してくるかもしれない。
評価したいのは、その先だ。
- どの指摘が本当に危険なのか
- どれは今すぐ直すべきなのか
- どれは単なる好みなのか
- どの問題がユーザー影響につながるのか
- 何から優先して修正するのか
を取捨選択し、自分の言葉で説明できるかを見る。
AIの指摘をたくさん出せる人ではなく、AIの指摘に優先順位をつけられる人を評価したい。
それができる人なら、AIの出力に自分の名前で責任を持てると思う。
実は、海外企業も「AIを禁止しない面接」に動き始めている
ここまで書くと、
「それは理想論では？」
と思われるかもしれない。
そこで、この案を考えながら海外の採用事例を調べてみたところ、すでにかなり近い方向へ動いている企業があった。
たとえばCanvaは2025年、技術面接においてAIの利用を禁止するのではなく、AIを使うことを前提にしたコーディング面接について公式Engineering Blogで紹介している。
評価するのも、単純にコードを書けるかどうかだけではない。
- 曖昧な要求をどう整理するか
- AIをどう活用するか
- 技術的な判断をどう行うか
- AI生成コードの問題を発見できるか
- 最終的な品質に責任を持てるか
といった部分だ。
興味深いことに、Canvaのパイロットでは、AI経験の浅い候補者は、コードが書けないからではなく、AIを導く判断力や、AIの提案が最適でないと見抜く部分で苦戦することが多かったという発見も報告されている。
単にコードが書けるかだけではなく、AIを導き、その出力を評価する「判断力」にも明確な差が出るということだ。
参考
自分たちの採用について考えて辿り着いた方向性、
AIを禁止するのではなく、AI込みでその人の判断を見る
が、すでに実際の採用の現場で使われ始めていると知った。
もちろん、Canvaの方式をそのまま真似すればよいとは思わない。
企業によって、
- 求めるエンジニア像
- 選考時間
- 扱う技術
- 採用するポジション
も違う。
ただ、少なくとも、
「AIを使わせたら実力が測れない」という前提そのものは、そろそろ見直してもいい時期に来ている
のだと思う。
正直に言うと、簡単ではない
ここまで「AI利用OK面接」を提案してきたが、当然デメリットもある。
この方式には、明確にコストがかかる。
- 曖昧要件の設計
- 欠陥コードの準備
- 評価基準の平準化
- 面接官へのトレーニング
- 面接時間の増加
- 候補者ごとの評価ブレ
自動採点できるコーディングテストと比べて、面接官側の負荷は確実に上がる。
評価も定性的になりやすく、面接官自身の目利きが問われる。
AI環境の差をどう扱うか
さらに難しいのが、候補者ごとのAI環境の差をどう扱うかだ。
普段からClaude CodeやCursorを使い込んでいる人と、無料のAIツールしか触ったことがない人では、当然スタート地点が違う。
有料プランによるモデル性能の差まで含めると、
「AI活用力」を測っているつもりが、
「使える環境の差」
を測ってしまう可能性もある。
会社側で同じAI環境を用意するのか。
それとも、普段使っている環境をそのまま持ち込んでもらうのか。
ここは、
公平性と「実務に近い状態で測ること」のバランス
を考えて、別途設計する必要があると思っている。
だから弊社も、まだこの方式へ移行したわけではない。
それでも私は、
AIを使えば多くの人が正解できるテストで誰かを選別し続けるよりは、こうした部分にコストを払う価値がある
と思っている。
だからこの記事のタイトルは「やめた」ではなく、「やめたい」 だ。
これから選考を受ける側の方へ
最後に、逆の立場の方へ一つだけ。
私は、AIを使うこと自体を隠す必要はないと思っている。
ただ、
説明できないコードを提出するのが一番危ない。
たとえば、
- なぜこう書いたのか
- AIは何を提案したのか
- なぜその案を採用したのか
- 他の選択肢と比べて何が良かったのか
- このコードにはどんなリスクがあるのか
を、自分の言葉で説明できるか。
AIが書いたコードだったとしても、最終的にその判断を自分で引き受けられるなら、それは十分にその人の実力の一部だと思う。
逆に、
「AIが出したから採用した」
しか説明できないコードは、たとえ完璧に動いていても怖い。
AI時代になって、コードを書く速度そのものより、
「なぜこれでいいのかを説明できること」
の価値が上がっているように感じる。
おわりに
エンジニア採用の現場は、これから同じ問題にぶつかる会社がさらに増えていくと思う。
AIを禁止するのか。
AI利用を申告してもらうのか。
AI込みで評価するのか。
あるいは、コーディングテストそのものを別の形に変えるのか。
まだ正解はない。
私自身も、この記事で提案した方法がベストだとは思っていない。
ただ一つ感じているのは、
AIをどう締め出すかを考えるより、AIがいる前提で「人間の何を評価するのか」を考える方が、これからの採用には重要なのではないか。
ということだ。
皆さんの会社では、AI時代のエンジニアのスキルをどう測っていますか。
実際にAI利用OKの選考を導入した方。
逆に失敗した方。
候補者側で、
「この選考は良かった」
「この選考は微妙だった」
という経験がある方も、ぜひコメントで教えてください。