Kubeflowとは？Kubernetes上の機械学習基盤の構成とPipelinesの使い方【26.03.1対応】

Kubeflowは、機械学習やAIのワークロードをKubernetes上で動かすためのオープンソースのプラットフォームです。単体のツールではなく、Pipelines・Trainer・Katib・Hubなど役割の違うサブプロジェクトの集まりで、必要なものだけを単独で入れることも、一式をまとめて入れることもできます。

この記事では、2026年7月のCNCF卒業と版番号の切り替えを踏まえた現在の構成を押さえ、中核のKubeflow Pipelines（KFP）でのパイプラインの書き方、kfp localとkindでの試し方、導入前に決めること、AirflowやMLflowとの使い分けまでを順に扱います。KFP SDKの書き方とv1からの移行を詳しく知りたい場合は、Kubeflow Pipelines v2（KFP）とは？SDK 2.17の書き方とv1からの移行・実行手順が専門の解説です。

まとめ：Kubeflowの現在地と採用可否の分かれ目

• 正体：Kubernetes上でAI・機械学習を動かすサブプロジェクト群。2023年7月にCNCFのIncubatingへ受理され、2026年7月24日にGraduated（卒業）へ移った。
• 構成：Graduatedのサブプロジェクトは Pipelines・Trainer・Katib・Notebooks・Hub・Spark Operator の6つ。推論のKServeは2025年9月に独立したCNCFプロジェクトになり、Kubeflowからは「エコシステム」の扱い。
• 最新版：一式を束ねたCommunity Distributionは26.03.1（2026年6月15日）が最新の安定版。1.11（2025年12月）の次から「年.月.パッチ」の版番号に変わった。KFP SDKは2.18.0（2026年10月28日）。
• 試し方：パイプラインのロジックだけならkfp localでクラスタ無しに動く。一式をkindに入れるならメモリ16GB・8コアが推奨。
• 使い分け：汎用のジョブ管理ならAirflow、実験の記録ならMLflow、クラスタを持ちたくないならGoogle CloudのAgent Platform Pipelines。Kubernetesの運用当番がいない組織はKubeflowを選ばない。

Kubeflowとは：Kubernetes上でAIワークロードを動かすサブプロジェクト群

Kubeflowは、データ処理・学習・ハイパーパラメータ探索・モデル管理といった機械学習の工程を、Kubernetesのコンテナとして動かすための部品群です。Kubernetesがスケジューリングとスケールを受け持ち、Kubeflowはその上にパイプラインや分散学習の仕組みを載せます。土台のKubernetes（クバネティス）の仕組みを理解していると、Kubeflowの設計はほぼそのまま読めます。

公式の紹介ページは、Kubeflowを「Kubernetesネイティブなデータ・AIワークロードのスタックを成す、モジュール型のオープンソースプロジェクト群」と説明しています。名前の由来もここにあり、ロゴのKとFはKubernetes（cloud native）とflow（データフローグラフで表すML全般）の2つのコミュニティを表しています。

コンテナ単位の処理による再現性とスケールの管理

機械学習の開発では、前処理・学習・評価の処理がノートブックやスクリプトに散らばりがちです。半年前の学習を再実行したいのに、当時のライブラリの版も前処理の条件も誰にも分からない。よくある詰まり方です。Kubeflowは各処理をコンテナにして入出力を記録するので、どの実行がどのモデルを生んだかを後から追えます。モデルを作って終わりにせず回し続けるMLOps（機械学習の運用）の実行基盤の一つ、という位置づけです。

CNCF卒業とカレンダー版番号への移行

KubeflowはGoogle社内でTensorFlowを動かしていた仕組みを2017年に公開したのが始まりで、2023年7月25日にCNCFのIncubatingプロジェクトになりました。CNCFのプロジェクトページによると、2026年7月24日にGraduatedへ移っています。2026年8月17日の卒業発表では、Pythonパッケージの累計が約2億6,000万ダウンロード、1,000超の組織から6,600人超のコントリビューターが参加していると示され、卒業の条件として第三者のセキュリティ監査と運営委員会の設置を済ませたことも書かれています。

