Skip to content
Published on

オープンソース ML プラットフォーム & MLOps 2026 完全ガイド - Kubeflow・Metaflow・Flyte・ZenML・MLflow・BentoML・ClearML・DVC・Weights & Biases 徹底比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 2026年5月、MLOps スタックは「標準レイヤ」が定まった

2023年までは MLOps スタックは「会社に合うものを選んでください」の世界だった。2026年5月の今、その曖昧さは大きく晴れた。実験追跡は MLflow と Weights & Biases が二分し、K8s ネイティブのオーケストレーションは Kubeflow Pipelines と Flyte が、Python 優先ワークフローは Metaflow と ZenML が、サービングは BentoML 1.4・KServe・Triton が、データバージョニングは DVC と lakeFS が、それぞれ領域を確立した。

本稿はマーケティングマトリクスではない。「2026年現在、本番では何がどの位置に入っているか」を正直に整理する。MLflow 3.0 の変化、Kubeflow 1.10 ラインナップ、Flyte の Union.ai による商用化、ZenML Cloud、BentoML 1.4 の LLM サービングモードまで、実際の API 形をもとに比較する。

2026 MLOps スタック — 7 レイヤに分解

まず全体像から。2026年標準の MLOps スタックは次の 7 レイヤに分かれる。

  1. 実験追跡(experiment tracking): ラン、パラメータ、メトリクス、アーティファクトの記録
  2. パイプラインオーケストレーション: DAG 実行、分散、キャッシュ
  3. モデルレジストリ: バージョン、ステージ、メタデータ
  4. モデルサービング: オンライン/バッチ/ストリーミング推論
  5. 特徴量ストア(feature store): 学習-推論間の特徴量整合性
  6. データ + 実験バージョニング: データセットとコードの同期
  7. ML 監視(monitoring): ドリフト、性能劣化、データ品質

レイヤあたり 1-2 ツールで足りた時代は終わった。今は レイヤ内でも LLM 特化トラックと従来 ML トラックに分岐する。以下、レイヤごとに見ていく。

実験追跡 — MLflow 3.0 と Weights & Biases が二分

実験追跡レイヤの 90% は 2 ツールが占める。

  • MLflow 3.0: Databricks が開発し Linux Foundation 配下に移った OSS。2026年 Q1 に 3.0 が GA。GenAI トレース、評価(eval)、プロンプトレジストリが一級市民に。
  • Weights & Biases: SaaS 優先だが SDK はオープン。UX/可視化で圧倒的優位。W&B Models、W&B Weave(LLM トレース)、W&B Launch を一括で提供。

代替群も無視できない。

  • Comet ML: ML + LLM 実験 + 本番監視まで統合した SaaS。
  • Neptune.ai: foundation model 学習向けメタデータストアとして再ポジショニング。
  • Aim: Apache 2.0 OSS。セルフホストと速い UI が強み。
  • TensorBoard、PyTorch Lightning Logger: 単体では限界があり上記と併用される。

MLflow 3.0 の典型的な使用例。

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

mlflow.set_tracking_uri("http://mlflow.internal:5000")
mlflow.set_experiment("iris-rf-2026")

X, y = load_iris(return_X_y=True)

with mlflow.start_run() as run:
    mlflow.log_param("n_estimators", 200)
    model = RandomForestClassifier(n_estimators=200)
    model.fit(X, y)
    mlflow.log_metric("train_acc", model.score(X, y))
    mlflow.sklearn.log_model(model, artifact_path="model", registered_model_name="iris-rf")
    print(run.info.run_id)

同じフローを W&B で書くと次のようになる。

import wandb
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

wandb.init(project="iris-rf-2026", config={"n_estimators": 200})
X, y = load_iris(return_X_y=True)
model = RandomForestClassifier(n_estimators=200).fit(X, y)
wandb.log({"train_acc": model.score(X, y)})
wandb.finish()

