8月19日、Cloud Native Nowが「Kubeflow's Graduation Is a Vote for Kubernetes as the AI Control Plane」と題した記事を公開した。この記事では、KubeflowのCNCF卒業を契機に、KubernetesがエンタープライズAIの共通コントロールプレーンになりつつあるという構造的な変化について詳しく紹介されている。
KubeflowがCNCFを「卒業」した
2026年8月17日、Cloud Native Computing Foundation（CNCF）はKubeflowの正式卒業（Graduation）を発表した。同年7月24日にCNCFの技術監視委員会（TOC）が承認した案件だ。
CNCFにおける「卒業」とは、プロジェクトの成熟度を示す最高位のステータスである。Sandbox→Incubating→Graduatedという3段階の中で、KubernetesやPrometheusといったプロジェクトと同列に並ぶことを意味する。
Kubeflowは2017年にGoogleが開発し、2023年にCNCFのIncubatingプロジェクトとして参加。そこから約3年で最高位に到達した。
本題：これはKubernetesへの「信任投票」だ
記事が主張する核心はここにある。KubeflowのGraduationは、Kubeflow単体の話ではなく、「KubernetesがAIインフラの共通コントロールプレーンになれるか」という問いへの答えだ、という点だ。
そもそもKubernetesは、コンテナ化されたアプリケーションをオーケストレーションするために設計されたシステムであり、AIワークロードを前提に作られたわけではない。GPUやTPUはCPUと比べてスケジューリングが格段に難しく、大規模な分散学習ジョブはポッドが落ちるたびに最初からやり直せない。推論には低レイテンシとトークンスループットの要件がある。通常のCPUベースのオートスケーリングメトリクスは、AIプラットフォームが必要とする情報のごく一部しか捉えられない。
しかしKubernetesはもともと、データベースやストレージ、仮想マシンも動かすように設計されていなかった。それでもコミュニティはOperator、CRD、専用コントロールループを使って拡張し、「コンテナスケジューラー」から「分散インフラの共通コントロールプレーン」へと変貌させた。Kubeflowは、AIに対して同じことを試みている。
TensorFlowランナーから「AIプラットフォーム」へ
Kubeflowの出発点は「KubernetesでTensorFlowを動かしやすくする」という狭い用途だった。現在はモジュール型のエコシステムへと拡張されている。
- Kubeflow Pipelines — ポータブルなAIワークフローの構築
- Kubeflow Trainer — 分散学習・LLMファインチューニング
- Katib — ハイパーパラメータ最適化・AutoML
- Kubeflow Notebooks — インタラクティブ開発環境
- Spark Operator — データ処理
- Model Registry — モデル・バージョン・メタデータ管理
これらは「Kubeflow Community Distribution」として一括デプロイできるが、個別に採用することも可能だ。エンタープライズは既存のデータツールや可観測性プラットフォームを持っているため、このモジュール性は実用上の重要なポイントになる。
なお、Kubeflowエコシステムから派生したKServe（プロダクション推論に特化）は、現在CNCFの独立したIncubatingプロジェクトとして分離している。
採用実績として挙げられているのは、CERN、DHL Data & AI、Jio Platforms（JioTV+のAIワークロード）、Telia、AT&T、Bloomberg、NVIDIA、Red Hat、LinkedIn、Spotify、Capital Oneなどだ。Pythonパッケージのダウンロード数は約2億6000万回、コントリビューターは1000以上の組織から6600人超に上る。
ロードマップが示す「本気度」
2026年のTrainerロードマップには、従来のMLOpsツールの延長線上にはない項目が並んでいる。
- ワークロード・トポロジーを考慮したスケジューリング
- Kueueを通じたマルチクラスタージョブディスパッチ
- マルチノードNVLinkサポート
- エラスティックトレーニング
- GPUアクセラレーテッドジョブのチェックポイント・リストア
- MPI、Flux、Slurm連携
- RDMA、Prometheusメトリクス、Grafanaダッシュボード
- LLMファインチューニング用のビルトインブループリント
さらに、Model Context Protocol（MCP）サーバーとの統合も計画されており、エージェント型AIワークフローへの対応が視野に入っている。
「卒業」＝「完成」ではない
記事は、Graduationの意義を認めつつも、現状の課題を率直に列挙している。
- SLO/SLIを独自定義していない
- アップグレード・ダウングレードの自動テストが未整備
- ディストリビューション間のコンフォーマンスプログラムが進行中
- インフラコスト把握はKubecostなど外部ツール依存
- Istio、Knative、cert-managerとの依存関係が既存Kubernetes環境を複雑化する
また、セキュリティ監査（ADA Logicsによる独立レビュー）では14件の脆弱性（うち3件はCritical）が発見された。メンテナーはその後対処し、脅威モデリングやファジングも追加している。Criticalが出たこと自体は手放しで歓迎できる話ではないが、外部レビューを受け入れ、結果を公開し、修正したという姿勢は成熟の証と言える。
「KubernetesがAIを制する」という問いの立て方自体が間違いかもしれない
記事の結論は示唆的だ。KubernetesがすべてのAIインフラを「置き換える」必要はない、という主張だ。
より現実的なアーキテクチャはレイヤー型になる。KubernetesがID管理・セキュリティ・ネットワーク・ポリシー・マルチテナンシーといった共通コントロールプレーンを担い、Kubeflowがライフサイクル全体の抽象化を提供し、専用システムが分散学習やアクセラレータースケジューリング、高性能推論を処理する、という構成だ。
多くのエンタープライズはすでにKubernetesを運用し、その周辺にスキルと自動化を蓄積している。AI専用の別インフラスタックを構築すれば、解消しようとしているサイロとは別の新たなサイロを作ることになる。
KubeflowのGraduationは、KubernetesがAIの波に飲み込まれるのではなく、その波の土台になりつつあることを示す出来事だ。
詳細はKubeflow's Graduation Is a Vote for Kubernetes as the AI Control Planeを参照していただきたい。