版番号の付け方も変わりました。リリース一覧では、1.11.0（2025年12月15日）の次が26.03（2026年3月22日）、続いて26.03.1（2026年6月15日）です。community-distributionのREADMEには、KubeCon EUとNAの前に年2回、たとえば26.03と26.10を出す計画が書かれていますが、2026年10月31日時点で26.10はまだ公開されていません。リポジトリ名もkubeflow/manifestsからkubeflow/community-distributionに変わったため、「kubeflow manifests」で探した古い手順書はリンク先を読み替えてください。

Kubeflowのサブプロジェクト構成と成熟度（2026年版）

Kubeflowを「一つのツール」と捉えると混乱します。公式のインストールページはサブプロジェクトを成熟度別に並べており、単独で入れても、一式（Distribution）の一部として入れても使える設計です。

Model RegistryからKubeflow Hubへの改称は、26.03.1のリリース告知で「完了」と書かれた変更です。古い資料で旧名を見かけたら同じものと読み替えてください。

KServeとFeastはKubeflowの外の「エコシステム」

以前の解説で必ず構成要素に入っていた推論サーバーのKServe（旧KFServing）は、2025年9月29日にKubeflowとは別のCNCF Incubatingプロジェクトとして受理されました。kubeflow.orgでは特徴量ストアのFeastと並ぶエコシステムのプロジェクトとして載っています。とはいえ、Community Distributionの一式には今もKServeが同梱されており（26.03.1ではKServe 0.18.0）、Kubeflowで学習したモデルをKServeで配信する組み合わせ自体は変わりません。推論基盤の選び方はモデルサービングとKServe・Triton・BentoMLの選定基準で比べています。

Kubeflow Pipelines（KFP）の仕組みとパイプラインの書き方

機械学習パイプラインとは、データの取得・前処理・学習・評価・登録といった工程を、入出力でつないだ一連の処理として定義したものです。Kubeflow Pipelines（KFP）はこれを有向非巡回グラフ（DAG）として組み、ステップごとにKubernetesのPodを立てて実行します。この記事ではKFPを入口として、コンポーネントの定義からパイプラインの実行までを説明します。

KFPの5つの基本概念と値の受け渡し

• Component：前処理や学習などの1ステップ。コンテナとして実行される。
• Pipeline：コンポーネントを入出力でつないだDAG全体。
• Run：パイプラインを1回走らせた実行単位。
• Experiment：パラメータ違いのRunを比べるためのまとまり。
• Artifact：コンポーネントが出力するモデルやデータセット。

小さな値はパラメータとしてそのまま渡し、モデルやデータファイルはアーティファクトとしてオブジェクトストレージ経由で渡します。どのRunがどのアーティファクトを生んだかが残る点が、スクリプトを順に呼ぶだけの運用との違いです。KFPのバックエンドは、ステップの実行にArgo Workflowsを使っています（26.03.1の構成表ではArgo Workflows 3.7.3）。

KFP SDK 2.18によるパイプライン定義とコンパイル

現行のSDKはv2系で、PyPIのkfpの最新は2.18.0（2026年10月28日公開・Python 3.9以上）です。次の例は、足し算の結果を2乗する2ステップのパイプラインで、kfp 2.18.0とPython 3.11の環境でコンパイルと実行を確かめています。

from kfp import dsl, compiler

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

@dsl.component(base_image="python:3.11")
def square(x: float) -> float:
    return x * x

@dsl.pipeline(name="add-and-square")
def calc_pipeline(x: float = 1.0, y: float = 2.0) -> float:
    s = add(a=x, b=y)
    return square(x=s.output).output

# IR YAML（PipelineSpec）を書き出す
compiler.Compiler().compile(calc_pipeline, "pipeline.yaml")

出力されたpipeline.yamlの末尾にはschemaVersion: 2.1.0とsdkVersion: kfp-2.18.0が入ります。このファイルをKubeflowのUIからアップロードするか、SDKから直接Runを作ります。

import os
from kfp.client import Client

# Dexでログインしたセッションのクッキーを環境変数で渡す
client = Client(
    host="http://localhost:8080/pipeline",
    cookies=os.environ["KFP_SESSION_COOKIES"],
)
client.create_run_from_pipeline_package(
    "pipeline.yaml",
    arguments={"x": 3.0, "y": 4.0},
    namespace="kubeflow-user-example-com",  # 権限のあるProfileの名前空間
)

