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

Nomadのシステム発注は、要件整理、段階的な設計・構築、移行と運用試験の順に進めると、本番運用までの準備が整います。

発注形態、RFPと契約、開発の進め方、費用相場、委託先の選び方が判断の中心です。全体像はNomadのシステム開発の完全ガイドをご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

外注時は、製品の導入と、Nomad上で動く業務アプリの開発を分けて発注します。Nomadは、アプリの稼働サーバーと条件を管理する実行基盤で、業務画面やCRMを作るフレームワークではありません。

Nomad単体でできることとできないことの切り分け

Nomadが担う機能と、別途設計・発注が必要な領域を一覧にして分けておきます。

• 実行管理：ジョブ配置、リソースを考慮したスケジューリング、再配置、障害復旧
• リリース：ローリング更新やカナリアリリース。Git管理とCI/CD連携で手動デプロイを減らせます
• 別途設計：ネットワーク、VM、DB、アプリのコンテナ化、業務ロジック、ログ分析、バックアップ
• 周辺製品：Terraformはインフラ、Consulはサービス発見や通信、Vaultはシークレットを担当

各製品の担当範囲は、発注時に明確に切り分けます。

Nomadを採用する案件かの判断

導入目的と運用環境を照らし合わせて、Nomadを検証する価値があるかを判断します。

• 既存環境で足りる場合：少数サーバーならsystemdやマネージドサービス、Terraform整備で目的を達成できる場合があります
• 導入の目的：デプロイ短縮、属人運用削減、環境間の可搬性、既存アプリ統合
• 検証する状況：コンテナとレガシーアプリの統合、クラウドとオンプレミスへの分散
• 管理したい処理：バッチやシステムジョブを宣言的に管理する

Nomadの導入そのものを目的化せず、対象ワークロード、運用人員、必要なエコシステム、マネージドサービスの方針を見ます。そのうえで、Kubernetesとの優劣は、これらの条件に照らして判断します。

Nomadのシステム発注形態の選び方

発注形態は、社内の技術力と責任範囲をもとに選びます。PoCなら技術支援型、本番移行まで任せるなら請負・準委任の段階発注、24時間運用には別途保守契約が現実的です。

技術検証やPoCの小さな発注

適合性が分からない段階では、2〜6週間程度のPoCから始めます。本番環境全体の構築を一括で発注するのはリスクが大きいため、避けます。

• 検証環境：数ノードのクラスタ、DockerまたはRaw exec、基本ジョブ
• 連携確認：簡易CI/CD、サービス登録、ログ取得
• 障害試験：更新、異常終了、ノード障害、ネットワーク分断、ACL拒否
• 運用試験：証明書更新、ログ確認、バックアップ復元、手順書での再現

この期間は、リサーチノートと一般的な基盤構築工数をもとにした目安です。Nomad公式の標準期間ではありません。

成果物と、本番移行で再利用できるコードの範囲は、発注書に明記します。

設計・構築から運用までの一括外注

設計から運用引き継ぎまでを一括で依頼する形も候補になります。「一括」と書くだけでは責任範囲が曖昧なため、作業項目ごとに分けて書きます。

• 作業範囲：設計、Nomad server・client、クラウド資源、アプリ改修、データ移行
• 運用準備：監視、障害試験、引き継ぎ、受入条件
• 納品物：ソース、job spec、Terraform、設定値、手順書
• 契約事項：管理場所、アカウント権限、教育回数、問い合わせ対応時間

この形が向くのは、社内にNomadとTerraformを横断して扱える人材が少ない場合です。Consul、Vault、Linux、ネットワーク、監視についても、まとめて見られる人が社内にいないときに当てはまります。

窓口がまとまり、責任分界を調整しやすい一方で、委託先の設計に依存し、完成後に社内で運用できないリスクがあります。

段階発注と内製化支援の組み合わせ

現状分析から運用改善まで段階に分けて発注し、各段階の成果物と次工程の判断基準を設けます。

