LabHub

ブログ

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

2026-05-16 · 22 分で読めます · #japanese#mlops#kubeflow#metaflow#flyte#zenml#mlflow#bentoml#clearml#dvc#weights-and-biases#open-source

한국어English日本語

はじめに — 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 の典型的な使用例。

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 ツールが市場を分け合う。

周辺として 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 ラインナップの主要コンポーネントは以下。

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。

主要な抽象は最小限。

典型的な 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 配下のグラジュエーションプロジェクト。最大の特徴は 型安全とキャッシュ。

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 などを挿せる。

主要な抽象。

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 + 自前 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 の 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 の定義例。

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 のフロー。

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 の使用例。

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 ワークフローの出発点は依然としてノートブックだ。

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

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

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

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

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

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

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

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

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

主要ツール。

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

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

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

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

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

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

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

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

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

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

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

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

核心は 「何が一級市民で何が補助か」。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

コメント

まだコメントはありません。

ログインするとコメントできます