Kubernetes AI Conformanceとは？CNCF認証の要件（KAR）と自社基盤への採用判断を実装者目線で解説

学習ジョブと推論サービスをKubernetesに載せる企業が増えるにつれ、同じマニフェストを別のクラスタへ持っていくと動かない、という事象が現場で目立つようになりました。GPUの割り当て方、分散学習の同時起動、アクセラレータ指標の出し方が基盤ごとに違うためです。CNCFはこの食い違いを減らすため、AI/MLワークロードを載せるKubernetes基盤が備えるべき能力を定義した認証制度、Certified Kubernetes AI Conformance Programを公開しました。

本記事は、この制度が何を定めているのか、要件（KAR）の中身はどこまで具体的か、そして自社のプラットフォーム選定で「AI適合性の認証」を条件に入れるべきかどうかを、実装者の判断材料として整理します。数値と版番号は2026年8月10日時点で一次情報にあたって確認したものです。

まとめ：Kubernetes AI Conformanceの要点と採用判断の結論

• 制度の位置づけ：AI/MLワークロードを載せるKubernetes基盤が備えるべき能力・設定の最小集合を定めた認証制度。既存のCertified Kubernetes Conformanceに合格していることが前提の上乗せ規格です。
• 時系列：2025年6月のKubeCon + CloudNativeCon Japanでbetaが示され、2025年11月11日のKubeCon + CloudNativeCon North Americaでv1.0とともにプログラムが開始されました。
• 要件の管理：要件はKubernetes AI Requirements（KAR）としてIDで管理され、Kubernetesのマイナー版ごとにチェックリストのYAMLが用意されます。2026年8月時点で最新は1.36系です。
• 要件の中身：Dynamic Resource Allocation（DRA）、gang scheduling、アクセラレータ指標に基づくオートスケール、GPU指標のPrometheus形式での公開、AIオペレータの動作実証、Gateway APIによる推論ルーティングなどが並びます。
• 現状の限界：多くのKARは「SHOULD」段階で、審査も提出書類による自己申告が中心です。自動テストと検証ボットは2026年内の整備が予定されています。
• 採用判断：GPUノードを自社で運用し、学習または推論を複数環境にまたがって載せるなら選定条件に入れる価値があります。単一クラウドの1環境だけで、推論を外部のマネージドAPIに任せている構成では、認証の有無より個別機能の実装状況を見るほうが実利があります。

Kubernetes AI Conformanceとは｜CNCFが定めた認証制度

Certified Kubernetes AI Conformance Programは、CNCFとKubernetesコミュニティが主導する認証制度です。狙いは単純で、あるAI適合基盤で動いたAIアプリケーションが、別のAI適合基盤でもそのまま動くという可搬性を担保することにあります。PyTorch、TensorFlow、Hugging Faceといった広く使われるフレームワークが同じ前提で走ることを、基盤側の責任範囲として言語化した点が新しいところです。

背景には実需があります。CNCFが引用したLinux Foundationの調査では、82%の組織がすでに独自のAIソリューションを構築しており、そのうち58%がKubernetesでワークロードを支えています。基盤の断片化が進むほど、同じジョブが環境ごとに違う挙動をするリスクが積み上がる、という問題意識が制度の出発点でした。

Kubernetes自体の役割やコンテナオーケストレーションの基礎から確認したい場合は、Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説と、自社に必要かどうかの判断軸をまとめたコンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説を先に読むと、本記事の要件が何の上に積まれているかを掴みやすくなります。

素のKubernetes適合性との違いと上乗せされる要件の範囲

AI Conformanceは、従来のCertified Kubernetes Conformanceのスーパーセットとして設計されています。つまり、まず標準のKubernetes適合性テストに合格していることが入口条件で、その上にAI固有の要件が積まれる構造です。従来の適合性は100を超えるディストリビューションとプラットフォームが取得しており、その運用モデルをAI領域へ持ち込んだ形になります。

上乗せされる範囲は、標準の適合性テストが踏み込まなかった領域に集中しています。アクセラレータのドライバとランタイム管理、ジョブ単位のネットワーク、ボリューム取り扱い、そしてAIフレームワークを動かすための参照構成です。汎用のワークロードでは表面化しない課題、たとえば「8基のGPUが揃うまでジョブを開始してはいけない」といった要求が、ここで初めて基盤側の要件として書き下されました。

