MLOps Lifecycle（機械学習ライフサイクル運用）
ML システム運用の地図層。DevOps との差分 (データ/モデル/実験の三位一体・非決定論・training-serving skew・CT)、10 フェーズ・成熟度モデル・Three Pipelines・失敗モード (Sculley)・LLMOps を俯瞰し各深掘り記事へ委譲。
article technology ja ML システム運用の地図層。DevOps との差分 (データ/モデル/実験の三位一体・非決定論・training-serving skew・CT)、10 フェーズ・成熟度モデル・Three Pipelines・失敗モード (Sculley)・LLMOps を俯瞰し各深掘り記事へ委譲。MLOps Lifecycle（機械学習ライフサイクル運用）
MLOps は ML システムの構築・デプロイ・監視・継続的改善を組織的に成立させる実践・文化・ツールの集合体で、DevOps を ML の文脈へ拡張したものである。DevOps と決定的に異なるのは、コードに加えて データとモデルを第一級アーティファクト として扱う点、同一コードでもデータ変化で出力が変わる 非決定論性、学習時と推論時の特徴量処理が乖離する training-serving skew、そしてコードを変えずともデータ変化で再学習が必要になる CT（Continuous Training） の存在である。本記事はライフサイクル全体を束ねる 地図層（オーケストレーション層） として、デプロイ戦略・ドリフト検知・マネージド基盤・分散学習などの内部詳細は各深掘り記事へ委譲する。confidence: medium は情報カットオフ ~2025-08 に基づく固定値で、2025/2026 のツールバージョン・規制スケジュールは [要確認] を付す。
MLOps の定義と DevOps との差分
MLOps = DevOps 実践 + ML 固有の関心事（データ・モデル・実験）で、DataOps（データ品質保証）を取り込んで成立する。中核の差分を整理する。
| 軸 | 伝統的 DevOps | MLOps |
|---|---|---|
| 成果物 | コード | コード + データ + モデル（三位一体） |
| 決定論性 | 同コード → 同出力 | データ変化で出力が変わる（非決定論的） |
| テスト対象 | 機能 / 回帰 | モデル性能 / データ品質 / 分布 |
| パイプライン | CI/CD | CI/CD + CT |
| 変化トリガ | コード変更 | コード変更 + データ変更 + 性能劣化 |
| 依存 | ライブラリ | ライブラリ + データソース + 特徴量スキーマ |
| 固有障害 | — | training-serving skew |
Training-Serving Skew は MLOps 固有の主要障害で、特徴量処理のロジックが学習と推論で乖離し、オフライン評価と本番性能に大きなギャップを生む。CT は「コードを変えずともデータが変われば再学習が必要」という DevOps に存在しない概念で、CI/CD をそのまま適用できない根本理由である。
エンドツーエンドのライフサイクル 10 フェーズ
各フェーズで生成されるアーティファクトと通過すべき品質ゲートを示す。
| 相 | フェーズ | 主アーティファクト | 品質ゲート |
|---|---|---|---|
| A | 問題定義・フレーミング | 問題定義書・成功 KPI・実現可能性 | ビジネス KPI と ML 指標の対応明文化 |
| B | データ収集・バリデーション | データパイプライン・品質レポート・スキーマ | スキーマ一貫性・欠損率・参照整合性 |
| C | 特徴エンジニアリング / Feature Store | FeatureView・オフライン/オンライン特徴量 | 特徴量ドリフト・Point-in-Time 正当性 |
| D | 実験・モデル開発 | 実験ログ・ベースラインモデル | ベースライン有意差・再現可能性 |
| E | 学習・チューニング | 学習済み重み・HPO ログ | 検証性能・収束・再現性 |
| F | 評価・バリデーション | 評価/フェアネスレポート・モデルカード | KPI 閾値・スライス別性能・回帰チェック |
| G | モデルレジストリ・バージョニング | バージョン化モデル・ステージラベル | 承認ゲート・系譜完全性 |
| H | デプロイ・サービング | 推論エンドポイント・配信コンテナ | レイテンシ SLO・ロールバック手順 |
| I | 監視・オブザーバビリティ | ダッシュボード・アラート・ドリフトレポート | ドリフト/性能劣化検知 |
| J | 継続的再学習・ガバナンス | 再学習トリガ・監査ログ・ラベリング | 再学習後の再評価・承認フロー |
C 相の Point-in-Time Correctness は学習時の未来情報混入（target leakage）を防ぐタイムスタンプ制御で、Feature Store が自動保証する設計が多い。F 相の モデルカード は対象ユース・評価条件・サブグループ性能・倫理的考慮を記述する。
MLOps 成熟度モデル
最も広く参照されるのは Google Cloud のレベル定義である。
- Level 0（手動）: 実験と本番が分離。Jupyter で手動学習しモデルファイルを受け渡す。監視・再学習なし。更新頻度は年 1–2 回。
- Level 1（ML パイプライン自動化）: 学習パイプライン自動化（Kubeflow / TFX / Airflow）。特徴処理がパイプラインに統合され skew が軽減。CT 導入。デプロイは半手動。
- Level 2（CI/CD + CT）: コード変更が自動テスト→自動デプロイ、ドリフト検知→自動再学習。Feature Store・実験追跡・モデルレジストリ・自動評価ゲート・監視が完全統合され、ソフトウェア同等の速度でモデルを進化させる。
Microsoft の成熟度モデルは 5 段階（0: No MLOps / 1: DevOps no MLOps / 2: Automated Training / 3: Automated Model Deployment / 4: Full MLOps Automated Retraining）で、Level 4 がドリフト検知→自動再学習の完全 CI/CD/CT に対応する。両モデル共通の MLOps 固有の付加要素が CT であり、CI/CD への上乗せではなくデータ駆動の再学習ループを成熟度の軸に据える点が要諦である。
Three Pipelines パターンとトリガモデル
MLOps は相互に連動する 3 本のパイプラインで構成される。Data Pipeline（収集→バリデーション→特徴エンジニアリング→Feature Store）、ML Training Pipeline（学習→評価→バリデーション→Model Registry）、CI/CD Pipeline（Staging テスト→Shadow→カナリア→本番）。Data の出力（特徴量）が Training を駆動し、Training の出力（承認済みモデル）が CI/CD を駆動する。
| トリガ種別 | 対象パイプライン | 条件例 |
|---|---|---|
| コード変更 | CI/CD | Git PR マージ |
| データ変化 | Data → Training | 新バッチ到着・スキーマ変更 |
| スケジュール | Training | 週次/日次再学習 |
| 性能劣化 | Training | 本番精度が閾値以下 |
| ドリフト検知 | Training | データ/コンセプトドリフトアラート |
| 手動承認 | CI/CD | 規制対象モデルの人間サインオフ |
このトリガの多様性こそ DevOps（コード変更のみ）との差であり、CT を運用に組み込む設計の出発点になる。
コアコンポーネントとツールランドスケープ
ライフサイクル各相の代表ツールを 1 つに絞って示す（バージョンは [要確認]）。
| ステージ | 代表ツール | 役割 |
|---|---|---|
| データ検証 | Great Expectations / TFDV | 品質ルール・スキーマ推論・ドリフト検出 |
| 特徴量 | Feast（OSS）/ Tecton（商用） | 再利用・PIT 一貫性・低レイテンシ配信 |
| 実験追跡 | MLflow Tracking | パラメータ/メトリクス/アーティファクト記録 |
| モデルレジストリ | MLflow Model Registry | ステージ管理（Staging/Prod/Archived） |
| オーケストレーション | Kubeflow Pipelines | K8s ネイティブのコンテナ化ステップ |
| データ/モデル版管理 | DVC / LakeFS | Git 連携バージョニング・タイムトラベル |
| サービング | KServe | 推論エンドポイント管理 |
| 監視 | Evidently AI | ドリフト/性能レポート |
| CI/CD | GitHub Actions + Argo CD | テスト→デプロイ・GitOps |
選択は マネージド統合 vs コンポーザブル OSS のトレードオフに帰着する。マネージド（SageMaker / Vertex AI / Azure ML → 詳細は tech-74）はインフラ管理不要・統合ツールチェーン・サポートが利点だが、ロックイン・カスタマイズ制限・従量コストが難点。OSS スタックはロックインなし・フルカスタマイズ・コスト透明性が利点だが、統合コスト・スキル要件・運用負荷が高い。ZenML 等の抽象化レイヤはスタックを「コード」として定義し両者を橋渡しする [要確認]。
再現性・系譜・ガバナンス
再現可能な ML システムには データ・コード・モデルの三位一体バージョニング が必要である。データ版（DVC tag / LakeFS commit / Delta Lake version）+ コード版（git commit hash）+ 環境版（Docker image hash / conda.lock）→ モデルアーティファクト（MLflow run_id）の連鎖を固定する。
系譜（lineage）は 4 層で追跡する。(1) データ系譜: 生データ→前処理→特徴量→学習データ、(2) 実験系譜: パラメータ→メトリクス→アーティファクト、(3) デプロイ系譜: モデル版→デプロイ時刻→エンドポイント、(4) デシジョン系譜: 推論→使用モデル版→出力。この 4 層がコンプライアンスとインシデント対応を支える。
文書化標準として モデルカード（Mitchell et al., FAccT 2019）が対象ユース・評価条件・サブグループ性能・倫理的考慮を記述する。EU AI Act は高リスク AI（採用・信用・医療・法執行等）にリスク管理文書・データガバナンス・技術文書・ログ保存・人間による監視・適合性評価を要求し、MLOps の監査証跡・系譜・モデルカードがその技術基盤となる（施行スケジュール・高リスク分類の最終テキストは [要確認]）。規制対象モデルでは Level 2 でも人間の最終 承認ゲート（CI の environment: production + 必須レビュアー等）を設ける設計が推奨される。
本番モニタリングと継続的再学習
監視の主軸は 2 種のドリフトである。データドリフト（covariate shift） は入力特徴量の分布変化（例: 季節変動で年齢層が変わる）、コンセプトドリフト は入力に対する正解ラベルの関係変化（例: フィッシング手口の進化）。加えて training-serving skew がオフライン/本番の乖離を生む。指標計算・PSI/KL・アラート閾値などの監視内部は tech-83 へ委譲する。
Ground-Truth ラグ 問題（例: ローン審査の不良債権判定は数ヶ月後）では正解が即座に得られず、代理指標（サロゲートメトリクス）の設計が必要になる。継続的再学習の設計原則は 3 点に集約される。(1) 盲目的な自動化を避ける: ドリフト検知→自動再学習の全自動化はラベルノイズやデータ品質問題まで学習する、(2) 再学習後の再評価を必須化: 本番化前に必ず評価パイプラインを通す、(3) ロールバック手順を事前定義: 性能劣化時に旧版へ即座に戻す。これらは Three Pipelines の Training→CI/CD 接続点に承認ゲートとして実装される。
失敗モードとアンチパターン
主要失敗モードを整理する（多くは Sculley et al. 2015 に由来）。
| ID | アンチパターン | 説明 | 検出時期 |
|---|---|---|---|
| AP-1 | Training-Serving Skew | 学習と推論で異なる特徴量処理 | 本番デプロイ後 |
| AP-2 | Hidden Feedback Loop | 出力が将来の学習データを汚染 | 長期運用後 |
| AP-3 | Data Leakage into Features | 評価時に未来情報混入（target leakage） | 実験段階で検出困難 |
| AP-4 | Pipeline Jungle | 場当たり変換の堆積で全体把握不能 | 運用フェーズ |
| AP-5 | Undeclared Consumers | 出力を無断利用する下流が増殖 | 組織レベル |
| AP-6 | Dead Experimental Code | 実験コードが本番に残留 | コードレビュー |
| AP-7 | Retraining Without Validation | 再学習→評価スキップ→劣化モデル本番化 | 本番デプロイ後 |
| AP-8 | Silent Rollback Gap | ロールバック未整備で旧モデルに戻せない | インシデント時 |
| AP-9 | CACE 違反 | 1 点変更が全体へ連鎖 | 変更直後〜数週間後 |
| AP-10 | Concept Drift 無視 | 再学習なし放置で静かに劣化 | KPI 悪化時 |
CACE（Changing Anything Changes Everything） は、ML では入力特徴量・ハイパーパラメータ・学習データ・フレームワーク版が相互依存し 1 点の変更が予測不能な連鎖を引き起こすという原則で、厳格なバージョニングと評価ゲートを必要とする根拠である。Hidden Feedback Loop は出力が世界に影響し次回学習データに反映されるループ（推薦→クリック→学習データ→フィルターバブル、審査拒否→偏見増幅）で、長期運用で顕在化する。出典: D. Sculley et al., NeurIPS 2015。
LLMOps デルタ（2025/2026 フロンティア）
LLM / 基盤モデルの運用は従来 MLOps を拡張し固有の関心事を加える（ツール名・バージョンは [要確認]）。
- プロンプトバージョニング: プロンプトはコードであり版管理が必須。変更はモデル重み更新に相当する影響を持つ（LangSmith / PromptLayer 等）。
- 評価ハーネス（LLM-as-Judge）: 人手評価コストが高く LLM を評価者に用いる。評価モデルと評価対象を一致させない設計が推奨される（lm-evaluation-harness / Ragas 等）。
- RAG パイプライン運用: ベクトルストア（Chroma / Qdrant / Pinecone 等）のインデックス更新・チャンク戦略の版管理・Recall@k/MRR 監視・ハルシネーション検出。エンベディングモデル変更時はインデックス全体の再構築を要する。
- Fine-tune → Eval → Deploy ループ: SFT/RLHF/DPO（詳細は tech-49）をパイプライン化し、ベースモデル版のピン留め・MMLU/HumanEval 等の評価ゲート組込み・量子化後の再評価（詳細は tech-87）を行う。
- ガードレール: 入力（プロンプトインジェクション対策）・出力（PII/有害コンテンツ/ハルシネーション）の両面制御（NeMo Guardrails / Llama Guard 等）。
- トークンコスト監視: 推論コストがトークン消費に比例するため、プロンプト長変化・キャッシュヒット率・モデル版別コストを監視次元に加える。
継続/転移学習のメソッドは tech-86、K8s 基盤は tech-80 / tech-66、分散学習は tech-48、デプロイ戦略（カナリア/Blue-Green/シャドウ）は tech-85 を参照。
参考文献
- D. Sculley, G. Holt, D. Golovin, et al. “Hidden Technical Debt in Machine Learning Systems.” NeurIPS 2015.
- Google Cloud. “MLOps: Continuous delivery and automation pipelines in machine learning.” Architecture doc.
- Microsoft. “Machine Learning operations maturity model.” Azure Architecture Center.
- S. Amershi, A. Begel, C. Bird, et al. “Software Engineering for Machine Learning: A Case Study.” ICSE-SEIP 2019.
- M. Mitchell, S. Wu, A. Zaldivar, et al. “Model Cards for Model Reporting.” FAccT 2019. arXiv:1810.03993.
Backlinks
No backlinks yet