TL;DR（この記事の要約）

• 2026年現在、Cluely・Interview Coderなど**面接中にリアルタイムでAI回答を表示する「カンニングAI」**が急増。画面共有では検出不可能なオーバーレイ型ツールも登場している

• Fabricの約19,000件の面接データ分析では、オンライン技術面接の約15%でAI支援の兆候が検出されている

• 従来型のコーディング試験やアルゴリズム問題は「AIの使い方テスト」と化しており、候補者の実力を測る選考シグナルとして機能しにくくなっている

• 対策の本質は「不正を検出する」ことではなく、「AIを使っても差がつかない評価軸」に選考を再設計すること

• 具体的には設計判断ディスカッション・ライブデバッグ・過去の実務経験深掘りなど、AIが代替しにくい領域にシフトする

このページでわかること

「オンライン面接で候補者がAIを使っていた気がするけど、どう対処すればいいかわからない」

採用担当者やエンジニアリングマネージャーから、こうした相談が増えています。ChatGPTやCopilotで事前に回答を準備するレベルにとどまらず、面接中にリアルタイムでAIが回答を生成する「カンニングAI」ツールが普及し始めました。画面共有では見えないオーバーレイ表示、音声をリアルタイム解析して回答案を提示するなど、もはや面接官の目視だけでは検出が困難な状況です。

この記事では以下を解説します。

• 2026年に普及している面接カンニングAIツールの実態と仕組み

• AI不正が採用プロセスに与えるリスクと損失

• 検出アプローチの現状と限界

• AIに強い選考プロセスの再設計方法（5つの具体的手法）

• 面接官が今日からできる対策チェックリスト

• 企業規模別の導入ロードマップ

人材業界で採用を売る側にいた経験と、エンジニアとして採用される側にいる経験の両方から、実践的な対策をお伝えします。

なお、AI時代の技術面接全般の再設計については「AI時代のエンジニア技術面接リデザイン｜評価が変わる選考設計ガイド」、コーディング試験の設計については「エンジニア採用のコーディング試験設計と公平な評価の実践ガイド」もあわせてご覧ください。

1. 面接カンニングAIの実態｜何が起きているのか

「見えないカンニング」の仕組み

2026年現在、エンジニア採用の面接で使われるAI不正ツールは大きく3つのカテゴリに分かれます。

リアルタイムオーバーレイ型

CluelyやInterview Coderに代表されるツールです。これらはOSのウィンドウマネージャに低レベルでアクセスし、透明なオーバーレイとして回答を画面上に表示します。ZoomやTeamsの画面共有は「デスクトップの下のレイヤー」しかキャプチャしないため、面接官からはオーバーレイが見えません。

音声解析型

面接官の質問音声をリアルタイムで文字起こしし、AIが即座に回答案を生成するタイプです。候補者はイヤホンやサブディスプレイで回答を確認しながら話します。一般的に質問から回答までに3〜5秒の一定した遅延が発生するのが特徴です。

事前準備＋リアルタイム補助型

想定質問に対するAI生成回答を事前に準備し、面接中はキーワード検索で該当する回答を呼び出すタイプです。これは従来の面接対策の延長線上にありますが、AIによって回答の品質が飛躍的に向上しています。

どれくらい広がっているのか

Fabricが2026年に公開した約19,000件の面接分析データによると、オンライン技術面接の約15%でAI支援の兆候が検出されています。特にリモートでのコーディング試験では、不正の疑いがある面接の割合がさらに高いとされています。

リクルートワークス研究所の報告では、採用プラットフォームのPhenomが2025年5月に「Fraud Detection Agents」を発表するなど、不正検出ツール市場が急成長していることが紹介されています。

この問題が深刻なのは、AI不正が特定の企業規模や業界に限定されないことです。スタートアップから大企業まで、オンライン面接を実施しているすべての企業が影響を受けます。特に以下のような場面でリスクが高まります。

• フルリモート採用で対面の機会がない場合

• 一次選考をコーディング試験のみで判断している場合

• 面接官がエンジニアではなく、技術的な深掘りが難しい場合

• 採用の緊急度が高く、選考のスピードを優先している場合

カンニングAIの「性能」と進化スピード

見過ごせないのは、これらのツールの精度がすでに実用レベルに達している点です。一般的なLeetCode型のアルゴリズム問題であれば、GPT-4oやClaude系モデルはほぼ正答を出せます。つまり、標準的なコーディング試験は「候補者のコーディング力」ではなく「AIプロンプトの使い方」を評価するテストに変わりつつあるのが現実です。

