2026年3月、アムステルダムで開催されたKubeCon EU 2026は、Kubernetesの歴史における決定的な転換点となった。NVIDIAによるGPU DRAドライバーのCNCF寄贈、KAI SchedulerのCNCF Sandbox昇格、そしてScaleOpsの1億3,000万ドル（約195億円）Series C調達──これら3つの事象が同時期に発生したことは偶然ではない。MicrosoftがKubernetesを「AI Infrastructure OS」と宣言した背景には、GPU運用効率が平均20〜30%に留まるエンタープライズの構造的課題がある。Kubernetes 1.34で正式版（GA）に到達したDynamic Resource Allocation（DRA）を基盤に、GPU運用効率を70〜80%まで引き上げる技術スタックが2026年に初めて完成した。本稿はテクノロジーの視点から、この構造転換の技術仕様・実装設計・経済的インパクトを分析する。

DRA GA到達の技術的意味 ── CPUメモリ中心設計の終焉

Dynamic Resource Allocation（DRA）は、Kubernetes 1.26（2023年）でアルファとして導入され、1.32でベータに昇格、そして2025年8月のKubernetes 1.34で正式版（GA）に到達した。この3年間の進化は、Kubernetesのリソース管理モデルを根本から書き換えるものである。

従来のKubernetesリソースモデルは、CPUとメモリという2つの汎用リソースを前提に設計されていた。GPUはnvidia.com/gpu: 1のようなExtended Resourcesとして扱われ、「整数個の割り当て」しかできなかった。A100 80GBのGPUを推論ワークロードに割り当てても、実際のVRAM使用量が8GBであれば、残りの72GBは他のワークロードから利用できない。この「整数問題」が、エンタープライズGPU運用効率を20〜30%に留めてきた最大の構造的要因である。

DRA GAでは、resource.k8s.ioグループのAPIが安定版v1に昇格し、破壊的変更が入らないことが保証された。これにより、プロダクション環境での採用障壁が大幅に低下した。主要な技術的進化は以下の通りである。

ResourceClaimの宣言的リソース要求：ポッドが必要とするGPUの属性（メモリ容量、コンピュート能力、NVLinkトポロジー）を宣言的に記述し、スケジューラがクラスタ内の最適なデバイスを自動選択する。従来の「GPU 1個ください」から「VRAM 16GB以上、FP16演算性能200TFLOPS以上のGPU」という属性ベースの要求に変わった。

Prioritized List（1.34でベータ）：複数の許容デバイスタイプを優先順位付きで指定できる。例えば「H100が利用可能ならH100、なければA100、それもなければL40S」という柔軟なフォールバック戦略をマニフェスト内で定義できる。

Consumable Capacity（1.34でアルファ）：1つのGPUデバイスを複数ポッドで共有する柔軟なモデル。NVIDIAのMulti-Instance GPU（MIG）やMulti-Process Service（MPS）と連携し、GPU VRAM・コンピュートユニットを分割して複数のワークロードに割り当てる。

Resource Health Status（1.34でアルファ）：デバイスの健全性情報をPod Statusに公開する。GPUのECCエラー、温度異常、メモリ劣化をKubernetesネイティブに検知し、障害ノードからのワークロード退避を自動化できる。

筆者は大規模インフラの無停止運用に携わった経験から、「止められない」制約下での機器リプレースの難しさを身をもって知っている。DRAのResource Health Statusは、まさにこの運用課題に対するKubernetesネイティブな回答であり、GPU障害の予兆検知から自動退避までをオーケストレーション層で完結させる設計思想に技術的な合理性を感じる。

NVIDIA GPU DRAドライバー寄贈 ── ベンダーロックイン解体の転換点

