MLOps

目次

概要

学習したモデルを、継続的に安全に運用する

MLOpsは、モデル学習、評価、配備、監視、再学習を継続的に回すための実務です。コードだけでなく、データ、特徴量、実験、モデル、評価結果までを追跡対象として扱います。

要点

MLOpsの中心は「モデルを本番に置くこと」ではなく、「変化するデータとモデルを追跡し続けること」です。

この章で重視すること

  • 実験管理、モデル管理、配備、監視の流れを一続きで理解する
  • ソフトウェア運用と違う難しさとしてdata driftを押さえる
  • 再現性と評価基準の管理を重視する

主な構成要素

  • experiment tracking
  • feature / dataset versioning
  • model registry
  • deployment
  • online / offline evaluation
  • drift detection
  • retraining pipeline

これらは別々の道具ではなく、モデルのライフサイクルをつなぐ部品です。実験で得たモデルが、どのデータで作られ、どの評価を通り、どの環境へ配備され、配備後にどう監視されているかを追える必要があります。

flowchart LR Data["data / features"] Train["training pipeline"] Eval["evaluation"] Registry["model registry"] Deploy["deployment"] Monitor["monitoring"] Feedback["feedback / labels"] Data --> Train --> Eval --> Registry --> Deploy --> Monitor --> Feedback --> Data

この流れのどこかが手作業で切れていると、問題発生時に原因を追いにくくなります。MLOpsの成熟度は、使っているツールの数ではなく、この追跡と再実行がどれだけ安定しているかで見ます。

実験管理

機械学習では、コードだけでなく、データ、前処理、特徴量、ハイパーパラメータ、乱数seed、評価指標が結果に影響します。実験管理では、それらを後から追えるようにします。

記録すべきものは次です。

  • dataset version
  • preprocessing code
  • feature definition
  • model architecture
  • hyperparameters
  • metrics
  • artifacts
  • 実行環境

「良い結果が出たが再現できない」は、MLOpsで最初に避けたい失敗です。

モデルレジストリ

model registryは、モデルをversionとして管理する場所です。単にファイルを置く場所ではなく、どの実験から生まれ、どの評価を通り、どの環境に配備されたかを追います。

見るべき情報は次です。

  • model version
  • lineage
  • validation status
  • owner
  • deployment target
  • rollback先

Feature Store

特徴量を複数チームや複数モデルで使う場合、定義がずれると学習と推論の結果が合わなくなります。feature storeは、特徴量の定義、生成、再利用、オンライン提供を管理する仕組みです。

重要なのは、学習時と推論時で同じ意味の特徴量を使うことです。

学習パイプライン

学習パイプラインは、データ取得、検証、前処理、学習、評価、登録までを自動化します。

flowchart LR A["data"] --> B["validation"] B --> C["feature engineering"] C --> D["training"] D --> E["evaluation"] E --> F["model registry"]

パイプライン化すると、手作業の差分が減り、再実行と監査がしやすくなります。

配備

モデル配備にはいくつかの形があります。

  • batch inference
  • online inference
  • streaming inference
  • edge inference

オンライン推論ではlatency、throughput、availabilityが重要です。batch推論ではスケジュール、再実行、失敗時の部分再処理が重要になります。

監視

モデルは配備後に劣化します。データ分布が変わったり、ユーザー行動が変わったり、上流システムの仕様が変わったりするためです。

見るべき観点は次です。

  • input drift
  • prediction drift
  • feature missing rate
  • latency
  • error rate
  • business KPI
  • labelが遅れて得られる評価指標

モデル監視では、すぐ分かる指標と、遅れて分かる指標を分けます。たとえば推薦モデルのクリック率は比較的早く見えますが、解約率やLTVへの影響は遅れて現れます。不正検知では、真のラベルが調査後にしか確定しないこともあります。

指標 早く見えるか 注意点
latency / error rate 早い モデル以前にserving基盤の問題を示すことがある
input drift 早い driftがあっても必ず悪化とは限らない
prediction drift 早い ユーザー構成や季節性でも変わる
精度指標 遅いことが多い label遅延を考える
業務KPI 遅いことが多い 施策や外部要因の影響を受ける

