コーディング面接でのCursorとGitHub Copilot使用の検出方法
ChatGPT型の検出戦略がCursorとCopilotを見逃す理由
コーディング面接の一般的な不正検出手法は、1つの前提に基づいています。候補者がAlt+Tabでチャットウィンドウに切り替え、解答コードを入手してペーストするというワークフローです。ペーストサイズ、タブ切り替え時間、バースト入力速度はすべて、このパターンを前提に設計されています。
しかし2026年、候補者が実際に使用しているAIツールはこの想定と異なります。Cursor、GitHub Copilot、Windsurf、Continue、そしてCluelyのような新世代の不可視オーバーレイツールはペーストを使いません。エディター内で直接動作し、Tabで提案を受け入れ、バッファーに文字を入力する方式は、ペーストイベントよりもはるかに「手入力」に見えます。Cursorを効果的に使う候補者は、ペースト警告をトリガーしませんし、タブ切り替えも行いません。素朴なスクリーニングツールの整合性レポートは完全にクリーンに見えるでしょう。
これは異なる問題であり、異なる検出手法が必要です。本記事では、エディター内AIアシスタントの行動特性、その限界が露呈する瞬間、そしてこうしたツールの正当な利用者でも確実に解釈可能な信号を得られるようにラウンドを設計する方法について解説します。
エディター内AIツールがプラットフォームに残す痕跡
大きく3つのカテゴリーのツール、3つの異なる兆候パターンがあります。
- タブ補完型エージェント（Copilot、Cursor Tab、JetBrains AI）。 短い遅延の後、「ゴーストテキスト」の提案が表示されます。候補者がTabキーを押すと、40～300文字が1回の操作でバッファーに挿入されます。キーストロークレコーダーの観点では、エディターの入力処理方式によって、高速キーストロークの連打か、単一のバッファー挿入イベントのいずれかに見えます。
- エージェンティック型エディター（Cursor Composer、Windsurf Cascade、Claude Code、Aider）。 候補者がサイドパネルに自然言語の指示を入力または音声入力すると、AIが大きなコード領域を一括で書き換えます。外部からは、対応するキーストロークがないまま複数行の編集が次々と発生する様子が観察されます。
- 不可視オーバーレイツール（Cluely、Interview Solver、Interview Coder）。 別プロセスが画面を読んで、スクリーンキャプチャAPIから見えないオーバーレイで候補者に解答を表示します。その後、候補者がそれを手入力または写字します。プラットフォーム記録には「候補者が自力で入力」と見えますが、入力パターンが不自然です。
いずれのケースも、ペースト動作ではなく、受け入れ、写字、または指示という形態です。そしてそれぞれに固有の痕跡があります。
信号1：タイピング中に現れるタブ受け入れバースト
タブ補完ツールの最も特徴的なシグネチャーは、キーストリームのパターンです。手入力で30文字の行を書く場合、80～250ミリ秒の間隔で30回のキープレスが連続し、ときどき1～2秒の停止が入ります。同じ行にCopilot Tabで提案を受け入れる場合は、0ミリ秒時点で1つのイベント、その後1ミリ秒ごとに30文字が挿入される、またはエディターによっては個別のタイミングデータなしで単一のバッファー挿入として記録されます。
ClarityHireのキーストロークレコーダーは、キー間の遅延が5ミリ秒未満の連続入力をマシン発信ブロックとして分類します。このブロックは通常のキーストロークとは分離して記録され、整合性レポートには「ペースト」でも「キーストロー」でもなく、受け入れという別のイベント型として表示されます。
レポートで注視すべきパターン：
- 毎分5～10個の受け入れイベント、各々40～250文字で、通常のタイピングと混在している。これが正規のCopilot/Cursorの動作パターンです。
- 1回の受け入れで関数全体を完成させる大型ブロック（300文字以上）。これはタブ補完ではなくエージェンティック型の動作です。
- ペースト0回、タブ切り替え0回なのに、初見の問題で22分以内に200行の動作するソリューションを完成させる。この圧倒的なボリュームそのものが信号です。
いずれか1つでは決定的ではありません。しかし初見の課題に対してこれらが全て揃えば、強い証拠となります。
信号2：人間には再現できないカーソルジャンプ
人間がコードを書くとき、カーソルは人間らしく動きます。矢印キー、Home/Endキー、別の行への時々のマウスクリック。一方、エージェンティック型エディターが領域を書き換える場合、カーソルは瞬間移動します。次の編集は前の編集から2つの関数離れており、その間に明目のナビゲーション操作がありません。ファイル間でのリファクタリングでは、Cmd+Pのファジー検索なしでアクティブファイルが切り替わります。
ライブコーディングラウンドで使われる協調編集エディターは、すべての変更でカーソル位置とアクティブドキュメントを記録します。タイムラインを見ると「テレポート編集」が目立ちます。80行目での編集直後に異なるファイルの12行目での編集が続き、その間に目に見えるナビゲーション操作やスクロールがない。人間がホットキーの組み合わせでそれを実現することは可能ですが、20分間で20回の瞬間移動が集中するパターンは異常です。2～3回なら正常。20分で20回はAIエージェントの仕業です。
信号3：候補者自身の基準と異なるタイピング特性
タブ受け入れで完成行を得ても、候補者はそれを引き出すための指示を入力するか、次の行を自力で書く必要があります。結果、キーストリームは二相になります。マシンが生成した長大なコード領域の間に、短い人間のタイピング領域が点在する形です。
キーストロークバイオメトリクスは、手入力部分にはまだ有用です。候補者の滞留時間と速度のパターンはセッション全体で一貫しているはずです。ただし比率が新しい信号になります。Cursor多用型の候補者は最終ファイルの15～25%しか手入力しません。非使用者は95%以上です。この比率はレポートに直接表示され、単一イベントの分類精度に依存しません。
この信号は不可視オーバーレイツール使用者も捕捉します。Cluelyオーバーレイから読み取ったテキストを手入力する候補者は、非常に均一な速度で、修正がほぼない形で入力します。なぜなら創作ではなく写字だからです。キーストリーム全体と最終ファイルの編集距離がほぼゼロに近づきます。本来の著作には必ずバックスペース削除、関数名の変更、失敗した試行の痕跡があります。写字にはそれがありません。
信号4：プロセスより完成度が高いコード
最終ファイルに対してコード一貫性分析を実行すると、別の次元の情報が得られます。Cursor ComposerやClaude Codeが生成するコードは非常に一貫性が高いです。用語使用に揺らぎがなく、命名規則が統一され、候補者が実際に実行しなかったエッジケースまで防御的に処理されています。これはChatGPTから断片的に貼り付けたコード（往々にして不一貫）とは別の失敗パターンです。Cursorのコードは、その過程で見える動作からはあり得ないほど洗練されています。
診断の核心はすでに一貫性判定者が問う質問です。「これは1人が、30分間で、ビデオ通話しながら、最初から最後まで書いたように見えるか？」インタビューの緊張下の人間は必ず何か粗い痕跡を残します。忘れたconsole.log、途中で名前を変えようとした関数、コードと矛盾するコメント。Cursor Composerのファイルはそうした不完全性をほぼ持ちません。その完璧さが信号なのです。
面接で質問するべきこと
検出は答えの半分です。もう半分は、AIユーザーが逃げられない質問をすることです。
- 非自明な行を指して理由を聞く。 「ここでオブジェクトではなく
Mapを使った理由は？トレードオフは何だった？」本物の著者は思考を述べます。受け入れて進むだけのユーザーは肩をすくめます。 - 小さな拡張を強制する。 「このケースをケースインセンシティブにするフラグを追加してください。」5行、AIの補助なし。候補者は流暢に書くか、詰まるか。どちらでも情報価値があります。
- 見える範囲のバグについて聞く。 プロンプトやテンプレートに意図的に軽微な問題を埋め込みます。AIツールは気づかずに「修正」する傾向があります。候補者に何をどう変えたか、なぜか説明させてください。正当なユーザーは説明します。AIユーザーはdiffを読み上げるだけです。
これらのフォローアップ質問は、AI生成コード提出時の検査と同じ道具です。ツールを「バレさせる」のではなく、候補者がその職務に必要な自分のコードとの関係を持つかを見極めることが目的です。
シグナルが明確になるようにラウンドを設計する
2つの構造的工夫ですべてが読みやすくなります。
- ラウンド開始前にルールを宣言する。 「任意のツール、Cursor、Copilot、個人スニペット、何でも使って構いません。書いたものを拡張して説明してもらいます。」これがオープンブック型で、検出問題を解釈の問題に変えます。Cursor使用を最初から宣言し、自分の仕事を説明できる候補者はOKです。隠して説明できない候補者が落選対象です。
- 最後の5分をAIなし拡張に指定する。 開始時に明示。「最後の5分は小さな拡張問題で、AIツール使用禁止」。アシスタントなしで候補者がどう入力するか観察してください。この1ブロックだけで、ラウンド全体の比較対象となるクリーンなベースラインが得られます。
この2つのルールにより、整合性レポートに固定点ができます。ないと、空白の前提条件に対してリズムを推測しています。あると、全てのインタビューに既知の基準セクションが確保されます。
次のステップ
テクニカルインタビューを実施中で、現在の整合性レポートがペーストとタブ切り替えだけを追跡している場合：
- キーストロークロギングに受け入れブロック検出を追加するか、これを組み込んでいるコーディングプラットフォームを選択してください。ないと、Cursorユーザーは完全に見えません。
- 今週、全てのライブラウンドにAIなし5分ブロックを追加してください。ほぼコストゼロで、疑わしい候補者だけでなく全員のベースラインが得られます。
- 候補者向けの指示を更新して、何が許可で何が禁止かを明記してください。多くの候補者は明確なルールを守ります。従わない少数派は必ず不自然に隠蔽します。
- タブ切り替え数への依存をやめてください。2026年の不正ツールはエディターから出る必要がありません。
エディター内AIとの軍拡競争は検出だけでは勝てません。正当な使用と非使用を区別できず、不正な使用を面接で弁明できないようなインタビュー設計でこそ勝てます。求める信号は「Cursorを使ったか」ではなく、「自分のコードが何をするか理解しているか」です。その問いを中心にラウンドを組立れば、検出問題はほぼ自動的に解決します。