AI時代の技術面接

• AIツールがコード作成やレビューの領域にまで急速に浸透する状況では、面接でのAI使用は原則として排除し、基礎能力を中心に評価すべき
• 良い面接は シグナル品質（signal quality） と 企業コスト（cost to company） の二軸で評価され、この2要素は完全に独立しているわけではない
• 面接の種類は Take-home、Live exercise、Presentation、Actual work の4つに分けられ、それぞれシグナル品質とコストが異なる
• AIコーディング によって take-home は簡単すぎるものになり、レビュー負担が増し、流出した問題でも AI が強力なコーチ役を果たす
• AI熟練度は instrumental skill（道具的スキル） に過ぎないため、企業は foundational skill（基礎能力） の評価に集中すべき

---

核心的な主張

• AIモデルとツールの急速な進化の中で、エンジニアが6か月後もコードを書き、レビューしているのかという疑問が生まれ、核心的な技術が消えるなら 面接方式も進化すべきなのか という問いから出発する
• 大半の企業は現状維持を選んでおり、この革命を主導する企業も含まれる
  • Anthropic の採用ガイドラインでは、take-home は「別途指示がない限り Claude なしで」完了するよう求めている
• 一部企業は AI 使用を許可・推奨・必須化しており、AI熟練度そのものが面接のテーマ になることもある
• 結論として 面接ではAIを一般的に排除すべきであり、面接を AI に合わせて調整する具体的方法を提示する

良い面接の2つの次元

• シグナル品質（Signal quality）

  • 与えられた能力セットに対して強い候補者を識別し、ノイズ（役割の本質ではない、あるいは容易に教えられる要素）を無視する能力
  • 面接特化の準備への耐性（Invulnerability to preparation）: 成果が準備量や努力に左右されるなら、その特性に対するシグナルしか得られない
  • 現実性（Realism）: 面接は日常業務に似ているべきだが、それ自体が目的ではない。「algorithm & data structure」面接は実務で直接使われないにもかかわらず長く生き残ってきた
  • 平等性（Equality）: 事前のドメイン専門性、有料メンタリング、時間的余裕、オンライン流出問題、最近経験した知人などにより、一部候補者が有利になる。理想的には全員に公平な環境が必要
  • 難易度（Difficulty）: 良い面接は多くの人が失敗するほど十分に難しい。最善なのは 複数の洞察を必要とする広範で曖昧な問題

• 企業コスト（Cost to company）

  • 面接問題には相当な時間投資が必要: 草案設計と試験的承認、職種・レベル別スコアカード作成、社内外候補者でのテスト、面接官向け文書化と教育
  • 問題とスコアカードは継続的に補正されるため、投資も継続して必要
  • 難易度（Difficulty）: 問題作成自体も難しいが、十分に難しい問題を作るのはさらに大きな挑戦。簡単すぎても難しすぎても、どちらも時間の無駄
  • 候補者への魅力（Appeal to candidate）: 時間がかかりすぎる手順や退屈な問題は優秀なエンジニアを遠ざけ、転換率を下げる。問題はエンジニアリング文化を示す
• この2つの次元は完全に独立しているわけではなく、たとえば難易度は双方に影響する。難しい面接は強い候補者を際立たせる一方で、false negative（誤った不採用） を生みうる
• 面接は完璧である必要はなく、false negative と false positive は常に存在する。false negative の特定は難しいが、良いオンボーディングと明確な最初の学期のマイルストーンにより、false positive は素早く整理できる

面接タイプの分類

• Take-home

  • 候補者が (1) 曖昧な問題（例: プロダクト仕様）に対する解決策を、(2) いくつかの技術的制約（例: プログラミング言語の一覧）を守って提出する
  • しばしば候補者が作業を発表し、その場で修正する review 面接 へ続く
  • シグナル品質: （AI以前は）高い — 設計・コーディング・細部・テストなど幅広いシグナルを提供し、6時間以上の投入は動機の証明にもなる
  • 企業コスト: 中程度 — 評価の自動化が可能で、成果物（コード）を非同期でレビューできるが、候補者を離脱させる可能性もある
  • AIと動機の強い個人に非常に脆弱

