ライブコーディング面接とは、候補者が面接時間内にリアルタイムでコードを書き、思考プロセスを見せる選考手法だ。エンジニア採用支援の実務では、レジュメや筆記テストでは見えない「実際の開発力」を可視化するために多くの現場で導入されている。テイクホーム課題より候補者負担が低く、従来の技術質問より採用精度が高い—この2点が急速に普及した理由だ。

TL;DR（この記事の要約）

• ライブコーディング面接は候補者の思考プロセス・問題解決の進め方をリアルタイムで評価できる選考手法。コーディング試験とは異なり「考え方のプロセス」を見るのが目的

• ペアプログラミング面接との最大の差は「面接官の関与度」—ペアプロは同僚として一緒に書き、コミュニケーション力も同時評価

• 実技系手法はレジュメ評価より採用予測妥当性が約4倍高い（Schmidt & Hunter メタ分析より）

• 課題の難易度設定・評価ルーブリックの標準化が評価ブレ防止の鍵。面接官任せにしない

• AI時代にはコードの暗記力ではなく、AI出力を検証・改善する力を測る設計へのアップデートが必要

• 90日ロードマップで設計→パイロット→本番導入を段階的に進めると失敗が少ない

このページでわかること

• ライブコーディング面接とペアプログラミング面接の違いと使い分け基準

• 「良い課題」の5条件と課題設計の4ステップ

• 評価ルーブリックの作り方と合否ラインの設定方法

• 面接官の役割設計とトレーニングの進め方

• AI時代に対応した出題・評価の再設計（AI利用許可設計）

• リモート環境での実施方法とツール選定比較

• 導入を成功させる90日ロードマップ

• よくある失敗パターンと具体的な対策

1. なぜ今「実技系面接」が注目されているのか

エンジニア採用の選考手法は、ここ数年で大きく変化している。従来主流だった「経歴の確認＋技術質問」だけでは、候補者の実務能力を正確に測れないという課題がある。レジュメ上のスキルセットと実際のコーディング力が一致しないケースは多い。GitHubのOSSコントリビューションが豊富でも、チーム開発のコミュニケーションに課題があるエンジニアもいれば、経歴は地味でもペアプロさせると抜群のパフォーマンスを発揮する人材もいる。

統計データ：実技系面接の採用予測妥当性

産業心理学の主要メタ分析（Schmidt & Hunter, Journal of Applied Psychology, 1998・209研究・32,124件のデータ収録）によると、ワークサンプルテスト（ライブコーディング面接はこの一形態）の採用予測妥当性はr=0.54。従来の非構造化面接（r=0.14）と比較すると約3.9倍高く、学歴・経歴評価（r=0.10）とは5倍以上の差がある。採用ミスマッチを減らしたいなら、実技系手法の導入は最も費用対効果の高い選択肢の一つだ。

テイクホーム課題（持ち帰り型）は候補者の負担が大きく、複数社を並行して受けているエンジニアは「課題に8時間かけてください」と言われた時点で離脱してしまう。面接時間内に完結し、かつ実務に近い能力を評価できる手法として、ライブコーディング面接・ペアプログラミング面接の導入が広がっている。

実技系面接のメリット・リスク

主なメリット:

• 思考プロセスが見える：正解にたどり着くまでの過程を観察でき、「考え方」を評価できる

• コミュニケーション力の評価：技術的な議論・質問の仕方・説明能力がリアルタイムで分かる

• カルチャーフィットの判断材料：一緒に働いたときのイメージが湧きやすい

• 候補者側の負担軽減：面接時間内で完結するため、テイクホーム課題より拘束時間が短い

主なリスク（対策可能）:

• 緊張によるパフォーマンス低下で実力が測れない→ウォームアップ設計と冒頭の声かけで軽減

• 面接官のスキルによって評価の質が大きくブレる→ルーブリックとトレーニングで標準化

• 設計が甘いと「コードを書かせるだけの場」になる→良い課題の5条件を満たす設計で防止

2. ライブコーディング面接とペアプロの違い・使い分け

混同されやすいこの2つの手法は、面接官の関与度と評価ポイントが異なる。

ライブコーディング面接の特徴

候補者が1人でコードを書き、面接官はその過程を観察する。必要に応じて質問やヒントを出す形式だ。

評価の重点: 独力での問題分解力・コード品質（可読性・命名・構造化）・デバッグ力・制限時間内のタイムマネジメント

向いているケース: ジュニア〜ミドルレベルの技術力を客観的に測りたい、アルゴリズムやデータ構造の基礎力を確認したい、選考の初期フェーズで足切り的に使いたい