• 段階：現状分析、PoC、本番設計、移行、運用改善
• 先行調査：コンテナ化率やWindows・Java・VMの混在が不明な場合
• 操作演習：ジョブ登録、ロールバック、ログ確認、ACL・証明書の更新
• 内製化支援：障害一次切り分け、操作教育、レビュー、Runbook演習

段階ごとの基準を決めておくと、要件が変わった際に見直す範囲を絞れます。

定例会で説明を受けるだけでなく、発注者が実際に操作する場も設けます。

RFPと要件整理で決めること

RFPでは製品名より先に、業務目的と現行環境を書きます。Nomadの導入が目的化すると、不要なクラスタや周辺製品まで増えるためです。

候補各社が同じ条件で見積もれるよう、対象範囲、制約、納期、運用体制、予算の考え方を具体的に書きます。

目的と対象ワークロードの一覧

デプロイ時間を何分まで短縮するか、障害時に何分以内で復旧するか、手作業を何件減らすかを、KPIとして定めます。

対象ワークロードも、種類ごとに整理します。

• 対象例：Webアプリ、API、定期バッチ、常駐エージェント、Windowsアプリ、Java、VM、データベース
• 確認項目：コンテナ化、状態の有無、保存先、通信先、停止可能時間

Nomadのジョブに載せる対象と、外部サービスに残す対象も明示します。特にDBは、Nomad上で動かすかRDSなどを使うかで、バックアップ、復旧、ストレージ、費用、責任が変わります。

マスタや移行データの所有者と提供期限も、RFPに記載します。発注者が準備を任せきりにすると、後工程で作業が止まる原因になります。

非機能要件とセキュリティの先行記載

可用性やセキュリティを後付けにせず、障害時の目標と設定範囲を先に定めます。

• 非機能要件：可用性、性能、拡張性、バックアップ、監査、運用時間帯
• 復旧要件：リージョン・ネットワーク・ストレージ障害とスナップショット復元、RTO・RPO
• 通信と認可：HTTP・RPCのmTLS、ACL、Namespace、必要に応じたSentinel
• 秘密情報：Vault管理、DBパスワードの期限、管理者権限、監査ログ保存期間

Nomad serverは3台または5台を基本とする設計が多いです。ただし、台数だけで可用性が決まるわけではありません。

脆弱性対応の期限と、証明書の更新担当も決めておきます。

暗号化やACLで安全性を高める設計のため、初期設定は委託先任せにしません（出典: HashiCorp Nomad公式「Security Model」「Enable TLS encryption」「ACL system overview」）。

成果物と受入条件のRFPへの記載

成果物と受入試験をRFPに明記して、完成後に何を受け取るかを発注側と委託先でそろえます。

• 構成・コード：構成図、環境一覧、job spec、Terraform、Consul・Vault設定、CI/CD
• 運用資料：監視・ログ、バックアップ復元、障害Runbook、移行・ロールバック計画、操作マニュアル
• 試験記録：テスト結果と、ノード障害時のサービス再配置
• 受入条件：更新時の許容停止時間、ACL拒否、指定時間内の復元

コードと設定の管理リポジトリと、発注者への引き渡し時期も決めておきます。受入条件は、試験結果で判定できる表現にします。

条件が曖昧だと、追加費用や納期延長の原因になります。そのため、具体的な確認方法を記載します。

請負と準委任の契約形態の選び方

契約は、作業内容と完成物をどこまで確定できるかで選びます。要件と受入条件が固まった本番構築は、請負が合います。

調査、PoC、現状分析、運用改善など、作業中に判断する工程は準委任が合いやすいです。工程ごとに契約を組み合わせる形を取ります。

たとえば、調査・設計は準委任、本番構築・移行は請負、稼働後の監視・改善は保守契約とする形が使いやすいです。

請負契約の完成物と変更ルール

請負契約では、完成物と検査方法を定め、対象範囲の変更手順も合意しておきます。