両ツールとも scikit-learn、PyTorch、XGBoost などの自動インスツルメントを備えており、明示的なログがなくても基本メトリクスは取得できる。違いは 保存モデルとガバナンス。MLflow はセルフホスト前提で BSD 系ライセンスに親和的、W&B は SaaS 優先だが協業 UX が格段に滑らかだ。

パイプラインオーケストレーション — K8s ネイティブ vs Python 優先

ML パイプラインは単なる ETL と異なり、GPU リソースのスケジューリング・キャッシュ・再現性を同時に扱う必要がある。2026年5月時点で 4 ツールが市場を分け合う。

  • Kubeflow Pipelines + Kubeflow 1.10: CNCF インキュベーションプロジェクト。K8s ネイティブ ML プラットフォームの定番。コンポーネントはコンテナ単位。
  • Metaflow: Netflix が作り Outerbounds が商用化。Python デコレータ第一主義。AWS Batch/Step Functions と深く統合。
  • Flyte: Lyft が作り Union.ai が商用化。LF AI & Data 配下。K8s ネイティブ + 型安全。
  • ZenML: フレームワーク非依存、「抽象化レイヤ」ポジショニング。MLflow/W&B/Kubeflow/Airflow をバックエンドに挿す。

周辺として Prefect・Dagster・Airflow も ML ワークフローに使われるが、ML 特化ではなく一般データオーケストレーションなので別記事(iter72/53)で扱う。

DSL 親和性はおおむね ZenML > Metaflow > Flyte > Kubeflow Pipelines の順。Python 1 ファイルで完結できるかが基準だ。

Kubeflow 1.10 — K8s 上のフルスタック ML プラットフォーム

Kubeflow は単一ツールではなく、K8s 上に乗せた フルスタック ML プラットフォーム である。2026年5月時点の 1.10 ラインナップの主要コンポーネントは以下。

  • Kubeflow Pipelines (KFP): DAG パイプライン SDK + UI。
  • Katib: 分散ハイパーパラメータ調整。
  • Training Operator: PyTorchJob、TFJob、MPIJob、PaddleJob の分散学習 CRD。
  • KServe: モデルサービング(旧 KFServing)。別プロジェクトに分離も統合維持。
  • Notebook Controller: JupyterHub スタイルのノートブックインスタンス。
  • Spark Operator、Volcano: バッチスケジューリング。

KFP 2.x の DSL 例。

from kfp import dsl, compiler

@dsl.component(base_image="python:3.12")
def preprocess(input_path: str, output_path: str):
    import pandas as pd
    df = pd.read_csv(input_path)
    df.dropna().to_csv(output_path, index=False)

@dsl.component(base_image="python:3.12", packages_to_install=["scikit-learn"])
def train(data_path: str) -> float:
    import pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    df = pd.read_csv(data_path)
    X, y = df.drop("label", axis=1), df["label"]
    return RandomForestClassifier().fit(X, y).score(X, y)

@dsl.pipeline(name="iris-pipeline")
def pipeline(input_path: str = "/data/iris.csv"):
    pre = preprocess(input_path=input_path, output_path="/tmp/clean.csv")
    train_task = train(data_path=pre.outputs["output_path"])

compiler.Compiler().compile(pipeline, "iris.yaml")

Kubeflow は K8s を運用できるチームには強力だが、4 つの中で導入コストが最も高い。そのため、マネージド(GCP Vertex AI Pipelines、AWS SageMaker MLOps、Azure ML)経由で採用されるケースが多い。

Metaflow — Python デコレータ 1 行で始まるワークフロー

Metaflow は Netflix がデータサイエンティスト視点で設計したワークフローライブラリ。Outerbounds が商用ホスティングを提供するが、コアは Apache 2.0。

主要な抽象は最小限。

  • FlowSpec: ワークフロークラス。
  • @step: ステップデコレータ。
  • self.next(...): 明示的分岐。
  • @batch、@kubernetes、@gpu: ステップ別の実行環境デコレータ。
  • @retry、@timeout、@catch: 信頼性デコレータ。

典型的な Metaflow コードは次の通り。