監視設計では、アラートにする指標と、ダッシュボードで観察する指標を分けます。すべてをアラートにすると疲弊し、重要な異常を見逃しやすくなります。

再学習

再学習は、単に定期実行すればよいわけではありません。新しいデータが十分あるか、評価が改善しているか、過去の重要ケースで悪化していないかを確認します。

本番モデルの更新には、通常のソフトウェアより慎重な比較が必要です。

再学習のトリガーには、時間ベース、データ量ベース、性能劣化ベースがあります。

トリガー 例 向いている状況
時間ベース 毎週、毎月 データ分布が安定して変化する
データ量ベース 新規labelが10万件集まった label取得に時間がかかる
劣化ベース segment別recallが閾値を下回った 監視指標が信頼できる
イベントベース 価格改定、新商品、法改正 外部変化が明確

再学習後は、全体平均だけでなく重要segmentを見ます。全体の精度が改善しても、少数だが重要なユーザー群で悪化していれば、本番化しない判断が必要です。

Governance

MLOpsでは、誰がどのデータでどのモデルを作り、どの判断で本番化したかが重要になります。説明責任が必要な領域では、モデルカード、データカード、評価レポート、承認ログを残します。

Governanceは承認を重くするためだけのものではありません。後から「なぜこのモデルがこの判断をしたのか」「どのデータを使ったのか」「どのリスクを確認したのか」を説明できる状態を作るためのものです。

最低限残したい情報:

  • 学習データの出所と期間
  • 除外したデータと理由
  • 評価データの作り方
  • 全体性能とsegment別性能
  • 既知の失敗ケース
  • 本番化の承認者と判断理由
  • rollback条件
  • 監視する指標

生成AIや外部モデルを使う場合は、モデル自体を再学習しなくても、プロンプト、検索対象データ、ツール権限、評価セット、ガードレールの変更を追跡します。

よくある失敗

  • notebookの結果だけで本番化する
  • trainingとservingの前処理が違う
  • 精度だけ見てlatencyを見ない
  • label遅延を考えずに監視する
  • rollback手順がない
  • driftを検知しても再学習判断がない

MLOps成熟度

MLOpsは、いきなり完全自動化を目指すより、どこが手作業かを明確にするところから始めます。Google CloudのMLOps資料では、手動運用、MLパイプライン自動化、CI/CDを含む自動化という段階で整理されています。

段階 状態 主なリスク
手動 notebookやscriptで学習し、手で配備する 再現できない、属人化する
パイプライン化 学習、評価、登録を自動化する pipeline自体の変更管理が弱い
CI/CD/CT コード、pipeline、model更新を継続的に管理する 評価と承認設計が複雑になる

成熟度はツールの数ではなく、変更を安全に繰り返せるかで見ます。

CI/CD/CT

通常のソフトウェアではCI/CDが中心ですが、機械学習ではCT(Continuous Training)も重要になります。

  • CI feature engineering、training code、pipeline componentをテストする
  • CD pipelineやserving環境を安全に配備する
  • CT 新しいデータや性能劣化をきっかけに再学習する

CTでは、再学習すれば必ず良くなるとは限りません。新モデルは、固定test set、最新データ、重要segment、過去の事故ケースで比較してからpromoteします。

データ検証

MLOpsで最も重要な検査の1つはデータ検証です。

  • schemaが変わっていないか
  • 欠損率が急に増えていないか
  • カテゴリ値に未知の値が増えていないか
  • 数値分布が大きく変わっていないか
  • labelの遅延や欠落がないか

モデルの異常に見えて、実は上流データの仕様変更だった、ということはよくあります。データ検証をpipelineの前半に置くと、壊れたデータで学習する事故を防げます。

ロールバックと段階配備

モデルのrollbackは、コンテナだけ戻せば終わりではありません。特徴量定義、前処理、モデルファイル、serving code、依存ライブラリが揃って戻る必要があります。