ペアプログラミング面接の特徴

面接官と候補者が一緒にコードを書く。面接官は「同僚」として振る舞い、相互にコミュニケーションを取りながら課題を進める。

評価の重点: 協働・コミュニケーション力・他者の意見を取り入れる柔軟性・技術的な議論・提案力

向いているケース: チームワーク重視の開発組織、ミドル〜シニアレベルのエンジニア選考、候補者体験を重視したい場合

使い分け早見表

実際には両方を選考フローに組み込む企業も多い。1次選考でライブコーディング（基礎力確認）→ 2次選考でペアプログラミング（協働力確認）というフローは効果的だ。選考フロー全体の設計については「エンジニア採用の選考フロー設計完全ガイド」を参照してほしい。

3. 課題設計の具体的な手順

面接の成否を分けるのは課題の質だ。課題設計を適当にやると、評価の精度が下がるだけでなく、候補者に「この会社の技術力は大したことない」という印象を与えてしまう。

良い課題の5つの条件

1. 実務に近い

競技プログラミングのような問題ではなく、日常の開発業務に近い課題を出す。API設計、データ変換、小規模なリファクタリングなど。採用ポジションの実際の開発業務から課題を抽象化するのが理想だ。

2. 段階的に深められる

基本実装→機能拡張→エッジケース対応、のように段階的に難易度を上げられる設計にする。候補者のレベルに応じて到達点が変わるため、ジュニアからシニアまで同じ課題で評価できる。

3. 制限時間内に完了可能

基本実装が制限時間の50〜60%で完了できる難易度に設定する。残りの時間で発展的な議論ができる余裕を持たせる。「課題を終わらせること」ではなく「思考プロセスを見ること」が目的だと念頭に置く。

4. 特定の技術に依存しすぎない

「Reactの特定のフックの使い方を知っているか」ではなく、「状態管理の考え方を理解しているか」を測れる課題にする。ただし、採用ポジションが特定技術を前提とする場合は例外。

5. 正解が1つではない

複数のアプローチが可能な課題にすることで、候補者の設計判断力を評価できる。一つの最適解しかない課題は「知識テスト」になってしまう。

課題設計の4ステップ

Step 1: 評価したい能力を明確にする

まず「この面接で何を測りたいのか」を定義する。1つの課題で測る能力は2〜3個に絞る。欲張って全部を1つの課題で測ろうとしないこと。

Step 2: 課題のプロトタイプを作る

社内のエンジニアに実際に解いてもらい、以下を検証する：想定時間内に基本実装が完了するか、複数のアプローチが可能か、課題文の解釈にブレがないか。最低3人のエンジニアにテストしてもらい、全員が制限時間の60%以内に基本部分を完了できることを確認する。

Step 3: ルーブリックを同時に作る

課題とセットで評価基準を作る。これを後回しにすると、面接官ごとの「なんとなくの印象」で合否が決まってしまう。

Step 4: 半年に1回課題を更新する

同じ課題を長期間使い続けると、口コミサイトやSNSで課題内容が流出するリスクがある。課題の核となるスキル評価ポイントは変えず、ドメインや具体的な要件を変えるだけでも十分に流出対策になる。

職種別の課題例

バックエンド: 「ユーザーの注文履歴を取得するAPIを設計・実装してください。入力はユーザーIDで、直近30日分の注文をページネーション付きで返してください」→ 発展: ページネーション設計・キャッシュ戦略・スケーラビリティ

フロントエンド: 「この検索フォームコンポーネントは動作するが、状態管理が複雑になっている。リファクタリングしてください」（動くが改善の余地があるコードを事前準備）→ 発展: カスタムフックへの切り出し・アクセシビリティ改善・パフォーマンス最適化

インフラ・SRE: 「本番環境でAPIのレスポンスタイムが急激に悪化しているアラートが出ました。以下のメトリクスとログを見て、原因を特定し対策を提案してください」（ダッシュボード・ログのスクリーンショットを事前準備）→ 発展: 短期応急対応・根本原因解消・モニタリング設計

4. 評価ルーブリックの作り方と合否ライン

「なんとなく良かった」「コミュニケーションが上手だった」では、再現性のある採用判断にならない。ルーブリックを使って評価を言語化・数値化する。

主要評価軸と4段階基準（ペアプログラミング面接）

問題分解力: 4=適切なサイズに分解し優先順位をつけて取り組める / 3=段階的に進められる / 2=分解しようとするが手順が不明確 / 1=問題全体に一度に取り組もうとし行き詰まる

