MLエンジニア・データサイエンティストの採用とは、「MLモデルを本番で動かす人」と「データから意思決定の示唆を出す人」を切り分けて要件を定義し、ケーススタディ型の選考で実務力を見極め、課題の面白さとデータ・計算資源で口説く一連の設計です。両職種を混同した求人票は、母集団形成と選考の両方でミスマッチを生みます。この記事では、要件定義・求人票・スカウト・選考・クロージング・段階的採用までを順に解説します。

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

• 経済産業省の推計では先端IT人材（AI・データ領域）は2030年に約12.4万人不足。ML人材は従来の採用手法では母集団が集まらない

• 「MLエンジニア」と「データサイエンティスト」は役割・スキルセット・評価基準が異なるため、混同した求人票はミスマッチの元

• 年収レンジは求人媒体の公開求人で見るとミドルで650〜1,000万円、シニアで1,000〜1,500万円が目安。相場を外すとスカウトが読まれない

• 選考では技術的基礎力・プロダクション実装力・ビジネス翻訳力の3軸で評価し、ペーパーテストだけに頼らない

• Kaggle実績や論文だけでなく、プロダクション環境での運用経験があるかどうかが即戦力の分かれ目

• いきなり正社員を狙わず、副業・業務委託からの段階的採用を採用チャネルに組み込む

MLエンジニア・データサイエンティスト採用はなぜ難しいのか

ML人材の採用が難しい根本原因は、候補者の絶対数の少なさよりも、企業側の要件定義の曖昧さにあります。本番運用経験を持つ人材が限られている市場で、「MLエンジニア」と「データサイエンティスト」を混同した求人を出せば、わずかな候補者にすら届きません。

「ML人材を採りたいが、そもそも候補者がいない」——AI活用を推進する企業が増える一方で、MLエンジニアやデータサイエンティストの採用に苦戦するスタートアップは後を絶ちません。この記事では、ML人材の採用で成果を出すための要件定義・選考設計・クロージング手法を、13サービス以上のスカウト媒体を運用してきた立場から体系的に解説します。

データで見る：ML人材の需給環境

ML人材の需給は、IT人材全体の不足と先端領域への需要集中が重なった二重の売り手市場です。採用計画を立てる前に、社内で共有しておくべき公的データを整理します。

ML人材を取り巻く市場の主要指標

経済産業省の推計では、先端IT人材の不足は従来型IT人材の余剰と同時に進行するとされており、「IT人材は余るがML人材は足りない」という偏りが2030年に向けて拡大する見通しです。1人の候補者を複数社が奪い合う構図は、当面変わりません。

1. MLエンジニアとデータサイエンティストの違いを正しく理解する

ML人材の採用でまず押さえるべきは、「MLエンジニア」と「データサイエンティスト」が異なる職種だということです。ここを混同すると、求人票もスカウトも選考もすべてズレます。

1-1. 役割の違い

1-2. なぜ混同されるのか

日本の求人市場では、「データサイエンティスト」というタイトルで実際にはMLエンジニアリングを求めるケースが多く見られます。逆に、分析メインの業務なのに「MLエンジニア」で募集しているケースもあります。

候補者から見ると「入社してみたらやりたい仕事ではなかった」というミスマッチの原因になりますし、選考段階で「期待されるスキルと自分のスキルが違う」と辞退されるリスクも高まります。

1-3. 自社に必要なのはどちらか？判断フレームワーク

以下の質問で、自社が今必要としている人材像を明確にしましょう。

1. MLモデルを本番のプロダクトに組み込む必要がある → MLエンジニア

2. データを分析して経営判断を支援したい → データサイエンティスト

3. モデルの精度改善と運用の両方を担ってほしい → MLエンジニア（シニア）

4. まずはPoCで機械学習の有効性を検証したい → データサイエンティスト

5. MLOps基盤を構築・運用したい → MLエンジニア（プラットフォーム寄り）

どちらか迷う場合は、ソフトウェアエンジニアリングとML知識の比率で考えるとわかりやすいです。エンジニアリング7割・ML3割ならMLエンジニア、分析・統計7割・エンジニアリング3割ならデータサイエンティストです。MLOps基盤の担い手を探している場合は「MLOpsエンジニア採用ガイド」、データ基盤側の人材が必要な場合は「データエンジニア採用ガイド」も参照してください。

