本文へ移動

ホーム / ML / 第6部 面接の実践

第6部 面接の実践・第12章

面接の全体像と答え方

★★☆ 重要5トピック・面接 4問

ML エンジニアの面接の流れと、技術質問への答え方の型、面接官の評価軸、準備の優先順位を押さえる。

12.1面接の典型的な流れ

用語★★☆ 重要
ひとことで

理論の理解・実装力・本番での運用経験・ビジネスへの貢献が見られる。

ML エンジニアの面接では、理論の理解・実装力・本番での運用経験・ビジネスへの貢献の4つが見られます。会社によって、研究寄りなら理論、サービスの会社なら運用と貢献の比重が大きくなります。

段階内容準備
カジュアル面談仕事の内容と経歴のすり合わせ経歴を2分で話せるように
技術面接(基礎)ML の基礎・評価・リーク・深層学習・LLM の質問各章の「面接ではこう答える」を声に出す
コーディング・実技アルゴリズム・pandas や SQL での前処理・指標の実装手で書いて時間を測る
ML システム設計推薦・不正検知・RAG などを 45〜60分で設計答え方の型と回答例を2〜3題
経験・行動プロジェクトの深掘り・失敗・対立STAR のエピソードを5〜8本
最終面接志望動機・キャリア・カルチャーの相性逆質問を用意
面接の種類よく聞かれる質問
ML の基礎過学習をどう防ぐか・不均衡なデータの指標・リークの例・勾配ブースティングとニューラルネットの使い分け・Transformer の仕組み
コーディングアルゴリズムの問題、データの前処理を pandas や SQL で書く、簡単なモデルや評価指標を実装する
ML システム設計おすすめ・検索・不正検知・RAG を使った質問応答を設計する(次の項目)
経験・行動一番成果が出たプロジェクト・失敗したモデル・オフラインでは良かったのに本番で効かなかった経験・意見が対立したとき

面接ではこう答える

ML エンジニアの面接は、多くの場合、ML の基礎の技術面接、コーディング、ML システム設計、経験の深掘り、の組み合わせです。見られているのは、理論の理解、実装力、本番での運用経験、ビジネスへの貢献の4つで、研究寄りの会社では理論、サービスの会社では運用と貢献の比重が大きくなります。応募先がどちらに近いかを求人票や記事から読み取り、準備の配分を決めます。

「知っている」だけでなく「使える」ことが伝わる順番1. 結論一言で2. 仕組みなぜそうなるか3. 注意点弱点・使い分け4. 実体験自分がどう使ったか4段目の実体験があるかどうかで、評価が大きく変わる
技術質問は4段で答える
段内容例(「過学習をどう防ぎますか」)
1. 結論一言で答える検証データで見つけ、データを増やす・正則化・早期終了で防ぎます
2. 仕組みなぜそうなるか学習データの癖まで覚えると、学習の誤差は下がるのに検証の誤差が上がるからです
3. 注意点弱点や使い分け検証データで選びすぎると検証データにも過学習するので、テストは最後に1回だけ使います
4. 実体験自分がどう使ったか以前、木の深さを下げて早期終了を入れ、検証の AUC の低下を止めました(数字を添える)

分からない質問は、知っている近い話から「〜だと考えます」と推論を口に出し、確かでないことは確かでないと言います。黙り込むより評価されます。

評価軸高評価の振る舞い低評価の振る舞い
基礎の理解指標・過学習・リークを自分の言葉で説明できる用語の定義を暗記で答えるだけ
評価の設計指標・分け方・基準(ベースライン)を自分から決める精度の数字だけを示す
本番の感覚レイテンシ・費用・監視・戻し方まで話すモデルの精度の話で終わる
ビジネスへのつなぎモデルの指標とビジネスの指標の関係を説明できる「AUC が上がりました」で終わる
トレードオフ「A を選ぶと B を失う」を理由つきで話す流行の手法の名前を並べる
当事者意識自分が何を判断し、何をしたかを具体的に話す「チームで」ばかりで自分の役割が見えない
準備期間優先すること
1週間経験のエピソード(STAR)を5本・自己紹介・志望動機。ML の基礎の頻出(指標・過学習・リーク)を声に出す
2〜4週間上に加えて、ML システム設計の型と回答例を2〜3題。LLM(RAG・評価)と推論・監視の頻出を復習
1〜2か月上に加えて、コーディング(アルゴリズム・pandas・SQL)を毎日。深層学習・GPU・MLOps の深掘りに備える

どの期間でも、自分の経験を数字つきで話せるようにすることが最優先です。知識の質問も、最後は「実際にどうしたか」で差がつきます。