from metaflow import FlowSpec, step, batch, retry

class IrisFlow(FlowSpec):
    @step
    def start(self):
        from sklearn.datasets import load_iris
        self.X, self.y = load_iris(return_X_y=True)
        self.next(self.train)

    @batch(cpu=4, memory=16000)
    @retry(times=2)
    @step
    def train(self):
        from sklearn.ensemble import RandomForestClassifier
        self.model = RandomForestClassifier(n_estimators=200).fit(self.X, self.y)
        self.acc = self.model.score(self.X, self.y)
        self.next(self.end)

    @step
    def end(self):
        print(f"acc={self.acc:.3f}")

if __name__ == "__main__":
    IrisFlow()

Metaflow の強みは ローカル優先。ノートブックでそのまま実行でき、--with batch を追加するだけで AWS Batch に分散する。自動アーティファクト保存(S3)と自動追跡が標準なので、別途 MLflow が要らないケースも多い。

Flyte — Kubernetes ネイティブの型安全ワークフロー

Flyte は Lyft が作り Union.ai が商用化した K8s ネイティブワークフロー。LF AI & Data Foundation 配下のグラジュエーションプロジェクト。最大の特徴は 型安全とキャッシュ。

  • Python の型アノテーション がそのまま入出力スキーマ。
  • 自動キャッシュ: 同じ入力で自動キャッシュヒット。コスト削減効果が大きい。
  • K8s ネイティブ: Pod、Deployment、GPU/TPU スケジューリングが一級市民。
  • 多言語: Python が第一、Java/Scala SDK もある。

Flyte の例。

from flytekit import task, workflow, Resources

@task(cache=True, cache_version="1.0", requests=Resources(cpu="2", mem="4Gi"))
def preprocess(input_path: str) -> str:
    import pandas as pd
    df = pd.read_csv(input_path).dropna()
    out = "/tmp/clean.csv"
    df.to_csv(out, index=False)
    return out

@task(requests=Resources(cpu="4", mem="16Gi", gpu="1"))
def train(data_path: str) -> float:
    import pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    df = pd.read_csv(data_path)
    X, y = df.drop("label", axis=1), df["label"]
    return RandomForestClassifier().fit(X, y).score(X, y)

@workflow
def iris_wf(input_path: str = "/data/iris.csv") -> float:
    clean = preprocess(input_path=input_path)
    return train(data_path=clean)

Flyte の強みは K8s 親和 + キャッシュが本当に動く こと。同じデータと同じコードで実行すれば自動でキャッシュヒットし、時間とコストを節約できる。

ZenML — フレームワーク非依存の抽象化レイヤ

ZenML は上記ツールと直接競合するのではなく、その上の抽象化レイヤ を自称する。ZenML Pipelines はバックエンドに Kubeflow、Airflow、Tekton、Vertex、SageMaker、AWS Step Functions などを挿せる。

主要な抽象。

  • @step、@pipeline: Python デコレータでステップとパイプラインを定義。
  • Stack: orchestrator + artifact_store + container_registry + experiment_tracker を束ねた環境。
  • Component: 各レイヤの実装。MLflow、W&B、Neptune.ai、Kubeflow、Vertex などを差し替え可。
  • Materializer: ユーザ定義型のシリアライザ。

ZenML コード。

from zenml import pipeline, step
from typing import Tuple
import pandas as pd

@step
def load() -> pd.DataFrame:
    import pandas as pd
    return pd.read_csv("/data/iris.csv")

@step
def split(df: pd.DataFrame) -> Tuple[pd.DataFrame, pd.DataFrame]:
    return df.iloc[:120], df.iloc[120:]

@step
def train(train_df: pd.DataFrame) -> float:
    from sklearn.ensemble import RandomForestClassifier
    X, y = train_df.drop("label", axis=1), train_df["label"]
    return RandomForestClassifier().fit(X, y).score(X, y)

@pipeline
def iris_pipeline():
    df = load()
    tr, _ = split(df)
    train(tr)

