HashiCorp Nomadとは？アーキテクチャとKubernetesとの違い・採用判断を実装目線で解説

コンテナのオーケストレーターというとKubernetesが真っ先に挙がりますが、コンテナ以外のアプリケーションも同じ仕組みで動かしたい、あるいはKubernetesほどの運用負荷は抱えたくない、という現場も多く残っています。その受け皿になるのが HashiCorp Nomad です。Nomadはコンテナに加えてJavaアプリケーションや単体バイナリ、QEMUによる仮想マシンまでを1つのジョブ定義で扱える、単一バイナリのワークロードオーケストレーターです。本記事では、Nomadのサーバー/クライアント構成とスケジューラの動き、HCLで書くジョブ仕様の三層構造、Consul・Vaultとの連携、Kubernetesとの設計思想の違い、そして2.0系へ移った版管理の変更点までを技術者の実装目線で整理し、自社で採用が噛み合う条件と見送ったほうがよい場面まで言い切ります。

まとめ：Nomadは「コンテナも非コンテナも1つのジョブで束ねる」軽量オーケストレーター

先に要点を示します。詳細は各章で掘り下げます。

• Nomadの正体： HashiCorp製のワークロードスケジューラ兼オーケストレーター。単一バイナリで動き、コンテナ（Docker・Podman）だけでなく、単体バイナリ・Javaアプリ・QEMUのVMなど非コンテナのワークロードも同じ枠組みで配置・管理できる。
• 構成： サーバーエージェント（Raftで合意を取りリーダーが状態を持つ）とクライアントエージェント（実際にタスクを走らせる）の2役だけ。制御プレーンの部品点数がKubernetesより少なく、運用の見通しが立てやすい。
• ジョブ仕様： HCL（HashiCorp Configuration Language）で書く。1本のジョブファイルにJob→Group→Taskの三層を宣言し、望ましい状態を書けばスケジューラが差分を埋めて自己修復する。
• 不足機能の補完： サービスディスカバリやサービスメッシュはConsul、シークレット管理はVaultと組み合わせて補う。単体では機能を絞り、周辺は同社スタックで足す設計。
• Kubernetesとの距離： 対象ワークロードが広く運用が軽い一方、CNCFのような巨大なエコシステムやマネージドサービスの厚みでは劣る。「複雑さの回避」を取るか「エコシステムの厚み」を取るかの選択になる。
• 版番号： 2.0系が公開中（2026年7月時点）。2026年4月の2.0.0からIBMのV.M.F（Version-Modification-Fix）方式へ版管理が移り、春・秋の機能リリースと月次の修正リリースで回る。

Nomadとは何か：ワークロードオーケストレーターとしての位置づけ

Nomadは、アプリケーションをクラスタ上のどのマシンで動かすかを決め、起動・再起動・スケールまでを自動化するスケジューラです。HashiCorpがオープンソースとして開発しており、単一のGoバイナリで提供されます。エージェントを1つ立ち上げれば、それがサーバーにもクライアントにもなり、開発用の単一ノードから本番の大規模クラスタまで同じバイナリで構成できます。

Nomadを特徴づけるのは、扱えるワークロードの幅の広さです。Kubernetesがコンテナ（正確にはPod）を前提に組まれているのに対し、Nomadは「タスクドライバー」という抽象を挟むことで、Dockerコンテナ、staticにビルドした実行ファイル、Javaのjar、QEMUの仮想マシンイメージなどを同じジョブの記法で並べられます。コンテナ化しきれていないレガシーな業務アプリと、新規のコンテナサービスを、同じクラスタ・同じ運用フローに載せられるという点が、移行期の現場で効いてきます。

オーケストレーターという言葉そのものの整理や、コンテナ領域に限らないIT自動化との違いを押さえたい場合は、上位概念としてオーケストレーションとは？自動化との違いと種類・企業の導入判断を解説もあわせて参照すると、Nomadがどの層の道具なのかが見えやすくなります。そもそもコンテナとは何かという前提から確認したい場合はコンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説が土台になります。

Nomadのアーキテクチャ：サーバーとクライアントの2役で成り立つ構成

Nomadの制御プレーンは、覚えるべき役割が少ないのが持ち味です。ここがKubernetesとの体感差を生む部分なので、構成要素を分解します。

サーバーとクライアントという2種類のエージェントの役割分担の仕組み

