こんにちは。株式会社ユーザベース エキスパート事業「NewsPicks Expert」の開発をしている長島です。
NewsPicks Expert では、インフラ基盤に Kubernetes、パッケージマネージャに Helm を採用しています。
私たちのチームでは、Helm のアップデート作業における情報収集&更新可否をまるっと AI に任せられないかと試行錯誤しており、それがある程度形になってきたため、本記事にてその実装過程と得られた知見について共有したいと思います。
本題に入る前にさらっと AI レビューを導入する前のアップデート作業の流れについて書いておきます。
-
Renovate が依存関係の更新を検知して PR を自動作成
-
GitHub Actions が現状と更新後のマニフェスト差分をコメント
-
【手動】差分コメントを確認
-
【手動】更新されるバージョンのリリースノートを確認
-
【手動】影響範囲を判断
-
問題なければ PR をマージしてアップデート
Renovate による自動 PR 作成から GitHub Actions での差分可視化までは自動化されているので、あとは差分を確認してマージして OK かを判断するだけではあるのですが、これが地味に大変。
最後の「マージして大丈夫？」という判断の心理的ハードルが私にとっては割と高かったんですよね。各 Helm チャートの特性や過去の更新履歴への理解がまだ浅く、リリースノートの精査と影響範囲の検討には毎回結構時間がかかるので、月次のアップデート作業が億劫になっていました。
こんな状況を改善したく「差分検証からマージ判断まで AI に丸投げできないか？」と考え始めたわけですが、かといってすぐにうまくいくわけでもなく、少しずつ改善してやっと実用的なレベルに持っていけたかな？といった感じです。
本日までの試行錯誤の記録と更なる改善課題について書かせていただきます。少しでも皆様の参考になれば幸いです。
まずはスラッシュコマンドの作成
Claude Code のスラッシュコマンドを一言で言うと「ターミナル内で Claude に指示を出すためのショートカット」です。毎回プロンプト書くの大変ですからね。
詳しく知りたい方は公式ドキュメントを貼っておきますのでご覧ください。
とりあえず、Claude Code のスラッシュコマンドとして /review-renovate を作成しました。
/review-renovate [helm-release-name]
このコマンドを実行すると、指定した Helm リリースに関する Renovate PR を検索し、レビューを開始します。このコマンドの中に Claude への指示を書く感じですね。
とりあえず実行してみる
Github の対象のプルリクエストにコメントするようにプロンプトを書いたので、画像のような形でコメントが追加されました。
これで自動化完了！とはもちろんいかず。
とりあえずは動いたけど、
- 書いている変更点があっているか判断できない
- どのバージョンでどの変更があったのかわからない
- 結局 kubectl コマンドを使って環境を見に行かないといけない
などなど問題がたくさんあります。ここから少しずつプロンプトを調整していったので、それぞれでどう改善していったのかを紹介できればと思います。
※ プロンプトの改修履歴を残しておけば before / after で改善方法をお見せできたのですが、ローカルでごちゃごちゃやっていたので詳細にはお見せできず。。
覚えている範囲でプロンプトのどこを改善したのかも書きたいと思います。
改善①: エビデンスの明確化
課題: 記載内容に信頼性がない
🔍 主な変更点 - ✅ セキュリティ更新: GO-2025-3372フレームワーク修正、containerd、golang/glogの更新 - 🆕 新機能: OPA rego v1構文サポート（v0構文は非推奨） - ⚠️ 運用変更: CRDとVAP/VAPB生成にOperation `generate`フラグが必要 - 🐛 バグ修正: ビルド問題修正、ネストしたループパフォーマンス改善 - Breaking Changes: なし（運用要件変更のみ）
こんなふうに書いてあっても、結局内容があっているか確認しないといけないのでむしろ作業が増えてマイナスです。
改善
レビュー結果の信頼性を高めるため、すべての判断にエビデンスを付けるようにしました。
実際のプロンプトの該当部分を抜粋:
### 📋 コミット詳細 (uzabase/helm-charts) - **コミット**: [`abc1234`](https://github.com/uzabase/helm-charts/commit/abc1234...) - **変更内容**: values.yaml のデフォルト値を更新 ### 📋 リリース詳細 - **リリースノート**: [v3.19.0](https://github.com/external-secrets/external-secrets/releases/tag/v3.19.0) - **変更内容**: 新しい認証方式のサポートを追加
余談ですが、弊社では独自に helm chart を管理しているものもあるので、その場合は対象レポジトリのコミット履歴を追うようにしています。
結果
#### v0.17.0 - **リリースノート**: [v0.17.0](https://github.com/external-secrets/external-secrets/releases/tag/v0.17.0) - **Breaking Changes**: v1beta1 API のサポート終了 - **新機能**: 1Password SDK プロバイダー追加、Infisical のパスサポート強化
どのソースをもとに記載しているのかを明記してくれるようになったので、人間による確認も容易になりました。
現状では基本 Breaking Changes の記載がある部分などを人間の目でも軽くチェックするようにしています。
改善②: バージョンごとの詳細分析
課題: バージョンアップの幅が大きいと、情報が欠落する傾向あり
月次でのアップデート作業で、かつ毎回全ての helm チャートをアップデートし切れるわけではないので、複数バージョンジャンプするなんてこともしばしばあります。
そういった helm chart のアップデートの際に下記のような問題が起きました。
- 最新バージョンのリリースノートしか見ない
- 途中のバージョンの Breaking Changes を見逃す
アップデートが大きくなるほど顕著に現れる現象でした。
改善
複数バージョンの変更を漏れなく確認するため、マイナーバージョンアップを一つの単位として、それぞれ分けて評価分析してもらうようにしました
実際のプロンプトの該当部分を抜粋:
### ステップ 4: バージョン分析 1. **更新タイプの分類**： - メジャー（1.x → 2.x）：高リスク、破壊的変更の可能性大 - マイナー（1.1 → 1.2）：中リスク、新機能 - パッチ（1.1.1 → 1.1.2）：低リスク、バグ修正 2. **メジャー・マイナーバージョン更新時の評価方法**： - **重要**: メジャーおよびマイナー更新では、**各バージョンごとに個別に評価**すること - 例: v1.5.0 → v1.7.0 の場合 - v1.5.0 → v1.6.0 の変更を評価 - v1.6.0 → v1.7.0 の変更を評価 - それぞれのバージョンの変更内容を明記 - パッチバージョン更新は集約して評価可能 3. **複数バージョンジャンプの場合**（例：3.18.2→3.19.0）： - すべての中間バージョンを分析 - バージョン間の変更を集約 - 累積的な影響を強調
結果
#### v0.17.0 - **リリースノート**: [v0.17.0](https://github.com/external-secrets/external-secrets/releases/tag/v0.17.0) - **Breaking Changes**: v1beta1 API のサポート終了 - **新機能**: 1Password SDK プロバイダー追加、Infisical のパスサポート強化 #### v0.18.0 - **リリースノート**: [v0.18.0](https://github.com/external-secrets/external-secrets/releases/tag/v0.18.0) - **Breaking Changes**: AWS Provider が AWS SDK v2 へ移行 - **新機能**: MFA トークンジェネレーター、IBM カスタム認証情報サポート #### v0.19.0 - **リリースノート**: [v0.19.0](https://github.com/external-secrets/external-secrets/releases/tag/v0.19.0) - **Breaking Changes**: CRD サイズ増加により `kubectl apply --server-side` または ArgoCD の `ServerSideApply=true` 設定が必要 - **新機能**: SSH キージェネレーター、Infisical 認証方法拡張 #### v0.20.0-v0.20.3 - **リリースノート**: [v0.20.0](https://github.com/external-secrets/external-secrets/releases/tag/v0.20.0), [v0.20.1](https://github.com/external-secrets/external-secrets/releases/tag/v0.20.1), [v0.20.2](https://github.com/external-secrets/external-secrets/releases/tag/v0.20.2), [v0.20.3](https://github.com/external-secrets/external-secrets/releases/tag/v0.20.3) - **新機能**: - コントローラーの Liveness Probe 追加 - GCP Workload Identity Federation サポート - Vault Provider の Pod Identity 認証サポート - メトリクスのセキュアサービング - **バグ修正**: 多数の Provider 固有の問題修正、依存関係更新
バージョンごとのまとまりを意識できるようになったのか、それぞれのバージョンにおける変更内容の詳細度が上がっています。
改善①でエビデンスも明確化してあるので、大分信頼度が上がったんじゃないでしょうか。
改善③: 実環境の設定を確認する
課題: 自分たちの環境で必要な設定なのかがわからない
例えば
v1beta1 API のサポート終了したので要確認
と言われても、結局現環境の状態を helm ファイルを見たり手動で kubectl コマンドを叩いての確認が必要でした。
なんならその機能を使っているか？の確認から必要なケースもあるので結構しんどい。そこまで見に行ってほしい。
改善
helm file の確認とは別に、kubectl コマンドを使って対象の環境の設定を確認してもらうようにしました。
実際のプロンプトの該当部分を抜粋:
#### 3-2. 現環境調査 1. **kubectl コンテキストの切り替え**： 2. **現環境の確認対象**： - 現在の Deployment/StatefulSet/DaemonSet 等の設定 - ConfigMap や Secret の内容（機密情報に注意） - 実行中のコンテナの引数やフラグ - 非推奨機能の使用状況 - CRD や API バージョンの互換性 3. **確認の原則**： - **読み取り専用コマンドのみ使用**（get, describe, logs 等） - **環境を変更するコマンドは絶対に実行しない**（apply, delete, patch, edit 等） - 機密情報を含む可能性のある Secret の内容は詳細に表示しない 4. **確認すべき重要ポイント**: - 現在使用中の設定値 - リソースの構成状況 - 環境固有の制約や特殊設定 - 過去の変更履歴
書き込み系のコマンドはプロンプトの中でも禁止していますが、ClaudeCode の settings.json の deny ルールにも記載しています。
{ "permissions": { "allow": [ // 許可するコマンド群 ], "deny": [ "Bash(kubectl apply:*)", "Bash(kubectl delete:*)", "Bash(kubectl patch:*)", // その他、環境を変更する可能性のあるコマンド ] } }
これにより、万が一プロンプトを無視して危険なコマンドを実行しようとしても、システムレベルでブロックされます。
結果
🔍 変更内容と影響 環境への影響評価 v1beta1 API 削除: 環境は既に external-secrets.io/v1 を使用中のため影響なし ✅ AWS SDK v2 移行: 現環境では AWS Provider を使用していないため影響なし ✅ CRD サイズ増加: v0.19.0 以降の CRD は大きくなり、ArgoCD の ServerSideApply 設定が必要 ⚠️ GCP Workload Identity Federation: 既存の GCP Workload Identity 設定に影響なし ✅
先ほど例に出した「v1beta1 API 削除」への対応が現環境で必要なのかどうかを確認し表示してくれています。いい感じ。
改善③続き: ナレッジを蓄積
改善③ で kubernetes の環境設定を見に行くようにしましたが、毎回環境を見に行ってもらうのも無駄なので確認内容を記録してもらうことにしました。
現状取得した環境情報は以下の構造で保存するようにしています。
.agent-doc/knowledge/
├── dev/
│ └── external-secrets/
│ ├── current-config.md # 現在の環境設定
│ └── renovate-history.md # 過去の評価履歴
└── prd/
└── external-secrets/
├── current-config.md
└── renovate-history.md
これにより、アップデート対象の helm チャートに関する評価履歴や環境設定を事前に確認し、その情報をもとに評価することになります。
ここは最近運用を始めたところなので効果があるかは微妙なところですが（コンテキストが過剰になっちゃうかも？）、とりあえずこれでしばらく様子を見たいと思います。
ここまで色々改善した後、実際の運用で評価してもらった出力はこんな感じです。
ちょっと情報量が多すぎる気もしますが、割といい感じになったのではないでしょうか。
今後もやりながら改善していきますが、一旦はこの形をベースに運用していこうと思います。
一次レビューを任せられるようになってきたとはいえ、作業時間が劇的に短くなったりはしていないので、今後は AI に任せる範囲をもう少し広げたいと思っています。
現在は手動でコマンド実行していますが、Claude Code Actions 等を活用して PR 作成・更新時に自動レビューできるようにしたいです。
また、「〇〇の設定変更が必要」となった場合に、その変更を自動で行って PR まで作成してくれるようになれば、さらに効率化できそうだなーと想像しているところです。
現在の環境設定の記録がある程度溜まったら、これらの自動化にも挑戦してみようと思います。
Renovate の PR レビューを Claude Code に任せることで、月次の更新作業に取り組みやすくなりました。完璧な自動化とまではいきませんが、「マージして大丈夫？」という心理的ハードルが下がったのは大きな成果だと感じています。
実環境の情報を kubectl で取得させるというアプローチは、試した中で特に効果的だったなーと思います。リリースノートだけでは分からない「うちの環境ではどうなの？」に答えられるようになったので、評価の質があげられたなと。
とはいえ、一次レビューをさせられるようになっただけでまだまだ改善の余地はあるので、今後も色々と試していきたいと思います。
ここまで読んでいただきありがとうございました。もっと良いアプローチや Claude Code の活用アイデアがあれば、ぜひコメント等で教えてください。同じような課題に取り組んでいる方との情報交換ができれば嬉しいです。
