「学習中心」だったAI計算需要が、静かに逆転している
Kubernetes AI推論という言葉を、この1年でよく見かけるようになったと感じていないでしょうか。KubeCon + CloudNativeCon Japan 2026の基調講演でも、CNCFの関係者がAIコンピューティング配分の変化について語っていました。数年前まで、AI関連の計算資源の大半はモデルの「学習（トレーニング）」に投じられていましたが、今その主役は「推論（インフェレンス）」に移りつつあります。
データセンター需要に関する分析によれば、AI推論向けの計算能力は2030年までに90ギガワット超（年平均成長率35%）に達すると予測されています。McKinseyの試算はさらに具体的で、AI学習向けのデータセンター需要は2025年の23.1ギガワットから2030年に62.2ギガワット（年平均成長率22%）へ拡大する一方、推論向けの需要は同じ期間で20.9ギガワットから93.3ギガワット（年平均成長率35%）へと急拡大するとされています。2030年時点で、推論はAI計算全体の半分以上を占め、学習を上回る最大のワークロードになる見込みです。
同様の傾向は他の調査でも指摘されています。データセンター動向の分析記事では、Deloitteの推計として「2025年時点で推論がAI計算全体の半分を占め、2026年には3分の2に達する」という見立てが紹介されており、Brookfieldの予測では2030年までに推論がAI計算需要の75%を占めるとされています。数字に幅はあるものの、方向性は一致しています。学習中心で設計されたインフラは、もう前提が崩れているということです。
これだけの規模でワークロードの主役が入れ替わるとなると、これから基盤を選ぶ・見直す企業にとっては、コスト効率とベンダーロックイン回避を両立できるかどうかが重要な判断軸になっていきます。実際、KuboのようなK3sベースのマネージドKubernetesを検討する動きも出てきています。
この変化が厄介なのは、学習と推論ではインフラに求められる性質がまったく異なる点です。次の章では、その違いがKubernetes運用にどう跳ね返ってくるかを見ていきます。
推論ワークロードはなぜKubernetesを"作り直させる"のか
学習ジョブは基本的にバッチ処理です。数時間から数日かけて一度に大量のGPUを使い切り、終われば解放する。一方、推論ワークロードは常時稼働が前提で、リクエスト数に応じて秒単位・分単位でスケールし、レイテンシの悪化がそのままユーザー体験の悪化に直結します。学習用に最適化されたスケジューリングやリソース管理の仕組みを、そのまま推論に流用すると無駄が生まれやすいのです。
この課題に対応するため、Kubernetes本体にも推論向けの機能追加が進んでいます。代表例が「In-Place Pod Resize」です。Kubernetes公式ブログによると、この機能はPodを再起動せずにCPU・メモリのリクエスト/リミットを変更できるもので、v1.33でベータ昇格・デフォルト有効化されました。推論サービングでは、起動直後は高いCPUを必要とし、その後は低い水準で安定するようなケースが多く、再起動なしでリソース調整できることは可用性に直結します。
さらに、Google Cloudのブログでは、推論・学習双方に対応するための技術要素として、GPU/TPUをきめ細かく制御する「Dynamic Resource Allocation（DRA）」、分散学習ジョブがリソースを揃うまで待機する「All-or-Nothing Scheduling」、GPU使用率などのカスタムメトリクスに基づくオートスケーリング、アクセラレータの標準化された可観測性の4点が紹介されています。いずれも、Kubernetesが「コンテナオーケストレーター」から「AIワークロード基盤」へと役割を広げつつあることを示しています。
こうした機能拡張が個々のクラウドやディストリビューションでバラバラに実装されると、結局は「動く環境」が限定されてしまいます。そこで動き出したのが、CNCFによる標準化の取り組みです。
CNCFの「AI Conformance Program」は何を保証しようとしているのか
CNCFの公式発表によると、Certified Kubernetes AI Conformance Programは2025年6月のKubeCon Japanでベータ版が発表され、同年11月11日のKubeCon North America（アトランタ）で正式ローンチされました。目的は明確で、AIワークロードの相互運用性と移植性を確保し、ベンダー間の断片化を減らすことです。AWS、Google Cloud、Microsoft Azure、Oracle、Red Hatなど主要クラウドがすでに認証プラットフォームとして参加しています。
Forbesの解説記事では、このプログラムが生まれた背景として「82%の組織が独自のAIソリューションを構築しており、うち58%がKubernetesを利用している」という調査結果を挙げ、プラットフォーム間の互換性不足がベンダーロックインのリスクを高めていたと指摘しています。認証を受けたプラットフォーム間であれば、あるKubernetes環境で動作確認したAIアプリケーションが、別の認証環境でも同じように動作することが期待できるわけです。
プログラムの要件も年々厳格化しています。Cloud Native Nowの報道によれば、2026年のKubeCon Europeでは認証基準「Kubernetes AI Requirements（KAR）v1.35」が発表され、先述のIn-Place Pod Resizeの安定版対応とWorkload-Aware Schedulingが必須要件に追加されました。同時にOVHcloud、SpectroCloud、JD Cloud、China Unicom Cloudなど新プラットフォームが認証を取得し、認証プラットフォーム数は31まで増加しています。CNCFのJonathan Bryce氏は「AI推論ワークロードは近い将来、Kubernetesクラスタ上で動く他のあらゆるワークロードクラスを圧倒するようになるだろう」と述べており、詳細な要件定義はGitHub上のリポジトリで公開が進んでいます。
つまりCNCFが目指しているのは、「推論ワークロードが急増しても、環境を選ばず一貫した挙動で動かせる」という状態です。この方向性は、そのままマネージドKubernetesを選ぶ際の判断基準にもなります。
マネージドK3s環境は推論時代のインフラ要件にどう向き合うべきか
ここまで見てきた変化を整理すると、推論時代のインフラに求められる条件は大きく3つに集約できます。1つ目は、GPU使用率や推論レイテンシといったAI固有の指標に基づくオートスケーリング。2つ目は、アクセラレータのメトリクスを標準化された形で可視化する可観測性。3つ目は、特定のクラウドやディストリビューションに縛られない可搬性、つまりベンダーロックインの回避です。
この3条件は、EKSやAKSのようなフルマネージドサービスを単体で使う場合、コストとロックインのトレードオフに悩まされやすい領域です。K3sベースのマネージドKubernetesであるKuboは、標準準拠のPure Kubernetesを採用しているためCNCFが目指す「環境間の一貫性」と相性がよく、Prometheus+Grafana標準搭載により、アクセラレータのメトリクス可視化もそのまま土台にできます。
推論ワークロードの多くはAIエージェントやMLOpsパイプラインの一部として動いています。こうした自律的なワークロードの運用まで見据えるなら、Kuboの上でCaptain.AIのようなAIエージェント実行基盤を組み合わせる構成も選択肢になります。GitOps対応やHelmチャート対応が標準搭載のため、推論サービスのデプロイパイプラインを一から構築し直す必要もありません。
まとめ
AI計算需要は「学習中心」から「推論中心」へと逆転しつつあり、2030年には推論の計算能力が学習を大きく上回るという予測が複数の調査機関から示されています。Kubernetesはこの変化に対応するため、In-Place Pod ResizeやDynamic Resource Allocationといった推論特化の機能を取り込みながら、CNCFのAI Conformance Programを通じて「どの環境でも同じように動く」標準化を進めています。
この流れを踏まえると、これからのクラスタ設計に必要なのは、推論特有のメトリクスに基づくオートスケーリング、可観測性、そして特定ベンダーに縛られない可搬性の3点です。堅牢なインフラを一から構築する余力がない企業にとって、K3sベースで標準準拠、かつコスト効率に優れたKuboは、推論時代のワークロードを支える基盤として現実的な選択肢になるはずです。まずはお問い合わせから、自社の推論インフラの現状を整理してみてはいかがでしょうか。