さらに厄介なのは、これらのツールの進化スピードです。2024年時点ではテキストベースの回答支援が主流でしたが、2025年後半からは音声リアルタイム解析が一般化し、2026年に入ってからはオーバーレイ型が急速に普及しています。半年前の対策が通用しなくなる速さで進化が続いています。

なりすまし（プロキシ面接）の問題

カンニングAIに加えて、面接自体を別人が受ける「なりすまし」（プロキシ面接）も増加傾向にあります。リモート面接では本人確認が困難なケースがあり、スキルの高いエンジニアが複数の候補者の面接を代行するビジネスすら存在します。

Deloitte UKが2024年9月に新卒採用で対面面接を再開した背景には、こうしたなりすまし問題への対応もあったとされています。

2. AI不正が採用にもたらすリスク

ミスマッチ採用のコスト

AI不正によって実力以上のパフォーマンスを見せた候補者を採用した場合、入社後のギャップは深刻です。

• オンボーディング期間の長期化: 面接で見せたスキルレベルと実際のスキルに乖離があり、想定していた立ち上がり期間では戦力化しない

• チームの生産性低下: 期待していたアウトプットが出ず、他メンバーのサポート工数が増加する

• 早期離職リスク: スキルギャップに本人が苦しみ、半年以内に離職するケースも少なくない

• 採用コストの二重発生: 再採用にかかる費用・工数がそのまま損失になる

• チームの士気への影響: 既存メンバーが「なぜこの人が採用されたのか」と疑問を持ち、採用プロセスへの信頼が低下する

• プロジェクト遅延: 即戦力として計画に組み込んでいた場合、プロジェクト全体のスケジュールに影響する

エンジニアの採用コストは一般的に年収の30〜50%程度と言われています。ミスマッチ採用が発生すれば、この投資がすべて無駄になるだけでなく、機会損失も生まれます。さらに、再採用のリードタイムも考慮すると、1件のミスマッチが企業にもたらす総コストは想像以上に大きくなります。

採用ミスマッチの構造的な原因と防止策については「エンジニア採用ミスマッチを防ぐ原因分析と実践的な対策ガイド」で詳しく解説しています。

選考の信頼性低下

AI不正が横行すると、選考プロセスそのものへの信頼が揺らぎます。

• 面接官が「この回答は本人の実力なのか？」と常に疑念を抱く状態になる

• 正直に面接を受けている候補者が不利になり、公平性が損なわれる

• 結果として、優秀な候補者が「あの会社の選考は形骸化している」と判断し、応募を避けるリスクがある

法的・倫理的リスク

候補者の不正を理由に内定取消や解雇を行う場合、法的な根拠が求められます。「面接でAIを使っていた疑いがある」だけでは、正当な理由として認められない可能性があります。

ここで問題になるのが、「AIの使用が不正かどうか」の線引きです。面接前にChatGPTで想定質問を研究するのは従来の面接対策と本質的に変わりません。面接中にリアルタイムでAIに回答させるのは明らかに不正です。しかし、その間のグレーゾーンは広く、企業ごとにポリシーを明確に定義する必要があります。

具体的には以下のような対応が推奨されます。

• 採用選考におけるAI使用ポリシーを文書化し、候補者に事前共有する

• 「禁止する行為」と「許容する行為」を具体的に定義する（例：事前の情報収集にAIを使うのはOK、面接中のリアルタイム使用は不可）

• 不正が発覚した場合の対応手順（選考中止・内定取消等の条件）を事前に定めておく

• 法務部門や社外の弁護士に、ポリシーの法的妥当性を事前確認する

採用選考における法務知識の全般については「エンジニア採用の法務知識ガイド｜労働契約・競業避止・知財の実務」で詳しく解説しています。AI活用における法規制やバイアスのリスクについては「エンジニア採用AI活用のリスクと法的対応｜バイアス防止の実践ガイド」もあわせてご覧ください。

採用ブランドへの影響

AI不正対策の姿勢は、自社の採用ブランドにも影響します。過度な監視体制を敷けば「社員を信用しない文化」と見られるリスクがありますし、逆に何も対策しなければ「選考がザルで入社のハードルが低い」と見られかねません。

理想的なのは「AI活用を前提にした先進的な選考を行っている」というポジショニングです。「当社の選考ではAIの使用を認めています。その上で、あなた自身の判断力とコミュニケーション力を評価します」というメッセージは、優秀なエンジニアにとって魅力的に映ります。

3. 不正検出アプローチの現状と限界

テクノロジーによる検出

