コーディングインタビューでAIコラボレーションスキルを評価する方法
スキルとしてのAI使用
この2年間、採用面接におけるAI使用は主に対策すべき行為でした。評価基準は「候補者がAIを使ったか、そしてそれを検出できたか」という単純なものでした。その視点はAI使用禁止のラウンドでも今なお有効で、そこで不正使用を検出する完全性レイヤーは実質的に重要な役割を果たします。
しかし同じ採用ループの中で、AI使用が必須となるラウンドを導入する企業が増えています。Meta、Canva、Shopify、Coinbaseといった大手企業は、AIとの協働能力を採点基準に明示的に組み込んでいます。あなたの採用ループもその方向に向かっているなら、ルーブリックが必要です。なぜなら、「どんなツールでも使ってください」と候補者に伝えておきながら、最終的なコードが動作しているかだけで採点すれば、実質的には何も測定できていないからです。コードが動作するのはAIの成果です。スキルは候補者がそこに加える価値にあるのです。
この記事は、AIとの協働を前提としたラウンドを設計する採用マネージャーを対象としています。採点する価値がある4つの観点、その観点を引き出す試験形式、そしてシグナルを減弱させてしまいがちな面接官の典型的な誤りについて解説します。
採点するべき4つの観点
効果的なAIコラボレーション・ルーブリックは、45分間の面接で観察可能で、かつAIを上手に使いこなしている技術者と単にそのアウトプットをコピーするだけの技術者を区別するスキルをテストします。以下の4つの観点があり、各レベルに具体的な指標があります。
1. プロンプトの質と問題分解
優れた候補者はモデルに「この機能を作ってくれ」と丸投げしません。まず問題を自分で分解してから、必要な部分についてプロンプトを送ります。優秀な技術者の最初のプロンプトは、よく定義されたチケットのような形をしています。一方、経験不足の技術者のプロンプトは、元の問題文そのままに見えます。
確認すべきポイント：
- プロンプトを送る前に、問題を自分の言葉で言い直したか
- モデルに対して制約を与えたか（ファイルパス、関数シグネチャ、データの形状、期待される出力例など）
- 1つずつ明確に指示したのか、それとも問題全体をペーストして結果を期待したのか
目安として、候補者がプロンプト文に書いたトークン数とAIが生成したコード行数の比率が参考になります。この比率が低すぎれば、候補者はモデルをブラックボックスとして扱い、入力内容に対して判断を働かせていない可能性があります。
2. 検証とスケプティシズム
この観点が強い候補者と弱い候補者を最も明確に分ける傾向があります。モデルがアウトプットを生成します。候補者はそれをどう扱うでしょうか。
最も強いシグナルは、候補者が統合する前にコードを検証するかどうかです。具体的な行動：
- 生成されたコードを行ごとに読んでからコピーペーストする
- 候補者自身が構築したテストケース（モデルが提案したものではない）で実行する
- ハルシネーション（AI生成の幻覚）で生じた関数やライブラリを検出し、再度プロンプトするか自分で修正する
- アウトプットは一見正しく見えるが、エッジケースで失敗することに気付く
最も弱い行動は「ペーストして祈る」です。候補者はAIのコードをエディタにコピーして、ハッピーパス（正常系）だけを実行し、成功を確認して先に進みます。これはAIコラボレーションにおいて、ジュニア技術者がdiffを読まずにマージするのと全く同じです。
非同期評価でLLM生成コードにフラグを立てるために使用されるコード一貫性分析を活用してください。AI必須のラウンドでは、採点対象は「候補者がAIを使ったか」ではなく（それは想定内です）、「候補者がAIアウトプットに加えた編集が、コードを読んで考えた形跡を示しているか、それとも単なるコピー・ペーストか」です。
3. ループの支配権
経験浅い候補者はAIの提案に従うままです。優秀な候補者はAIをリードします。
採点の対象となる具体的な行動：
- モデルが誤った答えを返したとき、候補者は問題を診断して修正された条件でプロンプトを再送するのか、それともただ再生成を繰り返して違う答えを期待するのか
- モデルが候補者が異なるアーキテクチャを提案したとき、候補者は異議を唱えるのか（「ここはステートマシンを使いたいんだけど、そのパターンでやり直してくれ」）、それとも提案を受け入れるのか
- モデルが脱線して、候補者が要求していないリファクタリングを始めたとき、候補者はそれに気付いて軌道修正するのか
この観点はスクリーン記録がなければ見えません。プロンプト履歴とエディタのdiffが一緒にキャプチャされていることを確認してください。最終的なコードだけでなく、その過程全体が大切です。
4. AIペアリング中のコミュニケーション
最後の観点は、候補者が面接官をプロセスに巻き込むかどうかです。柔らかく聞こえるかもしれませんが、これは実務でAIと協働するチームの中でその候補者がどう働くかを最も予測させる要素です。
良い例：
- プロンプトを送る前に説明する：「Claudeにパーサーのドラフトを頼むつもりです。トークナイザーの部分は正しく処理すると思いますが、エスケープ文字は多分対応漏れが出るので、その後自分で修正する必要があると思います」
- 送信前にプロンプトを面接官に見せる
- モデルとの意見の相違を無言で隠さず、声に出して伝える
- コード説明時に「ここは自分が書いた部分」「ここはAIが生成した部分」を明確に区別する
弱い例：無言でプロンプトを送信する、モデルのアウトプットを読みながら長い沈黙（その間、何を考えているか一言も説明しない）、エディタに現れるコードについて説明がない。AIと無言で作業する候補者は、人間のチームメンバーとも無言で作業します。これは採用ループで確認したい組織的なシグナルです。
これらのスキルを引き出す試験形式
アルゴリズム問題を与えてAI使用を許可するという誘惑に駆られるかもしれません。それはしないでください。AIが数秒で解くので、候補者は40分間コメント編集をしているだけになります。何も学べません。
より優れた試験には3つの特性があります：
- 複数ステップと組み込みのサプライズ。 候補者が明確に解ける小さなタスクから始めます。途中で、前提を崩すような変更要件を導入します。新しいデータ形式、パフォーマンス要件の厳格化、非推奨ライブラリへの対応など。適応がAIコラボレーション能力を最も顕著に示します。
- 微妙な初期バグを含むコード。 コンパイルして実行されるが、微妙なバグを含むコードを与えます。オフバイワンエラー、例外処理の欠陥、負荷下でのレース条件など。候補者が自力でそれを見つけるのか、AIに見つけさせるのかを観察します。ほとんどのモデルは、明示的に指示されなければ微妙なバグには気付きません。
- ドキュメントやリサーチの要素。 タスクに、候補者が馴染みのないライブラリやAPIとの統合が含まれている。モデルはそれについて知識がある。候補者は、モデルの説明が実際のドキュメントと一致しているか検証する必要がある。「モデルが主張していること」と「ドキュメントに書いてあること」のギャップは、豊かなシグナルをもたらします。
試験全体は45分。ClarityHireの協働コードエディタはMonacoでコードを統合実行し、プロンプト履歴キャプチャと組み合わせています。面接官はデブリーフ時に、最終コードだけでなく、エディタのdiffとモデルとの対話を並べて確認できます。
採点基準、1～4
各観点を1～4スケールで独立して採点します。各レベルを形容詞ではなく、具体的な行動に根付かせます。
プロンプトの質（1～4）:
- 1: 問題文全体をモデルにペーストする。分解なし。
- 2: 機能全体をリクエストするが、最低1つは制約を加える。
- 3: タスクを2～3つに分解し、関連するコンテキストを含めて個別にプロンプトを送る。
- 4: 関数シグネチャ、データ形状、動作例を含む、スコープが明確に定義されたプロンプトを書く。
検証（1～4）:
- 1: モデルのアウトプットを読まずにペーストする。
- 2: アウトプットは読むが、ハッピーパス（正常系）のみテストする。
- 3: モデルの提案に依存しない独自のテストケースを最低1つ構築し、最低1つの問題を検出する。
- 4: あらゆるアウトプットを疑わしいものとして扱う。統合前に、実際のドキュメント、実際のテストデータ、エッジケースに対して検証する。
支配権（1～4）:
- 1: モデルが生成したものに従う。失敗時に修正プロンプトではなく再生成を繰り返す。
- 2: 失敗後に同じコンテキストでプロンプトを再送する。時々、モデルが脱線していることに気付く。
- 3: モデルが誤った理由を診断し、修正した条件でプロンプトを再送する。
- 4: アーキテクチャは自分で決める。戦術的なタスクにモデルを使う。モデルが異なる設計を提案したら異議を唱える。
コミュニケーション（1～4）:
- 1: 無言でプロンプトを送信する。エディタに現れるコードについて説明がない。
- 2: 最終結果は説明するが、プロセスは説明しない。
- 3: プロンプト送信前に説明し、プロンプトを面接官に見せる。
- 4: 自分の貢献とモデルの貢献を明確に区別する。モデルとの不一致を声に出して示す。
構造化スコアカードを使用してください。各面接官がデブリーフ前にスコアをロックします。4つの観点は十分に独立しているため、面接官間の不一致も有益です。1人の面接官が検証を4、コミュニケーションを2と評価するかもしれません。その差異こそが議論する価値があるのです。
よくある面接官の誤り
このラウンドのシグナルを弱めてしまう5つのエラー：
- 最終コードを採点する。 コードはAIのものです。判断、プロンプト、編集は候補者のものです。そちらを採点しましょう。
- 「AIが何をしたのか説明してください」と聞く。 これはAIとの協働をテストするのではなく、読解力をテストしているだけです。代わりに「AIのアプローチについて、あなたならどう変えますか？」と聞いてください。
- ラウンドを無言のままにしておく。 候補者がモデルのアウトプットを読むときに2分間沈黙しているなら、促してください。「いま見ている部分について、どう思いますか？」沈黙はテストではなく、ペアプログラミング能力を測定しているのです。
- モデルが一撃で解ける問題を選ぶ。 些細な問題では、候補者は支配権、検証、回復のいずれかを実証する必要がない。モデルとの意見相違が最低1回は発生する問題を選んでください。
- 完全性ベースラインを忘れる。 これはAI必須ラウンドですが、AI禁止ラウンドと同じ採用ループの一部です。この候補者のキーストロークパターンがAI禁止ラウンドと同じに見えるなら、それは注目に値します。肯定的な理由（候補者が本当にそう入力する）も否定的な理由（画面外の助言者が両ラウンドを担当している）も考えられます。
次のステップ
AI協働ラウンドを採用ループに加えようとしているなら：
- 4つの観点のうち、当該職種にとって最も重要なものを決める。応用ML技術者なら検証を最優先するかもしれませんし、一般的なソフトウェアエンジニアならコミュニケーションを重視するかもしれません。
- 途中のサプライズと微妙な初期バグを含む試験を1つ設計する。最初の候補者が見る前に採点基準を書き込みます。
- エディタのdiffと一緒にプロンプト履歴をキャプチャする。プロンプトがなければ、あなたはコードを採点しています。プロンプトがあれば、エンジニアを採点できます。
- 記録済みセッションで2人の面接官と調整する。面接官間の不一致こそがルーブリックの品質を示します。
- このラウンドをAI禁止ラウンドとは独立して採点する。異なる能力を測定するもので、混ぜると不適切な候補者を評価してしまいます。
このラウンドの目標は、AIを使える候補者を見つけることではありません。ほぼ全ての候補者ができます。大切なのは、判断力、検証能力、リーダーシップが十分に優れていて、AIのレバレッジが実現し、高くつく「ペーストして祈る」に陥らない候補者を見つけることです。