iris_pipeline()

ZenML の価値は ベンダーロックインを先送りできる こと。ローカル → SageMaker → Kubeflow と段階的に移行する際、コード変更がほぼない。コストは抽象化税 — バックエンド固有の機能を 100% 活用しようとすると結局そのバックエンド SDK を直接叩くことになる。

モデルレジストリ — MLflow Registry vs BentoML Model Store vs Hugging Face Hub

学習済みモデルはどこかに保存され、バージョン・ステージ(Staging/Production)・メタデータを追跡する必要がある。2026年5月時点で 3 候補がよく登場する。

  • MLflow Model Registry: MLflow とセットで最も標準に近い。models:/name/Production URI パターン。
  • BentoML Model Store: BentoML サービングと結合。bentoml.transformers.save_model() のフロー。
  • Hugging Face Hub: 公開/非公開リポジトリでのモデル共有。transformers/diffusion エコシステムの事実上の標準。

エンタープライズは概ね MLflow Model Registry + 自前 S3 ストレージ を最も多く使い、オープンモデル + LLM 環境は Hugging Face Hub プライベートリポ を、BentoML 運用チームは BentoML Model Store をそのまま使う。

MLflow Registry からの読み込み。

import mlflow.pyfunc

model_uri = "models:/iris-rf/Production"
model = mlflow.pyfunc.load_model(model_uri)
predictions = model.predict([[5.1, 3.5, 1.4, 0.2]])

モデルサービング — BentoML 1.4・KServe・Triton・Ray Serve の役割分担

モデルサービングは一つのツールが全ケースをカバーしない。シナリオごとに分かれる。

  • BentoML 1.4 + Yatai: Python フレンドリーなサービングフレームワーク。モデル + ビジネスロジックを単一の「Bento」にパッケージ化。2026年 Q1 の 1.4 で LLM サービングモード(vLLM、TGI バックエンド統合)が GA。
  • Seldon Core 2: K8s ネイティブサービング。メッシュベースのマルチモデルルーティング。
  • KServe: 旧 KFServing。Kubeflow と一緒に使われるが単独可。サーバーレス/オートスケール + 標準推論プロトコル。
  • TorchServe: Meta + AWS 連携。PyTorch モデルサービングの標準。
  • TensorFlow Serving: TF SavedModel サービング。C++ ベースで安定。
  • NVIDIA Triton Inference Server: GPU 最適サービング。TensorRT、ONNX、PyTorch、TF、vLLM バックエンド統合。
  • Ray Serve: Ray クラスタ上の Python サービング。Anyscale マネージド。

BentoML 1.4 の LLM サービング例。

import bentoml
from transformers import AutoTokenizer

@bentoml.service(resources={"gpu": 1, "memory": "16Gi"})
class LlamaService:
    def __init__(self) -> None:
        from vllm import LLM
        self.llm = LLM(model="meta-llama/Llama-3.3-70B-Instruct")
        self.tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.3-70B-Instruct")

    @bentoml.api
    def generate(self, prompt: str, max_tokens: int = 256) -> str:
        outputs = self.llm.generate([prompt], sampling_params={"max_tokens": max_tokens})
        return outputs[0].outputs[0].text

LLM でない古典的モデルは TF Serving、TorchServe、Triton の方が速くて安定する。LLM 推論は vLLM/SGLang/TGI/TensorRT-LLM(iter69 で扱った推論エンジン)を BentoML や Triton バックエンドに挿すのが標準パターン。

特徴量ストア — Feast 0.40・Hopsworks・Featureform・Tecton

特徴量ストアは学習時と推論時に同じ特徴量が出るよう保証するレイヤ。

  • Feast 0.40: Apache 2.0 OSS。K8s またはローカルデプロイ。オンラインストアとして Redis、DynamoDB、Bigtable に対応。
  • Hopsworks: オープンコア。セルフホストと SaaS の両方を提供。特徴量ストア + ノートブック + サービング統合。
  • Featureform: 仮想化レイヤ。既存データウェアハウスを特徴量ストアのように抽象化。
  • Tecton: 商用 SaaS。Feast 出身チームによる同系譜。エンタープライズでよく採用される。

