機械学習エンジニア転職の面接、実装力不足で落ちる理由

提出したノートブックに戻ってきたレビューコメントは、たった一行でした。「このコードは、このままでは本番環境で動きません」——博士課程で画像認識を研究していた候補者が、ある事業会社のコーディング課題で受け取った評価です。

IT・Web業界で800名以上の転職支援に携わる中、機械学習エンジニアの選考で面接官のフィードバックを見ていると、研究実績も学位も申し分ないのに「実装力」の一点で不合格になるケースが繰り返し出てきます。今回は、なぜ研究出身者ほどこの壁にぶつかりやすいのか、その構造と、研究経験を実装力として面接で伝え直す具体的な言い換え方を、実例を交えてお伝えします。

目次

1. 機械学習エンジニア転職の面接で、なぜ実装力が最初に問われるのか
2. 研究寄りの組織とプロダクト寄りの組織、採用基準の分かれ目
3. 論文コードとプロダクションコード、前提がそもそも違う
4. Kさんが受け取った一行のレビューコメント
5. 面接で実装力を見極めるために聞かれる質問
6. 「精度」と「保守性」は別の評価軸だという話
7. 研究経験を実装力として翻訳する、面接での言い換え例
8. 職務経歴書でも同じ翻訳をする
9. コーディングテスト、研究出身者が意外と苦戦する形式
10. ポートフォリオ・GitHubで実装力を示す作り方
11. MLOps・本番運用の経験不足をどう埋めるか
12. よくある質問に答えます
13. 修士・博士で実務未経験でも応募していいですか
14. Kaggleでの実績は面接でどこまで評価されますか
15. 研究職からMLエンジニアへの転職で年収は下がりますか
16. 指導教員の研究室の実績しかない場合、職務経歴書に何を書けばいいですか
17. まとめ、実装力は「経験の有無」ではなく「翻訳の有無」で決まる

機械学習エンジニア転職の面接で、なぜ実装力が最初に問われるのか

機械学習エンジニアの求人市場は、数字の上では明らかに拡大しています。AIエンジニアの平均年収は629万円前後(厚生労働省「job tag」、2025年9月時点)で、国税庁の調査にある給与所得者の平均(478万円)より3割以上高く、IT・通信分野の求人倍率は3.35倍(doda、2025年度)、AI関連の求人数は2017年度比で約6.6倍に増えている(インディードリクルートパートナーズ、2025年7月)というデータが集計されています(出典：AI Japan Index「AI人材需給ギャップマップ2026」)。

ただ、この数字だけを見て「学位と研究実績があれば通る」と考えると、面接で足元をすくわれます。私が面接官から聞くフィードバックの多くは、研究内容そのものへの評価ではなく、コーディング課題やペアプログラミングで提出されたコードの中身に向けられているからです。

一次面接(現場のMLエンジニアが担当することが多い)は研究内容のディスカッションで盛り上がり、手応えを感じて帰ってくる候補者は少なくありません。ところが二次面接や技術課題の段階で急に評価が落ち、理由を聞くと「実装力に不安がある」という一言で片づけられてしまう。求められているのは、アルゴリズムを理解している人ではなく、動くシステムを保守できる人だという需要のシフトが、この落差の背景にあります。

研究寄りの組織とプロダクト寄りの組織、採用基準の分かれ目

もう一つ、応募前に見落とされがちな視点があります。機械学習エンジニアという同じ肩書きでも、募集している組織が「研究寄り」か「プロダクト寄り」かで、面接で重視される軸がまったく違うということです。

大手のAI研究所や大学発スタートアップの研究開発部門は、新規性のあるアルゴリズムを世に出すことがミッションで、実験計画力や論文執筆力が評価の中心になります。一方、SaaS企業やEC企業のMLチームは、既存の研究成果を安定して事業に組み込むことがミッションで、実装力と運用力が最優先されます。求人票の「業務内容」欄が「新規アルゴリズムの研究開発」なのか「既存サービスへのモデル組み込み・改善」なのかを見分けるだけで、面接対策の重心はかなり変わります。

