Kubeflowとは？Kubernetes上の機械学習基盤の全体像とPipelinesの使い方

Kubeflowとは、機械学習のワークフローをKubernetes上で動かすためのオープンソースのプラットフォームです。公式ドキュメントでは単体のツールではなく、Kubernetes上でAI・機械学習のワークロードを動かすサブプロジェクト群として整理されており、Pipelines・Katib・KServeなど役割の異なるコンポーネントが集まって一つの基盤を成しています。

この記事では全体の構成を押さえたうえで、中核であるKubeflow Pipelinesの仕組みとKFP SDK v2でのパイプライン作成、ローカルでの試し方、導入前に決める3点、AirflowやMLflowとの使い分けまでを順に扱います。2026年に入ってCNCFでの成熟度も版番号体系も変わったため、そこも一次情報で確かめます。

まとめ：Kubeflowの要点と採用可否の分かれ目

• 正体：Kubernetes上で機械学習を運用するためのプラットフォーム。2023年7月にCNCFのIncubatingへ受理され、2026年7月24日にGraduated（卒業）へ昇格した。
• 構成：Pipelines・Katib（AutoML）・KServe（推論提供）・Trainer（分散学習）・Notebooks・Central Dashboardなどの集合。必要なものだけ個別に導入できる。
• 中核：Kubeflow Pipelines（KFP）。現行はKFP SDK v2（kfp 2系）で、Pythonのデコレータで定義し、コンパイルするとIR形式のYAMLが出力される。
• 版番号：1.11（2025年12月）のあと、Community Distributionとして年月ベースの26.03.1（2026年4月）へ移行。1.10を最新とする解説は現行と噛み合わない。
• 試し方：本番はKubernetesクラスタが前提だが、kfp localならクラスタ無しで単体のパイプラインをローカル実行できる。
• 使い分け：汎用ワークフローならAirflow、実験トラッキング中心ならMLflow、自前運用を避けたいならVertex AI Pipelines。Kubernetesの運用体制が無いなら無理に選ばない。

Kubeflowとは何か：Kubernetesネイティブな機械学習プラットフォーム

Kubeflowは、機械学習のワークロード（データ処理・学習・ハイパーパラメータ探索・モデル提供）をKubernetes上で動かすことに特化したフレームワークです。Kubernetesがコンテナのスケジューリングやスケーリングを担い、Kubeflowがその上に機械学習ならではの作法（パイプライン、分散学習、推論サーバ）を載せます。基盤にKubernetes（K8s）の仕組みを使うため、学習ジョブや推論を必要なだけ水平スケールできます。

Kubeflowが解決する再現性とスケールの課題を具体で押さえる

機械学習の開発では、前処理・学習・評価・デプロイといった処理がスクリプトに散らばり、再現性やスケールで壁に当たります。同じ学習を半年後に再実行したいのに、当時のライブラリ版と前処理の条件が誰にも分からない、という詰まり方が典型でしょう。Kubeflowはこれらをコンテナ化した処理単位としてKubernetes上に載せ、実験の記録・再実行・スケールを標準化します。MLOps（機械学習の運用）の実践基盤の一つという位置づけです。

CNCF卒業とリリース体系の変更で変わったKubeflowの現在地

KubeflowはGoogle社内のTensorFlow運用の仕組みから生まれ、2023年7月25日にCNCFのIncubatingプロジェクトとして受理されました。その後、CNCFのプロジェクトページが示すとおり2026年7月24日にGraduated（卒業）へ移っています。「まだIncubatingなので様子見」と書かれた2025年以前の解説は、この時点で前提が変わりました。

版番号の付き方も変わっています。1.11は2025年12月にリリースされ、公式のリリースページによればKFP v2.15.0、Katib v0.19.0、KServe v0.15.2などを束ねた構成です。続くCommunity Distribution 26.03.1からは「年.月.パッチ」のカレンダー版番号へ移り、KFP 2.16.1・KServe 0.18.0を同梱してKubernetes 1.36に対応しています。リポジトリ名もkubeflow/manifestsからkubeflow/community-distributionへ改称されたため、古い手順書のURLはそのままでは追えません。

Kubeflowを構成する主要コンポーネントと必要な分だけ導入する考え方

Kubeflowを「一つのツール」と捉えると混乱します。役割の異なるコンポーネントが集まってプラットフォームを成しており、全部を導入する必要はありません。公式のインストール案内も、サブプロジェクトの単体デプロイ、Community Distribution一式、ベンダー提供のパッケージ版という3経路を並べる形です。

