MLOpsプラットフォーム 2026 完全版 - MLflow · Kubeflow · W&B · Vertex AI · SageMaker · Databricks · BentoML · Ray · Modal · Hugging Face 徹底ガイド

はじめに — 2026年5月、MLOpsとLLMOpsは同じ表面を共有する

2024年までは「MLOps」と「LLMOps」という言葉は別物として扱われていた。2026年5月現在、両者はほぼ同じ表面を共有している。実験トラッキングはプロンプトrunを記録し、モデルレジストリはLoRAアダプタをバージョン管理し、サービングプラットフォームはvLLMとTGIを公式バックエンドとして搭載する。監視ツールはデータドリフトだけでなく、ハルシネーション率、毒性、faithfulnessを同じダッシュボードに並べる。

本記事は流行のplatform-of-the-monthマトリクスではない。2026年に本番のMLチームが実際にどんな組み合わせを動かしているのかを30個のツールでまとめる。OSS優先のスタック、クラウドマネージドのスタック、「GPUだけ借りる」サーバーレススタック、韓国・日本の大手の社内プラットフォームまで同じ物差しで見る。

2026 MLOpsスタックを8レイヤーに分解する

まず全体像から。2026年の標準MLOpsスタックは次の8レイヤーに分解できる。

1. 実験トラッキング (experiment tracking): run、パラメータ、メトリクス、アーティファクト
2. モデルレジストリ (model registry): バージョン、ステージ、モデルカード
3. パイプラインオーケストレーション (orchestration): DAG、キャッシュ、再試行
4. 学習インフラ (training infra): GPUスケジューリング、分散学習、HPO
5. モデルサービング (serving): オンライン / バッチ / エッジ
6. データバージョニング (data versioning): データセット、特徴量、インデックス
7. 監視 (monitoring): データドリフト、概念ドリフト、予測ドリフト
8. LLM評価 (LLM eval): faithfulness、毒性、jailbreak検出

1〜2個のツールで1レイヤーを片付けられた時代は終わった。同じレイヤーの中でもクラシックMLトラックとLLMトラックに分岐する。

実験トラッキング — MLflow 3、Weights & Biases、Comet、Neptune.ai

実験トラッキングの90%は2つのツールで占められている。MLflow 3.0とWeights & Biasesだ。MLflowはDatabricksが作りLinux Foundationに寄贈したBSDライセンスのOSSで、3.0からはGenAIトレーシング、評価、プロンプトレジストリが一級市民になった。W&BはSaaS優先だがSDKはオープンで、Models / Weave / Launch / Sweepsを1パッケージで売る。

代替群も無視できない。Comet MLはML + LLM実験 + 本番監視を統合したSaaS、Neptune.aiは基盤モデル学習向けのメタデータストアにポジショニングを強化した。OSSセルフホスト陣営ではAimとClearMLが固い。

代表的なMLflow 3コードは次のようになる。

import mlflow
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).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

run = 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)})
artifact = wandb.Artifact("iris-rf", type="model")
artifact.add_file("model.pkl")
run.log_artifact(artifact)
wandb.finish()

ストレージとガバナンスで分かれる。MLflowはセルフホストが標準でライセンスも友好的だがUIは平凡。W&Bは協業UXが滑らかでLLM評価も同梱だがコストが累積しやすい。

ClearML、DagsHub、MLEM — OSS陣営の統合ツール

ClearMLは実験トラッキング + オーケストレーション + データ管理 + サービングを1パッケージにまとめたOSSだ。agent-workerパターンでキューにジョブを投げるとGPUノードが拾って実行する。1ツールで完結させたい中小チームがよく選ぶ。

DagsHubはDVC + MLflow + Git LFSを1つのSaaS UIに束ねる。データバージョニングと実験トラッキングを同じ画面で見られる点が売り。MLEMはIterative.aiが作るモデルパッケージツールで、scikit-learn / PyTorchモデルをFastAPIサービスとして一行で書き出せる。

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

Kubeflowは単一ツールではなくK8s上のフルスタックだ。2026年5月の1.10ラインの主要コンポーネントは次の通り。

• Kubeflow Pipelines (KFP): DAGパイプラインSDK + UI
• Katib: 分散ハイパーパラメータチューニング
• KServe: モデルサービング (InferenceService CRD)
• Training Operator: PyTorch / TensorFlow / MPI分散学習オペレータ
• Spark Operator, Notebook Controller, Central Dashboard