• 契約条件：成果物、納期、検査、修正・不具合対応
• 権利と責任：知的財産権、秘密保持、再委託、損害賠償範囲
• 変更管理：対象外作業の単価、変更要求の受付、再見積もり条件

Nomadでは、サーバーに加えて、job spec、Terraform、CI/CD、監視、Runbookが完成物に含まれるかで、契約の価値が変わります。

アプリ改修やデータ移行の追加、セキュリティ・性能前提の変更による納期への影響も、契約書や個別契約に添付します。

準委任契約の作業体制と時間

準委任では、特定の完成物よりも、合意した期間内に専門人材が行う作業と報告物を定義します。

• 作業内容：調査、設計、レビュー、構築支援
• 提出物：月次報告、課題一覧、設計判断、変更コード、次月計画、未解決リスク
• 発注者の役割：回答期限、会議参加者、承認者、環境準備

PoCや既存環境の調査では、想定外の制約が見つかる可能性があります。その場合は、作業時間と報告物を管理する準委任が合うことがあります。

発注者の意思決定が遅れると期間が延びるため、双方の役割を事前に定めておきます。

保守契約の障害対応とアップグレード

保守の範囲と対応時間を分けて、採用するバージョンや更新の担当も契約に定めます。

• 障害対応：監視対象、通知先、一次・二次対応、重大度ごとの目標時間
• 定常作業：定例報告、脆弱性対応、証明書更新、製品アップグレード
• 契約時間：24時間365日対応か、平日営業時間のベストエフォートか
• 更新管理：採用版、LTS、アップグレード検証の担当

2026年時点で、Nomadは2.0系からIBMのバージョン・リリース・サポートモデルへ移行しています。

公式リリースノートでは、1.10.xは2027年4月30日まで、2.0.xは基本サポートが2028年4月30日までです。

延長サポートはEnterprise向けの有料オプションです（出典: HashiCorp Developer「Nomad v2.0.x release notes」、2026年確認）。

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

発注後は、現状分析、基本設計、PoCの順に進めて、本番構築へ移ります。その後は、移行、試験、引き継ぎと続きます。各段階で、リスクと前提を更新します。

工程は一直線に進めず、各段階の結果を見て次へ進むかを判断します。さらに、本番移行の前には、アプリだけでなく障害と運用も試験します。

現状分析での移行対象と責任分界

移行対象の構成と、委託先・発注者それぞれの準備事項を洗い出します。委託先が作るものと発注者が用意するものも、区分しておきます。

• 現行環境：サーバー、OS、ミドルウェア、アプリ、バッチ、ネットワーク、DB
• 運用基盤：監視、バックアップ、CI/CD
• ワークロード：停止可否、起動順、CPU・メモリ、ポート、永続データ、外部接続、認証、復旧手順
• 発注者の準備：クラウドアカウント、DNS、証明書、ネットワーク、テストデータ、業務確認、既存仕様、停止時間

確認が足りないまま構築すると、Nomadに載せられない処理が移行直前に見つかることになります。

前提は議事録と課題管理表に残し、委託先と発注者の認識違いを減らします。

設計・構築での再現可能なコードの納品

設計要素と展開手順をコード化し、テスト環境から本番まで再現できる状態で納品を受けます。

• 基盤設計：server・clientの役割と台数、リージョン、通信経路、ストレージ、状態を持つ処理
• 周辺連携：Consul・Vault、監視、ログ保存先
• コード管理：job specとTerraformをGitでレビューし、変更履歴を追跡
• 運用手順：展開条件、ロールバック、復元可能期間、ログ項目、ノード追加、権限とレビュー

成功時の動きだけでなく、失敗時の挙動も確認します。運用担当者が同じ手順で展開できる形になっているかも、納品前に見ておきます。

移行・試験・引き継ぎによる本番運用の確認

少数のサービスから移行と試験を始め、発注者が運用操作を実行してから本番運用へ移ります。

