「MLOpsって、結局データ側の仕事ですか、インフラ側の仕事ですか」——データエンジニアとインフラエンジニアの両方から、ほぼ同じ言葉で聞かれることが増えました。どちらの人も、求人票を見て「自分にも行けそうだ」と感じているのに、応募してみると結果が割れます。
私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、MLOpsの求人は職種名が同じでも、必須要件の並びを読むと中身がかなり違います。今回は2026年9月時点で公開されていた求人票を読み分けたうえで、データ基盤出身とインフラ出身のどちらがどの求人に強いのか、実例を交えてお伝えします。
今回は、次の内容に沿ってご紹介します。
- 「MLOps」求人がデータパイプライン寄りとインフラ・SRE寄りに分かれる理由と、求人票での見分け方
- データエンジニア出身者・インフラ出身者それぞれが、どちらの求人に強く、何を補えば届くか
- MLOps未経験で入るときの現実的な順路と、応募戦略の立て方
目次
MLOpsエンジニア転職の求人票は、大きく二種類に分かれる
MLOpsは、機械学習モデルを作って終わりにせず、本番で動かし続けるための仕組みを整える仕事です。ここまでは解説記事に共通していますが、求人票を実際に読むと「仕組み」の指す範囲が会社ごとに違います。
まず、Google Cloudの公開資料にあるMLOps成熟度の考え方が分かりやすい物差しになります。レベル0は手動でモデルを作って配る状態、レベル1はデータの検証や特徴量の管理を含めて学習のパイプラインを自動化する段階、レベル2はそのパイプライン自体のCI/CDまで自動化する段階、という整理です(出典:Google Cloud「MLOps: ML における継続的デリバリーと自動化パイプライン」)。
この段階の違いが、そのまま求人票の必須要件の違いに出ます。レベル1を作っている会社は、データの取り込み・変換・検証に強い人を求めます。レベル2やモデルの配信基盤に力を入れている会社は、IaCやコンテナ運用に強い人を求めます。同じ「MLOpsエンジニア」でも、前者はデータ基盤の延長、後者はインフラ・SREの延長にあたります。
2026年9月時点の求人票で見た三つの型
2026年9月時点で公開されていた求人票やチーム紹介から、型が分かれている例を三つ挙げます。企業名は出さず、記載されていた範囲だけを紹介します。
一つ目は、インフラ寄りの型です。業務にTerraformでの実装、GitHub ActionsでのCI/CD、特徴量ストアやMLパイプラインの実行基盤、LLMの基盤づくりが並び、必須要件はAWSまたはGoogle CloudでのAIシステムの構築・運用1年以上、Terraform、Dockerでした。データエンジニアリングの経験は歓迎要件にとどまっていました。
二つ目は、データ寄りの型です。業務はdbtやBigQuery ML、Pythonでのデータエンジニアリングのワークフロー、データガバナンスが中心で、必須は機械学習の基礎知識とプログラミング2年以上。歓迎にGoogle CloudやAWSでのデータエンジニアリング業務が入っており、Terraformの文字は必須欄にありませんでした。
三つ目は、両方を一つの職種に同居させている型です。あるIT企業のチーム紹介では、学習・再学習のパイプラインと、推論サーバー・モデル配信・監視の基盤が同じMLOpsチームの担当として書かれ、MLOpsとデータエンジニアが同じグループに所属していました。
これらは求人票に書かれていた範囲の話で、その会社の実際の採用基準や入社後の配分まで断定するものではありません。ただ、職種名だけを見て応募先を決めていると、この差に気づかないまま書類選考を迎えることになります。
求人票の必須要件で、寄りを見分ける
見分けるコツは、職種名や「歓迎スキル」ではなく、必須要件欄に何が最初に並ぶかを見ることです。歓迎欄は企業が「あれば嬉しい」を広く書く場所なので、寄りが出にくい。必須欄は、書類選考でそのまま足切りに使われる場所です。
必須要件欄で見る手がかり
- データ寄り:SQL、dbt、Airflowなどのワークフロー、データウェアハウス、データ品質・ガバナンス
- インフラ寄り:TerraformなどのIaC、Kubernetes・Docker、CI/CD、監視・オンコール、クラウドでの運用年数
- ML側の要件:どちらでも「機械学習の基礎知識」は出るが、モデル開発の実績まで必須にする求人は少数派
三つめの「ML側の要件」は誤解が多いところです。データエンジニアもインフラエンジニアも、機械学習を一から研究できないと応募できない、と思い込んで手が止まる方が少なくありません。私が見てきた範囲では、必須に書かれているのは「基礎知識」や「モデルを本番に載せた経験」であって、論文レベルの知識ではありません。研究職出身の方の見せ方は、機械学習エンジニアの面接で実装力を問われる場面を扱った記事で詳しく書いています。
データ基盤出身者の場合、パイプライン寄りの求人に強い
データエンジニア出身の方が有利になるのは、上で挙げたデータ寄りの型です。実例を一つ挙げます。
Pさん(28歳・経験4年)は、広告配信を手がける自社開発企業でデータエンジニアをしていました。日次のバッチと分析基盤の運用が仕事で、SQLとAirflowには自信があります。MLOps求人を10社ほど並べて応募し、データ寄りの求人では書類が通る一方、インフラ寄りの求人はほとんど通りませんでした。
原因は必須要件欄です。通らなかった求人には「Terraform」「Kubernetes運用」が必須で並んでいて、Pさんの職務経歴書には該当する言葉が一つもありませんでした。ところが面談で話を聞くと、Pさんはデータ基盤の権限設計で環境構築の自動化に関わっていて、クラウドの構成管理コードを自分で書いた経験がありました。職務経歴書には「基盤の運用」としか書かれていなかったのです。
「基盤構築の経験は、データ側の言葉のまま書くと、インフラ側の求人から見えなくなる」というのがこの件の学びでした。書き直したあと、インフラ寄りの求人でも書類を通るものが出始めましたが、最終的に内定を得たのはデータ寄りの求人でした。データ出身者はデータ寄りで勝ち、インフラ寄りは経験を翻訳して届く範囲を広げるのが現実的な順序です。
データエンジニアとしての基盤構築経験をどう伝えるかは、データエンジニアの基盤構築経験を年収交渉で伝える方法でも触れています。設計判断を語れるかどうかが、MLOpsでも評価の軸になります。
インフラ・SRE出身者の場合、基盤・推論寄りの求人に強い
反対に、インフラエンジニアやSRE出身の方は、Terraform、CI/CD、コンテナ運用が必須に並ぶ求人に強くなります。こちらも実例です。
Qさん(36歳・経験13年)は、ゲーム運営会社の社内インフラチームでSREをしています。Kubernetesの運用、Terraformでの環境管理、オンコールの設計と、インフラ寄りのMLOps求人が求める要素はほとんど持っていました。実際、インフラ寄りの求人では書類がほぼ通り、一次面接も順調でした。
つまずいたのは二次面接です。「学習パイプラインで、データの品質が落ちたことはどう検知しますか」と聞かれ、答えに詰まりました。Qさんの経験は「動いている基盤を落とさない」ことに寄っていて、データそのものの正しさを見る発想がなかったのです。結果は見送りでした。
Qさんは数か月かけて、自社のログ基盤で簡単なデータ検証の仕組みを作りました。次の応募では、同じ質問に「スキーマの変化と分布のずれを検知して、学習ジョブを止める」と実装の経験つきで答えられて、内定に至りました。インフラ出身者の弱点は、データの品質を守る視点にあります。ここを補うと、インフラ寄りの求人だけでなく、両方を求めるタイプの求人にも届くようになります。
こうしたインフラ寄りの求人の実態は、SREとプラットフォームエンジニアの求人の違いでも書いたとおり、職種名より必須要件と業務内容の文言で判断するのが確実です。
出身別に、強い求人と補うべき点を整理する
ここまでの内容を、出身別に表にまとめます。あくまで私が現場で見てきた傾向で、個々の求人や選考結果を保証するものではありません。
| 出身 | 強い求人の型 | 求人票でぶつかりやすい必須要件 | 補う順序 |
|---|---|---|---|
| データエンジニア | パイプライン・データ品質寄り | Terraform、Kubernetes運用、CI/CD | 構成管理コードとデプロイ自動化の経験を洗い出す |
| インフラ・SRE | 基盤・推論・CI/CD寄り | データ検証、ワークフロー設計、特徴量管理 | データ品質を検知する仕組みを一つ作る |
| バックエンド | 推論APIやサービング寄り | 機械学習の基礎、クラウド運用の年数 | 個人でも構わないのでモデルを載せて監視まで通す |
| ML研究・データサイエンス | モデル開発に近い求人 | 運用・保守の経験、テスト、監視 | 本番運用の障害対応を追体験できる場を探す |
バックエンドと研究出身の方はこの記事の主役ではないので、深追いしません。ただ、「どの出身なら絶対に有利」という一本道はなく、自分の出身と求人の寄りが合っているかを先に確認することが、応募数を減らしながら通過率を上げる最短の道です。
なお、先ほどの三つ目の「両方同居型」は、どちらの出身でも書類までは通りやすい反面、入ってからの守備範囲が広くなります。学習パイプラインの設計と、推論基盤の障害対応を一つのチームで受け持つことになるので、面接では「自分はどちら側が強く、もう片方をどう補っているか」を先に自分から話せる人が評価されます。私は、こうした求人に応募する方には、強みと補完中の領域を一言ずつ用意してもらっています。
MLOps未経験の現実と、隣接職種から入る順路
「MLOpsエンジニア 未経験」と検索している方に、正直にお伝えします。完全な未経験は、正社員の求人ではかなり厳しいです。先ほどのインフラ寄りの求人では、必須に「クラウドでのAIシステムの構築・運用1年以上」が入っていました。
民間の解説記事では、MLOpsの年収は正社員で600〜1,000万円が中心、フリーランスで月70〜120万円という記述があります(出典:フリーランスコンシェルジュ「MLOpsエンジニアとは」)。あくまで民間メディアの推定値で、求人ごとに差が大きいことは前提にしてください。私の感覚でも、この水準は経験者向けの求人の話で、未経験で応募して届く水準ではありません。
では、未経験の方はどうするか。私は、次の二段階の順路を勧めています。
隣接職種から入る順路
- 第一段階:データエンジニアまたはインフラ・SREの求人に入り、パイプラインかクラウド基盤の実務を1〜2年積む
- 第二段階:その職場で機械学習チームと接点を持ち、モデルの配信や再学習の自動化に関わる
- そのうえで、必須要件に合うMLOps求人へ応募する
インフラ側の入口については、オンプレミスのインフラ経験をクラウドの言葉に翻訳した例が参考になります。データ側の入口は、データエンジニアとデータアナリストの求人票の読み方を先に読むと、配属先のミスマッチを避けやすくなります。
応募戦略:職種名ではなく業務キーワードで探す
「MLOps」という職種名での募集は多くないので、パイプライン構築やモデルのデプロイといった業務で探す方が現実的です。私が見てきた範囲でも、職種名を「機械学習エンジニア」「データエンジニア」「SRE」「プラットフォームエンジニア」としている求人の中にMLOpsの業務が含まれているケースは少なくありません。
そこで、応募の前に次の三つを確認します。
- 必須要件欄の最初の三つが、データ系かインフラ系か
- 業務内容に「学習パイプライン」と「推論・配信基盤」のどちらが先に書かれているか
- チーム紹介で、MLOpsがデータエンジニアとインフラ・SREのどちらと同じグループか
この確認だけで、書類を出す前に自分の出身と合わない求人を外せます。迷う求人は、応募せずに一度カジュアル面談で「必須欄の最初の三つのうち、入社後に一番時間を使うのはどれか」と聞いてみるのも手です。書類選考の通過率が低いときは、経験不足を疑う前に、応募先の寄りを間違えていないかを見る方が先です。PさんもQさんも、スキルそのものは応募前からほぼ足りていて、ずれていたのは応募先の選び方と、経歴の書き方でした。足りないと思い込んで学習に時間を回す前に、まず読み直すことをお勧めします。
AI系の求人全般で採用基準がどう動いているかは、AIエンジニアの採用基準の変化にも書いています。
よくある質問
データエンジニアからMLOpsエンジニアに転職できますか。 できます。特にデータの取り込み・変換・検証を中心とした求人には強いです。一方で、Terraformやコンテナ運用が必須の求人には届きにくいので、環境構築の自動化に触れた経験があれば、インフラ側の言葉に直して職務経歴書に書いておくと応募先が広がります。
インフラ・SREからMLOpsエンジニアに行けますか。 行けます。基盤・CI/CD・監視の経験が評価される求人が多いです。ただし、データの品質をどう見るかを聞かれる場面があるので、簡単なデータ検証の仕組みを一つ作って、面接で語れるようにしておくと差がつきます。
機械学習の知識はどこまで必要ですか。 求人票で確認できた範囲では、必須は「基礎知識」レベルの記載が中心でした。モデルを自分で研究開発できることまで求める求人は、少なくとも私が見た範囲では少数派です。ただし基礎知識の内容は面接で聞かれるので、学習・評価・過学習といった言葉を自分の言葉で説明できるようにしてください。
MLOps未経験でも応募できる求人はありますか。 必須に「クラウドでのAIシステム構築・運用の実務経験」を置く求人があり、完全な未経験では届きにくいのが実情です。隣接するデータ基盤・インフラの職種で実務を積んでから応募する方が、結果的に早くなります。
まとめ
MLOpsという職種名は同じでも、求人票の必須要件をたどるとデータパイプライン寄りとインフラ・SRE寄りに分かれています。データ出身者は前者に、インフラ出身者は後者に強く、それぞれ足りない側の言葉と経験を一つ補うだけで、応募できる求人が一気に広がります。
この記事で一番お伝えしたかったのは、MLOpsへの転職で最初にやるべきことは、スキルを増やすことではなく自分の出身と求人の寄りが合っているかを確認することだという点です。応募先の必須要件欄を三行だけ読み直すことから、始めてみてください。