論文・コンペの経験の話し方:論文やコンペ(Kaggle など)の実績は強みになりますが、「順位」や「手法の名前」だけで終わらせないようにします。

  • 何が効いたか、なぜ効いたと考えたかを話す(特徴量・検証の仕方・データの理解)。試してだめだったことも話すと、考え方が伝わります。
  • コンペと実務の違いを分かっていることを示す:実務では、課題と指標を自分で決める、データを集める、推論の速さ・費用・保守のしやすさも大事、精度 0.1% のためにモデルを10個混ぜることは少ない、など。
  • 論文は、そのアイデアを一言で説明し、自分の仕事のどんな問題に使えそうかまでつなげます。
  • チームでの仕事なら、自分が担当した部分をはっきり言います。

この章のまとめ

🖨 まとめシート(印刷・PDF)
  • 面接官は「知っているか」より「本番で正しく判断できるか」を見ている
  • 技術質問は 結論 → 仕組み → 注意点 → 実体験 の4段で答える
  • 準備時間が少ないほど、経験エピソードの整理を最優先にする

この章のクイズ

面接ではこう聞かれる

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1作ったモデルでビジネスにどんな成果が出ましたか?

模範回答

例えば次のように答えます(内容と数字は架空の例です)。「解約の予測モデルを作り、解約しそうなお客様に担当者が先に連絡する仕組みに組み込みました。成果は A/B テストで測り、モデルの上位の人に連絡した群と、これまでのルールで選んだ群を比べて、3か月の解約率が 2ポイント下がりました。月に換算すると約〇〇万円の売上を守った計算です。」のように、モデルの指標ではなくビジネスの指標と金額で話します。

大事なのは、モデル以外の要因と切り分けたことを説明することです。同じ時期にキャンペーンや季節の変化があっても、ランダムに分けた対照群と比べたので、差はモデルによるものだと言えます。A/B テストができなかった場合は、前後の比較だけでは他の要因が混ざることを認めたうえで、似た条件の群と比べるなどの工夫をしたと話します。自分の担当した範囲と、うまくいかなかった点も添えると信頼されます。

深掘りされたら

  • A/B テストができない状況では、効果をどう見積もりましたか?

見られているポイント指標と、モデル以外の要因の切り分け

Q2不正検知のシステムを設計してください。

模範回答

まず前提をそろえます。何の不正か(決済・アカウントの乗っ取り)、判定までに許される時間(決済なら数百 ms 以内)、見逃しと誤検知のどちらが重いかです。指標は、不正が少ない不均衡なデータなので、適合率・再現率・PR-AUC と、防いだ損失の金額、誤って止めた正常な取引の数を見ます。

データは過去の取引で、正解はチャージバックなどで数週間後に分かります。特徴量は、利用者の過去の行動との違い・直近の回数(5分間に何回か)・端末や場所です。モデルは勾配ブースティングから始め、オンラインで判定し、スコアで「通す・追加の確認・止める」に分けます。手口が変わる(コンセプトドリフト)ので、正解が遅れて届く前提で監視し、定期的に再学習します。判定の結果がラベルに影響する偏りにも触れます。

深掘りされたら

  • 止めた取引は本当に不正だったか分からなくなります。どう扱いますか?

見られているポイント要件と指標の確認・遅れて届く正解・ドリフト・判定の段階分け

Q3社内文書に答えるチャットボットを設計してください。

模範回答

まず、誰が何を聞くか、答えの正確さがどれくらい重要か、文書の量と更新の頻度、権限の違いを確かめます。構成は RAG にします。文書を見出しで分割して埋め込み、ベクトル検索とキーワード検索を組み合わせ、再ランキングした上位を LLM に渡し、引用元を付けて答えさせます。

重要なのは権限で、利用者が見られない文書は検索の段階で除きます。評価は、実際の質問から評価データを作り、検索(正しい文書が上位にあるか)と生成(文書に沿って正しく答えたか)を分けて測り、変更のたびに流します。運用では、利用者の評価ボタンと失敗例の収集、文書の更新の自動取り込み、トークンの費用の監視を入れます。

深掘りされたら

  • 答えが間違っていたと利用者から報告がありました。どう調べますか?

見られているポイントRAG の構成・権限・検索と生成を分けた評価・運用

Q4一番苦労した ML のプロジェクトについて教えてください。

模範回答

例えば、次のような話し方をします(架空の例)。「需要予測のモデルで、オフラインの誤差は改善したのに、在庫の担当者に使われませんでした。話を聞くと、予測が毎日大きく変わるので信用できず、理由も分からないことが原因でした。」

「そこで、精度の指標に加えて予測の安定性も評価に入れ、特徴量の寄与を画面に出して、担当者と週に1回結果を見直す場を作りました。精度はわずかに下がりましたが、使われる割合が上がり、欠品が減りました。」のように、課題・自分の判断・結果・学んだこと(モデルの精度だけでなく、使われ方まで設計する)の順で話します。

深掘りされたら

  • そのとき、ほかに考えた選択肢は何でしたか?

見られているポイント課題・判断の理由・結果・学びを順に話す