段階配備では次を使います。

  • shadow deployment
  • canary release
  • A/B test
  • champion / challenger
  • traffic splitting

本番での評価は、精度だけでなく、レイテンシ、エラー率、コスト、ビジネスKPI、安全性も含めます。

Feature Storeの注意点

Feature Storeは便利ですが、導入すれば自動でMLOpsが整うわけではありません。重要なのは特徴量の意味と鮮度です。

確認すること:

  • onlineとofflineで同じ定義か
  • point-in-timeに正しく取得できるか
  • 過去データに未来情報が混ざらないか
  • 特徴量ownerが明確か
  • 削除や非推奨の手順があるか

特徴量は再利用資産であると同時に、間違えると複数モデルを同時に壊す共有依存でもあります。

モデル監視と業務監視

モデル監視では、技術指標と業務指標を分けます。

種類 例
技術指標 latency、error rate、missing feature、drift
モデル指標 precision、recall、calibration、segment別性能
業務指標 成約率、解約率、問い合わせ数、不正検知後の損失

ラベルが遅れて届く場合、短期的にはproxy指標を見て、後から真の指標で検証します。

Training-serving skew

MLOpsで特に事故になりやすいのが、学習時と推論時で特徴量の作り方がずれることです。GoogleのRules of MLでも、訓練と提供のずれは実運用で繰り返し問題になる論点として扱われます。

代表的なずれは次の通りです。

ずれ 例 対策
時刻 学習では未来情報を使っていた point-in-time joinを使う
前処理 学習だけ欠損補完が違う 前処理を共有library化する
schema 推論時に新しいcategoryが来る unknown値の扱いを決める
feature freshness online特徴量が古い 鮮度SLOを持つ
dependency 外部APIの仕様が変わる contract testを置く

モデル精度の劣化を見つけたとき、最初にモデルを複雑にするのではなく、データの生成経路と推論時の入力を比較します。MLOpsの多くは、モデル改善よりも、同じ入力なら同じ特徴量が作られる状態を保つ作業です。

モデルデプロイメント戦略と A/B テスト

MLOpsの中心は、訓練済みモデルを本番環境に安全にデプロイすることです。

Canary デプロイと Blue-Green デプロイ

Canary: 新バージョンをトラフィックの小部分(5-10%)に流す

# トラフィック分割の例
import random

def route_request(model_version):
    r = random.random()
    if r < 0.1:
        return serve_model("v2_canary")
    else:
        return serve_model("v1_stable")

もし新バージョンのエラー率が上昇したら、自動的に v1 に戻します。

Blue-Green: 旧バージョン(Blue)と新バージョン(Green)を並行運用

Before:
  Load Balancer → Blue (v1)

Deployment:
  Load Balancer → Blue (v1) / Green (v2)

After (successful):
  Load Balancer → Green (v2)
  Blue becomes fallback

利点: 問題発生時の即座のロールバック、ゼロダウンタイム

KServe によるモデルサービング

KServeは Kubernetes 上でモデルを標準化されたインターフェースで提供します:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    sklearn:
      storageUri: gs://bucket/iris-model
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 500m
          memory: 512Mi
  explainer:
    alibi:
      storageUri: gs://bucket/alibi-explainer
  transformer:
    custom:
      image: myregistry/transformer:latest

レプリケーション、オートスケーリング、トラフィック分割が自動で管理されます。

MLflow による実験管理と検証

MLflow は実験の再現性を確保し、モデルの複数バージョンを管理します:

import mlflow
from mlflow.models import infer_signature
from sklearn.ensemble import RandomForestClassifier

mlflow.start_run()

# ハイパーパラメータ記録
params = {
    "n_estimators": 100,
    "max_depth": 10,
    "random_state": 42
}
mlflow.log_params(params)

# モデル学習
model = RandomForestClassifier(**params)
model.fit(X_train, y_train)

# メトリクス記録
accuracy = model.score(X_test, y_test)
mlflow.log_metric("accuracy", accuracy)