コミュニケーション: 4=考えを自発的に言語化し建設的な議論ができる / 3=聞かれれば説明でき、フィードバックを取り入れられる / 2=説明が少なく、面接官が引き出す必要がある / 1=無言でコーディングを続け、対話がほぼ成立しない

コード品質: 4=命名・構造が明確でエッジケースも考慮。レビュー不要なレベル / 3=読みやすく基本的な設計原則を守っている / 2=動くが可読性・構造に改善の余地が多い / 1=動かないか著しく可読性が低い

設計判断: 4=トレードオフを理解した上で選択し理由を明確に説明できる / 3=合理的な設計を選び、聞かれれば理由を説明できる / 2=選択理由が不明確 / 1=意思決定ができない

AIコラボレーション力（2026年必須追加項目）: 4=AIの出力を批判的に検証し改善提案を自ら行える / 3=AIの出力を理解し必要に応じて修正できる / 2=AIの出力をそのまま受け入れがちで検証が不十分 / 1=AIの出力に依存し正しさの判断ができない

合否ラインの定義

このように4段階の判定を事前に定義しておくことで、合議の際の「なんとなく通す・落とす」を防げる。

ルーブリック運用の3ルール

1. 面接直後にスコアリングする: 記憶が鮮明なうちに採点する。他の面接官と合議する前に、まず個人の評価を確定させること。先にスコアを出してから議論することで、声の大きい人に引っ張られるのを防げる

2. スコアには必ず根拠メモを添える: 「コミュニケーション: 3」だけでなく「ハッシュマップの選択理由を聞いた際に、時間計算量の観点から論理的に説明できた」のように具体的な場面を記録する

3. 四半期に1回キャリブレーションを行う: 面接官全員で過去の評価事例を振り返り、スコアの基準がズレていないか確認する

5. AI時代のライブコーディング面接再設計

GitHub CopilotやCursorといったAIコーディングアシスタントの普及により、実技系面接の前提が変わりつつある。

測るべき能力のシフト

AIコラボレーション力: AIが生成したコードの正しさを検証できるか、AIへの指示（プロンプト）を適切に設計できるか、AIの出力を元に良い設計へ改善できるか

メタ認知力: 「何が分からないか」を特定し適切な情報源（AI含む）にアクセスできるか、複数のアプローチの中からトレードオフを評価して選択できるか、自分の判断の根拠を言語化しチームメンバーに共有できるか

システム思考: 個々のコードではなくシステム全体の設計を俯瞰できるか、非機能要件（パフォーマンス、セキュリティ、保守性）を考慮した判断ができるか

AI活用面接の3フェーズ構成

1. フェーズ1（10分）: 分析・構想: AIなしで問題を分析させ、アプローチを口頭で説明してもらう。要件の確認・整理・仮説設定のプロセスを観察する

2. フェーズ2（25分）: 実装: AIツールを使いながら実装。AIへの指示の出し方、出力の検証方法、修正の判断をリアルタイムで観察する

3. フェーズ3（10分）: レビュー・議論: 「AIが提案したコードで変更した箇所とその理由は？」「このコードの弱点はどこか？」を議論

面接中のAI利用を禁止するのではなく、むしろ許可してその使い方を評価する設計が増えている。「AIが出力したコードをそのまま使いますか？それとも修正しますか？修正するならどこを、なぜ？」—この問いかけが、候補者の技術的な判断力を最も鮮明に浮き彫りにする。

AI時代の課題設計のポイント

単純なアルゴリズム問題はAIに聞けばすぐに答えが出る。代わりに、以下のような課題が有効だ。

• 自社ドメイン固有の課題: 公開情報にない文脈理解が必要で、AIだけでは解けない

• 要件が曖昧な課題: 候補者自身が要件を整理する必要があり、コミュニケーション力が問われる

• 既存コードのリファクタリング: AIは「何を改善すべきか」の優先順位づけが苦手で、判断力が問われる

• 複数制約のあるトレードオフ課題: スピード・可読性・安全性などのバランス判断を求める

6. リモート環境での実施とツール選定

リモートでの実技系面接は対面とは異なるチャレンジがある。適切なツール選定と運用設計が重要だ。

ツール比較

リモート実施の3原則

1. 事前の環境確認: 面接前日までに候補者へ推奨環境（ブラウザ、回線速度）を案内し、ツールの接続テストを実施する。「本番直前に初めてツールを触る」状態は候補者のパフォーマンスを下げる

2. コミュニケーションの補完: 表情やジェスチャーが読み取りにくいため、面接官は意識的に声に出してリアクションする。カメラオンを推奨（表情が見えることで心理的安全性が高まる）