2025〜2026年にかけて、複数のHRテック企業がAI不正検出ツールをリリースしています。

行動分析型

• 候補者の視線の動き、応答速度のパターン、タイピングリズムなどを分析する

• PhenomのFraud Detection Agentsは、ChatGPTやClaudeの利用痕跡をリアルタイムで検出する機能を備えている

• ただし、精度は完璧ではなく、誤検出のリスクがある

環境監視型

• プロクタリング（試験監視）ソフトで候補者のPC環境を監視する

• ブラウザのタブ切り替え、外部アプリの起動、背景ノイズなどを検出する

• セキュアブラウザを使って他アプリケーションへのアクセスを制限する方法もある

音声・映像分析型

• 候補者の発話パターンを分析し、台本を読み上げているかどうかを判定する

• AIの回答を読み上げる場合、自然な会話と比較して抑揚や間の取り方に特徴的なパターンが出る

• 応答までの遅延が一定（3〜5秒）であることも検出シグナルの一つ

検出アプローチの限界

技術的な不正検出には、構造的な限界があります。

いたちごっこになる

検出ツールが進化すれば、不正ツールも検出を回避する方向に進化します。たとえば、応答遅延をランダム化する、音声パターンを自然に近づけるなど、回避策は次々と登場します。

候補者体験を損なう

過度な監視は候補者にストレスを与え、「この会社は社員を信用しない文化なのか」という印象を与えかねません。優秀な候補者ほど選択肢が多いため、監視が厳しい企業の選考を避ける可能性があります。

候補者体験（CX）が採用成果に与える影響については「エンジニア採用CX（候補者体験）を改善して辞退率を下げる実践ガイド」で解説しています。

法的リスク

候補者のPC環境を監視する行為は、プライバシーの観点から問題になるケースがあります。特に日本の個人情報保護法のもとでは、監視の範囲と方法について慎重な設計が必要です。

検出だけに頼る戦略は持続しない

結論として、不正検出だけを軸にした対策は長期的に維持困難です。むしろ重要なのは、「AIを使っても差がつかない」評価軸への移行です。次章以降では、その具体的な方法を解説します。

4. AIに強い選考プロセスの再設計｜5つの実践手法

手法1: 設計判断ディスカッション

概要: 候補者に対してシステム設計の課題を提示し、設計判断の「Why」を深掘りする対話型の評価手法です。

なぜAIに強いのか: AIは「一般的な正解」を生成できますが、「なぜその選択肢を選んだのか」「過去の経験からどう判断したか」「トレードオフをどう考えたか」といった判断プロセスの深掘りには対応しきれません。

実践例:

• 「このシステムでRDBとNoSQLのどちらを選びますか？」→ 回答後に「前職でデータストアの選定で迷った経験はありますか？」と具体的な経験を深掘りする

• 「このアーキテクチャの弱点はどこですか？」→ 「もし予算が半分だったら、どこを妥協しますか？」と制約条件を変えて思考の柔軟性を見る

• 「この設計を3年後に見直すとしたら、何を変えますか？」→ 技術トレンドの理解と長期的視点を評価する

評価ポイント:

• 判断の根拠を自分の言葉で説明できるか

• 過去の具体的な経験に基づいた回答ができるか

• 前提条件が変わったときに柔軟に思考を切り替えられるか

• トレードオフを適切に言語化できるか

システムデザイン面接の詳細な設計方法は「エンジニア採用のシステムデザイン面接設計ガイド｜評価基準と実践手法」を参照してください。

手法2: ライブデバッグ＆コードリーディング

概要: 候補者にバグを含むコードを渡し、リアルタイムで原因を特定・修正してもらう手法です。

なぜAIに強いのか: AIは「ゼロからコードを生成する」のは得意ですが、「既存コードの文脈を理解し、問題箇所を特定する」プロセスには限界があります。特に、複数ファイルにまたがるバグの追跡や、実行環境に依存する問題の切り分けは、実務経験に基づく直感と思考プロセスが問われます。

実践例:

• 本番で実際に発生したバグ（匿名化済み）を再現した環境を用意する

• 候補者に「このAPIが500エラーを返す原因を特定してください」と依頼する

• 思考プロセスを口頭で説明しながら進めてもらう（シンキングアラウド）

• デバッグの進め方、仮説の立て方、ツールの使い方を観察する

• 修正が終わったら「このバグが再発しないようにするには何をしますか？」と再発防止策を聞く

準備のコツ:

ライブデバッグの課題は事前準備に手間がかかりますが、一度作れば複数の候補者に使い回せます。以下の手順で準備すると効率的です。

