MLOpsが必要な理由
「Jupyter Notebookで精度95%を達成した」と「本番環境で安定して精度95%を維持している」の間には、巨大な溝がある。Google Researchの論文「Hidden Technical Debt in Machine Learning Systems」が指摘した通り、MLシステムにおけるモデルコードは全体のごくわずかで、大部分はデータパイプライン、特徴量管理、モニタリング、サービングインフラだ。
KGAでは年間20以上のMLプロジェクトを手がけているが、本番デプロイ後にモデル性能が劣化する「静かな障害」を何度も経験してきた。これを体系的に防止するのがMLOpsパイプラインだ。
実験管理: MLflow Tracking
MLflowはMLOpsの中心的なツールだ。KGAではMLflow 2.xを全MLプロジェクトの実験管理に使用している。
実験管理で重要なのは「再現可能性」だ。MLflow Trackingで記録すべき項目: ハイパーパラメータ（learning_rate、batch_size等）、データセットのバージョン（DVC hash）、前処理パイプラインのバージョン、環境情報（Python版、CUDA版、依存ライブラリ）、評価メトリクス（accuracy、F1、AUC等）、モデルアーティファクト（重みファイル）。
KGAの実装では、mlflow.autolog()で基本メトリクスを自動記録しつつ、カスタムメトリクス（ビジネスKPIに対応する指標）は明示的にmlflow.log_metric()で記録している。「技術的な精度」と「ビジネス上の価値」を同一実験で追跡できることが、ステークホルダーとのコミュニケーションを大幅に円滑化する。
Feature Store: Feast実践
Feature Store（特徴量ストア）は、特徴量の計算・格納・提供を一元管理するシステムだ。KGAではFeast（v0.38）を採用している。
Feature Storeなしの世界では、学習時と推論時で特徴量計算のコードが重複し、Training-Serving Skewの温床となる。あるクライアントでは、学習時はPandasで計算した特徴量が、推論時はJavaで再実装されており、微妙な計算誤差でモデル精度が本番で7%低下していた。
Feastの構成: Offline Store: BigQuery（学習用のバッチ特徴量）。Online Store: Redis（推論用の低レイテンシ特徴量提供）。Feature Registry: GCS上のYAML定義（特徴量のスキーマ、所有者、SLA）。Materialization: Offline→Onlineの定期同期（毎時または日次）。
重要な設計判断として、Point-in-Time Correctness（時点整合性）がある。学習時に「2024年3月1日時点で利用可能だった特徴量」を正確に再現する必要があり、未来の情報が混入するdata leakageを防止する。Feastのget_historical_features()メソッドがこれを自動的に処理する。
モデルレジストリと承認ワークフロー
MLflow Model Registryでモデルのライフサイクル管理を行う。ステージは「Staging」→「Production」→「Archived」の3段階。KGAでは以下の承認ワークフローを運用している。
- データサイエンティストがモデルを学習し、MLflowに登録（自動でStaging）。2. 自動評価パイプラインがテストデータセットでベンチマーク実行。3. 品質ゲート（accuracy > baseline + 1%、latency < 100ms、メモリ使用量 < 2GB）を自動チェック。4. 品質ゲート通過後、MLエンジニアがレビューし、Production昇格を承認。5. Blue-GreenデプロイでProductionモデルを入れ替え。
品質ゲートの自動化が重要だ。人手レビューだけでは見落としがあるし、スピードも遅い。KGAでは品質ゲートをGitHub Actionsで実装し、PRマージからStaging評価完了まで平均25分で処理している。
デプロイ戦略とドリフト検知
モデルのデプロイ方式は用途により使い分ける。リアルタイム推論: KServe（Kubernetes上のモデルサービングフレームワーク）でAutoScalingを設定。バッチ推論: Apache Sparkジョブで大量データを一括処理。エッジ推論: ONNX Runtimeでモデルを変換し、エッジデバイスやブラウザで推論。
モデルが本番で「静かに壊れる」最大の原因はデータドリフトだ。入力データの分布が学習時から変化し、モデルの予測精度が徐々に低下する。KGAのドリフト検知パイプライン: Feature Drift: 各特徴量の分布をKolmogorov-SmirnovテストとPopulation Stability Index（PSI）で日次監視。PSI > 0.2で警告、> 0.25でアラート。Prediction Drift: モデルの予測分布の変化をJensen-Shannon Divergenceで監視。Concept Drift: 予測と実際のラベルの乖離を監視。
実例として、不動産価格予測モデルで金利変動に起因するconcept driftを検出した事例がある。PSIが0.31に達した時点でアラートが発火し、3日以内にモデルを再学習して精度低下を最小限に抑えた。ドリフト検知なしではこの劣化に気づくまで2-3ヶ月かかっていただろう。