2. ML人材の採用が難しい5つの構造的理由

ML人材の採用難は一過性の需要増ではなく、供給・報酬・志向・技術変化・評価という5つの構造要因が同時に作用した結果です。どれか1つを解消しても採用は楽になりません。

1. 実務経験者の絶対数が少ない：大学や研究機関でモデル構築を経験した人材は増えていますが、本番環境でMLシステムを設計・運用・改善した経験を持つ人材となると一気に絞られます

2. 報酬レベルが他職種より高い：ML人材の報酬は一般的なソフトウェアエンジニアよりも高い水準にあり、外資系テック企業やヘッジファンドはさらに上のレンジを提示します

3. 「研究志向」と「実装志向」のミスマッチ：研究寄りのキャリアを志向する人材と、プロダクト実装を志向する人材が混在しています

4. 技術の変化スピードが速い：LLMの普及で求められるスキルが数年で入れ替わり、要件を固定的に定義するとマッチする候補者が極端に少なくなります

5. 評価が難しい：Kaggleや論文の実績と実務での成果が一致しないケースが多く、面接だけでは判断しにくい面があります

2-1. 報酬レンジの目安

スカウト媒体上の公開求人票で見かける年収レンジを整理すると、おおむね次の水準に収まります。媒体運用をしていると、この上限が半年単位で引き上げられていくのを目にします。

スタートアップが報酬だけで勝負するのは難しいため、後述するEVP（Employee Value Proposition）設計が重要です。職種・言語別の最新の年収相場は「エンジニア年収相場2026｜言語・職種別の市場データと採用オファー戦略」、既存メンバーとの報酬バランスの取り方は「エンジニア組織の報酬レビュー・昇給設計ガイド」も参考になります。

研究志向と実装志向のミスマッチを防ぐには、採用時にキャリア志向を丁寧にヒアリングし、自社の期待する役割と一致するかを確認することが欠かせません。また「2年前の最新スキルが今は当たり前」という技術変化の速さを踏まえ、学習能力と適応力を重視した要件設計が必要です。

3. ML人材の要件定義と求人票の書き方

ML人材の求人票は「何を解くのか」を軸に書くと反応が変わります。技術スタックの羅列よりも、取り組む課題・データの規模・計算資源を具体的に示した求人票のほうが、候補者の関心を引けます。

3-1. フェーズ別の要件定義

自社のMLプロジェクトのフェーズによって、必要な人材像は大きく変わります。

3-2. 求人票に書くべき5つの要素

1. 解くべきビジネス課題：「推薦アルゴリズムの改善」よりも「月間1,000万ユーザーのマッチング精度を改善し、CVRを向上させる」の方が具体的で刺さります

2. データの規模と質：「大量のデータ」ではなく「日次1億レコード、3年分の蓄積データ」のように定量化します。データの整備状況も正直に書くと信頼度が上がります

3. 技術スタックと開発環境：使っているフレームワーク、クラウド環境、GPU環境を明記します。ML人材はGPU環境（NVIDIA A100 / H100等）の有無を気にする傾向があります

4. チーム構成と裁量：「MLチーム3名」だけでなく、研究者とエンジニアの内訳、意思決定のプロセス、論文投稿や学会参加の奨励有無を書くと候補者の関心を引けます

5. 年収レンジ：ML人材は年収レンジが明記されていない求人を避ける傾向が強いです。前述のテーブルを参考に、市場相場に合ったレンジを明記しましょう

求人票の書き方全般については「エンジニアが応募したくなる求人票（JD）の書き方完全ガイド」も参考にしてください。

3-3. スカウト文面のポイント

ML人材へのスカウトでは、「あなたの〇〇の経験に注目しました」というパーソナライズが特に重要です。具体的には以下の情報を事前に調べてスカウト文面に反映します。

• Kaggleプロフィール: コンペの成績、得意な手法

• GitHub: OSSへのコントリビューション、個人プロジェクト

• 論文: Google Scholarでの被引用数、研究テーマ

• 登壇実績: PyCon、MLOps Community、データサイエンス系勉強会

