Amazon EKS（以下、EKS）のアップグレードは、定期的に発生する作業です。EKSを採用する企業の多くでは、おそらく手順書はすでに用意されているでしょう。ゼロベースで挑む作業ではありません。ただし、本当に手間がかかるのはアップグレードの実作業ではなく、その前段階にある互換性調査です。Kubernetes本体・EKSはもちろん、周辺コンポーネント（EKSアドオン、Argo系、Datadog Agent、Istio、External Secrets Operatorなど）についても、バージョンが変わるたびに一から確認し直す必要があります。見落とせばサービスに悪影響が出るためです。

そこでこの記事では、EKSのアップグレードに携わるエンジニアに向けて、Claude Codeを活用して作業を効率化する実践知を紹介します。具体的には、筆者が実務でEKSを1.32から1.34へと2バージョンアップグレードした際に、事前の互換性調査・更新作業・作業証跡の可視化という一連の流れにClaude Codeをどう活用したかをまとめました。結果として、過去に1バージョンだけ上げたときよりも短い時間で、本番環境への影響もゼロのまま完走できています。

対象読者は、EKSやKubernetesクラスタの運用を担当するSRE・インフラエンジニアの方々です。日々の運用にAIツールをどう組み込めるか、一つの事例として参考にしていただけると嬉しいです。

Before / After⁠：ひと目でわかる変化

従来の「すべて人間が手作業で調べて判断していた運用（Before⁠）⁠」と、「⁠Claude Codeをパートナーとして組み込んだ今回の運用（After⁠）⁠」で、各フェーズがどう変化したのかを一覧で示します。

ここからは、この表の各項目を詳しく見ていきます。

事前作業⁠：互換性調査をClaude Codeと進める

まずは、実際にアップグレードを行う前のKubernetes本体・EKSの互換性調査です。このフェーズで、Claude Codeを最も濃く使いました。

Kubernetes本体⁠・EKSの互換性調査

最初に、リリースノートや公式ドキュメントの精査を行います。この事例ではKubernetes本体のリリースノート（1.33、1.34）と、EKSのAWS公式ドキュメントの「既存のクラスターを新しい Kubernetes バージョンに更新する」を参照しました。Claude Codeと一緒に、自分たちの環境への影響を一つずつ確認しました。

たとえば1.33ではstatus.nodeInfo.kubeProxyVersionフィールドの削除やEndpoints APIの非推奨化がありましたが、いずれも自分たちの利用実態には影響しないと判断できました。Amazon Linux 2ベースδAMIが廃止された点も、すでにAmazon Linux 2023へ移行済みだったため対応不要でした。

周辺コンポーネント互換性調査

調査方法の基本的な型はシンプルです。使用中の周辺コンポーネントのバージョン一覧をClaude Codeにまとめてもらい、リリースノート全般（破壊的変更に限らない）を出力してもらいます。そのうえで、今回のEKSバージョンに対応するために必要なバージョンを判断します。本事例では、10種類以上あるコンポーネントについて、サブエージェント（バックグラウンドで並行してタスクを実行させる仕組み）に並行して調査してもらいました。実際に使ったプロンプトは、たとえば次のようなものです（External Secrets Operatorの調査時の例⁠）⁠。

external-secrets-operator の現行バージョンは 0.16.2 です。
EKS を 1.33、1.34 まで上げる予定です。
0.16.2 から最新の 2.0.1 までのリリースノートを確認し、バージョンごとの変更点を整理してください。
特に破壊的変更がないかは重点的に見てください。
根拠となる公式リリースノートのリンクも添えて教えてください。

以前、Claude Codeが非公式記事から引用してきたことがあったため、必ず根拠となる公式ドキュメントのリンクも教えてもらうようにしています。そのうえで、最終確認は必ず自分で行います。

対応方針の判断

Claude Codeを壁打ち相手にして特に助かったのが、判断が難しかったArgo WorkflowsとExternal Secrets Operatorの対応方針の検討です。

Argo Workflowsは、3.7系・4.0系のリリースノートを確認しました。現行バージョンは3.7.4（2025年11月13日リリース⁠）⁠、最新バージョンは4.0.0（2026年2月4日リリース）でしたが、どちらもテスト済みKubernetesバージョンとしてはv1.31.9・v1.33.1までの記載にとどまり、1.34は含まれていませんでした。

Claude Codeは「最新版である4.0.0を採用するのが良い」という方向で提案してくれましたが、3.7から4.0はメジャーバージョンアップにあたり、移行作業のコストも小さくありません。Kubernetes 1.34が未テストであることも踏まえ、Argo Workflowsのアップグレード自体をやめるのではなく、今回のEKSアップグレードにおける必須対応からは外す、という判断にしました。

External Secrets Operatorは、現行バージョンの0.16.2から最新の2.0.1まで、EKS 1.33には0.17.x以上、EKS 1.34には0.20.x以上が必要という前提がありました。特に0.19.0でCRDが肥大化し kubectl apply --server-sideが必須になった点が大きな変更でした。

Claude Codeは「Argo CD Applicationが管理する全リソースにServerSideApplyを適用すると良い」と提案してくれましたが、対応が必要だったのは肥大化したExternal Secrets OperatorのCRDだけだったため、そこにだけArgo CDのsyncOptionsでServerSideApply=trueを設定する方法をClaude Codeと一緒に整理しました。これらの例のように、調査はClaude Codeに手伝ってもらったとしても「最終判断は自分が責任を持って行う」というスタンスが重要です。

更新作業⁠：Claude Codeと並走しながらアップグレードを進める

更新作業について、安全性を高めるために実施していたことを紹介します。Claude Codeによる調査やクラスタの状態確認を行うシェルでは、意図しない破壊的変更を防ぐためにkubectxのread-onlyモード（--readonlyオプション）を適用していました。

