MLOpsとは？DevOpsとの違い・成熟度レベル0〜2・主要ツールとMLflowで始める手順【2026年10月】

MLOps（Machine Learning Operations、読みは「エムエルオプス」）は、機械学習モデルを本番環境で使い続けるために、学習・登録・デプロイ・監視・再学習を一つの流れとして管理する考え方と、それを支えるツール群です。モデルの予測性能は、学習時と本番でデータの傾向が異なると低下することがあります。この記事では、DevOpsとの違い、Google Cloudが示す成熟度レベル0〜2、2026年10月時点の主要ツールの選び方を整理し、MLflowとドリフト検知の最小構成を実際に動かすコードまで示します。

まとめ：MLOpsの定義と始め方の要点

• MLOpsが管理する対象はコード・データ・モデルの3つです。DevOpsのCI/CDに、新しいデータでモデルを自動で学習し直す継続的トレーニング（CT）が加わります。
• Google Cloudの文書は成熟度を3段階に分けています。手動のレベル0、学習パイプラインを自動化するレベル1、パイプライン自体のCI/CDまで自動化するレベル2です。
• 最初に入れるのは実験の記録とモデルレジストリです。MLflow 3.17.2なら数十行で、学習の記録・モデル登録・本番版の切り替えまで動きます。
• ツールはクラウドが決まっていればそのマネージドサービス（SageMaker AI、Gemini Enterprise Agent Platform、Azure Machine Learning）、決まっていなければMLflowを起点にします。Kubeflowは Kubernetes を運用できる体制があるときだけ選びます。
• モデルが1本で更新が年に数回でも、評価と切り戻しの手順は必要です。手動更新で必要な品質と対応時間を満たせるなら、パイプラインの自動化は見送れます。

MLOpsの定義：機械学習モデルを本番で更新し続けるための仕組み

機械学習システムのうち、学習アルゴリズムを書くコードが占める割合はわずかです。Googleの研究者らによる2015年の論文「Hidden Technical Debt in Machine Learning Systems」は、実運用のMLシステムでMLコードはごく一部（small fraction）にすぎず、周囲をデータ収集・特徴量抽出・検証・サービング基盤・監視などが大きく取り囲んでいる図を示しました。MLOpsは、この周囲の部分を整備して、モデルを一度作って終わりにしないための実践です。

Google CloudのMLOpsのアーキテクチャ文書は、MLシステムの継続的インテグレーション（CI）、継続的デリバリー（CD）、継続的トレーニング（CT）の実装と自動化を扱い、主に予測AIシステムに適用されると明記しています。需要予測・不正検知・レコメンドのように、表形式や画像のデータでモデルを学習し、予測を返すシステムが中心です。生成AIのアプリケーションで必要になるプロンプトの版管理やトレースは、MLOpsから派生したLLMOpsの領域になります。

DevOpsとの違い：コード・データ・モデルの管理対象

DevOpsはコードの変更を素早く安全に本番へ届ける仕組みです。MLOpsもCI/CDを土台にしますが、コードを1行も変えなくても、入力データの性質が変わるだけでモデルの予測は外れ始めます。この違いから、管理対象・テスト・リリースの契機が次のように広がります。

担い手が増える点は見落とされがちです。Google Cloudの文書は、手動運用の段階ではモデルを作るデータサイエンティストと、予測サービスとして提供するエンジニアが分断され、学習時と本番で特徴量の作り方がずれる「トレーニング サービング スキュー」が起きうると指摘しています。MLOpsの仕組みの多くは、この受け渡しを人の手から外すためのものです。

MLOpsのライフサイクルと4つの構成要素

Google Cloudの文書は、モデルを本番に届ける工程をデータ抽出、データ分析、データ準備、モデルの学習、評価、検証、サービング、監視の8つに分け、これらをどこまで自動化したかで成熟度が決まるとしています。実務では次の4つの部品に分けて考えると、何から入れるかを決めやすくなります。

実験管理とモデルレジストリ：学習条件の記録と版管理

実験管理は、学習のたびにパラメータ・評価指標・成果物を記録する仕組みです。例えばMLflowでは、これらをrun単位で記録し、登録モデルの各版から元のrunを参照できます。モデルレジストリは、登録したモデルに版番号を振り、どの版が本番で動いているかを管理します。この2つがないと、精度が落ちたときに「先月のモデルを何で作ったか」をたどれません。記録項目とrunの設計は実験管理とは？記録項目とrun設計・導入判断を実装目線で解説、版管理と本番昇格の設計はモデルレジストリとは？モデル版管理と本番昇格の設計で詳しく扱っています。