テンプレートのスカウトを大量に送るよりも、1人あたり15〜20分かけてパーソナライズしたスカウトを10通送る方が、トータルの返信率は高くなります。スカウト文面の基本的な書き方は「エンジニア向けスカウトメールの書き方と返信率を上げる例文集」で詳しく解説しています。

4. ML人材を正しく見極める選考設計

ML人材の選考は、ケーススタディ形式で「課題の構造化→手法選択→運用の現実感→説明力」を一度に見るのが最も効率的です。一問一答の知識確認では、実務で成果を出せるかどうかを判別できません。

4-1. 選考フローの設計

ML人材の選考フローは、一般的なエンジニア採用よりもステップが多くなりがちです。しかし、選考期間が長すぎると他社に先を越されるリスクがあります。全体で2〜3週間以内に収まるように設計しましょう。

推奨フロー（全体2〜3週間）

1. 書類選考 + ポートフォリオレビュー（2〜3日）：職務経歴書だけでなく、GitHub / Kaggle / 論文もレビュー

2. カジュアル面談（30〜45分）：技術的な深掘りはせず、キャリア志向とカルチャーフィットを確認

3. 技術面接（ケーススタディ）（60〜90分）：後述のケーススタディ形式で技術力を評価

4. チーム面接（45〜60分）：一緒に働くメンバーとの相性を確認

5. オファー面談（45〜60分）：条件提示と質疑応答

4-2. 技術面接の3つの評価軸

軸1: 技術的基礎力

統計学・機械学習の基礎を理解しているかを確認します。ホワイトボードで数式を書かせるような面接ではなく、実務に即した質問で判断します。

• 「過学習を検知・対策するために、実務でどのようなアプローチを取りますか？」

• 「分類タスクの評価指標としてAUC-ROCを選ぶ場合と、Precision-Recallを選ぶ場合の判断基準は？」

軸2: プロダクション実装力

モデルを本番環境で動かす能力を評価します。研究と実務の間の溝を埋められるかどうかが、即戦力になれるかの分かれ目です。

• 「モデルの推論レイテンシが要件を満たさない場合、どのような最適化アプローチを検討しますか？」

• 「モデルのドリフト（精度劣化）をどのように検知し、対処しますか？」

軸3: ビジネス翻訳力

技術をビジネス成果に結びつける能力を評価します。特にデータサイエンティストの採用では、この軸が最も重要です。

• 「あるモデルのAUC-ROCが0.85から0.90に改善しました。この改善がビジネスにどの程度のインパクトを与えるかを、どのように算出しますか？」

• 「経営層から"AI導入で売上を10%上げたい"と言われた場合、どのようなステップで進めますか？」

4-3. ケーススタディ形式の面接

筆記試験や一問一答型の面接ではなく、実際のビジネス課題をベースにしたケーススタディを出題するのが効果的です。

ケーススタディ設計の4原則

1. 自社の実際の課題をベースにする（守秘義務に配慮して抽象化）

2. 正解が1つではない問題にする（思考プロセスを見る）

3. 事前に課題を送り、準備時間を与える（60〜90分程度の持ち帰り課題）

4. プレゼンテーション + 質疑応答の形式にする

具体例：「ECサイトの商品推薦システムを改善してほしいと依頼されました。現在のCTRは2%です。データとして過去1年分の購買履歴・閲覧履歴・商品マスタがあります。どのようなアプローチで取り組みますか？」

この課題で見られるのは、問題の構造化能力（いきなり手法に飛びつかず、課題を整理できるか）、手法選択の妥当性（協調フィルタリング、コンテンツベース、深層学習の使い分け）、実装の現実感（レイテンシや運用コストへの言及があるか）、コミュニケーション力（技術的な内容をわかりやすく説明できるか）の4点です。評価のばらつきを抑える評価シートの作り方は「エンジニア面接評価シート設計ガイド」で解説しています。

4-4. Kaggle実績・論文の正しい評価方法

• Kaggle実績: コンペ入賞は技術力の証明として有効ですが、Kaggleの課題と実務の課題は質的に異なります。実務では「精度はほどほどでも安定して動くシステム」が求められることが多いため、Discussionへの貢献やNotebookの質も併せて見ると本質的な能力がわかります