KServeは旧KFServing、Kubeflow Trainerは旧Training Operator、Kubeflow Hubは旧Model Registryです。過去の資料では旧名で書かれていることが多いので、同じものを指すと理解しておくと混乱しません。一式を入れる手順は、community-distributionリポジトリのREADMEにある一行コマンドが基準になります。

git clone -b v26.03.1 https://github.com/kubeflow/community-distribution.git
cd community-distribution

while ! kustomize build example | kubectl apply --server-side --force-conflicts -f -; do
  echo "Retrying to apply resources"
  sleep 20
done

Kubeflow Pipelines（KFP）の仕組みとPipeline・Runの関係

Kubeflowの中で最もよく使われるのがKubeflow Pipelines（KFP）です。「kfpとは」という検索が示すとおり、Kubeflowを触る入口はほぼここになります。KFPは機械学習の一連の処理を、有向非巡回グラフ（DAG）として組み立てて実行する仕組みです。ステップの内側で計算を複数ノードへ分散させたいなら、Rayとは？分散処理フレームワークの仕組みと採用判断で扱う分散実行基盤をコンポーネント内に組み合わせられます。

KFPを構成する5つの基本概念とコンポーネント間で受け渡す値の種類

• Component（コンポーネント）：前処理・学習といった1ステップ。コンテナとして実行される処理単位。
• Pipeline（パイプライン）：コンポーネントを入出力でつないだDAG全体。
• Run（実行）：パイプラインを走らせた1回分の実行インスタンス。
• Experiment（実験）：関連するRunをまとめる単位。パラメータを変えた比較に使う。
• Artifact（アーティファクト）：コンポーネントが出力するモデルやデータ。

コンポーネント間はパラメータ（小さな値）とアーティファクト（モデルやデータファイル）で結ばれ、どのRunがどの成果物を生んだかが記録されます。この追跡性が、スクリプトの寄せ集めとの決定的な違いです。パラメータは値をそのまま、アーティファクトはオブジェクトストレージ経由で受け渡します。

KFP SDK v2でパイプラインを定義しIR YAMLへ変換する手順

現行のKFP SDKはv2（kfp 2系）で、Pythonのデコレータでコンポーネントとパイプラインを定義します。PyPIのkfpページでは2026年9月時点の最新が2.17.0（2026年7月9日公開）、対応Pythonは3.9以上と記載されています。次は2つの数値を足すだけの最小パイプラインです。

from kfp import dsl
from kfp import compiler

@dsl.component(base_image="python:3.11")
def add(a: float, b: float) -> float:
    return a + b

@dsl.pipeline(name="addition-pipeline")
def addition_pipeline(x: float = 1.0, y: float = 2.0):
    add(a=x, b=y)

# コンパイルするとIR形式のYAML（PipelineSpec）が出力される
compiler.Compiler().compile(addition_pipeline, "pipeline.yaml")

生成されたpipeline.yamlをKubeflowにアップロードして実行します。SDKから直接Runを作ることもできます。

from kfp.client import Client

client = Client(host="http://localhost:8080")
client.create_run_from_pipeline_package(
    "pipeline.yaml",
    arguments={"x": 3.0, "y": 4.0},
)

v1からv2への主な変更点とContainerOp廃止後の書き換え方針

古い記事のコードをそのまま動かそうとすると、ここでつまずきます。v1で中心だったContainerOpクラスはv2で削除され、コンポーネントは@dsl.componentや@dsl.container_componentで定義する形に変わりました。コンパイル結果も、v1のArgo依存のYAMLからバックエンド非依存のIR YAML（PipelineSpec）へ統一されています。既存のコンポーネントYAMLはload_component_from_fileで読み込めるため、新規分からv2で書き始める進め方が現実的でしょう。

Kubeflowの試し方：ローカル検証から本番クラスタ導入までの段取り

フルのKubeflowはKubernetesクラスタ前提でリソース要求も大きいため、いきなり全部を立てる必要はありません。目的に応じて次の3段階から選べます。

kfp localでクラスタを立てずにロジックだけを検証する手順

パイプラインのロジックだけを手元で確認したいなら、kfp localが最短です。local.init()でランナーを初期化すると、コンポーネントを通常のPython関数のように呼び出して結果を得られます。

from kfp import local

local.init(runner=local.SubprocessRunner())

task = add(a=1.0, b=2.0)
print(task.output)   # 3.0 のように結果を直接取得できる

ランナーは軽量なSubprocessRunnerと、本番に近いDockerRunnerから選べます。公式のローカル実行ガイドでは、DockerRunnerがローカルのpipeline rootをコンテナへマウントし、出力をコンテナ外へ書き出す挙動だと説明されています。キャッシュやリトライは動かないため、ロジック検証用と割り切ってください。