• Live exercise

  • algorithm & datastructure、live coding、system design、postmortem review などで、通常は1時間以上。「Netflix のアーキテクチャを設計する」「rate-limiter を書く」といった問題を面接官の前で即興で解く
  • シグナル品質: 中程度 — 適切に設計・進行されれば客観的だが、シグナルは通常1つのテーマに集中する
  • 企業コスト: 中程度 — 候補者の準備への耐性を高めるには、多様な問題を多数用意する必要がある
  • コスト削減のため、一部企業は自動化サービスを利用する

• Presentation

  • 「主導したプロジェクトの説明」「アーキテクチャ図」「〜した経験」などで、候補者が問題と答えを自ら選ぶ
  • シグナル品質: 低い — 失敗パターンが多い
    • 興味深い問題を扱った経験がない（例: ジュニア）、退屈な問題を選ぶ、影響や貢献を誇張する、発表準備が不足している、強いコミュニケーターだが実行者ではない、面接官のドメイン知識不足により不正確な評価になる
  • 企業コスト: 低い — 補正の観点で大きな準備は不要
  • 「違うやり方をするなら?」のような振り返り質問や、「要件 X を変えたら?」のような仮説質問で低いシグナル品質を緩和でき、この場合は未補正の live exercise に近づく。より多くの面接官の努力と専門性が求められる

• Actual work（面接タイプではない）

  • 1週間の有給で一緒に働く方式。Linear のような企業が採用している
  • シグナル品質: 高い / 企業コスト: 高い
• 大半の企業はこれらを組み合わせており、Live exercise が優勢

問題流出は時間の問題（AIとは無関係）

• 問題流出は時間の問題であり、Glassdoor のようなサイトが面接の秘密をすべて並べる。一部候補者は問題を売るために面接を受けることさえある
• 無視するとシグナルが弱まり、面接成果の主要因が「自社の面接プロセスを調べたかどうか」に変質する

• 対応戦術

  • 準備の統制（Control the preparation）: presentation を構成に含めたり、精密なガイドを提供したりして（例: 「システム設計はデータベース中心」「アルゴリズムはグラフ」）、公平な環境を作る
  • タイプ別の問題多様化: 古い問題を定期的に保管（archive）する。候補者が問題を正確に予測できなければ、準備範囲を広げなければならず、それが目的。ただし無料ではない
  • 流出難易度を上げる（Make it harder to leak）: オンサイト実施、ホワイトボード利用、最も脆弱な問題をプロセス後半に配置する（候補者数が少ないため流出確率が下がる）

AIコーディングが現在の面接モデルを脅かす

• (1) Take-home は候補者にとって簡単すぎ、企業にとって高すぎるものになる

  • 2026年には大半の提出物が AI 生成または AI 支援になる可能性が高く、現在は耐えている課題でも次のモデルリリースで解かれるのは時間の問題
  • 結果として大半の候補者が最初の段階を通過するため、レビューに多くの時間がかかる。AI が生成した提出物を AI でレビューするのは不合理
  • AIコーディングは面接コストを被面接者から面接官へ移す
    • Brandolini の法則の引用: 悪いコードを反駁するのに必要なエネルギーは、それを作るのに必要なエネルギーより1桁大きい

• (2) コードを書く時間が減るなら、live-coding の比重を下げるのが自然

  • 機械語を書かず高級言語を使うように、面接で許可するツールも日常業務に合わせるのが合理的だという見方

• (3) 問題が流出すると AI は強力なコーチになる

  • 以前は問題を見つけて準備するのに時間と資源が多く必要だったが、今では AI により最も強力で安価な支援を得られる

古典的な学校評価モデルが技術に抵抗してきた方法

