💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

なぜMLflow 2.x運用ガイドが必要なのか

MLflowは月間1,400万回以上ダウンロードされ、オープンソースの実験トラッキングツールの事実上の標準となった。インストールして`mlflow.autolog()`を呼び出すまでは簡単だ。問題はその先だ。チームが大きくなり実験が数千個を超えると、実験命名規則の不在、アーティファクトストレージ容量の爆発的増加、モデル昇格プロセスの混乱といった運用課題が発生する。

本記事では、MLflow 2.x（2.9〜2.18）および3.x初期バージョンまでを含め、プロダクションレベルで実験トラッキングとモデルレジストリを設計・運用する実践パターンを扱う。ローカル実習ではなく、チーム単位の運用を前提に作成した。

アーキテクチャ設計：トラッキングサーバーとアーティファクトストアの分離

コアコンポーネント

MLflowのプロダクションアーキテクチャは3つのレイヤーに分離すべきだ。

1. **Tracking Server**：実験メタデータ（パラメータ、メトリクス、タグ）を保存。PostgreSQLまたはMySQLバックエンドを使用。

2. **Artifact Store**：モデルバイナリ、データセット、可視化ファイルを保存。S3/GCS/Azure Blobを使用。

3. **Model Registry**：モデルバージョン管理、エイリアス、ステージ遷移。Tracking Serverと同一DBを使用。

プロダクショントラッキングサーバー起動コマンド

mlflow server \

--backend-store-uri postgresql://mlflow_user:${DB_PASSWORD}@db.internal:5432/mlflow_prod \

--default-artifact-root s3://company-mlflow-artifacts/prod/ \

--artifacts-destination s3://company-mlflow-artifacts/prod/ \

--host 0.0.0.0 \

--port 5000 \

--workers 4 \

--gunicorn-opts "--timeout 120 --keep-alive 5"

アーティファクトストア設定時の注意事項

S3をアーティファクトストアとして使用する際、クライアントとサーバーの両方で`MLFLOW_S3_ENDPOINT_URL`を設定するとパス衝突が発生する。サーバー側では`--default-artifact-root`でパスを指定し、クライアントはこの環境変数を設定しないのが原則だ。

クライアント側の設定（正しい方法）

トラッキングサーバーURIのみ設定。アーティファクトパスはサーバーが管理。

os.environ["MLFLOW_TRACKING_URI"] = "http://mlflow.internal:5000"

S3認証はIAM Role使用推奨（EC2/EKS環境）

ローカル開発時のみcredential明示

os.environ["AWS_PROFILE"] = "mlflow-dev"

mlflow.set_experiment("/team-search/ranking-model-v3")

GCSを使用する場合は`gs://bucket/path`形式で指定し、プロダクションではService Account Keyの代わりにWorkload Identityを使用すべきだ。アーティファクトのアップロード/ダウンロードタイムアウトは`MLFLOW_ARTIFACT_UPLOAD_DOWNLOAD_TIMEOUT`環境変数で制御し、GCSのデフォルトは60秒だ。大容量モデルチェックポイントを扱う場合、この値を300秒以上に引き上げる必要がある。

実験トラッキング設計パターン

実験命名戦略

実験名は`/{team}/{project}/{experiment-type}`パターンを使用する。フラットな命名は実験が100個を超えると管理不能になる。

良い例：階層的な命名

mlflow.set_experiment("/search-team/query-ranking/bert-finetune")

mlflow.set_experiment("/fraud-team/transaction-classifier/xgboost-baseline")

mlflow.set_experiment("/recommendation/item2vec/hyperopt-sweep")

悪い例：フラットで曖昧な命名

mlflow.set_experiment("experiment_1")

mlflow.set_experiment("test_model")

mlflow.set_experiment("johns_experiment")

タグ体系の設計

タグは実験検索とガバナンスの核心だ。最低限以下のタグは必ず記録する。

from datetime import datetime

with mlflow.start_run(run_name="bert-ranking-v3.2.1") as run:

必須タグ

mlflow.set_tag("team", "search")

mlflow.set_tag("owner", "jane.doe@company.com")