• 論文実績: トップカンファレンス（NeurIPS、ICML、CVPR等）への採択は高い技術力の証明ですが、プロダクト貢献力とは別物です。筆頭著者かどうか、どの部分を担当したかを面接で確認すると、実際の貢献度がわかります

5. ML人材を口説くクロージング戦略

ML人材のクロージングは、報酬の積み増しよりも「解く課題・データ・計算資源・研究への理解・キャリアパス」の5点をどれだけ具体的に示せるかで決まります。転職動機が一般的なエンジニアと異なるため、訴求ポイントも変える必要があります。

5-1. ML人材が重視する5つの条件

1. 解くべき課題の面白さ：「どんな技術を使うか」よりも「どんな課題を解くか」に関心が強い傾向があります。自社のデータやドメインの独自性を具体的に伝えましょう

2. データの質と量：「データはたくさんあります」ではなく、「日次5億レコードの行動ログ、正解ラベル付き」のように具体的に伝えます。整備状況が悪い場合も正直に伝えた上で「だからこそあなたの力が必要」と動機づけるのが効果的です

3. GPU・計算リソースの充実度：クラウドGPU（AWS p4d / GCP A3等）の利用予算があるか、オンプレのGPUサーバーがあるかを明確にしましょう

4. 研究活動への理解：論文投稿やカンファレンス参加を業務時間内に認めるかどうかは、研究志向の候補者にとって重要な判断材料です

5. キャリアパスの明確さ：ICトラック（テックリード → プリンシパル → フェロー）、マネジメントトラック（チームリード → EM → VPoE）、リサーチトラック（リサーチエンジニア → シニアリサーチャー → リサーチディレクター）のうち、自社でどれが実現可能かを具体的に示します

5-2. オファー面談で差をつけるポイント

ML人材のオファー面談では、条件面だけでなく入社後の具体的なイメージを伝えることが重要です。

• 最初の3ヶ月で取り組む課題を具体的に説明する

• チームメンバーの紹介（可能であれば面談時に同席してもらう）

• 学習・研究のサポート体制（書籍購入、カンファレンス参加、GPU予算等）

• 評価制度（ML人材のアウトプットをどのように評価するかを明確にする）

5-3. カウンターオファーへの対策

ML人材は転職活動中に現職からカウンターオファー（引き留め）を受けるケースが多いです。

• 金額だけでなく「環境」で差別化する: 現職のカウンターオファーが年収アップだけなら、「解く課題の面白さ」「成長機会」で勝負する

• 内定から承諾までの期間を短くする: 長引くほどカウンターオファーの影響を受けやすい。1週間以内の回答を目安にする

• 候補者の転職理由を深く理解する: 「なぜ現職を離れたいのか」の本質的な理由に自社がフィットしていることを確認する

6. 副業・業務委託から始めるML人材の段階的採用

ML人材の採用では、いきなり正社員を目指すよりも副業・業務委託から始める段階的なアプローチが特に有効です。MLプロジェクトは「やってみないとわからない」要素が大きく、一緒に仕事をしてからフルタイムに移行すれば双方のリスクが小さくなるためです。

6-1. 段階的採用が有効な3つの理由

1. ミスマッチリスクの軽減：プロジェクトの成否と相性を見てから正社員オファーを出せる

2. 候補者側のハードルが低い：「まず副業で」と提案することで、転職を迷っている優秀な人材にもアプローチできる

3. 市場の特性に合っている：研究者やフリーランスのデータサイエンティストは、複数プロジェクトを並行して進めるワークスタイルに慣れている

契約形態ごとの使い分けは「エンジニア契約形態比較ガイド｜正社員・業務委託・SES・派遣の使い分け」で詳しく解説しています。

6-2. 副業・業務委託の活用パターン

パターン1: PoCプロジェクトの外注

• 3〜6ヶ月のPoC案件を業務委託で依頼し、成果と相性を見てから正社員オファーを出す

• 稼働目安: 週1〜2日

パターン2: 技術顧問として参画

• シニアML人材に技術顧問として月8〜16時間程度参画してもらい、MLチームの方向性やアーキテクチャに対するアドバイスを受ける