Nomadのエージェントは、起動時の設定でサーバーモードかクライアントモードかを選びます。サーバーはクラスタの状態管理を担い、複数台でRaftコンセンサスを組んでリーダーを1台だけ選出。リーダーがジョブの受付とスケジューリング判断を行い、フォロワーが状態を複製することで、サーバー1台が落ちても可用性を保ちます。本番では3台または5台構成が定石です。クライアントは各ノードで動き、割り当てられたタスクを実際に起動し、ヘルスとリソース使用量をサーバーへ報告します。役者はこの2つだけで、外部のキーバリューストアを別途立てる必要もありません。

スケジューラとビンパッキング方式によるアロケーション配置の決定

ジョブが投入されると、サーバー上のスケジューラが「このタスクをどのクライアントに置くか」を決めます。既定はビンパッキング（bin-packing）方式で、空いているノードへ詰め込むように配置し、リソースの無駄を抑える設計。スケジューラはservice・batch・system・sysbatchといったジョブ種別ごとに配置方針を変え、常駐サービスは分散、バッチ処理は空きノードへの充填、systemジョブは全ノードへ1つずつ、といった振る舞いを取ります。配置は「アロケーション（allocation）」という単位で管理され、どのタスクがどのノードのどのアロケーションで動いているかを追跡できます。

タスクドライバーによりコンテナ以外のワークロードも動かす仕組み

Nomadが非コンテナのワークロードまで扱える鍵が、タスクドライバーです。ドライバーは実行環境を抽象化するプラグインで、docker ドライバーならDockerコンテナ、exec や raw_exec ドライバーならホスト上のバイナリ、java ドライバーならjar、qemu ドライバーならVMイメージを起動します。ジョブ定義では driver = "docker" のように1行で切り替えられるため、種類の違うワークロードを1つのクラスタへ混在。コンテナ前提のプラットフォームを新設せずに、既存資産を段階的に載せていける柔軟さがここにあります。

ジョブ仕様（HCL）の構造とJob・Group・Taskの三層で宣言する書き味

Nomadの運用は「1本のHCLファイルに望ましい状態を書き、投入する」に集約されます。この宣言的な書き味は、インフラをコードで管理する発想と地続きです。前提となる考え方はIaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説で整理しているので、宣言的定義に馴染みがなければ先に押さえておくと理解が早くなります。

JobからGroup・Taskへ入れ子で連なるジョブ仕様の三層構造

ジョブ仕様は入れ子の三層で構成されます。最上位が job で、デプロイの単位です。その中に group（同一ノードにまとめて配置したいタスクのまとまり＝KubernetesのおおよそのアナロジーはPod）があり、さらにその中に task（実際に動く1プロセス）が入ります。groupには count でレプリカ数を、taskには使用するドライバー・イメージ・リソース（CPU・メモリ）・ネットワークまでを宣言。この階層を1ファイルに書き切れるため、アプリ1つの構成を1つのファイルで見通せます。KubernetesがDeployment・Service・ConfigMapなどを別リソースに分けて記述するのに対し、Nomadは関連する定義を1本のジョブに束ねる方向を取っています。

望ましい状態の宣言による自己修復とローリングアップデートの仕組み

投入されたジョブは「望ましい状態（desired state）」として保存され、Nomadは実際の状態との差分を絶えず埋めようとします。タスクが異常終了すればスケジューラが再配置し、ノードが丸ごと落ちればそのノードで動いていたアロケーションを健全なノードへ移し直す。バージョンを上げるジョブを再投入すれば、update スタンザの指定に沿ってローリングアップデートやカナリアデプロイを行い、失敗時には自動ロールバックもかけられます。運用者が個々のプロセスを手で面倒みるのではなく、あるべき姿を宣言してNomadに収束させる、という運用モデルです。

ConsulとVaultとの連携でNomad単体の機能不足を補う

Nomadはスケジューリングに機能を絞っており、サービスディスカバリやシークレット管理は同社の別プロダクトと組み合わせて補う設計です。ここはKubernetesが標準機能や豊富なアドオンで自己完結しがちなのと対照的で、Nomadを検討する際の前提になります。

Consulを組み合わせると、Nomadが起動したタスクを自動でConsulのサービスカタログへ登録し、サービス間のディスカバリや動的な名前解決、さらにConsul Connectによるサービスメッシュ（サイドカープロキシによる相互TLS通信）まで構成できます。サービスメッシュの仕組みそのものはサービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説で扱っているため、Consul Connectの位置づけの理解にはそちらが近道。Vaultを組み合わせれば、データベース資格情報やAPIキーといったシークレットを、ジョブ定義から動的に払い出して各タスクへ渡せます。なお2026年時点のNomad 1.10系以降では、Consul・Vault連携がレガシーなトークン方式から Workload Identity ベースへ移行しており、新規構築ではこの方式が前提になる点に注意してください。

