機械学習をチームで進めると、「あのモデルどのデータで学習したっけ」「学習率0.001のときの精度って、メモどこ？」が常態化する。Jupyterのセル実行に頼った属人的な記録はすぐ限界に来る。MLflowは、実験追跡とモデル管理の問題を最初に正面から解いたOSSで、いまや事実上標準だ。
Databricksが2018年に開発を始め、いまはLinux Foundation傘下のOSSとして広く採用されている。Pythonとの統合がスムーズで、数行のコードで実験ログが取れる。基本構造と使い方を整理する。
MLflowの4コンポーネント
| コンポーネント | 役割 |
|---|---|
| Tracking | 実験のパラメータ・メトリクス・成果物を記録 |
| Projects | コードと環境をパッケージ化して再現可能に |
| Models | 学習済みモデルを共通形式で保存・読み込み |
| Model Registry | モデルのバージョン管理とステージング |
多くのチームはTrackingとModel Registryから使い始め、必要に応じてProjectsとModelsに広げます。
最小の実験ログ
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score
mlflow.set_experiment("customer_churn")
with mlflow.start_run():
# ハイパーパラメータをログ
n_estimators = 100
max_depth = 10
mlflow.log_param("n_estimators", n_estimators)
mlflow.log_param("max_depth", max_depth)
# 学習
model = RandomForestClassifier(n_estimators=n_estimators, max_depth=max_depth)
model.fit(X_train, y_train)
# メトリクスをログ
preds = model.predict(X_test)
acc = accuracy_score(y_test, preds)
mlflow.log_metric("accuracy", acc)
# モデルを保存
mlflow.sklearn.log_model(model, "model")これだけで、パラメータ・メトリクス・モデル本体はMLflow Tracking Serverに記録される。UIから過去の実験を一覧でき、ベストモデルを後から選び直せる。
Model Registry：本番への昇格管理
学習しただけでは「実験のひとつ」に過ぎません。それを「本番モデル」として管理するのがModel Registryです。
# モデルをRegistryに登録
mlflow.register_model(
model_uri="runs:/<run_id>/model",
name="customer_churn_model"
)
# Stageを変更（None → Staging → Production → Archived）
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
name="customer_churn_model",
version=3,
stage="Production"
)「Staging」「Production」「Archived」のステージで、モデルのライフサイクルを管理します。「いまProduction扱いのモデルは、どのバージョンか」が常に追跡でき、ロールバックも明確になります。
MLflow Tracking Serverの構成
| 要素 | 役割 |
|---|---|
| Tracking Server | UIとAPIを提供 |
| Backend Store | メタデータ（MySQL/Postgres/SQLite） |
| Artifact Store | モデル・成果物（S3/GCS/Azure Blob等） |
個人開発ならローカルファイルで済むが、チーム運用ではTracking Serverを共有で立てるのが定石だ。MetadataはMySQLやPostgres、Artifactsはオブジェクトストレージに置く構成が標準的である。
クラウドMLOpsとの統合
主要クラウドのマネージドMLOpsは、MLflow互換のTrackingまたはMLflowそのものを内蔵する。
| サービス | MLflowとの関係 |
|---|---|
| Databricks | MLflowをマネージドで提供（開発元） |
| Azure ML | MLflow Tracking API互換 |
| SageMaker | SageMaker MLflowで対応 |
| Vertex AI | Vertex AI Experimentsが類似機能 |
「MLflow APIで書いておけば、後でクラウドに移しても動く」というのが大きな利点です。クラウドMLOpsの比較はクラウドMLOpsプラットフォーム比較を参照してください。
運用上のハマりどころ
- Artifactsの肥大化：すべてのRunのモデルを残すと、ストレージが膨らむ。古いRunの自動削除ポリシーを設計する。
- 共有Tracking Serverの認証：本番運用では認証が必須。OSS版だけでは弱く、リバースプロキシ等で補強する。
- UIのスケール限界：実験数が10万を超えるあたりからUIが重くなる。フィルタリングと古いRunのアーカイブで対処。
- Tagsの命名規約：チームごとにバラバラだと検索しづらい。組織として命名ルールを決める。
向く・向かない場面
- 向く：実験追跡をすぐ始めたい、PythonとSparkが中心、ベンダーロックインを避けたい、Databricksユーザー
- 向かない：クラウドのマネージドで全部済ませたい（→クラウドMLOps）、Python以外の言語が主、特徴量管理が中心の課題（→Feast）
まとめ
- MLflowは実験追跡とモデルレジストリのOSS事実上標準。
- Tracking・Projects・Models・Model Registryの4コンポーネント。
- 数行のコードで実験ログが取れ、UIで一覧・比較・選別できる。
- 主要クラウドのMLOpsとAPI互換があり、移植性が高い。
- 「まず実験追跡から始める」というMLOps入門の最初の一歩として最適。
全体像はMLOpsツール選び方ガイド、隣接の選択肢はFeast とは・クラウドMLOpsプラットフォーム比較にあります。MLflow導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. MLflowはDatabricks前提ですか？
A. いいえ、OSSなのでDatabricks無しでも動く。Linux Foundation傘下のOSSで、独立して使える。DatabricksはMLflowのマネージド版を提供しており、Databricksユーザーには深い統合があるという話で、必須ではない。
Q. dbtテストとMLflowは関係ありますか？
A. 別レイヤーだが補完的だ。dbtテストはデータの品質を保証し、MLflowは「そのデータで学習したモデル」のメタデータを記録する。データの変更がモデル精度に与える影響を追跡するには、両者の連携設計が要る。dbtの基本はdbt実装ガイド、テスト設計はdbt tests 実践を参照してください。
Q. Weights & BiasesやNeptune.aiとの違いは？
A. W&BやNeptune.aiは商用SaaSで、UIや可視化、コラボ機能でMLflowを上回る。MLflowはOSSで自社内に閉じられること、Databricksとの統合が強いことが優位点だ。データ流出が許容できない・OSS志向ならMLflow、UXとクラウド機能を優先するなら商用、と分かれる。
Q. モデルサービングもMLflowで完結しますか？
A. MLflowにはモデルをローカルやDockerでサービングする機能はあるが、本番運用に直接堪える機能ではない。実際は、MLflowからモデルを取り出し、SageMaker/Vertex AI/KServeなどの専用サービング基盤にデプロイする構成が現実的だ。「モデルレジストリはMLflow、サービングは専用基盤」と役割を分ける。