KFPパイプラインはPythonで書きYAMLにコンパイルする。

from kfp import dsl, compiler

@dsl.component(base_image="python:3.11")
def preprocess(input_path: str, output_path: dsl.OutputPath(str)) -> None:
    import pandas as pd
    df = pd.read_csv(input_path)
    df.to_parquet(output_path)

@dsl.component(base_image="ghcr.io/myorg/trainer:1.4")
def train(data_path: dsl.InputPath(str), model_path: dsl.OutputPath(str)) -> None:
    import joblib, pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    df = pd.read_parquet(data_path)
    model = RandomForestClassifier().fit(df.drop("y", axis=1), df["y"])
    joblib.dump(model, model_path)

@dsl.pipeline(name="iris-pipeline")
def iris_pipeline(input_path: str) -> None:
    p = preprocess(input_path=input_path)
    train(data_path=p.output)

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

隠れたコストはK8s自体だ。EKS / GKE / AKSのマネージドKubeflowを使わないなら、専任プラットフォームチームが事実上必須になる。

Metaflow、Flyte、ZenML、Prefect ML、Airflow ML

K8sネイティブが重すぎるなら、Python優先ツールを選ぶ。MetaflowはNetflixが作りOuterboundsが商用化した。AWS Batch + Step Functionsと深く統合され、デコレータ1行でGPUステップを宣言できる。FlyteはLyft発でUnion.aiが商用化。K8sネイティブ + 型安全が強み。

ZenMLは「フレームワーク非依存の抽象化レイヤー」として位置づけられる。MLflow / W&B / Kubeflow / Airflow / SageMakerをバックエンドとして差し込み、同じコードを移し替える。Prefect 3 + Prefect MLはデータパイプラインとMLパイプラインを1つのUIで見る。Airflow 3はML向けデコレータ(@task.virtualenv、@task.kubernetes)を追加したが依然としてML優先のツールではない。

Vertex AI — Google CloudのフルマネージドML

GCPのVertex AIは学習 + チューニング + サービング + パイプライン + 特徴量ストア + 監視を1つのコンソールに束ねる。Custom Training、AutoML、Workbench(ノートブック)、Pipelines(KFPベース)、Endpoints、Model Garden、Vertex AI Agent Builder、Vertex AI Searchなどに分岐する。

Vertex AI Custom Jobはこう投入する。

from google.cloud import aiplatform

aiplatform.init(project="my-project", location="us-central1")

job = aiplatform.CustomContainerTrainingJob(
    display_name="iris-rf-2026",
    container_uri="us-central1-docker.pkg.dev/my-project/ml/iris-trainer:1.4",
    model_serving_container_image_uri="us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-3:latest",
)
model = job.run(
    args=["--n_estimators=200"],
    replica_count=1,
    machine_type="n1-standard-8",
    accelerator_type="NVIDIA_TESLA_T4",
    accelerator_count=1,
)

Vertex AIの強みはBigQuery + Dataplex + Lookerとの自然な統合、Gemini学習インフラのノウハウ、そしてModel Gardenによる70以上の基盤モデル提供だ。弱みはGCPロックインと、セルフホストよりも顕著に高いインスタンス単価である。

SageMaker — AWSのML山脈

AWS SageMakerは単一サービスではなく山脈だ。2026年5月時点で次のように分かれる。

• SageMaker Studio: 統合IDE
• SageMaker Training / Processing Jobs: バッチ学習
• SageMaker Pipelines: パイプラインオーケストレーション
• SageMaker Endpoints (real-time, async, serverless): サービング
• SageMaker Feature Store: 特徴量ストア
• SageMaker Model Monitor, Clarify: ドリフト + バイアス
• SageMaker JumpStart: 事前学習モデルカタログ
• SageMaker HyperPod: 基盤モデル学習専用クラスタ

エンドポイントを展開すれば次のコードブロックだけだ。

import boto3
from sagemaker import Session
from sagemaker.sklearn import SKLearnModel

session = Session()
role = "arn:aws:iam::123456789012:role/SageMakerRole"

model = SKLearnModel(
    model_data="s3://my-bucket/iris-rf/model.tar.gz",
    role=role,
    entry_point="inference.py",
    framework_version="1.4-1",
    sagemaker_session=session,
)
predictor = model.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.large",
    endpoint_name="iris-rf-endpoint",
)
print(predictor.predict([[5.1, 3.5, 1.4, 0.2]]))