mlflow.set_tag("git.commit", "a1b2c3d4")

mlflow.set_tag("data.version", "v2026.03.05")

mlflow.set_tag("environment", "gpu-cluster-a100")

mlflow.set_tag("purpose", "hyperparameter-sweep")

パラメータの記録

mlflow.log_params({

"learning_rate": 2e-5,

"batch_size": 32,

"max_epochs": 10,

"model_architecture": "bert-base-uncased",

"optimizer": "AdamW",

"warmup_steps": 500,

})

メトリクスはステップ単位で記録（エポックまたはグローバルステップ）

for epoch in range(10):

train_loss = train_one_epoch(model, train_loader)

val_ndcg = evaluate(model, val_loader)

mlflow.log_metrics({

"train_loss": train_loss,

"val_ndcg@10": val_ndcg,

}, step=epoch)

最終モデルのロギング

mlflow.pytorch.log_model(

model,

artifact_path="model",

registered_model_name="search-ranking-bert",

)

autologの落とし穴

`mlflow.autolog()`はクイックプロトタイピングには便利だが、プロダクション実験では以下の問題が発生する。

- **不要なアーティファクトの過剰記録**：sklearnの場合、feature importance plot、confusion matrixなどがrun毎に保存される。ハイパーパラメータサーチを数千回実行するとアーティファクトストレージ容量が急激に増加する。

- **カスタムメトリクスの欠落**：ドメイン特化メトリクス（NDCG、MRR、ビジネスKPI）はautologが記録しない。

- **フレームワーク間の一貫性欠如**：PyTorch、TensorFlow、XGBoostがそれぞれ異なるメトリクス名と構造で記録する。

プロダクションでは`mlflow.autolog(log_models=False, log_datasets=False)`で最小記録のみ有効化し、主要メトリクスとモデルは明示的に記録することを推奨する。

モデルレジストリ運用戦略

モデル命名規則

モデル名は**プロダクト中心**で付ける。バージョン番号やアルゴリズム名はモデル名に含めない。

良い例（プロダクト/機能中心）

fraud-detector

search-ranker

recommendation-item2vec

churn-predictor

悪い例（アルゴリズム/バージョン中心）

xgboost-fraud-v3

bert-search-ranking-2026

lgbm_model_final_final

バージョン番号はレジストリが自動管理する。アルゴリズム変更はタグや説明（description）で追跡する。

エイリアスベースのデプロイワークフロー

MLflow 2.xでは、従来のStage（Staging/Production）の代わりに**エイリアス**システムの使用が推奨される。エイリアスはより柔軟で、複数のプロダクション環境を管理できる。

from mlflow import MlflowClient

client = MlflowClient()

新しいモデルバージョン登録後にエイリアス設定

model_name = "search-ranker"

version = client.create_model_version(

name=model_name,

source="runs:/abc123/model",

run_id="abc123",

description="BERT-base finetuned on 2026 Q1 query logs"

)

現在のchampionを確認

try:

current_champion = client.get_model_version_by_alias(model_name, "champion")

print(f"Current champion: v{current_champion.version}")

except mlflow.exceptions.MlflowException:

print("No champion alias set yet")

カナリアデプロイ：新バージョンにchallengerエイリアスを付与

client.set_registered_model_alias(model_name, "challenger", version.version)

カナリア検証通過後にchampionに昇格

client.set_registered_model_alias(model_name, "champion", version.version)

以前のchampionをarchivedに移動

client.set_registered_model_alias(model_name, "previous-champion", current_champion.version)

サービングコードでエイリアスでモデルをロードすれば、レジストリのエイリアスを変更するだけで無停止モデル切り替えが可能だ。

サービングコード：エイリアスベースのモデルロード

model = mlflow.pyfunc.load_model("models:/search-ranker@champion")

predictions = model.predict(input_data)

モデルバージョンメタデータ管理

モデルバージョン毎に以下の情報をタグで残す必要がある。この情報がなければ、6ヶ月後に「このモデルはどのデータで訓練されたのか」誰もわからなくなる。