# モデル登録
signature = infer_signature(X_train, model.predict(X_train))
mlflow.sklearn.log_model(model, "model", signature=signature)

mlflow.end_run()

モデルのステージング → 本番への遷移を追跡できます:

  • Development
  • Staging
  • Production

ONNX による相互運用性

ONNX（Open Neural Network Exchange）は、PyTorch/TensorFlow/scikit-learnなど異なるフレームワーク間でモデルを変換・共有します:

import sklearn
import onnx
import onnxruntime as ort
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType

# scikit-learn → ONNX
model = LogisticRegression()
model.fit(X_train, y_train)

initial_type = [("float_input", FloatTensorType([None, 4]))]
onnx_model = convert_sklearn(model, initial_types=initial_type)

with open("model.onnx", "wb") as f:
    f.write(onnx_model.SerializeToString())

# 推論
sess = ort.InferenceSession("model.onnx")
pred = sess.run(None, {"float_input": X_test.astype("float32")})

ONNX モデルは C++、Java、JavaScript など様々な環境で実行できます。

機械学習パイプラインの監視

本番運用では、モデル精度だけでなくシステムメトリクスも監視します。

主要メトリクス

  1. モデルメトリクス: 精度、F1スコア、AUC
  2. データメトリクス: 入力の統計量、欠損率
  3. サービスメトリクス: レイテンシ、スループット、エラー率
  4. ビジネスメトリクス: コンバージョン率、顧客満足度

Prometheus + Grafana を使い、リアルタイムダッシュボードを構築:

from prometheus_client import Counter, Histogram
import time

# メトリクス定義
prediction_counter = Counter(
    'model_predictions_total',
    'Total predictions',
    ['model_version', 'status']
)

inference_time = Histogram(
    'model_inference_seconds',
    'Inference latency'
)

# 推論実行
@inference_time.time()
def predict(model, X):
    try:
        result = model.predict(X)
        prediction_counter.labels(
            model_version='v2',
            status='success'
        ).inc()
        return result
    except Exception as e:
        prediction_counter.labels(
            model_version='v2',
            status='error'
        ).inc()
        raise

オートML とハイパーパラメータ最適化

Google Cloud AutoML、Auto-sklearn など、自動化が進みます。しかし基本原理を理解することは重要です。

Bayesian Optimization

Bayesian Optimization は、目的関数 f(x) を少ない評価回数で最大化します。

from sklearn.gaussian_process import GaussianProcessRegressor
from scipy.optimize import minimize
import numpy as np

# 観測データから Gaussian Process をフィット
gp = GaussianProcessRegressor(kernel=RBF(length_scale=1.0))
gp.fit(X_observed, y_observed)

# 次の評価点を選択 (獲得関数)
def acquisition_function(x):
    mu, sigma = gp.predict(x.reshape(1, -1), return_std=True)
    # Expected Improvement (EI)
    Z = (mu - np.max(y_observed)) / (sigma + 1e-9)
    ei = (mu - np.max(y_observed)) * norm.cdf(Z) + sigma * norm.pdf(Z)
    return -ei

x_next = minimize(acquisition_function, x0=np.random.uniform(0, 1)).x

Random Search と比べ、Bayesian Optimization は少ない回数で高精度のハイパーパラメータを発見します。

機械学習パイプラインの実装パターン

MLOpsの成功はシステム設計にかかっています。

特徴量ストア（Feature Store）

オンライン・オフライン両環境で一貫した特徴量を供給します。Feast（オープンソース Feature Store）では、訓練用履歴特徴量と推論用オンライン特徴量を統一管理できます。

リアルタイムモデル更新では SGDClassifier の partial_fit を使い、Kafka から流れるデータで継続学習。一方、バッチ予測は BigQuery で大規模データセットに対して効率的に実行。

Kubeflow Pipeline は Kubernetes ベースの MLOps で、各ステップを Pod として実行。前処理、学習、評価、デプロイまで全段階を自動化。

本番運用の心臓は監視。Prometheus + Grafana でメトリクスを可視化。精度低下やレイテンシ増加をアラート。