NomadとKubernetesの違いを設計思想と運用負荷から捉える

両者はどちらもオーケストレーターですが、狙いどころが異なります。優劣ではなく、何を引き受け何を切り捨てたかの違いとして見るのが実務的です。Kubernetesを軸に据えたコンテナオーケストレーション全体の判断枠組みは、判断ハブとしてコンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説にまとめてあるので、本記事の技術解説とあわせて読むと選定の解像度が上がります。

対象ワークロードの広さと制御プレーンを構成する部品点数の違い

最大の違いは対象範囲です。Kubernetesはコンテナ（Pod）を前提に、そのぶんコンテナ運用に必要な機能を深く揃えています。Nomadはコンテナに限定せず、非コンテナのワークロードも同じ土俵に載せる代わりに、コンテナ固有の機能は薄めです。構成部品でも差が出ます。Kubernetesはkube-apiserver・etcd・スケジューラ・コントローラマネージャ・kubelet・kube-proxyなど複数のコンポーネントで成り立ち、加えてCNIやIngressコントローラなどを選定して組み上げます。Nomadはサーバーとクライアントの単一バイナリが基本で、必要に応じてConsul・Vaultを足す構成です。

コンポーネント数の差が生む学習コストと運用負荷の実務的な重み

この部品点数の差は、そのまま学習コストと運用負荷に跳ね返ります。Kubernetesは表現力が高い反面、YAMLで多数のリソースを書き分け、クラスタのアップグレードやネットワーク・ストレージのアドオン管理まで運用者の負担は大きめ。Nomadは覚える抽象が少なく、1つのHCLジョブで完結しやすいぶん、少人数チームでも運用を回しやすい傾向があります。下表に主要な観点を整理します。

表の各行は「どちらが優れているか」ではなく「どちらの前提に自社が近いか」を測る物差しです。次章でこの物差しを採用判断に落とします。

Nomadを採用すべき条件と見送るべき場面を実装目線で言い切る

ここは競合記事が比較表で止めがちな部分です。踏み込んで、条件付きで判断を示します。

HashiCorp Nomadの採用が噛み合う具体的な4つの条件

Nomadが刺さるのは、次のいずれかに当てはまる現場です。第一に、コンテナ化しきれていない業務アプリとコンテナサービスが混在し、両者を1つの運用に載せたい場合。raw_execやjavaドライバーで既存資産をそのまま載せられるため、全面コンテナ化を前提にせず移行を始められます。第二に、少人数でインフラを回しており、Kubernetesの運用体制まで抱えられない場合。単一バイナリと1ファイルのジョブ仕様は、専任チームを置きにくい組織で現実的です。第三に、すでにConsul・Vault・Terraformといった同社スタックを使っており、HCLと運用文化を共有できる場合。宣言的なジョブ管理の考え方はIaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説の延長線上にあり、既存のIaC運用と地続きに扱えます。第四に、データセンターやエッジ、複数クラウドにまたがってワークロードを分散したい場合です。もっとも、どのオーケストレーターを選ぶにせよ、クラスタ基盤の設計・移行・運用体制づくりは片手間では回りにくい領域。自社に専任を置きにくい段階でNomadやKubernetesの導入を検討するなら、AWS・Google Cloud・Azureのインフラ構築支援のように、要件定義から基盤設計・移行までを外部と組む選択肢も現実的です。

HashiCorp Nomadを見送るべき・過剰投資になる場面

逆に、Nomadを避けたほうがよい場面もはっきりしています。まず、Helm・Operator・多数のCNCFツールといったKubernetes前提のエコシステムを積極的に使いたいなら、Nomadでは道具立てが揃わないのが弱点。次に、EKS・GKE・AKSといったマネージドKubernetesで運用そのものをクラウド側へ委譲したい場合、マネージドNomadの選択肢は限られるため、運用移譲のうまみを取りにくくなります。採用市場も無視できません。Kubernetesの経験者は母数が大きく、Nomad人材は相対的に希少です。属人化を避けたい組織では、この人材供給の差が長期の運用リスクになります。純粋にコンテナだけを大規模に動かし、周辺ツールもフルに使う前提なら、Nomadの「軽さ」より Kubernetesの「厚み」が効くと判断してよいでしょう。

