Helmとは｜Kubernetesのチャート作成と運用・Helm 4の変更点

Helmとは｜Kubernetesのパッケージ管理を担うツール

結論として、HelmはKubernetesマニフェストのテンプレート化と配布を担うツールです。aptやnpmがOS・言語エコシステムで果たす役割を、Kubernetesリソースに対して行うもの、と捉えると輪郭が掴めます。Helm公式サイトも自らを「Kubernetes用パッケージマネージャー」と位置づけています。

ただし、パッケージマネージャーという比喩だけでは実務像が見えません。実際に効いてくるのは、同じアプリを環境違いで何度も展開する場面です。

チャート・リリース・リポジトリの3語だけ押さえる

Helmの用語は多く見えますが、最初に必要なのは3つだけです。

重要なのは、同じチャートから名前の違うリリースを複数作れる点です。1つのクラスタにステージング用とレビュー環境用を並べる、といった運用がこれで成立します。

素のマニフェスト運用と何が変わるか

素のYAMLで運用すると、本番・ステージング・開発でほぼ同じファイルが3セット並びます。レプリカ数とイメージタグだけが違う、という状態です。

この構成は、変更が入った瞬間に破綻します。3ファイル全部に同じ修正を入れる必要があり、1つ忘れると環境差異として残ってしまう。

Helmではテンプレートを1つに保ち、差分をvaluesファイルに逃がします。修正はテンプレート1箇所で済む。

Helmが向く場面・向かない場面

向くのは、設定値の差し替えで表現できる差分を扱うケースです。イメージタグ、レプリカ数、リソース制限、Ingressのホスト名あたりは典型例です。

逆に、クラスタの状態を見て処理を分岐させたい、バックアップやフェイルオーバーを自動化したい、といった要件はHelmの守備範囲を超えます。そこはOperatorの領域で、判断基準はKubernetes Operatorとは｜CRDの仕組みと自作の判断基準に整理してあります。

またマニフェストをどう配信するか（Gitの状態をクラスタに同期させるか）は別レイヤーの話です。ArgoCDと組み合わせる設計はArgoCDとは｜GitOpsの仕組み・Kubernetes運用と案件動向を参照してください。

ミニFAQ：KustomizeとHelm、どちらを選ぶべき？

配布を伴わず自分たちのマニフェストにパッチを当てたいだけならKustomizeで足ります。第三者に配る／バージョンを切って配布する要件が入るとHelmが有利です。両方を併用し、Helmでレンダリングした結果にKustomizeでパッチを当てる構成も採用例があります。

Helmチャートの構造｜helm createで生成されるファイルの役割

結論から言うと、チャートで実際に手を入れるファイルはChart.yaml・values.yaml・templates配下の3箇所にほぼ集約されます。helm create コマンドで雛形を生成すると、次の構成が作られます。

Chart.yaml / values.yaml / templates の分担

Chart.yamlで特に効いてくるのがversionとappVersionの使い分けです。versionはチャート自体の版、appVersionは中で動くアプリの版を指します。ここを混同すると、アプリを変えていないのにチャートを配り直す羽目になります。

templatesに置くファイルは、通常のマニフェストに変数を差し込んだものです。値はvalues.yamlから .Values 経由で参照します。

values.yamlはあくまでデフォルト値です。実行時に別ファイルやコマンドラインで上書きされる前提で書きます。

テンプレートに値を流し込む仕組み

テンプレート記法はGoのテンプレートエンジンがベースです。最初のうちは、変数展開・条件分岐・繰り返しの3つが読めれば困りません。

公式のチャートのテンプレートに関するベストプラクティスには、インデントやクォートの扱いなど、実際にハマりやすい点が日本語でまとまっています。テンプレートを書き始める前に一読しておくと手戻りが減ります。

チャートの作り方とvalues設計

結論として、自作チャートは雛形生成 → 不要リソース削除 → values設計 → レンダリング確認 → パッケージ化の順で進めると迷いません。いきなり全部書こうとすると、テンプレートの文法エラーとKubernetesの仕様エラーが混ざって切り分けができなくなります。

Step1｜雛形を生成して不要なリソースを削る

helm create に続けてチャート名を渡すと雛形が生成されます。ここで生成されるIngressやHorizontalPodAutoscalerは、使わないなら最初に消してしまうのが実務的です。

雛形をそのまま残すと、使っていないテンプレートが値の分岐条件だけ残り、後から読む人が「これは動いているのか」を判断できなくなります。

