候補者がAI使用を認めた際の対応方法
採用チームが予期しない瞬間
テイクホーム課題のウォークスルー中に、候補者が口を切ります。「このコードの一部にChatGPTを使いました」。あるいはライブコーディング面接で、誠実性ログにコピペの記録が残った後、「そうなんです、Copilotを使ってました。いつもそうなんですよ」と自分から認めてくる。
ほとんどの採用チームは、こんな瞬間への明確なポリシーを持っていません。面接官は動揺し、愛想よく面接を終わらせて、その後のパネル会議で議論になります。反射的に不合格にするチームもあれば、「正直さは評価される」という理由で通してしまうチームもあります。どちらの反応も間違っています。両方とも、最も重要な唯一の問いを見落としているからです。この候補者はAIの助けなしに、その仕事をこなせるのだろうか？
このポストは、候補者がAI使用を自発的に認めてきた時の対応方法です。実際に誠実性を第一とした採用を実践しているチームの経験から、我々がお勧めするフレームワークをご紹介します。
ステップ1：反応しない。受け入れて続ける。
最初の10秒でその後の流れが決まります。ここで躊躇ったり拒絶したりすれば、候補者は口を閉ざしてしまい、判断に必要な唯一の情報—つまり本人がどのようにAIを使ったのかという正直な説明—を失ってしまいます。
ニュートラルな受け入れ方が効果的です：
「教えてくれてありがとう。AI使用については私たちもいろいろ考えているので、後から推測するより、実際にどう使ったのか詳しく聞かせもらいたいんです。説明してもらえますか？」
これは遡及的な許可ではありません。本当の情報を引き出すために、会話を広げているのです。こうすることで候補者は安心感を持ち、後からどんなデータ分析をするよりも、正確な説明が得られることが多いです。
ステップ2：AI使用のどのパターンなのかを見分ける
実質的に異なる3つのケースがあります。多くの不合格判定は、これら3つを一緒くたにしてしまうことが原因です。
- パターンA — AIを補助ツールとして使う。 Copilotで定型コードを自動生成させたり、ChatGPTに構文を確認したり、Cursorで生成されたコードを自分で書き直したりする。主体は本人で、AIはキー入力を減らすだけ。
- パターンB — AIと協働する。 プロンプトを自分で書き、複数の出力から選び、デバッグして統合する。アーキテクチャの選択は全て説明できるが、行ごとの細部は必ずしも全て弁護できるわけではない。
- パターンC — AIに全面依存する。 問題を入力して出力をコピペし、動くように調整するだけ。「何をするか」は説明できるが、「なぜこの設計か」や「制約が変わったら何が変わるか」は説明できない。
2026年の実務エンジニアの大多数はパターンAで仕事をしています。パターンCが問題。パターンBが判断の分かれ目で、ここでは候補者のフォローアップの回答がほぼ全ての意思決定を担うことになります。
ステップ3：3つのパターンを見分ける質問を重ねる
認問の後で「AIを使いました？」と聞いても意味がありません。もう答え知ってますから。本当に3つのパターンを見分ける質問はこれです：
- 「AIの最初の提案のどこが気に入らなかった？修正した箇所を示してください。」 パターンBなら具体的な瞬間を挙げられます。パターンCは硬直するか「変数名を変えた」みたいな曖昧な返答をします。
- 「ここでAIなしには書けなかった部分って、どこですか？もし使ってなかったら、どうしてました？」 パターンAとBは明確に答えられます。パターンCは曖昧なままか、突然防衛的になります。
- 「この関数が[コード内の特定のエッジケース]で呼ばれたら、何が起こりますか？」 インタビュー全体で最高のシグナル質問です。実行をシミュレーションできるか試します。パターンAとBは追跡できます。パターンCは困ります。
- 「もし制約が[X]に変わったら、何を変えますか？」 本当にデザインについて考えたのか、単にAIのデフォルトを受け入れたのかを見ます。パターンCの候補者はよく「AIに聞きます」と答えます。
これらの質問に鮮明に答える候補者は、最初のドラフトがどうであれ、パターンAかBを示しています。答えられない候補者は、コードがいくらきれいに見えても、パターンCを示しています。
ステップ4：既に持っている誠実性データと照合する
ここで誠実性レポートが活躍します。候補者の説明と、セッションデータが一致するかを確認します。
ライブコーディングセッションなら、以下を見てください：
- キー入力パターン。 パターンAは人間らしいバースト状入力と思考の一時停止。パターンCは長い沈黙の後、1回だけ大きなペーストがあります。
- ペースト時のタイミング。 30秒の沈黙→ペースト→細かな編集、これはパターンCの典型。コーディング中に何度もペーストするなら、通常はパターンA。
- コード文体の一貫性。 ファイル全体で書き方が同じ？それとも関数ごとに異なる著者っぽく見える？一貫性がなければパターンC、あればAかB。
- 最初にコードを書き始めるまでの時間。 難しい問題を見てから8秒以内に完成コードを入力し始めた？考えてません。
目的は候補者を「引っかける」ことではなく、既に言った認問が本当かどうか、データで確認することです。パネルの議論が「感覚」ではなく「事実」ベースになります。
ステップ5：職種の実際の基準で判断する
ここまでで3つの情報が揃いました：本人の説明、質問への答え、データ。これを職務内容と照らします。
- ほとんどのエンジニア職なら、パターンAかBで、その判断を説明できる候補者は採用検討の価値があります。現実として、優秀なエンジニアは皆、毎日AIを使っています。正直に使ったと言った人を罰して、黙って使った人を雇う—これは最悪の結果です。
- 独立思考が明示的な要件の職種（研究エンジニア、セキュリティアナリスト、未知の問題を一人で考える必要がある場合）は、コードの品質がどうあれ、パターンCはアウト。採用基準は「成果物」ではなく「思考力」だからです。
- シニア職なら、AIにやらせた判断トレードオフを説明できるかが分かれ目。AIでスケーフォルドして、そのアーキテクチャ上の選択を弁護できるシニアエンジニアは問題なし。でも流暢なコードなのに「なぜこの設計？」に答えられないシニアエンジニアは、あなたが払ってる値段より下のレベルでしか動いてません。
判断がつかなければ、別の問題で30分のフォローアップ面接を組んで、明確に「このセッションではAI禁止」と伝えてください。ほとんどの候補者は問題なく合格します。そうでない人たちが、あなたの答えをくれます。
ステップ6：事前にポリシーを明確にする
候補者の突然の認問にチームが戸惑うのは、ポリシーが文書化されていないせいです。これを事前に解決してください。すべてのアセスメント招待に、明確に書いてください：
- 非同期テイクホーム課題の場合：「助けになるツールは何でも使ってください。後で30分のウォークスルーで、コードについて説明してもらいます。」
- ライブコーディングの場合：「このセッション中はAI コーディングアシスタントは使わないでください。ドキュメント、メモ帳、通常のエディタはOKです。」
ルールが明確なら、認問は「ルール守りました」という確認信号か「守りませんでした」という事実かのどちらか。曖昧な瞬間が生まれません。
次に何をするか
AI使用を認めてくる候補者は、あなたに有利に働いています。AIを黙って使った候補者（そしてたくさんいます）が隠す情報を、教えてくれているからです。その認問を、即判決の口実ではなく、もっと深い会話のスタート地点として使ってください。
これを上手くやるチームは、3つの習慣を持っています。ラウンドごとのAIポリシー明示、推論の深さを探る面接、そして候補者の説明を検証する誠実性ツールです。これらが揃えば、AI認問は複数のシグナルの1つに過ぎなくなります。それが理想的な状態です。