私が見てきた限り、研究出身者が実装力で落ちる相談の大半は、研究寄りの組織を想定した準備のまま、プロダクト寄りの組織に応募してしまっているケースです。求人票の業務内容を先に読み分けることが、実装力を鍛える以前の対策として効きます。

論文コードとプロダクションコード、前提がそもそも違う

研究出身者が実装力を証明できないのは、能力が足りないからではありません。論文用のコードとプロダクションのコードは、書く目的が根本的に違うからです。

論文のコードは「この手法でこの精度が出た」を一度だけ再現できれば役目を終えます。実行するのは自分自身か、せいぜい査読者。入力データの形式は自分が決められるので、想定外の値が来ることを前提にしていません。パスはベタ書き、乱数シードは固定、実験が失敗したら手元でやり直せばいい——この前提のもとでは、例外処理やテストコードは合理的にすら見えます。

一方、プロダクションのコードは「自分以外の誰かが半年後に読んでも動く」ことが前提です。想定外の入力、依存パッケージのバージョンアップ、深夜のバッチ処理の失敗、チームメンバーによるレビューと変更——これらすべてに耐える設計が求められます。私が面接官から実際に聞く指摘には、次のようなものがあります。

こうした指摘は、精度やアルゴリズムの選択とは別の軸で評価されているという点が重要です。「書けるかどうか」ではなく「渡せるかどうか」が見られている、と考えるとしっくりきます。

Kさんが受け取った一行のレビューコメント

Kさん(33歳・工学博士、大学の特任研究員を2年経験)は、画像認識分野で査読付き論文の採録実績もある候補者でした。EC企業のレコメンドチームのMLエンジニア職に応募し、一次面接では研究内容のディスカッションで面接官と大いに盛り上がったと、私に嬉しそうに報告してくれました。

ところが二次面接の前に課された持ち帰りのコーディング課題——レコメンドモデルを日次で再学習するバッチ処理の実装——で状況が変わります。提出されたコードは、研究で使っていたノートブックをほぼそのままコピーしたようなもので、ハイパーパラメータはベタ書き、例外処理は一つもなく、関数は1つの巨大なセルにまとまっていました。返ってきたのは、冒頭で紹介した一行のレビューコメントです。

Kさんは私に「研究内容自体は評価されていたはずなのに、なぜ実装で落ちるのか納得がいかない」と話しました。実際にコードを一緒に見てみると、直すべき点は3つに整理できました。関数を機能単位に分割して型ヒントとdocstringをつける、pytestで最低限の単体テストを3件書きモデルの入出力形状を検証する、READMEに「なぜこの設計にしたか」と「本番投入するなら何が足りないか」まで書く——この3点です。

コードだけでなく、面接での話し方も変えました。詳しくは後述しますが、研究の実績を「精度がどれだけ上がったか」ではなく「その精度をどう再現可能な形で運用に耐える仕組みにしたか」で語り直したところ、別のシリーズBスタートアップのMLエンジニア職で二次面接を通過し、内定を得ています。Kさんの場合、コードの書き直しよりも、面接での言葉の選び方を変えたことのほうが効いた実感があります。

面白いのは、Kさんが振り返って「一番痛かったのは、レビューコメントの短さだった」と話していたことです。精度の議論なら何十分でも語れるのに、実装については一行で切り捨てられる——この温度差こそが、研究出身者が実装力の壁にぶつかったときに感じる戸惑いの正体だと思います。

面接で実装力を見極めるために聞かれる質問

面接官が実装力を確かめるとき、いきなり「コードを書いてください」とは聞きません。むしろ、提出済みのコードやポートフォリオをもとに、設計の意図を掘り下げる質問が中心になります。私が候補者から聞き取った、実際に出た質問を並べてみます。

最後の質問が示すように、Git履歴そのものも評価対象になります。1回のコミットで完成形をどさっと上げるより、小さく積み上げた履歴のほうが「試行錯誤をどう管理してきたか」が伝わり、面接官の印象は良くなります。研究のコードは手元で完結させてしまいがちで、Gitを使っていても最終版しかコミットしていないケースが多く、ここも見落とされがちなポイントです。

