テクノロジーの視点から分析する。2026年1月、CNCFが発表した2025年版クラウドネイティブ調査は、Kubernetesがもはやコンテナオーケストレーションの域を超え、AIインフラの「デファクトOS」として確立されたことを数値で裏付けた。本番環境での採用率82%、AI推論ワークロードの66%がKubernetes上で稼働するという事実は、GPU時代のインフラ基盤がどこに収斂しつつあるかを明確に示している。

一方で、最大の課題として浮上したのは技術的な制約ではない。「開発文化の変革」が47%で首位 ── 組織が技術に追いついていないという構造的課題である。本稿ではCNCF調査データを軸に、KubernetesがAIインフラの中核に据わった技術的背景と、その先にある組織的転換点を解説する。

本番環境82%の意味 ── コンテナからAI基盤へ

CNCFの2025年版調査によれば、コンテナユーザーの82%がKubernetesを本番環境で運用している。2023年の66%から16ポイントの上昇であり、もはや「試験的に導入している」フェーズは過ぎた。回答組織の98%がクラウドネイティブ技術を採用済みであり、59%が開発・デプロイの「大部分」または「ほぼ全て」をクラウドネイティブに移行したと報告している。

注目すべきは、この数字が単なるWebアプリケーションの運用基盤としてのKubernetesではなく、AIワークロードの基盤としての数値を含んでいる点である。生成AIモデルをホスティングする組織の66%がKubernetesを使用して推論ワークロードの一部または全部を管理している。ただし、AIモデルのデプロイ頻度はまだ保守的で、日次デプロイは7%にとどまり、47%が「不定期にデプロイ」と回答している。50%超の組織が自前でモデルを訓練していない ── つまり事前学習済みモデルの運用に集中している。

筆者は以前、全国規模のインフラサービスで「止められない」という制約が技術判断の全てを支配する環境を経験した。KubernetesがAI推論の基盤として選ばれる理由も本質は同じである。GPUリソースは高価であり、ダウンタイムの許容幅は極めて狭い。自己修復機能、ローリングアップデート、ヘルスチェックといったKubernetesの基本機能が、AI推論の本番運用で最も価値を発揮する局面に入った。

DRA GA化とGPUプール化 ── ハードウェア抽象化の完成形

KubernetesがAIインフラとして機能するための技術的基盤が、2025年に大きく成熟した。最大のマイルストーンは、Kubernetes v1.34（2025年9月）でDynamic Resource Allocation（DRA）がGA（General Availability）に到達したことである。

DRAは、GPU・FPGA・特殊NICといった非CPUリソースのジャストインタイムな選択・割り当て・共有を実現するAPIである。従来のDevice Pluginでは1つのPodが1つのGPUを排他的に占有するモデルだったが、DRAでは以下が可能になった。

  • 複数Podでのデバイス共有: 消費可能容量（Consumable Capacity）のトラッキングにより、物理GPUを複数Podで効率的に分割
  • 優先リスト: 「高性能GPU 1基 or 中性能GPU 2基」といった柔軟なリクエスト記述
  • 管理者アクセスラベリング: namespace単位でデバイスへのアクセス権を制御
  • デバイスのTaintとToleration（v1.33でアルファ）: ノードと同様のTaint機構をGPUレベルで適用

v1.33（2025年5月）で導入されたPartitionable Devicesもアルファ段階だが重要だ。ドライバーが重複する論理デバイスを公告できるため、MIG（Multi-Instance GPU）的なパーティショニングがKubernetesネイティブに管理可能になる。

NVIDIA GPU OperatorもCDI（Container Device Interface）をデフォルトに切り替え、ベンダー固有の実装から標準化されたインターフェースへ移行した。これにより、マルチベンダーGPU環境 ── NVIDIA・AMD・Intelが混在するクラスター ── でも統一的なリソース管理が現実になりつつある。

推論スタックの標準化 ── 「クラウドネイティブ四重奏」

GPU管理の標準化と並行して、LLM推論のソフトウェアスタック自体もKubernetes上で標準化が進んでいる。コミュニティで「クラウドネイティブ四重奏」と呼ばれる構成が事実上の標準として浮上した。

KServe（コントロールプレーン）はCRD（Custom Resource Definition）を通じてモデルのライフサイクル管理、弾力的スケーリング、トラフィックガバナンスを統合する。vLLM（実行エンジン）はPagedAttentionによるメモリ効率化と連続バッチ処理で、GPU利用率を最大化する。llm-d（スケジューリング層）は複数vLLMインスタンスのキャッシュアウェアなルーティングとprefill/decodeの分離を担当する。そしてWG Serving（標準化層）がGateway Inference Extension（GIE）を通じて、HTTPサービスにおけるIngressと同等の役割をAI推論に提供する。

