本番KubernetesをClaude Codeで管理する——YAMLからCronJobアーキテクチャまで

はじめに
自然言語 → 本番品質K8s YAML生成——マニフェストからHelmチャートまで
1. 自然言語での指示パターン
2. 既存YAMLのHelmチャート化
Kubernetes MCP Server × Claude Code——クラスター操作をCLIに統合
1. MCP接続の設定
2. ポッド障害デバッグワークフロー
Claude Code as K8s CronJob——「エージェントをインフラとして動かす」FutureSearch事例
まとめ

はじめに

Terraformで作るクラウドインフラの話（terraform-iac）でも、CI/CDパイプラインの話（headless-cicd）でも、ローカルDockerの話（devcontainer）でもない。本番クラスターで動くKubernetesリソースをClaude Codeで管理し、さらにClaude Code自体をK8s CronJobとして動かす——コンテナオーケストレーションの実践だ。

KubernetesのYAMLマニフェストは本番環境を定義する「コード」だ。しかし、resource limits・liveness probe・security context・PodDisruptionBudgetといった設定漏れがインシデントの原因になる。「動くYAML」と「本番品質のYAML」の間には大きなギャップがある。Claude Codeはそのギャップを埋める。

自然言語 → 本番品質K8s YAML生成——マニフェストからHelmチャートまで

自然言語での指示パターン

「Node.jsアプリのプロダクション用デプロイメントマニフェストを作って。
要件: 3レプリカ、ヘルスチェック、リソース制限、
LoadBalancerサービス付き」

この指示から生成されるマニフェストには、単なるDeployment + Serviceだけでなく、本番で必要な設定が自動で含まれる（kubezilla.io）。

- resourceRequests/Limits: CPU・メモリの適切な設定

- livenessProbe / readinessProbe: アプリケーション固有のヘルスチェックエンドポイント

- securityContext: 非root実行・読み取り専用ルートファイルシステム

- PodDisruptionBudget: ローリングアップデート中の可用性保証

「YAMLを書く知識」から「何が必要かを説明する能力」へ。インフラ定義の主役が変わる。設定漏れが大幅に減ると報告されており、エンジニアが「正しいYAMLの書き方」を覚えることより「何が必要かを正しく定義すること」に集中できる。

既存YAMLのHelmチャート化

「このDeployment/Service YAMLをHelmチャートに変換して。
values.yamlにリポジトリURL・タグ・レプリカ数を外部化して」

Claude Codeが生成するHelmチャートの構造はこうなる。

my-chart/
├── Chart.yaml          # チャートメタデータ・依存関係
├── values.yaml         # デフォルト値（環境別オーバーライド対応）
├── templates/
│   ├── deployment.yaml # テンプレート化されたDeployment
│   ├── service.yaml    # テンプレート化されたService
│   ├── ingress.yaml    # Ingressリソース
│   └── _helpers.tpl    # 共通ヘルパーテンプレート
└── charts/             # サブチャートの依存関係

環境ごとのvalues.yamlオーバーライドも含めて設計されるため、dev/staging/productionの切り替えがhelm install -f values-prod.yamlで完結する。

Kubernetes MCP Server × Claude Code——クラスター操作をCLIに統合

MCP接続の設定

claude mcp add kubernetes-mcp-server

github.com/containers/kubernetes-mcp-server（RedHat/Containers製Go実装、GitHubで確認済み）はClaude Codeから直接Kubernetes APIサーバーに接続するMCPサーバーだ。以下のHelmオペレーションをClaude Codeから実行できる。

- helm_install: 指定ネームスペースへのHelmチャートインストール

- helm_list: Helmリリースの一覧確認

- helm_uninstall: Helmリリースのアンインストール

「Helmコマンドを覚える」学習コストが下がり、新しいエンジニアのクラスター操作のオンボーディングが加速する。

ポッド障害デバッグワークフロー

CrashLoopBackOffが発生したとき、Claude Codeへの指示はシンプルだ。

「このポッドが CrashLoopBackOff になっている原因を調べて:
pod-name: payment-service-6d7f8c9b4-xk2p9」

Claude Codeが自動で実行するステップはこうなる。kubectl describe podでイベントを確認し、kubectl logs --previousでクラッシュ前のログを取得し、エラーメッセージを解析して原因を特定し、修正策を提案する（シークレット不足・ボリュームマウント誤り等）。

深夜のオンコール対応でClaude Codeが根本原因の候補を絞り込み、専門家への連絡を最小化する——「誰でも障害の初動診断ができる」状態が作れる。

KagentフレームワークはPrometheus・GrafanaとClaude Code MCPを連携させた自律インフラ管理の高度な統合例として挙げられているが（kagent.dev）、現時点では補足的な情報として捉えてほしい。

Claude Code as K8s CronJob——「エージェントをインフラとして動かす」FutureSearch事例

この章が本記事の核心だ。

FutureSearchはClaude Codeを人間が操作するCLIとしてではなく、Kubernetes CronJobとして自律実行させている（futuresearch.ai）。コミュニティスキャン・分類・コンテンツ生成・SEO最適化を、平日毎朝8AMに全自動で実行する「エージェントインフラ」のアーキテクチャだ。

Dockerfileの設計（非TTY実行の鍵）

FROM python:3.13 AS base
# Node.js必須（Claude CLIがNode.jsで動くため）
RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
RUN apt-get install -y nodejs

# インタラクティブオンボーディングをスキップ（非TTY実行の前提条件）
RUN echo '{"hasCompletedOnboarding": true}' > /root/.claude.json

hasCompletedOnboardingフラグが重要だ。TTYなし環境でClaude CLIが対話的なオンボーディングプロセスを開始しないために必要な設定で、ここを外すとCronJobが止まる。

CronJobマニフェストとフェイルセーフ

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "0 8 * * 1-5"     # 平日8AM UTC実行
  concurrencyPolicy: Forbid    # 並行実行禁止
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: claude-agent
            resources:
              requests:
                cpu: "100m"
                memory: "4Gi"  # Claude Codeはメモリを多く使用

実行コマンドは以下の形だ。

claude -p "タスクの指示" \
  --dangerously-skip-permissions \
  --verbose \
  --output-format stream-json

3時間のタイムアウトを設定しており、タイムアウト（exit code 124）の場合、別のClaude Codeインスタンスが自動で「部分的な結果を収集 + 診断PRを作成」する。

各CronJob実行でブランチを作成 → 結果をコミット → PRを作成するGitHub-centricなパターンも特徴的だ。カスタムダッシュボードやDBが不要で、GitHubがそのまま実行ログ・成果物の保管先になる。

適用範囲と制約

FutureSearchが明示する通り、このパターンが適しているのは発見・分類タスク・コンテンツ生成・SEO最適化のような定型的な自律タスクだ。決済処理やミッションクリティカルなシステムへの適用は推奨されない。

セキュリティ設計も重要だ。K8s CronJobでClaude Codeを動かす場合、ServiceAccountの権限を最小化すること。クラスター管理者権限を付与しないこと。--dangerously-skip-permissionsは必要最小限の権限スコープで使う。コスト管理も事前に確認が必要で、CronJobが頻繁に実行されるとAPIトークン消費が増大する。

まとめ

K8s YAMLの生成からHelmチャート管理、障害デバッグまでがClaude Codeで繋がる。「本番品質のYAML」を毎回ゼロから書く時代は終わりつつある。

FutureSearchが示したCronJobアーキテクチャは、Claude Codeが「道具」から「インフラ」に変わる次のステップだ。ミッションクリティカルでないタスクから試してみることで、「エージェントをインフラとして動かす」感覚が掴める。