1. 過去に実際に発生したバグを匿名化・簡素化する

2. 再現環境をDockerコンテナやオンラインIDEで用意する

3. 難易度を「15分で原因特定、30分で修正完了」程度に調整する

4. 面接官用のガイド（想定される解法、評価基準、ヒントの出し方）を作成する

評価ポイント:

• 問題を体系的に切り分ける能力

• ログやエラーメッセージの読み解き方

• 仮説を立てて検証するプロセスの質

• 行き詰まったときのリカバリー能力

• ヒントを受けたときの活用の仕方

手法3: 過去の実務経験の構造化深掘り（STARメソッド応用）

概要: 候補者の過去の実務経験を、Situation（状況）→ Task（課題）→ Action（行動）→ Result（結果）の構造で深掘りする手法です。

なぜAIに強いのか: AIは一般的な「それっぽい経験談」を生成できますが、具体的な文脈に踏み込んだ質問を重ねると、実体験に基づかない回答はほぼ確実に破綻します。

実践例:

面接官: 「直近でもっとも困難だった技術的課題を教えてください」 候補者: 「マイクロサービス間のデータ整合性の問題に対応しました」 面接官: 「そのとき、チーム内で意見が分かれた場面はありましたか？」 候補者: 「はい、Saga PatternとTwo-Phase Commitで意見が割れました」 面接官: 「あなたはどちらを推しましたか？ その理由は？」 面接官: 「最終的にどう決着しましたか？ 振り返って別の選択もあり得たと思いますか？」

このように、一つのエピソードを5〜6回掘り下げることで、実体験と作り話を区別できます。

評価ポイント:

• 具体的な数字や固有名詞が出てくるか

• 感情や葛藤を自然に語れるか

• 反省点や学びを自分の言葉で表現できるか

• 質問の角度を変えても一貫性があるか

構造化面接の全般的な設計については「エンジニア採用の構造化面接設計ガイド｜評価ブレをなくす実践手法」で解説しています。

手法4: AI出力レビュー課題

概要: AIが生成したコードや設計案を候補者に渡し、レビュー・改善してもらう手法です。「AIを使えること」を前提にしつつ、その上で候補者が何を加えられるかを評価します。

なぜAIに強いのか: AIの出力をレビューするには、AIの限界を理解し、品質基準を持ち、改善提案ができる必要があります。これはAI自身にはできない、「AIの上に立つ」スキルです。実務でもAI生成コードのレビューは日常的なタスクになりつつあるため、入社後の業務に直結する評価にもなります。

実践例:

• AIが生成したReactコンポーネントを渡し、「このコードをプロダクションに出す前に、何を直しますか？」と質問する

• AIが書いたインフラ設計書を渡し、「セキュリティの観点で見落としている点を指摘してください」と依頼する

• AIが生成したテストコードを渡し、「カバーされていないエッジケースを3つ挙げてください」と質問する

• AIが生成したAPIのエラーハンドリングコードを渡し、「本番運用で起きそうな問題を指摘してください」と依頼する

課題の作り方のコツ:

AI出力レビュー課題を効果的にするには、「AIが間違えやすいポイント」を意図的に含めることが重要です。たとえば以下のようなパターンが有効です。

• エラーハンドリングの不備（正常系は完璧だがエッジケースを見落としている）

• パフォーマンスの問題（動くがN+1クエリが発生するなど）

• セキュリティの脆弱性（SQLインジェクションやXSSの可能性が残っている）

• 設計上の問題（密結合、テスタビリティの低さなど）

AIはこれらの問題を「自分で作ったコード」として認識できないため、カンニングAIを使って回答するのは困難です。

評価ポイント:

• AIの出力の問題点を正確に特定できるか

• 改善提案の具体性と実現可能性

• 品質基準の高さ（何を「十分」と判断するか）

• AI出力の限界をどの程度理解しているか

• レビューの優先順位付け（何から直すべきかの判断力）

手法5: 対面（またはカメラオン）でのペアプログラミング

概要: 面接官と候補者がリアルタイムで一緒にコードを書く手法です。対面が難しい場合は、カメラオン＋画面共有で実施します。

なぜAIに強いのか: ペアプログラミングではリアルタイムの対話が求められるため、AIの回答を読み上げる時間的余裕がありません。また、面接官が横で見ている（または画面を見ている）ため、オーバーレイ型ツールの使用も困難です。

実践例:

• 30分程度の時間で、小さな機能追加やリファクタリングを一緒に行う