プラットフォーム提供者が認証を取得するまでの申請手続きと審査

取得側の手続きは4段階に整理されています。要件を確認して自社基盤が満たしているかを検証し、チェックリストと証跡をそろえ、コンフォーマンスのリポジトリへプルリクエストを出し、CNCFのレビューを受けるという流れです。レビュー期間は営業日で10日程度が目安とされています。

提出物には、記入済みのYAMLチェックリスト、公開ドキュメント、製品ロゴ、そして基盤のKubernetes適合性の証明が含まれます。ここで押さえておきたいのは、2026年8月時点の審査が自動テストではなく自己申告と書類確認を軸にしている点です。CNCFは第三者検証を強めるための検証ボットの整備を進めており、自動コンフォーマンステストは2026年内の提供が予定されています。

KARで定義されるAI適合要件の中身と技術的な構成要素の全体像

要件はKubernetes AI Requirements、略してKARという識別子で管理されます。KAR-0001のようにIDが振られ、それぞれがKubernetesのどのマイナー版から適用されるかが紐づけられる仕組みです。要件ファイルはAIConformance-1.36.yamlのような命名で版ごとに置かれ、2026年8月時点では1.33から1.36までの版が参照できます。

設計上の特徴は、各要件が「SHOULD」から始まり、下地となるKubernetes APIが成熟するにつれて「MUST」へ昇格するライフサイクルを持つことです。DRAのようにKubernetes本体でベータから安定版へ進んでいる機能は、制度側でも段階的に必須へ寄せられていきます。裏を返せば、ある時点の認証は「すべての項目を必須として満たした」証明ではありません。

アクセラレータの要求を属性で表現するDRAという仕組みの位置づけ

従来のGPU要求は「nvidia.com/gpu を2個」といった数量指定でした。この書き方では、同じ2基でもメモリ容量や世代が違うカードが割り当てられ、学習ジョブが期待どおりに走らないことがあります。Dynamic Resource Allocation（DRA）は、数量ではなくデバイスの属性で要求を書けるようにする仕組みです。

これにより、特定のGPUモデルを指定したり、メモリ容量や演算能力に関する条件を宣言したりできます。AKSではKubernetes 1.34の系列でDRAが既定で有効化され、AI適合性の取得基盤として扱われました。異種のアクセラレータが同居するクラスタほど、この属性ベースの指定が効いてきます。

分散学習を止めないgang schedulingと全確保の考え方

分散学習では、必要なポッドが全部そろって初めてジョブが意味を持ちます。半分だけスケジュールされた状態は、単に進まないだけでなく、高価なGPUを占有したまま待ち続ける形になり、複数ジョブが互いの資源を奪い合ってデッドロックに陥ります。gang schedulingは、全部を確保できるときだけ起動し、できなければ何も起動しないという方針でこれを避ける手法です。

KARはこの能力を要件として掲げ、実装例としてKueueやVolcanoが挙げられています。バッチ寄りのML基盤を運用しているなら、既存クラスタで真っ先に確認したい項目でしょう。ここが未整備のまま学習ジョブを増やすと、GPU費用だけが伸びて学習が進まない状態になりがちです。

GPU指標の公開と可観測性まわりで求められる実装水準の目安と順序

要件には、アクセラレータの性能指標を機械可読なエンドポイントで公開することと、ワークロードからの指標をPrometheus形式など標準的な形で収集できることが含まれます。実装としてはNVIDIA DCGM Exporterが広く使われ、GPU使用率、メモリ、温度、消費電力といった値をPrometheus形式で出します。

この指標は監視のためだけのものではありません。GPU使用率を見てHPAが推論ポッドを増減させる、という制御の入力になるため、公開されていなければオートスケールの要件も成立しない関係にあります。クラスタ側の監視設計そのものはKubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断で整理しているので、閾値の決め方まで踏み込む場合はあわせて確認してください。

ネットワークとノード供給まわりで新しく加わった要件の輪郭と影響

1.36系ではネットワークとアーキテクチャの要件が加わりました。KAR-0010はPod間の高速通信、KAR-0011は推論向けの高度なイングレス、KAR-0041は推論処理を役割ごとに分離して動かす構成への対応を扱います。分散学習の通信がボトルネックになる規模では、CNIの選定が学習時間に直結します。