Community Distributionはログインが必要なため、ブラウザでログインしただけではPythonのClientは認証されません。クラスタの外から接続するときは、公式の「Connect the SDK to the API」にあるとおりDexのセッションクッキーを取得してcookiesに渡し、Runを作る名前空間（既定ユーザーならkubeflow-user-example-com）を指定します。クッキーには有効期限があるので、期限が切れたら取り直します。

v1で中心だったContainerOpはv2で削除され、コンポーネントは@dsl.componentか@dsl.container_componentで書きます。v1の記事にあるコードを移行するときは、まずContainerOpの使用箇所を確認してください。移行の手順と、ParallelFor・条件分岐などの書き方はKFP v2の解説記事に分けています。

Kubeflowの試し方：kfp localからkindでの一式導入まで

一式のKubeflowは重いので、確かめたいことに合わせて段階を選びます。パイプラインの中身ならkfp local、UIや権限を含めた動きならkindへの一式導入、本番なら下の経路の中から選ぶ、という順です。

kfp localによるクラスタ不要のパイプライン実行

先ほどのcalc_pipelineは、KFP SDKをインストールした環境でlocal.init()を呼ぶと実行できます。以下は使い捨てのPython仮想環境を前提とし、use_venv=Falseでは各ステップ専用の仮想環境を作らず、現在の環境に依存パッケージをインストールします。

from kfp import local

local.init(runner=local.SubprocessRunner(use_venv=False))
task = add(a=1.0, b=2.0)
print(task.output)        # 3.0
run = calc_pipeline(x=3.0, y=4.0)
print(run.output)         # 49.0

ランナーは2種類です。公式のローカル実行ガイドは、各ステップを別コンテナで動かすDockerRunnerを「可能な限り使う」よう強く勧めています。SubprocessRunnerはDockerを入れられないノートブック環境向けで、実行できるのはLightweight Python Componentだけです。同じガイドは、ローカル実行ではリトライやメモリ・GPUの指定が効かないとしています。キャッシュについては、2.18.0のlocal.init()にenable_caching引数（既定は無効）があるので、必要なら明示的に有効にします。

kindへのCommunity Distribution 26.03.1の一式導入

UIやマルチユーザーを含めて試すなら、community-distributionの手順でkindクラスタに一式を入れます。実行前にDockerまたはPodmanを用意し、LinuxではREADMEのinotify上限設定も済ませます。READMEの前提はメモリ16GB以上・CPU 8コアの推奨で、構成要素を減らせば4〜8GB・2〜4コアまで下げられるとしています。26.03.1のREADMEにある資源の見積もりは、全体でCPU約4.4コア、メモリ約12GB、永続ボリューム65GBです。内訳ではPipelinesが最も重く（メモリ3,552Mi・PVC 35GB）、Istio（2,364Mi）とKubeflow Hub（2,112Mi）が続きます。

git clone -b 26.03.1 https://github.com/kubeflow/community-distribution.git
cd community-distribution
./tests/install_KinD_create_KinD_cluster_install_kustomize.sh
kind get kubeconfig --name kubeflow > /tmp/kubeflow-config
export KUBECONFIG=/tmp/kubeflow-config
while ! kustomize build example | kubectl apply --server-side --force-conflicts -f -; do
  echo "Retrying to apply resources"; sleep 20
done
kubectl port-forward svc/istio-ingressgateway -n istio-system 8080:80

タグ名は26.03.1で、先頭にvは付きません（1.11までのv1.11.0とは書式が違います）。ブラウザでhttp://localhost:8080を開くとDexのログイン画面が出て、既定のユーザーは[email protected]、パスワードは12341234です。READMEは本番では必ずこのパスワードを変えるよう警告しています。ノートPCでPodがPendingのまま並ぶときは、まずメモリ不足を疑ってください。

本番の導入経路：パッケージ版・自前適用・マネージド

本番の経路は3つあります。community-distributionを自分のクラスタにkustomizeで適用する方法、ベンダーが保守するパッケージ版を使う方法、そしてKubeflowを立てずにマネージドのパイプライン実行サービスへ寄せる方法です。公式のインストールページに載っているパッケージ版は次のとおりで、Kubeflowコミュニティはどれも推奨・認定はしないと明記しています。

AWSとGoogle Cloudはこの一覧にありません。Amazon EKSやGKEに載せる場合は、community-distributionを自分で適用することになります。awslabsのKubeflow on AWSはリリース一覧の最新がv1.7.0-aws-b1.0.3（2023年9月1日）で、対応Kubeflowも1.7のままなので、新規の導入先には向きません。OpenShift上で商用サポート付きで動かすなら、Open Data Hubを製品化したRed Hat OpenShift AIが候補になります。