2026年3月24日、KubeCon EU 2026の基調講演でNVIDIAが発表した「GPU DRAドライバーのCNCF寄贈」は、GPU管理のガバナンスモデルを根本から変える決定である。従来、NVIDIAのGPU Operatorとdevice pluginはNVIDIA単独のガバナンス下にあり、Kubernetes本体のリリースサイクルと独立して開発されていた。これがCNCFに移管されることで、AWS、Google Cloud、Microsoft、Red Hat、SUSEなど主要プレイヤーがコードベースに直接コントリビュートできるようになった。

寄贈されたDRAドライバーの技術的特徴は3つある。第一に、MIG/MPS対応のリソース共有。1つのH100をMIGで最大7パーティションに分割し、各パーティションを独立したResourceClaimとして管理できる。第二に、マルチノードNVLink対応。Grace Blackwell GB200 NVL72のような大規模AIモデル訓練向けシステムで、ノード間のGPU相互接続トポロジーをDRAレベルで認識し、最適なポッド配置を実現する。第三に、動的ハードウェア再構成。ワークロードの変化に応じてMIGパーティションのサイズを動的に変更し、推論時は小パーティション多数、訓練時は大パーティション少数という運用を自動化できる。

この寄贈と同時に、NVIDIA KAI SchedulerがCNCF Sandbox projectに採択された。KAI Schedulerは、DRAドライバーの上位層として動作し、以下の機能を提供する。

  • フラクショナルGPU割り当て：MPSメモリパーティショニングまたはタイムスライシングにより、GPU 0.5個や0.25個といった分数指定が可能
  • 階層型キューイング：チーム・プロジェクト単位でGPUクォータを設定し、組織全体のGPUリソースを公平に分配
  • ギャングスケジューリング：分散訓練ジョブで必要な全GPUが同時に確保できるまで実行を保留し、部分起動による無駄を防止

KubeCon EU 2026では、Google CloudもTPU向けDRAドライバーをオープンソース公開した。これにより、DRAは事実上のアクセラレータ管理標準APIとなり、GPU（NVIDIA）、TPU（Google）、Trainium（AWS）という主要AIアクセラレータがすべてDRA経由で管理される時代が到来した。NVIDIAのDRAドライバー寄贈の詳細な経済分析については別稿で詳しく論じている。

ScaleOps 1.3億ドル調達が示すGPU最適化市場の爆発

2026年3月30日、イスラエル発のKubernetesリソース最適化企業ScaleOpsが、Insight Partners主導で1億3,000万ドル（約195億円）のSeries Cラウンドを完了した。評価額は8億ドル超。前回のSeries B（2024年11月、5,800万ドル）からわずか16ヶ月での大型調達であり、年間成長率450%超という爆発的成長が背景にある。

ScaleOpsの技術的な差別化要因は、CPU・メモリ・GPUの3軸同時最適化をリアルタイムで自動実行する点にある。従来のKubernetesリソース管理は、Vertical Pod Autoscaler（VPA）やHorizontal Pod Autoscaler（HPA）による個別最適化が主流だった。しかし、GPU搭載ノードではCPU・メモリ・GPUの3リソースが相互依存しており、GPUだけを最適化してもCPUがボトルネックになればGPU利用率は上がらない。ScaleOpsはこの3軸を同時に監視・最適化し、人間の介入なしにリソース割り当てを動的に調整する。

公開されているケーススタディから、具体的な効果を確認できる。

導入企業ワークロード導入前GPU利用率導入後GPU利用率コスト削減
クリエイティブソフトウェア企業数千台規模のGPUクラスタ20%非公開（大幅改善）GPU支出50%以上削減、レイテンシ35%改善
グローバルゲーム企業数百台GPU上の動的LLMベースライン7倍向上年間140万ドル削減（単一ワークロード）
セルフホストLLM本番環境推論サービング20〜30%70〜80%インフラ支出50〜70%削減

注目すべきは、ScaleOps共同創業者のYodar Shafrir氏がRun:ai（2024年にNVIDIAが買収）の元エンジニアである点だ。Run:aiのGPUオーケストレーション技術がNVIDIAに吸収された後、その知見がScaleOpsというオープンなKubernetesエコシステム側のソリューションとして再結実している構図は、GPU管理のイノベーションがベンダー独占からコミュニティ駆動へ移行する大きな潮流を象徴している。

