MLflow 3で実験管理・モデルレジストリ・オートログ・GenAIトレースを本番運用。scikit-learn・PyTorch・FastAPIの実例と、champion/challengerエイリアス設計、遅延・コスト計測まで日本語で解説。
更新日: 2026年8月12日
MLflow 3は、Python機械学習プロジェクトの実験管理・モデルレジストリ・モデル配信・GenAIトレースを一元化するオープンソースのMLOpsプラットフォームです。バージョン3.0（2025年6月GA）で LoggedModel が第一級市民となり、従来のステージ制モデル管理はエイリアス（champion / challenger）ベースに刷新されました。本記事では、私が本番のレコメンドAPIやLLMゲートウェイで実際に運用してきた設計を踏まえ、scikit-learn・PyTorch・FastAPIを軸に、遅延・コスト・オンコール観点まで含めて解説します。
LoggedModelを中心に再設計され、Model Registry Stageは非推奨。エイリアスとタグで本番昇格を制御するmlflow.autolog()はscikit-learn・XGBoost・LightGBM・PyTorch・Transformers・Kerasなど主要フレームワークをコード変更ゼロで自動計測できるMLflow 3は、Databricks社が主導するオープンソースのMLOpsプラットフォームで、機械学習のライフサイクル全体を統合的に管理するために設計されています。2025年6月にGAされた3.0では、内部データモデルが大幅に見直され、学習された成果物を表すLoggedModelが第一級エンティティに昇格しました。これにより、同じrunから複数のモデルを派生させたり、モデルに直接メトリクスやパラメータを紐付けたりできるようになり、Deep Learningの試行錯誤やGenAIワークフローがはるかに扱いやすくなっています。
正直なところ、2.x系との差分は「Registryまわりの再設計」に尽きます。主な違いを整理すると次のとおりです。
LoggedModelAPIの導入。mlflow.log_model()が返すオブジェクトを介して、後からメトリクスを追記できる私自身、プロダクションで日次数千万リクエストのレコメンドAPIを運用しているのですが、旧Registry Stagesは「Productionは1件だけ」という制約が強くて、A/Bやカナリア配信を組む際に本当に不便でした。エイリアスに移行してからは、championとchallengerを同居させたり、地域ごとにchampion-jpのような別名を張ったりできるようになり、運用の柔軟性が段違いです。
ローカル検証だけならpip install mlflowで終わりますが、本番ではPostgreSQLをバックエンドストア、S3/GCS/Azure Blobをアーティファクトストアとする構成が2026年の実務標準です。SQLiteでも動くには動きます。ただし複数プロセスからの同時書き込みで詰まるので、開発以外では選ばないでください。
# uvが2026年の標準的なPython環境管理ツール。pipでも可
uv pip install "mlflow[extras]==3.1.*" psycopg2-binary boto3
# トラッキングサーバーの起動（本番想定）
mlflow server \
--backend-store-uri postgresql://mlflow:[email protected]:5432/mlflow \
--artifacts-destination s3://my-org-mlflow-artifacts/prod \
--serve-artifacts \
--host 0.0.0.0 \
--port 5000 \
--workers 4
クライアント側は環境変数MLFLOW_TRACKING_URIを設定するだけで、以降のPythonコードから透過的に使えます。私はKubernetes上でDeploymentとして動かし、S3のアーティファクトはVPCエンドポイント経由に絞ってセキュリティを担保しています。
import os
import mlflow
os.environ["MLFLOW_TRACKING_URI"] = "http://mlflow.internal:5000"
os.environ["MLFLOW_S3_ENDPOINT_URL"] = "https://s3.ap-northeast-1.amazonaws.com"
os.environ["AWS_PROFILE"] = "ml-prod"
mlflow.set_tracking_uri(os.environ["MLFLOW_TRACKING_URI"])
print(mlflow.get_tracking_uri())
MLflowの中核概念はExperiment（実験グループ）とRun（1回の学習実行）です。1つのExperimentに複数のRunがぶら下がり、各RunはParameter、Metric、Tag、Artifact、そしてLoggedModelを持ちます。基本的な使い方は次のとおりです。
import mlflow
import mlflow.sklearn
from sklearn.datasets import load_diabetes
from sklearn.ensemble import GradientBoostingRegressor
from sklearn.model_selection import train_test_split
from sklearn.metrics import mean_absolute_error, r2_score
# Experimentを作成または取得
mlflow.set_experiment("diabetes-gbr-baseline")
X, y = load_diabetes(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(run_name="gbr-v1") as run:
params = {"n_estimators": 300, "max_depth": 3, "learning_rate": 0.05}
mlflow.log_params(params)
model = GradientBoostingRegressor(**params, random_state=42).fit(X_tr, y_tr)
preds = model.predict(X_te)
mlflow.log_metric("mae", mean_absolute_error(y_te, preds))
mlflow.log_metric("r2", r2_score(y_te, preds))
mlflow.set_tag("dataset_version", "diabetes-2026-q3")
mlflow.set_tag("owner", "recsys-team")
logged = mlflow.sklearn.log_model(
sk_model=model,
name="model",
input_example=X_tr.head(3),
registered_model_name="diabetes-gbr",
)
print(f"run_id={run.info.run_id}, model_uri={logged.model_uri}")
上のコードで押さえておきたいポイントは3つあります。まず、input_exampleを渡すとMLflowが自動的にモデル署名（入出力スキーマ）を推論して保存します。これは後段のFastAPI連携で入力バリデーションに使えます。次に、registered_model_nameを指定すると同時にRegistryにも登録され、以降はエイリアス操作でデプロイを制御できます。最後に、tagはUIでのフィルタや検索に効きます。データセットバージョンやオーナーチームは必ずタグ付けしておくと、後日「あのモデルはどこの誰がどのデータで学習したか」がすぐに追えます（半年後の自分に感謝されるやつです）。
Optuna 4.0によるハイパーパラメータ最適化と組み合わせる場合、MLflowCallbackを経由してtrialごとに自動記録するのが定番パターンです。
実験のたびにlog_paramやlog_metricを手書きするのは面倒で、記録漏れの原因にもなります。mlflow.autolog()を呼ぶだけで、主要フレームワークのハイパーパラメータ・学習曲線・モデル・入出力サンプルまで自動的に記録されます。2026年8月時点でサポートされている主なフレームワークは以下のとおりです。
fitのパラメータ、CVスコア、モデル）import mlflow
import xgboost as xgb
from sklearn.datasets import fetch_california_housing
from sklearn.model_selection import train_test_split
mlflow.set_experiment("california-xgb-autolog")
mlflow.xgboost.autolog(log_datasets=True, log_input_examples=True)
X, y = fetch_california_housing(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():
dtrain = xgb.DMatrix(X_tr, label=y_tr)
dtest = xgb.DMatrix(X_te, label=y_te)
booster = xgb.train(
params={"objective": "reg:squarederror", "eta": 0.05, "max_depth": 6},
dtrain=dtrain,
num_boost_round=200,
evals=[(dtest, "test")],
early_stopping_rounds=20,
verbose_eval=False,
)
# ← このrunにはparams・iterationごとのRMSE・best_iteration・モデル・入力例が
# すべて自動記録される
MLflow Model Registryは、モデルのバージョン管理と環境昇格を担う中央リポジトリです。MLflow 3以降、旧Stagesの代わりにエイリアスとタグでデプロイ状態を表現します。命名は自由なので、組織に合わせたワークフローを設計できます。
from mlflow import MlflowClient
client = MlflowClient()
MODEL = "diabetes-gbr"
# バージョン7を「challenger」として指定（新規モデル）
client.set_registered_model_alias(MODEL, "challenger", version=7)
client.set_model_version_tag(MODEL, version=7, key="validation_status", value="pending")
# 検証OKなら「champion」を差し替える（本番デプロイ）
client.set_registered_model_alias(MODEL, "champion", version=7)
client.delete_registered_model_alias(MODEL, "challenger")
# ロールバックはエイリアス貼り替えだけで数秒
client.set_registered_model_alias(MODEL, "champion", version=6)
推論サービスからはmodels:/<name>@<alias>形式のURIで参照します。champion差し替えは即座に有効になるので、CI/CDからset_registered_model_aliasを呼ぶだけでロールバック時間は数秒です。私のチームではArgo Workflowsから毎晩再学習を回し、シャドウ評価を通過した場合のみエイリアスを昇格するようにしています。
import mlflow.pyfunc
# 常に本番モデルをロード
model = mlflow.pyfunc.load_model("models:/diabetes-gbr@champion")
# シャドウ推論用のchallenger
try:
challenger = mlflow.pyfunc.load_model("models:/diabetes-gbr@challenger")
except Exception:
challenger = None
MLflowが記録したモデルはmlflow.pyfunc.load_model()で読み込めるため、任意のPython Webフレームワークから配信できます。もっとも汎用性が高いのはFastAPIとの組み合わせです。以下は本番向けの最小構成です。
from contextlib import asynccontextmanager
from fastapi import FastAPI
from pydantic import BaseModel
import mlflow.pyfunc
import pandas as pd
MODEL_URI = "models:/diabetes-gbr@champion"
state: dict = {}
@asynccontextmanager
async def lifespan(app: FastAPI):
# 起動時にロード、メモリ常駐（fork-safe）
state["model"] = mlflow.pyfunc.load_model(MODEL_URI)
yield
state.clear()
app = FastAPI(lifespan=lifespan)
class Features(BaseModel):
age: float
bmi: float
bp: float
s1: float; s2: float; s3: float; s4: float; s5: float; s6: float
sex: float
@app.post("/predict")
def predict(features: Features):
df = pd.DataFrame([features.model_dump()])
yhat = state["model"].predict(df)
return {"prediction": float(yhat[0])}
詳細な本番配信パターンは FastAPI × scikit-learn 機械学習モデル本番デプロイガイド にまとめていますが、MLflow由来のモデルには次の追加パターンが有効です。
championを再ロードし、無停止でモデル更新challengerにも推論させてログだけ取り、実トラフィックで比較ModelSignatureをPydanticスキーマに落として自動検証より重い推論ワークロードや自動バッチングが必要な場合は、BentoMLやRay Serve、KServeとの組み合わせも選択肢に入ります。bentoml.mlflow.import_model()を使えばMLflowレジストリからBento Runnerに直接取り込めます。
実験管理ツールの選定は、ライセンス・データ主権・GenAI対応度・コストで決まることが多いです。私が2026年時点で評価した主要ツールの比較を掲載します。
| 項目 | MLflow 3 | Weights & Biases | Neptune.ai | Comet |
|---|---|---|---|---|
| ライセンス | Apache 2.0 OSS | SaaS（有償） | SaaS（有償） | SaaS + OSS SDK |
| セルフホスト | ◎ 標準機能 | △ Enterpriseのみ | ○ On-Prem有償 | ○ On-Prem有償 |
| モデルレジストリ | ◎ エイリアス/タグ | ◎ Artifacts | ○ Model Registry | ○ Model Registry |
| GenAI・LLM Tracing | ◎ 3.0でGA | ◎ Weave統合 | △ 発展途上 | ○ LLMOps機能あり |
| ハイパラ探索連携 | Optuna/Hydra手動 | ◎ Sweep内蔵 | Optuna連携 | Optimizer内蔵 |
| データ主権 | ◎ 完全に自社 | × 外部SaaS | × 外部SaaS | × 外部SaaS |
| 年間コスト（10人） | インフラ費のみ | 約50万〜300万円 | 約30万〜150万円 | 約30万〜100万円 |
私の推奨は明確です。データを社外に出したくない金融・医療・製造業ではMLflowほぼ一択。逆にスタートアップでスピード最優先ならW&Bのマネージドが工数削減効果は大きいです。ハイブリッド構成として、日次ジョブはMLflow、GenAI開発チームだけW&B Weaveを併用しているケースも増えました。
MLflow 3の目玉は、従来型のML実験管理にとどまらずGenAI（LLM）ワークロードまで統合された点です。mlflow.langchain.autolog()やmlflow.openai.autolog()を有効化するだけで、LangChainチェーンやOpenAI/Anthropic APIコールが自動的にトレースされ、レイテンシ・トークン使用量・プロンプト・レスポンスがUIで可視化できます。
import mlflow
from openai import OpenAI
mlflow.set_experiment("rag-support-bot")
mlflow.openai.autolog() # 自動トレース有効化
# プロンプトをレジストリで管理（バージョン付き）
mlflow.register_prompt(
name="support_system_prompt",
template=(
"あなたはPythonデータ分析の専門家です。以下のコンテキストのみを"
"根拠に、日本語で200字以内で回答してください。\n"
"コンテキスト: {{context}}\n\n質問: {{question}}"
),
commit_message="v1: 200字制限を追加",
)
prompt = mlflow.load_prompt("prompts:/support_system_prompt/1")
client = OpenAI()
with mlflow.start_run(run_name="rag-eval-2026-08"):
resp = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "system",
"content": prompt.format(
context="pandas 3.0のpipe()はメソッドチェーンに使える",
question="pipe()の使い方は？",
),
}],
)
# ← トレースには全メッセージ・入出力トークン・レイテンシ・モデル名が記録される
プロダクションでLLMを扱う上で、このトレースの粒度は本当に効きます。私が運用しているLLMゲートウェイでは、ゲートウェイ層の DuckDB分析パイプライン でMLflowのトレースをエクスポートし、日次でp99レイテンシとコストを分析しています。プロンプトのバージョン管理と組み合わせると、「プロンプトv3に上げたら平均トークンが1.4倍に増えた」といった回帰も即座に検知できます（先月これで痛い目を見たので…）。
ここでは、私が数年間MLflowを本番運用して得た知見を、失敗談も交えて共有します。
autologを有効にすると、学習ごとにモデルバイナリと入力例が保存されます。Transformerの大規模モデルだと1runで数GB単位になることも珍しくありません。対策として、run単位のTTL（例：30日で自動削除）をS3のライフサイクルポリシーで設定し、Registryに登録済みバージョンだけ長期保存する運用が現実的です。
MLflow ModelsのSignatureは Pandera と組み合わせることで、推論時の入力スキーマドリフトを即座に検知できます。学習時と推論時のカラム型がずれるのは、私の観測範囲でML障害の最頻出パターンです。ほんとに多い。
「精度は上がったがp99レイテンシが3倍」というのは避けたい失敗です。MLflowにinference_latency_msやpeak_memory_mbもメトリクスとして記録し、精度と同じダッシュボードで比較する習慣を作ってください。GPU推論ならgpu_util_pctやvram_gbも忘れずに。
MLflow OSSにはRBACが未搭載です（Databricks版にはあります）。認証はOAuth2 Proxyで、書き込み権限はネットワーク層かNginxのURIマッチで制御するのが定番です。MLflow公式の認証プラグインもありますが、SSO統合が必要ならリバースプロキシ方式のほうが素直です。
数十人規模で運用するとPostgreSQLのrunsやmetricsテーブルが数億行に膨らみます。パーティショニングと、archive済みExperimentの物理削除（mlflow gcコマンド）を月次で回すのを忘れないでください。私は最初これを怠り、UI表示が10秒以上かかる状態になった経験があります（オンコール中にダッシュボードが開かないのは地味に辛い）。
2.x時代のStagingやProductionといったステージは、MLflow 3でも一時的に読み取れますがdeprecated扱いです。移行スクリプトで各バージョンに対応するエイリアス（例：Production→champion）を張り、旧APIの呼び出しをset_registered_model_alias()に置き換えるのが公式推奨のパスです。バージョン3.2以降で旧API自体が削除される予定なので、余裕を持って移行してください。
スコープが違います。MLflowは実験管理・モデル管理・軽量な配信、KubeflowはK8s上のパイプラインオーケストレーションが主眼です。実務ではKubeflow Pipelines（またはArgo Workflows）でDAGを回し、各コンポーネントの中でMLflowに記録するのが一般的な組み合わせです。既存のk8s資産があるならKubeflowを検討、なければMLflow単独＋Prefect等でも十分回ります。
はい。バックエンドストア（PostgreSQL/MySQL）とアーティファクトストア（S3/GCS/Azure Blob/ローカルFS）の抽象化がしっかりしているため、AWS・GCP・Azure・オンプレのMinIOなど、環境を選ばず動きます。私はハイブリッド構成で、開発クラスタはGCP、本番はオンプレというケースを運用したことがありますが、モデルURI（models:/...）で参照する限りアプリケーション側は環境差を意識する必要がありません。
組み込みではありませんが、codecarbonやnvidia-ml-pyと組み合わせてmlflow.log_metric()で記録できます。私はCallback経由でエポックごとにVRAM使用量とkWhを記録し、精度向上と環境負荷のトレードオフをダッシュボード化しています。2026年はESG観点でモデル学習のCO2見積もりを要求されるケースも増えており、記録しておいて損はありません。
MLflow自体はTLS終端をしないので、前段にNginxやTraefik、あるいはCloudflare Tunnelを置くのが実務的な解です。オンプレの社内システムであればOAuth2 Proxy＋Google/AzureADのOIDC連携が定番で、追加でBASIC認証を挟めばアーティファクトダウンロード用のCLIアクセスも制御できます。Kubernetes上ならIngress ControllerでcertManagerと組み合わせるのが最短ルートです。
SQLMeshで仮想データ環境と自動バックフィルを実現するデータ変換フレームワークの実践ガイド。dbtとの違い、DuckDBで3分で始める初期化、PythonモデルとCI連携までを本番運用視点で解説します。
Narwhalsはpandas・Polars・PyArrow・cuDF等に統一APIを提供する依存関係ゼロのデータフレーム抽象化ライブラリ。@narwhalifyデコレータで既存関数を簡単にバックエンド非依存化できます。
Optuna 4.0でMLモデルのハイパーパラメータを自動最適化。TPEサンプラー、Pruner、RDB分散実行、多目的最適化、Dashboardまで、KaggleとProdで使ったコードで実践解説します。