client.set_model_version_tag(model_name, version.version, "training_data", "s3://data/query-logs/2026-q1/")

client.set_model_version_tag(model_name, version.version, "training_commit", "a1b2c3d4e5f6")

client.set_model_version_tag(model_name, version.version, "validation_ndcg", "0.847")

client.set_model_version_tag(model_name, version.version, "approved_by", "jane.doe")

client.set_model_version_tag(model_name, version.version, "approval_date", "2026-03-05")

実験トラッキングツール比較

MLflow選択前に、チームの要件に合うツールを評価すべきだ。

| ------------------------ | ---------------------------- | ------------------ | ---------------------------- | -------------------------- |

| **モデルレジストリ** | 内蔵 | 内蔵 | 外部連携 | 内蔵 |

| **UI/UX** | 機能的 | 直感的、最優秀 | 機能的 | 優秀 |

| **コミュニティ** | 20K+ GitHub Stars | 活発 | 活発 | 活発 |

**選択基準の要約**：

- **コスト重視 + セルフホスティング必須**：MLflowまたはClearML

- **最高レベルの可視化 + チームコラボレーション**：Weights & Biases

- **大規模エンタープライズ + ガバナンス**：Neptune.ai

- **Databricksエコシステム使用中**：MLflow（ネイティブ統合）

CI/CDパイプライン統合

GitHub ActionsとMLflow連携

モデル学習と登録を自動化すれば、再現性が保証されヒューマンエラーが削減される。

.github/workflows/train-and-register.yml

name: Train and Register Model

on:

push:

paths:

- 'models/search-ranker/**'

branches: [main]

workflow_dispatch:

inputs:

experiment_name:

description: 'MLflow experiment name'

required: true

default: '/search-team/query-ranking/scheduled-retrain'

env:

MLFLOW_TRACKING_URI: ${{ secrets.MLFLOW_TRACKING_URI }}

AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:

train:

runs-on: [self-hosted, gpu]

steps:

- uses: actions/checkout@v4

- name: Setup Python

uses: actions/setup-python@v5

with:

python-version: '3.11'

- name: Install dependencies

run: |

pip install -r requirements.txt

pip install mlflow[extras]

- name: Train model

run: |

python models/search-ranker/train.py \

--experiment-name "${{ github.event.inputs.experiment_name || '/search-team/query-ranking/ci-train' }}" \

--run-name "ci-${{ github.sha }}" \

--register-model search-ranker

- name: Validate model

run: |

python models/search-ranker/validate.py \

--model-uri "models:/search-ranker@challenger" \

--threshold-ndcg 0.82

- name: Promote to champion

if: success()

run: |

python scripts/promote_model.py \

--model-name search-ranker \

--from-alias challenger \

--to-alias champion

モデル検証スクリプト例

CIパイプラインでモデル昇格前に必ずパフォーマンス検証を実施すべきだ。

scripts/validate_model.py

from mlflow import MlflowClient

def validate_model(model_name: str, alias: str, threshold: float) -> bool:

"""モデルのパフォーマンスが閾値を満たしているか検証する。"""

client = MlflowClient()

エイリアスでモデルバージョンを照会

model_version = client.get_model_version_by_alias(model_name, alias)

run = client.get_run(model_version.run_id)

検証メトリクスの確認

val_ndcg = run.data.metrics.get("val_ndcg@10")

if val_ndcg is None:

print(f"ERROR: val_ndcg@10 metric not found in run {model_version.run_id}")

return False

現在のchampionと比較

try:

champion = client.get_model_version_by_alias(model_name, "champion")

champion_run = client.get_run(champion.run_id)

champion_ndcg = champion_run.data.metrics.get("val_ndcg@10", 0)

print(f"Champion v{champion.version} NDCG: {champion_ndcg:.4f}")

print(f"Challenger v{model_version.version} NDCG: {val_ndcg:.4f}")

champion比でのパフォーマンス低下チェック

if val_ndcg < champion_ndcg * 0.98: # 2%以上低下時は失敗

print("FAIL: Challenger performs worse than champion by more than 2%")

return False

except Exception:

print("No existing champion found. Proceeding with threshold check only.")

