Nomadのシステム開発の発注/外注/依頼/委託方法について

Nomadのシステムを発注・外注するなら、Nomadのインストールだけではなく、アプリケーションの移行、CI/CD、ネットワーク、監視、秘密情報管理、障害対応までを含む「本番実行基盤」として要件と責任範囲を決めることが重要です。

HashiCorp Nomadは、コンテナだけでなくJava、Windows、VM、バッチなどのワークロードもクラウド・オンプレミス・エッジで動かせるワークロードオーケストレーターです。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、契約後の進め方までを、Nomadのシステム開発を依頼する担当者向けに解説します。

▼全体ガイドの記事
・Nomadのシステム開発の完全ガイド

Nomadのシステムを発注する前に知る全体像

Nomadのシステム開発を外注する際は、製品の導入作業と、Nomad上で動かす業務アプリケーションの開発を分けて考えます。Nomadは業務画面やCRMを作るフレームワークではなく、アプリケーションをどのサーバーでどの条件で動かすかを管理する実行基盤です。

Nomadが担うのは、ジョブ定義に基づく配置、リソース制約を考慮したスケジューリング、ローリングアップデート、カナリアリリース、再配置、障害時の復旧などです。ジョブ仕様をGitで管理し、CI/CDからNomad APIへ送信することで、手作業によるサーバーごとのデプロイを減らせます。

一方で、クラウドのネットワークやVMを作る処理、データベースの設計、アプリケーションのコンテナ化、業務ロジック、ログ分析基盤、バックアップ方針はNomadだけでは完結しません。Terraformはインフラのプロビジョニング、Consulはサービスディスカバリや通信、Vaultはシークレット管理を担うため、発注時に各製品の担当範囲を切り分ける必要があります。

少数のサーバーとサービスを手作業で運用しているだけなら、Nomadを導入せず、既存のsystemdやクラウドのマネージドサービス、Terraformの整備で目的を達成できる場合があります。導入目的は「Nomadを使うこと」ではなく、デプロイ時間の短縮、属人運用の削減、複数環境への可搬性、既存アプリの統合などの業務上の成果に置き換えます。

反対に、コンテナとレガシーアプリを同じ運用ルールで扱いたい、クラウドとオンプレミスにワークロードを分散したい、バッチやシステムジョブを宣言的に管理したいという場合は、Nomadの検証価値が高まります。Kubernetesと比べて優劣を先に決めるのではなく、対象ワークロード、運用人員、必要なエコシステム、将来のマネージドサービス利用方針で判断します。

Nomadのシステム発注形態はどれを選ぶべきですか？

発注形態は、結論として、社内の技術力と求める責任範囲で選びます。PoCだけなら技術支援型、本番移行まで任せるなら請負または準委任を組み合わせた段階発注、24時間の運用まで必要なら運用保守契約を別に設ける形が現実的です。

Nomadが自社のワークロードに合うか分からない段階で、本番環境全体の構築を一括発注するのは危険です。最初は2〜6週間程度のPoCとして、数ノードのクラスタ、DockerまたはRaw exec、基本的なジョブ定義、簡易CI/CD、サービス登録、ログ取得を対象にします。これはリサーチノートと一般的な基盤構築の工数から整理した目安であり、Nomad公式の標準期間ではありません。

PoCの合否判定は、画面が表示できたかだけでは足りません。ジョブのローリング更新、異常終了からの復旧、ノード障害、ネットワーク分断、ACL拒否、証明書更新、ログ確認、バックアップからの復元までを試し、社内の運用担当者が手順書を見て再現できるかを確認します。PoCの成果物と本番移行時に再利用できるコードの範囲を、発注書に明記します。

社内にNomad、Linux、Terraform、Consul、Vault、ネットワーク、監視を横断して設計できる人材が少ない場合は、アーキテクチャ設計から構築、移行、教育までを一括で依頼します。ただし、「一括」と書くだけでは責任範囲が曖昧になります。Nomad serverとclientの構成、クラウド資源、アプリ改修、データ移行、監視、障害試験、運用引き継ぎを作業項目ごとに分けます。

一括発注のメリットは窓口がまとまり、環境間の責任分界を調整しやすいことです。一方で、委託先の設計思想に依存しやすく、完成後に社内で運用できないリスクがあります。ソースコード、Nomad job spec、Terraformコード、設定値の管理場所、アカウント権限、手順書、教育回数、問い合わせ対応時間を、納品物と受入条件として契約に含めます。