• 候補者にドライバー（コードを書く役）をやってもらい、面接官はナビゲーター（方向性を示す役）を務める

• 途中で要件変更を入れ、対応力を見る

評価ポイント:

• コミュニケーションの質（考えを言語化しながらコードを書けるか）

• フィードバックの受け止め方

• 意思決定のスピード

• 実際のコーディングスキル

ペアプロ面接の詳細は「エンジニア採用のペアプロ・ライブコーディング面接設計ガイド」を参照してください。

5. 面接官向け：AI不正を見抜くためのシグナルと対処法

「怪しい」と感じたときのシグナル

面接中に以下のシグナルが複数見られた場合、AI支援の可能性を疑う根拠になります。ただし、あくまで「疑い」であり、これだけで不正と断定してはいけません。

応答パターンの違和感

• 質問から回答までの遅延が常に3〜5秒で一定（自然な会話では質問の難易度によって変わる）

• 回答が「教科書的」で、個人の経験や感情が含まれていない

• 専門用語を正確に使いこなすが、噛み砕いた説明を求めると急に曖昧になる

• 質問を言い換えると、同じ内容でも全く違う切り口の回答が返ってくる

視線・動作の不自然さ

• 回答中に特定の方向（サブディスプレイの方向など）を頻繁に見る

• タイピングの速度が不自然に速い、または回答の質に対してタイピングが少なすぎる

• カメラを見ずに、画面の別の場所をずっと見ている

コーディング時の不自然さ

• コードが一気に完成形で出てくる（通常は段階的に書く）

• エラーが出た場合の対処が「AIっぽい」（全体を書き直す、関係ない部分まで修正するなど）

• 変数名やコメントが異常に丁寧（実務経験者は場面に応じてカジュアルに書くことも多い）

シグナルを検出したときの対処法

やってはいけないこと

• その場で「AIを使っていますか？」と直接問い詰める

• 根拠なく不正と断定する

• 面接を途中で打ち切る

やるべきこと

• 深掘り質問に切り替える（「もう少し詳しく教えてください」「前職では具体的にどうしていましたか？」）

• コードについて「この部分をなぜこう書いたのか」を逐一説明してもらう

• 前提条件を急に変えて、思考の柔軟性を試す（「もしこの制約がなかったら、別のアプローチを取りますか？」）

• 面接後に他の面接官と所見を共有し、複数の視点で判断する

面接後の合議（デブリーフ）の具体的な進め方は「エンジニア採用の面接デブリーフと合否判定の仕組み化ガイド」を参照してください。

6. 選考フロー全体の再設計ロードマップ

Phase 1: 即座にできる対策（1〜2週間）

まずは大きな投資なしで始められる対策から着手します。

• 面接官全員に「AI不正のシグナル」を共有する30分程度の研修を実施する

• 既存のコーディング試験を「思考プロセスの可視化」重視に変更する（回答だけでなく、思考の過程を口頭で説明してもらう）

• 面接冒頭で「AIツールの使用に関するポリシー」を候補者に明示する

• デブリーフのチェック項目に「AI支援の疑い」を追加する

• 面接評価シートに「回答の具体性（抽象的/具体的経験に基づく）」の評価項目を追加する

この段階でのポイントは、面接官の「気づき力」を高めることです。ツールに頼らず、面接官自身がAI支援の兆候を識別できるようになるだけで、選考の質は大きく向上します。

Phase 2: 選考フォーマットの変更（1〜2ヶ月）

選考フロー自体を段階的に更新していきます。

• コーディング試験の出題形式を、アルゴリズム問題から実務型課題（バグ修正・コードレビュー）に段階的に移行する

• 設計判断ディスカッションを選考フローに組み込む（技術面接の30%以上をディスカッション形式にする目安）

• 最終面接に対面（またはカメラオンのペアプロ）を導入する

• 面接官のトレーニングを実施し、深掘り質問のスキルを強化する

• 選考の各ステージで「何を評価するか」を明文化し、面接官間の認識を揃える

• リファレンスチェックの導入を検討する（特に技術力に疑問が残るケース）

面接官育成の具体的な方法は「エンジニア採用の面接官トレーニング｜評価精度を高める実践手法」で解説しています。

Phase 3: プロセス全体の最適化（3〜6ヶ月）

選考プロセスの根本的な再設計に取り組みます。

• 選考フロー全体を見直し、各ステージで評価する能力を明確に分離する

• ワークサンプルテスト（実際のタスクに近い課題を一定期間かけて取り組んでもらう）を導入する

• リファレンスチェックで候補者の実務能力を裏取りする

