「デプロイして」と話しかけるだけでKubernetesのマニフェストが数秒で生成される。実際、AWSは自然言語でEKSクラスタを操作できるAmazon EKS MCP Serverをプレビュー公開し、GoogleもオープンソースのAI搭載アシスタントkubectl-aiを提供している。もはやKubernetes運用の入力コストはゼロに近づいている。
しかし、ここで一つ問いたい。マニフェストが1秒で書けるようになったからといって、あなたのクラスタは本当に速くなっただろうか。CPUが謎にスロットリングされる、スケーリングが不安定になる、レイテンシが突然跳ね上がる——こうした問題は、AIがどれだけ速くYAMLを書いても解決しない。なぜなら、これらの原因は「コードの書き方」ではなく「アーキテクチャの設計」にあるからだ。
AIが速くしたのは「入力」だけで「設計」ではない
AIがKubernetesマニフェストを生成する際、得意なのは構文的に正しいYAMLを書くことだ。DeploymentやServiceの型を理解し、テンプレートに沿ってフィールドを埋める作業はAIにとって朝飯前になった。
だが、そのマニフェストに書き込まれる数値——CPUのrequests/limits、レプリカ数、autoscalerの閾値——が本番環境にとって適切かどうかは、AIには判断できない。これらの数値は、アプリケーションの実際の負荷特性、データベースの応答時間、ネットワークのトポロジーといった「その場の文脈」に依存するからだ。つまりAIが速くしているのは「入力のスピード」であって、「設計の正しさ」ではない。この区別を見失うと、爆速でデプロイされた本番環境が、なぜか爆速で不安定になるという逆説にはまる。
ボトルネックの正体① —— requests/limitsの誤解とCPUスロットリング
最も見落とされやすいのが、CPUのrequests/limits設定だ。Kubernetes公式ドキュメントによれば、CPUのlimitはカーネルレベルのスロットリングとして強制されるハードリミットであり、コンテナがlimitに近づくとカーネルがCPUへのアクセスを直接制限する。これはメモリのOOM Killとは異なり、超過した瞬間に反応的に落ちるわけではなく、静かにレスポンスタイムを悪化させる。
AIが生成したYAMLに何気なく書かれた「cpu: 500m」のようなlimit値が、実はバーストの多いワークロードにとって致命的なスロットリング源になっているケースは少なくない。Kubernetes公式ブログの「The Case for Kubernetes Resource Limits」では、predictability（予測可能性）を重視するなら requests と limits をほぼ同値にする、効率を優先するなら limits に20%程度のヘッドルームを持たせる、という2つのアプローチが提示されている。どちらが正しいかは、AIではなく「そのワークロードの負荷特性を知っている人間」が判断すべき設計問題だ。
ボトルネックの正体② —— HPAとVPAの「デススパイラル」
自動スケーリングも同様だ。KubernetesにはHorizontal Pod Autoscaler（HPA）とVertical Pod Autoscaler（VPA）という2つの自動スケーリング機構があるが、この2つを同じリソースメトリクスに対して同時運用すると、レプリカ数の変動が1台あたりのメトリクスを歪め、VPAが推奨requestsを下げ、それによってHPAがさらにスケールするという循環（デススパイラル）が起きる。
これは理論上の話ではない。スポーツ用品大手Adidasのプラットフォームチームは、開発・ステージング環境の全ワークロードにVPAを自動適用してCPU・メモリ使用率を30%削減した一方で、「VPAはリソースメトリクスを使うHPAと連動できない」という制約に直面し、制御対象をリソースリクエストのみに限定するという慎重な設計判断を行った。結果として月額コストを50%削減できたのは、AIがYAMLを書いたからではなく、チームが両者の役割分担を正しく設計したからだ。AIにHPAとVPAのマニフェストをそれぞれ生成させることはできても、「この2つを同時に有効化していいか」を判断するのはアーキテクチャ設計の領域である。
ボトルネックの正体③ —— アプリ層のDB接続不足はAIには見えない
3つ目のボトルネックは、Kubernetes層ではなくアプリケーション層に潜む。典型例がデータベースへの接続だ。マイクロサービスがリクエストごとに新規のDB接続を作成していると、接続確立のオーバーヘッドがそのままレイテンシに直結する。
Googleは2026年、AlloyDB向けにマネージドコネクションプーリング機能を発表し、直接接続と比較してクライアント接続数を3倍、トランザクションスループットを最大5倍に改善したと報告している。これはKubernetesのPodの数やスケーリング設定をどれだけ最適化しても届かない領域の話だ。AIにマニフェスト生成を頼んだところで、「このサービスはDB接続をプールせずに毎回張り直している」というアプリケーション内部の設計上の欠陥までは指摘してくれない。AIはあなたが渡したコンテキストの中でしか最適化できない。
AIに任せていい層、エンジニアが設計すべき層 —— 線引きの提案
ここまで見てきた3つのボトルネックに共通するのは、いずれも「AIが構文的に正しいYAMLを書けるかどうか」とは無関係に存在する、という点だ。CNCFのブログでも、ポリシー違反はコードレビューを終えて開発者が既に次のタスクに移った後、CI/CDパイプラインやアドミッションコントローラーの段階でようやく発覚することが多く、開発の初期段階でのガバナンスにギャップがあると指摘されている。これはAI生成コードに限った話ではなく、人間が書いたマニフェストでも同様に起きる構造的な課題であり、生成が速くなった分だけ、レビューと設計判断の重要性はむしろ増している。
現実的な役割分担は明確だ。マニフェストの雛形生成、繰り返しの多いkubectl操作、構文チェックといった作業はAIに任せてよい。一方で、CPUのrequests/limitsの粒度、HPAとVPAの併用可否、DBコネクションプールの設計といった「アーキテクチャの正しさ」は、クラスタとアプリケーションの全体像を理解した人間が判断すべき領域として残る。AIの進化がこの線引きを消すことはなく、むしろ線引きを明確にする責任を人間側に強く求めるようになっている。
KuboのAI-Driven Deploymentも「自然言語でデプロイして」と頼める点ではこの流れに乗っているが、それはあくまで入力を楽にする機能だ。重要なのは、その先でrequests/limitsやHPA/VPAの設定状況を人間が把握できるかどうかであり、KuboのCaptain UIが可視化されたダッシュボードを標準搭載しているのは、まさに「AIが見えない領域」を人間が判断できるようにするためだ。
まとめ —— 「速い」と「正しい」は別の指標
AIによってKubernetesマニフェストの生成速度は間違いなく上がった。しかしCPUスロットリング、HPA/VPAのデススパイラル、DB接続不足のような本当のボトルネックは、コードの生成速度とは別の次元にある。今後Kubernetes運用に求められるのは、AIに「何を任せるか」と「何を任せないか」を切り分ける設計判断力そのものだ。
EKS/AKS/GKEのようなマネージドサービスは高コスト・複雑・ベンダーロックインという三重苦を抱えやすいが、K3sベースのKuboであれば、AI-Driven Deploymentによる入力の簡単さと、Pure Kubernetes（標準K8s、ベンダーロックインなし）としての本格的な設計自由度を両立できる。Prometheus + Grafanaがモニタリング標準搭載されているため、本記事で触れたCPUスロットリングやスケーリングの異常も可視化しやすい。4vCPU/8GB/40GB×3ノード構成であれば月額48,000円からとコスト効率も高く、EKSの約58%のコストで同等の本格運用を実現できる。
「AIに書かせる」ことと「AIに設計を委ねる」ことは別物だ。その違いを理解した上で、正しいアーキテクチャ設計ができる基盤を選びたいなら、Kuboの料金プランを一度確認してみてほしい。導入を検討中であれば、お問い合わせから無料相談も可能だ。