• 正社員オファーにつながるケースもある。技術顧問の活用法は「技術顧問でエンジニア採用を強化する実践ガイド」を参照

パターン3: 社内コンペの審査員・メンター

• ML分野の著名な人材を社内コンペの審査員やメンターとして招き、自社の課題とデータを知ってもらう。そのまま参画につながるケースがある

6-3. 副業から正社員へ移行する際の注意点

• 移行時期の目安: 3〜6ヶ月の業務委託期間を経て、双方の意向を確認

• 条件面のギャップ: 業務委託は時給換算で正社員より高くなることが多いため、正社員移行時の年収設計は慎重に

• 契約条件の整理: 成果物の知的財産権、競合制限条項を事前に取り決めておく

7. LLM時代に変わるML人材の採用要件

LLMの普及によって、ML人材に求められるスキルセットは「従来ML」と「LLM活用」の二層構造になりました。両方を高水準で備えた人材は市場にほぼ存在しないため、採用要件は分けて定義する必要があります。

7-1. LLMの台頭で求められるスキルが変わった

• 従来のML人材に求められたスキル: 特徴量エンジニアリング／勾配ブースティング（XGBoost / LightGBM）／ニューラルネットワークの設計と学習／A/Bテスト設計

• LLM時代に加わった新しいスキル: プロンプトエンジニアリング／RAGアーキテクチャの設計／ファインチューニング（LoRA / QLoRA）／LLMアプリケーションの評価手法（LLM-as-a-Judge等）／ベクトルデータベースの設計・運用

7-2. 「フルスタックML人材」への期待と現実

従来のMLに加えてLLMスキルも求める「フルスタックML人材」を探そうとする企業が増えていますが、そのような人材は市場にほぼ存在しません。現実的なアプローチは次の3つです。

1. 既存のMLエンジニアにLLMスキルを学んでもらう（学習支援制度の整備）

2. LLM特化の業務委託人材を活用する（RAG構築やファインチューニングをスポット依頼）

3. ソフトウェアエンジニアをMLに育成する（API連携やインフラ構築が得意なエンジニアにLLM活用を担当してもらう）

LLM領域に特化した採用要件は「LLMエンジニア採用ガイド｜要件定義から選考・口説き方まで」で詳しく解説しています。

7-3. 採用要件の書き方も変わる

LLM時代のML人材採用では、要件定義を**「従来ML」と「LLM」で分けて記載**するとよいでしょう。

• 必須: Python / ML基礎（教師あり学習・教師なし学習）/ データ前処理

• 歓迎（従来ML）: PyTorch / 推薦システム / 時系列予測

• 歓迎（LLM）: RAG設計 / プロンプト最適化 / LLMOps

• 期待する成長: 入社後6ヶ月以内に、自社プロダクトへのLLM活用方針を策定できるレベル

8. ML人材に届く採用チャネルと媒体の使い分け

ML人材の母集団形成は、汎用のスカウト媒体だけでなく、技術アウトプットが可視化される媒体とコミュニティを組み合わせるのが定石です。ML人材はGitHub・Kaggle・論文といった「実績が外から見える場所」に集まっているため、そこを起点に探すほうが精度が上がります。

チャネル別の使い分け

媒体運用の経験から言うと、ML人材は複数媒体に同時登録していることが多く、別媒体から同じテンプレートが届くと即座に見抜かれます。候補者単位で「どの媒体で・何に触れて・いつ送ったか」を記録し、二重送信を防ぐ運用が必須です。GitHub・技術ブログを起点にしたスカウトの設計は「LAPRAS完全ガイド」、検索条件の組み方は「スカウト候補者検索の完全ガイド」を参照してください。

FAQ（よくある質問）

Q1. MLエンジニアとデータサイエンティスト、どちらを先に採用すべきですか？

自社のMLプロジェクトのフェーズによります。まだ機械学習の有効性を検証する段階（PoC）であればデータサイエンティスト、すでに検証済みのモデルを本番環境に組み込む段階であればMLエンジニアが先です。迷う場合は、ソフトウェアエンジニアリング力が高いMLエンジニアを採用し、分析業務は外部のデータサイエンティストに業務委託する方法もあります。

