「何を作ったか説明して」——2026年に増える新型面接質問への対策

まとめ： 2026年、面接官が「〜した経験を教えてください」ではなく「実際に作ったものを説明してください」と切り出すケースが増えている。背景にあるのは、AIが持ち帰り課題や暗記した行動面接の回答の信頼度を急速に下げていること——ライブでの説明はごまかしが効きにくい。STAR対策とは違う準備が必要で、「一番印象的に聞こえるプロジェクト」ではなく「フォローアップ質問に耐えられるプロジェクト」を選ぶことが鍵になる。

数週間かけて5つのSTARストーリーを磨き上げた。ところが面接官は「それはいいので、実際に作ったものを見せてください」と言い、履歴書の一行を指しながら、その中でなぜその判断をしたのかを聞き始めた。準備が語りだけで深さがなかったら、まさにこの瞬間に崩れる。

これは行動面接の言い換えではない。まったく別のフォーマットであり、特定の理由で増えている。

「〜した経験を教えてください」が通用しなくなっている理由

Karatは2026年の採用トレンドレポートのために、米国・インド・中国のエンジニアリングリーダー400人を調査した。結論は率直だ——持ち帰り課題と暗記された行動面接の回答は、AIの下でもっとも早く信頼性を失う採用シグナルだという。候補者は持ち帰り課題の文章をそのままAIに貼り付ければ、実際にどう考えたかがまったく見えないまま、動くソリューションを手に入れられる。磨き上げられたSTARストーリーも同じ手口で作れてしまう。

自分自身が作ったもののライブ説明は、その場でのアウトソースが難しい。なぜその判断をしたのか知っているか知っていないかのどちらかで、フォローアップ質問一つでその差は数秒で露呈する。Karatのリーダーたちが「ライブ面接は候補者が問題にどう取り組み、判断を下し、AIをどう使うかを観察できるためより価値が高い」と述べているのはそのためだ——ライブ面接自体が新しいわけではなく、他のあらゆる手段がノイズだらけになったからだ。

この動きは市場によって差がある。Karatのデータでは、中国企業はライブ面接中のAI利用を公然と認める割合が米国のほぼ2倍（68% 対 38%）で、持ち帰り課題への依存度もはるかに低い（20% 対 45%）——AIをワークフローに組み込むことがすでに当たり前になっている市場ほど、ライブでの実地観察へのシフトが速いことを示している。

同じロジックは実務レベルでも見られる。データ職向けの採用ガイドは今や、ライブのSQLパズルラウンドを削って、候補者が2人の面接官相手に自分の作ったものを説明し、突っ込みを受ける長めのプレゼン枠に置き換えることを公然と勧めている——ある担当者いわく、AIモデルは「同じクエリをだいたい14秒で書いてしまう」からだ。パズルはもう有効なフィルターではなくなった。ウォークスルーはまだ機能している。

日本の転職市場、特に外資系やグローバル企業のエンジニア採用では、この「作ったものを見せてください」形式がすでに登場し始めている。米国・中国発のトレンドではあるが、外資系企業のテックリード面接やプロジェクトレビュー形式の面接ラウンドで同様の質問が使われるケースが増えている。

この質問が実際に評価しているもの

「プロジェクトの見せ方」の一般的なアドバイスは、これを構造化された独り語りとして扱う——プロジェクトを要約し、障壁に触れ、成果でまとめる。しかしそれは実際に起きることの3分の1程度しかカバーしていない。

本当のテストは、冒頭の要約の後に来るフォローアップの掘り下げだ：

• 「なぜXではなくその方法を？」 — その時点でトレードオフを理解していたか、それともテンプレート・チュートリアル・同僚の指示にただ従っただけか。
• 「今作り直すなら何を変える？」 — リリース後もその問題を考え続けているか、それとも動いた瞬間にクローズしたと思っているか。
• 「実際のコストは？スケール時のパフォーマンスは？」 — 語っているストーリーではなく、自分自身の数字を把握しているか。
• 「失敗ケースを説明して」 — 語っているハッピーパスだけでなく、作ったものの限界を理解しているか。