• フランスの高校・大学試験は概して同じ形を保っている
  • 資料（講義・本など）の持ち込み不可、道具（特に電卓）はほぼ不許可、事前に内容は非公開、予測不可能（各試験は異なり1回限り）、広範で曖昧な問題
  • フランス文学試験の精髄は dissertation で、1文のテーマから5〜10ページのエッセイを書く形式で、1830年から存在する。科学系試験も曖昧な問題3〜4問を解く類似の形式
• take-home、客観式知識問題、グループ課題、発表など他の評価形式で補完されるが、例外に過ぎず原則ではない
• 分類の再適用
  • シグナル品質: 高い — 準備空間が非常に広く、継続的努力が必要
  • コスト: 非常に高い — 試験ごとに新しいテーマと採点ガイドを設計し、全候補者が同時に同じ試験を受ける（企業面接ではまったく非現実的）
• 興味深いのは、コピー＆ペースト、インターネット、電卓、ソルバーなど認知ツールが飛躍的に発展しても、このモデルは大きく変わらなかったこと
  • 教育はその時々のツールではなく 基礎能力 に集中すべきであり、これは記憶（mneme）より判断（phronesis）に焦点を当てるアリストテレス的モデルと一致する

企業が面接中のAI使用を制限すべき理由

• 基礎能力 vs 道具的能力の区別

  • Foundational traits & skills は、構築が難しい、あるいはコストの高い能力・態度・習慣
    • 根源的な知的能力、長年の学習で得られた深い専門性（毎秒数百万リクエストの分散システム、数百のマイクロサービスをモノリスへ移行することなど）、二次的推論、職業倫理・integrity・回復力のような徳目
    • 問題を識別・抽象化・解決させる内在化された知識（fundamentals）であり、さらに多くの技術を積み上げる土台を提供する。「賢いから自力でやるだろう」と言わせるもの
  • Instrumental skills は、安価または短時間で伸ばせる
    • プログラミング言語の中級熟練、テキストエディタの適切な使用、文書検索、AIプロンプトの調整
  • 面接では、複数の道具的スキルのシグナルを通じて、候補者の基礎的特性（生産性への投資意欲、構造的学習）を検証することが多い

• Rationale 1: AI熟練度は基礎能力ではない

  • エンジニアリングツールは継続的に進化してきたが、面接は概して同じままだった（low-code の面接タイプはなく、システム設計も大半が基本的・非マネージド技術を使う）
    • 最高の企業は単一ツールの熟練度を求めず、LLM の台頭により Expert Generalist の重要性はさらに増している
  • プログラミング言語の専門性が面接でそれほど重視されない理由も同じ。言語は問題解決という上位目的のための道具にすぎない
  • AI使用も同様で、prompt/context engineering、MCP/skills の定義、multi-agent workflow、harness engineering など繊細な技術は必要だが、これは道具的スキルであり、コード作成・レビュー・拡張可能なアーキテクチャ設計に必要な 同じ基礎能力 を要求する
  • 企業が採用するのは頭脳であって、AIエージェントに漫然と指示を入力する手ではない
  • レビューと生産は表裏一体であり、コード・アーキテクチャ・分析のレビューには、作成・設計・分析と似た能力が必要。ビジネス要件の生成と検証には人間が必要なので、コードレビューはすぐには消えない（十分に詳細な仕様はすなわちコードである）

• Rationale 2: AIは基礎的特性・能力を隠してしまう

  • Peter Drucker の引用: 手だけを雇うことはできず、人間全体が一緒にやって来る
  • Lewis Mumford の区別を活用 — tool（人間の労働者が主導） vs machine（独自の論理で動作し、agency を持つ）。AI使用が過剰になると、エンジニア固有の貢献と AI モデルの貢献を区別するのはほぼ不可能
  • AIを「tool」ではなく「machine」のように使うエンジニアには警戒すべき。AIは強力な自動補完を超える生産性の飛躍であり、思考の大部分を外部化できる。「taste」のような人間固有領域も脅かされ、Fitts' list さえ古びて見える
  • Derrida が分析した Plato の pharmakon のように、AI は治療薬（反復的リファクタリングの自動化、ライブラリの特異点学習時間の節約）であると同時に毒（基礎能力萎縮の危険）でもある
  • AIを過度に重視する面接は、人間ではなく モデル（"machine"）を評価 する危険がある。人間の推論を面接のテーマとして強調する課題設計が必要

