AIアシスト型コーディングスキルを測定するエンジニア面接の実施方法

誰も評価していないスキル

2026年の中盤までに、ほとんどのエンジニアは日々の仕事の一部でAIアシスタントを使用しています。面接で答えるべき質問は「AIなしでコーディングできるか」ではありません。それは仮定の話です。本当に問うべきは「この候補者はAIを使って、隣のエンジニアより速く、かつ安全に成果物をリリースできるか」ということです。

これは異なるスキルであり、異なる面接形式が必要です。AI使用禁止というルールが隠されたテイクホーム課題では測定できません。LeetCodeスクリーンでも測定できません。オープンブック形式の多くでさえ、AIを強力な検索エンジンのように使うだけで候補者が通過できます。以下は、AIの使いこなしを直接測定し、見た目の良さを報酬としない面接ラウンドを設計するための実践的ガイドです。

AIの使いこなしとは何か

有能なエンジニアがアシスタントを1時間使う様子を観察してください。以下の5つのことをしているのが見えるでしょう。

1. 解法ではなく制約を中心にプロンプトを組み立てる。 コードが何をしなければならないか、何をしてはいけないかをモデルに伝え、繰り返し改善します。
2. 自信を持って拒否する。 モデルがAPIバージョンの間違い、存在しないライブラリの提案、脆弱なパターンなど、微妙に間違ったものを提案したとき、彼らは数秒で気づいて方向性を修正します。
3. 退屈な部分にアシスタントを最も活用する。 ボイラープレート、テストスキャフォルディング、フォーマット変換など、高いレバレッジのある使い方です。負荷のかかるロジックは自分で書くか、モデルに厳密な仕様を要求します。
4. 信頼する前に検証する。 コードを実行し、差分を読み、エッジケースを確認します。感覚で本番コミットしません。
5. 使用をやめるタイミングを知っている。 モデルが堂々巡りしているときは、考えることとコード読解に戻ります。

弱いAIユーザーはその逆をします。漠然とした質問をし、長い生成結果を批判的に検討せず、モデルにソリューションの構築を任せ、動作するものなら何でもリリースします。面接の役割はこの二つを区別することです。

シグナルが浮かぶ問題形式

問題の形状は具体的な内容より重要です。以下の特性を持つものを選んでください。

• 素朴なAIの答えが微妙に間違っている。 引っかけではなく、候補者が気づかなければならない実際の制約です。よくあるバージョンは、モデルの学習データが古い、最近のまたは珍しいAPIを実装するよう求めることです。
• 問題はAI未使用の候補者には完了できず、かつAI頼みの候補者は一度で解けない程度の複雑さがある。 この2つのアプローチを両立させることが求められます。
• 受け入れ基準が明確である。 「素敵なものを作ってください」ではなく、候補者が検証できる明確なマストハーブです。
• 仕様に意図的な曖昧性がある。 合理的なエンジニアなら質問して解決するか、仮定を述べるでしょう。弱いAIユーザーは仕様をモデルに貼り付けて、戻ってきたものをリリースします。

実際の例：「注文のCSVを読み込み、顧客ごとの月ごとの合計を計算し、JSONを出力する小さなコマンドを構築してください。2つの曖昧性があります。注文のタイムゾーン、および払い戻め行への対処方法です。60分間。任意のツールを使用できます。」

ライブで実施し、非同期ではなく

純粋な非同期テイクホーム課題はこの2つのプロフィールを区別できません。成果物はどちらの場合も同じに見えます。これを画面共有またはコラボレーティブエディタを使った60～75分のライブコーディングセッションとして実施し、AIの使用を明確に許可してください。

事前に発表するルール：

• どのAIツールでも公正です。どのツールを使ったか教えてください。
• AIの使用で減点することはありません。どのように使うか掘り下げます。
• AIが提供したものについて掘り下げます。保持する内容について説明できるように準備してください。

このフレーミングは候補者を守勢から実演的な姿勢に変えます。有能な候補者は積極的に取り組みます。弱い候補者は緊張します。彼らのワークフローは精査に耐えられないからです。

セッション中にリアルタイムで観察すること

セッション中の5つの具体的なシグナル：

• プロンプト品質。 制約、例、望ましい出力の形状を説明しているか。それとも仕様を貼り付けて期待しているか。
• 拒否率。 どのくらいの頻度で生成結果を破棄するか。有能なエンジニアは少なくとも何度か拒否します。時には黙って、時には声に出して。すべてを保持するエンジニアはリリースするコードを読んでいません。
• AIを使わない部分。 重要なロジックは自分で書いているか。それとも正確さを決定する部分をアシスタントに任せているか。
• 検証の習慣。 実際の入力でコードを実行するか。受け入れる前に差分を読むか。エッジケースを見るか。
• 回復。 モデルが堂々巡りするとき、一歩下がって考えるか、プロンプトを続けるか。

60分の窓で、成果物だけでなくキーストロークを監視すれば、これらは観察可能です。ClarityHireのコラボレーティブエディタは、貼り付けイベントを入力から分離してタグ付けしたセッション全体を記録します。ウォークスルー中に候補者と特定の選択を再検討する際に便利です。

スコアリングルーブリック

5つの次元、それぞれ1～4のスコア。デブリーフ前にスコアリング：

各項目を独立してスコアリングしてください。ClarityHireの構造化面接スコアカードはこれらをロックして、レビュアーが成果物を見た後にドリフトできないようにします。

セッション後のウォークスルー

最後の15分を3つの質問に費やしてください：

1. 「拒否した生成結果を見せてください。なぜですか？」
2. 「このコードで自分で書いた部分を説明してください。AIに任せなかった理由は？」
3. 「リリースしたコードで最も脆い部分は何ですか？次に何を修正しますか？」

セッション中に実際に考えたことがある候補者は、躊躇なくこれらに答えられます。モデルが生成したものをすべて受け入れた候補者はできません。そしてそのギャップは各答えの最初の10秒で明らかになります。これはテイクホーム課題に適用する同じ著者性テストであり、ライブAI使用に適用されます。

採用フロー内での位置づけ

この質問形式を、標準的なライブコーディング画面の追加ではなく、替わりとして扱ってください。採用フローには依然としてシステムデザインラウンドと行動ラウンドを含める必要があります。この質問が答えるのは、従来はクローズドブック型コーディング画面で処理されていた質問であり、LLM時代ではほとんどのシグナルを失っています。

次に何をするか

次のAI許可型ラウンドの前に3つの具体的なステップを実行してください：

1. 1つのロールを選んで、ライブコーディング質問を書き直す AIが一度で解けない、でもAI未使用の候補者は完了できないものにします。
2. インタビュアーをトレーニングして、成果物ではなくワークフローをスコアリングさせる。 成果物は最低条件です。ワークフローがシグナルです。
3. 候補者到着前に「検証」の意味を決定する。 ルーブリックを事前にロックすることで、キャリブレーションを台無しにする事後的な合理化を防ぎます。

2026年にこれを正しくやったチームは、モデルが部屋にいないふりをするチームより採用で勝ります。このスキルは本当です。強力なユーザーと弱いユーザーの間のギャップは非常に大きいです。そしてこれを測定する面接形式は、それが置き換わるものと同じくらい実施するのが難しくありません。