絶対閾値チェック

if val_ndcg < threshold:

print(f"FAIL: NDCG {val_ndcg:.4f} below threshold {threshold:.4f}")

return False

print(f"PASS: NDCG {val_ndcg:.4f} meets threshold {threshold:.4f}")

return True

if __name__ == "__main__":

parser = argparse.ArgumentParser()

parser.add_argument("--model-name", required=True)

parser.add_argument("--alias", default="challenger")

parser.add_argument("--threshold", type=float, default=0.80)

args = parser.parse_args()

if not validate_model(args.model_name, args.alias, args.threshold):

sys.exit(1)

マルチテナンシー構成

チームが複数あり実験データを分離する必要がある場合の、MLflowマルチテナンシー構成方法だ。

認証の有効化

MLflow 2.xから基本認証機能が内蔵された。

認証有効化されたサーバー起動

mlflow server \

--backend-store-uri postgresql://mlflow:${DB_PASSWORD}@db:5432/mlflow \

--default-artifact-root s3://mlflow-artifacts/ \

--app-name basic-auth \

--host 0.0.0.0 \

--port 5000

チーム別分離戦略

完全なデータ分離が必要な場合、チーム別に別々のMLflowインスタンスを運用するより、実験命名と権限による論理的分離を実装する方が運用コスト面で有利だ。

チーム別実験プレフィックスによる論理的分離

TEAM_PREFIX = {

"search": "/search-team",

"fraud": "/fraud-team",

"recommendation": "/rec-team",

}

def get_experiment_name(team: str, project: str, experiment: str) -> str:

"""チームプレフィックスを含む実験名を生成する。"""

prefix = TEAM_PREFIX.get(team)

if prefix is None:

raise ValueError(f"Unknown team: {team}. Allowed: {list(TEAM_PREFIX.keys())}")

return f"{prefix}/{project}/{experiment}"

使用例

experiment = get_experiment_name("search", "query-ranking", "bert-v4-sweep")

mlflow.set_experiment(experiment) # "/search-team/query-ranking/bert-v4-sweep"

大規模な組織では、MLflow 3.xのMulti-Workspace機能を活用すれば、単一トラッキングサーバーでワークスペース単位の実験/モデル/プロンプト分離が可能だ。

アーティファクト管理とコスト最適化

アーティファクトクリーンアップの自動化

実験が蓄積するとアーティファクトストレージコストが急速に増加する。特にハイパーパラメータサーチで数百〜数千のモデルチェックポイントが生成される場合が問題だ。

from mlflow import MlflowClient

from datetime import datetime, timedelta

def cleanup_old_runs(experiment_name: str, days_old: int = 90, dry_run: bool = True):

"""指定期間を過ぎた失敗/キャンセルされたrunのアーティファクトを整理する。"""

client = MlflowClient()

experiment = client.get_experiment_by_name(experiment_name)

if experiment is None:

print(f"Experiment '{experiment_name}' not found")

return

cutoff_ts = int((datetime.now() - timedelta(days=days_old)).timestamp() * 1000)

runs = client.search_runs(

experiment_ids=[experiment.experiment_id],

filter_string=f"attributes.end_time < {cutoff_ts} AND attributes.status != 'RUNNING'",

order_by=["attributes.end_time ASC"],

max_results=500,

)

deleted_count = 0

for run in runs:

タグで保存要否を確認

if run.data.tags.get("keep", "false").lower() == "true":

continue

レジストリに登録されたモデルがあるrunはスキップ

if run.data.tags.get("mlflow.registeredModelName"):

continue

if dry_run:

print(f"[DRY RUN] Would delete run {run.info.run_id} "

f"(ended: {datetime.fromtimestamp(run.info.end_time / 1000)})")

else:

client.delete_run(run.info.run_id)

deleted_count += 1

print(f"{'Would delete' if dry_run else 'Deleted'} {deleted_count} runs "

f"out of {len(runs)} found")

使用：まずdry_runで確認後、実際に削除

cleanup_old_runs("/search-team/query-ranking/bert-finetune", days_old=60, dry_run=True)