ScaleOpsの顧客にはAdobe、Wiz、DocuSign、Salesforce、Coupaといったエンタープライズが名を連ねる。AIエージェントROI測定の構造的ギャップが指摘されるなか、GPU運用効率の定量的改善はROI可視化の最も直接的な手段であり、ScaleOpsへの資金集中はこの文脈で理解すべきである。

GPU運用3層スタック ── Operator・DRA・KAI Schedulerの実装設計

KubeCon EU 2026で確立されたGPU管理の標準アーキテクチャは、3層構造で理解できる。

第1層：GPU Operator（ライフサイクル管理）

GPU Operatorは、ノード上のGPUドライバー、CUDAランタイム、デバイスプラグインのインストール・更新・監視を自動化するOperatorパターンの実装である。ノードが追加されると自動的にGPUソフトウェアスタックをプロビジョニングし、ドライバー更新時のローリングアップデートを管理する。2026年現在、GPU Operatorはv24.9.0以降でKata Containers連携に対応し、機密コンピューティング環境でのGPU利用を可能にしている。

第2層：DRAドライバー（リソース抽象化）

DRAドライバーは、物理GPUデバイスをKubernetesのリソースモデルにマッピングする翻訳層である。MIG/MPSによるGPU分割、属性ベースのデバイス選択、NVLinkトポロジー認識をResourceClaim APIとして公開する。CNCFに寄贈されたことで、ベンダー中立なAPIとして進化していく。

第3層：KAI Scheduler（ワークロード最適化）

KAI Schedulerは、DRAが公開するリソース情報を基に、AIワークロード固有のスケジューリングロジックを実装する。フラクショナルGPU、ギャングスケジューリング、階層型キューイングはこの層で処理される。

実装例として、推論サービスのデプロイメントを示す。

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: inference-gpu-claim
spec:
  spec:
    devices:
      requests:
      - name: gpu
        deviceClassName: gpu.nvidia.com
        selectors:
        - cel:
            expression: "device.attributes['gpu.nvidia.com'].memory >= 16Gi"
      - name: gpu-fallback
        deviceClassName: gpu.nvidia.com
        selectors:
        - cel:
            expression: "device.attributes['gpu.nvidia.com'].memory >= 8Gi"
        allocationMode: ExactCount
        count: 2

このマニフェストは、16GB以上のVRAMを持つGPU 1基を優先的に要求し、利用不可の場合は8GB以上のGPU 2基にフォールバックする。従来のExtended Resourcesでは不可能だった属性ベースの柔軟な要求定義が、DRA GAで標準機能として利用できるようになった。

Kata Containers統合とベアメタル自動化 ── AIインフラの残された課題

GPU運用効率化の議論では、コンテナオーケストレーション層のみに注目が集まりがちだが、実際のエンタープライズ導入ではセキュリティ分離と物理インフラ管理の2つの課題が残っている。

Kata ContainersによるGPU機密コンピューティング

Kata Containersは、軽量仮想マシン（Utility VM）内でコンテナを実行し、ホストカーネルからのワークロード分離を実現するCNCFプロジェクトである。KubeCon EU 2026では、NVIDIAとCNCF Confidential Containersコミュニティの協業により、GPU Operator経由でKata Containers内からGPUアクセラレーションを利用する機能が発表された。

これにより、以下のユースケースが実現可能になった。

  • マルチテナント環境での推論ワークロード分離：異なる顧客のモデルが同一ノード上のGPUを共有しつつ、メモリ空間を完全に分離
  • 規制産業（医療・金融）でのAI推論：HIPAA/PCI-DSSコンプライアンス要件を満たすGPU処理
  • 学習データの機密性保護：連合学習やプライベートデータでのファインチューニング時、データがホストOSから隔離される

ベアメタルライフサイクル自動化