Step2｜values設計（環境差分の切り出し方）

ここが自作チャートの品質を左右します。判断基準はシンプルで、環境によって変わる値だけをvaluesに出す。

「とりあえず全部valuesに出しておけば後で困らない」という設計にすると、values.yamlが数百行になり、どの値が実際に使われているのか追えなくなります。使われない設定項目は負債です。

なお、パスワードやトークンをvalues.yamlに直接書くのは避けてください。Secret管理は外部ツール（External SecretsやSealed Secretsなど）に寄せ、チャートは参照だけを持つ形が扱いやすくなります。

Step3｜レンダリング結果を確認してからクラスタに触る

チャートを書いたら、クラスタに適用する前にレンダリング結果のYAMLを目で見る工程を挟みます。helm template コマンドで、テンプレートに値を流し込んだ後の最終形が出力されます。

加えて helm lint で構文と推奨事項のチェックをかけます。この2つを通してからinstallすると、原因の切り分けが一気に楽になります。

Step4｜パッケージ化とリポジトリでの配布

配布が必要なら helm package でtgz形式に固め、チャートリポジトリに置きます。OCIレジストリをチャート置き場として使う構成も一般的になっており、コンテナイメージと同じレジストリで版管理できます。

公開チャートを探すときはArtifact Hubを使います。helm search hub コマンドからも同じインデックスを引けます。

複数valuesの重ね方と依存関係

環境差分は、values.yamlを1つにまとめるのではなく複数ファイルに分けて重ねるのが扱いやすい構成です。helm upgrade の -f（--values）は公式リファレンスでも「複数指定できる」と明記されており、共通値と環境固有値を分離できます。

後から指定したファイルの値が優先されるため、共通 → 環境別 → 一時的な上書き、の順に重ねる運用が定番です。

他チャートに依存する場合はChart.yamlのdependenciesに宣言し、helm dependency update で取得します。依存先のバージョンは範囲指定ではなく固定に寄せるほうが、再現性の面で安全です。

ミニFAQ：既存のマニフェストをチャート化する順番は？

先にhelm createで空の雛形を作り、既存YAMLをtemplatesにそのままコピーして、helm templateで元のYAMLと差分が出ないことを確認します。この時点では変数化しないのがコツです。差分ゼロを確認してから、環境で変わる箇所だけを順に変数へ置き換えていくと、事故が起きにくくなります。

リリース運用｜install / upgrade / rollback の回し方

結論として、日常運用で使うのは helm upgrade --install と helm rollback、それに状態確認系のコマンドが中心です。公式のUsing Helmに一通りの流れがまとまっています。

upgrade --install で冪等に回す

--install フラグは公式リファレンスで「if a release by this name doesn't already exist, run an install」と説明されています。初回か更新かをスクリプト側で判定する必要がなくなるため、CI/CDのデプロイステップは基本これ1本で書けます。

GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説で触れているような一般的なCIからも、このコマンドを呼ぶ形が扱いやすくなります。

リビジョン履歴とロールバック

installやupgrade、rollbackが実行されるたびにリビジョン番号が1ずつ増えます。helm rollback にリリース名とリビジョン番号を渡すと、その時点の状態へ戻せます。

保存されるリビジョン数には上限があり、helm upgrade の --history-max は公式リファレンス上デフォルト10です。0を指定すると無制限になります。10世代より前に戻したい要件があるなら、ここを明示的に引き上げておく必要があります。

なお、helm rollbackが戻すのはHelmが管理しているリソースの定義です。データベースのスキーマやPersistentVolume内のデータは戻りません。ここを混同したまま「ロールバックできるから安全」と考えると、本番で足をすくわれます。

タイムアウトとdry-run

--timeout は「個々のKubernetes操作の待機時間」で、公式リファレンスではデフォルト5分とされています。初回のイメージpullに時間がかかる構成では、ここが短すぎて失敗扱いになることがあります。

--dry-run は none / client / server のいずれかを取り、変更を永続化せずに動作を確認できます。serverを指定するとAPIサーバー側の検証まで通せるため、本番適用前の確認はこちらが確実です。

ミニFAQ：upgradeが途中で失敗したとき、リリースはどうなる？

