MLOps

「モデルを作る」と「モデルを運用する」は別の仕事

Jupyter Notebookで精度の高いモデルを作れたとしても、それを本番環境で安定して動かし続けるのは全く別のスキルセットが必要になる。学習データの更新、モデルの再学習、バージョン管理、A/Bテスト、精度劣化の検知——これらを手作業で回すと、チームの規模に関わらず破綻する。

MLOpsはDevOpsの思想を機械学習に適用したものだが、ソフトウェアのデプロイとは異なる固有の課題がある。コードだけでなくデータとモデルの重みの3つを同時にバージョン管理する必要があること、モデルの性能がデータの分布変化（ドリフト）で時間とともに劣化すること、実験の再現性を担保する必要があることなどだ。

MLOpsパイプラインの構成要素

データパイプライン: 学習データの収集・前処理・バリデーションを自動化する。データの品質がモデルの品質を直接決める以上、ここが最も重要なレイヤーだ。

実験管理: MLflow、Weights & Biases、Cometなどで、ハイパーパラメータ・学習曲線・評価指標を記録し、実験の再現性を確保する。

モデルレジストリ: 学習済みモデルをバージョン付きで保管し、ステージング→本番への昇格フローを管理する。

サービング: モデルをAPIとして公開する。vLLM、TensorRT-LLM、Triton Inference Serverなどが推論エンジンとして使われる。

モニタリング: 推論のレイテンシ、エラー率に加え、データドリフト（入力データの分布変化）やモデルドリフト（精度の経時劣化）を監視する。閾値を超えたら自動で再学習をトリガーする仕組みも一般的だ。

LLM時代のMLOps

LLMの台頭で「LLMOps」という派生概念も生まれている。プロンプトのバージョン管理、RAGパイプラインの評価、ガードレールの設定、推論コストの最適化など、従来のMLOpsにはなかった運用課題が加わった。ツールチェーンも LangSmith、Braintrust、Arize AI など LLM 特化のものが増えている。