MLOps

概要

MLOps（Machine Learning Operations）は、機械学習モデルの開発から本番運用までを、継続的かつ再現可能に回すための実践の総称です。データの収集と前処理、モデルの学習と評価、デプロイ、本番での監視、そして性能が落ちたときの再学習 — このサイクル全体をパイプラインとして自動化・標準化することを目指します。DevOps がアプリケーション開発と運用の壁を壊したように、MLOps はデータサイエンティストの実験とエンジニアの本番運用の壁を壊す取り組みです。

機械学習プロジェクトの難しさは「モデルを作ること」よりも「作ったモデルを本番で動かし続けること」にあります。Jupyter Notebook 上では良い精度が出たのに本番に持っていけない、半年前のモデルを再現できない、いつの間にか精度が劣化していたことに誰も気づかない — こうした「本番化の谷」を埋める方法論として、MLOps は2010年代後半に急速に体系化されました。

なぜ生まれたか

ソフトウェアの世界には CI/CD やバージョン管理という成熟した仕組みがありましたが、機械学習はそのままでは乗りませんでした。理由は、システムの振る舞いを決める要素がコードだけではないからです。同じコードでも学習データが変われば別のモデルができ、同じデータでも乱数シードやハイパーパラメータが違えば結果が変わります。つまり成果物が「コード×データ×設定」の掛け算で決まるのに、Git で管理できるのはコードだけ。実験は Notebook に散らばり、「あの精度が出たモデル、どのデータとどの設定で作ったんだっけ」が誰にも分からなくなるのが常態でした。

さらに深刻なのは、デプロイして終わりにならないことです。普通のソフトウェアは仕様が変わらなければ動き続けますが、モデルは世界の側が変わると壊れます。ユーザーの行動、市場、季節性 — 学習時のデータ分布と本番の入力がずれていく「ドリフト」により、コードを1行も変えていないのに精度が静かに劣化していくのです。Google のエンジニアが2015年の論文で「機械学習システムは技術的負債の高利貸しである」と警告したように、この特有の劣化と複雑さに対処する運用体系が必要とされ、DevOps の思想を機械学習に拡張した MLOps が生まれました。

詳細

3軸のバージョン管理と継続的なループ

MLOps の出発点は、再現性のために「コード・データ・モデル」の3つを揃えてバージョン管理することです。コードは Git で管理できますが、数百 GB のデータセットや学習済みモデルはリポジトリに入りません。そこでデータには DVC や lakeFS のようなデータバージョニングツール、モデルには「モデルレジストリ」（学習済みモデルを、使ったデータ・コード・設定・評価指標と紐付けて登録する台帳）を使います。この3軸が揃って初めて、「本番のモデル v12 は、データセット v5 とコード v3.1 から、この設定で学習された」という系譜（リネージ）をたどれるようになります。

実験管理とパイプラインの自動化

開発フェーズの中心は実験管理です。MLflow や Weights & Biases のようなツールで、実験ごとのハイパーパラメータ・データ・評価メトリクスを自動記録し、「どの条件で何が出たか」を後から比較できるようにします。Notebook での場当たり的な試行錯誤を、追跡可能な実験に変えるのが狙いです。有望なモデルができたら、データ検証 → 前処理 → 学習 → 評価 → 登録という一連の流れをパイプライン（Kubeflow Pipelines、Vertex AI Pipelines、SageMaker Pipelines など）として定義し、人手を介さず再実行できるようにします。データの前処理では ETL 基盤とも接続し、学習時と推論時で特徴量の計算ロジックがずれる事故（training-serving skew）を防ぐためにフィーチャーストアを置く構成も一般的です。

デプロイと監視 — DevOpsとの共通点と差分

デプロイでは DevOps の手法がそのまま活きます。モデルをコンテナ化して API として配信し、カナリアリリースやブルーグリーンデプロイで段階的に切り替え、新旧モデルを本番トラフィックで比較する A/B テストやシャドーデプロイ（新モデルに本番入力を流すが結果は使わない方式）で安全性を確かめます。

差分が大きいのは監視です。通常のモニタリングがレイテンシやエラー率を見るのに対し、MLOps ではそれに加えて「モデルの精度」と「入力データの分布」を監視する必要があります。厄介なのは、正解ラベルがすぐには手に入らないことです。たとえば与信モデルの予測が正しかったかは数か月後にしか分かりません。そこで代理指標として、入力データの分布が学習時からずれていないか（データドリフト）、予測値の分布が変化していないか、を統計的に検知し、アラートにつなげます。劣化を検知したら新しいデータで再学習し、評価をパスしたモデルを再デプロイする — この再学習ループを、最初はモデル劣化を起点とする手動運用から始め、成熟度に応じてスケジュール実行、さらにトリガー駆動の全自動へと進めていくのが典型的な発展段階です。

実務での落とし穴

よくある失敗は、いきなり高度な自動化基盤を組もうとすることです。Google の提唱する成熟度モデルでも、レベル0（手動でモデルを作って手動デプロイ）から始まり、学習パイプラインの自動化（レベル1）、CI/CD との完全統合（レベル2）へ段階的に進むとされています。モデルの数が少ないうちは、実験管理と「コード・データ・モデルの紐付け記録」だけでも十分に価値があります。また、機械学習システムはモデル本体のコードが全体のごく一部で、周辺のデータ収集・検証・配信インフラが大半を占めます。モデルの精度改善だけに投資してパイプラインの信頼性を疎かにすると、精度以前の問題（データの欠損、特徴量のずれ、静かな劣化）でシステムが壊れていきます。近年は LLM を組み込んだシステム向けに、プロンプトのバージョン管理や出力品質の評価・監視を扱う「LLMOps」という派生領域も生まれており、ファインチューニングや RAG の評価・運用にも同じ「継続的に計測し、劣化に気づき、改善を回す」という MLOps の思想が引き継がれています。