モデルレジストリとは、MLモデルのバージョン・メタデータ・ステージを一元管理するための基盤だ。「本番で動いているモデルはどのバージョンか」「過去の実験で最高精度だったモデルはどれか」を答えられない組織は、MLOpsの出発点としてまずモデルレジストリの整備から始めるべきだ。
モデルレジストリとは
ML開発では実験を繰り返すうちに数十〜数百のモデルバージョンが生まれる。「どれが本番で使われているのか」「先月のモデルと今月のモデルはどう違うのか」「ロールバックしたい場合に前バージョンはどこにあるのか」――これらに答えられなくなったとき、モデルレジストリの必要性が痛感される。
【モデルレジストリのMLパイプラインにおける位置づけ】
データ収集 → 特徴量エンジニアリング → モデル学習 → 評価
|
[実験トラッキング]
メトリクス・パラメータ記録
|
[モデルレジストリ] ← ここが今回のテーマ
バージョン管理
ステージ管理 (Staging/Production/Archived)
メタデータ・アーティファクト管理
|
+------------------+------------------+
| |
[ステージング環境] [本番環境]
A/Bテスト・検証 推論サービングモデルレジストリの主な機能は4つだ。①バージョン管理 (モデルアーティファクトとメタデータを版管理)、②ステージ管理 (Staging→Production→Archivedの状態遷移)、③系譜追跡 (どのデータ・コード・実験から生まれたかを記録)、④デプロイ連携 (登録モデルをサービング環境に自動デプロイ)。
主要ツールの比較
モデルレジストリとして広く利用されているツールを比較する。
| ツール | OSS/商用 | バージョン管理 | ステージ管理 | 実験追跡 | デプロイ連携 | 料金 |
|---|---|---|---|---|---|---|
| MLflow Model Registry | OSS | ◎ | ◎ | ◎ | ○ (カスタム要) | 無料 (自己ホスト) |
| Weights & Biases (W&B) | 商用 (一部OSS) | ◎ | ◎ | ◎ | ◎ | 無料〜月額$50+ |
| Neptune.ai | 商用 | ○ | ○ | ◎ | △ | 月額$49+ |
| AWS SageMaker Model Registry | 商用 | ◎ | ◎ | △ | ◎ (AWS統合) | 利用量課金 |
| Google Vertex AI | 商用 | ◎ | ◎ | ○ | ◎ (GCP統合) | 利用量課金 |
import mlflow
from mlflow.tracking import MlflowClient
# MLflowでのモデル登録・バージョン管理
mlflow.set_tracking_uri("http://localhost:5000")
# 実験の実行とモデルの記録
with mlflow.start_run(run_name="xgboost_v2_training") as run:
# モデルの学習 (省略)
accuracy = 0.923
mlflow.log_param("n_estimators", 200)
mlflow.log_param("max_depth", 6)
mlflow.log_metric("accuracy", accuracy)
mlflow.log_metric("f1_score", 0.918)
# モデルをレジストリに登録
model_uri = f"runs:/{run.info.run_id}/model"
mlflow.register_model(model_uri, "customer_churn_predictor")
# クライアントでバージョン管理
client = MlflowClient()
# 最新バージョンをStagingに昇格
client.transition_model_version_stage(
name="customer_churn_predictor",
version=3,
stage="Staging",
archive_existing_versions=False
)
# バージョン情報の確認
versions = client.get_latest_versions("customer_churn_predictor")
for v in versions:
print(f"Version: {v.version}, Stage: {v.current_stage}, Run: {v.run_id}")モデルライフサイクル管理
モデルレジストリの中核機能がステージ管理だ。モデルは「登録 → Staging → Production → Archived」というライフサイクルを経る。各ステージへの昇格には承認ルールを設定することで、品質管理のゲートを設けることができる。
| ステージ | 意味 | 昇格条件 | 承認者 | ロールバック |
|---|---|---|---|---|
| None (登録直後) | 実験で生成されたモデル | 学習完了・メトリクス記録済み | 自動 | 不要 |
| Staging | 検証・テスト中のモデル | 精度が閾値以上・テスト通過 | MLエンジニア | Noneへ戻す |
| Production | 本番稼働中のモデル | Staging検証OK・ビジネス承認 | プロダクトオーナー | 前バージョンに戻す |
| Archived | 廃止されたモデル | Productionから置き換えられた時 | 自動 (Prod昇格時) | 再度Productionに昇格可 |
実装ベストプラクティス
モデルレジストリを最大限に活用するためのベストプラクティスをまとめる。
- メタデータを充実させる: モデルの説明、学習データのバージョン、特徴量リスト、評価指標を必ず記録する。3ヶ月後に「このモデルをなぜ採用したのか」を誰でも理解できる状態にする
- タグを活用する: ユースケース・チーム・アルゴリズムタイプをタグで整理することで、大量のモデルでも検索が容易になる
- CI/CDと統合する: 学習パイプラインのCI完了時に自動的にモデルを登録・Stagingに昇格させる
# モデル昇格の自動化スクリプト
from mlflow.tracking import MlflowClient
def auto_promote_to_staging(model_name: str, min_accuracy: float = 0.90):
client = MlflowClient()
# 最新の「None」ステージのバージョンを取得
none_versions = client.get_latest_versions(model_name, stages=["None"])
for version in none_versions:
run = client.get_run(version.run_id)
accuracy = float(run.data.metrics.get("accuracy", 0))
if accuracy >= min_accuracy:
client.transition_model_version_stage(
name=model_name, version=version.version, stage="Staging"
)
print(f"v{version.version} をStagingに昇格 (accuracy={accuracy:.3f})")
else:
print(f"v{version.version} は精度不足でスキップ (accuracy={accuracy:.3f})")
auto_promote_to_staging("customer_churn_predictor", min_accuracy=0.90)LLM時代のモデルレジストリ
従来のMLモデル管理とLLM時代のモデル管理は異なる課題を持つ。LLMでは「モデルそのもの (数十〜数百GB)」の管理よりも「どのベースモデルを使い、どのプロンプトとファインチューニングが適用されたか」のバージョン管理が重要になる。
LLMOpsにおけるモデルレジストリの進化形として、「プロンプトレジストリ」との統合が注目されている。どのプロンプトバージョンとどのモデルの組み合わせが最高精度を出したかを追跡できる仕組みが、LLMを本番運用する企業には必要となっている。W&BやLangSmithなどのツールがこの領域に対応を進めている。
まとめ
- モデルレジストリはMLモデルのバージョン・ステージ・メタデータを一元管理する基盤
- OSSで自社管理ならMLflow、SaaSで手軽に始めるならW&Bが定番の選択
- Staging→Production→Archivedのステージ管理で品質ゲートを設ける
- LLM時代はプロンプトバージョン管理との統合が新たな課題
よくある質問
Q. モデルレジストリとは何ですか?
MLモデルのバージョン、メタデータ、ステータスを一元管理するための基盤です。どのモデルが本番で稼働しているか、過去のどのバージョンが最も精度が高かったかを追跡できます。
Q. MLflowとWeights & Biasesのどちらを選ぶべきですか?
OSSで自社管理したいならMLflow、SaaSで手軽に始めたいならW&Bが適しています。チーム規模やインフラ運用のリソースで判断してください。
Q. モデルレジストリはいつ導入すべきですか?
本番環境にモデルをデプロイする段階で導入すべきです。最低限、モデルのバージョン管理と本番/ステージングの区別ができる仕組みが必要です。