クラスタを持ちたくない場合、Google CloudのVertex AI Pipelines（現在の名称はGemini Enterprise Agent Platform Pipelines）がKFPやTFXで書いたパイプラインをサーバーレスで実行します。料金は1回の実行ごとの固定費に計算資源の利用料が加わる形です。KFP SDK v2のパイプライン定義はそのまま使えますが、公式の移行ガイドによると、Kubeflow Pipelinesで永続ボリューム（PVC）を使っていた処理は、Cloud StorageのバケットをCloud Storage FUSEでマウントする形に置き換えます。認証やマシン指定などの設定も移行先に合わせて見直します。学習の一部をSQLで済ませる構成なら、BigQuery MLとVertex AIの分担も合わせて決めておくと手戻りが減ります。

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

Kubeflowでつまずくのは、パイプラインの書き方より基盤側の前提です。KFPはステップごとにPodを立てるため、同時に必要な資源は「同時に走るRunの数×DAGの中で並列に動くステップ数×各ステップの要求資源」で決まります。並列のステップが多いパイプラインを複数人が同時に回し、クラスタの空きが足りなければ、Podはスケジュール待ちになります。後から決め直すと名前空間の切り直しやデータの移し替えが発生するので、次の4点は先に固めてください。

認証は、一式の既定ではDex（OIDC）とoauth2-proxyでログインし、ユーザーやチームを「Profile」単位で名前空間に割り当てます。社内のIDプロバイダーにつなぐかどうかは、最初に決めておく事項です。

アーティファクトの保管先とSeaweedFSへの切り替え

保管先の既定は版によって変わっています。1.11のリリース告知で、Pipelinesの既定のオブジェクトストアはMinIOからSeaweedFSに替わり、名前空間ごとのS3認証情報にも対応しました。26.03.1の告知では、PipelinesでのMinIOの非推奨化が完了し、MinIOクライアントのコードもAWS SDK v2に置き換えられています。1.10以前の手順書どおりにMinIO前提で組むと、更新のたびに設定を読み替えることになります。

もう一つの落とし穴は、既定のストレージがクラスタ内で動いていることです。クラスタを作り直したときに成果物が残るかは、永続ボリュームの保存先と削除方法、保持ポリシー（reclaimPolicy）で決まります。GKEのドキュメントのとおり、動的プロビジョニングの既定であるDeleteではPVCを消すと基盤のディスクも削除されます。学習データと成果物はAmazon S3やGoogle Cloud Storageのようなクラスタ外のS3互換ストレージに置き、保持期間とライフサイクル規則まで決めておくのが安全です。

Kubeflowと他ツールの使い分け：Airflow・MLflow・Agent Platform Pipelines

KubeflowとAirflow・MLflowを比較するときは、処理を実行する基盤と実験・モデルを管理する機能を分けて考えます。役割が重なって見えても守備範囲は違います。

Apache Airflowとの比較：汎用ジョブ管理とML専用機能

Apache AirflowはDAGでタスクを定時実行する汎用のワークフローエンジンで、分散学習やハイパーパラメータ探索の仕組みは持ちません。データ基盤のバッチ全体を回すならAirflow、学習から評価・登録までをKubernetes上で完結させるならKubeflow、という切り分けになります。データの取り込みはAirflowで回し、学習の部分だけKFPのRunを起動する併用もよく見られます。

MLflowとの比較：実験管理・処理実行と基盤の提供範囲

MLflowは実験のパラメータ・指標・モデルを記録・管理する機能に加え、MLflow ProjectsでローカルやDatabricks、Kubernetes上の処理を起動する機能も備えています。ただし、Kubeflowのように分散学習や探索などの基盤を一式で提供するものではありません。競合というより補完の関係で、Kubeflowで実行してMLflowに記録する組み合わせが定番です。Kubeflow側も「MLflow連携」をExperimentalのサブプロジェクトとして進めていますが、まだ実験段階なので、現時点では各コンポーネントからMLflowのAPIを直接呼ぶ構成が確実です。

Kubeflowの採用条件と見送る判断の線引き

Kubeflowは「機械学習のツール」というより「Kubernetesの運用プロジェクト」に近いものです。判断の軸もそちらに置くと外しにくくなります。

