MLOps ── MLモデルの開発・運用を統合する考え方
研究で良い精度が出たモデルが、 本番投入後に「データが変わって精度急落」「再学習の手順が再現できない」と崩壊するのを防ぐのがMLOps。 競技や論文の後、 実務に乗せるなら必須の知識です。
従来のソフトウェア開発（DevOps）と比べると、 MLOpsの独自の難しさが見えます：
| 側面 | 従来のDevOps | MLOps |
|---|---|---|
| ビルド対象 | コード | コード + データ + モデル |
| テスト | ユニット／統合テスト | + データ品質、 モデル精度、 公平性 |
| 再現性 | 同じコード→同じ動作 | 同じコード + 同じデータ + 同じ乱数 → 同じモデル |
| 劣化 | バグ以外は基本起きない | データ分布の変化で勝手に劣化 |
| 監視対象 | 応答時間、 エラー率 | + 予測分布、 入力ドリフト、 ラベル遅延 |
つまり、 「動いている」を維持するだけで通常のWebサービスの何倍も気を配る必要があります。
MLOpsの中核ループは CT（Continuous Training）と呼ばれる継続的再学習サイクル：
Google が提案する成熟度モデルでは、 レベル0（手作業）→ レベル1（ML自動化）→ レベル2（CI/CD自動化）の3段階で評価。
典型的なMLOpsプロジェクトの1スプリント（2週間）の作業ログ例：
最小限のスニペットで動作確認できる例。 公的データ（SSDSE 等）を想定しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 | # MLflow による実験トラッキング（MLOpsの最小例） import mlflow import mlflow.sklearn from sklearn.ensemble import RandomForestRegressor mlflow.set_experiment("ssdse_aging_rate") with mlflow.start_run(): mlflow.log_param("n_estimators", 100) model = RandomForestRegressor(n_estimators=100).fit(X_train, y_train) score = model.score(X_test, y_test) mlflow.log_metric("r2", score) mlflow.sklearn.log_model(model, "model") # 後で `mlflow ui` で実験履歴・パラメータ・精度を一覧表示できる |
| レベル | 特徴 | 例 |
|---|---|---|
| 0：手動 | Jupyter notebook で実験、 手作業デプロイ | 個人研究 |
| 1：ML自動化 | パイプライン化、 自動再学習 | 中規模スタートアップ |
| 2：CI/CD自動化 | コードpush→テスト→再学習→デプロイ全自動 | 大規模AI企業 |
| レベル | 特徴 | 例 |
|---|---|---|
| 0：手動 | Jupyter notebook で実験、 手作業デプロイ | 個人研究 |
| 1：ML自動化 | パイプライン化、 自動再学習 | 中規模スタートアップ |
| 2：CI/CD自動化 | コードpush→テスト→再学習→デプロイ全自動 | 大規模AI企業 |