おすすめしやすいのは、現状分析とPoC、本番設計、移行、運用改善を段階に分ける方法です。各段階で成果物と次段階の判断基準を置けば、要件が変わったときに全体契約を見直しやすくなります。特に、既存アプリのコンテナ化率やWindows・Java・VMの混在状況が不明な場合は、調査工程を先に発注します。

内製化支援を含める場合は、定例会で説明するだけでなく、発注者側がジョブ登録、ロールバック、ログ確認、ACL変更、証明書更新、障害一次切り分けを実際に操作する場を設けます。納品後の自走を目指すなら、操作教育、レビュー、Runbookの演習までを作業範囲に含めることが大切です。

RFPと要件整理では何を決めますか？

RFPでは、製品名より先に業務上の目的と現行環境を書きます。Nomadの導入が目的化すると、必要のないクラスタや周辺製品まで増えるためです。発注候補が同じ条件で見積もれるように、対象範囲、制約、納期、運用体制、予算の考え方をできる限り具体化します。

まず、デプロイ時間を何分まで短縮したいのか、障害時に何分以内で復旧したいのか、手作業を何件減らしたいのかをKPIにします。そのうえで、対象をWebアプリ、API、定期バッチ、常駐エージェント、Windowsアプリ、Java、VM、データベースなどに分け、コンテナ化の有無、状態を持つか、保存先、通信先、停止可能時間を記録します。

Nomadのジョブに載せる対象と、外部サービスとして残す対象も明示します。データベースをNomad上で動かすのか、RDSなどのマネージドサービスを使うのかで、バックアップ、障害復旧、ストレージ、費用、責任が変わります。発注者がマスタや移行データを丸投げすると後工程で止まりやすいため、データの所有者と提供期限もRFPに記載します。

可用性、性能、拡張性、バックアップ、監査、セキュリティ、運用時間帯を、後から追加する前提にしないことが重要です。たとえばNomad serverは3台または5台を基本とする設計が多いですが、ノード数だけで可用性は決まりません。リージョン障害、ネットワーク分断、ストレージ障害、クラスタのスナップショット復元まで含めて、RTOとRPOを決めます。

セキュリティでは、HTTPやRPCのmTLS、ACL、Namespace、必要に応じたSentinel、Vaultによるシークレット管理を検討します。管理者権限を誰に付与するか、ジョブへ渡すDBパスワードの有効期限、監査ログの保存期間、脆弱性対応の期限、証明書の更新担当を要件に入れます。Nomadの公式セキュリティ資料も、暗号化やACLを構成して初めて安全性を高められる設計として説明しているため、初期設定を委託先任せにしないことが大切です（出典: HashiCorp Nomad公式「Security Model」「Enable TLS encryption」「ACL system overview」）。

RFPの成果物欄には、構成図、環境一覧、Nomad job spec、Terraformコード、ConsulやVaultの設定、CI/CD定義、監視・ログ設計、バックアップと復元手順、障害対応Runbook、テスト結果、移行計画、ロールバック計画、操作マニュアルを挙げます。ソースコードと設定をどのリポジトリで管理し、いつ発注者へ引き渡すかも明記します。

受入条件は「構築完了」ではなく、試験結果で判定できる表現にします。たとえば、指定したノード障害時にサービスが再配置されること、更新時に許容停止時間を超えないこと、ACLで権限外のAPIが拒否されること、バックアップから指定時間内に復元できることを確認項目にします。曖昧な受入条件は、追加費用や納期延長の原因になりやすいです。

契約形態は請負と準委任のどちらが適していますか？

契約形態は、作業内容と完成物をどこまで確定できるかで選びます。要件と受入条件が固まった本番構築は請負、調査やPoC、現状分析、運用改善のように作業しながら判断する工程は準委任が合いやすいです。実務では、調査・設計を準委任、本番構築や移行を請負、稼働後の監視や改善を保守契約とする組み合わせが使いやすいです。

請負契約では、委託先が完成させる成果物、納期、検査方法、修正対応、瑕疵や不具合への対応、知的財産権、秘密保持、再委託、損害賠償の範囲を確認します。Nomadでは、サーバー構築だけでなくjob spec、Terraform、CI/CD、監視、Runbookまでが完成物に含まれるかで価値が大きく変わります。