クラウドGPUインスタンスの価格上昇（AWSは2026年初頭にGPUインスタンス価格を約15%引き上げた）に伴い、オンプレミス・コロケーションでのGPUクラスタ構築需要が急増している。しかし、ベアメタルサーバーのプロビジョニングはクラウドのAPI呼び出しほど簡単ではない。

CNCFエコシステムでは、Tinkerbell（ベアメタルプロビジョニングエンジン）とMetal3（Cluster APIプロバイダー）が成熟し、ベアメタルGPUサーバーの宣言的管理が可能になっている。TinkerbellのHookOS（インメモリOS）でサーバーをPXEブートし、Cluster API経由でKubernetesクラスタに自動参加させ、GPU Operatorがドライバーを自動インストールする──この一連のフローが、GitOpsワークフローとして定義・再現可能になった。

AWSはEKS Anywhereを通じてTinkerbellをオンプレミスKubernetesのプロビジョニング基盤として採用しており、単一クラスタで最大10万ワーカーノード（約160万Trainiumアクセラレータ、約80万NVIDIA GPU相当）の管理を実証している。この規模は、GPU管理が「クラウドかオンプレミスか」の二項対立ではなく、統一されたKubernetes API層で両方を管理するハイブリッドモデルへ収束していることを示している。

「GPU運用13%→80%」の経済学 ── 1,000台クラスタの試算

GPU運用効率の改善がもたらす経済的インパクトを、1,000台のH100クラスタを想定して試算する。

項目従来（DRA以前）DRA GA + KAI + ScaleOps
平均GPU利用率20〜30%70〜80%
実効GPU処理能力200〜300台分700〜800台分
同等処理に必要な実GPU数1,000台300〜400台
月額インフラコスト（クラウド）約330万ドル約100〜130万ドル
年間コスト削減額─約2,400〜2,760万ドル
消費電力（TDP基準）700kW210〜280kW

この試算は単純化したものだが、GPU利用率を3〜4倍に改善することで、インフラコストが60〜70%削減される構造は明確である。ScaleOpsの実績値（GPU支出50%以上削減、年間140万ドル削減）は、この試算と整合的である。

さらに重要なのは、GPUの調達リードタイムが依然として長期（高性能GPU は数ヶ月〜1年待ち）であることだ。新規GPU調達を待つよりも、既存GPUの利用効率を最適化する方が即座にROIを実現できる。筆者はフルスタックエンジニアとしてさまざまな技術選定に関わってきたが、あらゆる技術を横断してきたからこそ言えるのは、「買い増す前にまず既存資産を使い切る」というのは技術投資の鉄則であるということだ。DRA GA + KAI Scheduler + ScaleOpsの組み合わせは、この鉄則をGPUインフラの領域で実装可能にした初めてのスタックといえる。

2026年後半の展望 ── Kubernetes as AI Infrastructure OSの確立

KubeCon EU 2026で明確になったのは、Kubernetesが「コンテナオーケストレーター」から「AIインフラストラクチャOS」へと進化したという事実である。MicrosoftはKubernetesを「AI Infrastructure OS」と明確に宣言し、AWS、Google Cloud、NVIDIAがGPU管理のコアコンポーネントをCNCFに寄贈・統合した。

2026年後半に向けて、以下の技術的進展が予想される。

NVIDIA Grove（推論ワークロードAPI）のエコシステム拡大：KubeCon EU 2026で発表されたGroveは、マルチノードAI推論ワークロードをKubernetes APIとして宣言的に定義するオープンソースプロジェクトである。PodCliques、PodCliqueScalingGroups、PodCliquesSetという階層型カスタムリソースにより、prefillワーカー・decodeリーダー・フロントエンドサービスを単一のマニフェストで定義できる。llm-d推論スタックとの統合が進めば、GPT-5.4のような大規模モデルの推論基盤をKubernetesネイティブに構築する標準パターンが確立される。

