MLOpsツールの選び方：MLflow・Feast・クラウドのMLOpsを「いま何に困っているか」で決める

需要予測のモデルをPoCで作ったデータサイエンティストは1人です。精度は良好。営業企画は「来月から発注に使いたい」と言っています。ところが本番の話になると、手が止まります。先月いちばん精度が出たモデルがどのデータで学習したものか、本人にも分からないのです。ノートブックは forecast_final_v3_fix.ipynb まで増えました。情シスからはクラウドのMLOps製品の見積もりが届き、経営企画からは「来期の予算に載せたいので、何にいくら要るのか1枚にまとめて」と頼まれました。

ここで製品の機能表を比べ始めると、選定は長引きます。MLOpsの道具は、一度に揃えるものではありません。困りごとが出た順に、1つずつ足します。最初に要るのは、たいてい「どの条件で学習したモデルか」を後から追える記録と、本番に出しているモデルの版の管理だけです。

早見表：いまの困りごとから、最初に入れるものを決める

モデルが1〜2個で、推論が夜間の一括処理だけなら、1行目と2行目で足ります。3行目から下は、困ってからで間に合います。

MLOpsの6つの仕事は、要るようになる合図で足す

全部を最初に揃えると、使わない部品の運用だけが残ります。足すのは、右の列に当てはまる合図が出た行だけです。パイプラインの実行には、データ基盤ですでに使っているオーケストレーターを使い回せます。選び方はオーケストレーターの選定とDagsterの解説に書いています。

実験の記録とモデルの版管理は、MLflow から始める

MLflow は Databricks が作ったOSSで、2020年6月に Linux Foundation に移管されました。学習のコードに数行足すと、条件と結果が残ります。

import mlflow
from sklearn.ensemble import RandomForestRegressor

mlflow.set_experiment("demand_forecast")

with mlflow.start_run():
    params = {"n_estimators": 300, "max_depth": 8}
    mlflow.log_params(params)
    model = RandomForestRegressor(**params).fit(X_train, y_train)
    mlflow.log_metric("mape", mape(y_test, model.predict(X_test)))
    mlflow.sklearn.log_model(sk_model=model, name="model",
                             registered_model_name="demand_forecast")

本番に出す版は、別名（エイリアス）で指します。ここは古い記事と変わった点です。Staging・Production の「ステージ」は、MLflow 2.9.0 で非推奨になりました。いまは版に champion のような別名を付け、推論側はその別名で読み込みます。

from mlflow import MlflowClient

MlflowClient().set_registered_model_alias("demand_forecast", "champion", 3)

model = mlflow.pyfunc.load_model("models:/demand_forecast@champion")

戻すときは、別名を前の版に付け替えます。推論側のコードは一切変わりません。

チームで使うなら、記録を1か所に集めます。置き場は3通りです。

どこに置いても、MLflow のAPIで書いた学習コードはそのまま動きます。後でクラウドを変えるかもしれない会社には、これが保険になります。

特徴量ストアは、同じ計算を2か所に書き始めたら検討する

「直近30日の購入額」を、学習用にはSQLで、推論用にはアプリのコードで計算している。よく見かける形です。こうなると、いずれ2つの定義がずれます。精度が落ちた原因を何日も追った末に、学習と推論で数字が違っていたと分かる。よくある結末です。

特徴量ストアは、特徴量の定義を1か所にまとめ、学習用の過去データと推論用の最新値を同じ定義から返す仕組みです。Feast は Gojek と Google が共同で開発したOSSで、いまは LF AI & Data Foundation のプロジェクトです。

from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64

customer = Entity(name="customer", join_keys=["customer_id"])

source = FileSource(path="data/customer_stats.parquet",
                    timestamp_field="event_timestamp")

customer_stats = FeatureView(
    name="customer_stats",
    entities=[customer],
    ttl=timedelta(days=30),
    schema=[Field(name="purchase_30d", dtype=Float32),
            Field(name="orders_30d", dtype=Int64)],
    source=source,
)

