MLflow 3 + Kubeflow PipelinesでMLOps基盤を構築する実践ガイド
この記事でわかること
- MLflow 3とKubeflow Pipelines v2を組み合わせたMLOpsパイプラインの全体アーキテクチャ
- 実験管理（MLflow）→パイプラインオーケストレーション（Kubeflow）→モデルサービング（KServe）の統合構築手順
- KFP v2 SDKを使ったPythonデコレータベースのパイプライン定義方法
- モデルドリフト検出と自動再学習パイプラインの設計パターン
- 本番運用で遭遇する典型的なトラブルと解決策
対象読者
- 想定読者: MLエンジニアで、Kubernetesを使った本番ML基盤の構築を検討している方
-
必要な前提知識:
- Pythonの基礎文法（デコレータ、型ヒントを含む）
- MLflowの基本操作（
mlflow.log_metric、mlflow.log_modelレベル） - Kubernetesの基本概念（Pod、Service、Namespace）
-
kubectlコマンドの基本操作
結論・成果
MLflow 3の実験管理・モデルレジストリとKubeflow Pipelines v2のオーケストレーションを統合することで、モデルの実験から本番デプロイまでのリードタイムを数日から数時間に短縮できます。Kubeflowを使った組織では、パイプラインが安定した後のモデルデプロイ時間が32%削減されたと報告されています（Kubeflow公式ブログ）。また、MLflowの軽量なセットアップにより実験サイクルが40%高速化され（ZenML比較記事）、KServeによるオートスケーリングで推論コストの最適化も実現できます。
この記事では、上図のアーキテクチャを構成する各コンポーネントの役割と、それぞれの統合方法を実装コード付きで解説していきます。
MLflow 3とKubeflow Pipelines v2の役割を整理する
MLOpsパイプラインを構築する際、「MLflowとKubeflowのどちらを使うべきか」という質問をよく見かけます。結論から言うと、両者は競合ではなく補完関係にあります。それぞれの得意領域が異なるため、組み合わせて使うのが2025-2026年の主流パターンです。
MLflow 3の役割：実験管理とモデルレジストリ
MLflow 3は2025年6月にリリースされた統合AIプラットフォームです（Databricks公式ブログ）。従来の実験トラッキングに加え、GenAI/LLMOps向けの機能が大幅に強化されました。
| 機能カテゴリ | MLflow 3の主要機能 | 用途 |
|---|---|---|
| 実験管理 | Experiment Tracking、LoggedModel | 学習パラメータ・メトリクス記録 |
| モデル管理 | Model Registry、モデルバージョニング | モデルのライフサイクル管理 |
| GenAI対応 | Tracing、LLM-as-a-Judge評価 | LLMアプリケーションの可観測性 |
| プロンプト管理 | Prompt Engineering UI、A/Bテスト | プロンプトのバージョン管理 |
MLflow 3で特に注目すべきはLoggedModelというアーキテクチャです。これはモデルをファーストクラスのエンティティとして扱い、GenAIエージェント、ディープラーニングのチェックポイント、モデルバリアントを横断的に管理・比較できるようにするものです。
# mlflow_experiment.py
# MLflow 3での実験記録の基本パターン
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, f1_score
# MLflow Tracking Serverに接続
mlflow.set_tracking_uri("http://mlflow-server.kubeflow.svc.cluster.local:5000")
mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run(run_name="rf-baseline") as run:
# ハイパーパラメータの記録
params = {
"n_estimators": 200,
"max_depth": 10,
"min_samples_split": 5,
"class_weight": "balanced",
}
mlflow.log_params(params)
# モデル学習
model = RandomForestClassifier(**params)
model.fit(X_train, y_train)
# メトリクスの記録
y_pred = model.predict(X_test)
mlflow.log_metric("accuracy", accuracy_score(y_test, y_pred))
mlflow.log_metric("f1_score", f1_score(y_test, y_pred))
# モデルの保存とレジストリへの登録
mlflow.sklearn.log_model(
model,
artifact_path="model",
registered_model_name="fraud-detector",
)
print(f"Run ID: {run.info.run_id}")
なぜMLflow 3を選ぶのか:
-
軽量なセットアップ:
pip install mlflowだけで実験管理を開始でき、学習曲線が低い - フレームワーク非依存: scikit-learn、PyTorch、TensorFlow、HuggingFaceなど20以上のフレームワークをネイティブサポート
- GenAI対応: MLflow 3からLLMのトレーシング・評価機能が統合され、従来MLとLLMの両方を一元管理できる
注意: MLflowの推論サーバー（
mlflow models serve）はFastAPIベースのため、大規模な本番環境には向きません。本番の推論サービングにはKServeを使うのが推奨パターンです。
Kubeflow Pipelines v2の役割：パイプラインオーケストレーション
Kubeflow Pipelines（KFP）v2は、ML ワークフローをKubernetes上で定義・実行するためのフレームワークです（Kubeflow Pipelines公式ドキュメント）。v2ではPythonデコレータベースの直感的なAPI、型安全性の向上、アーティファクト管理の改善が導入されました。
Kubeflow 1.10（2025年3月リリース）でKFP 2.4.1が含まれ、リソースリミットのプレースホルダサポートやParallelForタスクの並列度制限が追加されました。さらにKubeflow 1.11（2025年12月リリース）では、Trainer v2.1.0で統一APIによる分散学習の簡素化が実現しています（Kubeflow 1.11リリースアナウンス）。
MLflow vs Kubeflow ではなく MLflow + Kubeflow:
| 観点 | MLflow | Kubeflow | 統合時の役割 |
|---|---|---|---|
| 実験管理 | ネイティブ対応 | 限定的 | MLflow担当 |
| パイプライン | 非対応 | ネイティブ対応 | Kubeflow担当 |
| モデルレジストリ | ネイティブ対応 | KServeと連携 | MLflow担当 |
| 分散学習 | 非対応 | Training Operator | Kubeflow担当 |
| モデルサービング | 開発用サーバー | KServe連携 | KServe担当 |
| ハイパーパラメータ最適化 | 非対応 | Katib | Kubeflow担当 |
KFP v2 SDKでMLOpsパイプラインを実装する
ここからは実際にKFP v2 SDKを使って、データ前処理→学習→評価→モデル登録のパイプラインを構築していきます。KFP v2の大きな特徴は、Pythonの関数にデコレータを付けるだけでパイプラインコンポーネントを定義できる点です。
パイプラインコンポーネントの定義
KFP v2では@dsl.componentデコレータを使ってコンポーネントを定義します。各コンポーネントは独立したコンテナとしてKubernetes上で実行されます。
# pipeline_components.py
# KFP v2のコンポーネント定義
from kfp import dsl
from kfp.dsl import Input, Output, Dataset, Model, Metrics
@dsl.component(
base_image="python:3.11-slim",
packages_to_install=["pandas==2.2.0", "scikit-learn==1.5.0"],
)
def preprocess_data(
raw_data_path: str,
train_data: Output[Dataset],
test_data: Output[Dataset],
test_size: float = 0.2,
):
"""データの前処理と学習/テスト分割を行う"""
import pandas as pd
from sklearn.model_selection import train_test_split
df = pd.read_csv(raw_data_path)
# 欠損値処理と特徴量エンジニアリング
df = df.dropna(subset=["target"])
df = df.fillna(df.median(numeric_only=True))
train_df, test_df = train_test_split(
df, test_size=test_size, random_state=42, stratify=df["target"]
)
train_df.to_csv(train_data.path, index=False)
test_df.to_csv(test_data.path, index=False)
@dsl.component(
base_image="python:3.11-slim",
packages_to_install=[
"pandas==2.2.0",
"scikit-learn==1.5.0",
"mlflow==3.4.0",
],
)
def train_model(
train_data: Input[Dataset],
model_artifact: Output[Model],
metrics: Output[Metrics],
mlflow_tracking_uri: str,
n_estimators: int = 200,
max_depth: int = 10,
):
"""モデル学習とMLflowへのメトリクス記録を行う"""
import pandas as pd
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, f1_score
import joblib
# MLflow接続設定
mlflow.set_tracking_uri(mlflow_tracking_uri)
mlflow.set_experiment("fraud-detection-pipeline")
train_df = pd.read_csv(train_data.path)
X_train = train_df.drop("target", axis=1)
y_train = train_df["target"]
with mlflow.start_run():
params = {
"n_estimators": n_estimators,
"max_depth": max_depth,
}
mlflow.log_params(params)
model = RandomForestClassifier(**params, random_state=42)
model.fit(X_train, y_train)
# 学習データでの暫定評価
y_pred = model.predict(X_train)
train_acc = accuracy_score(y_train, y_pred)
mlflow.log_metric("train_accuracy", train_acc)
# KFPメトリクスにも記録（UI表示用）
metrics.log_metric("train_accuracy", train_acc)
# モデル保存
joblib.dump(model, model_artifact.path)
mlflow.sklearn.log_model(
model,
artifact_path="model",
registered_model_name="fraud-detector",
)
@dsl.component(
base_image="python:3.11-slim",
packages_to_install=[
"pandas==2.2.0",
"scikit-learn==1.5.0",
"mlflow==3.4.0",
],
)
def evaluate_model(
test_data: Input[Dataset],
model_artifact: Input[Model],
metrics: Output[Metrics],
mlflow_tracking_uri: str,
accuracy_threshold: float = 0.85,
) -> bool:
"""テストデータでモデルを評価し、閾値を満たすか判定する"""
import pandas as pd
import mlflow
from sklearn.metrics import accuracy_score, f1_score, classification_report
import joblib
mlflow.set_tracking_uri(mlflow_tracking_uri)
test_df = pd.read_csv(test_data.path)
X_test = test_df.drop("target", axis=1)
y_test = test_df["target"]
model = joblib.load(model_artifact.path)
y_pred = model.predict(X_test)
acc = accuracy_score(y_test, y_pred)
f1 = f1_score(y_test, y_pred, average="weighted")
metrics.log_metric("test_accuracy", acc)
metrics.log_metric("test_f1_score", f1)
# 閾値判定
passed = acc >= accuracy_threshold
metrics.log_metric("threshold_passed", int(passed))
return passed
なぜKFP v2のデコレータベースAPIを選ぶのか:
-
v1との違い: v1では
ContainerOpやYAMLベースのコンポーネント定義が必要だったが、v2ではPure Pythonで完結する -
型安全性:
Input[Dataset]、Output[Model]といった型アノテーションにより、コンポーネント間のデータフローがコンパイル時に検証される -
再現性:
base_imageとpackages_to_installを明示することで、実行環境が完全に固定される
パイプライン全体の定義と実行
個々のコンポーネントを組み合わせてパイプライン全体を定義します。
# pipeline_definition.py
# パイプライン全体の定義
from kfp import dsl, compiler
@dsl.pipeline(
name="fraud-detection-training",
description="不正検知モデルの学習・評価・デプロイパイプライン",
)
def training_pipeline(
raw_data_path: str = "gs://ml-data-bucket/fraud/raw_data.csv",
mlflow_tracking_uri: str = "http://mlflow-server.kubeflow.svc.cluster.local:5000",
n_estimators: int = 200,
max_depth: int = 10,
accuracy_threshold: float = 0.85,
):
# Step 1: データ前処理
preprocess_task = preprocess_data(raw_data_path=raw_data_path)
# GPUが不要なタスクはリソースを小さく設定
preprocess_task.set_cpu_limit("2")
preprocess_task.set_memory_limit("4Gi")
# Step 2: モデル学習
train_task = train_model(
train_data=preprocess_task.outputs["train_data"],
mlflow_tracking_uri=mlflow_tracking_uri,
n_estimators=n_estimators,
max_depth=max_depth,
)
train_task.set_cpu_limit("4")
train_task.set_memory_limit("8Gi")
# Step 3: モデル評価
evaluate_task = evaluate_model(
test_data=preprocess_task.outputs["test_data"],
model_artifact=train_task.outputs["model_artifact"],
mlflow_tracking_uri=mlflow_tracking_uri,
accuracy_threshold=accuracy_threshold,
)
# パイプラインのコンパイルと実行
if __name__ == "__main__":
# YAMLにコンパイル
compiler.Compiler().compile(
pipeline_func=training_pipeline,
package_path="fraud_detection_pipeline.yaml",
)
print("パイプラインをコンパイルしました: fraud_detection_pipeline.yaml")
コンパイルされたYAMLはkfp.Clientを使ってKubeflow Pipelines APIに送信します。
# submit_pipeline.py
from kfp.client import Client
# Kubeflow Pipelines APIに接続
client = Client(host="http://kubeflow.example.com/pipeline")
# パイプライン実行
run = client.create_run_from_pipeline_package(
pipeline_file="fraud_detection_pipeline.yaml",
arguments={
"raw_data_path": "gs://ml-data-bucket/fraud/raw_data_20260305.csv",
"n_estimators": 300,
"max_depth": 15,
},
run_name="fraud-detection-20260305",
experiment_name="fraud-detection-experiments",
)
print(f"パイプライン実行開始: {run.run_id}")
注意: Kubeflow Pipelines v1のSDK（
kfp<2.0）とv2（kfp>=2.0）はAPI互換性がありません。v1で定義したパイプラインをv2に移行する場合、コンポーネント定義の書き換えが必要です。KFP v2移行ガイドを参照してください。
Katibによるハイパーパラメータ最適化の統合
Kubeflow 1.10でKatibに高レベルAPIが導入され、Training Operatorとの統合が自動化されました。ハイパーパラメータ探索空間を定義するだけで、最適なパラメータの組み合わせを自動探索できます。
# katib_tuning.py
# Katibの高レベルAPIによるハイパーパラメータ最適化
from kubeflow.katib import KatibClient, search
katib_client = KatibClient(namespace="kubeflow")
# ハイパーパラメータ探索の実行
# Katib 0.17+の高レベルAPIを使用
katib_client.tune(
name="fraud-detector-tuning",
objective=train_fn, # 学習用のcallable関数を渡す
objective_type="maximize",
objective_metric_name="accuracy",
parameters={
"n_estimators": search.int(min=100, max=500, step=50),
"max_depth": search.int(min=5, max=30, step=5),
"learning_rate": search.double(min=0.01, max=0.3),
},
algorithm_name="bayesianoptimization",
max_trial_count=20,
resources_per_trial={
"cpu": "2",
"memory": "4Gi",
},
)
よくある間違い: Katibの探索アルゴリズムにRandom Searchを使って「全然良いパラメータが見つからない」というケースがあります。探索空間が広い場合はBayesian Optimization（bayesian-optimization）を使いましょう。Random Searchは探索空間が狭い場合や、まず大まかな傾向を掴みたい場合に有効です。
KServeでモデルを本番サービングする
MLflow Model Registryに登録されたモデルを本番環境でサービングするには、KServeを使います。KServeは2025年9月にCNCFインキュベーティングプロジェクトに採択された、Kubernetes上の標準的なモデルサービングプラットフォームです（CNCF公式ブログ）。
MLflowモデルをKServeにデプロイする
KServeはMLflowフォーマットのモデルをネイティブにサポートしています（KServe MLflowドキュメント）。InferenceServiceのマニフェストを定義するだけでデプロイ可能です。
# kserve-inference-service.yaml
# MLflowモデルをKServeでサービングするマニフェスト
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: fraud-detector
namespace: production
annotations:
# オートスケーリング設定
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "10"
autoscaling.knative.dev/target: "50" # 同時リクエスト数の目標
spec:
predictor:
# MLflowモデルの指定
mlflow:
protocolVersion: v2 # Open Inference Protocol
storageUri: "s3://ml-models/fraud-detector/production/v3"
resources:
requests:
cpu: "1"
memory: "2Gi"
limits:
cpu: "2"
memory: "4Gi"
# デプロイコマンド
kubectl apply -f kserve-inference-service.yaml
# デプロイ状態の確認
kubectl get inferenceservice fraud-detector -n production
なぜKServeを使うのか:
-
MLflow単体の限界:
mlflow models serveはFastAPIベースで、大規模な本番環境でのオートスケーリングや高並列処理に対応できない - KServeの強み: Knativeベースのオートスケーリング、ゼロスケール（リクエストがない時にPodを0にしてコスト削減）、カナリアデプロイ、A/Bテストを標準サポート
- Open Inference Protocol: KServeはOpen Inference Protocol（旧V2 Inference Protocol）をサポートし、フレームワークに依存しない統一的な推論APIを提供する
カナリアデプロイでモデルを段階的にリリースする
新しいモデルバージョンを本番に出す際、いきなり全トラフィックを切り替えるのはリスクがあります。KServeのカナリアデプロイ機能を使って、段階的にトラフィックを移行しましょう。
# kserve-canary-deploy.yaml
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: fraud-detector
namespace: production
spec:
predictor:
# 現行モデル（90%のトラフィック）
mlflow:
protocolVersion: v2
storageUri: "s3://ml-models/fraud-detector/production/v3"
canaryTrafficPercent: 10 # 新モデルに10%のトラフィックを流す
# 新モデル（カナリア）
canaryPredictor:
mlflow:
protocolVersion: v2
storageUri: "s3://ml-models/fraud-detector/production/v4"
トレードオフ: カナリアデプロイは安全性が高い反面、デプロイ完了までに時間がかかります。A/Bテストの統計的有意性を確保するには十分なトラフィック量が必要で、1日あたりのリクエストが少ないサービスでは数日かかることもあります。リクエスト量が少ない場合はシャドーデプロイ（本番トラフィックを新モデルにも複製して推論結果を比較するが、レスポンスは返さない）を検討してください。
ドリフト検出と自動再学習パイプラインを設計する
MLモデルは時間の経過とともに性能が劣化します。入力データの分布が変化するデータドリフトや、入力と出力の関係が変化するコンセプトドリフトが発生するためです。ここでは、ドリフトを検出して自動的にモデルを再学習するパイプラインの設計パターンを紹介します。
Evidentlyによるドリフト検出
Evidentlyは、MLモデルのドリフト検出とモニタリングを行うオープンソースライブラリです。本番推論データの分布を学習時のデータと比較し、統計的にドリフトを検出します。
# drift_detector.py
# Evidentlyによるドリフト検出コンポーネント
from kfp import dsl
@dsl.component(
base_image="python:3.11-slim",
packages_to_install=[
"evidently==0.5.0",
"pandas==2.2.0",
],
)
def detect_drift(
reference_data_path: str,
current_data_path: str,
drift_threshold: float = 0.1,
) -> bool:
"""データドリフトを検出する
PSI（Population Stability Index）を使用して
参照データと現在データの分布差を計測する。
"""
import pandas as pd
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset
import json
reference_df = pd.read_csv(reference_data_path)
current_df = pd.read_csv(current_data_path)
# ドリフトレポート生成
report = Report(metrics=[DataDriftPreset()])
report.run(
reference_data=reference_df,
current_data=current_df,
)
# 結果の解析
result = json.loads(report.json())
drift_share = result["metrics"][0]["result"]["share_of_drifted_columns"]
print(f"ドリフトが検出されたカラムの割合: {drift_share:.2%}")
print(f"閾値: {drift_threshold:.2%}")
is_drifted = drift_share > drift_threshold
if is_drifted:
print("⚠ ドリフトが検出されました。再学習を推奨します。")
else:
print("✓ ドリフトは検出されませんでした。")
return is_drifted
自動再学習パイプラインの構成
ドリフト検出結果に応じて自動再学習を実行するパイプラインを定義します。Kubeflow Pipelinesの条件分岐機能を使って、ドリフトが検出された場合のみ再学習を実行します。
# auto_retrain_pipeline.py
from kfp import dsl
@dsl.pipeline(
name="auto-retrain-pipeline",
description="ドリフト検出→条件付き自動再学習パイプライン",
)
def auto_retrain_pipeline(
reference_data_path: str,
current_data_path: str,
mlflow_tracking_uri: str,
drift_threshold: float = 0.1,
accuracy_threshold: float = 0.85,
):
# Step 1: ドリフト検出
drift_task = detect_drift(
reference_data_path=reference_data_path,
current_data_path=current_data_path,
drift_threshold=drift_threshold,
)
# Step 2: ドリフト検出時のみ再学習を実行
with dsl.If(drift_task.output == True): # noqa: E712
# 新データで前処理
preprocess_task = preprocess_data(
raw_data_path=current_data_path,
)
# 再学習
train_task = train_model(
train_data=preprocess_task.outputs["train_data"],
mlflow_tracking_uri=mlflow_tracking_uri,
)
# 評価
evaluate_model(
test_data=preprocess_task.outputs["test_data"],
model_artifact=train_task.outputs["model_artifact"],
mlflow_tracking_uri=mlflow_tracking_uri,
accuracy_threshold=accuracy_threshold,
)
制約条件: この自動再学習パイプラインは、ドリフトの原因が「データ分布の自然な変化」である場合に有効です。データパイプラインの障害やスキーマ変更によるドリフトの場合、再学習しても性能は改善しません。ドリフト検出→原因分析→再学習の判断というフローが本来は必要であり、完全自動化には慎重になるべきです。
CronWorkflowによるスケジュール実行
定期的にドリフト検出を実行するには、Kubeflow PipelinesのRecurring RunまたはkubectlからArgo WorkflowsのCronWorkflowを設定します。
# schedule_drift_check.py
from kfp.client import Client
client = Client(host="http://kubeflow.example.com/pipeline")
# 日次でドリフト検出パイプラインを実行
client.create_recurring_run(
experiment_id="drift-monitoring",
job_name="daily-drift-check",
pipeline_package_path="auto_retrain_pipeline.yaml",
cron_expression="0 6 * * *", # 毎日06:00 UTC
params={
"reference_data_path": "gs://ml-data-bucket/fraud/reference.csv",
"current_data_path": "gs://ml-data-bucket/fraud/latest.csv",
"mlflow_tracking_uri": "http://mlflow-server.kubeflow.svc.cluster.local:5000",
},
)
よくある問題と解決方法
MLOpsパイプラインの構築・運用で遭遇する典型的なトラブルと解決策をまとめます。
| 問題 | 原因 | 解決方法 |
|---|---|---|
KFPコンポーネントがModuleNotFoundErrorで失敗 |
packages_to_installに依存パッケージの漏れ |
packages_to_installにすべての依存を明示。ネイティブ拡張が必要な場合はカスタムDockerイメージを使用 |
| MLflow Tracking Serverに接続できない | Kubernetes Serviceの名前解決エラー |
mlflow-server.kubeflow.svc.cluster.localのFQDNを確認。NamespaceをまたぐPod間通信はNetworkPolicyを確認 |
| KServeのInferenceServiceがReadyにならない | StorageURIのアクセス権限不足 | ServiceAccountにS3/GCSのIAMロールを付与。MinIO使用時はSecretの設定を確認 |
| Katibのトライアルが全て失敗する | メトリクス名の不一致 | KatibのobjectiveMetricNameと学習コード内の出力メトリクス名を完全一致させる |
| パイプライン実行が途中でOOMKilled | メモリリミットの不足 |
set_memory_limitで適切な値を設定。大規模データは分割処理を検討 |
ハマりポイント: KFP v2で最も多いミスは、コンポーネント関数内で定義されていないモジュールを使おうとすることです。@dsl.componentデコレータが付いた関数は独立したコンテナで実行されるため、関数外でimportしたモジュールは使えません。すべてのimportは関数内部で行う必要があります。
# NG: 関数外のimportはコンポーネント内で使えない
import pandas as pd # ← これはコンポーネント内では参照できない
@dsl.component(base_image="python:3.11-slim", packages_to_install=["pandas"])
def bad_component():
df = pd.read_csv("data.csv") # NameError!
# OK: 関数内でimportする
@dsl.component(base_image="python:3.11-slim", packages_to_install=["pandas"])
def good_component():
import pandas as pd # ← 関数内でimport
df = pd.read_csv("data.csv")
まとめと次のステップ
まとめ:
- MLflow 3は実験管理・モデルレジストリ、Kubeflow Pipelinesはオーケストレーション、KServeは本番サービングと、それぞれの強みを活かした統合構成が2025-2026年のMLOps標準パターン
- KFP v2のPythonデコレータベースAPIにより、パイプライン定義のコード量が大幅に削減され、型安全なデータフローが実現できる
- ドリフト検出→自動再学習のパイプラインはEvidentlyとKubeflow Pipelinesの条件分岐で構築可能だが、完全自動化には原因分析のステップが不可欠
- KServeのカナリアデプロイとオートスケーリングにより、安全かつコスト効率の高いモデルリリースが可能
次にやるべきこと:
- ローカル環境でMLflow 3のTracking Serverを起動し、実験記録のフローを試す（
mlflow server --host 0.0.0.0 --port 5000） - Minikubeまたはkindで小規模なKubeflow Pipelinesを構築し、KFP v2のコンポーネント定義を実際に動かす
- KServeのInferenceServiceを使ったモデルサービングを試し、
curlでOpen Inference Protocolのリクエストを送る - 本番導入時は、Kubeflow公式のインストールガイドとMLflow公式ドキュメントを参照して、自組織のKubernetesクラスタに合わせた構成を検討する
参考
- MLflow 3.0: Build, Evaluate, and Deploy Generative AI with Confidence（Databricks公式ブログ）
- Kubeflow Pipelines公式ドキュメント
- Kubeflow 1.10 Release Announcement
- Kubeflow 1.11 Release Announcement
- KServe MLflowモデルサービング
- KServe becomes a CNCF incubating project
- Kubeflow vs MLflow vs ZenML: Which MLOps Platform Is the Best?（ZenML Blog）
- Kubeflow Pipelines v2 Practical Guide
- Evidently（GitHub）
注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。