ソフトウェアライセンスとIBM移行後の版管理の変化を採用判断に織り込む

採用判断には、技術面だけでなくライセンスと版管理の変化も織り込む必要があります。Nomadを含むHashiCorp製品は2023年にBSL（Business Source License）1.1系へ移行しており、競合SaaSとして提供する用途に制限がかかる点は事前に確認しておくべきです。加えて、HashiCorpのIBM傘下入りに伴い、2026年4月の2.0.0リリースからバージョニングがセマンティックバージョニングからV.M.F（Version-Modification-Fix）方式へ切り替わりました（2026年7月時点で2.0系が公開中）。以降は4月に「V」の新サポートライフサイクル、10月に「M」の機能追加、月次で「F」の修正、という周期で回ります。旧モデル最後のLTSである1.10系はサポート終了が2027年4月に設定されているため、長期運用を見込むなら2.0系以降を前提に検証を進めるのが無難です。版番号や具体的な機能はHashiCorpの公式Release Notesで実測し、「2.0系（2026年7月時点）」のように時点を添えて扱うことをおすすめします。

HashiCorp Nomadの導入検討でよくある質問と回答

Nomadの検討時に実際に挙がりやすい質問へ、簡潔に答えます。

NomadとKubernetesはどちらを選ぶべきですか？

コンテナ以外のワークロードも束ねたい、少人数で運用したい、HashiCorpスタックを既に使っている、といった条件が揃うならNomadが噛み合います。逆に、Kubernetes前提のエコシステムを積極的に使いたい、マネージドサービスへ運用を委譲したい、K8s人材を確保したい場合はKubernetesが向きます。「複雑さの回避」か「エコシステムの厚み」かで分けるのが実務的な判断軸です。

Nomadはコンテナ以外のアプリケーションも動かせますか？

動かせます。タスクドライバーという抽象により、Dockerコンテナのほか、staticにビルドした単体バイナリ（exec/raw_exec）、Javaのjar（java）、QEMUの仮想マシン（qemu）などを同じジョブ記法で扱えます。コンテナ化が済んでいないレガシーアプリと新規のコンテナサービスを、同一クラスタ・同一運用に載せられる点がNomadの強みです。

Nomad単体でサービスディスカバリやシークレット管理はできますか？

Nomadはスケジューリングに機能を絞っているため、本格的なサービスディスカバリやサービスメッシュはConsul、シークレット管理はVaultと組み合わせて補うのが基本設計です。簡易なサービス登録はNomad単体でも可能ですが、動的な名前解決や相互TLS、動的なシークレット払い出しを行うなら周辺プロダクトの併用を前提に構成します。

Nomadの設定はどの言語で書きますか？

HCL（HashiCorp Configuration Language）でジョブ仕様を記述します。1本のジョブファイルにJob→Group→Taskの三層と、レプリカ数・リソース・ネットワーク・アップデート方針までを1ファイルに宣言。KubernetesがYAMLで複数リソースに分けて書くのに対し、Nomadは関連する定義を1ファイルに集約する方向で、TerraformなどのHCL運用と記法を共有できます。

Nomadの最新バージョンと版管理はどうなっていますか？

2026年7月時点で2.0系が公開中です。2026年4月の2.0.0からIBMのV.M.F（Version-Modification-Fix）方式へ移り、4月に新サポートライフサイクル、10月に機能追加、月次で修正、という周期になりました。旧モデル最後のLTSである1.10系はサポート終了が2027年4月です。正確な版番号は公式Release Notesで確認し、時点を添えて扱ってください。

関連記事

• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説：NomadとKubernetesの選定を、より上位の「自社にオーケストレーターが必要か」の視点から整理した判断ハブ記事です。
• オーケストレーションとは？自動化との違いと種類・企業の導入判断を解説：コンテナ領域に限らないオーケストレーションの全体像と、自動化との違いを押さえたいときの土台になります。
• コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説：Nomadが扱うワークロードの中心であるコンテナの前提知識を、仮想マシンとの違いから確認できます。
• サービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説：NomadとConsul Connectで構成するサービスメッシュの仕組みを理解する助けになります。
• IaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説：HCLによる宣言的なジョブ管理の背景にある、インフラをコードで扱う考え方を整理しています。