SageMakerの強みはAWS統合(S3、IAM、VPC、CloudWatch、EventBridge)と深い自動化だ。弱みはインスタンス単価がEC2比で30〜50%高いことと、JumpStartモデルのライセンス追跡を別途行う必要がある点だ。

Azure ML Studio + Microsoft Fabric

Azure Machine Learning StudioはSageMaker / Vertex AIと同じポジションだ。Workspaces、Compute Clusters、Pipelines、Endpoints (Online + Batch)、Model Catalog、Prompt Flow、Responsible AI Dashboardを束ねる。2026年に入ってMicrosoft Fabric + Azure MLの統合が強化され、OneLakeのデータをそのまま学習入力にできる。Azure OpenAI Serviceは別サービスだがPrompt Flowから呼び出せる。

エンタープライズMicrosoftスタック(Entra ID、Purview、Defender for Cloud)との深い統合が強み。弱みはUIの一貫性に難があり、自己署名証明書やprivate linkの設定の学習曲線が急なことだ。

Databricks ML + Mosaic AI — レイクハウス上のML

DatabricksはUnity Catalog + MLflow + Delta Lakeを1パッケージにまとめ「レイクハウスML」を標榜する。2024年のMosaic AI買収後、Mosaic AI Pretraining、Mosaic AI Vector Search、Mosaic AI Model Servingが追加された。

• Model Serving: GPU + CPU統合エンドポイント、Provisioned Throughput
• AI Gateway: LLM呼び出しルーティング + コスト上限
• Mosaic AI Agent Framework: エージェント構築 + 評価
• Genie Spaces: NLQ → SQL自動化

データを既にDatabricksに置いているチームには、ロックインコストに対する費用対効果が最も良い部類に入る。

Hugging Face Hub + Inference Endpoints + AutoTrain

Hugging Faceは単なるモデルハブを超え、フルスタックMLOpsツールに進化した。2026年5月時点の中核ラインは次の通り。

• Hub: 130万件以上のモデル、データセット、Space
• Inference Endpoints: マネージドGPU/CPUサービング (AWS / Azure / GCPリージョン選択)
• Inference Providers: Together / Fireworks / Replicateなど外部プロバイダ統合ルーティング
• AutoTrain: コードなしのファインチューニングUI
• Spaces: Gradio / Streamlitアプリホスティング
• TGI (Text Generation Inference): LLMサービングバックエンド

Inference Endpointは次のようにデプロイする。

from huggingface_hub import create_inference_endpoint

endpoint = create_inference_endpoint(
    name="llama-3-8b-prod",
    repository="meta-llama/Meta-Llama-3-8B-Instruct",
    framework="pytorch",
    accelerator="gpu",
    instance_size="x1",
    instance_type="nvidia-a10g",
    region="us-east-1",
    vendor="aws",
    type="protected",
)
endpoint.wait()
print(endpoint.url)

OSSモデルとマネージドサービングを同じUIで一度に扱える点が強み。弱みはエンタープライズSLAがハイパースケーラーより短く、専用インスタンスのコストがRunPod / Modal比で約30%高いことだ。

Determined AI、Anyscale + Ray Train — GPU分散学習

GPUクラスタを自前で回す必要があるチームは分散学習専用ツールを使う。Determined AI(2021年HPE買収)は分散学習 + HPO + 実験トラッキングを統合したOSSだ。ノードにエージェントを入れるとGPUプールが自動でスケジューリングされる。

AnyscaleはRayメンテナが作るマネージドSaaSだ。Ray Train、Ray Tune、Ray Serve、Ray Dataを同じクラスタで動かす。Ray TrainでPyTorch DDPを立ち上げると次の1関数だ。

import ray
from ray.train.torch import TorchTrainer
from ray.train import ScalingConfig

def train_fn(config):
    import torch
    import torch.nn as nn
    from torch.utils.data import DataLoader, TensorDataset
    model = nn.Linear(10, 1)
    opt = torch.optim.SGD(model.parameters(), lr=config["lr"])
    ds = TensorDataset(torch.randn(1024, 10), torch.randn(1024, 1))
    dl = DataLoader(ds, batch_size=32)
    for epoch in range(config["epochs"]):
        for x, y in dl:
            loss = ((model(x) - y) ** 2).mean()
            opt.zero_grad(); loss.backward(); opt.step()