請負で注意したいのは、契約時に決めていないアプリ改修やデータ移行が後から見つかることです。対象外作業の単価、変更要求の受付方法、見積の再提出条件、納期への影響を、変更管理手順として契約書や個別契約に添付します。機能を増やすだけでなく、セキュリティや性能の前提が変わる場合も変更扱いにします。

準委任契約では、特定の完成物を約束するより、合意した期間に専門人材が調査、設計、レビュー、構築支援を行うことを定義します。PoCや既存環境の調査では、想定外の制約が見つかる可能性が高いため、準委任で作業時間と報告物を管理する方が実態に合う場合があります。

ただし、準委任だから成果物が不要になるわけではありません。月次の作業報告、課題一覧、設計判断の記録、変更したコード、次月の計画、未解決リスクを提出物にします。発注者側の意思決定が遅れると期間だけが延びるため、質問への回答期限、会議参加者、承認者、環境を用意する責任も決めます。

稼働後の保守では、監視対象、アラートの通知先、一次対応と二次対応の境界、対応時間帯、重大度ごとの目標時間、定例報告、脆弱性対応、証明書更新、Nomadや周辺製品のアップグレードを分けて記載します。24時間365日の有人対応が必要か、平日営業時間のベストエフォートでよいかでも、月額費用と体制が変わります。

2026年時点では、Nomad 2.0系からIBMのバージョン・リリース・サポートモデルに移行しています。公式リリースノートでは、Nomad 1.10.xは2027年4月30日まで、2.0.xは基本サポートが2028年4月30日までで、延長サポートはEnterprise向けの有料オプションとされています。新規構築なら採用バージョン、LTS、アップグレード検証の担当を契約に入れます（出典: HashiCorp Developer「Nomad v2.0.x release notes」、2026年確認）。

Nomadのシステム開発を外注する進め方

発注後は、現状分析、基本設計、PoC、本番構築、移行、試験、引き継ぎの順に進めます。すべての工程を一直線に進めるのではなく、各段階でリスクと前提を更新し、次の工程へ進む判断を行います。特に本番移行前には、アプリの動作確認だけでなく、障害と運用の試験を行います。

現行のサーバー、OS、ミドルウェア、アプリ、バッチ、ネットワーク、データベース、監視、バックアップ、CI/CDを一覧化します。各ワークロードについて、停止可否、起動順、必要CPU・メモリ、ポート、永続データ、外部接続、認証情報、障害時の復旧手順を確認します。ここが曖昧なまま構築を始めると、Nomadに載せられない処理が移行直前に発覚します。

この工程では、委託先が作るものと発注者が用意するものを一覧にします。クラウドアカウント、DNS、証明書、ネットワーク接続、テストデータ、業務担当者の確認、既存システムの仕様、移行停止時間などは、発注者側の準備が必要になることが多いです。前提条件を議事録と課題管理表に残すことで、後からの認識違いを減らせます。

基本設計では、serverとclientの役割、台数、リージョン、通信経路、ストレージ、状態を持つ処理の扱い、Consul・Vaultとの接続、監視とログの保存先を決めます。Nomad job specとTerraformコードは手作業で編集するだけでなく、Gitでレビューでき、テスト環境から本番環境へ同じ手順で展開できる状態にします。

構築後は、成功するデプロイだけでなく、失敗時の挙動を確認します。カナリアリリースから全体展開へ進む条件、ロールバックの実行者、バージョンを戻せる期間、ログから原因を追える項目、ノード追加時の手順を決めます。運用担当者がコードの変更履歴を追跡できるよう、リポジトリの権限とレビュー方法も納品範囲に含めます。

移行は、1サービスを先行して移すカナリア方式から始めます。平常時の性能、デプロイ時間、ログの見え方、アラートの発生、障害時の再配置を確認し、問題がなければ対象を広げます。データベースや状態を持つワークロードは、バックアップ、整合性、切り戻し、停止時間を別に試験します。

引き継ぎでは、手順書を受け取るだけでなく、発注者が実際に作業します。ジョブの停止と再開、ロールバック、ACL変更、シークレット更新、証明書更新、ノード障害対応、スナップショット復元を演習し、できなかった項目を残課題にします。運用開始後の初期支援期間と、追加改修の見積方法もこの段階で合意します。