ナラティブだけを準備していたら、これはどこにも表れない。誰かに割り込まれた瞬間に表面化する。

STAR対策とは違う準備の仕方

STAR対策はきれいな5文構成に最適化されている。ウォークスルー対策は割り込みに耐えることに最適化されている。具体的には：

1. 「一番印象的に聞こえるプロジェクト」ではなく「守り切れるプロジェクト」を選ぶ。 同僚が難しい判断をすべて下していて、その理由を再構成できない華やかな公開プロジェクトより、自分が完全に理解している地味な社内ツールの方が強い。
2. ストーリーではなく数字を完璧に覚える。 スケール・レイテンシ・ビジネス成果に触れるなら、その数字自体の根拠——出どころ、除外した範囲、変化させた要因——を問われる前提で準備する。
3. 「何をしたか」ではなく「なぜそうしたか」を練習する。 プロジェクト内の主要な判断それぞれについて、選ばなかった代替案とその理由を一文で用意しておく。ほぼ必ず最初のフォローアップになる。
4. 「今なら何を変えるか」を先回りして答える。 自分の仕事の正直な限界を一つ用意しておく。聞かれる前に自分から言えば自己認識に見え、追い込まれてから言うと言い逃れに見える。
5. 話す練習ではなく、割り込まれる練習をする。 誰かに説明の途中で鋭い質問を挟んでもらう。このフォーマットが試しているのは、予期しない切り替えの中で思考の筋道を取り戻すスキルであり、一人での通し練習では絶対に鍛えられない。

「でも自分のプロジェクトはそんなに大したものじゃない」

これは候補者フォーラムで絶えず見かける、最もよくあるパニックポイントだ。日々の業務がトラフィックの少ないメンテナンス中心で、「プロジェクト深掘り」ラウンドで見せられるスケール感やドラマ性が何もないと悩むエンジニアは多い。海外エンジニア向け掲示板r/Blindの定番スレッドの一つでは、可視性の低い社内システムについてスケールとビジネスインパクトを繰り返し聞かれたある候補者が、実物を使う代わりに「数か月かけて細部までそれっぽく作り話をしようか」と本気で悩んでいたという投稿があった。

それはやめた方がいい。面接官はプロジェクトの規模を採点しているのではなく、あなたの説明が質問に耐えられるかを採点している。あらゆる角度から守り切れる小さくて理解し尽くしたプロジェクトは、最初の「なぜ」で他人の判断を暗唱していただけだと露呈する大きなプロジェクトに勝る。本当に自分でアーキテクチャを設計していないなら、正直にそう言った上で、自分が実際に担った部分——その中で作った拡張機能、自分自身がぶつかったトレードオフ、追いかけて仕組みを理解したバグ——について話せばいい。

この段階で不合格になった候補者からの実際の報告によれば、面接官が特に見抜こうとしている失敗パターンは、「今なら何を変えるか」と聞かれた瞬間に守り切れなくなる判断を、自分がしたかのように主張してしまうことだ。守れる小さな貢献を自分のものとして語る方が、守れない大きな貢献を盛って語るより評価される。

ライブウォークスルーのシンプルな構成

フォーマットが許すなら、図・リポジトリ・簡単なスケッチなど、何か視覚的なものを画面に出しておく。そうすれば面接官が割り込むときに指させる具体物ができる。そのうえで冒頭をこう組み立てる：

1. 解決しようとしていた課題を一文で。 誰のための課題だったかも含めて。
2. アプローチを一文で。 説明ではなく判断として述べる（「YではなくXを選んだのは〜だからです」）。
3. そこで話すのをやめる。 次の5分は面接官にフォローアップで主導させる。この先も語り続けたくなる衝動は抑える——このフォーマットは面接官が舵を取るように設計されており、話しすぎるとむしろ実際に評価されている部分が遅れるだけだ。

