Helmは、Kubernetesアプリケーションパッケージマネージャーとして公式にバージョン4.0.0に到達した。Helm 4は6年ぶりの大規模アップグレードであり、Cloud Native Computing Foundation（CNCF）の指導のもとでHelmの10周年を迎える節目でもある。このアップデートは、スケーラビリティ、セキュリティ、開発者のワークフローに関するいくつかの課題に対応することを目的としている。
Helm 4のSDKには、統合と開発者体験を向上させるためのいくつかの強化が含まれている。最新のGoロギングインターフェースを採用し、マルチロガーのサポートを可能にする。また、埋め込みコマンドによってHelmの機能を他のアプリケーションに直接組み込めるようになる。さらに、Helm 4はサーバーサイド適用（kubectl applyコマンドのロジックをAPIサーバーに移行するKubernetesの機能）をネイティブでサポートする。この変更は、Kubernetesエコシステム全体で進行中の広範なトレンドを反映しており、Helmを基盤とした統合が強力であり、現代のクラスタ挙動と物理的に整合性があることを保証する。
/filters:no_upscale()/news/2025/11/helm-4/en/resources/1Screenshot%20From%202025-11-30%2021-09-45-1764537293094.png)
プラグインシステムも再構築された。従来のHelmプラグインは引き続き機能するが、ユーザーはWebAssembly（WASM）でプラグインを作成でき、より広範な移植性を実現している。さらに、チャート配布、パフォーマンス、チャート署名およびテスト自動化のメカニズムにおいても改善が行われた。
これらの変更は、新機能の追加だけでなく、Helm v3時代に蓄積された設計上の負債を見直すことを反映していると、Helm共同創設者Rimantas Mocevicius氏のブログ投稿で述べられている。
HIP-0012（Helm Improvement Proposal）は、Helm 4を導く提案であり、2024年後半の計画段階から始まり、2025年中頃までのエンジニアリングを経て、2025年11月にリリースされる予定だった。提案は、チームが合理的な期間内に提供可能な機能開発を強調し、慎重に破壊的変更を導入することを目指していた。Kubernetes統合を対象とした改善、例えばサーバーサイド適用（SSA）、最新のプラグインアーキテクチャ、チャートAPIの改良などがロードマップに含まれていた。貢献者の関与やメンテナンスのバックログに関する問題も認識され、プロセス改善を通じて対処された。
より広範なユーザーの視点から見ると、Jimmy Song氏は自身のブログで、リリースが「テンプレートツールを超えて進化」し、Helmを現代化していると述べている。彼は、SSAの追加がGitOps手法により近づけるものであり、再現可能なビルド、プラグイン用のWASM、ステータス解析用のkstatusなどのツールがHelmを現代のKubernetesパラダイムに適合させると示唆している。これらの変更により、Helmは単なるチャートレンダラーから、よりデプロイメントオーケストレーターへと進化しているとSong氏は述べている。
Helmエコシステムにおけるより議論の多い問題の1つは、カスタムリソース定義（CRD）のサポートに関するものだ。新しいバージョンのマージ、バージョンリストへの追加、メタデータの保持、後方互換性のためのロールバックパスを確保するなど、より堅牢なCRD更新動作を提案する提案が提出されている。しかし、Helm 4の初期リリース時点では、これらの提案は組み込まれていない。Helmは、チャートインストール時に特別なcrds/ディレクトリに配置されたCRDをインストールするが、通常のアップグレードプロセスを通じてCRDをアップグレードまたは削除することはない。既存のドキュメントでは、crdsフォルダ内の更新されたCRDは警告のみでスキップされ、適用されないと警告している。
コミュニティのフィードバックは、この省略に対する失望を反映している。リリース直後のRedditディスカッションでは、ユーザーがCRD動作が改善されたかどうかを尋ねた。あるユーザーは「CRDに関する改善はまだないのか？::(」とコメントし、HelmがCRDライフサイクルを安全に管理できないままであることを指摘した。別のユーザーは、自社のツールとCLIワークフローが注釈ベースのCRDに依存しており、HelmのCRDロジックの変更に適応するのは容易ではないと報告した。
Heinan Cabouly氏のような他のコメントでは、Argo CDのようなGitOpsツールが数年前にすでにHelmの最大のワークフローギャップを解決していたと主張し、Helm 4は革新というよりも追いつくためのものだと示唆している。しかし、Helm 4は、プロジェクトの長期的な存続可能性を改善する重要なマイルストーンとして認識されており、単なるインクリメンタルな修正ではないと評価されている。
実務者やブロガーは、Helm 4のデプロイメント安全性の改善を歓迎している。特に、依存コンポーネント間の競合状態を減少させる新しい準備ベースのコントロールが評価されている。Pierre-Louis Gueugnon氏は、Enixのブログで、よりスマートなコンテンツベースのチャートキャッシュとパフォーマンス改善を称賛しており、頻繁かつ大規模なデプロイメントを行うチームにとって実用的な品質向上であると述べている。
今後、Helmのメンテナーは、v4で初期採用されなかった機能がマイナーリリースやHelm 5で検討される可能性があると示唆している。コミュニティは、CRDアップグレードが安全で安定し、広く採用されるほど十分に文書化される時期を注視している。