モデルバージョニング基盤：大規模ML成果物の管理

2025年12月11日更新

2025年12月アップデート： MLflow 3.0が生成AIアプリケーションとAIエージェント向けにレジストリを拡張—モデルを正確なコードバージョン、プロンプト設定、評価実行、デプロイメントメタデータと連携させる。モデルバージョニングは今や単なる重みだけでなく、ファインチューニングされたアダプター、プロンプトテンプレート、検索設定も追跡する。数百GBの重みを持つLLMにはGitを超えた専門的な基盤が必要となる。

MLflow 3.0は生成AIアプリケーションとAIエージェントを扱うためにモデルレジストリを拡張し、モデルを正確なコードバージョン、プロンプト設定、評価実行、デプロイメントメタデータと連携させた。¹ この進化は「モデルバージョニング」の意味の根本的な変化を反映している—単純なpickleファイルの追跡から、複数のファインチューニングアダプター、プロンプトテンプレート、検索設定を持つ複雑なシステムの管理へ。本番AIを運用する組織には、重みだけでなく、モデルを確実に再現しデプロイするために必要な全体のコンテキストをバージョン管理する基盤が必要である。

従来のソフトウェアバージョニングとは異なり、MLモデルのバージョニングでは、大規模なバイナリファイル、複雑なトレーニング設定、データセットバージョン、評価メトリクスを追跡しながら、再現性とコンプライアンス要件を維持する必要がある。² ファインチューニングモデルが急速に増殖し、プロンプトエンジニアリングがバージョン管理を必要とする成果物の別のレイヤーを追加するLLMでは、この課題は複合的になる。

モデルバージョニングが重要な理由

本番MLシステムは静かに失敗する。モデルは時間とともに劣化し、ファインチューニングバージョンは予期せずパフォーマンスが低下し、適切なバージョニングがなければ、何が変わったのか特定することも、既知の正常な状態にロールバックすることもできない。

バージョニングの課題

バイナリ成果物： モデルの重みは、古典的なMLではメガバイトから、大規模言語モデルでは数百ギガバイトに及ぶ。Gitはこれらのファイルを効率的に処理できず、専門的な基盤が不可欠となる。

設定の爆発的増加： 単一のモデルには、トレーニングコード、ハイパーパラメータ、データ前処理、特徴量エンジニアリング、デプロイメント設定が関わる。あらゆる変更がモデルの動作に影響を与える可能性がある。

データセットへの依存： モデルの品質はトレーニングデータに依存する。データセットのバージョニングがなければ、同一のコードであってもモデルの再現は不可能となる。

評価との結合： 特定のテストセットでのパフォーマンスメトリクスがデプロイメントの決定を左右する。それらのメトリクスはモデルバージョンと永続的にリンクする必要がある。

ビジネス要件

再現性： 金融やヘルスケアにおける規制要件では、任意の時点でデプロイされた正確なモデルバージョンを再作成する能力が求められる。³

監査可能性： コンプライアンスでは、デプロイされたモデルをトレーニングデータ、コード、デプロイメントを承認した意思決定者まで遡ることが求められる。

ロールバック機能： 本番インシデントでは、数時間ではなく数分以内に以前のモデルバージョンに戻す必要がある。

コラボレーション： 同じモデルで作業する複数のデータサイエンティストには、モデル成果物の明確な所有権と競合解決が必要である。

モデルレジストリアーキテクチャ

モデルレジストリは、開発から本番までのMLモデルのライフサイクルを管理する中央リポジトリとして機能する：⁴

コアコンポーネント

バージョン管理： 各モデルバージョンには一意の識別子が付与され、通常はモデル名とセマンティックバージョン（v1.2.3）またはハッシュベースの識別子を組み合わせる。

メタデータストレージ： トレーニングパラメータ、評価メトリクス、データ系統、デプロイメント履歴がモデル成果物と共に永続化される。

成果物ストレージ： モデルの重み、設定ファイル、関連アセットはスケーラブルなオブジェクトストレージ（S3、GCS、Azure Blob）に保存される。