Feast 0.40 の定義例。

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

user = Entity(name="user", join_keys=["user_id"])

user_stats_source = FileSource(
    path="s3://feast-data/user_stats.parquet",
    timestamp_field="event_ts",
)

user_stats_view = FeatureView(
    name="user_stats",
    entities=[user],
    ttl=timedelta(days=7),
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="purchase_value_7d", dtype=Float32),
    ],
    source=user_stats_source,
)

特徴量ストアの導入はつい後回しになりがちだ。しかし「学習-推論一貫性」が崩れて事故になった瞬間から必須になる。

データ + 実験バージョニング — DVC・lakeFS・Pachyderm・Quilt

コードは Git が責任を持つが、データはそうではない。データバージョニングツールは次の 4 つが市場を分け合う。

  • DVC (Data Version Control): Git の上のデータ/モデルバージョニング。.dvc メタファイルで大きなファイルを追跡、実データは S3/GCS/Azure に保存。
  • lakeFS: データレイク向けの Git モデル。ブランチ、マージ、コミットがペタバイト規模 S3 でも動く。
  • Pachyderm: データバージョニング + データリネージ + 自動パイプライントリガ。
  • Quilt Data: データパッケージカタログ。

DVC のフロー。

git init
dvc init
dvc remote add -d storage s3://my-bucket/dvc

dvc add data/raw/train.csv
git add data/raw/train.csv.dvc .gitignore
git commit -m "track training data"

dvc push   # データは S3 へ
git push   # メタデータは Git へ

DVC のもう一つの強みは DVC Pipelines だ。dvc.yaml でステージ定義 + 依存性を明示すれば、変更されたステージのみ再実行する。少ないインフラで再現可能な ML ワークフローが構築できる。

ML 監視 — Evidently・Arize・WhyLabs・Fiddler

モデルは本番投入後、データが変化すれば性能が落ちる(データ/コンセプトドリフト)。監視はそれを捉えるレイヤ。

  • Evidently AI: Apache 2.0 OSS。レポートとダッシュボードを Python で生成。K8s 上にセルフホスト可。
  • Arize AI: 商用 SaaS。ML + LLM 観測性を統合。Phoenix が OSS 分派。
  • WhyLabs: データ品質 + ドリフト + 異常検知。無料プランあり。
  • Fiddler AI: 説明可能性(XAI)を強調。エンタープライズコンプライアンストラック。

Evidently の使用例。

import pandas as pd
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset

ref = pd.read_csv("reference.csv")
cur = pd.read_csv("current.csv")

report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=ref, current_data=cur)
report.save_html("drift.html")

監視は「最初は作りやすいが運用ではノイズが多くてオフにされる」ケースが多い。アラート閾値のチューニングとダッシュボードのカスタマイズの方がより重要になる。

ノートブック & IDE — Jupyter・Marimo・Hex・Deepnote・Quarto

ML ワークフローの出発点は依然としてノートブックだ。

  • Jupyter / JupyterLab 4 / JupyterHub: 事実上の標準。マルチユーザは JupyterHub。iter27 のノートブック深掘りで別途扱う。
  • Marimo: リアクティブノートブック。セル実行順序が依存グラフで決まる。再現性が強い。
  • Hex・Deepnote: マネージドの協業ノートブック。
  • Quarto: ノートブック + Markdown をレポート/書籍/サイトに変換。

Marimo の差別化点は明確だ。セル間依存性がコード解析で抽出されるため、順序依存バグが減る。データサイエンティストが README なしでも引き渡せるノートブックと考えればいい。

ベクトル DB 統合 — Pinecone・Weaviate・Milvus・Qdrant

RAG と埋め込みワークフローを扱うにはベクトル DB が必須。iter62 でベクトル DB 自体を詳しく扱うが、MLOps 視点での要点は モデルサービングとの統合 だ。BentoML、Ray Serve、KServe いずれもベクトル DB クライアントと一緒にパッケージ化するパターンを標準化している。

