数千台規模のクラウドKubernetesクラスタでAI/ML基盤を運用し、GPU予算が前年から急増している情報システム部門のインフラ担当にとって、稼働率の実態は投資判断そのものを左右する数字になる。予算要求の起点になるのはGPU（画像処理用の演算装置で、AI学習・推論に多用される）の追加確保だが、既存基盤の稼働率を測らないまま増額を通す例は珍しくない。Cast AIが2026年4月に公表した「2026 State of Kubernetes Optimization Report」は、AWS・Google Cloud・Microsoft Azure上で稼働する数万規模のKubernetesクラスタを分析し、GPU使用率が平均5%にとどまると報告した。ただしこの数値は「最適化を適用する前のクラスタ」を母集団としたもので、かつ最適化製品を販売する同社自身の集計である点は差し引いて読む必要がある[1]。
CPU使用率は8%、メモリ使用率は20%で、いずれも2024年から悪化している[3]。生成AI関連のワークロードが増え、GPU単価そのものも上昇局面にある今、稼働率を測らないままの増額稟議は説得力を欠く。この記事は、GPU予算を増やす前に可視化投資を優先すべき根拠を、レポートの数字から示す。
予備知識
- Kubernetes: 複数のサーバーにまたがるコンテナの配置とスケーリングを自動化する基盤ソフトウェア。
- GPU使用率: 確保したGPUの計算能力のうち、実際の処理に使われた割合。
- オートスケーラー: 負荷に応じてノードやPod数を自動的に増減させる仕組み。Kubernetesの標準実装は実使用量ではなくリクエスト値（要求した割当量）を基準に動く。
- ライトサイジング: 実際の使用量に合わせてCPU・メモリ・GPUの割り当てを見直す作業。
オートスケーラーやリソース要求値の仕組みを基礎から確認し、可視化施策を設計したい担当者向け。
GPU使用率5%が示すKubernetes基盤の過剰プロビジョニング実態
GPU使用率とは、確保したGPUの計算能力のうち実際の処理に使われた割合を指す。Cast AIのレポートは、AWS（EKS）・Google Cloud（GKE）・Microsoft Azure（AKS）上の数万規模のKubernetesクラスタを分析し、GPU使用率の平均が5%にとどまると報告した[5]。クラウド別ではAKSが2%、EKSが5%、GKEが6%で、いずれも一桁台にとどまる[4]。この内訳はプレスリリースには含まれず、レポート本体（登録制）に記載されているものだ。
言い換えると、確保したGPU容量の95%が常時遊休状態にある[1][2]。Cast AI共同創業者のLaurent Gil氏は「GPUが1時間遊んでいるコストはドル単位だが、CPUのそれはセント単位だ。GPU容量の95%が何もしていない。（中略）これは設定の問題ではなく、経営上の緊急事態だ」と述べている[1][2]。
組織は実際の使用量の約20倍のGPU容量を確保している計算になる[2]。GPU予算を積み増す前に、この乖離を可視化できているかどうかが最初の分岐点になる。
GPU予算の増額と可視化投資のどちらを優先するか、組織的な意思決定プロセスから整理したい人向け。
CPUとメモリでも進む効率低下——2024年からの悪化トレンド
CPU・メモリの使用率とは、確保したリソースに対する実際の消費量の割合で、Kubernetesクラスタ全体で見るとGPUと同様に低い水準にとどまる。Cast AIの調査では、CPU使用率は2024年の10%から2025年は8%へ、メモリ使用率は23%から20%へ、いずれも低下した[3]。過剰配分率で見ると、CPUは2024年の40%から2025年は69%に拡大し、メモリは79%に達している[3]。
| 指標 | 2024年 | 2025年 |
|---|---|---|
| CPU使用率 | 10% | 8% |
| メモリ使用率 | 23% | 20% |
| CPU過剰配分率 | 40% | 69% |
背景には、リソース要求値を一度設定すると見直されない運用がある。Cast AIは、共有マニフェストを経由して同じ設定値が複数のワークロードに伝播する点と、クラスタのオートスケーラーが実使用量ではなく設定上のリクエスト値を基準に動作する点を要因として挙げている[3]。ワークロードや通信量は変化するため、半年前の設定は実態に合わなくなる[3]。
一度きりの設定見直しでは対応できず、継続的な棚卸しが要ると、レポートは指摘している[3]。四半期ごとの点検を制度化しなければ、次に測定するまでの間に乖離は再び広がる。
2026年7月15日（太平洋夏時間、日本時間では16日早朝）、Google Cloud（グーグルが提供するクラウド基盤サービス）のオランダ拠点で電源網の異常が発生し、冷却設備の停止を経て、europe-west4-a（オランダに置かれたア[…]
オートスケーラーとライトサイジングが機能しない構造的原因
オートスケーラーとは負荷に応じてノードやPod数を自動的に増減させる仕組みで、Kubernetesの標準実装は実使用量ではなくリクエスト値を基準に判断する。この基準のずれが、使用率が低くても課金対象のリソースが減らない理由になる。
オートスケーラーはPodのリクエスト値の合計を見てノード数を確保するため、リクエスト値が実態より大きければ、実使用量が低くてもノードは増えたまま残る[3]。ライトサイジングは、実際の使用量に合わせてリクエスト値を見直す作業を指す。
Cast AIは、自社プラットフォームを使う組織が確保CPUフットプリントを平均で約50%削減したと報告している[3]。この差は、削減余地がリクエスト値と使用実態の乖離としてすでに存在していたことを示す。
可視化ツールへの投資は、この乖離を数字として提示する役割を持つ。使用率と課金額を並べて示せれば、増額と削減のどちらを稟議に載せるべきか判断できる。GPU予算の増額を検討する前に、既存クラスタの使用率を確認できる体制があるかどうかが判断の起点になる。
数千人規模の従業員を抱え、基幹業務システムにRDS for MySQL（Amazonが管理するリレーショナルデータベースサービス）を使い、四半期ごとに内部監査を受けている企業のDB運用担当者は、2026年8月以降、毎月の請求書に見慣れない[…]
稟議とSIer保守契約がKubernetesの棚卸しを遅らせる日本企業の事情
日本企業でも同じ過剰プロビジョニングは起きるが、可視化から是正に進む経路が違うため、実質的な着手はさらに遅れやすい。クラウドコストのガバナンス体制とFinOps（クラウド費用を組織的に管理する運用の考え方）の成熟度が業種を問わず追いついていない状況は、海外企業と共通する。
日本企業に特有の事情は主に5点ある。
- クラスタの構成情報や課金明細をSIerの保守契約側が保有している場合が多く、使用率の棚卸しにも照会と回答待ちが挟まる。
- リソース見直しの実施には稟議による承認が要り、年度予算のサイクルに縛られる。
- 内部統制の監査では変更管理の記録が重視されるため、過剰配分そのものは指摘対象になりにくい――というのが筆者が実務で見てきた範囲での実感だ。
- オートスケーラー設定を継続的に見直せる専任人材を持つ企業は限られる。
- 稼働年数の長いシステムほどリクエスト値の根拠が引き継がれておらず、誰が何を基準に設定したのか分からないまま数年単位で放置されている例を、筆者は複数見ている。
| 論点 | 一般的な想定 | 日本企業で起きること |
|---|---|---|
| 使用率の把握 | 社内で即時に可視化 | SIerへの照会と回答待ちが発生 |
| リソース見直し | 担当者の裁量で実施 | 保守契約の範囲外作業として見積が要る |
| 監査での扱い | 効率も評価対象 | 変更管理の記録が優先され効率は見落とされがち |
IT部門の次の一手は、GPU予算を増額する稟議より先に、既存クラスタの使用率を可視化する稟議を通すことである。決裁側の判断材料は、可視化投資の費用がGPU増強予算のごく一部の規模で済む点にある。
まとめ
Cast AIの2026年レポートは、GPU使用率5%、CPU使用率8%、メモリ使用率20%という数字で、Kubernetes基盤の過剰プロビジョニングを裏付けた[1][3]。AI予算が増える局面ほど、この乖離を放置するコストは大きくなる。
IT担当の次の一手は、GPU予算の増額稟議より先に、既存クラスタの使用率を可視化する稟議を通すことである。クラウド別のGPU使用率やCPU・メモリの過剰配分率を数字で示せれば、稟議の説得力は上がる[1][3]。
決裁側の判断材料は、可視化投資がGPU増強予算のごく一部の規模で済む点と、後回しにすれば来期も同じ議論を繰り返す点にある。使用率を測らないままの増額は、根拠のない投資になる。
よくある質問（FAQ）
Q. GPUの使用率が低いとどんな問題があるのか。
確保したGPUの大半が遊休のまま課金され続ける。Cast AIの分析では平均使用率が5%にとどまり、確保容量の95%が常時使われていない状態にある[1][2]。
Q. Kubernetesのオートスケーラーは使用率を見て動かないのか。
標準的な実装は実使用量ではなくPodのリクエスト値を基準に動く。リクエスト値が実態より大きいまま放置されると、使用率が低くてもノード数は減らない[3]。
Q. 可視化ツールを導入すればGPUコストはどれくらい下がるのか。
Cast AIは自社プラットフォームを使う組織で確保CPUフットプリントが平均約50%減ったと報告している[3]。削減幅は環境によって異なるが、まず現状の使用率を数字で把握することが出発点になる。