ライフサイクル管理： モデルはステージ（開発、ステージング、本番、アーカイブ）を経て移行し、各移行時にガバナンス制御が行われる。

レジストリワークフロー

トレーニングジョブ → モデル登録 → ステージングレビュー → 本番デプロイメント
     ↓              ↓               ↓                    ↓
  メトリクス      バージョンID      承認            トラフィックルーティング
  ログ記録       生成           記録            監視

登録： トレーニングパイプラインは、関連するメタデータと共に成功したモデルを自動的に登録する： - トレーニング実行IDと実験コンテキスト - ハイパーパラメータと設定 - ホールドアウトデータでの評価メトリクス - データバージョン参照 - コードコミットハッシュ

ステージング： 候補モデルは本番前に検証を受ける： - ベンチマークに対する自動テスト - 機密性の高いアプリケーションでの人間によるレビュー - 現在の本番モデルとのA/Bテスト - 推論レイテンシのパフォーマンスプロファイリング

昇格： 承認されたモデルは本番にデプロイされる： - トラフィックは徐々に新しいバージョンにシフト - 監視が劣化を検知 - メトリクスが低下した場合はロールバックをトリガー

プラットフォーム比較

MLflow

MLflowは最も包括的なオープンソースモデルレジストリを提供する：⁵

モデルレジストリ機能： - バージョニングとエイリアスを備えた集中型モデルストア - 系統追跡（実験 → 実行 → モデル） - ステージ遷移（Staging、Production、Archived） - 注釈とメタデータタグ付け - プログラムアクセス用REST API

MLflow 3.0の強化： - LoggedModelエンティティがモデルをコード、プロンプト、評価と連携 - 生成AIアプリケーション向けの強化されたトレーシング - 複雑なAIシステム向けのエージェントサポート - Databricksがマネージドエンタープライズ版を提供

ワークフロー例：

import mlflow

# トレーニング中にモデルをログ
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# モデルレジストリに登録
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# 本番に昇格
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

最適な用途： オープンソースの柔軟性を持つ包括的なMLOps機能を求める組織。

Weights & Biases

W&Bは強力な成果物バージョニングを備えた実験追跡に重点を置いている：⁶

主な機能： - 豊富な可視化を備えた実験追跡 - 系統グラフを備えた成果物バージョニング - エイリアス（@champion、@production）を備えたモデルレジストリ - チームワークフロー向けのコラボレーション機能 - 主要なMLフレームワークとの統合

成果物バージョニング：

import wandb

run = wandb.init(project="nlp-models")

# モデルを成果物としてログ
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# エイリアス付きでレジストリにリンク
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

考慮事項： クラウドファーストのアーキテクチャでは外部サーバーへのデータ送信が必要となり、厳格なデータプライバシー要件と矛盾する可能性がある。

最適な用途： 最小限のセットアップオーバーヘッドで実験追跡とコラボレーションを優先するチーム。

DVC（Data Version Control）

DVCは大容量ファイルとデータセット向けにGitを拡張する：⁷

アーキテクチャ： - Git風のコマンド（dvc add、dvc push、dvc pull） - メタデータファイルはGitで追跡、大容量ファイルはリモートストレージに保存 - 再現可能な実験のためのパイプライン定義 - 複数のストレージバックエンド（S3、GCS、Azure、SSH）

最近の動向： DVCはlakeFSファミリーに加わり、lakeFSがペタバイト規模のデータバージョニングのエンタープライズ標準として機能している。

ワークフロー例：

# 大容量モデルファイルをDVCに追加
dvc add models/bert-finetuned.pt

# メタデータをGitにコミット
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# リモートストレージにプッシュ
dvc push

# 任意のコミットから再現
git checkout v1.0
dvc checkout

最適な用途： 既存のGitワークフローを持ち、軽量なデータとモデルのバージョニングを求めるチーム。

クラウドネイティブレジストリ

Vertex AI Model Registry（Google Cloud）：⁸ - ネイティブGCP統合 - エンドポイントへの直接デプロイメント - 自動系統追跡 - Vertex AI Pipelinesとの統合