1. まず1サービスをカナリア方式で移し、性能、デプロイ時間、ログ、アラート、障害時の再配置を確かめます。
2. 問題がなければ対象を広げます。DBなど状態を持つ処理は、バックアップ、整合性、切り戻し、停止時間を別に試験する必要があります。
3. 発注者がジョブの停止・再開、ロールバック、ACL・シークレット・証明書の更新を演習します。
4. ノード障害とスナップショット復元を練習し、未完了の項目は残課題にします。

運用開始後の初期支援期間と、追加改修の見積方法も合意します。

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

Nomad固有の国内標準価格の統計は確認できていません。そこで、2025〜2026年の業務システム・クラウド基盤の公開情報と構成要素をもとに、編集部が推定した金額を示します。

ここでの金額は、Nomadのライセンス価格ではなく、要件定義、設計、構築、移行、試験、ドキュメントを含む導入プロジェクトの予算目安です。

初期費用の幅（50万円台のPoCから1億円超まで）

費用は検証規模から本番の要件まで幅があるため、規模と含む条件をそろえて比べます。

• 技術検証・学習：50万〜150万円程度。数ノード、基本ジョブ、簡易CI、短期検証
• 小規模本番：300万〜800万円程度。可用性や24時間運用は含まないことが多い
• 中規模業務基盤：800万〜2,000万円程度
• 複合要件：複数クラウド・拠点、混在環境、移行、DR、監査、教育を含み1,500万〜4,000万円程度
• 高要件：多リージョン、厳格なSLA、24時間運用、脆弱性診断、長期移行を含む場合、3,000万円〜1億円以上の可能性

これらは案件の規模と要件による推定で、Nomad公式の料金や一律の相場ではありません。

見積の構築費と周辺費用の分け方

クラウド資源などの費用は、開発会社への支払額とは別に発生します。そのため、見積では構築作業と運用費を分けて確認します。

• 構築項目：要件定義、基本・詳細設計、server・client、アプリのコンテナ化
• 周辺作業：CI/CD、Consul、Vault、ネットワーク、監視、ログ、バックアップ、移行、試験、教育、文書
• 仮の工数配分：要件定義10〜15%、設計15〜25%、実装・構築30〜40%、試験15〜20%、移行・教育5〜10%
• 別途運用費：VM、ディスク、通信、ロードバランサ、ログ、監視、証明書、外部サポート
• 月額推定：小〜中規模20万〜100万円程度、大規模・24時間体制100万〜500万円以上

配分は一般的な業務システム計画の仮の比率で、Nomad固有の統計ではありません。提案会社の根拠を確認します。

月額費用は、ノード数、ログ量、通信量、SLAによって変わります。

Enterprise Self Managedは問い合わせ型で、一律の価格ではありません（出典: HashiCorp Product Pricing、2026年確認）。

安い見積もりの対象外と前提条件

安価な見積もりは、対象外の作業と前提条件を確認したうえで、同じ条件で比較します。

• 対象外の確認：アプリ改修、セキュリティ、監視、移行、引き継ぎ
• 見積条件：ノード数、環境数、ジョブ数、移行対象、テストケース、支援期間
• 追加費用：付帯費用、保守費用、追加作業の単価
• 前提と除外：範囲が明確か、低価格の提案に不足がないか

要件定義の精度で見積もりは大きく変わり、付帯費用や保守費用も別途確認が必要です（出典: イー・ジーシステム「システム開発の費用相場と見積書の読み方（2026年版）」）。

一方で、前提と除外事項が明確な会社は、金額が高く見えても後から増額しにくい傾向があります。

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構成、アプリ改修、移行、テスト
• 運用範囲：セキュリティ診断、監視、文書、教育、保守
• 価格差の理由：作業漏れ、設計の深さ、試験範囲、再利用コード、保守範囲
• 総保有コスト：初期費用、クラウド、ライセンス・サポート、保守、社内工数