• 試用期間中の評価制度を設計し、入社後のスキル確認を仕組み化する

• 採用データを蓄積し、「面接評価と入社後パフォーマンスの相関」を分析する

• 定期的に選考プロセスをレビューし、新しいAIツールへの対応を継続する

• 面接質問バンクを構築し、「使い回しが効かない」ユニークな質問を蓄積する

ワークサンプルテストの設計については「エンジニア採用のワークサンプルテスト設計ガイド｜実務課題で見極める選考手法」を参照してください。リファレンスチェックの実施方法は「エンジニア採用のリファレンスチェック実践ガイド｜質問例と導入手順」を参照してください。

企業規模別の優先度

スタートアップ（〜30名）

スタートアップの最大の武器は「直接会える」ことです。少人数だからこそ、候補者と深い関係を築きやすい強みを活かしましょう。

• 対面面接を基本にする（オフィスに来てもらう）

• 採用数が少ないため、一人あたりの選考に時間をかけられる

• トライハイヤー（業務委託→正社員転換）で実務を見てから判断する

• CTOやリードエンジニアが直接面接し、技術的な深掘りの質を担保する

• カジュアル面談で候補者との信頼関係を構築し、面接本番でオープンなコミュニケーションを引き出す

トライハイヤーの導入方法は「エンジニア採用のトライハイヤー戦略｜業務委託→正社員で失敗を防ぐ」、カジュアル面談については「エンジニア採用のカジュアル面談完全ガイド｜選考移行率を上げる実践ノウハウ」で解説しています。

中規模企業（30〜300名）

中規模企業は採用数の増加に伴い、選考プロセスの標準化が重要になります。面接官の数も増えるため、評価基準の統一が鍵です。

• 選考フローの標準化と面接官トレーニングに投資する

• コーディング試験プラットフォームのアクションログ機能を活用する

• 構造化面接を導入し、評価のブレを減らす

• 面接官同士のキャリブレーション（評価基準の擦り合わせ）を定期的に実施する

大企業（300名〜）

• HRテックによる不正検出ツールの導入を検討する

• 選考プロセスの継続的な改善サイクル（PDCAまたはスクラム採用）を回す

• 採用データの分析体制を構築し、面接精度を定量的に管理する

• 社内のエンジニアが面接官として参加しやすい体制を整え、技術的な深掘りの質を担保する

• グローバル採用を行っている場合は、地域ごとのAIツール普及状況に応じた対策を設計する

7. AI時代の選考で「本当に評価すべきこと」

AIが代替できないスキルにフォーカスする

2026年の技術面接で評価すべきは、「AIと一緒に成果を出せる能力」です。具体的には以下の4つです。

問題の定義力

「何を解くべきか」を正しく特定する能力です。AIは与えられた問題を解くのは得意ですが、「そもそも何が問題なのか」を特定するのは苦手です。

設計判断力

技術的なトレードオフを理解し、制約条件のなかで最適な選択をする能力です。正解が一つではない状況で、根拠を持って判断できるかどうかが重要です。

コミュニケーション力

技術的な内容を非エンジニアにもわかるように説明する能力、チーム内で建設的な議論ができる能力です。プロダクトマネージャーやデザイナーとの協業、技術的な制約を経営層に伝える場面など、エンジニアのコミュニケーション力は日々の業務で試されます。これはAIには代替できません。

AI活用力

AIツールを適切に使いこなし、出力を批判的に評価・改善できる能力です。GitHub Copilot、Claude Code、Cursorなどのツールを使いこなすエンジニアと使わないエンジニアでは、アウトプットの速度と品質に大きな差があります。むしろ面接でAIの使用を許可し、「AIをどう使うか」を評価軸にする発想もあります。

「AI使用OK」という選択肢

逆転の発想として、面接でのAI使用を公式に認めるアプローチもあります。この場合、評価軸は以下に変わります。

• AIにどのようなプロンプトを入力するか（問題の分解力）

• AIの出力をどう評価・修正するか（批判的思考力）

• AIの使い方で、候補者間にどれだけの差が出るか

• AIを使っても解けない部分に対して、自力でどこまで進めるか

MetaやGoogleなどの企業では、すでにこのアプローチに移行しつつあります。「AIを使えない人を選ぶ」のではなく、「AIを最も効果的に使える人を選ぶ」という考え方です。

AI使用OKにする場合の設計ポイント

ただし、単に「AI使ってOK」と言うだけでは機能しません。以下の設計が必要です。