minikube・kindへ入れてUIを含む挙動を手元で確かめる

Kubernetesの検証環境であるminikubeやkind上にデプロイすれば、UIを含む本来の挙動を試せます。必要メモリが大きいため、パイプラインだけ試すならKFPを単体で入れるstandalone構成が現実的でしょう。ノートPCで一式を立てようとしてPodがPendingのまま並ぶ、という詰まり方が起きやすい段階です。

本番デプロイで選べる3つの経路とマネージドへ寄せる判断の分かれ目

本番運用では、community-distributionのリリースをkustomizeで自クラスタに適用するのが基本です。クラウドのマネージドKubernetes上に載せるなら、Amazon EKSの仕組みと料金モデルやGKEのAutopilot／Standardの違いを踏まえ、ノード管理をどこまで自前で持つかを先に決めておくと後の運用が軽くなります。自前運用を避けるなら、KFPベースのマネージドであるVertex AI Pipelinesが選択肢で、KFP SDKで書いたパイプラインをほぼそのままサーバーレス実行できます。学習の一部をSQLで済ませたい場合は、BigQuery MLとVertex AIの分担も先に整理しておくとよいでしょう。

なお、awslabsのKubeflow on AWSはリリース一覧のとおり最新が2024年9月のv1.7.0-aws-b1.0.3で、対応Kubeflowは1.7.0のままです。新規インストールが動作しない旨の警告も付いているため、これから始めるなら別の経路を選んでください。

Kubeflow導入前に決める3点：クラスタ規模と認証とストレージ

Kubeflowでつまずく箇所は、パイプラインの書き方よりも基盤側の前提にあります。KFPのRunはステップごとにPodが立ち上がるため、5ステップを10人が同時に回せば数十Podがスケジュール待ちに入ります。後から決め直すと名前空間の切り直しやデータ退避が発生するので、次の4点は先に固めてください。

アーティファクト保管に使うオブジェクトストレージの置き場所を決める

Kubeflowはユーザーやチームを「Profile」で管理し、Profileごとに名前空間を割り当てます。1.11では名前空間ごとのS3認証情報に対応し、テナント間で保管先を分けられるようになりました。同時に既定のストレージバックエンドがMinIOからSeaweedFSへ切り替わっています（MinIOも引き続きサポート対象）。既定のまま本番へ持ち込むと、クラスタを作り直したときに過去の成果物ごと消えます。学習データと成果物はAmazon S3やGoogle Cloud Storageのようなクラスタ外へ逃がし、保持期間とライフサイクル規則まで決めておくのが安全側の設計です。

Kubeflowと他ツールの使い分け：Airflow・MLflow・Vertex AI

「kubeflow airflow」で検索されるように、KubeflowはAirflowやMLflowとよく比較されます。役割が重なって見えて守備範囲は違うので、まず全体像を表で整理します。

Apache Airflowとの違いはML専用機能を基盤が持つかどうか

Apache AirflowはDAGでタスクをスケジュール・実行する汎用のワークフローエンジンで、機械学習専用の機能は持ちません。分散学習やモデルサービングは自分で組み込むことになり、一方Kubeflowはそれらを最初からKubernetesネイティブに内包します。データ基盤全体のジョブ管理も含めて汎用的に回したいならAirflow、機械学習の学習から提供までをKubernetes上で完結させたいならKubeflowという切り分けです。Airflowでデータ処理を回しつつKubeflowでML部分を担わせる併用も見られます。

MLflowとの違いは実行基盤を抱えるか記録に徹するかの分かれ目

MLflowはインフラを問わず軽量に導入でき、実験のトラッキングとモデルのバージョニング・パッケージングが主眼です。Kubeflowのようにパイプラインの実行基盤やクラスタを持つわけではありません。両者は競合というより補完関係で、KubeflowでオーケストレーションしながらMLflowで実験を記録する併用が定石です。まず実験管理から始めたい小規模チームはMLflow単体が手軽でしょう。

Kubeflowを選ぶべきでない場面と代わりに置く現実的な選択肢

Kubernetesの運用経験がチームに無い場合、Kubeflow自体の運用コスト（アップグレード、認証、リソース管理）が機械学習の生産性を上回り、かえって足を引っ張ります。モデルが1〜2個で実験の記録が主目的なら、MLflow単体で足りるでしょう。Kubeflowが本領を発揮するのは、複数のモデルを継続的に学習・提供し、Kubernetes基盤を運用できる体制がある組織です。

受託開発の現場から見たKubeflowの採用条件と見送る判断の線引き

ここまでの整理を、発注や技術選定の立場から使える形にまとめ直します。Kubeflowは「機械学習のツール」というより「Kubernetesの運用プロジェクト」に近いため、判断の軸もそちら側に置くと外しにくくなります。