「精度」と「保守性」は別の評価軸だという話

ここで裏付けとして紹介したいのが、Googleの研究者らが2015年に発表した論文「Hidden Technical Debt in Machine Learning Systems」です。この論文は、本番のMLシステムにおいて機械学習のコードそのものは全体の小さな一部にすぎず、その周囲に周辺の仕組みが大きく広がっていると指摘しています(出典：Sculley et al.「Hidden Technical Debt in Machine Learning Systems」(Google, NeurIPS 2015))。

論文ではさらに、モデルとその周辺コードの境界が曖昧になる「境界侵食」、複数のモデルが互いに影響し合う複雑な依存関係、モデルの予測が将来の学習データに影響を与え、モデル自身の評価をゆがめる「隠れたフィードバックループ」など、研究環境では意識しにくいリスクが列挙されています。研究で評価される精度と、事業会社で評価される保守性は、そもそも測っているものが別だと考えたほうが実態に近いのです。

この視点を持つと、面接官の質問の意図も読み取りやすくなります。「このモデルの精度はどこまで追求しましたか」ではなく「このモデルが半年後に壊れたら、誰が何を見て直せますか」を聞かれていることが多い、というのが私の実感です。

研究経験を実装力として翻訳する、面接での言い換え例

研究出身者に足りないのは経験そのものではなく、その経験を実装力の言葉に翻訳する作業であることが多いです。研究の過程で誰もが一度はやっている作業の中に、実は実装力の証拠が眠っています。言い換え方の実例を並べてみます。

Beforeの説明が悪いわけではありません。ただ、精度や結論だけを語ると、面接官には「1人で1回だけ動かした結果」にしか聞こえません。Afterのように再現性・共同作業・失敗からの改善まで含めて語ると、同じ経験が実装力の証拠として伝わります。この言い換えは、コードを1行も書き直さなくてもその場で使えます。

職務経歴書でも同じ翻訳をする

この言い換えは、面接の口頭説明だけでなく職務経歴書にもそのまま応用できます。研究出身者の職務経歴書でよく見るのは、「〇〇に関する研究に従事し、△△学会で発表」という業績の羅列です。これは学術的には正しい書き方ですが、採用担当者が知りたい「実装として何をしたか」が抜け落ちています。

たとえば「画像分類モデルの精度改善に関する研究を実施」という一行は、「学習データの前処理からモデル評価までのパイプラインをPythonで構築し、実験条件をコード管理することで再実験にかかる時間を1/3に短縮」のように、成果物と工夫した工程を動詞で書き直すと印象が変わります。研究テーマの学術的な新しさより、パイプラインをどう作ったか、どう改善したかという実装の痕跡を探して書き出す作業だと考えてください。

コーディングテスト、研究出身者が意外と苦戦する形式

技術面接には複数の形式がありますが、研究出身者の得意・不得意は他のバックグラウンドの候補者と少し違う傾向があります。競技プログラミング寄りのオンラインジャッジ形式は、数理的な思考力や計算量の見積もりに慣れているぶん、むしろ得意な人が多いというのが私の実感です。

つまずきやすいのは、面接官と会話しながら進めるライブコーディングやペアプログラミングの形式です。研究は基本的に1人で黙々とコードを書く時間が長く、「今、何を考えているか」を声に出しながら手を動かす経験がありません。頭の中では論理的に筋道を立てているのに、それを実況しないまま黙々と書き進めてしまい、面接官から「思考のプロセスが見えない」という評価を受けてしまう。形式ごとの対策の違いは技術面接・コーディングテストで落ちる人に共通する準備不足でも詳しく触れているので、あわせて読んでおくと準備の抜け漏れが減ります。

ポートフォリオ・GitHubで実装力を示す作り方

「Kaggleに参加しましょう」「GitHubを公開しましょう」という助言はよく見かけますが、研究出身者の場合、ノートブックをそのまま公開しただけでは、面接官が見ているポイントを外してしまいます。私が候補者に勧めているのは、次のような手直しです。