❯ kubectx --readonly arn:aws:eks:ap-northeast-1:123456789012:cluster/my-eks-cluster
[READONLY SHELL] kubectl context is arn:aws:eks:ap-northeast-1:123456789012:cluster/my-eks-cluster in READ-ONLY mode — type 'exit' to leave.

更新作業の初めには、Amazon EKSのCluster Insights を使い、aws eks list-insightsでPASSINGを確認します。この機能自体、今回Claude Codeに教えてもらって初めて知りました。このAWS公式の自動チェックを、安全性確認の最後の砦として使っています。

更新作業の手順自体は、すでにEKSを運用している企業であれば既存のドキュメントがあるケースが多いでしょう。筆者の環境でも先人たちが積み重ねてきた資産があったため、ゼロから作り直すようなことはしていません。この事例では、ノードグループ入れ替えの失敗時におけるリカバリーフローを中心に、Claude Codeと一緒に見直し・アップデートを行いました。

トラブル対応

途中、Spotノードグループの入れ替えで残り7台ほどになったところでdrainが進まなくなりました。Podの入れ替え中に新しいReplicaSetがCrashLoopBackOffとなっており、イベントを見るとPDBが原因になっていそうでした。実際にClaude Codeへ投げたプロンプトは、次のようなものです。

❯ kubectl get pdb --all-namespaces -o wide | awk 'NR==1 || $5 == "0"'
NAMESPACE      NAME         MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
my-namespace   my-service   40%             N/A               0                     43h

PDB の ALLOWED DISRUPTIONS が 0 になっていて、drain が止まっています。
原因を整理してください。あわせて、考えられる対応策も教えてください。

Claude Codeと調査することで、ALLOWED DISRUPTIONSが0になっている原因を理解したうえで対応ができました。

• 全4台のPodのうち正常なのはRunningの2台（CrashLoopBackOffの2台はカウントされない）
• minAvailableは40% → 4台中2台（切り上げ）が必要
• ALLOWED DISRUPTIONS = 2（正常Pod⁠）⁠− 2（必要数）= 0

新しいReplicaSetが壊れ続けているせいで、退避可能なPodがないと判定されていたわけです。クラッシュしていたのは検証環境のアプリケーションだったため、恒久対応はCrashLoopBackOff自体の解消ですが、今回は対症療法としてPDBを削除する方針を取りました。

読者の方々も、万が一作業中にトラブルが発生した際にはkubectlコマンドでPodやノードの状況を可視化したうえで、原因や解決策の調査をClaude Codeに依頼してみてください。

更新後の作業⁠：Claude Codeでアップグレード前後を可視化する

作業証跡の可視化

アップグレード前後の状態を比較するため、Claude Codeにkubectl get nodes / kubectl get pods --all-namespaces / kubectl get deployments,statefulsets,daemonsets --all-namespaces相当のコマンドを実行してもらい、Before/Afterで出力を保存してもらいました。得られたレポートを抜粋します。

# 🎉 EKSアップグレード完了レポート

## ✅ アップグレード成功
Cluster: my-eks-cluster
期間: 2026-03-02 → 2026-03-03

## 📊 主要な変更

### Kubernetesバージョン
- Before: v1.32.11-eks-ac2d5a0
- After:  v1.34.4-eks-3a10415
- ✅ 2バージョンアップ成功

### ノード
- Before: 65台（v1.32.9: 65台）
- After:  75台（v1.34.4: 75台）
- ✅ 全ノードが v1.34.4 に統一
- 📈 10台増加（スケールアウト）

### ワークロード
- Deployments: 252 → 286 ✅
- StatefulSets: 5 → 5 ✅
- DaemonSets:   9 → 9 ✅

### Pod状態
- Before: 1,011 Pods
- After:  1,180 Pods
- 📈 Pod数増加は新ノード追加による正常な動作

ここで重要なのは、Claude Codeの「新ノード追加による正常動作」という推測をそのまま信じず、自分で裏取りをした点です。実際の調査では、ノード増加（65→75）は検証環境のオートスケール、Deployments 増加（252→286）は他チームのデプロイが原因でした。AIはもっともらしい理由を補完してしまいがちなため、出力されたメトリクスの増減に対して、現実の運用コンテキストと照らし合わせた妥当性確認は人間の責任で行う必要があります。

おわりに

この事例では、アップグレードの調査・判断・更新作業でのトラブル対応・作業証跡づくりのすべてにClaude Codeを組み込んだことで、一つひとつの作業の負担が着実に軽くなりました。

加えて、今回aws eks list-insightsという機能を活用できたのは、Claude Codeに教えてもらったからです。裏を返せば、教えてもらわなければ気づかないまま終わっていたということでもあり、AIに頼るだけでなく、自分自身も最新の仕様やベストプラクティスをキャッチアップし続ける姿勢が大切だと改めて感じました。

こうした気づきも含め、Claude Codeを活用することで自分の理解力そのものも引き上げられた実感があります。単なる作業代行ではなく、判断を研ぎ澄ます壁打ち相手として、今後もAIとうまく付き合っていきたいと思います。

次回に向けては、今回得られた知見をその場限りにせず仕組み化していきたいと考えています。チェックを仕組み化する発想も、当時は頭にありませんでしたが、今回のアップグレードを振り返る中で、AWS公式サンプルの sample-eks-upgrade-skill の存在を知りました。これを参考にしながら、今回のプロンプトやチェック観点を自分たちの環境向けのスキルとして育てていくつもりです。

読者のみなさんも本稿を参考にして、EKSアップグレードの作業にClaude Codeを取り入れていただければ幸いです。