AIアシスト・コーディングインタビュー・ポリシー：設計と採点の方法
すべてのエンジニアリングチームが答える必要のある方針の問題
Metaが先陣を切りました。Shopify、Canva、Ripplingが続きます。2026年の中盤までに、テクニカルインタビュー中にAIアシスタンスを明確に許可する企業は約4社に1社となっています。採用委員会のエンジニアリングチームの関心は「ChatGPTを禁止すべきか？」から「エンジニアの90%が日々AIでコーディングしているなら、誠実なインタビューとは何か？」へシフトしています。
このブログポストは、採用面接ポリシーを一から構築する際に推奨される方針とルーブリックです。これは「何となくコーディング」を許可するものではなく、候補者が初日から使用するのと同じツールを使いながら、信頼できる判断結果を得られるインタビュー設計です。
実際に何を測定しているのかを定義する
AIをはじめて許可する際に、ほぼすべてのチームが犯す過ちはルーブリックを変更しないことです。従来の「LRUキャッシュを実装する」というプロンプトのままに、候補者にClaudeタブにアクセスさせ、全員が合格することに驚いています。
AIを許可する場合、実は「候補者がコードを書けるか」ではなく、AIでは対応できない以下の4つのことを評価しているのです。
- 問題の枠組み化。 曖昧なビジネス要件を具体的な仕様に落とし込めるか。質問者が明記していなかったエッジケースも含めて説明できるか？
- 方向付け。 何を最初に構築し、何をスキップし、いつ設計を作り直すかを判断できるか？
- 批判的検証。 AIが自信を持って間違ったコードを提示したとき、それに気づくか。代替案を求めるか、それともバグのまま出荷するか？
- 説明責任。 提出したすべてのコードを説明できるか。「AIが書いたから」は答えではありません。
ルーブリックがすべてを左右するため、問題を1つ書き始める前に、この4点を明確に記しておいてください。
AIが一度には解けないプロンプトを設計する
AI許可のプロンプトに必要な3つの特性があります。
- 意図的に不完全である。 候補者は不明な点を質問するか、仮定を明示する必要があります。制約をすべて最初に書き込んだプロンプトなら、候補者は仕様をモデルに投げ込んで終わりです。
- メインパスが作業の半分である。 もう半分は、前の仮定と矛盾する制約に対処することです。実世界のエンジニアリングはleetcode問題ではなく、相反する要件を調和させることです。
- 少なくとも1つの落とし穴がある。 見落とすと解答は正しく見えるが、ある入力では失敗する微妙な要件です。AIモデルはこうした落とし穴を見落とします。思考する人間はキャッチします。
具体例を挙げます。「レート制限を実装してください」の代わりに「この既存エンドポイントにレート制限を追加してください。プロダクトチームは不正使用に対する『適切な』保護を望んでいます。このエンドポイントはモバイルアプリと社内cronジョブの両方から呼ばれます。現在のコードは以下の通りです」と聞きます。候補者は「適切な」を定義し、cronジョブがIP単位の素朴なレート制限に引っかかることに気づき、トレードオフを説明する必要があります。AIは喜んでIP単位のレート制限を書きます。候補者がそれが間違っていると判断することが試されるのです。
LLMコピペに対抗するプロンプト設計の詳細は、LeetCodeなしで開発者を評価する方法やAIが生成したコード提出を検出するを参照してください。
実際のインタビューの進め方
ライブAIアシスト・コーディングインタビューは実際には60分間で以下のように進みます。
- 10分 — 問題の理解。 インタビュアーが問題を説明します。候補者はそれを読み、不明な点を質問し、自分の仮定を述べます。この時点ではまだコードを書きません。この部分が最もシグナルが高く、AIの影響をほぼ受けません。
- 35分 — AIを活用した実装。 候補者がコードを書き、必要に応じてAIモデルにプロンプトを送り、何をしているかを説明します。インタビュアーはAIの使い方を観察します。プロンプトに十分なコンテキストが含まれているか、出力を無批判に受け入れるか、それとも後輩とペアプログラミングするように扱うか。
- 15分 — 防御と拡張。 インタビュアーは、候補者にAIが生成した関数をウォークスルーさせ、制約を変更させ、何が壊れるかを説明させます。弱い候補者がここで崩壊する部分です。
これは強いライブコーディングインタビューと同じ構造で、1つの明確な違いがあります。AIは禁止されたデバイスではなく、候補者が「上手く使える」ことを評価されるツールという点です。
採点ルーブリック：5つの評価軸、各5点満点
すべての候補者、すべてのインタビュアーに対して同じルーブリックを使用し、各レベルに行動的な定義を持たせます。基本的な例は以下の通りです。
| 評価軸 | 評価対象 |
|---|---|
| 問題の枠組み化 | コード作成前の明確化質問と仮定の質 |
| 意思決定 | 最初に何を構築するかを正しく判断したか。行き止まりで再検討したか？ |
| AI活用力 | プロンプトは具体的でスコープが明確か。不正な出力を拒否して代案を求めるか？ |
| 批判的検証 | AIの誤りに気づくか。落とし穴のケースをテストするか？ |
| 説明責任 | すべてのコードを説明でき、変更を指示されたら対応でき、トレードオフを説明できるか？ |
各軸を1～5で採点し、行動的な定義を使用します。定義があることが雰囲気採点との違いです。ルーブリック校正をしたことがなければ、インタビューを開始する前に必ず行ってください。複数のインタビュアーによる自由形式の採点は、最も声の大きい人が採用を決めるという結果につながります。
スコアカードシステムでフォームを一度作成して使い回します。スコアカードがすべての軸に評価が入るまで提出できない仕組みになっていなければ、そういうシステムに切り替えてください。
整合性の確認：信頼するが検証する
AIを許可することは、その通話に実際にいる人が採用される候補者本人であることを盲目的に信頼することを意味しません。2つの具体的なリスクが残っています。
- なりすまし。 別の人がキーボードを操作していたり、カメラの外で候補者に指示を与えていたりする。
- カンニング。 候補者が別のデバイスからフレーミング言語や「意図的に作成していない」明確化質問を受け取っている。
これらのリスクはAIポリシーとは無関係です。リモートインタビュー全般に存在する課題です。ClarityHireの整合性検証レイヤーはこうした世界のために設計されています。AIが許可されているなら、AIを使ったからといって候補者にフラグを立てません。同じ人がずっとキー入力していること、顔が身分証と一致していること、成果物がインタビュー中に観察された実装と一致していることを検証します。キー入力生体認証と顔検証は、候補者がClaudeを使おうが使うまいが、なりすましをキャッチします。
AIが許可されたインタビューを実施している場合、整合性レポートはAI使用の有無ではなく、誰がその仕事をしたのかを報告すべきです。
次のステップ
既存のインタビューループをAI許可に切り替える場合は、この順序で進めてください。
- 1つのプロンプトを不完全に指定し、隠れた制約を含めるよう書き直します。候補者に見せる前に、2人の社内エンジニアでパイロットします。
- 従来の「コーディング正確性」ルーブリックを上記の5軸ルーブリックに置き換えます。行動的な例を使ってすべてのレベルを定義します。
- 本番運用前に、記録されたセッションで3人のインタビュアーを校正します。
- AI許可ポリシーとは別に整合性ポリシーを決定します。これらは異なる問題です。
- 10回のインタビュー後、スコア分布を確認してドリフトをチェックします。全員がAI活用力で4点を取得しているなら、定義が甘すぎます。
この取り組みを上手くやっているチームは、最も厳しいポリシーのチームではありません。採点テクニックではなく判断を測定するルーブリックを持つチームです。