特徴量ストア：学習と推論の特徴量定義の共通化

特徴量ストアは、特徴量の定義と値を一か所に集め、学習用のバッチ取得と推論用の低レイテンシ取得の両方に同じ定義で提供する仕組みです。Google Cloudの文書はレベル1のオプション部品に位置づけています。前述のトレーニング サービング スキューを防ぐのが主な役割なので、学習と推論で別々のSQLやコードが特徴量を作っている組織ほど効果が大きくなります。

デプロイとサービング：検証済みモデルの本番公開

サービングの形はREST APIでのオンライン予測、端末への組み込み、バッチ予測の3通りです。オンライン予測では、新しいモデルを一部のトラフィックだけに当てるカナリアリリースやA/Bテストで確かめてから切り替えます。工程と切り戻しの判断はモデルデプロイとは？本番へ出す6工程と段階公開・切り戻しの判断基準、推論サーバーの選定はモデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を参照してください。

監視と再学習：データ変化の検知とモデル更新

本番では正解ラベルがすぐには手に入らないことが多く、精度そのものより先に、入力データの分布が学習時からずれていないか（データドリフト）を監視します。Google CloudのMLOps文書では、データ分布の変化を再学習の起動条件の一つに挙げています。検知時はデータ品質を確認し、評価を通った版だけを本番へ反映します。この「検知→再学習→評価→昇格」の輪を自動で回すのが継続的トレーニングです。指標としきい値の決め方はモデルモニタリングとは？ドリフト検知の仕組み・指標・しきい値設計で解説しています。

成熟度レベル0〜2の要件と導入段階

Google Cloudの文書は、自動化の度合いでMLOpsを3段階に分けています。レベル0では新しいモデルの版が年に数回しかデプロイされないことを前提とし、CIもCDも考慮されません。自社がどこにいて、次に何を足せばよいかを表にまとめます。

レベル1の要件は、パイプラインにデータとモデルの自動検証、パイプラインの起動条件（トリガー）、メタデータの管理を組み込むことです。レベル2は、特徴量や学習コードの変更を頻繁に本番へ出す組織、本番で多数のパイプラインを抱える組織が対象です。モデル1本を数か月に一度更新する段階でレベル2を目指す必要はありません。

MLflowで最小のMLOpsを動かす手順

レベル0から1へ進む最初の一歩は、学習の記録とモデルの登録を自動化することです。ここではOSSのMLflow（2026年10月21日公開の3.17.2）とscikit-learnで、記録→登録→本番版の指定→読み込みまでを1本のスクリプトで動かします。以下のコードはPython 3.12・MLflow 3.17.2・scikit-learn 1.9.1・SciPy 1.18.1・NumPy 2.5.4で実行し、出力を確認したものです。

MLflowによる学習結果の記録とモデル登録

MLflowのモデルレジストリを使うには、データベースを持つバックエンドストアが必要だと公式ドキュメントに書かれています。手元で試すならSQLiteのファイルで足ります。例として使うのはscikit-learn付属の乳がん診断データ（二値分類）で、F1は良性（ラベル1）を陽性として計算します。昇格基準の0.95は手順を示すための仮の値で、実務では現行の本番版の成績と比べて決めます。

pip install mlflow==3.17.2 scikit-learn==1.9.1 scipy==1.18.1 numpy==2.5.4

import mlflow
from mlflow import MlflowClient
from sklearn.datasets import load_breast_cancer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("sqlite:///mlflow.db")
mlflow.set_experiment("mlops-demo")

X, y = load_breast_cancer(return_X_y=True, as_frame=True)
X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.2, random_state=42)

with mlflow.start_run() as run:
    params = {"C": 0.5, "max_iter": 5000}
    model = LogisticRegression(**params).fit(X_tr, y_tr)
    f1 = f1_score(y_te, model.predict(X_te))
    mlflow.log_params(params)
    mlflow.log_metric("f1", f1)
    info = mlflow.sklearn.log_model(
        model, name="model", input_example=X_tr.head(3),
        registered_model_name="bc-classifier",
    )
    print("run_id:", run.info.run_id, "f1:", round(f1, 4))

client = MlflowClient()
version = info.registered_model_version
if f1 >= 0.95:
    client.set_registered_model_alias("bc-classifier", "champion", version)
    print("champion ->", version)
else:
    raise SystemExit("F1 is below 0.95; this example stops without promotion")

loaded = mlflow.pyfunc.load_model("models:/bc-classifier@champion")
print(loaded.predict(X_te.head(3)))