3. トラブル対応手順の明確化: ネットワーク障害時に電話切り替えるか・時間延長するか等のリカバリー手順を事前に決め、候補者にも伝えておく

7. 候補者体験を高める運用の工夫

実技系面接は候補者にとってストレスが高い。運用次第で「この会社で働きたい」にも「二度と受けたくない」にもなる。

面接前の準備で差がつく

面接の3〜5営業日前に、以下を候補者に伝える：面接の形式・使用する言語・環境・面接の流れとおおよその時間配分・評価の観点（「コードの完成度ではなく、思考プロセスを重視します」等）・使用するツールのURL・AIツールの利用可否。

「何を評価されるか分からない」状態が最も候補者のストレスを高める。事前に透明にすることで、候補者は実力を出しやすくなり、結果として正確な評価につながる。

面接中の工夫

ウォームアップの時間を設ける: 面接開始直後に本題に入るのではなく5分程度を設ける。面接官の自己紹介・面接の進め方の説明・「完成しなくても全く問題ありません。どう考えたかを教えてください」というメッセージ—これだけで候補者の緊張が大幅に和らぐ。

困っているときのサポート: 候補者が5分以上詰まっている場合はヒントを出す。ヒントを出したこと自体は減点にしない。ヒントを受けてどう動いたかを評価する。

タイムキープの声かけ: 「あと15分です」「基本部分はここまでで大丈夫です。残りの時間で設計の議論をしましょう」等、適切にタイムキープの情報を伝える。

8. 導入を成功させる90日ロードマップ

実技系面接をゼロから導入する場合の目安スケジュールを示す。

フェーズ1（Day 1〜30）：設計

• 現在の選考フローを棚卸しし、実技系面接を挿入するポイントを決定

• ペアプログラミングとライブコーディングのどちらを（またはどちらも）導入するか決定

• 課題のプロトタイプを2〜3パターン作成、評価ルーブリックのドラフト作成

• 面接官候補（3〜5名）の選定

• 使用するツールの選定・契約

フェーズ2（Day 31〜60）：パイロット

• 社内エンジニアを候補者役にした模擬面接を各面接官2〜3回実施

• 模擬面接のフィードバックを基に課題とルーブリックを修正

• 面接官向けマニュアル（進行台本・ヒントの出し方・評価の記入方法）を整備

• リモート実施の場合、ツールの動作検証

• AI利用を許可する場合のガイドライン策定

フェーズ3（Day 61〜90）：本番導入

• 実際の候補者で本番実施開始

• 最初の5〜10件は面接後にベテラン面接官と振り返りを行う

• 候補者にアンケートを送り面接体験のフィードバックを収集

• 課題・ルーブリック・運用フローの微調整

• 定量データの収集開始（選考精度・辞退率・候補者満足度）

90日あればチーム全体で運用を回せるレベルに到達できる。完璧を目指すのではなく、まず小さく始めて改善を繰り返すのがポイントだ。

よくある失敗パターンと対策

実際の採用支援現場で繰り返し見かける失敗を整理する。

失敗1: 課題が難しすぎる

ほとんどの候補者が基本実装すら完了できない。合格率が極端に低い。→ 社内で中堅レベルのエンジニア3人に解いてもらい、全員が制限時間の60%以内に基本実装を完了できるか検証する。できなければ課題の難易度を下げる。

失敗2: 面接官が「試験官」になっている

面接官が腕組みをして無言で観察。候補者が萎縮してパフォーマンスが出ない。→ 面接の冒頭5分のスクリプトを用意し「一緒にコードを書く場です」というメッセージを徹底する。面接官のトレーニングで「候補者役」を経験させ、試される側の心理を理解させる。

失敗3: ルーブリックが形骸化している

ルーブリックは作ったが実際の評価は「なんとなくの印象」で決まっている。→ 面接直後に個別でスコアリングを完了させてから合議に入るルールを徹底する。四半期ごとのキャリブレーション会議で過去の評価を振り返る。

失敗4: 課題が流出している

候補者が明らかに準備してきた解答をそのまま書いている。→ 課題を3〜5パターン用意してローテーションする。課題の核心は同じでも、ドメインや要件を変えるだけで十分に流出対策になる。

失敗5: AI利用ルールが曖昧

面接官ごとに対応がバラバラ。ある面接官はAI利用を許可し、別の面接官は禁止している。→「AIは利用可能。ただしAIが出力したコードの検証プロセスを評価する」等の統一ルールを文書化し全面接官に周知する。