Pod間通信やService、Ingressの設計そのものはKubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断で扱っています。ノード供給側では、GPUノードを需要に応じて増減させる仕組みが要件になるため、Karpenterとは？Kubernetesのノード自動プロビジョニングの仕組みとCluster Autoscalerとの違い・採用判断で挙げた自動プロビジョニングの考え方がそのまま効いてきます。

認証済みプラットフォームの広がりと2026年8月時点の到達点

プログラム開始時点では、Amazon EKS、Google Cloud のGKE、Microsoft AzureのKubernetesサービス、Red Hat OpenShift、BroadcomのVMware vSphere Kubernetes Serviceといった主要基盤が初期の認証を取得しました。CNCFが2026年3月24日に公表した集計では、認証済みプラットフォームは18から31へ増えています。

この間に加わった顔ぶれには、OVHcloud、SpectroCloud、JD Cloud、China Unicom Cloudなどが含まれます。SUSEのRKE2やMirantisのk0sといった軽量ディストリビューションも認証を取得しており、パブリッククラウドのマネージドサービスに限らず、オンプレミスや自前運用の選択肢にも広がってきました。GPU基盤を提供する新興事業者にとっては、能力を示す共通の物差しとして機能し始めています。

マネージドサービス側の実装を具体的に見たい場合は、Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説とGoogle Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを実装者目線で解説で、ノード提供形態と料金モデルの違いを押さえておくと、認証の有無と運用コストを同じ土俵で比べられます。

AI Conformanceが解こうとする実装現場の課題と背景

制度が想定している痛みは、抽象的な相互運用性の話ではありません。もっと即物的で、GPUの利用効率と移行コストに直結する課題群です。

ひとつ目は資源のデッドロックです。gang schedulingが効かない環境では、複数の分散学習ジョブが部分的にポッドを確保したまま膠着し、時間単価の高いアクセラレータが仕事をしないまま課金され続けます。ふたつ目は異種ハードウェアの取り違えで、数量指定しかできない基盤では世代の違うGPUが混ざり、学習時間の見積もりが崩れます。

三つ目は可観測性の欠落でした。推論のレイテンシやスループット、ハードウェアの健全性が標準的な形で出てこない基盤では、性能劣化の原因をアプリ側かハード側か切り分けられません。四つ目は移行コストで、基盤ごとに前提が違えば、クラウドを跨いだ配置換えのたびにマニフェストと運用スクリプトを書き直す作業が発生します。AI適合性は、この四つを基盤側の責任として明文化し、選定時に確認できる形へ落とし込む試みだと読めます。

自社基盤にAI適合性を求めるべき条件と見送ってよい場面の整理

ここからは制度の説明ではなく、選定に関わる立場としての判断を書きます。結論から言えば、AI適合性は「GPUを自社で抱えるかどうか」で価値が大きく変わる指標です。

自社にAI適合性の認証を求めてよい三つの条件と判断が変わる分岐点

次の三つのいずれかに当てはまるなら、プラットフォーム選定の条件に入れる実利があります。第一に、学習ジョブをオンプレミスのGPUとパブリッククラウドの両方に載せる計画があること。第二に、GPUノードを自社で運用し、その稼働率を運用改善で引き上げていく方針を持っていること。第三に、推論基盤を将来別のクラウドへ移す可能性が要件として挙がっていることです。

これらの条件下では、認証の有無が移行時の書き直し量を左右します。とくに二番目のケースでは、gang schedulingとアクセラレータ指標に基づくオートスケールが揃っているかどうかで、同じGPU台数から取り出せる仕事量が変わってきます。逆に言うと、この三条件のどれにも当てはまらない組織にとって、認証バッジは選定を左右するほどの情報を持ちません。

認証バッジの有無よりも個別機能の実装状況を確かめるべき場面の整理

見送ってよいのは、まず推論を外部のマネージドAPIで賄い、Kubernetes上にGPUを持たない構成です。この場合に効いてくるのはGateway APIまわりのルーティングくらいで、要件の大半は自社の運用に触れません。次に、単一クラウドの単一リージョンで完結し、移行予定もない構成も同様です。可搬性のために払うコストが、得られる自由度に見合いません。まだPoC段階で常時稼働のGPUを持たない段階も、判断を急ぐ理由が薄いでしょう。