trainer = TorchTrainer(
    train_fn,
    train_loop_config={"lr": 1e-3, "epochs": 10},
    scaling_config=ScalingConfig(num_workers=4, use_gpu=True),
)
result = trainer.fit()

RayはLLM学習だけでなくエージェントオーケストレーション(複数LLM呼び出しの並列化)にも使われ、LLMOpsスタックの中核インフラとして定着した。

BentoML — Python優先のモデルサービング

BentoMLはPythonモデルをコンテナにパッケージングしてマネージドBentoCloudへ展開するOSSフレームワークだ。1.4ではLLMサービングモード(bentoml serve --reload --use-vllm)とマルチモデルルーティングが正式サポートされた。

サービス定義は1ファイルで済む。

import bentoml
from bentoml import api
from sklearn.ensemble import RandomForestClassifier
import joblib

@bentoml.service(resources={"cpu": "2", "memory": "1Gi"}, traffic={"timeout": 30})
class IrisRF:
    def __init__(self) -> None:
        self.model: RandomForestClassifier = joblib.load("model.pkl")

    @api
    def predict(self, x: list[list[float]]) -> list[int]:
        return self.model.predict(x).tolist()

BentoMLはK8sに直接デプロイするか、マネージドBentoCloudへ展開する。KServe / Seldon Core 2 / Triton と比較すると、Python親和性が最も高い。

Modal、RunPod、Replicate、Fireworks AI、Together AI — サーバーレスGPU

GPUだけ借りてインフラは消えてほしいチームはサーバーレスGPUプラットフォームを使う。

• Modal: Pythonデコレータ優先のサーバーレス。コールドスタート1秒程度。
• RunPod: GPUポッド + サーバーレスエンドポイント、A100/H100/H200の単価がハイパースケーラー比で50%程度
• Replicate: API1行でOSSモデルを呼べる、cog形式でパッケージング
• Fireworks AI: OSS LLM最適化サービング、Llama/Mixtral/Qwenで1秒未満のTTFT
• Together AI: OSS LLMホスティング + カスタムモデルサービング + ファインチューニング
• Lamini、Predibase: エンタープライズ向けファインチューニング + サービング (LoRA serving)

ModalでGPU関数を起動するコードは次の通り。

import modal

app = modal.App("llama-inference")
image = (
    modal.Image.debian_slim()
    .pip_install("torch==2.4.0", "transformers==4.44.0", "vllm==0.6.0")
)

@app.function(image=image, gpu="A100-40GB", timeout=300)
def generate(prompt: str) -> str:
    from vllm import LLM, SamplingParams
    llm = LLM(model="meta-llama/Meta-Llama-3-8B-Instruct")
    out = llm.generate([prompt], SamplingParams(max_tokens=200, temperature=0.7))
    return out[0].outputs[0].text

@app.local_entrypoint()
def main():
    print(generate.remote("MLOps in 2026 means"))

LLMサービングバックエンド — vLLM、SGLang、TGI、TensorRT-LLM

LLMサービングは独立したカテゴリだ。2026年5月時点で4つのエンジンが市場を分け合う。

• vLLM: PagedAttentionの発明者。最も速い出発点。0.6.xでマルチLoRA同時サービングが安定化。
• SGLang: vLLMの次世代。RadixAttentionでprefix cacheを最適化。
• TGI (Hugging Face): HFモデル親和。Inference Endpointsのバックエンド。
• TensorRT-LLM: NVIDIA製。H100 / H200で最低遅延。

BentoML 1.4とKServe 0.13は上記4つをすべてバックエンドとして差し込める。vLLMのOpenAI互換サーバーは1コマンドで起動する。

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3-8B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192 \
  --enable-prefix-caching \
  --enable-lora \
  --max-lora-rank 32 \
  --port 8000

モデル監視 — Arize、WhyLabs、Fiddler、TruEra、Galileo、Evidently

学習-サービングスキュー、データドリフト、概念ドリフト、予測ドリフト、そしてLLMのハルシネーションまでを一緒に見る。

• Arize AI: ML + LLM監視を統合。Phoenix(OSS) + マネージドSaaS。
• WhyLabs: WhyLogs(OSS)ベース。セルフホスト親和。
• Fiddler: ML監視 + 説明可能性 + RAG eval。
• TruEra: TruLens(LLM eval OSS)のメンテナ。2024年Snowflake買収。
• Galileo: LLM専用の評価 + ガードレール。
• Evidently AI: OSS親和、レポート形式で出力。