Nomadのシステム発注費用と相場

Nomad固有の国内標準価格統計は確認できないため、以下は2025〜2026年の一般的な業務システム・クラウド基盤構築の公開情報と、Nomadの構成要素をもとにした編集部推定です。Nomadのライセンス価格そのものではなく、要件定義、設計、構築、移行、試験、ドキュメントを含む導入プロジェクトの予算目安として見てください。

技術検証や学習環境なら、50万〜150万円程度が一つの目安です。数ノードのクラスタ、基本ジョブ、簡易CI、短い検証期間を想定したレンジで、本番の可用性や24時間運用は含まないことが多いです。小規模な本番クラスタは300万〜800万円程度、中規模の業務基盤は800万〜2,000万円程度が目安になります。

複数クラウド、複数拠点、Windows・Java・VMの混在、既存アプリ移行、DR、監査、教育を含むと、1,500万〜4,000万円程度のレンジを検討します。金融などで多リージョン、厳格なSLA、24時間運用、脆弱性診断、長期移行を求める場合は、3,000万円〜1億円以上になる可能性があります。これらは案件規模と要件で大きく変わる推定であり、Nomadの公式料金や一律相場ではありません。

見積書では、要件定義、基本設計、詳細設計、Nomad server・client構築、アプリのコンテナ化、CI/CD、Consul、Vault、ネットワーク、監視、ログ、バックアップ、移行、テスト、教育、ドキュメントを分けます。要件定義10〜15%、設計15〜25%、実装・構築30〜40%、試験15〜20%、移行・教育5〜10%という配分は、一般的な業務システムの計画時に置く仮の比率です。Nomad固有の統計ではないため、提案会社の工数根拠と一緒に確認します。

クラウドのVM、ディスク、通信、ロードバランサ、ログ保管、監視サービス、証明書、外部サポートは、開発会社への支払額とは別に発生します。小〜中規模で月額20万〜100万円程度、大規模や24時間体制で月額100万〜500万円以上という推定レンジもありますが、ノード数、ログ量、通信量、SLAによって変わります。Enterpriseや有償サポートは公開された一律価格ではなく、公式価格ページでもEnterprise Self Managedは問い合わせ型です（出典: HashiCorp Product Pricing、2026年確認）。

「Nomadの構築一式」とだけ書かれた安価な見積もりは、アプリ改修、セキュリティ、監視、移行、運用引き継ぎが含まれていない可能性があります。公開情報でも、システム開発は要件定義の精度によって見積もりが大きく変動し、付帯費用や保守費用を別に見る必要があると説明されています（出典: イー・ジーシステム「システム開発の費用相場と見積書の読み方（2026年版）」）。

比較するときは、合計金額だけでなく、含まれるノード数、環境数、ジョブ数、移行対象、テストケース、稼働後の支援期間、追加作業の単価を揃えます。見積もりの前提と除外事項が明確な会社は、金額が高く見えても後から増額しにくい傾向があります。逆に、前提を書かずに低価格だけを示す提案は、発注後の追加見積もりを想定して確認します。

Nomadの委託先選定と見積比較のポイント

Nomadの委託先は、Nomadという単語を知っている会社ではなく、本番運用に必要な周辺領域まで扱える会社を選びます。公式サイトにパートナー情報があっても、担当チームの実績、担当エンジニア、構築範囲、運用保守、価格は案件ごとに確認する必要があります。

確認したい技術領域は、Nomadのジョブ設計だけではありません。GoやLinux、Terraform、Consul、Vault、Docker、ネットワーク、Windows・VM、Observability、SRE、バックアップ、脆弱性対応を一体で扱えるかを確認します。提案時には、担当者が自社の要件を聞き、Nomadを使わない選択肢やKubernetesとの併用も含めて説明できるかを見ます。

実績を聞くときは、社名や導入件数だけでなく、ワークロードの種類、ノード数、環境数、可用性、移行方法、運用人数、障害対応、契約後の保守を質問します。三菱UFJ eスマート証券の公式事例では、NomadとConsulで運用手順の標準化とサーバー管理台数の削減につなげたと紹介されています。これは自社で同じ効果が出る保証ではありませんが、提案会社に「どの運用課題をどう標準化するか」を説明してもらう際の参考になります（出典: HashiCorp公式「Mitsubishi UFJ eSmart Securities」）。

