1. 「動く」YAMLが量産される時代——でもKubernetesリソース設計は静かに壊れている
Kubernetesのマニフェストを書くハードルは、この1〜2年で劇的に下がりました。AIコーディングアシスタントに「このアプリをデプロイして」と頼めば、Deployment・Service・HorizontalPodAutoscalerのYAMLが数秒で生成され、kubectl apply -fが通ります。エラーもなく、Podは起動し、画面には緑のチェックマークが並びます。
しかし、この「動く」という結果は、Kubernetesリソース設計が「正しい」ことを意味しません。実際、Cast AIの2026年版レポートによれば、本番Kubernetesクラスタ全体のCPU過剰プロビジョニング率は前年の40%から69%へと悪化し、メモリの過剰プロビジョニング率は79%に達しています。一方で実際のCPU利用率はわずか8%、メモリ利用率も20%程度にとどまっているというデータが示されています。
つまり、申告されたリソース（request/limit）と実際に使われているリソースの間には、埋まらないどころか広がり続けるギャップがあるということです。AIが生成したマニフェストが「動く」のはスケジューラーとkubeletの視点での成功にすぎず、コストとキャパシティプランニングの観点では、むしろ問題を隠蔽しているケースが少なくありません。
この記事では、なぜAIが本番品質のKubernetesリソース設計を苦手とするのか、その技術的な理由と、実務でチェックすべきポイントを整理します。
KuboのようなマネージドK3s基盤を使っている場合でも、AIが生成したマニフェストをそのまま適用する前に、実クラスタの利用状況を可視化できるかどうかが、コストと信頼性を分ける最初の分かれ目になります。
2. なぜAIは「間違った問題」を解決してしまうのか
AIコーディングアシスタントは、文法的に正しく、スキーマにも準拠したKubernetesマニフェストを生成できます。しかし、Kubernetesの公式ドキュメントが説明しているように、requestsとlimitsにはそれぞれ異なる役割があります。requestsはkube-schedulerがPodをどのノードに配置するかを決める基準であり、limitsはkubeletが実行時にCPUスロットリングやOOM Killで強制する上限です。この2つの値をどう設定するかは、コードの文法とは別次元の「その組織固有のトラフィックパターンと余裕率の設計」です。
AIはこの文脈情報を持っていません。実際にPerfectScaleのブログでも指摘されているとおり、AI駆動のリソース最適化ツールはメトリクスの解釈を誤ると不適切なスケーリング判断を下し、パフォーマンス低下やコスト増加につながるリスクがあります。加えて、AIの意思決定プロセスが不透明であるために、後から「なぜこの値になったのか」を監査しづらいという問題も指摘されています。
さらに厄介なのは、limitsだけを指定してrequestsを省略した場合、Kubernetesは自動的にlimitの値をrequestとしてコピーするという仕様です。AIが「安全側」に倒して大きめのlimitを設定すると、それがそのままrequestとして扱われ、実際の使用量とは無関係にノードの空き容量を圧迫する結果になります。これは、AIが生成したYAMLが「動く」ことと「効率的である」ことの間にある典型的な落とし穴です。
3. クラスタオートスケーラーは「申告された数字」しか見ていない
過剰プロビジョニングがそのままクラウド代の無駄になる理由は、Cluster Autoscalerの仕組みそのものにあります。Kubernetes公式ドキュメントのノードオートスケーリングの解説によれば、Cluster Autoscalerはpending状態のPodが持つresource requestsを見て、既存ノードで賄えないと判断した場合に新しいノードを追加します。ここで重要なのは、「実際の使用量は直接考慮しない」という制約が明記されている点です。つまり、AIが余裕を見て大きめのrequestsを設定すればするほど、Cluster Autoscalerは律儀にノードを追加し、請求額を押し上げていきます。
同様の構造は水平方向のスケーリングにも存在します。HorizontalPodAutoscalerの公式ドキュメントでは、CPU利用率は「実際の使用量 ÷ resource request」で計算されるため、そもそもrequestsが設定されていなければCPU利用率という指標自体が定義できず、オートスケーラーは何のアクションも取れないと説明されています。AIが生成したマニフェストにrequestsが漏れている、あるいは極端に大きい値になっているだけで、HPAはサイレントに機能不全に陥るということです。
こうした「申告された数字」と「実際の需要」のズレを放置したまま運用を続けると、Kubernetes運用の中核であるはずのオートスケーリングが、コスト最適化ではなくコスト膨張の装置になってしまいます。
Kubo CloudのCaptain UIは、リソースの申告値と実利用率を並べて可視化できるダッシュボードを備えており、AIが生成したマニフェストが「本番品質」かどうかを人間が最終判断するための材料をブラックボックス化させません。
4. AIに書かせたYAMLを「本番品質のリソース設計」にする3つのチェックポイント
AIが生成したKubernetesマニフェストを本番投入する前に、最低限確認すべき3つのポイントを整理します。
チェックポイント1: メトリクスベースで検証する
ScaleOpsの解説記事では、少なくとも7日間以上のCPU・メモリ・OOM・スロットリングのデータを収集し、平均値ではなくp95やp99のパーセンタイル値をもとにrequestsを設定することが推奨されています。CPUとメモリでは扱いを分けるべきで、CPUは実測のp95/p99需要に余裕を加えた値、メモリはOOM Killを避けるためrequestとlimitをほぼ同じ水準に揃えるという方針が示されています。
日本語圏でも、Think ITで紹介されているKRR(Kubernetes Resource Recommender)のようなツールが実用段階にあります。KRRはPrometheusなどに蓄積済みのメトリクスをもとに、CPUは過去1週間の99パーセンタイル値、メモリは過去1週間の最大値に15%のバッファを加えた値を数秒で提案してくれます。AIが最初に生成した値を、こうしたメトリクスベースの推奨値と突き合わせる工程を挟むだけで、過剰/過小プロビジョニングのリスクは大きく下がります。
チェックポイント2: namespace単位の歯止めをかける
Kubernetes公式のリソースクォータ管理ドキュメントにあるとおり、ResourceQuotaはnamespace全体のリソース合計を制限し、LimitRangeは個別のPod・コンテナ単位で最小値・最大値・デフォルト値を強制します。AIが個々のマニフェストで妥当な値を書けていたとしても、チーム全体でnamespaceに歯止めがなければ、積み上がったリクエストの合計がクラスタ全体のキャパシティを圧迫します。AI生成のワークフローを導入するなら、その前提としてnamespace単位のガードレールを先に敷いておくことが実務上のセーフティネットになります。
チェックポイント3: 継続的にモニタリングする
トラフィックパターンはリリースのたびに変化するため、一度検証した値も定期的な再検証が必要です。KuboのようにPrometheus + Grafanaがモニタリング標準搭載されているマネージドK3s環境であれば、AIが生成したマニフェストを適用した後も、実利用率の推移を継続的に観測しながらrequests/limitsをチューニングし続けられます。
5. まとめ
AIコーディングアシスタントは、Kubernetesマニフェストを「文法的に正しく、動く」形で生成する能力においては既に実用段階にあります。しかし、kubectl applyが通ることと、Kubernetesリソース設計が本番品質であることは別問題です。Cast AIの2026年データが示すように、CPU過剰プロビジョニング率69%、メモリ79%という数字は、多くの組織がこの落とし穴にはまっていることを物語っています。
AIに欠けているのは、実際のトラフィックパターン・ノードの利用履歴・チーム固有の余裕率という「システム全体のコンテキスト」です。この文脈を補うのは、メトリクスベースの検証、namespace単位の歯止め、そして継続的なモニタリングという地道な運用設計であり、ここにこそインフラエンジニアの専門性が残ります。
KuboのAI-Driven Deploymentは、単にYAMLを生成するだけでなく、実クラスタの利用状況を踏まえた提案を行う点で、汎用AIコーディングアシスタントとは一線を画します。K3sベースのKubo Cloudなら、EKSやAKSと同等のPure Kubernetes環境を月額48,000円〜という予測可能なコストで運用でき、Captain UIによる可視化とあわせて、AIが書いたマニフェストを「動く」から「正しい」へと引き上げるための土台を用意できます。AIとの協業を前提にKubernetes運用を見直したい方は、お問い合わせから相談してみてください。