DRAエコシステムのマルチアクセラレータ対応：Google CloudのTPU向けDRAドライバー公開に続き、AWSのTrainium/Inferentia向けDRAドライバー、AMDのInstinct MI向けDRAドライバーの登場が見込まれる。DRA APIが事実上の「アクセラレータ管理標準」として確立されれば、ワークロード定義をアクセラレータ非依存にしたまま、コスト・性能に応じて最適なハードウェアを動的に選択する時代が到来する。

GPU機密コンピューティングの産業化：Kata Containers + GPU Operatorの組み合わせにより、規制産業でのGPU活用が加速する。特に医療AI（HIPAA）、金融AI（PCI-DSS/SOX）の領域で、オンプレミスGPUクラスタをKubernetesで統合管理しつつ、ワークロード間の暗号学的分離を実現するアーキテクチャが標準化されると予想される。

NVSentinelによるGPU障害自動修復：KubeCon EU 2026で発表されたNVSentinelは、GPUの障害検知・診断・修復を自動化するシステムである。DRAのResource Health Status APIと連携し、ECCエラーの蓄積やメモリ劣化を検知した時点でワークロードを自動退避させ、障害ノードをクラスタから隔離する。1,000台以上のGPUクラスタでは、統計的にGPU障害は日常的に発生するため、この自動化は運用コストに直結する。

FAQ

DRA（Dynamic Resource Allocation）とは何か？従来のdevice pluginとどう違うのか？

DRAはKubernetes 1.34でGA（正式版）になったリソース管理APIである。従来のdevice pluginがGPUを整数個でしか割り当てられなかったのに対し、DRAはGPUのVRAM容量・コンピュート性能・NVLinkトポロジーなどの属性に基づく柔軟な要求定義と、MIG/MPSによる分数割り当てを標準APIとして提供する。

NVIDIA KAI SchedulerはデフォルトのKubernetesスケジューラを置き換えるのか？

KAI Schedulerはデフォルトスケジューラの「置き換え」ではなく、AIワークロード専用の拡張スケジューラとして動作する。DRAドライバーが公開するGPU情報を活用し、フラクショナルGPU、ギャングスケジューリング、階層型キューイングなどAI固有の最適化を追加する。通常のCPU/メモリワークロードはデフォルトスケジューラが処理する。

ScaleOpsのようなGPU最適化ツールは自社開発で代替できるか？

技術的には可能だが、推奨しない。GPU利用率の最適化は、ワークロードパターンの継続的モニタリング、リソース要求の動的調整、ノードのbin-packing最適化を同時に実行する必要がある。ScaleOpsの450%成長と大手企業の採用実績は、この領域の専門ツールへの需要が高まっていることを示している。自社開発よりも、DRA + KAI Scheduler（OSS）+ ScaleOps（商用）の組み合わせが現時点での最適解である。

オンプレミスGPUクラスタとクラウドGPU、どちらが有利か？

2026年のAWSのGPUインスタンス価格引き上げ（約15%）を考慮すると、年間を通じて高稼働率が見込まれるワークロードではオンプレミスが有利になりつつある。ただし、ベアメタルプロビジョニング（Tinkerbell/Metal3）、GPU Operator、DRA、KAI Schedulerの運用スタック全体を管理できるチームが前提である。バースト的なワークロードにはクラウドGPU、定常ワークロードにはオンプレミスというハイブリッドモデルが最も経済合理的である。

GPU機密コンピューティング（Kata Containers + GPU）は本番環境で使えるか？

NVIDIA GPU Operator v24.9.0以降でKata Containers連携が公式にサポートされており、本番利用は可能である。ただし、軽量VM層によるオーバーヘッド（起動時間の増加、メモリフットプリントの増大）がある。推論ワークロードのレイテンシ要件が厳しい場合は、ベンチマークで性能影響を確認すべきである。規制コンプライアンスが必須の環境では、このオーバーヘッドはセキュリティ要件とのトレードオフとして許容される。

参考文献