候補会社には同じRFPを渡し、提案書の章立てもできるだけ揃えます。比較する項目は、要件定義の工数、設計の成果物、構築対象の環境数、クラスタのHA構成、アプリ改修、移行、テスト、セキュリティ診断、監視、ドキュメント、教育、保守です。各社が「含む」「含まない」「別途見積もり」を明示できるよう、回答欄を設けます。

価格差が出た場合は、人数や単価だけでなく、作業の抜け、設計の深さ、テスト範囲、再利用できるコード、保守の範囲を確認します。担当者が商談時に説明した内容と見積書の項目が一致しているかも重要です。最終的には、初期費用、クラウド費、ライセンス・サポート費、保守費、社内対応工数を合わせた総保有コストで判断します。

提案面談では、Nomadを採用しない方がよい条件、Kubernetesと併用する場合の理由、失敗しやすい移行対象、障害時に誰が判断するかを質問します。良い提案は、メリットだけでなく、運用スキルの習得、周辺製品の増加、二重基盤の管理、バージョン更新、ベンダーロックインのリスクも説明します。

また、PoCが不採用となった場合に何を残せるかを確認します。現状分析、負荷試験、ジョブ定義、構成図、比較結果、撤退判断の記録が残れば、別の基盤を選ぶ場合にも活用できます。反対に、委託先だけが操作できる環境や、納品されない設定ファイルに依存する提案は、契約前に見直します。

よくある質問

Nomadの発注では、製品の知識だけでなく、既存環境の移行、契約、費用、運用の確認が必要です。ここでは、発注前に質問されやすいポイントをまとめます。

OSS版のライセンス費だけで判断すれば、商用ライセンス費が不要になる場合があります。ただし、クラスタ設計、アプリ移行、TLS・ACL、監視、バックアップ、クラウド資源、アップグレード、障害対応の費用は別に発生します。Enterpriseや有償サポートの価格は環境や契約条件による問い合わせ型のため、OSS版と商用版を同じ要件で見積もって比較します。

コンテナ中心で、Kubernetes向けの運用人材やマネージドサービス、エコシステムを活用したい場合はKubernetesが候補になります。コンテナと非コンテナのワークロードを扱い、構成を軽量に保ち、クラウド・オンプレミスをまたいで運用したい場合はNomadが候補になります。優劣ではなく、対象アプリ、運用体制、必要な機能、将来の拡張方針をRFPに書いて比較します。

導入目的、現行構成、対象ワークロード、ノード数の想定、クラウドやオンプレミスの条件、可用性、RTO・RPO、セキュリティ、監視、移行期限、運用時間帯、予算の考え方、成果物、受入条件を書きます。既存アプリの改修やデータ移行をどこまで委託するか、発注者が準備するアカウント・データ・担当者も明記すると、見積比較がしやすくなります。

外注できます。監視、アラート一次対応、障害時の復旧支援、証明書更新、脆弱性対応、バージョンアップ、定例報告、改善提案を保守契約に含めます。24時間対応か営業時間内対応か、重大度ごとの目標時間、発注者へのエスカレーション、追加改修の扱いを分けて書くことで、稼働後の認識違いを減らせます。

まとめ

Nomadのシステムを発注・外注するときは、Nomadの導入だけでなく、アプリケーション、CI/CD、ネットワーク、監視、ログ、バックアップ、シークレット、移行、保守までを一つの本番基盤として整理します。まず導入目的と対象ワークロードを明確にし、必要であればPoCから始めることが大切です。

RFPには、非機能要件、成果物、受入条件、発注者側の準備、除外事項を記載します。契約は、調査・PoCを準委任、本番構築を請負、稼働後を保守契約とするなど、工程の性質に合わせて分けます。費用は50万〜150万円程度の検証から、複数拠点・移行・24時間運用を含む1億円以上まで幅があるため、金額だけでなく対象範囲と前提条件を揃えて比較します。

委託先は、Nomadの知識だけでなく、Terraform、Consul、Vault、Linux、ネットワーク、監視、既存アプリ移行、障害対応まで担えるかを確認します。ソースコード、設定、手順書、運用教育、アップグレード方針を契約に明記すれば、納品後も自社で管理しやすいNomad基盤になります。

▼全体ガイドの記事
・Nomadのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。