検証チェックリスト

MLOps 本番化には多くの要素が必要：

  1. データパイプライン：Data versioning（DVC, MLflow）、品質チェック（Great Expectations）
  2. モデル管理：Model Registry、バージョン管理
  3. デプロイメント：CI/CD パイプライン、Canary デプロイ
  4. 監視：入力分布、精度、レイテンシ、ビジネスメトリクス
  5. ドキュメント：Model Card、Datasheet

実装例：MLflow による実験管理とモデル比較

MLflow はOpenMLのオープンソース実装で、複数のモデルを一元管理できます。

import mlflow
from mlflow.models import infer_signature
import numpy as np
from sklearn.datasets import load_iris
from sklearn.ensemble import RandomForestClassifier, GradientBoostingClassifier
from sklearn.model_selection import cross_val_score

mlflow.set_experiment("iris_classification")

X, y = load_iris(return_X_y=True)

models = [
    ("RandomForest", RandomForestClassifier(n_estimators=100, random_state=42)),
    ("GradientBoosting", GradientBoostingClassifier(random_state=42))
]

for model_name, model in models:
    with mlflow.start_run(run_name=model_name):
        # Hyperparameters
        mlflow.log_params(model.get_params())
        
        # Cross-validation
        cv_scores = cross_val_score(model, X, y, cv=5)
        mlflow.log_metric("cv_mean", cv_scores.mean())
        mlflow.log_metric("cv_std", cv_scores.std())
        
        # Train and log model
        model.fit(X, y)
        signature = infer_signature(X, model.predict(X))
        mlflow.sklearn.log_model(model, "model", signature=signature)
        
        # Log artifact
        mlflow.log_text(f"Cross-val scores: {cv_scores}", "cv_scores.txt")

MLflow UI で複数実験を可視化・比較可能。

ONNX での クロスプラットフォーム対応

ONNX（Open Neural Network Exchange）はモデル形式の標準化。scikit-learn → ONNX → Java/C++/JavaScript での実行。

import onnx
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
from sklearn.ensemble import RandomForestClassifier

# scikit-learn から ONNX へ
model = RandomForestClassifier(n_estimators=10)
model.fit(X, y)

# Conversion
initial_type = [("float_input", FloatTensorType([None, 4]))]
onnx_model = convert_sklearn(model, initial_types=initial_type)

# Save
onnx.save_model(onnx_model, "rf_model.onnx")

# Load and infer in ONNX Runtime
import onnxruntime as ort

sess = ort.InferenceSession("rf_model.onnx", providers=['CPUExecutionProvider'])
input_name = sess.get_inputs()[0].name
output_name = sess.get_outputs()[0].name

pred = sess.run([output_name], {input_name: X_test.astype('float32')})[0]

ONNX モデルは言語・プラットフォーム非依存。エッジデバイス展開も可能。

Kubeflow - ML本番化プラットフォーム

Kubeflow (kubeflow.org) は、Kubernetes上でML/AI ワークフローを管理・スケーリングするプラットフォームです。

KubeflowコンポーネントとTFJob例

Kubeflow Central Dashboard、Jupyter Notebook Server、TensorFlow Training (TFJob)をサポート。

TFJobの例:

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  name: tensorflow-training-job
spec:
  tfReplicaSpecs:
    Chief:
      replicas: 1
    Worker:
      replicas: 2
    PS:
      replicas: 1

Katib ハイパーパラメータチューニング

自動ハイパーパラメータ最適化。GridSearch、RandomSearch、BayesianOptimizationをサポート。

apiVersion: kubeflow.org/v1alpha3
kind: Experiment
metadata:
  name: random-example
spec:
  algorithm:
    algorithmName: random
  parallelTrialCount: 3
  maxTrialCount: 12

Kubeflow Pipelines

DAG形式で ML ワークフロー定義。

import kfp
from kfp import dsl
from kfp.v2.dsl import component

@component
def preprocess_data(input_path: str) -> str:
    import pandas as pd
    df = pd.read_csv(input_path)
    return '/output.csv'