初回の実行では Created version '1' of model 'bc-classifier'. と表示され、F1スコア0.9722で基準の0.95を超えたため版1に champion が付きます。同じスクリプトをもう一度実行すると版2が作られ、champion は版2へ移ります。推論側のコードは models:/bc-classifier@champion を指定すれば、読み込み先の版が変わってもURIの書き換えは不要です。ただし、読み込み済みのモデルはaliasの変更だけでは切り替わらないため、推論プロセスで再読み込みする必要があります。

本番版の切り替え：stagesからaliasへの移行

古い解説記事では、モデルの版を「Staging」「Production」のステージへ遷移させる方法が紹介されています。この transition_model_version_stage はMLflow 2.9.0から非推奨で、ドキュメントは将来のメジャーリリースで削除すると予告しています。代わりに使うのが上のコードのalias（別名）とtagです。aliasは1つの版に複数付けられるので、champion と challenger を並べてA/Bテストをする運用にも向きます。いまstagesで組んでいる場合は、新規の昇格処理からaliasへ置き換えてください。

入力データのドリフト検知：PSIとKS検定

監視の最小構成は、学習時の特徴量の分布と、直近の本番入力の分布を比べることです。次のコードは、分布の差を1つの数値にまとめるPSI（Population Stability Index）と、2標本のKS検定を計算します。

import numpy as np
from scipy.stats import ks_2samp

def psi(expected, actual, bins=10):
    expected, actual = np.asarray(expected, float), np.asarray(actual, float)
    if not (np.isfinite(expected).all() and np.isfinite(actual).all()):
        raise ValueError("drop NaN and inf before computing PSI")
    edges = np.quantile(expected, np.linspace(0, 1, bins + 1))
    if np.any(np.diff(edges) == 0):
        raise ValueError("repeated quantiles: use category-wise bins for this feature")
    edges[0], edges[-1] = -np.inf, np.inf
    e = np.histogram(expected, edges)[0] / len(expected)
    a = np.histogram(actual, edges)[0] / len(actual)
    e, a = np.clip(e, 1e-6, None), np.clip(a, 1e-6, None)
    return float(np.sum((a - e) * np.log(a / e)))

rng = np.random.default_rng(0)
train = rng.normal(50, 10, 5000)
same = rng.normal(50, 10, 5000)
shifted = rng.normal(56, 12, 5000)

for name, cur in [("same", same), ("shifted", shifted)]:
    stat, p = ks_2samp(train, cur)
    print(f"{name}: PSI={psi(train, cur):.3f} KS={stat:.3f} p={p:.2e}")

same: PSI=0.005 KS=0.026 p=7.55e-02
shifted: PSI=0.328 KS=0.228 p=4.30e-114

同じ分布から取ったデータではPSIが0.005、平均を50から56、標準偏差を10から12へ変えたデータでは0.328となりました。KS検定のp値は件数が多いとわずかな差でも小さくなるので、アラートの判定にはPSIのような大きさの指標を使い、しきい値は自社の過去データで平常時のPSIを数週間分測ってから決めます。特徴量が数十を超えたら、ドリフトの集計とレポートをまとめて出せるEvidently（2026年9月11日公開の0.7.23）のようなライブラリに置き換えると管理が楽になります。

関数の冒頭の2つの検査は、見逃しを防ぐためのものです。値が1種類しかない特徴量では分位点が重なり、検査なしで計算すると「学習時はすべて1、本番はすべて2」という明らかな変化でもPSIが0になります。上のコードはこの場合に例外で止まるので、カテゴリ値や定数に近い特徴量は値ごとの比率で比べてください。

主要MLOpsツールの選び分け（2026年10月時点）

MLOpsのツールは、全工程を1つのクラウドで賄うマネージドサービスと、部品ごとに組み合わせるOSSに分かれます。製品名は変更されることがあるため、以下の表では現名称と改称時期を併記します。

AWSのドキュメントによると、SageMakerは2024年12月3日にSageMaker AIへ改称されましたが、APIの名前空間は互換性のため変わっていません。Google Cloudは2026年4月22日のリリースノートでVertex AIをGemini Enterprise Agent Platformへ改称し、Vertex AI TrainingはAgent Platform Managed Training、Vertex AI EndpointsはAgent Platform Endpointsという名前になりました。Azure Machine Learningはモデル登録でワークスペースにモデルを版付きで保存し、マネージドオンラインエンドポイントでCPU・GPUの推論環境をフルマネージドで動かせます。

選び方は次の順で判断します。