特に LangChain/LlamaIndex などの LLM フレームワークと組み合わせると、ベクトル DB はもはや「別途インフラ」ではなく「ML サービスの一級コンポーネント」となる。

E2E「MLflow スタイル」のマネージドプラットフォーム

セルフホストが負担なら、マネージドを使う。

  • Databricks Lakehouse Platform: MLflow 原作者。ノートブック + Spark + MLflow + Unity Catalog 統合。
  • Vertex AI: Google。AutoML、Pipelines、Endpoints、Feature Store 統合。
  • SageMaker: AWS。Studio、Pipelines、Model Registry、Endpoints 統合。
  • Azure ML: Microsoft。Workspace + Designer + Endpoints + Responsible AI 統合。

各マネージドプラットフォームは独自 SDK を強要する一方、MLflow/Kubeflow Pipelines/PyTorch/TensorFlow と互換の標準入口も提供する。マネージドの利点は インフラ負荷 0、欠点は ベンダーロックイン。

LLM 特化 MLOps (LLMOps) — LangSmith・Langfuse・Arize Phoenix・Helicone

2024-2025年にかけて「LLMOps」というサブカテゴリが形成された。古典 MLOps と重なるが、次の点が異なる。

  • トレース単位: メトリクスではなく プロンプト/レスポンストレース が一次データ。
  • 評価(eval): 正解が曖昧なため、LLM-as-judge、ルールベース、ユーザーフィードバックを組み合わせる。
  • プロンプトレジストリ: モデルバージョンとは別にプロンプトバージョンを管理。
  • コスト追跡: トークン単位コストが ML コストの中心。

主要ツール。

  • LangSmith: LangChain 圏の標準。SaaS + セルフホスト。
  • Langfuse: OSS セルフホストトラック。トレース/評価/プロンプト管理。
  • Arize Phoenix: Arize の OSS 分派。LLM トレースと評価。
  • Helicone: OpenAI/Anthropic API ゲートウェイ + トレース。

iter77(LLM 観測性)と iter83(ファインチューニング)でさらに深く扱う。

韓国 MLOps — NAVER Cloud・Kakao Enterprise・NCSOFT・Hyundai

韓国 MLOps エコシステムは次の軸で構成される。

  • NAVER Cloud ML プラットフォーム: HyperCLOVA X ベースのファインチューニング + 自社 MLOps ツール。
  • Kakao Enterprise: Kakao i Cloud の ML トラック。Kubeflow と自社ツールの混合。
  • NCSOFT AI センター: ゲーム AI + キャラクター AI 中心の自社パイプライン。
  • Hyundai Motor Group AI Lab: 自動運転データ + モデル自動化に Flyte/Kubeflow 混合事例。
  • 韓国 ML エンジニアコミュニティ: MLOps Korea、Pseudo Lab、Modulabs トラックなど定期ミートアップ。

大企業は自社プラットフォームの上に MLflow/Kubeflow を載せるパターン、スタートアップは SageMaker や Vertex AI をそのまま使うパターンが主流だ。

日本 MLOps — PFN・メルカリ・サイボウズ・リクルート

日本 MLOps エコシステムは次が際立つ。

  • PFN(Preferred Networks): Optuna(ハイパーパラメータ最適化)の原作者。自社ワークフロー Allgo と併用。
  • サイボウズ(Cybozu): kintone データに基づく ML パイプライン。Argo Workflows + 自社ツール。
  • リクルート AI Lab: 広告/リクルーティングドメインの ML パイプライン。Vertex AI + MLflow。
  • メルカリ ML プラットフォーム: 自社 ML プラットフォーム「Merlin」運用。KServe + Argo + Feast。
  • NTT Communications - PFN パートナーシップ: 通信データに基づく大規模学習。