学習データは get_historical_features で作ります。各行の時点で手に入っていた値だけを結合するので、未来の値が学習に混ざりません。推論時は get_online_features を使います。読むのは、オンライン用の保存先にある最新値です。保存先には Redis・DynamoDB・Bigtable・PostgreSQL などが公式ドキュメントに並んでいます。

Feast の公式ドキュメントは、自身を汎用のデータ加工の仕組みでもストリーム処理の仕組みでもないと明記しています。特徴量の元になる集計は、dbt などで作ったテーブルを使います。dbt の層の分け方はdbtの3層構造、データの品質の守り方はデータ品質ツールの選定を参照してください。リアルタイムの特徴量が要る場合の流れ方はバッチかストリーミングかの選び方に書いています。

推論が夜間の一括処理だけなら、dbt で作った特徴量のテーブルを読めば足ります。特徴量ストアが効くのは、1件ずつ即座に予測を返し、しかも同じ特徴量を複数のモデルで使う場面です。

クラウドのMLOpsは、データがあるクラウドに合わせる

3社とも、実験の記録から配信・監視まで一通り揃えています。機能の数で比べても差は出にくい。決め手は、データがどこにあるかです。データと別のクラウドに学習の環境を置くと、データを移す手間と費用が毎回かかります。

Google Cloud の改称には注意が要ります。Vertex AI Pipelines は Agent Platform Pipelines に、Vertex AI Feature Store は Agent Platform Feature Store に名前が変わりました。社内の稟議では、どちらの名前で書くかを先に決めます。旧名と新名が混ざると、承認する側が別の製品だと受け取りかねません。

データ基盤そのものが Databricks にあるなら、Databricks の中で MLflow を使う道もあります。詳しくはDatabricksの解説、クラウドDWHの比べ方はクラウドDWH入門を参照してください。

Kubeflow は、Kubernetes を運用できるチームの選択肢

Kubeflow は Kubernetes 上で動くOSSの集まりです。単体の製品ではありません。パイプライン、ノートブック、学習ジョブ、ハイパーパラメータ探索の Katib、モデルの版を管理するレジストリなどを、必要な分だけ組み合わせて使います。配信の KServe は、公式サイトでは周辺のプロジェクトとして扱われています。

自由度は高い。その分、Kubernetes 自体の運用が前提になります。社内に Kubernetes を運用するチームがいない会社が、MLOpsのためだけに Kubeflow を入れるのは勧めません。Google Cloud のパイプラインが Kubeflow Pipelines の定義で動くので、将来の移行に備えたいなら、パイプラインをその形で書いておくだけでも足ります。

手作業のままにした費用を、人件費で見る

予算の説明には、道具の費用と並べて、いまの手作業の費用を出します。比べる相手が無いと、道具の費用は高く見えるだけです。年収900万円のデータサイエンティストで試算します。会社の総コストは給与の約3倍なので年2,700万円、年1,900時間で割ると時給はおよそ14,200円です。

合計で年340万円ほど。数字は説明のための例なので、自社の年収と頻度に置き換えてください。この額と、MLflow の置き場やクラウドの費用、それを運用する人の時間を比べます。どちらが安いかより、手作業が1人に集中しているかどうかが判断の分かれ目になることもあります。その人が休めば、再学習は止まります。

運用で詰まるのは、決めごとが無いところ

よくある質問（FAQ）

PoCの段階では、どこまで揃えればよいですか?

MLflow の実験記録とモデルレジストリの2つで足ります。誰が、どのデータとパラメータで学習したかが残り、本番に出す版を別名で指せるようになります。配信と監視は本番に出す段階で足し、特徴量ストアは学習と推論で同じ計算を2か所に書き始めてから検討します。

MLflow のステージ（Staging・Production）は、まだ使えますか?

MLflow 2.9.0 で非推奨になり、将来のメジャーリリースで削除される予定です。新しく作るなら、版に champion のような別名を付け、推論側は models:/モデル名@champion の形で読み込みます。既存の仕組みがステージで動いているなら、次にモデルを差し替える機会に別名へ移すと、手戻りが少なく済みます。

特徴量ストアは本当に必要ですか?