S3ライフサイクルポリシー

MLflowアーティファクト整理とは別に、S3バケットレベルでライフサイクルポリシーを設定してコストをさらに削減できる。

{

"Rules": [

{

"ID": "MoveOldArtifactsToIA",

"Status": "Enabled",

"Filter": {

"Prefix": "prod/"

"Transitions": [

{

"Days": 90,

"StorageClass": "STANDARD_IA"

{

"Days": 365,

"StorageClass": "GLACIER"

}

]

{

"ID": "DeleteTempArtifacts",

"Status": "Enabled",

"Filter": {

"Prefix": "tmp/"

"Expiration": {

"Days": 7

}

]

}

トラブルシューティング：よくある運用障害

1. DBコネクションプール枯渇

**症状**：同時に多くの実験が動作する際に`OperationalError: too many connections`が発生。

**原因**：MLflowサーバーのデフォルトSQLAlchemyコネクションプールサイズ（5）が不足。

**解決策**：

サーバー起動時にコネクションプールパラメータを調整

mlflow server \

--backend-store-uri "postgresql://mlflow:pass@db:5432/mlflow?pool_size=20&max_overflow=40" \

--default-artifact-root s3://artifacts/ \

--workers 8

2. アーティファクトアップロードタイムアウト

**症状**：大容量モデル（数GB）のロギング時に`ConnectionError`またはタイムアウト。

**解決策**：

アップロードタイムアウトの延長

export MLFLOW_ARTIFACT_UPLOAD_DOWNLOAD_TIMEOUT=600

マルチパートアップロードチャンクサイズの調整（S3）

export MLFLOW_S3_UPLOAD_EXTRA_ARGS='{"ServerSideEncryption": "aws:kms"}'

3. runステータスがRUNNINGのまま永久に固着

**症状**：学習プロセスが停止したがMLflow UIで該当runが「Running」状態のまま。

**解決策**：

from mlflow import MlflowClient

client = MlflowClient()

固着したrunを強制終了

stuck_runs = client.search_runs(

experiment_ids=["1"],

filter_string="attributes.status = 'RUNNING'",

)

for run in stuck_runs:

end_time = run.info.end_time

end_timeがなく開始時間が24時間以上前の場合

if end_time is None or end_time == 0:

start_time = run.info.start_time

if (datetime.now().timestamp() * 1000 - start_time) > 86400000: # 24h

client.set_terminated(run.info.run_id, status="FAILED")

print(f"Force-terminated stuck run: {run.info.run_id}")

4. モデルレジストリのエイリアス衝突

**症状**：2つのCIパイプラインが同時に同じエイリアスを設定しようとする。

**解決策**：エイリアス設定前に現在のエイリアス状態を確認し、分散ロック（distributed lock）を使用する。Redisベースのロックが最もシンプルだ。

def safe_promote_model(model_name: str, version: str, alias: str, redis_url: str):

"""分散ロックを使用した安全なモデル昇格。"""

r = redis.from_url(redis_url)

lock_key = f"mlflow:promote:{model_name}:{alias}"

30秒TTLの分散ロック取得

lock = r.lock(lock_key, timeout=30)

if lock.acquire(blocking=True, blocking_timeout=10):

try:

client = MlflowClient()

client.set_registered_model_alias(model_name, alias, version)

print(f"Successfully promoted {model_name} v{version} to @{alias}")

finally:

lock.release()

else:

raise RuntimeError(f"Failed to acquire lock for {model_name}@{alias}")

5. PostgreSQLディスクフル

**症状**：`DiskFull`エラーとともにメトリクス記録が失敗。

**解決策**：MLflowはメトリクスを個別行として保存するため、ステップ単位のロギングが多いとDBが急速に膨張する。定期的に古いrunを削除し、`VACUUM FULL`を実行する。また、メトリクスロギング頻度を適切に調整する（毎ステップではなく100ステップ単位で記録）。

運用チェックリスト

プロダクションMLflowを運用する際、以下の項目を定期的に点検すべきだ。

初期設定チェックリスト

- [ ] PostgreSQL/MySQLバックエンドストア構成完了

- [ ] S3/GCSアーティファクトストア構成およびIAM権限設定

- [ ] トラッキングサーバー高可用性（HA）構成（ロードバランサー + 複数ワーカー）

- [ ] 認証有効化（`--app-name basic-auth`）

- [ ] TLSターミネーション設定（Nginx/ALBフロントエンド）

- [ ] 実験命名規則の文書化およびチーム共有

- [ ] モデルレジストリ命名規則の合意

週次運用チェックリスト

- [ ] アーティファクトストア容量モニタリング（閾値アラート設定）

- [ ] DBディスク使用量確認

- [ ] 固着した（RUNNINGステータス）runの整理

- [ ] 失敗したrunのアーティファクト整理スクリプト実行

- [ ] トラッキングサーバー応答時間確認（P95基準500ms以下を維持）

月次運用チェックリスト

- [ ] S3/GCSコスト分析およびライフサイクルポリシー検討

- [ ] DBパフォーマンス分析（スロークエリ確認、インデックス最適化）

- [ ] モデルレジストリの未使用モデル整理

- [ ] MLflowバージョンアップグレード検討

- [ ] バックアップ/リカバリ手順のテスト

ロールバックおよび障害復旧手順

モデルロールバック

プロダクションモデルに問題が発生した際に、即座に前バージョンにロールバックする手順だ。

from mlflow import MlflowClient

def rollback_model(model_name: str):

"""championモデルをprevious-championにロールバックする。"""

client = MlflowClient()

try:

previous = client.get_model_version_by_alias(model_name, "previous-champion")

except Exception:

print("ERROR: No previous-champion alias found. Manual intervention required.")

return False

current = client.get_model_version_by_alias(model_name, "champion")

ロールバック実行

client.set_registered_model_alias(model_name, "champion", previous.version)

client.set_registered_model_alias(model_name, "rolled-back", current.version)

ロールバック理由のタグ付け

client.set_model_version_tag(

model_name, current.version, "rollback_reason", "performance_degradation"

)

client.set_model_version_tag(

model_name, current.version, "rolled_back_at", datetime.now().isoformat()

)

print(f"Rolled back {model_name}: v{current.version} -> v{previous.version}")

return True

DB復旧

PostgreSQLバックエンドで障害発生時、以下の順序で復旧する。

1. 最新DBスナップショットから復元

2. MLflowサーバー再起動後、アーティファクトストアの整合性確認

3. `mlflow gc`コマンドで孤立（orphan）アーティファクト参照を整理

4. レジストリのchampionエイリアスが正しいモデルバージョンを指しているか確認

アーティファクトガベージコレクション

mlflow gc \

--backend-store-uri postgresql://mlflow:pass@db:5432/mlflow \

--older-than 30d

MLflow 2.xから3.xへのマイグレーションポイント

MLflow 3.0（2025年中盤リリース）はGenAIとAIエージェントサポートに焦点を当てた。既存2.xユーザーが注意すべき点は以下のとおりだ。

- **Model Registry拡張**：3.xではコードバージョン、プロンプト構成、評価run、デプロイメタデータまでモデルに紐付けられる。既存2.xレジストリと下位互換。

- **Tracing機能追加**：`mlflow-tracing` SDKでプロダクション環境で最小依存性でコード/モデル/エージェントに計装（instrumentation）を追加できる。

- **search_logged_models() API**：SQL類似構文で実験全体からパフォーマンスメトリクス、パラメータ、モデル属性ベースの検索が可能に。

- **LLMコスト追跡**：LLMスパンからモデル情報を自動抽出しコストを計算する機能が追加された。

- **UI改善**：GenAIアプリとエージェント開発者向けのサイドバーが追加され、既存のモデル学習ワークフローも引き続きサポート。

2.xから3.xへのアップグレード時、DBマイグレーションスクリプト（`mlflow db upgrade`）を必ず実行し、アップグレード前にDBバックアップを確保すべきだ。

まとめ

MLflow 2.xの実験トラッキングとモデルレジストリは、インストール自体は簡単だが、プロダクションレベルで運用するにはアーキテクチャ設計、命名規則、アーティファクト管理、CI/CD統合、マルチテナンシー、モニタリング、ロールバック手順まで体系的に整える必要がある。特にアーティファクトストレージのコスト管理とDBパフォーマンス最適化は、運用初期から設計に反映しなければ後に大きな技術的負債となる。

核心原則を要約すると以下のとおりだ。

1. **実験名は階層的に**付け、タグでメタデータを豊富に残す。

2. **モデル名はプロダクト中心**で、バージョンとアルゴリズムはレジストリとタグに任せる。

3. **エイリアスベースのデプロイ**で無停止モデル切り替えを実現する。

4. **CI/CDパイプライン**に学習-検証-昇格を自動化する。

5. **アーティファクト整理**を自動化しなければ、S3のコスト請求書が毎月恐ろしくなる。

References

- [MLflow Tracking公式ドキュメント](https://mlflow.org/docs/latest/ml/tracking/)

- [MLflow Model Registry公式ドキュメント](https://mlflow.org/docs/latest/ml/model-registry/)

- [MLflow Artifact Stores構成ガイド](https://mlflow.org/docs/latest/self-hosting/architecture/artifact-store/)

- [MLflow Model Registry Workflows](https://mlflow.org/docs/latest/ml/model-registry/workflow/)

- [MLflow Self-Hosting Troubleshooting](https://mlflow.org/docs/latest/self-hosting/troubleshooting/)

- [MLflow Releases](https://mlflow.org/releases)

- [MLflow GitHub Repository](https://github.com/mlflow/mlflow)

- [MLflow Model Serving公式ドキュメント](https://mlflow.org/docs/latest/ml/deployment/)

クイズ

Q1: 「MLflow 2.x 実験トラッキングとモデルレジストリ運用ガイド」の主なトピックは何ですか？

MLflow

2.xの実験トラッキング設計からモデルレジストリ運用、アーティファクト管理、CI/CD統合、マルチテナンシー、プロダクション配布まで実践ガイド。

MLflowは月間1,400万回以上ダウンロードされ、オープンソースの実験トラッキングツールの事実上の標準となった。インストールしてmlflow.autolog()を呼び出すまでは簡単だ。問題はその先だ。チームが大きくなり実験が数千個を超えると、実験命名規則の不在、アーティファクトストレージ容量の爆発的増加、モデル昇格プロセスの混乱といった運用課題が発生する。

本記事では、MLflow

2.x（2.9〜2.18）および3.x初期バージョンまでを含め、プロダクションレベルで実験トラッキングとモデルレジストリを設計・運用する実践パターンを扱う。

Q3:

アーキテクチャ設計：トラッキングサーバーとアーティファクトストアの分離について説明してください。

コアコンポーネント MLflowのプロダクションアーキテクチャは3つのレイヤーに分離すべきだ。 Tracking

Server：実験メタデータ（パラメータ、メトリクス、タグ）を保存。PostgreSQLまたはMySQLバックエンドを使用。

Artifact Store：モデルバイナリ、データセット、可視化ファイルを保存。S3/GCS/Azure Blobを使用。

Model Registry：モデルバージョン管理、エイリアス、ステージ遷移。Tracking Serverと同一DBを使用。

実験命名戦略実験名は/team/project/experiment-type

パターンを使用する。フラットな命名は実験が100個を超えると管理不能になる。タグ体系の設計

タグは実験検索とガバナンスの核心だ。最低限以下のタグは必ず記録する。 autologの落とし穴

mlflow.autolog()はクイックプロトタイピングには便利だが、プロダクション実験では以下の問題が発生する。

モデル命名規則

モデル名はプロダクト中心で付ける。バージョン番号やアルゴリズム名はモデル名に含めない。

バージョン番号はレジストリが自動管理する。アルゴリズム変更はタグや説明（description）で追跡する。

エイリアスベースのデプロイワークフロー MLflow

2.xでは、従来のStage（Staging/Production）の代わりにエイリアスシステムの使用が推奨される。エイリアスはより柔軟で、複数のプロダクション環境を管理できる。