中途半端に一部リソースだけ更新された状態で止まることがあります。helm history で直前の成功リビジョンを確認し、rollbackで戻すのが基本動作です。失敗時に自動で巻き戻す運用にしたい場合は、後述のフラグ（Helm 3では--atomic、Helm 4では--rollback-on-failure）を使いますが、巻き戻し完了までtimeoutを待つ点は把握しておいてください。

Helm 4の主な変更点と移行時の確認項目

本記事執筆時点（2026年9月）でHelm公式のバージョン対応表から確認できる最新メジャーバージョンはHelm 4系です。日本語の解説記事はHelm 3を前提としたものが多いため、移行前に公式ドキュメントで現行の記載を確認することをおすすめします。

公式ドキュメントで確認できる範囲を、確定している事項と実務対応に分けて整理します。

チャートは変えなくていい、スクリプトは変える

移行時に効いてくるのはこの一点です。チャート・テンプレート・valuesファイルはそのまま動く一方で、CLIを叩いている側（CI/CDのパイプライン、Makefile、運用スクリプト）が影響を受けます。

公式ドキュメントも、リネームされたフラグについて「Update any automation that uses these renamed CLI flags」と明記しています。移行前に、リポジトリ全体で --atomic と --force を検索しておくのが最初の一手です。

Kubernetesとのバージョン対応（n-3）

Helm 4はn-3の互換性モデルを採っています。あるKubernetesクライアント版に対してビルドされたHelmは、その版を含む過去3世代のKubernetesで利用できる、という設計です。

公式表では、Helm 4.3.xがKubernetes 1.37.x〜1.34.x、4.2.xが1.36.x〜1.33.xに対応する、といった形で整理されています。クラスタ側のバージョンが古い場合、Helmだけを最新にすると対応範囲から外れる可能性があるため、対応表で先に突き合わせてください。

リリース間隔は公式のリリースポリシーにあり、パッチは原則毎月第2水曜、マイナーは4か月ごと（年3回）とされています。バージョン追従の計画を立てるときの目安になります。

RBACとreadiness検出の変更に注意

Helm 4ではreadiness検出の仕組みが変更されています。これに関連して、--wait を使う構成ではServiceAccountに必要な権限が変わる可能性がある、という指摘がコミュニティの移行記事で見られます。一次情報として確定した記載を本記事では確認できていないため、断定はしません。

実務上の対応はシンプルで、移行検証を本番で行わないことです。まず検証用クラスタで --wait を含むパイプラインを一度通し、権限まわりで落ちないことを確認してから本番に進めてください。

よくある失敗と対策

実務でつまずきやすいのは、Helmの文法そのものよりも運用設計の詰めが甘い箇所です。

失敗1：values.yamlをコピーで増やしてしまう

環境が増えるたびにvalues-prod.yaml、values-stg.yaml…と全項目コピーした結果、共通値の変更が各ファイルに散ります。共通値は base のvaluesに置き、環境別ファイルには差分だけを書いて -f で重ねる構成にします。

失敗2：チャートのバージョンを固定していない

依存チャートや外部リポジトリのチャートをバージョン指定なしで参照すると、同じコマンドを叩いても時期によって結果が変わります。Chart.yamlのdependenciesと、CIで参照するチャートのバージョンは固定してください。

失敗3：Secretをvaluesに直書きする

values.yamlはGitに入る前提のファイルです。認証情報を書くと、そのままリポジトリに残ります。外部のシークレット管理に寄せ、チャート側は参照名だけを持つ形にします。

失敗4：Helm 4移行でCIが落ちる

--atomic や --force をそのまま使っているパイプラインは、フラグ名の変更で失敗します。移行前にgrepで洗い出し、検証環境で一度通しておけば回避できます。

失敗5：rollbackを万能だと思い込む

Helmが戻せるのはリソース定義です。マイグレーション済みのデータベーススキーマは戻りません。スキーマ変更を伴うリリースでは、アプリ側の後方互換設計をセットで考える必要があります。

Helmスキルが効くフリーランス案件と単価の目安

結論として、Helm単独での募集はほとんど見かけません。Kubernetes運用・CI/CD基盤構築のスキルセットの一部として要求される形が中心です。

以下の単価は、2026年9月時点で確認した主要フリーランスエージェント数社（首都圏中心）の公開案件の募集ページのうち、Kubernetes運用・SRE/DevOps領域に該当する数十件程度を観測ベースで整理した目安です。稼働は週3〜5日・準委任契約、実務経験3年以上の層を想定しています。Helmを要件として明記する公開案件はそれほど多くないため、周辺領域の募集条件を含めた幅のある目安として読んでください。