• 利用するクラウドが決まっている：そのクラウドのマネージドサービスを使う。学習データと同じクラウドを選べば、クラウド間のデータ転送や接続設定を避けやすくなります（SageMaker AI、Vertex AI、Azure Machine Learningの各記事を参照）。
• マルチクラウドやオンプレミスで動かす、またはクラウドを決めていない：MLflowで記録とレジストリを先に固め、推論は既存のコンテナ基盤に載せる。
• Kubernetesのクラスターを運用するチームがいる：パイプラインと学習ジョブをKubeflowで統一する（Kubeflowとは？Kubernetes上の機械学習基盤の全体像）。

実験管理・パイプライン・監視の各カテゴリでの製品ごとの比較は、MLOpsツール比較｜実験管理・パイプライン・監視の主要スタックと選定基準にまとめています。

MLOpsを導入すべき条件と見送る判断

MLOpsの仕組みは、モデルの更新回数と本番モデルの本数が増えるほど効果が大きくなります。次のいずれかに当てはまるなら、レベル1の自動化まで進める価値があります。

• 入力データが季節・価格・ユーザー行動などで変わり、必要な再学習を手作業では予定どおりに実施できない
• 本番モデルの版と学習データの対応を手作業で管理しており、取り違えや確認漏れが起きている
• モデルの予測が売上や審査など業務判断に直結し、誤りの原因を後から説明する必要がある

逆に、モデルが1本で更新が年に数回、バッチ予測の結果を人が確認してから使う運用なら、パイプラインの自動化は見送ってかまいません。前述のMLflowによる記録・登録に、更新時のモデル評価と切り戻し手順を組み合わせます。監視頻度は、入力の変化速度と異常を見逃せる時間から決めます。

避けるべき設計は次の2つです。1つ目は、モデルが本番に1本も出ていない段階でKubeflowなどの基盤から構築し、運用できる人がいないまま放置されるケースです。2つ目は、監視と評価の基準を決めずに再学習だけを自動化するケースで、異常なデータで学習したモデルが検証を通らずに本番へ出てしまいます。自動化は必ず「評価を通った版だけを昇格させる」条件とセットで入れてください。モデルの開発から運用の設計までを外部に相談したい場合は、機械学習モデル開発の支援も行っています。

よくある質問

MLOpsとAIOpsはどう違うのですか？

MLOpsは機械学習モデルを作って運用するための実践で、対象はモデルそのものです。AIOpsはITシステムの運用にAIを使う考え方で、ログやメトリクスから障害の予兆や原因を見つけることが目的です。詳しくはAIOpsとは？MLOps・DataOpsとの違いと役割分担で解説しています。

MLOpsとLLMOpsの違いは何ですか？

LLMOpsは大規模言語モデルを使うアプリケーションの運用に特化した領域です。自前でモデルを学習しないことが多く、管理対象がプロンプトの版、応答のトレース、評価データセット、トークン単位のコストに移ります。MLOpsのモデルレジストリや監視の考え方はそのまま使えます。

MLOpsエンジニアはどんな仕事をしますか？

データサイエンティストが作ったモデルを本番で動かし続けるための基盤を作る役割です。学習パイプラインの構築、モデルレジストリとデプロイの自動化、ドリフト監視の設計、推論環境のコスト管理が主な業務で、Pythonに加えてコンテナやクラウドの運用経験が求められます。

小規模なチームでもMLOpsは必要ですか？

本番で使うモデルが1本でもあれば、実験の記録とモデルの版管理は入れておくべきです。MLflowは1台のPCとSQLiteファイルで試せます。チームで運用する場合は、共有方法、アクセス制御、データベースとモデル成果物のバックアップも設計します。パイプラインの自動化は、再学習の頻度に加えて、手作業の負担、更新ミスの影響、必要な復旧時間から判断します。

MLOpsを学ぶには何から読めばよいですか？

全体像はGoogle CloudのMLOps文書（レベル0〜2の定義）と、2015年の論文「Hidden Technical Debt in Machine Learning Systems」でつかめます。手を動かすなら、この記事のMLflowのコードを実行し、モデルの版とaliasがどう動くかをMLflowのUI（mlflow ui --backend-store-uri sqlite:///mlflow.db）で確かめるのが近道です。

関連記事

• MLOpsツール比較｜実験管理・パイプライン・監視の主要スタックと選定基準
• LLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理の実装を解説【2026年版】
• モデルレジストリとは？モデル版管理と本番昇格の設計・採用判断を実装者目線で解説【2026年版】
• モデルモニタリングとは？ドリフト検知の仕組み・指標・しきい値設計を実装目線で解説【2026年版】
• Kubeflowとは？Kubernetes上の機械学習基盤の全体像とPipelinesの使い方