このフォーマットで一番難しいのは、プロジェクトを知っていることではない。編集し直すチャンスが一切ない状態で、想定していなかった詳細にフォローアップが飛んできたときに冷静でいられるかどうかだ。一人でシミュレートするのは本当に難しい——まさにその瞬間のためにリアルタイム面接サポートは存在していて、答えている最中に、自分のプロジェクトの数字やタイムライン、今問われているトレードオフをさりげなく提示し、鋭いフォローアップで頭が真っ白になるのを防ぐ。

このラウンド以外でもSTARストーリーを準備しているなら、STARメソッドガイドがそちらをカバーしている。ソフトウェアエンジニア向け行動面接ガイドも合わせて読む価値がある。2026年の面接プロセスの多くは今も両方のフォーマットを連続して実施しているからだ。

FAQ

行動面接を完全に置き換えるのですか、それとも追加されるだけですか？

主に追加です。Karatの2026年のエンジニアリングリーダー調査では、ライブでの問題解決とワークサンプルの議論が、持ち帰り課題や暗記された行動面接の回答よりも信頼できるシグナルとして上位に来ていますが、STAR形式の質問を完全になくした企業はほとんどありません。現実的な対策目標は両方を含む面接プロセスであり、ウォークスルーラウンドが以前より重みを増しているという前提で準備することです。

話したいプロジェクトが、ゼロから作った印象的なものではなく、ほとんどメンテナンス業務だった場合はどうすればいいですか？

一文で一番良さそうに聞こえるプロジェクトではなく、フォローアップに答えられるプロジェクトを選んでください。地味だが完全に理解しているメンテナンスプロジェクトの方が、「なぜその方法を選んだのか」で固まってしまう華やかなプロジェクトより強いです。面接官が聞いているのは、コードベースの規模ではなく、具体的な詳細のもとであなたがどう考えるかです。

自分でアーキテクチャを設計していない場合、または今なら何を変えるか説明できる自信がない場合はどうすればいいですか？

実際に自分が担った部分を正直に話してください。設計を引き継いだのであればそう伝えた上で、自分が実際に決めた部分——どう拡張したか、その中で直面したトレードオフ、今時間があれば変えたい点——について話します。担っていなかった当事者性を主張することが、この質問が見抜こうとしている失敗パターンであり、フォローアップが守り切れない判断に触れた瞬間、たいていすぐにわかってしまいます。

ポートフォリオレビューのためにプロジェクトを練習するのと何が違うのですか？

ポートフォリオレビューは基本的に一方通行です——あなたが発表し、相手は聞き、最後に質問が一つ二つある程度です。ワークサンプルのウォークスルーは意図的に対立的に作られています——面接官は説明の途中で「なぜXではなく？」「10倍のスケールだとコストはどうなる？」「実際のデータは何を示していた？」と割り込んできます。滑らかなナレーションを練習しても割り込みへの備えにはならず、自分の思考の根拠を練習することが備えになります。

実際のデモやスライドを持参すべきですか、それとも口頭だけで説明すべきですか？

フォーマットが許すなら、指させるものを用意してください——図、リポジトリ、スクリーンショット、ビデオ通話ならナプキンに書いたスケッチでも構いません。プロダクションレベルの磨き込みが重要なのではなく、面接官がフォローアップを投げかけられる具体的な対象を与えることが重要です。これはまさにこのフォーマットが試している能力です。口頭だけの説明は、自分が守りたくない詳細をぼかしやすくしてしまいます。

---

著者 · Alex Chen。キャリアコンサルタント・元テックリクルーター。採用側で5年間働いた後、候補者を支援する側に転向。教科書的なアドバイスではなく、リアルな面接のダイナミクスについて執筆しています。