• Rationale 3: AIは進化が速すぎる

  • Arthur Mensch（Mistral CEO）によれば、AIモデルは12か月ごとに約1年分のソフトウェアエンジニアリング経験を獲得する。AIエージェントをインターンにたとえる冗談は、もはや聞かれない
  • 大半の企業には、基礎能力を強制する AI 耐性のある問題を継続的に生成・維持する余力がない。モデルが毎月進化し、すべてのモデルにアクセスできるわけでもない状況で、最強モデルに抵抗し続ける問題を作るのは 負け戦
    • Anthropic の「Designing AI resistant technical evaluations」は、候補者ではなく AI と「戦う」ケーススタディ
  • より難しい take-home を作ることは、電卓を許可しながらより難しい暗算問題を出すのに似ている
  • AIのベストプラクティスも毎月進化し、モデルが指示理解に長けるにつれて prompt engineering の重要性は下がる。候補者が最新手法を知っているかどうかは有用なシグナルではない
  • 一方で fundamentals は定義上変わらない

反論への回答

• データがないという指摘 について: (1) 統計的有意性を持つ本当の実験（ランダム化比較試験）はほぼ不可能であり、それが生む false negative を受け入れる企業はない (2) 大半の面接設計の意思決定は、臨床試験的実験ではなく抽象的推論に基づいている
• AIによる不正行為（例: 面接中）: 明示的に禁止しているなら、AIツールの使用は即時不採用事由
  • Warren Buffett の引用: 採用では integrity、intelligence、energy を見るが、integrity がなければ残り2つが人を壊す。integrity のない人を採るなら、むしろ愚かで怠惰であってほしいと思うようになる
• AIで候補者を評価すべきか: だめ。 (1) 倫理的に誤り — 知識労働者である人間を採用するのに、機械がすべてを評価することはできない (2) AI評価は非決定的で幻覚でも知られており、結局 AI の評価を再レビューしなければならない

企業への具体的提言

• 大半の面接でAI使用を許可しないこと。特定ツールを過度に強調せず、基礎能力に集中する
• Live exercise に投資すること。偽物・退屈・低シグナルである必要はなく、短い必要もない。data structure & algorithm 面接を見直すこと — 今でも最も知的に挑戦的である。人間の努力を必要とする課題を設計し、単一問題への過剰準備を防ぐため多くの問題を保有する
• 面接タイプを混ぜる ことで、コスト効率よく幅広いシグナルを確保する
• Take-home を調整する こと。AI使用を明示的に禁止するか、許可するなら AI 生成物のレビューに時間を無駄にしないこと。take-home は必ずそれに基づく live exercise へつなげ、候補者が作業の発表、トレードオフへのアプローチ、要件変更、拡張性などを説明するようにする
• レビュー能力を評価する面接を最低1つ 設けること。作成コストが低く、興味深いシグナルを与え、候補者の負担も少ない。例: AI計画、postmortem、既存コードベース（Bug squash）、プロダクト要件文書、トレードオフ分析、システムアーキテクチャレビュー
• 候補者をオンサイトに呼ぶことを検討。不正を防ぐ最も単純な方法であり、問題流出もやや難しくする。ただし RTO（オフィス復帰）企業に限る
• 明確な面接準備ガイドを提供 して公平な環境を作る

[roxie]

私にとっては、1週間一緒に働くのに良さそうです

[linusjeh]

という文章もAIで書いたんだろうね（笑）

[jjpark78]

どうせ業務ではAIを使うのに、それを排除することに意味があるのかなと思います。むしろリモート面接をやめて現地のみで実施し、その場でどうAIを使い、どう考えるのかを、よく設計された質問とモニタリングで判断するほうが、AI時代にはより合っているのではないでしょうか?

同じ問題でも、どういうプロンプトを送るかを見れば、その人について多くのことが分かりますよね。