Amazon SageMaker Model Registry： - AWSエコシステム統合 - 承認ワークフロー - クロスアカウントモデル共有 - SageMaker Pipelinesとの統合

Azure ML Model Registry： - Azure統合 - MLflow互換性 - マネージドエンドポイントデプロイメント

最適な用途： 特定のクラウドプロバイダーにコミットし、ネイティブ統合を求める組織。

LLM固有の考慮事項

大規模言語モデルは、従来のMLを超える独自のバージョニング課題を提示する：⁹

バージョン管理すべきもの

ベースモデル： どの基盤モデル（Llama 3.1-8B、GPT-4、Claude）が出発点となるかを追跡する。

ファインチューニング済みの重み： フルファインチューニングは完全に新しい重みファイルを生成する。LoRAアダプターはベースモデルを参照する小さなデルタファイルを生成する。

プロンプトテンプレート： システムプロンプト、few-shot例、指示形式はモデルの動作に大きく影響する。

検索設定： RAGシステムでは、埋め込みモデル、チャンキング戦略、検索パラメータのバージョニングが必要である。

LLMのセマンティックバージョニング

変更の重要性を伝えるためにセマンティックバージョニングを採用する：¹⁰

メジャーバージョン（v2.0.0）： - 異なるベースモデル - アーキテクチャの変更 - 破壊的なAPI変更

マイナーバージョン（v1.3.0）： - 新しいデータでのファインチューニング - 大幅なパフォーマンス改善 - 新機能の追加

パッチバージョン（v1.2.1）： - バグ修正 - マイナーな最適化 - 設定の更新

アダプター管理

LoRAとQLoRAは体系的な整理を必要とするアダプターファイルを増殖させる：

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

アダプターバージョニング戦略： - アダプターはベースモデルとは独立してバージョン管理する - 互換性のあるベースモデルバージョンを文書化する - アダプターごとにトレーニングデータとハイパーパラメータを追跡する - サービング時にアダプター間の迅速な切り替えを可能にする

デプロイメント戦略

カナリアデプロイメント

フルロールアウト前に、新しいモデルバージョンに少量のトラフィックをルーティングする：¹¹

# Kubernetesカナリア設定
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

プロセス： 1. 新しいバージョンを本番と並行してデプロイ 2. トラフィックの5〜10%を新しいバージョンにルーティング 3. メトリクス（レイテンシ、エラー率、ビジネスメトリクス）を監視 4. メトリクスが維持されれば徐々にトラフィックを増加 5. 結果に基づいてロールアウトを完了またはロールバック

ツール： Istio、Argo Rollouts、Flaggerは、メトリクス劣化時の自動ロールバックを備えたプログレッシブデリバリーを自動化する。

A/Bテスト

ビジネスへの影響を測定するためにモデルバージョンを比較する：¹²

カナリアとの主な違い： - カナリアは問題を検知する（数分〜数時間） - A/Bテストは影響を測定する（数日〜数週間） - A/Bの結論には統計的有意性が必要

実装： - ユーザーIDをハッシュして一貫したルーティングを実現 - バリアントごとにコンバージョンメトリクスを追跡 - 統計的有意性が達成されるまで実行 - 将来の参照のために結果を文書化

シャドウデプロイメント

レスポンスを提供せずに本番トラフィックを新しいモデルにルーティングする：

メリット： - 実際のトラフィックパターンでテスト - ユーザーへの影響なく出力を比較 - デプロイメント前にエッジケースを特定

実装： - 本番モデルがレスポンスを提供 - シャドウモデルが同じリクエストを処理 - 出力は比較されるがユーザーには返されない - 不一致は調査をトリガー

ロールバック手順

すべてのデプロイメントにはロールバック機能が必要：

即時ロールバック：

# トラフィックルーティングのロールバック
kubectl set image deployment/model-service model=model:v1.2.0

# フィーチャーフラグのロールバック
feature_flags.disable("new_model_v2")

レジストリベースのロールバック： ```py

[翻訳のためコンテンツは省略]