同じレイヤーでも強みが異なる。クラシックMLはArize / WhyLabs / Fiddler、LLM専用はGalileo / Arize Phoenix / TruLens、OSSセルフホストはEvidently / WhyLogs / Phoenixを選ぶ。

LLM評価革命 — DeepEval、RAGAS、Promptfoo、langwatch

LLM評価は独立したスタックとして分岐した。

• DeepEval: pytest親和のLLM評価OSS。faithfulness、answer relevancy、bias、toxicity。
• RAGAS: RAGパイプライン評価のデファクト。context recall、faithfulness、context relevancy。
• Promptfoo: prompt A/Bテスト、CLI親和。
• langwatch: prompt observability + 評価 + コスト追跡。
• Argilla: human-in-the-loopラベリング + 評価。2024年HF買収。

LLMモデルカードとデータセットカード(datasheet)については、Hugging Face Hubが事実上のフォーマットになった。

データバージョニング — DVC、lakeFS、Pachyderm

• DVC: Iterative.ai作のGit親和データバージョニング。S3/GCS/Azureバックエンド。
• lakeFS: Git風APIでオブジェクトストレージのbranch / merge。
• Pachyderm: パイプライン + データlineage。2023年HPE買収。
• DagsHub: DVC + MLflow + Git LFS統合SaaS。

データバージョニングは学習再現性 + GDPR削除要求の追跡 + データセットlineageを同時に扱う。

ハイパーパラメータ最適化 — Optuna、Ray Tune、W&B Sweeps、Katib

OptunaはOSS HPOの事実上の標準だ。TPE、CMA-ES、NSGA-IIといったアルゴリズムを引数1つで切り替える。Ray TuneはRayクラスタ上で分散HPOを回す。W&B SweepsはW&B内でgrid / random / bayesを起動する。KatibはK8s上で同じことを行う。

study:
  storage: postgresql+psycopg2://user:pw@db/optuna
  direction: maximize
  sampler:
    type: tpe
    n_startup_trials: 20
  pruner:
    type: hyperband
parameters:
  - name: learning_rate
    type: float
    low: 1e-5
    high: 1e-2
    log: true
  - name: hidden_size
    type: categorical
    choices: [128, 256, 512]

ML向けCI/CD — Continuous Training (CT)

伝統的なCI/CDに一段階追加される。**CT (Continuous Training)**は新しいデータが入ったら自動的に再学習 → 評価 → 昇格するパイプラインだ。

主要パターンは次の通り。

• シャドウデプロイ: 新モデルを実トラフィックに公開せずログだけ収集
• カナリアデプロイ: 5%、25%、50%、100%とトラフィック比を段階的に増やす
• MLのblue-green: 2つのモデルバージョンを同時に温め、ルーターで切り替え
• A/Bテスト: ユーザーセグメント別にモデルを分岐
• 自動ロールバック: 監視SLO違反時に自動的に戻す

KServeとBentoCloudの両方で、canary / shadowをInferenceServiceの一級概念として支援する。

エッジ/組込推論 — TF Lite、Core ML、ONNX Runtime、OpenVINO、TVM

• TensorFlow Lite: Android / マイコン
• Core ML: Apple Silicon、iOS / macOS / visionOS
• ONNX Runtime: クロスプラットフォームランタイム (CPU、CUDA、DirectML、CoreML、OpenVINO EP)
• OpenVINO: Intel親和。CPU / iGPU / NPU加速。
• Apache TVM: コンパイラ優先。MLC LLMと組み合わせてモバイルLLM推論。
• MediaPipe: モバイルマルチメディアMLパイプライン。

エッジに近づくほど量子化 (INT8 / INT4 / GPTQ / AWQ)、剪定、蒸留が必須になる。

GPUコスト比較 — 2026年5月時点の時間単価

最もよく聞かれる質問はGPU単価だ。同じH100 80GBがプラットフォームごとに2〜3倍違う。

実際の価格はリージョン、約定、spotの有無で大きく変動するので、常に公式の価格ページを確認するのが必須だ。それでも傾向は明確だ。OSS GPUブローカー(CoreWeave / Lambda / RunPod)がハイパースケーラーより40〜60%安い。

韓国 — Naver HyperCLOVA、Coupang ML、Kakao Brain

韓国大手3社の社内MLOpsを公開資料ベースで見るとこうなる。

