[{"data":1,"prerenderedAt":305},["ShallowReactive",2],{"blog-ja-ai-generated-kubernetes-manifest-resource-overprovisioning":3,"blog-related-ja-ai-generated-kubernetes-manifest-resource-overprovisioning":254,"blog-ja-ai-generated-kubernetes-manifest-resource-overprovisioning-alt":243},{"id":4,"title":5,"author":6,"body":7,"date":237,"description":238,"extension":239,"image":240,"locale":241,"meta":242,"navigation":243,"path":244,"seo":245,"stem":246,"tags":247,"__hash__":253},"blog\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning.md","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","Kubo Team",{"type":8,"value":9,"toc":223},"minimark",[10,15,23,31,42,45,48,56,60,66,75,84,95,99,105,114,123,126,134,138,144,147,152,160,169,173,181,185,192,196,203,206],[11,12,14],"h2",{"id":13},"_1-動くyamlが量産される時代でもkubernetesリソース設計は静かに壊れている","1. 「動く」YAMLが量産される時代——でもKubernetesリソース設計は静かに壊れている",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-generated-kubernetes-manifest-resource-overprovisioning\u002Fsection01.webp",[16,24,25,26,30],{},"Kubernetesのマニフェストを書くハードルは、この1〜2年で劇的に下がりました。AIコーディングアシスタントに「このアプリをデプロイして」と頼めば、Deployment・Service・HorizontalPodAutoscalerのYAMLが数秒で生成され、",[27,28,29],"code",{},"kubectl apply -f","が通ります。エラーもなく、Podは起動し、画面には緑のチェックマークが並びます。",[16,32,33,34,41],{},"しかし、この「動く」という結果は、Kubernetesリソース設計が「正しい」ことを意味しません。実際、",[35,36,40],"a",{"href":37,"rel":38},"https:\u002F\u002Fcast.ai\u002Fblog\u002F2026-state-of-kubernetes-resource-optimization-cpu-at-8-memory-at-20-and-getting-worse\u002F",[39],"nofollow","Cast AIの2026年版レポート","によれば、本番Kubernetesクラスタ全体のCPU過剰プロビジョニング率は前年の40%から69%へと悪化し、メモリの過剰プロビジョニング率は79%に達しています。一方で実際のCPU利用率はわずか8%、メモリ利用率も20%程度にとどまっているというデータが示されています。",[16,43,44],{},"つまり、申告されたリソース（request\u002Flimit）と実際に使われているリソースの間には、埋まらないどころか広がり続けるギャップがあるということです。AIが生成したマニフェストが「動く」のはスケジューラーとkubeletの視点での成功にすぎず、コストとキャパシティプランニングの観点では、むしろ問題を隠蔽しているケースが少なくありません。",[16,46,47],{},"この記事では、なぜAIが本番品質のKubernetesリソース設計を苦手とするのか、その技術的な理由と、実務でチェックすべきポイントを整理します。",[16,49,50,55],{},[35,51,54],{"href":52,"rel":53},"https:\u002F\u002Fkubo.hexabase.io\u002F",[39],"Kubo","のようなマネージドK3s基盤を使っている場合でも、AIが生成したマニフェストをそのまま適用する前に、実クラスタの利用状況を可視化できるかどうかが、コストと信頼性を分ける最初の分かれ目になります。",[11,57,59],{"id":58},"_2-なぜaiは間違った問題を解決してしまうのか","2. なぜAIは「間違った問題」を解決してしまうのか",[16,61,62],{},[19,63],{"alt":64,"src":65},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-generated-kubernetes-manifest-resource-overprovisioning\u002Fsection02.webp",[16,67,68,69,74],{},"AIコーディングアシスタントは、文法的に正しく、スキーマにも準拠したKubernetesマニフェストを生成できます。しかし、Kubernetesの",[35,70,73],{"href":71,"rel":72},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fconfiguration\u002Fmanage-resources-containers\u002F",[39],"公式ドキュメント","が説明しているように、requestsとlimitsにはそれぞれ異なる役割があります。requestsはkube-schedulerがPodをどのノードに配置するかを決める基準であり、limitsはkubeletが実行時にCPUスロットリングやOOM Killで強制する上限です。この2つの値をどう設定するかは、コードの文法とは別次元の「その組織固有のトラフィックパターンと余裕率の設計」です。",[16,76,77,78,83],{},"AIはこの文脈情報を持っていません。実際に",[35,79,82],{"href":80,"rel":81},"https:\u002F\u002Fwww.perfectscale.io\u002Fblog\u002Fkubernetes-clusters-ai",[39],"PerfectScaleのブログ","でも指摘されているとおり、AI駆動のリソース最適化ツールはメトリクスの解釈を誤ると不適切なスケーリング判断を下し、パフォーマンス低下やコスト増加につながるリスクがあります。加えて、AIの意思決定プロセスが不透明であるために、後から「なぜこの値になったのか」を監査しづらいという問題も指摘されています。",[16,85,86,87,90,91,94],{},"さらに厄介なのは、",[27,88,89],{},"limits","だけを指定して",[27,92,93],{},"requests","を省略した場合、Kubernetesは自動的にlimitの値をrequestとしてコピーするという仕様です。AIが「安全側」に倒して大きめのlimitを設定すると、それがそのままrequestとして扱われ、実際の使用量とは無関係にノードの空き容量を圧迫する結果になります。これは、AIが生成したYAMLが「動く」ことと「効率的である」ことの間にある典型的な落とし穴です。",[11,96,98],{"id":97},"_3-クラスタオートスケーラーは申告された数字しか見ていない","3. クラスタオートスケーラーは「申告された数字」しか見ていない",[16,100,101],{},[19,102],{"alt":103,"src":104},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-generated-kubernetes-manifest-resource-overprovisioning\u002Fsection03.webp",[16,106,107,108,113],{},"過剰プロビジョニングがそのままクラウド代の無駄になる理由は、Cluster Autoscalerの仕組みそのものにあります。",[35,109,112],{"href":110,"rel":111},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fcluster-administration\u002Fnode-autoscaling\u002F",[39],"Kubernetes公式ドキュメントのノードオートスケーリングの解説","によれば、Cluster Autoscalerはpending状態のPodが持つresource requestsを見て、既存ノードで賄えないと判断した場合に新しいノードを追加します。ここで重要なのは、「実際の使用量は直接考慮しない」という制約が明記されている点です。つまり、AIが余裕を見て大きめのrequestsを設定すればするほど、Cluster Autoscalerは律儀にノードを追加し、請求額を押し上げていきます。",[16,115,116,117,122],{},"同様の構造は水平方向のスケーリングにも存在します。",[35,118,121],{"href":119,"rel":120},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fhorizontal-pod-autoscale\u002F",[39],"HorizontalPodAutoscalerの公式ドキュメント","では、CPU利用率は「実際の使用量 ÷ resource request」で計算されるため、そもそもrequestsが設定されていなければCPU利用率という指標自体が定義できず、オートスケーラーは何のアクションも取れないと説明されています。AIが生成したマニフェストにrequestsが漏れている、あるいは極端に大きい値になっているだけで、HPAはサイレントに機能不全に陥るということです。",[16,124,125],{},"こうした「申告された数字」と「実際の需要」のズレを放置したまま運用を続けると、Kubernetes運用の中核であるはずのオートスケーリングが、コスト最適化ではなくコスト膨張の装置になってしまいます。",[16,127,128,129,133],{},"Kubo Cloudの",[35,130,132],{"href":52,"rel":131},[39],"Captain UI","は、リソースの申告値と実利用率を並べて可視化できるダッシュボードを備えており、AIが生成したマニフェストが「本番品質」かどうかを人間が最終判断するための材料をブラックボックス化させません。",[11,135,137],{"id":136},"_4-aiに書かせたyamlを本番品質のリソース設計にする3つのチェックポイント","4. AIに書かせたYAMLを「本番品質のリソース設計」にする3つのチェックポイント",[16,139,140],{},[19,141],{"alt":142,"src":143},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-generated-kubernetes-manifest-resource-overprovisioning\u002Fsection04.webp",[16,145,146],{},"AIが生成したKubernetesマニフェストを本番投入する前に、最低限確認すべき3つのポイントを整理します。",[148,149,151],"h3",{"id":150},"チェックポイント1-メトリクスベースで検証する","チェックポイント1: メトリクスベースで検証する",[16,153,154,159],{},[35,155,158],{"href":156,"rel":157},"https:\u002F\u002Fscaleops.com\u002Fblog\u002Fkubernetes-resource-requests-and-limits\u002F",[39],"ScaleOpsの解説記事","では、少なくとも7日間以上のCPU・メモリ・OOM・スロットリングのデータを収集し、平均値ではなくp95やp99のパーセンタイル値をもとにrequestsを設定することが推奨されています。CPUとメモリでは扱いを分けるべきで、CPUは実測のp95\u002Fp99需要に余裕を加えた値、メモリはOOM Killを避けるためrequestとlimitをほぼ同じ水準に揃えるという方針が示されています。",[16,161,162,163,168],{},"日本語圏でも、",[35,164,167],{"href":165,"rel":166},"https:\u002F\u002Fthinkit.co.jp\u002Farticle\u002F22502",[39],"Think ITで紹介されているKRR(Kubernetes Resource Recommender)","のようなツールが実用段階にあります。KRRはPrometheusなどに蓄積済みのメトリクスをもとに、CPUは過去1週間の99パーセンタイル値、メモリは過去1週間の最大値に15%のバッファを加えた値を数秒で提案してくれます。AIが最初に生成した値を、こうしたメトリクスベースの推奨値と突き合わせる工程を挟むだけで、過剰\u002F過小プロビジョニングのリスクは大きく下がります。",[148,170,172],{"id":171},"チェックポイント2-namespace単位の歯止めをかける","チェックポイント2: namespace単位の歯止めをかける",[16,174,175,180],{},[35,176,179],{"href":177,"rel":178},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fmanage-resources\u002Fquota-memory-cpu-namespace\u002F",[39],"Kubernetes公式のリソースクォータ管理ドキュメント","にあるとおり、ResourceQuotaはnamespace全体のリソース合計を制限し、LimitRangeは個別のPod・コンテナ単位で最小値・最大値・デフォルト値を強制します。AIが個々のマニフェストで妥当な値を書けていたとしても、チーム全体でnamespaceに歯止めがなければ、積み上がったリクエストの合計がクラスタ全体のキャパシティを圧迫します。AI生成のワークフローを導入するなら、その前提としてnamespace単位のガードレールを先に敷いておくことが実務上のセーフティネットになります。",[148,182,184],{"id":183},"チェックポイント3-継続的にモニタリングする","チェックポイント3: 継続的にモニタリングする",[16,186,187,188,191],{},"トラフィックパターンはリリースのたびに変化するため、一度検証した値も定期的な再検証が必要です。",[35,189,54],{"href":52,"rel":190},[39],"のようにPrometheus + Grafanaがモニタリング標準搭載されているマネージドK3s環境であれば、AIが生成したマニフェストを適用した後も、実利用率の推移を継続的に観測しながらrequests\u002Flimitsをチューニングし続けられます。",[11,193,195],{"id":194},"_5-まとめ","5. まとめ",[16,197,198,199,202],{},"AIコーディングアシスタントは、Kubernetesマニフェストを「文法的に正しく、動く」形で生成する能力においては既に実用段階にあります。しかし、",[27,200,201],{},"kubectl apply","が通ることと、Kubernetesリソース設計が本番品質であることは別問題です。Cast AIの2026年データが示すように、CPU過剰プロビジョニング率69%、メモリ79%という数字は、多くの組織がこの落とし穴にはまっていることを物語っています。",[16,204,205],{},"AIに欠けているのは、実際のトラフィックパターン・ノードの利用履歴・チーム固有の余裕率という「システム全体のコンテキスト」です。この文脈を補うのは、メトリクスベースの検証、namespace単位の歯止め、そして継続的なモニタリングという地道な運用設計であり、ここにこそインフラエンジニアの専門性が残ります。",[16,207,208,211,212,216,217,222],{},[35,209,54],{"href":52,"rel":210},[39],"のAI-Driven Deploymentは、単にYAMLを生成するだけでなく、実クラスタの利用状況を踏まえた提案を行う点で、汎用AIコーディングアシスタントとは一線を画します。K3sベースの",[35,213,215],{"href":52,"rel":214},[39],"Kubo Cloud","なら、EKSやAKSと同等のPure Kubernetes環境を月額48,000円〜という予測可能なコストで運用でき、Captain UIによる可視化とあわせて、AIが書いたマニフェストを「動く」から「正しい」へと引き上げるための土台を用意できます。AIとの協業を前提にKubernetes運用を見直したい方は、",[35,218,221],{"href":219,"rel":220},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[39],"お問い合わせ","から相談してみてください。",{"title":224,"searchDepth":225,"depth":225,"links":226},"",2,[227,228,229,230,236],{"id":13,"depth":225,"text":14},{"id":58,"depth":225,"text":59},{"id":97,"depth":225,"text":98},{"id":136,"depth":225,"text":137,"children":231},[232,234,235],{"id":150,"depth":233,"text":151},3,{"id":171,"depth":233,"text":172},{"id":183,"depth":233,"text":184},{"id":194,"depth":225,"text":195},"2026-08-04","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-generated-kubernetes-manifest-resource-overprovisioning\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning",{"title":5,"description":238},"blog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning",[248,249,250,251,252],"k3s","kubernetes","resource-management","capacity-planning","managed-kubernetes","3NEP5v6iYyvY-NW5u5VudNNtoWEcM2xw4R8TIyuq1xE",[255,264,272,280,289,297],{"path":256,"title":257,"description":258,"date":259,"tags":260},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[248,249,261,252,262,263],"cost-optimization","aks","finops",{"path":265,"title":266,"description":267,"date":268,"tags":269},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[248,249,252,270,271],"devops","platform-engineering",{"path":273,"title":274,"description":275,"date":276,"tags":277},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[248,249,278,279,252],"kubevirt","networking",{"path":281,"title":282,"description":283,"date":284,"tags":285},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[249,248,286,287,288,252],"microservices","service-mesh","latency",{"path":290,"title":291,"description":292,"date":293,"tags":294},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[249,248,295,296,252],"ai-inference","cncf",{"path":298,"title":299,"description":300,"date":301,"tags":302},"\u002Fblog\u002Fja\u002Fhybrid-k3s-edge-metrics-network-overhead","2000台のIoTデバイスがネットワーク回線を圧迫していた。ハイブリッドK3s運用でpush型メトリクスが牙を剥いた日","2000台規模のエッジデバイスを支えるK3sエッジ運用の現場で見えた、軽量Kubernetesを選ぶべき理由と、push型メトリクス収集が生むネットワークコストの実態を、具体的な数値とハイブリッドクラスタ設計の観点から詳しく解説する記事。エンジニア・運用担当者向け。","2026-07-31",[248,249,303,304,252],"edge-computing","hybrid-cluster",1787649510154]