日本では Argo Workflows(古典)と Kubeflow + KServe の採用率が高い。Qiita と Zenn には 2026年に入り Flyte/Metaflow の日本語チュートリアルが急速に増えた。

CNCF AI & Data サブグループ — 標準化の流れ

2024年末、CNCF は AI & Data サブグループを正式に発足した。2026年5月時点で次のプロジェクトが配下に整列している。

  • Kubeflow Pipelines、Kubeflow Training Operator: ML パイプライン + 分散学習。
  • Flyte: ワークフロー(インキュベーション)。
  • KServe: サービング(インキュベーション)。
  • Volcano: バッチスケジューラ。
  • Spark Operator: K8s 上の Spark。
  • Argo Workflows: 古典だが ML ワークフローによく登場。

CNCF が標準化のハブとなり、K8s 上の ML のインターフェースが次第に統一されつつある。マネージドプラットフォームも KServe v1/v2 推論プロトコルを採用する流れだ。

組み合わせパターン — 実際の本番はどう編むか

実際の企業は一つのツールで完結させない。よく出る組み合わせパターン。

  • スタートアップ最小構成: MLflow(追跡 + レジストリ)+ Metaflow(ワークフロー)+ BentoML(サービング)+ Evidently(監視)。
  • K8s エンタープライズ: Kubeflow(パイプライン)+ MLflow(追跡)+ KServe(サービング)+ Feast(特徴量)+ DVC(データ)。
  • AWS マネージド優先: SageMaker Pipelines + SageMaker Model Registry + SageMaker Endpoints + W&B(SaaS 追跡)+ Evidently(監視)。
  • GCP マネージド優先: Vertex AI Pipelines + Vertex Endpoints + W&B + Featureform。
  • LLM 優先スタートアップ: Hugging Face Hub(モデル)+ Langfuse(トレース)+ BentoML 1.4(サービング)+ ZenML(ワークフロー抽象)。

核心は 「何が一級市民で何が補助か」。K8s が一級なら Kubeflow + KServe、Python ワークフローが一級なら Metaflow + BentoML、LLM が一級なら HF Hub + Langfuse + vLLM。

導入ロードマップ — 0 から本番まで

初めて MLOps を導入する際は次の順序が最も安全。

  1. 実験追跡 からまず入れる。MLflow か W&B。1 週間以内で可能。
  2. モデルレジストリ を同じ追跡ツール内で開始。別ツールはまだ不要。
  3. モデルサービング は最小限 BentoML か FastAPI + ONNX/TorchScript で開始。マネージド(SageMaker Endpoints、Vertex Endpoints)も可。
  4. パイプラインオーケストレーション はデータサイエンティストが 1-2 人なら cron + Makefile で十分。3 人以上、または日次学習が必要になったら Metaflow/ZenML。
  5. データバージョニング はデータセットが GB 以上で変更が頻繁になれば DVC か lakeFS。
  6. 特徴量ストア は学習-推論一貫性事故が一度起きたら導入。最初から入れない。
  7. 監視 はモデルが 1 個以上本番にあり、ユーザーデータが流入し始めたら。

8 つすべて入れて始めると 90% は失敗する。1 レイヤずつ 導入するのが定説だ。

おわりに — 2026年5月、「MLOps は今もモザイク」

本稿の結論は「標準が定まった」だったが、同時に「今もモザイク」でもある。1 社が 7 レイヤすべてを 1 ベンダーで束ねることはない。MLflow + Metaflow + BentoML + DVC + Evidently のような OSS 組み合わせが依然として最も多い。

最大の変化は LLMOps と古典 MLOps の分岐 だ。同じ会社の中でも 2 トラックが別個のツールスタックを持つ。LLMOps 側は LangSmith/Langfuse/Phoenix が、古典は MLflow/Kubeflow が固めていく流れだ。

ツール選定に時間をかけすぎないこと。どの組み合わせでも 「コード・データ・モデル・結果の 4 重バージョン管理」 さえできれば 90% は解決する。残りは優先順位の問題だ。

References

Discuss on Twitter • View on GitHub