この四層構造の意味は大きい。Envoy + GIE → KServe → llm-d → vLLMという流れにより、LLMの展開がWebサービスのデプロイと同じ操作体系で行える。OpenAI互換APIが各層で統一されているため、モデルの差し替えも標準化されたインターフェース上で完結する。

さらに、トポロジーアウェアスケジューリングの進化も見逃せない。NVLink接続のGPU間は600GB/sで通信できるが、PCIe経由では32GB/sに制限される。KueueのトポロジーアウェアスケジューリングやNVIDIA KAI Scheduler v0.10.0（2025年10月）は、この物理的なトポロジーを考慮したPod配置を実現し、分散推論の性能を最大30%改善する。

最大の壁は47% ── 「開発文化の変革」という組織問題

技術基盤は整った。ではなぜ、CNCFは調査報告で「組織文化が決定的要因として残っている」と強調したのか。2025年の調査で初めて、クラウドネイティブ採用の最大の課題として「開発チームの文化的変革」が47%で首位に立った。以下、「トレーニング不足」36%、「セキュリティ上の懸念」36%、「複雑性」34%と続く。

過去のCNCF調査では、技術的な複雑性やセキュリティが常に上位を占めていた。文化が首位になったという事実は、インフラの技術的成熟を反映している。Kubernetesの問題は解決された ── 問題は、それを使いこなす組織側にある。

筆者は150人月規模の大規模システム開発で、コードの品質よりもコミュニケーション設計が成否を分けることを体感した。Kubernetesの文化的課題もまったく同じ構造である。宣言的なマニフェスト管理、GitOps、IaC（Infrastructure as Code）、オブザーバビリティ ── これらはいずれも技術ではなく、チームの働き方そのものの変革を要求する。「kubectl applyを覚える」だけではKubernetesは使いこなせない。開発とインフラの境界を溶解させるDevOps文化の定着が前提条件になる。

特にAIワークロードでは、データサイエンティスト、MLエンジニア、インフラエンジニアの三者がKubernetesという共通言語で協働する必要がある。Jupyter Notebookで実験したモデルをKubeflow TrainerでKubernetes上の分散学習に変換し、KServe + vLLMで推論サービスとして展開する ── このパイプライン全体を一つのチームが回すには、従来のサイロ型組織では対応できない。

2026年以降の展望 ── Kubernetesはインフラの「Linux」になるか

データは明確な方向を示している。Kubernetesは既にAIインフラのデファクトスタンダードであり、Docker Swarmやクラウドプロバイダーのプロプライエタリなオーケストレーションサービスとの競争は実質的に終結した。AWSでさえ、高度なAIワークロードにはECSではなくEKS（Kubernetes on AWS）を推奨する方向に動いている。

DRAのGA化により、GPUリソースの抽象化はKubernetesネイティブで完結する。推論スタックの四層標準化により、LLM展開の操作体系はWebサービスのデプロイと同質になった。Kueue + JobSet + LeaderWorkerSetの成熟により、分散学習・推論のバッチスケジューリングもKubernetes上に集約された。

残された最大のフロンティアは「人」である。47%の組織が文化的変革を課題と認識しているということは、技術の準備完了を組織が認知しているということでもある。プラットフォームエンジニアリングチームの設置、社内のKubernetes教育プログラム、セルフサービス型の開発者ポータル構築 ── こうした施策が2026年以降のKubernetes/AI統合の成否を分ける。

筆者は10年以上の起業経験を通じ、技術的な正解を知っていても組織が動かなければ実装は頓挫するという場面を幾度も見てきた。KubernetesがAIインフラの「Linux」たり得るかは、技術の問題ではなく、組織がその変革を受け入れるかどうかにかかっている。

FAQ

KubernetesでAI推論ワークロードを動かすメリットは何か？

GPU リソースの動的割り当て（DRA）、自動スケーリング、自己修復、ローリングアップデートにより、高価なGPUの利用効率を最大化しつつ本番運用の安定性を確保できる。マルチクラウド対応とベンダー非依存性も大きな利点である。

DRA（Dynamic Resource Allocation）は従来のDevice Pluginと何が違うのか？

従来のDevice Pluginは1Pod=1GPUの排他的割り当てが基本だった。DRAではGPUの共有、優先順位付きリクエスト、namespace単位のアクセス制御が可能で、GPUリソースの柔軟で効率的な管理を実現する。

「開発文化の変革」が課題とは具体的に何を指すのか？

宣言的インフラ管理（IaC）、GitOps、DevOps/MLOps文化の定着が必要とされる。データサイエンティスト・MLエンジニア・インフラエンジニアがサイロを越えて協働する組織構造への転換が求められている。

Kubernetes以外にAI推論の選択肢はあるのか？

AWS ECSやGCP Cloud Runなどクラウド固有のサービスも利用可能だが、マルチクラウド対応やエコシステムの充実度でKubernetesが圧倒的に優位である。AWSも高度なAIワークロードにはEKS（Kubernetes）を推奨する傾向にある。

参考文献