@dsl.pipeline(name='ML Pipeline')
def ml_pipeline(input_path: str = 'data.csv'):
    preprocess_task = preprocess_data(input_path=input_path)

KServe - モデルサービング標準化

KServe (kserve.github.io) は、Kubernetes上でML モデルをサービングする標準を提供します。

InferenceService デプロイ

マルチフレームワーク対応（TensorFlow、PyTorch、Scikit-learn、XGBoost）。

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    sklearn:
      storageUri: s3://bucket/model.pkl
  autoscaler:
    minReplicas: 1
    maxReplicas: 10

トラフィック分割（A/B テスト）:

spec:
  predictor:
    sklearn:
      storageUri: s3://bucket/model-v1.pkl
  canaryTrafficPercent: 10

リクエスト例

REST エンドポイント:

import requests

url = "http://iris-sklearn-predictor.example.com/v1/models/iris:predict"
request = {"instances": [[6.8, 2.8, 4.8, 1.4]]}
response = requests.post(url, json=request)

MLflow - ML エクスペリメント管理

MLflow (mlflow.org) は、MLライフサイクル全般を管理するオープンソースプラットフォーム。

Tracking - 実験追跡

import mlflow
from sklearn.ensemble import RandomForestClassifier

mlflow.set_experiment("iris-classification")

with mlflow.start_run(run_name="rf-v1"):
    params = {"n_estimators": 100, "max_depth": 10}
    mlflow.log_params(params)
    
    model = RandomForestClassifier(**params)
    model.fit(X_train, y_train)
    
    accuracy = model.score(X_test, y_test)
    mlflow.log_metrics({"accuracy": accuracy})
    mlflow.sklearn.log_model(model, artifact_path="model")

MLflow Models 標準化フォーマット

time_created: 2026-05-02T12:00:00.000Z
flavors:
  sklearn:
    sklearn_version: 1.0.0
    pickled_model: model.pkl

signature:
  inputs:
    - name: sepal_length
      type: double
  outputs:
    - name: predictions
      type: integer

Google Cloud Vertex AI

Google Cloud (cloud.google.com, developers.google.com) の Vertex AI は、フルマネージドML開発プラットフォーム。

ワークフロー

  1. データ準備：BigQuery連携
  2. モデル訓練：AutoML またはカスタムトレーニング
  3. ハイパーパラメータ最適化：Vizier
  4. モデルデプロイ：Vertex Prediction
  5. モデル監視：Vertex Model Monitoring

カスタムトレーニングジョブ

from google.cloud import aiplatform

job = aiplatform.CustomTrainingJob(
    display_name='iris-training',
    script_path='train.py',
    container_uri='gcr.io/cloud-aiplatform/training/tf-cpu.2-10:latest'
)

model = job.run(
    args=['--output_dir=gs://my-bucket/models'],
    sync=True
)

ONNX - モデル相互運用性標準

ONNX (onnx.ai) は、異なるフレームワーク間でのモデル交換を可能にします。

モデル変換

import onnx
import onnxruntime as rt
from sklearn.ensemble import RandomForestClassifier
import skl2onnx

model = RandomForestClassifier(n_estimators=10)
model.fit(X_train, y_train)

initial_type = [('float_input', FloatTensorType([None, 4]))]
onnx_model = skl2onnx.convert_sklearn(model, initial_types=initial_type)
onnx.save_model(onnx_model, "iris_model.onnx")

# ONNX Runtime での推論
sess = rt.InferenceSession("iris_model.onnx")
input_name = sess.get_inputs()[0].name
pred_onx = sess.run(None, {input_name: X_test.astype(np.float32)})[0]

ONNXのメリット

  • フレームワーク非依存
  • 本番環境での最適化済み推論
  • エッジデバイスでの実行可能
  • モデルサイズ削減