• 課題の難易度を上げる: AIだけで完答できない複合的な課題にする。「Reactコンポーネントを作ってください」ではなく、「既存のレガシーコードをReactに段階的に移行する計画を立て、最初の1コンポーネントを実装してください」のように、文脈理解と判断が必要な課題にする

• プロセスの透明化: 「何をAIに聞いたか」「AIの回答をどう修正したか」を画面共有で見せてもらう

• 制限時間の設定: AIを使う前提で制限時間を短めに設定し、AI活用の速度と判断力を見る

• AI出力への批判的レビューを必須化: 「AIが出したこのコード、このまま使いますか？ 修正するとしたらどこですか？」と必ず聞く

AI活用込みの面接設計の詳細は「AI時代のエンジニア技術面接リデザイン｜評価が変わる選考設計ガイド」を参照してください。

エンジニアとしての視点から

エンジニアとして日々AIツールを使って開発している立場から言えば、「AIを使わずにコードを書く」こと自体がすでに非現実的になりつつあります。GitHub CopilotやClaude Codeを使いこなすエンジニアと、使わないエンジニアでは、アウトプットの速度に大きな差があります。

だからこそ、面接で「AIを禁止してピュアな実力を見る」というアプローチは、実務との乖離が大きくなっています。むしろ、「AIをどう使いこなすか」「AIの出力をどう判断するか」を見るほうが、入社後のパフォーマンスを正確に予測できるはずです。

ただし、これは「すべてをAI任せにしていい」という意味ではありません。AIが出すコードの品質を判断し、アーキテクチャ上の意思決定ができ、チームメンバーと建設的に議論できるエンジニアこそが、AI時代に本当に価値のある人材です。

FAQ（よくある質問）

Q1. 面接でAIの使用を全面禁止すべきですか？

全面禁止は現実的ではなく、効果も限定的です。理由は3つあります。(1) 検出が技術的に困難で、いたちごっこになる。(2) 実務ではAIを使うのが当たり前なので、AIを使えない環境での評価は実務能力を正しく反映しない。(3) 候補者体験が悪化し、優秀な人材が他社に流れるリスクがある。むしろ「AIを使ってもいい。ただし、使い方と判断プロセスを説明してください」というスタンスが実践的です。

Q2. 小規模なスタートアップでも対策は必要ですか？

必要です。むしろスタートアップは一人の採用ミスマッチのインパクトが大きいため、対策の優先度は高いといえます。ただし、大がかりなツール導入は不要です。対面面接を基本にする、深掘り質問を意識する、トライハイヤーで実務を見てから判断する、という3つだけでも十分な効果があります。

Q3. 対面面接に戻すしかないのでしょうか？

対面面接が最も確実なAI不正対策であることは事実ですが、「すべて対面に戻す」必要はありません。一次面接はオンラインでスクリーニングし、最終面接は対面で実施するハイブリッド型が現実的です。オンライン面接でも、設計判断ディスカッションやSTARメソッドによる深掘りは有効に機能します。

Q4. コーディング試験を廃止すべきですか？

廃止する必要はありませんが、形式の見直しは必要です。LeetCode型のアルゴリズム問題はAIに解かれやすいため、以下に移行することを推奨します。(1) 実務に近いバグ修正・リファクタリング課題に変える。(2) コードを書く過程（思考プロセス）を口頭で説明してもらう。(3) 書いたコードについて「なぜこう書いたのか」を深掘りする。コーディング試験の設計の詳細は「エンジニア採用のコーディング試験設計と公平な評価の実践ガイド」を参照してください。

Q5. AI不正検出ツールは導入すべきですか？

企業規模と採用数によります。年間の採用数が多い中〜大企業であれば、Track TestのアクションログやPhenomのFraud Detection Agentsなどの検出ツールは投資対効果があります。ただし、検出ツール単体に頼るのではなく、選考フロー自体の再設計とセットで導入するのが効果的です。小規模な企業であれば、ツール導入よりも面接官のスキル向上に投資するほうがROIが高いでしょう。

Q6. 候補者にAI使用ポリシーをどう伝えるべきですか？

選考の最初の段階（エントリー時や一次面接前）に、明文化したポリシーを共有することを推奨します。「当社の技術面接ではAIツールの使用を認めています。ただし、使用したツールと、それを使った理由を面接中に共有してください」のように、透明性のある形で伝えましょう。ポリシーが曖昧だと、正直な候補者が不利になります。

Q7. リモート採用を続けながら対策するには？