案件でHelmが登場する3つのパターン

上段ほど「Kubernetesが分かっていれば入れる」領域で、下段になるほど基盤全体の設計判断が求められます。単価が上がるのはHelmに詳しいからではなく、その周辺（クラスタ設計、権限設計、リリースプロセス設計）まで引き受けられるからです。

高い方のレンジで募集されやすいのは、Kubernetes本番運用を2〜3年以上経験し、CI/CDパイプラインの設計とIaCによる基盤構築の両方を単独で進められる層という印象です。この帯は非公開で打診されるケースもありますが、そちらは個別条件で大きく動くため、公開案件の数字とは分けて考えてください。

自分がどのレンジで評価されるか確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。Kubernetes関連の募集条件は案件一覧のKubernetesカテゴリから実物を見られます。

併せて評価されやすい周辺スキル

Helm単体ではなく、次のスキルと組み合わさったときに評価が上がります。

• IaCによる基盤構築（Terraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説）

• GitOpsによる配信設計（ArgoCD）

• コンテナ基盤の理解（Dockerとは？コンテナ技術の仕組み・できること・フリーランス案件の単価への影響を解説）

• 資格による裏付け（CKA資格とは｜Kubernetes認定の合格ライン・費用・出題範囲と勉強法）

SRE・DevOps領域全体の相場感はSREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安に、単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？に整理しています。

Helm導入・移行チェックリスト

着手前と移行前に、この一覧で抜けを潰してください。

チャートを新規作成するとき

• [ ] helm createの雛形から、使わないリソース（Ingress・HPA等）を削除したか

• [ ] Chart.yamlのversionとappVersionを使い分けているか

• [ ] valuesに出したのは環境で変わる値だけか

• [ ] 認証情報をvalues.yamlに直書きしていないか

• [ ] helm lintとhelm templateを通してからinstallしたか

• [ ] 既存YAMLからの移行なら、レンダリング結果が元と一致することを確認したか

運用を始めるとき

• [ ] CI/CDからはhelm upgrade --installで叩いているか

• [ ] --history-maxのデフォルト10世代で足りるか検討したか

• [ ] --timeoutのデフォルト5分で初回デプロイが完走するか確認したか

• [ ] 依存チャートのバージョンを固定したか

Helm 4へ移行するとき

• [ ] リポジトリ全体で --atomic と --force を検索し、新しいフラグ名へ置換したか

• [ ] ポストレンダラーに実行ファイルを直接渡していないか

• [ ] 公式のバージョン対応表で、クラスタのKubernetesバージョンが対応範囲内か確認したか

• [ ] --wait を使う構成で、検証クラスタでのパイプライン疎通を確認したか

まとめ

Helmは、Kubernetesマニフェストをテンプレート化して環境差分をvaluesに逃がし、リリース単位で更新・巻き戻しを管理するツールです。チャート・リリース・リポジトリの3語と、values設計の線引きさえ掴めば、実務で使う範囲はそう広くありません。

• 押さえる用語は3つ。チャート＝設計図、リリース＝実物、リポジトリ＝配布場所

• valuesに出すのは環境で変わる値だけ。全項目を出すとチャートが壊れやすくなる

• 既存YAMLからの移行は、まず変数化せずコピーして差分ゼロを確認してから進める

• 運用はhelm upgrade --installを基本形に。履歴はデフォルト10世代、タイムアウトはデフォルト5分

• rollbackが戻すのはリソース定義のみ。データは戻らない

• Helm 4への移行でチャートの書き換えは不要。直すのはCLIを叩くスクリプト側

• 案件ではHelm単独ではなく、Kubernetes運用・CI/CD・IaCとセットで評価される

次の一歩としては、手元のクラスタでhelm createから雛形を作り、既存のマニフェスト1つをチャート化してhelm templateで差分を確認するところから始めるのが確実です。そのうえでHelm 4への移行を検討するなら、まずリポジトリ内の --atomic と --force を洗い出してください。

参照した一次情報は以下のとおりです。

• Helm公式サイト

• Helm 4 Overview（公式ドキュメント）

• Using Helm（基本コマンドの解説）

• helm upgrade コマンドリファレンス

• Helmとkubernetesのバージョン対応表

• Helmのリリースポリシー

• チャートのテンプレートに関するベストプラクティス

• Artifact Hub（公開チャートの検索）