MLOpsエンジニア

一言でいうと

機械学習を継続して回すための基盤とパイプラインを整え、モデルを作る人が実験から本番投入までを繰り返せる状態を保つ職種です。

この職種の出自と登場時期

問題意識の出発点は2015年です。Google の研究者が NeurIPS で発表した「Hidden Technical Debt in Machine Learning Systems」が、機械学習システムのうちモデルのコードはごく一部で、大部分が周辺の仕組みで占められることを示しました。学習したモデルを本番で動かし続ける工程が、独立した技術領域として認識されます。

体系として整理されたのは2020年前後です。Google Cloud は MLOps を、機械学習システムに DevOps の考え方を持ち込むものとして定義し、手作業の段階からパイプラインの自動化、CI/CD による継続的な学習まで、成熟度をレベルで整理しました。ml-ops.org もこの時期に、機械学習システムの運用を体系としてまとめています。

国内では2021年前後から「MLOpsエンジニア」という職種名の求人が現れました。機械学習エンジニアの求人のなかに、基盤とパイプラインの担当として含まれる場合も多く、求人票では業務内容の確認が必要です。

ミッション

責任範囲は、モデルを作る人が試して本番に出すまでの時間を短くし、その状態を保ち続けることです。個別のモデルの精度ではなく、実験から本番投入までのサイクルが回っているかで評価されます。

そのため、指標は開発側の体験に寄ります。学習の実行にかかる時間、本番投入までのリードタイム、モデルの入れ替え頻度、精度劣化の検知までの時間が主な対象です。

主な業務範囲

• 学習パイプラインの整備。データ取得から学習、評価、モデル登録までを自動で回す
• モデルの提供基盤。推論APIの構築、バッチ推論の実行環境、スケーリングを担当する
• 実験管理。パラメータ・データ・結果を記録し、後から再現できる状態にする
• 監視と再学習。入力データの分布の変化と精度の劣化を検知し、再学習の起動を設計する
• 権限とガバナンス。学習データの取り扱い、モデルの承認フロー、監査ログを整える

求められる能力

実務で問われるのは、クラウド・コンテナ・Kubernetes・CI/CD・IaC の経験です。加えて、機械学習のワークフローを理解していることが求められます。学習と推論で必要な資源が違うこと、データの前処理が推論時にも必要になることを踏まえた設計ができるかどうかで差が出ます。

もう一つ求められるのが、モデルを作る側の作業を観察して詰まりどころを見つける力です。この職種の利用者は社内のデータサイエンティストと機械学習エンジニアで、使ってもらえない基盤は成果になりません。

この職種に就く人のキャリア経路

多いのは SRE・インフラエンジニア・Platform Engineer からの移行です。運用の自動化を進めた延長で、機械学習の領域を担当する流れです。機械学習エンジニアが基盤側に軸足を移すケースもあります。

そこから先は、機械学習の基盤組織の責任者、Platform Engineer として対象を機械学習以外へ広げる道、データ基盤の責任者へ進む道に分かれます。

隣接職種との違い

採用担当の見極めポイント

• 求人票では、現在の機械学習の運用状況を書いてください。手作業で学習しているのか、パイプラインが動いているのかで、必要な経験が変わります
• 職務経歴書では、本番で動いている機械学習システムを担当した経験を確認してください。検証環境の構築までしか書かれていないなら、精度が落ちたときに何をしたかを聞いてください
• 社内にモデルを作る担当がいない状態でこの役割を採ると、基盤を使う人がいないまま整備だけが進みます。利用者の有無を募集前に確認してください

求人・市場の傾向

母集団は薄く、インフラの実務経験と機械学習の理解を両方持つ候補者は限られます。MLOps を「SRE」カテゴリに寄せている媒体では検索で数件しか出ませんが、それは母集団の薄さではなくカテゴリ設計の問題です。媒体では「SRE」「インフラエンジニア」「機械学習エンジニア」の職種カテゴリで引き、フリーワードに「MLOps」「Kubeflow」「推論基盤」を入れて絞る進め方が現実的です。

扱うモデルの数と推論のトラフィックを載せてください。この職種の難易度は、その2つでおおよそ決まります。

関連キーワード

MLOps / モデル監視 / 推論基盤 / 実験管理 / Kubernetes / データドリフト / 継続的学習 / CI/CD