リモート面接でも効果的な対策は複数あります。(1) カメラオン必須にし、画面共有と顔の表示を同時に確認する。(2) 設計判断ディスカッションなど、リアルタイムの対話を中心にする。(3) 最終面接のみ対面にするハイブリッド型を採用する。(4) ワークサンプルテスト（非同期）＋面接（同期）の組み合わせで、複数の角度から評価する。リモート採用の全般的なノウハウは「エンジニア採用のオンライン面接設計ガイド｜Web面接で見極める実践手法」を参照してください。

Q8. 面接官が技術に詳しくない場合はどう対策すればいいですか？

非エンジニアの人事担当者でも実施できる対策があります。(1) STARメソッドによる経験深掘りは技術知識がなくても効果的です。「具体的にどうしましたか？」「その結果どうなりましたか？」という質問は、回答の一貫性を確認する強力なツールです。(2) 技術面接はエンジニアに任せ、人事は行動面・カルチャーフィットの評価に集中する役割分担が有効です。(3) 非エンジニア人事向けの技術リテラシー研修を受けることで、「怪しいシグナル」への感度を高められます。非エンジニア人事の技術理解については「非エンジニア人事の技術リテラシー入門｜採用力を高める実践ガイド」を参照してください。

Q9. 入社後にスキルの乖離が発覚した場合はどうすべきですか？

まず試用期間中の評価制度を整備することが予防策として有効です。具体的なアクションとしては、(1) 入社30日・60日・90日の節目でスキル確認を行う。(2) メンターやマネージャーとの1on1で技術力の実態を把握する。(3) 明らかに面接時の申告と実態が異なる場合は、人事・法務と連携して適切に対応する。重要なのは「罰する」ことではなく、「事前に防ぐ仕組み」を整えることです。オンボーディング期間の設計については「エンジニアのオンボーディング完全ガイド｜早期戦力化と定着率向上の実践手法」を参照してください。

Q10. AI不正対策にかけるコストの目安はありますか？

対策のレベルによりますが、まず「コストゼロでできること」から始めるべきです。面接官への30分の研修、深掘り質問リストの作成、デブリーフへの項目追加は費用がかかりません。次のステップとして、コーディング試験プラットフォーム（Track Testなど）のアクションログ機能は月額数万円から利用可能です。大規模な不正検出ツールの導入は年間数百万円規模になりますが、ミスマッチ採用1件のコスト（年収の30〜50%）を考えれば、採用数が多い企業では十分にROIが合います。

まとめ

面接AIカンニングツールの普及は、エンジニア採用の選考プロセスに根本的な再考を迫っています。しかし、これは脅威であると同時に、選考の質を本質的に高めるチャンスでもあります。

この記事で紹介した対策の要点を改めて整理します。

問題の本質

• CluleyやInterview Coderなど、画面共有では検出不可能なカンニングAIツールが急増している

• 従来型のアルゴリズム問題やコーディング試験は、もはや候補者の実力を正確に測れなくなっている

• 不正検出ツールだけに頼る対策は、いたちごっこになり長期的に持続しない

いま対策として取り組むべきこと

• 短期（1〜2週間）: 面接官に「AIカンニングのシグナル」を共有し、深掘り質問のスキルを上げる。面接冒頭でAI使用ポリシーを候補者に明示する

• 中期（1〜2ヶ月）: コーディング試験を実務型（バグ修正・コードレビュー）に移行し、設計判断ディスカッションを選考に組み込む。最終面接を対面またはペアプロ形式にする

• 長期（3〜6ヶ月）: 「AI活用込み」の評価軸に移行し、選考フロー全体を再設計する。ワークサンプルテストやリファレンスチェックで多角的に評価する

忘れてはいけないこと

対策に力を入れるあまり、候補者体験を犠牲にしてはいけません。過度な監視や制限は、優秀な候補者を遠ざけます。「不正を検出して排除する」のではなく、「AIを使っても差がつく選考」を設計する。この発想の転換が、2026年以降のエンジニア採用における競争力の分水嶺になります。

また、AI不正対策は一度設計して終わりではありません。AIツールは日々進化しており、半年前の対策が通用しなくなることも珍しくありません。定期的に選考プロセスをレビューし、新しいツールや手法に対応し続ける姿勢が求められます。

選考フロー全体の設計については「エンジニア採用の選考フロー設計完全ガイド｜歩留まり改善の実践手法」もあわせてご覧ください。

techcellarでは、AI時代の選考プロセス設計を含むエンジニア採用支援を提供しています。「自社の選考フローを見直したい」「面接官のトレーニングを受けたい」といったご相談は、お問い合わせページからお気軽にどうぞ。