MLOps ベストプラクティス

  1. 実験の再現性

    • 乱数シード管理
    • 依存パッケージのバージョン固定
    • MLflow で全パラメータ記録

  2. モデルレジストリ

    • MLflow Model Registry での版管理
    • ステージング：Development -> Staging -> Production
    • メタデータと変更履歴

  3. 継続的統合/デプロイ (CI/CD)

    • 新データで再訓練
    • テストセットで評価
    • ベースラインと

MLOps パイプラインの構築

CI/CD for ML

Data Pipeline: データ品質チェック、欠損値処理、特徴エンジニアリング。自動化により一貫性保証。

Model Training: ハイパラ探索、交差検証。自動再学習スケジュール（定期実行、データドリフト検出時）。

Model Evaluation: テストセットでの精度・バイアス・レイテンシ検証。しきい値超過で自動ロールバック。

モデルレジストリとバージョン管理

MLflow Model Registry: モデルの段階的プロモーション（Development → Staging → Production）。メタデータ、パラメータ、メトリクスを一元管理。

Model Card: モデル設計、学習データ、バイアス、用途を標準フォーマットで文書化。

監視とアラート

Performance Monitoring: 本番精度の低下を検出（Concept Drift、Data Drift）。

Latency SLO: 推論遅延の目標値を設定。超過時は自動スケーリングまたはモデル簡化。

Explainability Drift: 特徴重要度の変化を監視。重要度の急落は学習データ変化を示唆。

Kubernetes での ML デプロイメント

Kubeflow: ML ワークフロー（データ準備 → 学習 → 提供）の オーケストレーション。

KServe: 推論サービングの標準化。モデル A/B テスト、カナリアリリース、トラフィック分割。

Seldon: マルチモデルサービング、フィーチャーストア統合。

Feature Storeの実装例

中央集約型フィーチャー管理。オンライン（低遅延推論）とオフライン（バッチ学習）の dual-write。

既存フィーチャー の再利用により開発速度向上。一貫性保証。

例：Tecton、Feast。

モデル評価と交差検証

K-fold cross-validation: データを k 分割。k-1 で学習、1 で検証。繰り返し。過学習判定。

Stratified K-fold: クラス不均衡対応。各fold がクラス分布維持。

Time series validation: 時系列データで forward-chaining（未来テスト）。

本番トラブルシューティング

Slow inference: モデル圧縮、並列化、キャッシング。

Out of memory: バッチサイズ削減、quantization、model sharding。

Data pipeline failures: Checkpointing で復旧。監視と alerting。

高度なモデルサービング

シャドーデプロイ

本番前に新モデルをシャドウ実行。ユーザーに影響なし。本番予測と比較。

自信度（confidence）低い場合は本番投入を遅延。

A/Bテスト基盤

キャッシング戦略。ユーザー ID hash で一貫したグループ割り当て。

統計的有意性検定（t-test）。多重比較 correction（Bonferroni）。

モデル圧縮

Quantization: FP32 → INT8 で 4 倍圧縮。精度損失 1-5%。

Pruning: 重要度低いニューロン削除。50-90%削減可能。

Distillation: 大モデルを小モデルに蒸留。知識転移。

監視（データドリフト検出）

  • 予測精度の継続監視
  • 異常値検出と自動リトレーニング

関連技術とエコシステム

ここで紹介した各技術には、活発なコミュニティ・エコシステムが存在。 継続的な学習とアップデートを推奨。実装言語・フレームワークの選択は プロジェクト要件に基づいて判断。性能、保守性、開発速度のバランスが重要。

まとめ

MLOpsはMLを継続運用するための土台です。モデル精度だけでなく、再現性、監視、更新導線まで揃って初めて実務のシステムになります。

実務上の優先順位:

  • Reproducibility: データ・コード・環境のバージョン管理 (DVC, Git, Docker) を最初に整える
  • Observability: 推論レイテンシ、入力分布のドリフト (PSI / KL divergence)、精度劣化を監視
  • Rollback path: Model Registry で前バージョンへの即時切り戻しを保証
  • Cost discipline: GPU 使用率と Cold start のトレードオフを定期レビュー

参考文献

式・標準

論文

解説・補助