採用してよい組織の3条件

採用に踏み切ってよいのは、次の3つが同時に成り立つときです。第一に、本番のKubernetesクラスタをすでに運用し、アップグレードと権限管理の当番が決まっていること。Community Distributionは年2回のベースリリースで同梱コンポーネントの版がまとめて動き、26.03.1の告知によるとコミュニティのサポートはベストエフォートで約6か月です。当番がいなければ、サポート切れの版で動かし続けることになります。第二に、継続的に学習し直すモデルが複数あり、再学習のきっかけ（データ更新・精度低下）が決まっていること。単発のモデルで再実行や監査の要求も少ないなら、パイプライン化の手間に見合う効果は得にくくなります。第三に、成果物の置き場所と保持期間が決まっていることです。

見送るべき条件と段階的な代替策

Kubernetesの運用当番がいない、モデルが1〜2個、学習が年に数回。この条件ならKubeflowは見送ってください。Kubeflow自体の更新・認証・資源管理の手間が、機械学習の生産性を上回ります。代わりに、まずMLflowで実験の記録だけを始め、次にマネージドのパイプライン実行サービスでDAG化し、クラスタ運用の必要が出てから自前のKubeflowへ移す順で進めます。KFP SDK v2で定義し、ストレージや認証などの環境依存部分を分離したパイプラインはAgent Platform Pipelinesでも再利用しやすいため、この順なら手戻りは小さく収まります。

基盤構築を外注するときに決めておく範囲

外部に任せる場合は、クラスタ構築までか、KFPのパイプライン実装まで含むか、再学習の運用まで見るかを発注前に決めます。範囲によって見積もりも体制も変わるためです。引き継ぎでは、kustomizeのオーバーレイ一式、Profileと名前空間の割り当て表、アーティファクトの保管先とライフサイクル規則の3点を文書で受け取っておくと、その後の内製化が進めやすくなります。パイプラインに載せるモデルそのものの設計や学習から相談したい場合は、機械学習モデル開発で受け付けています。

よくある質問

KFPとは何ですか？

KFPはKubeflow Pipelinesの略で、機械学習の工程をDAGとして定義・実行・監視するKubeflowの中核サブプロジェクトです。同名のPython SDK（パッケージ名kfp）でパイプラインを書き、コンパイルしたYAMLをKubeflowに登録して実行します。2026年10月28日時点のSDKの最新は2.18.0です。

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

Kubeflowはパイプライン実行・分散学習・ハイパーパラメータ探索までをKubernetes上で動かす基盤で、MLflowは実験とモデルの記録・管理を中心に、MLflow Projectsで処理を起動する機能も持つツールです。分散学習や探索の基盤までは持たないため、Kubeflowで実行し、MLflowに記録する併用がよく取られます。

kubeflow/manifestsはどこに移りましたか？

一式を束ねるリポジトリは、kubeflow/manifestsからkubeflow/community-distributionに名前が変わりました。最新の安定版は26.03.1で、git clone -b 26.03.1のようにvを付けないタグ名で取得します。

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

別物です。KFP SDK（kfp）はPipelines専用のSDKです。Kubeflow SDK（PyPIのkubeflow）はTrainer・Katib・Hub・Spark Operator・Pipelinesを1つのPython APIで扱うためのSDKで、0.5.0（2026年8月10日）でPipelines向けのPipelinesClient()とSpark向けのSparkClient()に対応しました。対応するPipelinesは2.17.0以降、Pythonは3.10以上です。Pipelinesだけを使うならKFP SDKで足ります。

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

2026年10月31日時点では、Community Distributionの26.03.1（2026年6月15日公開）が最新の安定版です。同梱するのはPipelines 2.16.1・Trainer 2.2.0・Katib 0.19.0・KServe 0.18.0で、Kubernetes 1.35以上が対象です。1.11の次は年月ベースの版番号に移ったため、1.12は出ていません。

関連記事

• Kubeflow Pipelines v2（KFP）とは？SDK 2.17の書き方とv1からの移行・実行手順
• Kubernetes（クバネティス）とは？仕組み・メリット・デメリットとDockerとの違いをわかりやすく解説
• MLOpsとは？DevOpsとの違い・成熟度レベル0〜2・主要ツールとMLflowで始める手順【2026年10月】
• モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】
• Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順