この5つのうち、私が面接官から最も評判が良いと感じるのは最後の「不足している点を正直に書く」です。完璧なコードより、限界を自覚した上で設計していることが伝わるほうが、実装力の証拠として強く働きます。逆に、精度の高さだけをアピールするREADMEは、研究発表の延長にしか見えません。

MLOps・本番運用の経験不足をどう埋めるか

求人票を見ていても、MLOps関連の経験(モデルのAPI化、監視、CI/CDパイプライン、特徴量の管理基盤など)が必須要件として明記されるケースが増えています。研究出身者はここが未経験であることが多く、応募時点で気後れしてしまう相談をよく受けます。

ただ、いきなり大規模な基盤を構築できる必要はありません。私が勧めているのは、Kaggleで精度を1ポイント上げる時間があるなら、その時間を使って、学習済みモデルをFastAPIで簡易的にAPI化し、入力の異常値を検知したらログに記録する仕組みまで一気通貫で作ってみることです。規模は小さくても、モデルを作って終わりではなく運用まで見届けた経験は、面接での説得力がまったく違います。

もう一歩進めるなら、モデルの予測精度が時間とともに落ちていく「ドリフト」を簡易的にでも検知するダッシュボードを作ってみる、Dockerでローカル環境と本番相当の環境を揃えておく、といったところまで手を伸ばすと、未経験でも「運用の勘所」が伝わりやすくなります。全部を作り込む必要はなく、面接で「ここまでは自分で試しました、この先は実務で学びたいです」と正直に線を引けることのほうが評価されます。

あわせて、生成AIの普及で評価基準がどう変わっているかは生成AI時代のエンジニア転職の評価基準で扱っているので、実装力に加えてAIツールをどう使いこなすかという観点も押さえておくと準備が一段厚くなります。

よくある質問に答えます

修士・博士で実務未経験でも応募していいですか

応募してかまいません。ただし、企業によってはジュニア枠での提示になり、年収はAIエンジニアの平均年収(job tagで629万円前後)より低いレンジから始まることが多いです。実装力を証明できるポートフォリオが用意できていれば、この差は面接の中で縮められます。

Kaggleでの実績は面接でどこまで評価されますか

順位やスコアそのものより、「なぜその特徴量を選んだか」「なぜそのモデル構成にしたか」という判断の説明を求められることのほうが多いです。順位だけを伝えて終わると、精度追求の話に閉じてしまいます。

研究職からMLエンジニアへの転職で年収は下がりますか

大学や研究機関からの転身の場合、初年度は横ばいか、ポジションによっては一時的に下がることもあります。ただし実装力とMLOpsの経験を積むほど伸びが早い職種でもあるので、私の担当実績では2〜3年で研究職時代の年収を上回るケースが多く見られます。

指導教員の研究室の実績しかない場合、職務経歴書に何を書けばいいですか

自分が主体的に手を動かした部分を切り出して書きます。「研究室として発表した論文」ではなく、「自分が担当したデータ前処理のパイプライン」「自分が実装した評価スクリプト」のように、担当範囲を明確にすることが重要です。共同研究であっても、自分がコードのどの部分を書き、どんな判断をしたかまで具体的に書ければ、実務未経験であっても実装の経験として十分に伝わります。

まとめ、実装力は「経験の有無」ではなく「翻訳の有無」で決まる

研究出身者が機械学習エンジニアの面接で落ちる理由は、実装経験がないからではなく、その経験を実装力の言葉に翻訳できていないことがほとんどだというのが、この記事で一番伝えたかったことです。論文用のコードとプロダクションのコードは前提が違うと知り、コードとポートフォリオを少し手直しし、研究の過程を再現性・共同作業・失敗からの改善という言葉で語り直す——この3つだけで、面接官が受け取る印象は大きく変わります。「実装力がない」と言われて落ち込む前に、まずは自分の経験をどう翻訳できていないかを点検してみてください。