🎓 レベル:基礎 | 重要度:A(必須)
📎 前提:なし(第1章の入口) | 関連:MLOpsと実験管理(機械学習)
要点(BLUF)
- **MLOps とは「MLライフサイクル(データ→学習→デプロイ→監視→再学習)を継続的に回し続けるための運用規律」**です。一度デプロイして終わる「プロジェクト」ではなく、回し続ける「プロダクト」として扱います。
- DevOps との決定的な違いは、動く部品がコードだけでなく「データ」と「モデル」にも増えること。データが変われば、コードが1行も変わらなくても挙動が変わります。
- だから MLOps はバージョニング・テスト・デプロイ・監視の対象をコード/データ/モデルの3つに拡張し、ライフサイクルを閉じたループとして自動化していきます。
1. MLOps とは何か
MLOps(Machine Learning Operations)は、機械学習モデルを本番環境で確実に動かし続けるための、プロセス・ツール・文化の総称です。DevOps が「ソフトウェアを継続的にデリバリーする規律」だとすれば、MLOps は「MLシステムを継続的にデリバリーし、かつ運用中も性能を維持する規律」です。
研究や PoC では「精度 90% のモデルができた」で一区切りですが、本番ではそこがスタート地点です。ユーザーの行動は変わり、入力データの分布はずれ、依存ライブラリは更新され、モデルの精度は静かに落ちていきます。MLOps はこの「作った後の長い時間」をどう設計するかの学問です。
2. MLライフサイクル:閉じたループ
MLシステムは直線ではなくループで回ります。
flowchart LR A["問題定義"] --> B["データ収集と準備"] B --> C["特徴量エンジニアリング"] C --> D["モデル学習と評価"] D --> E["デプロイとサービング"] E --> F["本番監視"] F -->|"性能劣化やドリフトを検知"| G["再学習のトリガー"] G --> B
ポイントは末尾の戻り矢印です。監視で劣化を検知したら、データ収集からやり直す。このループを人手のヒロイズムでなく仕組みで回すのが MLOps の中核で、第6章(再学習と継続的トレーニング(CT))でループを閉じます。
3. DevOps との違い:3つの軸
| 観点 | DevOps | MLOps |
|---|---|---|
| バージョン管理の対象 | コード | コード+データ+モデル |
| テスト | 単体・結合テスト | +データ検証・モデル検証(精度・公平性・スキュー) |
| デプロイ後の挙動 | コードが同じなら同じ | 入力分布が変われば劣化する |
| 成果物 | 決定的(ビルド) | 確率的・データ依存(学習の再実行で微妙に変わりうる) |
最大の違いは「Change Anything Changes Everything(CACE)」——ML では一つのハイパーパラメータ・特徴量・データソースを変えると、システム全体の挙動が連動して変わります(MLシステムの技術的負債)。だからコードのユニットテストだけでは品質を保証できません。
4. 動く最小例:「コードが同じでもデータで結果が変わる」を体感する
MLOps の出発点となる直観——同じ学習コードでも入力データが変われば出力(モデル)が変わる——を最小コードで確認します。
import numpy as np
from sklearn.linear_model import LogisticRegression
def train_and_report(seed, drift=0.0):
rng = np.random.default_rng(seed)
n = 400
# クラス1の平均をdriftだけずらす(データ分布の変化を模擬)
X0 = rng.normal(0.0, 1.0, (n, 2))
X1 = rng.normal(1.5 + drift, 1.0, (n, 2))
X = np.vstack([X0, X1])
y = np.array([0]*n + [1]*n)
model = LogisticRegression().fit(X, y)
return model.coef_[0]
base = train_and_report(seed=0, drift=0.0)
drifted = train_and_report(seed=0, drift=1.0) # データだけ変えた
print(f"学習コードもseedも同一。データのみ変更")
print(f"係数(元データ) = [{base[0]:.3f}, {base[1]:.3f}]")
print(f"係数(ドリフト後) = [{drifted[0]:.3f}, {drifted[1]:.3f}]")
print(f"係数ノルムの変化 = {np.linalg.norm(drifted - base):.3f}")
出力:
学習コードもseedも同一。データのみ変更
係数(元データ) = [1.689, 1.628]
係数(ドリフト後) = [2.588, 2.590]
係数ノルムの変化 = 1.317
出力の意味:学習コードもシードも完全に同じなのに、入力データの分布をずらしただけで学習されたモデル(係数)が大きく変わりました。これが「コードだけ管理しても再現できない」というMLの本質で、データもバージョニングの対象になる理由です(再現性とバージョニング)。
5. 運用の勘所:プロジェクトでなくプロダクトとして設計する
- 最初から「2回目の学習」を想定する:1回デプロイして終わりではなく、再学習・再デプロイが何度も走る前提でパイプラインを組む(MLパイプラインの全体設計)。
- オーナーシップを決める:モデルが劣化したとき誰が気づき、誰が再学習を承認するか。監視(第6章)と組織の責任分界をセットで設計する。
- 小さく始めて成熟度を上げる:いきなり完全自動化は不要。まず手作業を可視化し、再現可能にし、段階的に自動化する(MLOps成熟度モデルと自動化レベル)。
なぜそうするのか
MLモデルの価値は「学習時の精度」ではなく「本番で出し続ける予測の質」で決まります。学習時にどれだけ高精度でも、本番で分布がずれて劣化すれば価値はゼロに近づきます。MLOps を「ループを回す規律」と定義するのは、価値の源泉が一回の学習ではなく運用の継続性にあるからです。
⚠️ よくある落とし穴
- 「モデルができた=完成」と考える:本番投入はゴールでなくスタート。監視と再学習の設計がないモデルは数か月で陳腐化する。
- コードだけ Git に入れて満足する:データとモデルが固定されていないと、同じコードでも結果が再現しない(§4)。
- DevOps の道具をそのまま流用しようとする:CI/CD は流用できるが、データ検証・モデル検証・ドリフト監視という ML 固有の関心が抜け落ちる。
- 完全自動化を最初から目指す:成熟度を飛ばすと運用が破綻する。まず再現性、次に自動化。
対応 lab
- なし(概念ノート)。動く最小例は本文 §4 に同梱。実運用の最小サービングは オンライン推論サービング、トラッキングは 実験トラッキング の lab で扱います。
関連ノート
- MLシステムの技術的負債(CACE と隠れた負債)
- 再現性とバージョニング(コード・データ・モデルの三位一体)
- MLパイプラインの全体設計(ループを仕組みにする)
- MLOps成熟度モデルと自動化レベル(自動化の現在地)
- MLOpsと実験管理(機械学習・理論的背景)
- 第1章 MLOpsの全体像 目次
- MLOps・AI基盤 全体目次