• Naver Cloud / HyperCLOVA X: 大規模学習は自社GPUクラスタ + Megatron-LM / Slurmベース。サービングは社内モデルサービングプラットフォーム + Triton + vLLMの組み合わせ。
• Coupang MLプラットフォーム: 社内 Bumblebee プラットフォームとして知られ、KFP / MLflowベースのパイプライン + 自社特徴量ストアを運用。
• Kakao Brain: 自社SoftCoクラスタでKarloなどを学習、社内Brain Cloudでサービング。PyTorch + DeepSpeed + Slurmライン。
• LG AI Research (EXAONEシリーズ): 自社クラスタ + NVIDIA DGX + 自社学習フレームワーク。

大学や研究機関もNIPA / NCDSのK-Cloud / KSC-Vのような公的GPU資源を使い始めている。

日本 — Preferred Networks PFCC、Mercari、CyberAgent、ABEJA

日本側は次の4社が社内MLOpsの標準を作った。

• Preferred Networks: 自社スパコンMN-3 / MN-Core、ChainerMNの後継としてPyTorch + 自社分散ライブラリPFCC。
• Mercari: 社内MLプラットフォーム「Mercari ML Platform」。KFP + Vertex AI + 自社特徴量ストア。
• CyberAgent AI Lab: CIU (CyberAgentのMLプラットフォーム) + 自社LLM (CyberAgentLM) の学習インフラ。
• ABEJA Platform: エンタープライズMLOps SaaS。annotation + 学習 + サービング統合。
• DeNA、Yahoo Japan、Rakuten: それぞれKFP + 自社特徴量ストア + 自社モデルレジストリ。

共通点はVertex AIへの依存度が非常に高いことだ。MercariとCyberAgentは公開ブログでGCP親和スタックの詳細を共有している。

スタック推奨 — 4つのシナリオ

• 小規模スタートアップ (3〜10名): Modal + W&B + Hugging Face Hub + Evidently。K8sなしでGPUだけ借りる。
• 中規模MLチーム (10〜50名): SageMakerかVertex AI + MLflow + DVC + Arize。マネージドのフルスタック。
• GPUクラスタを持つチーム (50名以上): Kubeflow 1.10 + MLflow + Ray + KServe + Argilla + Galileo。セルフホストのフルスタック。
• LLM優先チーム: vLLM + BentoML + Argilla + DeepEval + RAGAS + langwatch + Modal。評価とコスト追跡が核心。

正解はない。ただしレイヤーを意識的に分けておくと、レイヤー内のツールを差し替えるときの移行コストが小さい点だけは確かだ。

締めくくり — MLOpsは結局「再現性と回収可能性」

2026年5月のMLOps風景を一行で要約すると「再現性 (reproducibility) と回収可能性 (recoverability) が一級市民になった」だ。どのデータでどのコードで学習したモデルか、そのモデルがどのトラフィックに露出しているか、問題が起きたとき何分以内に戻せるか、が本当の評価軸だ。

ツールは差し替えられる。しかしレイヤー境界と責任分離は、一度引き間違えると6〜12か月を失う。本記事がその境界を引き直す助けになれば幸いだ。

References

• MLflow — Apache 2.0のMLライフサイクルプラットフォーム
• Kubeflow — K8s上のフルスタックMLプラットフォーム
• Weights & Biases — 実験トラッキング + LLM ops
• Neptune.ai — 基盤モデルのメタデータストア
• Comet ML — 実験トラッキング + 監視の統合SaaS
• Google Vertex AI — GCPのMLプラットフォーム
• AWS SageMaker — AWSのMLプラットフォーム
• Azure Machine Learning — MicrosoftのMLプラットフォーム
• Databricks Machine Learning — レイクハウス上のML + Mosaic AI
• Hugging Face — Hub + Inference Endpoints + AutoTrain
• BentoML — Pythonモデルサービング
• Modal — サーバーレスGPU
• Anyscale — マネージドRay
• Ray — 分散コンピューティング + ML
• ZenML — MLOps抽象化レイヤー
• Flyte — K8sネイティブワークフロー
• DVC — Git親和データバージョニング
• lakeFS — オブジェクトストレージのbranch / merge
• Arize AI — ML + LLM監視
• WhyLabs — OSS WhyLogsベースの監視
• Galileo — LLM評価 + ガードレール
• RAGAS — RAG評価の標準
• vLLM — LLMサービングエンジン