各社には、作業を「含む」「含まない」「別途見積もり」のいずれかで示せる回答欄を設けます。

商談で説明された内容と、見積項目が一致しているかも確認します。

提案面談での運用と撤退条件

面談では採用判断と運用上のリスクを尋ね、PoC後に撤退した場合に残る成果物も確認します。

メリットだけでなく、運用スキルの習得や周辺製品の増加、二重基盤、更新、ロックインのリスクも説明できるかを見ます。

• 採用判断：Nomadを選ばない条件、Kubernetes併用の理由、移行で失敗しやすい対象
• 運用リスク：障害時の判断者、スキル習得、周辺製品、二重基盤、更新、ロックイン
• 撤退時の成果：現状分析、負荷試験、job定義、構成図、比較結果、判断記録

撤退時に残る分析や記録は、別の基盤を選ぶ場合にも活用できます。

委託先だけが操作できる環境や、納品されない設定ファイルに依存する提案は、契約前に見直します。

よくある質問

Nomadの発注では、製品の知識だけでなく、既存環境の移行、契約、費用、運用の確認も必要です。

NomadはOSSなら無料なので発注費用は安くなりますか？

OSS版は、ライセンス費だけで見れば商用ライセンス費が不要になる場合があります。ただし、設計や移行、運用費は別です。

具体的には、クラスタ設計とアプリ移行の費用がかかります。さらに、TLS・ACL、監視、バックアップの費用もかかります。また、クラウド資源、更新、障害対応の費用も見込みます。

Enterpriseや有償サポートは、環境や契約条件によって個別に問い合わせる形です。同じ要件でOSS版と商用版を見積もって比べます。

NomadとKubernetesのどちらを外注すべきですか？

コンテナ中心で、Kubernetesの運用人材やマネージドサービス、エコシステムを使いたい場合は、Kubernetesが候補になります。

コンテナと非コンテナを扱い、軽量な構成でクラウドとオンプレミスをまたぐ場合は、Nomadが候補になります。

対象アプリ、運用体制、必要機能、将来の拡張方針をRFPに記載して、両者を同じ条件で比べます。

NomadのRFPには最低限何を書けばよいですか？

まず、導入目的、現行構成、対象ワークロードを書きます。さらに、ノード数、クラウド・オンプレミスの条件、可用性、RTO・RPOも書きます。

セキュリティと監視、移行期限も必要です。加えて、運用時間帯、予算、成果物、受入条件も書いておくと、各社が同じ前提で見積もれます。

アプリ改修やデータ移行の委託範囲と、発注者が用意するアカウント・データ・担当者も明記すると、比較しやすくなります。

納品後のNomad運用も外注できますか？

外注できます。保守契約には、監視、アラートの一次対応、障害復旧の支援、証明書更新、脆弱性対応を含めます。

バージョンアップ、定例報告、改善提案も定めます。24時間対応か営業時間内かを決め、重大度ごとの目標時間を分けます。

発注者へのエスカレーションと追加改修の扱いも決めておくと、稼働後の認識違いを減らせます。

まとめ

Nomadの発注では、導入だけでなく、アプリ、CI/CD、ネットワークまで含めて整理します。監視、ログ、バックアップも対象です。さらに、シークレット、移行、保守も含め、本番基盤として扱います。

目的と対象ワークロードを明確にし、必要に応じてPoCから始めます。RFPには、非機能要件、成果物、受入条件、発注者の準備、除外事項を記載します。

契約は工程に合わせて分けます。費用は、検証の50万〜150万円程度から、複数拠点・移行・24時間運用を含む1億円以上まで幅があります。

金額だけでなく、対象範囲と前提をそろえて比べます。委託先には、Nomadに加えて、Terraform、Consul、Vaultの力を求めます。さらに、Linux、ネットワーク、監視、移行、障害対応も扱えるかを見ます。

ソースコード、設定、手順書、運用教育、更新方針を契約に含めると、納品後も自社で基盤を管理しやすくなります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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