Kubeflowを採用してよい組織の条件を3つの観点で言い切る

採用に踏み切ってよいのは、次の3つが同時に成り立つときです。第一に、本番のKubernetesクラスタをすでに運用し、アップグレードと権限管理の当番が決まっていること。Kubeflowの更新は同梱コンポーネントの版がまとめて動くため、当番が居ないと1年で塩漬けになります。第二に、継続的に学習し直すモデルが3個以上あり、再学習のトリガーが決まっていること。単発のモデルではパイプライン化の投資が回収できません。第三に、成果物の置き場所と保持期間が決まっていること。

Kubeflowを見送るべき組織の条件と代わりに踏む現実的な進め方

逆に、Kubernetesの運用当番が居ない、モデルが1〜2個、学習が年に数回という条件なら、Kubeflowは見送ってください。代わりの進め方は段階的です。まずMLflowで実験の記録だけを始め、次にマネージドのパイプラインでDAG化し、クラスタ運用の必要が立ち上がってから自前のKubeflowへ移す。KFP SDKで書いたパイプラインはVertex AI Pipelinesでもほぼそのまま動くため、この順番なら手戻りも小さく収まります。

Kubeflow基盤を外注する場合に発注側が決めておく範囲と引き継ぎ

外部に基盤構築を任せる場合、発注前に決めておきたいのは「どこまでを納品物とするか」という線引きです。クラスタ構築までなのか、KFPのパイプライン実装まで含むのか、再学習の運用当番まで見るのかで、見積もりも体制も変わってきます。引き継ぎでは、kustomizeのオーバーレイ一式、Profileと名前空間の割り当て表、アーティファクトの保管先とライフサイクル規則の3点を文書で受け取っておくと、その後の内製化が進めやすくなるはずです。インフラ構築（AWS・Google Cloud・Azure）では、EKSやGKE上のKubernetes基盤の設計から運用の引き継ぎまでを含めて相談を受けています。

よくある質問

KFPとは何ですか？

KFPはKubeflow Pipelinesの略で、機械学習のワークフローをDAGとして定義・実行・監視するKubeflowの中核コンポーネントです。同名のPython SDK（パッケージ名kfp）でパイプラインを記述し、コンパイルしてKubeflowにデプロイします。現行はv2系で、PyPI上の最新は2.17.0です。

KubeflowとMLflowの違いは何ですか？

Kubeflowは機械学習をKubernetes上で動かすエンドツーエンドのプラットフォーム（パイプライン・学習・サービング）、MLflowはインフラ非依存で実験トラッキングとモデル管理を担う軽量ツールです。守備範囲が異なるため、オーケストレーションはKubeflow、記録はMLflowと併用されることも多くあります。

Kubeflowはローカルで試せますか？

試せます。パイプラインのロジックだけならkfp localでクラスタ無しに実行でき、UIを含めて動かしたい場合はminikubeやkind上にデプロイしてください。Kubeflow本体はKubernetesのカスタムリソースとコントローラの上に成り立つため、クラスタ無しで動くのはkfp localの範囲に限られます。

Kubeflow SDKとKFP SDKは違うものですか？

別物です。KFP SDK（kfp）はPipelinesを操作する従来からのSDKになります。Kubeflow SDK（github.com/kubeflow/sdk、PyPIパッケージ名kubeflow）はTrainer・Katib・Spark Operatorなど複数のコンポーネントを統一のPython APIから扱うSDKで、2026年3月のv0.4でPipelines（v2.17.0以降）への対応まで入りました。単一のコンポーネントだけならKFP SDKで足ります。

Kubeflow on AWSは今も使えますか？

これから新規に始める用途には向きません。awslabsが公開するKubeflow on AWSは最新リリースが2024年9月のv1.7.0-aws-b1.0.3で、対応Kubeflowは1.7.0のままアップストリーム（現行の26.03系）に追随できていない状態です。EKS上に自前でcommunity-distributionを適用するか、別のマネージド構成を検討してください。

Kubeflowの最新バージョンはどれですか？

2026年9月時点では、Community Distributionの26.03.1が最新の安定リリースです。それ以前のプラットフォーム版は1.11（2025年12月）で、以降は「年.月.パッチ」のカレンダー版番号へ移りました。年2回程度のベースリリースという計画のため、「1.12」を探しても見つかりません。

関連記事

• Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説
• Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説
• MLOpsとは？機械学習の運用を支える仕組みと導入判断をわかりやすく解説
• Rayとは？分散処理フレームワークの仕組みと採用判断を実装目線で解説【2026年版】
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説