Q2. Kaggle実績がない候補者は評価が難しいのですが、どうすればよいですか？

Kaggle実績は技術力の一つの指標ですが、必須ではありません。実務でMLプロジェクトを推進した経験がある候補者は、Kaggle未経験でも即戦力になれます。ケーススタディ形式の面接で実践力を評価する方法が有効です。GitHub上のプロジェクト、技術ブログの発信内容、勉強会での登壇資料なども参考になります。

Q3. ML人材の年収相場がわかりません。どこで確認できますか？

dodaやレバテック等の転職サービスが公開している年収データと、スカウトサービス上で類似スキルの候補者が登録している希望年収が参考になります。本記事のセクション2-1の年収テーブルも目安としてご活用ください。相場より大幅に低い提示では、スカウトの返信率が著しく下がります。

Q4. MLの専門知識がない人事担当者でも、ML人材の選考はできますか？

1次面接（カルチャーフィット・キャリア志向の確認）は人事担当者が対応できます。技術面接は社内のエンジニアに担当してもらうか、外部の技術顧問に協力を依頼しましょう。また、本記事のケーススタディ形式の面接であれば、「候補者の説明がわかりやすいか」「論理的に構造化できているか」という観点で非エンジニアでも評価できる部分があります。

Q5. LLM時代でも、従来の機械学習（XGBoostなど）のスキルは必要ですか？

はい、必要です。LLMは万能ではなく、構造化データの予測タスク（需要予測、不正検知、レコメンドなど）では依然として勾配ブースティング系の手法が高い精度を出すケースが多いです。LLMと従来MLの使い分けができる人材が、実務では最も価値が高いです。

Q6. ML人材の採用に強いスカウトサービスはどれですか？

ML人材のスカウトでは、BizReach、Forkwell、LAPRASが相対的にML人材の登録が多い傾向があります。また、LinkedIn経由で海外在住の日本人ML人材にアプローチするケースも増えています。どのサービスを使うかよりも、パーソナライズしたスカウト文面を送れるかどうかが返信率の決め手です。

Q7. スタートアップが大手テック企業と採用で戦うには、どうすればよいですか？

報酬面で大手テック企業に勝つのは難しいため、別の価値で差別化しましょう。スタートアップならではの強みとして「ビジネスに直結する課題に取り組める」「意思決定が速い」「自分の仕事が事業に直接インパクトする実感がある」「研究テーマの自由度が高い」といった点があります。ストックオプションの付与も報酬格差を補う手段の一つです。

Q8. 1人目のML人材を採用する場合、何から始めるべきですか？

1人目は「フェーズを問わず自走できるシニア」を狙うより、まず自社のMLプロジェクトのフェーズを固定してから探すのが現実的です。PoC段階なら業務委託のデータサイエンティストに3〜6ヶ月で有効性を検証してもらい、本番導入が決まった時点でMLエンジニアの正社員採用に切り替える二段構えが、採用難易度とミスマッチリスクの両方を下げます。

まとめ：ML人材の採用で成果を出すためのアクション

MLエンジニア・データサイエンティストの採用は、職種理解の深さと選考設計の精度が成果を左右します。

今すぐできるアクション:

1. 自社のMLプロジェクトのフェーズを整理し、必要な人材像（MLエンジニアかデータサイエンティストか）を明確にする

2. 年収レンジを市場相場に合わせて設定し、求人票に明記する

3. 求人票に「解くべき課題」「データの規模と質」「GPU環境」を具体的に記載する

4. ケーススタディ形式の技術面接を設計し、3軸（技術基礎力・プロダクション実装力・ビジネス翻訳力）で評価する

5. 副業・業務委託からの段階的アプローチを採用チャネルに加える

6. LAPRAS・Forkwell・Kaggle など技術アウトプットが見える場所を起点にスカウトを設計する

ML人材の採用は一朝一夕では成果が出ません。しかし、正しい職種理解と選考設計を持って臨めば、限られた候補者市場でも採用は実現できます。

techcellarでは、エンジニア採用に特化したスカウト運用代行・AIスカウト運用を提供しています。MLエンジニアやデータサイエンティストのスカウト運用でお困りの方は、お気軽にお問い合わせください。