結論：Claude CodeはKubernetes運用の「調査・生成・レビュー」を担う相棒として実戦投入できる段階に来ています。ただし、書き込み系操作の権限設計を最初にやらないと事故ります。
- 要点1：マニフェスト・Helmチャートの生成とレビューは、CLAUDE.mdに社内規約を書いておくだけで精度が大きく変わる
- 要点2：CrashLoopBackOff等の障害調査は「読み取り専用kubectlをClaude Codeに許可する」構成が最も安全で速い
- 要点3：ヘッドレスモード（claude -p）を使えば、CI/CDパイプラインにマニフェストの自動レビューを組み込める
対象読者：Kubernetesクラスタを運用する開発者・SRE・プラットフォームエンジニア。kubectlの基本操作ができる方を想定しています。
今日やること：検証用クラスタのkubeconfigを用意し、この記事の「読み取り専用の権限設計」をsettings.jsonに書いてから、CrashLoopBackOffのPodを1つClaude Codeに調査させてみてください。
深夜2時のCrashLoopBackOff、あの調査をAIに渡せるとしたら
正直に告白すると、筆者は昨年まで「Kubernetesの障害調査をAIに任せるのは怖い」と思っていました。kubectlは強力すぎるツールで、deleteひとつでサービスが止まる世界です。ところが、自社の検証クラスタで運用しているデモアプリが深夜にCrashLoopBackOffで落ちたとき、試しにClaude Codeへ「このPodがなぜ落ちているか、読み取り系コマンドだけで調査して」と投げたんです。
結果は想像以上でした。Claude Codeは自分でkubectl describe podを叩き、Last StateがOOMKilledであることを見つけ、直近のデプロイでresources.limits.memoryが誤って引き下げられていたことをGit履歴から特定。修正マニフェストの差分まで提示してきました。筆者が手作業でやれば、describeを読んで、logsを遡って、Gitを掘って……と30分コースだった調査が、コーヒーを淹れている間に「原因仮説＋修正案」まで揃っていた。これが筆者の検証環境での体験ですが、この体験がなければ本記事は書いていません。
本記事では、Claude CodeをKubernetes運用に組み込む実践手法を、マニフェスト生成からCI/CD連携まで7つのテーマで解説します。Docker・コンテナ構築編やTerraform IaC編が「インフラを作る」話だったのに対し、今回は「動いているオーケストレーション基盤を運用する」話。レイヤーがひとつ上がります。
なぜKubernetes運用にClaude Codeなのか — 動作環境と前提
Kubernetes運用のつらさは、突き詰めると「大量のYAMLと大量の状態を、人間の目で突き合わせ続けること」なんです。DeploymentとServiceとIngressとHPAとNetworkPolicyが絡み合い、しかもクラスタ内の実際の状態はマニフェストと乖離していく。この「宣言と現実の突き合わせ」こそ、コードベース全体を読みながらCLIを実行できるエージェント型AIの得意領域です。
Claude Codeがこの用途に向いている理由は3つあります。
- ターミナル常駐型：kubectlやhelmをその場で実行し、出力を読んで次のコマンドを自分で判断する。「describeの結果を見てからlogsを引く」という人間の調査フローをそのまま再現できる
- リポジトリ理解：マニフェストのGit履歴、Helmチャートのvalues階層、KustomizeのオーバーレイをClaude Codeはプロジェクト全体の文脈として読める
- 権限制御：settings.jsonのpermissionsで「許可するコマンドのパターン」を宣言でき、読み取り専用運用を仕組みで強制できる（詳細は次章）
本記事の検証環境は以下のとおりです。効果や挙動の記述はすべてこの環境での筆者の検証に基づくもので、環境によって結果は変わります。
| 項目 | バージョン・構成 |
|---|---|
| Kubernetes | 1.34 / 1.35（kind によるローカルクラスタおよび検証用マネージドクラスタ） |
| kubectl | クラスタと同一マイナーバージョン |
| Helm | v3系 |
| Claude Code | 2026年7月時点の最新版（npm経由でインストール） |
ちなみにKubernetes本体は2025年12月17日にv1.35「Timbernetes」がリリースされ、2026年7月時点でサポート対象は1.36 / 1.35 / 1.34の3マイナーバージョンです（kubernetes.io公式リリースページより）。v1.35はcontainerd 1.x系をサポートする最後のリリースとされており、クラスタのアップグレード計画を立てる際はこのあたりの互換性確認もClaude Codeに手伝わせると楽になります。
最初にやるべき権限設計 — 読み取り専用kubectlをsettings.jsonで強制する
Kubernetes運用にClaude Codeを持ち込むとき、機能の話より先に権限の話をさせてください。ここを飛ばすと本当に危ないからです。
Claude Codeにはpermissions設定があり、ツール実行を「allow（自動許可）/ ask(都度確認) / deny（拒否）」の3段階で制御できます。ルールはBash(コマンドパターン)の形式で書け、denyはallowより常に優先されるのがポイント（公式ドキュメント「Configure permissions」より）。つまり「読み取り系kubectlだけallow、書き込み系は明示的にdeny」という構成が宣言的に組めるんです。
筆者がプロジェクトの.claude/settings.jsonに入れている設定はこんな形です。
{
"permissions": {
"allow": [
"Bash(kubectl get *)",
"Bash(kubectl describe *)",
"Bash(kubectl logs *)",
"Bash(kubectl top *)",
"Bash(kubectl events *)",
"Bash(kubectl explain *)",
"Bash(helm list *)",
"Bash(helm template *)",
"Bash(helm lint *)"
],
"deny": [
"Bash(kubectl delete *)",
"Bash(kubectl apply *)",
"Bash(kubectl edit *)",
"Bash(kubectl patch *)",
"Bash(kubectl scale *)",
"Bash(kubectl drain *)",
"Bash(helm install *)",
"Bash(helm upgrade *)",
"Bash(helm uninstall *)"
]
}
}これで、Claude Codeは調査系コマンドを確認なしでどんどん実行できる一方、クラスタの状態を変えるコマンドは仕組みとして打てなくなります。「CLAUDE.mdに『deleteするな』と書けばいいのでは？」と思うかもしれませんが、CLAUDE.mdの指示はあくまで行動の方向付けであって、強制力を持つのはpermissionsとフックです。守らせたいルールは設定側に書く。これが鉄則です。
さらに慎重にやるなら、Kubernetes側でも防御します。viewロール相当の読み取り専用ServiceAccountを作り、そのトークンでkubeconfigのコンテキストを分ける。Claude Codeを起動するシェルでは読み取り専用コンテキストだけを使う。Claude Code側とKubernetes側の二重ガードにしておけば、どちらかの設定ミスが即事故にはなりません。
CLAUDE.mdには、規約や文脈情報を書きます。筆者のプロジェクトでは次のような内容を入れています。
# CLAUDE.md（抜粋）
## クラスタ構成
- context "kind-dev" は検証用。調査コマンドはここで実行する
- 本番クラスタのcontextには絶対に切り替えない
## マニフェスト規約
- リソースは manifests/ 配下、Kustomize構成（base/ + overlays/）
- 全コンテナに resources.requests / limits を必ず設定する
- imageタグにlatestは禁止。ダイジェストまたはsemverで固定
- Podには app.kubernetes.io/name と app.kubernetes.io/part-of ラベル必須
## 調査の流儀
- 障害調査は describe → logs --previous → events の順で証拠を集めてから仮説を出す
- 修正案は必ずマニフェストの差分（diff形式）で提示するこの「調査の流儀」を書いておくと、Claude Codeの調査手順が毎回安定します。書かないと、モデルの気分次第で調査ルートが変わるので、チームで使うなら必須だと思ってください。
マニフェスト・Helmチャートの生成とレビュー
権限設計が済んだら、まずは一番低リスクな「生成とレビュー」から始めましょう。クラスタに触らせず、YAMLファイルの読み書きだけをさせる使い方です。
マニフェスト生成：規約を前提に一式吐かせる
素のChatGPTなどにYAMLを書かせた経験がある方は「動くけど規約に合わない」問題にぶつかったはずです。Claude CodeはCLAUDE.mdと既存マニフェストを読んだうえで生成するので、この問題がかなり緩和されます。筆者が実際に使っているプロンプトはこうです。
manifests/base/ の既存構成を踏襲して、新サービス "report-worker" の
マニフェスト一式を作成してください。
要件:
- Deployment: レプリカ2、コンテナポート8080
- Service: ClusterIP
- 既存の payment-api と同じラベル体系・リソース設定の粒度に揃える
- liveness/readiness probe を必ず入れる（エンドポイントは /healthz）
- 不明な点（イメージ名、環境変数など）は生成前に質問してください最後の一文「不明な点は質問してください」が地味に重要です。これがないと、AIはイメージ名や環境変数を「それっぽく」埋めてしまう。仮定で埋められたYAMLは一見完成度が高いぶん、レビューをすり抜けやすいんです。
Helmチャートレビュー：values階層の罠を潰す
筆者の検証で特に手応えがあったのがHelmチャートのレビューです。Helmの怖さは、values.yamlの階層とテンプレート側の参照がズレていても、helm lintでは検出できないケースがあること。デフォルト値へ静かにフォールバックして、意図しない設定のまま本番へ行く。これ、経験者なら一度は踏んでいますよね。
charts/myapp/ のHelmチャートをレビューしてください。
観点:
1. values.yaml のキーとテンプレート内の .Values 参照の不一致
（タイポ・階層ズレでデフォルト値に落ちている箇所）
2. helm template で本番用 values-prod.yaml を展開した結果と、
ステージング用の展開結果の差分のうち、意図が疑わしいもの
3. resources / probe / securityContext の欠落
4. 非推奨APIバージョン（Kubernetes 1.34以降で削除済みのもの）の使用
helm template と helm lint は実行してよい。結果は重大度順の表で。筆者の検証環境で、社内デモ用チャート（テンプレート約20ファイル）にこのレビューを走らせたところ、values-prod.yamlのresource（正しくはresources）というタイポで本番だけリソース制限が消えていた箇所を検出してくれました。人間のレビューではまず見つからない類のバグです。helm templateを実行して展開結果同士を突き合わせる、という調査手順をAI自身が組み立てるのがエージェント型の強みで、この使い勝手はTerraformのplan差分レビューと同じ構図です。IaC全般で通用する型だと思ってください。
kubectlを使った障害調査 — CrashLoopBackOffデバッグの実践
ここからが本丸です。Kubernetesの障害調査は「証拠がクラスタ内のあちこちに散らばっている」のが厄介で、describe、logs、events、ノード状態を行き来する必要があります。この横断作業をClaude Codeに任せます。
調査の基本フロー
Kubernetes公式ドキュメント（Debug Running Pods）が示す調査の基本は、まずkubectl describe podでコンテナの状態と直近イベントを確認し、クラッシュしている場合はkubectl logs --previousで前回終了時のログを取ることです。CrashLoopBackOffは「コンテナが起動→クラッシュ→再起動を繰り返し、リトライ間隔が指数的に伸びている状態」を指すステータスで、原因は設定ミス・依存リソース不在・アプリのバグなど多岐にわたります。
Claude Codeへの依頼はシンプルでいいんです。
claude -p "namespace 'payments' でCrashLoopBackOffになっているPodを特定し、
原因を調査してください。手順: (1) kubectl get pods で対象特定
(2) describe で Last State と Exit Code 確認 (3) logs --previous で
クラッシュ直前のログ取得 (4) kubectl events で関連イベント確認。
証拠を引用しながら原因仮説を3つまで、確度順に提示。
修正はまだしないこと。" \
--allowedTools "Bash(kubectl get *) Bash(kubectl describe *) Bash(kubectl logs *) Bash(kubectl events *)"ヘッドレスモード（-pフラグ）は対話なしでClaude Codeを実行するモードで、–allowedToolsと組み合わせれば「このコマンド群だけ許可して1回きりの調査を走らせる」ことができます（公式ドキュメント「Run Claude Code programmatically」より）。オンコール対応のRunbookにこのワンライナーを貼っておくと、初動調査がコマンド一発になります。
Exit Codeの読み分けを任せる
CrashLoopBackOffの原因切り分けで最初に見るべきはExit Codeです。筆者はCLAUDE.mdに次の対応表を書いておき、Claude Codeの一次切り分けに使わせています。
| Exit Code / Reason | 典型的な原因 | 次に見るべき場所 |
|---|---|---|
| 137（OOMKilled） | メモリ制限超過 | resources.limits.memory、kubectl top、アプリのヒープ設定 |
| 1 | アプリケーションエラー | logs –previous のスタックトレース |
| 127 / 126 | コマンド不在・実行権限なし | Dockerfile の ENTRYPOINT/CMD、イメージのビルド |
| Reason: Error + probe失敗イベント | liveness probeの設定ミス | probeのパス・initialDelaySeconds |
2つ目の筆者エピソードを。検証クラスタでinitContainerを含むPodがCrashLoopBackOffになったとき、筆者は本体コンテナのログばかり見ていて30分ハマったことがあります。同じ状況をClaude Codeに調査させたら、describeの出力からinitContainerのステータス異常を先に拾い、「本体ではなくinit側のSecret参照が失敗している」と一発で指摘されました。人間は「いつもの場所」から見てしまうけれど、AIはdescribeの全行を等しく読む。思い込みがないことが、こと障害調査では強みになるんだなと痛感した瞬間です。
kubectl debugでの深掘り
ログだけで原因が特定できない場合、公式ドキュメントではエフェメラルコンテナやPodの複製による調査手段が案内されています。distroless等でシェルが入っていないコンテナにはエフェメラルコンテナを注入し、起動自体が失敗する場合はコマンドを差し替えた複製Podを立てる方法です。
# シェルのないコンテナにデバッグ用コンテナを注入
kubectl debug -it my-pod --image=busybox:1.36 --target=app
# クラッシュするPodを、コマンドをシェルに差し替えた複製で起動
kubectl debug my-pod -it --copy-to=my-pod-debug --container=app -- sh注意点として、kubectl debugは複製Podやエフェメラルコンテナを「作成」するため、純粋な読み取り操作ではありません。筆者の運用では、debugはallowリストに入れず、Claude Codeには「debugが必要な状況の判断とコマンド案の提示」までを任せて、実行は人間がやると決めています。障害調査で集めたログやメトリクスをどう恒常的な監視に落とすかはログ・監視・オブザーバビリティ編で詳しく扱っているので、併せてどうぞ。
【ここまでのやり方を自社チームに定着させたい方へ】 権限設計やCLAUDE.mdの規約設計は、正直、最初の設計を経験者と一緒にやるのが一番の近道です。UravationではClaude Code個別指導・導入支援として、SREチーム向けの権限設計レビューや運用フロー構築の伴走をしています。「うちのクラスタ構成だとどこまで許可していいか」といった個別事情のご相談から可能です。
リソース設定とHPA — 「なんとなくの値」を検証で潰す
Kubernetes運用の慢性疾患が、resources.requests / limitsの「なんとなく設定」です。requestsが小さすぎればノードが過密になり、limitsが小さすぎればOOMKilledの温床になる。そしてHPA（Horizontal Pod Autoscaler）はrequestsを基準にCPU使用率を計算するので、requestsが雑だとオートスケールまで雑になります。
HPAはautoscaling/v2 APIで定義し、メトリクスの目標値に応じてDeployment等のレプリカ数を自動調整するリソースです（kubernetes.io「Horizontal Pod Autoscaling」より）。Claude Codeに設計させるときは、負荷特性を必ず条件として渡します。
api-server の Deployment に対する HPA を autoscaling/v2 で設計してください。
前提条件:
- 平常時トラフィック: 約50 req/s、ピーク時: 約400 req/s（平日昼に急増）
- 現在の resources.requests: cpu 250m / memory 512Mi
- Pod起動からReadyまで約40秒かかる
- レプリカ範囲: 最小2〜最大12
要求:
- CPU使用率ベースの目標値の根拠を説明すること
- 急増トラフィックに対し、behavior（scaleUp/scaleDown）の
安定化ウィンドウをどう設定すべきか提案すること
- スケールイン時の急減（スラッシング）を避ける設定にすること3つ目の筆者エピソードです。検証環境でこのプロンプトを使う前、筆者は「targetCPUUtilization: 50」という教科書通りの値で運用していました。Claude Codeに負荷パターンを渡して設計させたところ、「Pod起動に40秒かかる構成でこの目標値だと、急増時にスケールアウトが間に合わない。目標値を下げて余裕を持たせるか、behaviorのscaleUpポリシーで一度に増やせるPod数を引き上げるべき」という指摘が返ってきました。負荷試験で確認したら、たしかに指摘どおりピーク到達前のレイテンシ悪化が緩和された。これは筆者の検証環境（kind + 負荷生成ツール）での結果であり、実環境での効果はワークロード特性に依存しますが、「設定値の根拠を言語化させる」だけでも導入価値があると感じています。
もうひとつ実用的なのが、クラスタ全体のリソース設定監査です。
kubectl get deployments -A -o yaml の出力を読み、以下を表にまとめてください:
1. resources.requests / limits が未設定のコンテナ
2. requests と limits の乖離が5倍以上あるコンテナ
3. limits.memory が requests.memory と同値でない（OOMリスク考慮が必要な）もの
修正の優先度を high / medium / low で付けることこの手の「全namespace横断の棚卸し」は人間がやると心が折れる作業ですが、AIには向いています。棚卸し結果をもとにマニフェストを直し、デプロイフローに乗せるところまではデプロイ・リリース編の型がそのまま使えます。
セキュリティ運用 — RBACとNetworkPolicyをAIにレビューさせる
セキュリティ設定は「動いているから触りたくない」心理が働きやすく、過剰権限が放置されがちな領域です。ここもレビュー用途ならリスクなしでAIを使えます。
RBAC監査
KubernetesのRBACはRole / ClusterRoleで権限を定義し、RoleBinding / ClusterRoleBindingで主体に紐付ける仕組みです（kubernetes.io「Using RBAC Authorization」より）。運用が長いクラスタでは「とりあえずcluster-adminを付けた」バインディングが化石のように残っていたりします。
kubectl get clusterrolebindings,rolebindings -A -o yaml の出力を読み、
以下の観点でRBAC監査レポートを作成してください:
1. cluster-admin が付与されている主体の一覧（人間・ServiceAccount別）
2. ワイルドカード（apiGroups: ["*"] / resources: ["*"] / verbs: ["*"]）を
含む Role / ClusterRole
3. secrets への get/list 権限を持つ ServiceAccount
4. 存在しない ServiceAccount を参照している宙に浮いたBinding
それぞれに「最小権限に絞る場合の修正版YAML案」を添えること。筆者が検証用に意図的に緩く作ったクラスタでこの監査を回したところ、仕込んだ過剰権限を全件検出したうえで、「このServiceAccountはDeploymentのreadしか実際には使っていないはず。Podのログを見る限り〜」と、実際の利用実態への推論まで添えてきました。もちろん最終判断は人間がやるべきですが、監査の下書きとしては十分すぎる品質です。
NetworkPolicyの設計
NetworkPolicyはPod間・外部との通信をラベルセレクタで制御するnamespaceスコープのリソースで、何もポリシーがない状態ではPod間通信はすべて許可されます（kubernetes.io「Network Policies」より）。「default-deny（全拒否）を敷いてから必要な通信だけ開ける」のが定石ですが、既存クラスタに後から入れるのは通信の依存関係の洗い出しが大変で、みんな後回しにする。ここでClaude Codeの出番です。
manifests/ 配下の全Service / Deployment定義を読み、サービス間の
通信依存グラフを推定してください（環境変数のエンドポイント設定や
Service名の参照から推測し、推測箇所には根拠を明記）。
その上で:
1. namespace "payments" に default-deny のNetworkPolicyを導入する場合、
最低限開けるべきIngress/Egressルールの一覧
2. 対応するNetworkPolicyマニフェスト（DNSへのEgress許可を忘れないこと）
3. 適用前に確認すべき「推測に自信がない通信経路」のリスト3番の「自信がない箇所を自己申告させる」のがコツです。default-denyの導入失敗は即障害につながるので、AIの推測とテレメトリ（実際のフローログ）を突き合わせてから適用する運用にしてください。このあたりの本番適用の段取りはSRE・インフラ運用編で扱った変更管理の考え方がそのまま活きます。
CI/CD連携 — ヘッドレスモードでマニフェストレビューを自動化する
ここまでの使い方は「人間がClaude Codeと対話する」形でしたが、真価はパイプラインへの組み込みで出ます。claude -pはCI上で普通に動くので、「PRで変更されたマニフェストをAIが一次レビューする」ゲートを作れるんです。
GitHub Actionsでの構成例がこちら。マニフェスト変更を含むPRに対して、レビュー結果をコメントとして返します。
name: k8s-manifest-review
on:
pull_request:
paths:
- 'manifests/**'
- 'charts/**'
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install Claude Code
run: npm install -g @anthropic-ai/claude-code
- name: Review manifests
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
git diff origin/${{ github.base_ref }}...HEAD -- manifests/ charts/ > /tmp/diff.txt
claude -p "CLAUDE.mdの規約に照らして /tmp/diff.txt のマニフェスト変更を
レビューせよ。観点: リソース設定の欠落・latestタグ・probe欠落・
非推奨API・securityContextの緩和。指摘は重大度順のMarkdown表で。
問題がなければ 'LGTM' とだけ出力。" \
--allowedTools "Read" > /tmp/review.md
- name: Comment on PR
uses: marocchino/sticky-pull-request-comment@v2
with:
path: /tmp/review.mdポイントは–allowedToolsをReadだけに絞っていることです。CI上のレビューJobにBashもクラスタアクセスも必要ありません。権限は用途ごとに最小で渡す。対話用・調査用・CI用でsettings（またはCLIフラグ）を分けるのが、運用に乗せるときの作法です。
この構成はArgoCDなどのGitOps運用と特に相性がいいんです。GitOpsでは「Gitにマージされたものがクラスタに同期される」ので、マージ前のレビューゲートがそのまま本番の防御線になる。AIレビュー→人間承認→自動同期という三段構えにすると、レビュー漏れとデプロイ作業ミスの両方を潰せます。パイプライン設計全般の話はCI/CDパイプライン自動化編に詳しく書いたので、そちらもご覧ください。
なお、ヘッドレスモードには–output-format jsonのような構造化出力のオプションもあり（公式ドキュメント「Run Claude Code programmatically」より）、レビュー結果をパースして「重大度highが1件でもあればCIを落とす」といったゲート化も可能です。まずはコメント投稿型で信頼を積み、精度に納得してからブロッキングゲートに昇格させる、という段階導入をおすすめします。
【要注意】よくある失敗パターン4つと回避策
筆者自身の失敗と、導入相談で繰り返し見てきたつまずきを4つにまとめます。
失敗1：本番クラスタのcontextのままClaude Codeを起動する
❌ いつもの作業シェルで、kubeconfigのcurrent-contextが本番のままclaudeを起動
⭕ Claude Code用のシェルでは読み取り専用ServiceAccountのcontextに固定。CLAUDE.mdにも「使用してよいcontext名」を明記する
なぜ重要か：permissionsで書き込みコマンドをdenyしていても、設定の適用範囲を間違える・別プロジェクトで起動するなどのヒューマンエラーは起こります。Kubernetes側の権限とClaude Code側の権限、二重にかけるのが原則です。
失敗2：kubectl applyまで自動許可してしまう
❌ 「調査から修正まで全部やってほしい」とapply/patchをallowに入れる
⭕ AIの担当は「調査・原因特定・修正マニフェスト作成」まで。クラスタへの適用はPR経由のGitOpsフローか、人間の手で行う
なぜ重要か：AIの修正案は「もっともらしいが間違っている」ことがあり、適用が自動だと間違いがそのまま本番の状態変更になります。Git経由にすれば、間違いはレビューで止まり、履歴も残る。「AIは提案し、人間が適用する」の線引きが運用の生命線です。
失敗3：曖昧な依頼で「それっぽいYAML」を量産する
❌「いい感じにHPA設定して」「セキュリティを強化して」
⭕「ピーク400req/s・Pod起動40秒という条件でHPAを設計し、目標値の根拠を説明して」のように、負荷特性・制約・判断根拠の提示まで要求する
なぜ重要か：Kubernetesの設定値は環境依存の塊で、「一般的に良い値」は存在しません。条件を渡さないと、AIは教科書的な値で埋めてきます。動くけど最適ではないYAMLは、レビューで最も見抜きにくい不良品です。
失敗4：AIの調査報告を裏取りせずインシデントレポートに書く
❌ Claude Codeが出した原因仮説をそのままポストモーテムに転記
⭕ 仮説には必ず「証拠となるコマンド出力の引用」を添えさせ、人間がその出力を再確認してから確定させる
なぜ重要か：AIは複数の証拠をつなぐ推論で稀に飛躍します。筆者も検証中、実際にはネットワーク起因だった障害を「probe設定起因」と誤推定された経験があります。プロンプトに「証拠を引用しながら」と入れるだけで検証可能性が大きく上がるので、調査系の依頼には必ず入れてください。
導入ロードマップ — 読み取り専用から始める3フェーズ
チームに入れるなら、一気にやらず段階を踏むのが結局速いです。筆者が支援先に提案している標準的な進め方を、汎用化して示します（期間は目安であり、チーム規模・クラスタ数によって変わります）。
| フェーズ | やること | ゴール |
|---|---|---|
| Phase 1（〜1ヶ月） | 検証クラスタで読み取り専用の権限設計を構築。CLAUDE.mdに規約と調査フローを整備。障害調査とマニフェストレビューを個人レベルで試す | 権限設計の型が固まり、調査プロンプトの「当たりパターン」がチームに数個溜まる |
| Phase 2（2〜3ヶ月） | CI/CDへヘッドレスモードのレビューゲートを組み込み（コメント型）。RBAC・リソース設定の定期棚卸しをAI下書き＋人間確定で運用 | マニフェストレビューの一次チェックがAI化され、人間レビューが設計判断に集中できる |
| Phase 3（4ヶ月〜） | レビューゲートのブロッキング化。オンコールRunbookへの調査ワンライナー組み込み。NetworkPolicy等の未着手セキュリティ課題へ展開 | 「AIが調査・提案、人間が承認・適用」の分業がチームの標準フローになる |
強調したいのは、Phase 1を飛ばさないことです。権限設計とCLAUDE.md整備という地味な工程が、後段すべての安全性と精度を決めます。ツールを入れること自体はすぐできるからこそ、土台を先に作る価値があるんです。
FAQ — Kubernetes×Claude Codeでよく聞かれる質問
Q1. kubectlのプラグインやk9sなど既存ツールとの使い分けは？
役割が違います。k9sは「人間が状態を見る」ためのビューア、Claude Codeは「調査の仮説立てと横断作業」を任せるエージェントです。筆者は普段の監視はダッシュボード、異常時の深掘りと棚卸し系タスクをClaude Code、と使い分けています。既存ツールを置き換えるのではなく、その間を埋める存在だと考えてください。
Q2. クラスタの情報を外部AIに渡して大丈夫？
kubectl出力にはSecretの値や内部ホスト名が含まれ得ます。まず組織のAI利用規程・コンプライアンスを確認してください。そのうえで、Secretのget/listをpermissionsでdenyする、機密namespaceを調査対象から除外する、といった制御を推奨します。「オンプレならAIに渡しても安全」といった単純化はせず、所属組織のセキュリティ部門と合意した範囲で使うのが原則です。
Q3. マネージドKubernetes（GKE / EKS）でも同じ方法が使えますか？
本記事の手法はkubectl・Helm・標準APIの範囲なので、ディストリビューションを問わず使えます。クラウド側リソース（ノードプール、IAM連携など）まで扱う場合は、gcloudやaws CLIにも同じ発想で読み取り専用のallowlistを組んでください。クラウドリソースのIaC管理はTerraform編の領域です。
Q4. AIが実行したkubectlコマンドの監査ログは残せますか？
二層で残せます。Claude Code側はフック機能でツール実行前後に任意のコマンドを差し込めるので、実行コマンドのロギングが可能です。Kubernetes側では専用ServiceAccountを使っていれば、APIサーバーの監査ログでAI経由の操作を主体単位で追跡できます。専用アカウントを切る運用は、この監査可能性の面でも効いてきます。
Q5. チーム導入で最初につまずくポイントは？
権限設計でもツール設定でもなく、「CLAUDE.mdに書くべき自社規約が言語化されていない」ことです。ラベル規約、リソース設定の基準、調査手順——暗黙知のままではAIに渡せません。逆に言うと、導入プロセス自体が運用知識のドキュメント化を強制してくれる。これは副産物として結構大きい価値だと筆者は思っています。
まとめ — 宣言的インフラとエージェント型AIは相性がいい
最後に本記事の要点を整理します。
- Claude CodeのKubernetes運用適用は「読み取り専用の権限設計」が出発点。permissionsのdeny優先ルールで書き込み系kubectlを仕組みとして封じる
- マニフェスト・Helmチャートの生成とレビューは最も低リスクで効果が出やすい。CLAUDE.mdの規約整備が精度を決める
- CrashLoopBackOff等の障害調査は describe → logs –previous → events の証拠収集をAIに任せ、仮説には証拠の引用を必須にする
- HPA・リソース設定は負荷特性を条件として渡し、「設定値の根拠」を言語化させる
- RBAC・NetworkPolicyの監査はレビュー用途ならリスクゼロで始められる
- CI/CDへはclaude -p（ヘッドレスモード）で組み込み、コメント型→ブロッキング型へ段階昇格
- 一貫する原則は「AIが調査・提案し、人間が承認・適用する」
Kubernetesは宣言的な世界です。あるべき状態がコードで書かれ、現実との差分が常に観測できる。この構造は、コードを読み・コマンドを実行し・差分を推論するエージェント型AIにとって、実は最高の活躍環境なんです。まずは検証クラスタで、CrashLoopBackOffのPodをひとつ調査させるところから始めてみてください。
【Kubernetes×Claude Codeの導入を本気で進めたい方へ】 権限設計、CLAUDE.md規約、CI/CDゲートの構築は、自社のクラスタ構成・チーム体制に合わせた個別設計が必要な領域です。UravationのClaude Code個別指導・導入支援では、SRE・プラットフォームチーム向けに、この記事で紹介した運用フローの設計から定着までを伴走支援しています。「まず何から手を付けるべきか」の壁打ちだけでも歓迎です。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。
出典・参考資料
- Kubernetes公式: Releases（サポート対象バージョン一覧）（2026年7月時点）
- Kubernetes公式ブログ: Kubernetes v1.35: Timbernetes（2025年12月17日）
- Kubernetes公式ドキュメント: Debug Running Pods（kubectl describe / logs / debug）
- Kubernetes公式ドキュメント: Horizontal Pod Autoscaling
- Kubernetes公式ドキュメント: Using RBAC Authorization
- Kubernetes公式ドキュメント: Network Policies
- Claude Code公式ドキュメント: Run Claude Code programmatically（ヘッドレスモード）
- Claude Code公式ドキュメント: Configure permissions