FAQ（よくある質問）

Q1. ライブコーディング面接とペアプログラミング面接、どちらから導入すべき？

導入のハードルが低いのはライブコーディング面接です。面接官が観察中心なので技術力要件が比較的低く、トレーニング期間も短くて済みます。まずライブコーディングから始めて、運用が安定したらペアプログラミングの導入を検討するのがおすすめです。

Q2. 候補者にコーディング言語を自由に選ばせるべき？

基本的には候補者が最も得意な言語で受けてもらうのが正確な能力評価につながります。ただし採用ポジションが特定の言語を前提とする場合は、その言語を指定しても問題ありません。指定する場合は事前にその旨を伝えてください。

Q3. 面接中にAIツールの使用を許可すべき？

許可を推奨します。実際の業務でAIツールを使うのであれば面接でも同様の環境を用意するのが合理的です。「AIが生成したコードをそのまま使ったのか、検証・修正したのか」は必ず確認しましょう。

Q4. 候補者がほとんどコードを書けなかった場合、どう終了する？

残り時間を設計の議論に切り替えます。「コードは一旦置いて、この課題をどう設計するか口頭で話しましょう」と提案し、技術的な思考力を別の角度から評価します。面接時間いっぱいまで沈黙が続く状況は候補者にとっても面接官にとっても苦痛なので、柔軟に対応してください。

Q5. 実技系面接で不合格にした候補者からクレームが来ることはある？

稀にありますが、事前に評価基準を透明にし、面接後に簡単なフィードバックを返すことで大幅に軽減できます。「何で不合格になったか分からない」状態が最もクレームにつながりやすいです。

Q6. 面接の録画は行うべき？

振り返りや面接官のトレーニングに非常に有効です。ただし必ず候補者の同意を得て「評価の公平性担保と面接官のトレーニングのために録画させてください」と目的を明示します。

Q7. 面接官は何人で実施するのが適切？

1対1（面接官1人、候補者1人）が基本です。ペアプログラミング面接は1対1が原則です。ライブコーディング面接では面接官2人（1人がリード、1人がオブザーバー）とするケースもありますが、候補者の緊張を考慮すると1対1のほうが候補者体験は良くなります。

Q8. 実技系面接の所要時間はどのくらいが適切？

ライブコーディングは45〜60分、ペアプログラミングは60〜90分が目安です。このうち冒頭5分はウォームアップ、最後10分は質疑応答に充てるため、実際のコーディング時間は30〜70分程度になります。候補者の集中力を考えると90分を超える面接は避けるべきです。

Q9. テイクホーム課題と実技系面接のどちらが優れている？

一概にどちらが優れているとは言えません。テイクホーム課題は「まとまった時間をかけた成果物の品質」を測れますが、拘束時間が長く辞退率が上がるデメリットがあります。実技系面接は「リアルタイムの思考プロセスと協働力」を測れますが、緊張で実力を出せないリスクがあります。両方を選考の異なるフェーズで組み合わせるか、候補者が選べるようにするのも有効な選択肢です。

Q10. 新卒エンジニアの選考にも使える？

使えます。ただし難易度を調整する必要があります。「設計力」より「基礎的なプログラミング力」と「学習意欲」を重視した課題設計にし、基本的なデータ構造の操作や簡単なバグ修正タスクから段階的に発展させる形式が効果的です。

まとめ：実技系面接は「採用力」そのもの

ライブコーディング面接とペアプログラミング面接は、導入に手間がかかる。課題の設計、ルーブリックの作成、面接官のトレーニング—一朝一夕にはいかない。しかし、この投資は確実にリターンを生む。

1. 採用精度の向上: レジュメだけでは見えない実力を評価でき、ミスマッチが減る。産業心理学のメタ分析が示す通り、実技系手法の採用予測妥当性は従来の面接の約4倍

2. 候補者体験の向上: 「この会社は技術を大切にしている」というメッセージを面接体験で伝えられる。採用ブランドへの投資になる

3. 面接官の成長: 評価力の向上はチーム内のコードレビューやフィードバック文化の改善にもつながる

4. AI時代への適応: コード暗記ではなく、思考力・判断力・協働力を測る設計に移行することで、これからの時代に求められる人材を見極められる

まず1つのポジションの選考に1つの課題を用意するところから始めれば、90日後にはチームの「標準的な選考プロセス」として定着できる。

エンジニア採用の選考設計でお困りの方は、techcellarの採用支援サービスもぜひご活用ください。スカウト運用だけでなく、選考プロセス全体の設計支援も行っています。