機械学習をPoCから本番に持っていく段になって、急に複雑度が跳ね上がります。ノートブックで動いたモデルを、どうデプロイし、どう再現性を担保し、どう監視するか。実験追跡・モデルレジストリ・特徴量管理・サービング・パイプライン・モニタリングと、必要な道具が一気に増えます。これがMLOpsと呼ばれる領域です。
選択肢は「OSSを組み合わせる」「クラウドのマネージドMLOpsに乗る」「Kubernetesベースで自前構築」の3パターンに大別できます。MLflow・Feast・Vertex AI・SageMaker・Azure ML・Kubeflowを軸に、選定の判断軸を整理します。
MLOpsで必要な6つの機能
| 機能 | 役割 |
|---|---|
| 実験追跡 | パラメータ・メトリクス・成果物の記録 |
| モデルレジストリ | 学習済みモデルのバージョン管理 |
| 特徴量ストア（Feature Store） | 学習・推論で同じ特徴量を再利用 |
| パイプライン | 前処理→学習→評価→デプロイの自動化 |
| サービング | モデルを推論エンドポイントとして提供 |
| モニタリング | 性能劣化・データドリフトの検知 |
これら全部を最初から揃える必要はありません。多くのチームは「実験追跡」と「モデルレジストリ」から始めます。MLflowはこの2つを軽量に提供する事実上の標準です。
3つの選択肢の位置づけ
| OSS組み合わせ | クラウドマネージド | Kubeflow | |
|---|---|---|---|
| 代表 | MLflow + Feast + Airflow | Vertex AI / SageMaker / Azure ML | Kubeflow on Kubernetes |
| 運用負担 | 中（個別運用） | 低（マネージド） | 高（K8s運用） |
| 柔軟性 | 高 | 中（ベンダー枠内） | 非常に高 |
| ベンダーロックイン | 無 | あり | 無 |
| 費用 | OSS無料＋インフラ | 規模に応じた課金 | OSS無料＋運用工数 |
多くの組織は「OSS組み合わせ」か「クラウドマネージド」で始めます。Kubeflowは大規模で自前運用力がある組織向けの選択肢です。
OSS組み合わせ：MLflow + Feast + Airflow
もっとも採用が広いのが、OSSの「軽量な組み合わせ」です。実験追跡とモデルレジストリにMLflow、特徴量管理にFeast、オーケストレーションにAirflowやDagsterといった、用途ごとのOSSを組み合わせます。詳細はそれぞれMLflow とは、Feast とはで扱います。オーケストレーションはオーケストレーター選び方を参照してください。
強みは、柔軟性とベンダーロックインの無さ。弱みは、複数OSSを個別に運用する負担と、統合の作り込みが必要な点です。
クラウドマネージドMLOps
AWS・Google Cloud・Azureがそれぞれ、フルマネージドのMLOpsプラットフォームを提供します。実験追跡からデプロイ・モニタリングまで一通り揃っており、運用負担が最小化されます。詳細はクラウドMLOpsプラットフォーム比較で扱います。
| プラットフォーム | 特徴 |
|---|---|
| Vertex AI（Google Cloud） | BigQueryとの統合が深い。AutoMLが強力 |
| SageMaker（AWS） | 最も機能が広く、エンタープライズ実績豊富 |
| Azure ML（Microsoft） | Azure資産との統合、Responsible AI機能 |
強みは、運用負担の劇的な軽さと、クラウドサービス（DWH・ストレージ・IAM）との統合の滑らかさ。弱みは、ベンダーロックイン、機能カスタマイズの限界、費用が読みにくい点です。
Kubeflow：Kubernetes上での本格構築
KubeflowはKubernetes上で動くMLOps基盤のOSSスイートです。Pipelines・Notebooks・Training・Servingといったコンポーネント群で、エンド・ツー・エンドのMLライフサイクルをカバーします。
強みは、徹底的なカスタマイズと、マルチクラウド対応。弱みは、K8s運用の専門性が必須で、構築・保守のコストが大きいことです。大規模・自前運用・コンプライアンス要件が厳しい組織で選ばれます。
選定の判断軸
| 判断軸 | 選び方 |
|---|---|
| 素早く始めたい・運用人員が薄い | クラウドマネージド（既存クラウドに合わせる） |
| 柔軟性・ロックイン回避 | MLflow + Feast + Airflow |
| マルチクラウド・大規模・自前運用 | Kubeflow |
| BigQuery中心 | Vertex AI |
| AWS資産が中心 | SageMaker |
| Azure資産が中心 | Azure ML |
データ基盤との関係
MLOpsはデータ基盤と地続きです。MLの「特徴量」は、データ基盤のSilver/Goldテーブルから生成されることが多く、品質ツールやセマンティックレイヤーと統合が進んでいます。
| データ基盤の層 | MLOpsとの関係 |
|---|---|
| 取り込み（EL） | 学習データのソース（EL vs ETLとデータ取り込みツール選定） |
| 変換（dbt） | Silver/Goldテーブルから特徴量を作る（dbt実装ガイド） |
| 品質 | 学習データの品質保証（データ品質ツール選定） |
| セマンティックレイヤー | メトリクス定義が学習指標と整合（セマンティックレイヤー） |
| カタログ | 特徴量・モデルもデータ資産として管理（データガバナンスとカタログ） |
MLOpsを単独で考えるのではなく、「データ基盤の上にどう乗せるか」で考えると、選定が現実的になるでしょう。
まとめ
- MLOpsは実験追跡・モデルレジストリ・特徴量・パイプライン・サービング・モニタリングの6機能。
- 選択肢は「OSS組み合わせ」「クラウドマネージド」「Kubeflow自前」の3パターン。
- 素早く始めるなら既存クラウドのマネージド、柔軟性なら MLflow + Feast、大規模自前なら Kubeflow。
- データ基盤の上に乗る前提で、データ品質・特徴量・カタログとの統合を含めて設計する。
- 最初から全機能を揃えない。実験追跡＋モデルレジストリから段階的に。
各ツールの詳細はMLflow とは・Feast とは・クラウドMLOpsプラットフォーム比較にまとめています。MLOps導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. PoCではどこまで揃えればよいですか？
A. 実験追跡（MLflow）とモデルレジストリだけで十分です。これだけあれば、誰がどのパラメータでどのデータで学習したかが追え、モデルのバージョンが管理できます。本番運用に進む段階で、サービングとモニタリングを足し、特徴量ストアは「同じ特徴量を学習と推論で使う」場面が出てから検討します。
Q. 特徴量ストアは本当に必要ですか？
A. モデルが1〜2個なら不要です。複数のモデルで同じ特徴量を使う、リアルタイム推論で過去の集計値が必要、といった段階で価値が出ます。dbtで作ったテーブルをそのまま特徴量として使う運用で足りる組織もあります。「特徴量がコピペ運用になっている」のが、特徴量ストア導入の検討シグナルです。
Q. クラウドマネージドのロックインは、どこまで深刻ですか？
A. 学習コード自体は移植しやすいですが、パイプライン定義・サービング設定・モニタリング設定はベンダーごとに違うので、移行コストは発生します。「将来クラウドを変える可能性」が無視できないなら、OSS（MLflow等）に重要な部分を寄せる構成にしておくと、移行コストを抑えられます。
Q. KubeflowとVertex AI Pipelinesは何が違いますか？
A. Vertex AI PipelinesはKubeflow Pipelinesベースで、マネージド版に近い位置づけです。Vertex AI Pipelinesで書いたPipeline定義は、ある程度Kubeflowでも動かせます。「将来オンプレやマルチクラウドに移すかも」という組織は、Vertex AIで始めてもKubeflow互換のPipelinesで書いておく、という設計判断もあります。