加えて、認証を過大に読まないことも判断の一部です。前述のとおり多くのKARはSHOULD段階にあり、審査も自己申告が中心です。したがって認証済みという表示は「その基盤がAI適合性のチェックリストに回答を提出し、CNCFの書類確認を通った」ことを意味します。自社が実際に使う機能、たとえばMIGによるGPU共有やRDMA対応のCNIが本当に動くかどうかは、要件ファイルの該当項目と提出済みチェックリストを突き合わせて確かめてください。ここを省略すると、バッジはあるのに必要な機能が未実装、という取り違えが起こります。

プラットフォーム選定に認証をどう組み込むかの実務手順と確認項目

実務では、次の順序で確認すると判断が早く済みます。制度そのものを追いかけるのではなく、自社のワークロードから逆算する形です。

対象とするKubernetesマイナー版の要件ファイルを読む手順

最初に、自社のAIワークロードを学習、推論、エージェント実行のどれが主かで分類します。次に、運用予定のKubernetesマイナー版に対応する要件ファイルを開き、KARの一覧から自社に関係する項目だけを抜き出します。学習中心ならgang schedulingとDRA、推論中心ならGateway APIとアクセラレータ指標のHPA、というように読む範囲を絞るのが実務的です。

そのうえで、候補基盤が提出したチェックリストと突き合わせ、必要な項目がSHOULDどまりで未実装の場合は、その機能を個別に検証する計画を立てます。GKEのように対応バージョンを公式ドキュメントで示している基盤もあるため、クラスタの版指定まで含めて確認しておくと、後戻りを避けられます。最後に、監視とオートスケールの設定が要件どおりに動くかを、実際のGPUノードで小さく試すところまでを選定工程に含めてください。

GPU基盤を含むクラウドインフラの設計と構築を外部に委ねる選択肢を検討している場合は、インフラ構築（AWS・Google Cloud・Azure）で対応領域と進め方を確認できます。要件の読み解きから、認証済み基盤の比較、実機での検証設計までをまとめて相談する形が現実的です。

よくある質問

AI Conformanceを取得していない基盤ではAIワークロードを動かせませんか？

動かせます。この制度は動作の可否を定めるものではなく、共通の能力が揃っているかを示す指標です。認証がない基盤でも、必要な機能を個別に導入すれば学習や推論は動きます。認証が効いてくるのは、複数の基盤にまたがって同じ構成を使い回すときや、選定段階で候補を横並びに比べたいときです。

認証を取ると性能が保証されるのでしょうか？

性能の保証ではありません。2026年8月時点の審査はチェックリストの提出と書類確認が中心で、自動的な性能テストは含まれていません。CNCFは第三者検証を強めるための検証ボットと自動コンフォーマンステストの整備を進めており、この状況は今後変わる見込みです。現時点では、スループットやレイテンシは自社のワークロードで実測してください。

KARの要件はすべて満たさないと認証されませんか？

現在確認できる範囲では、多くのKARがSHOULD、つまり推奨の位置づけです。下地となるKubernetes APIが安定するにつれて、個々の項目がMUSTへ昇格していく設計になっています。そのため「認証済み」の内実は版によって異なり、どの版の要件で認証されたかまで見ないと、実装範囲を取り違えることがあります。

既存のKubernetesクラスタをAI適合の構成に近づけるには何から着手しますか？

GPUを扱っているなら、指標の公開から始めるのが実装コストと効果のバランスが良いところです。DCGM Exporterで使用率とメモリをPrometheus形式に出せば、監視とHPAの両方の下地が同時に整います。その次にgang schedulingの導入、続いてDRAへの移行という順序が、既存ジョブへの影響を抑えやすい進め方でしょう。

今後この制度はどこまで広がる予定ですか？

CNCFは自動コンフォーマンステストへの移行に加えて、2026年内にソブリンAI向けの基準へ範囲を広げる方針を示しています。サンドボックス強化とデータプライバシーを扱う領域で、規制産業や公共分野の要求に応える意図が読み取れます。要件ファイルはKubernetesのリリースサイクルに合わせて更新されるため、選定時は最新版を確認する運用にしておくと安全です。

関連記事

• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説
• Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説
• Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを実装者目線で解説
• Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断
• Kubernetesネットワーク設計｜Service・Ingress・Pod間通信とCNI選定の実装判断
• Karpenterとは？Kubernetesのノード自動プロビジョニングの仕組みとCluster Autoscalerとの違い・採用判断