推論が夜間の一括処理だけで、モデルが1〜2個なら要らないことがほとんどです。dbt で作った特徴量のテーブルを読めば足ります。1件ずつ即座に予測を返す必要があり、同じ特徴量を複数のモデルで使うようになったら、Feast やクラウドの特徴量ストアを検討します。

Vertex AI の名前が見当たりません。

Google Cloud は2026年4月22日に、Vertex AI を Gemini Enterprise Agent Platform へ移しました。Vertex AI Pipelines は Agent Platform Pipelines、Vertex AI Feature Store は Agent Platform Feature Store になっています。古い記事や社内資料にある Vertex AI の機能は、多くが名前を変えて引き継がれているので、新しい名前で公式ドキュメントを確かめてください。

クラウドのMLOpsを選ぶと、後で移れなくなりますか?

学習のコードとモデルそのものは移しやすい一方、パイプラインの定義・配信の設定・監視の設定はクラウドごとに書き方が違い、移るときに書き直しになります。実験の記録とモデルの管理を MLflow のAPIで書いておけば、SageMaker AI と Azure Machine Learning はどちらも MLflow を受け付けるので、書き直す範囲を小さくできます。

出典

• MLflow Documentation: Model Registry Workflows（2026-10-17 参照：Model Stages が MLflow 2.9.0 で非推奨になったこと、別名の付け方（set_registered_model_alias）と models:/name@alias での読み込み）
• MLflow Documentation: Quickstart（2026-10-17 参照：log_params・log_metric・log_model(sk_model=…, name=…) の書き方）
• The Linux Foundation: The MLflow Project Joins Linux Foundation（2026-10-17 参照：MLflow が Databricks 作で、2020年6月に Linux Foundation に移管されたこと）
• AWS Documentation: Managed MLflow on Amazon SageMaker AI（2026-10-17 参照：マネージドMLflow、成果物は利用者のS3に置くこと、SageMaker Model Registry への自動登録）
• AWS Documentation: What is Amazon SageMaker AI?（2026-10-17 参照：2024年12月に Amazon SageMaker から Amazon SageMaker AI に改称されたこと）
• Microsoft Learn: MLflow and Azure Machine Learning（2026-10-17 参照：ワークスペースが MLflow 互換で、記録先・モデル管理に使えること）
• Microsoft Learn: What is managed feature store?（2026-10-17 参照：オフラインが ADLS Gen2、オンラインが Redis への書き出しに対応すること）
• Google Cloud: Gemini Enterprise Agent Platform release notes（2026-10-17 参照：2026年4月22日に Vertex AI が Gemini Enterprise Agent Platform の一部になったこと、Pipelines・Feature Store 等の新名称）
• Google Cloud: Introduction to Agent Platform Pipelines（2026-10-17 参照：Kubeflow Pipelines SDK または TFX で定義したパイプラインをサーバーレスで実行すること）
• Feast Documentation: Introduction（2026-10-17 参照：オフライン/オンラインの役割、時点を揃えた学習データ、Feast が汎用のデータ加工やストリーム処理の仕組みではないこと）
• Feast Documentation: Quickstart（2026-10-17 参照：Entity(join_keys)・FileSource・FeatureView の定義と get_historical_features / get_online_features）
• Feast Documentation: Online stores（2026-10-17 参照：オンライン保存先に Redis・DynamoDB・Bigtable・PostgreSQL などがあること）
• Feast Blog: The Future of Feast（2026-10-17 参照：2018年に Gojek と Google Cloud の共同で始まり、2020年に Linux Foundation for AI（現 LF AI & Data）に入ったこと）
• Kubeflow Documentation: Introduction（2026-10-17 参照：構成するサブプロジェクト（Pipelines・Notebooks・Trainer・Katib・Hub の Model Registry 等）と、KServe が周辺プロジェクト扱いであること）

PoCのモデルを本番に出す段で「どの版がどのデータで学習したか分からない」と止まっているなら、最初の記録と版管理の置き場を決めるところから一緒に整理できます。初回相談（30分・無料）で一緒に整理できます。