Docker Swarmのシステム発注は、要件を整理してRFPで提案を比べ、契約後に設計・開発・テスト・移行へ進む流れです。目指すのは、発注後も運用できる構成です。
発注形態、契約、費用、RFP、委託先の選び方を、発注時に決める順で説明します。
▼全体ガイドの記事
・Docker Swarmのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Docker Swarmのシステムの概要
Docker Swarmのシステムは、Dockerコンテナ化したWeb、API、バッチ、キューなどを複数サーバーへ配置して運用する構成です。Swarm自体を業務アプリにするわけではない点も、発注時に認識をそろえておきます。
Docker Engineに組み込まれたSwarm modeは、別のオーケストレーターを追加せずにサービスを配置・再配置できます。また、スケールやローリング更新も管理できます。
Docker・Compose・Swarm modeの違い
Docker、Compose、Swarm modeは担う役割が異なるため、発注時には対象にする機能とバージョンを切り分けておきます。
- Docker：アプリをイメージにまとめ、コンテナとして動かす基盤です。
- Docker Compose：主に開発環境や単一ホストで複数コンテナを起動する定義方法です。
- Swarm mode：複数のDocker Engineをクラスタとして扱い、サービスの望ましい状態を保ちます。
Docker公式ドキュメントでは、レプリカ数を宣言すると、障害で減ったタスクにmanagerが新しいレプリカを割り当てると説明されています。また、overlay network、サービスディスカバリ、内部ロードバランシング、ローリング更新とロールバックも利用できます（出典: Docker Docs「Swarm mode」、2026年確認）。
過去のDocker Classic Swarmと、現在Docker Engineに組み込まれたSwarm modeは区別して扱います。RFPでは、対象バージョンとOSを明示し、イメージの保管先とサポート期限も確認します。
業務システムの発注範囲
業務システムの発注範囲は、アプリ開発だけでなく、基盤と運用まで含めて検討します。可用性の目標やデータの扱いによって、どこまでを対象にするかが変わるためです。
- クラスタと通信：manager・workerの台数と役割、ロードバランサー、リバースプロキシ
- アプリ基盤：private registry、overlay network、TLS、CI/CD
- 運用：DB・ファイルの永続化、監視、ログ、バックアップ、障害時の連絡体制
ステートレスなWebやAPIは、複数ノードへ配置しやすい構成です。一方で、DBやアップロードファイルを安易にコンテナへ置くと、再配置時にデータを失うおそれがあります。
本番で高可用性を求めるなら、managerを3台または5台の奇数構成にする設計が候補になります。workerとは役割を分けます。
1台構成は学習やPoCに適します。ただし、manager障害から本番環境を復旧できる構成とは別物です。可用性の要件は、「何台の障害まで稼働するか」「何分以内に復旧するか」で定めます。
発注形態の選び方
発注形態は、業務アプリと基盤を一括で任せるのか、社内や別会社と分担するのか、PoCから段階的に広げるのかで選びます。
Swarmに詳しい会社を探すことも大切です。ただし、複数社へ分離発注すると、責任分界が曖昧なまま障害時に原因の押し付け合いが起きがちです。
業務要件から保守まで一括委託する方法
社内にインフラの担当者が少なく、業務フローも含めて整理したい場合は、SI会社や開発会社へ一括で委託する方法が適しています。
- 開発・基盤：要件定義、アプリ開発、Swarm構築、移行
- 保守：稼働後の対応も含めて依頼します
窓口が一つになると、DB接続、監視通知、リリース手順といった作業の境目を一社で調整できます。
一式見積もりでは人員や成果物が見えにくいため、作業項目ごとに分けて提示してもらいます。担当者、テスト範囲、納品物、保守時間を明記してもらうと、会社同士の比較に使えます。
アプリ会社とインフラ会社を分けて発注する方法
アプリに強い会社とクラウド・インフラに強い会社を分けると、それぞれの専門性を活かせます。ただし、担当範囲と責任者を契約書や運用設計書で明確にしておかないと、境目の作業が抜けてしまいます。
- アプリ会社：Dockerfile、healthcheck、ログ、環境変数を整備
- インフラ会社：クラスタ、ネットワーク、registry、監視、バックアップを構築
分けて発注するときは、イメージの脆弱性対応、障害の一次切り分け、リリース承認のほか、データ復旧の責任者も明記します。発注者がPMを担えない場合は、第三者PMや上位SI会社を置く選択肢もあります。
会社が増えるほど、調整費と会議コストも膨らみます。そのため、価格だけでなく、仕様変更や障害時の意思決定に何営業日かかるかも比べてください。
PoCから本番へ段階的に委託する方法
Swarmの採用をKubernetesなどと比較中なら、最初から大規模な本番構築は頼まず、PoCから始めます。検証環境は1〜2台に抑え、受け入れ条件を満たしてから本番へ進みます。
- 検証：既存Composeを移植し、ローリング更新、ロールバック、ノード停止、バックアップ復元を試します。
- 受け入れ確認：技術的な動作に加えて、復旧時間、手順の理解度、ログの追跡性、セキュリティを見る観点です。
- 本番判断：定義の再利用範囲と再設計範囲を分けて見積もり、本番化・引き継ぎ・採用見送りのどれにするかを決める段階です。
PoCで作った定義は、本番でもそのまま使えるとは限りません。流用できる部分と作り直す部分を分けておくと、見積もりの前提がそろいます。
本番化、別会社への引き継ぎ、採用見送りの判断基準を事前に決めておくと、不要な追加開発を抑えられます。
Docker Swarmのシステム発注・外注の進め方
技術用語を並べる前に、業務上の目的と非機能要件を発注側で先にそろえておくと、提案の比較がぶれにくくなります。
RFPで複数社へ同じ条件を渡し、要件定義、提案比較、契約の各段階で確認する成果物を決めておきます。設計・開発から保守開始までは、段階ごとに受け取るものと確かめる範囲が違うため、分けて見ておきます。
- 設計・開発：工程ごとの成果物と受け入れ条件
- テスト・移行：試験結果と移行対象の範囲
- 保守開始：稼働後の対応範囲と保守体制
要件定義とRFPで最初に整理する項目
RFPには、業務目的と機能範囲を書いたうえで、データ移行、利用規模、稼働条件も記載します。抽象的な要件は、確認できる数値や作業に置き換えます。
- 業務・機能：目的、利用者と権限、画面・API・バッチ、既存連携
- 規模・稼働：移行量、ユーザー数、同時アクセス数、稼働時間、許容停止時間
- 運用・統制：RTO・RPO、監査、個人情報、manager台数、バックアップ頻度、復旧テスト、通知時間
既存のCompose環境があれば、Composeファイル、Dockerfile、環境変数一覧を添付します。加えて、外部サービス、DB容量、ログ保管期間を資料に含めます。リリース頻度と現在の障害履歴も渡すと、提案の前提がそろいます。
準備できない情報があれば、現状調査を別作業として見積もるようRFPに書きます。要件整理を省くと、DB冗長化や監査ログの追加で予算と納期が膨らみやすくなります。
請負契約と準委任契約の使い分け
契約形態は、工程の要件がどこまで固まっているかで選びます。成果物と完成責任を明確にできる工程では、請負契約が候補になります。
- 請負契約：機能と受け入れ条件を定められる開発工程
- 準委任契約：要件が固まらない現状調査や技術検証、伴走型の要件定義、運用改善で使われることがあります
準委任契約では作業時間と体制を定めておきます。契約形態は工程に合わせて選ぶものです。特に、仕様変更の多い工程を無理に請負にすると、追加費用や責任範囲をめぐる争いにつながります。
契約書では、対象範囲と検収条件、仕様変更の手続きを中心に確認します。再委託の可否、秘密保持、個人情報の扱いも、同じ契約書で確かめます。
障害対応と損害賠償の上限、知的財産権、ソースコードとIaCの帰属に加えて、第三者ライセンスや契約終了時の引き継ぎも見ておきます。stack定義や監視設定を受け取れない契約では、他社への引き継ぎや自社での運用が難しくなります。
設計・開発・テスト・移行で確認する成果物
設計から移行までは、工程ごとに成果物と受け入れ条件をそろえて進めます。
- 設計：構成図、ノード台数・スペック、ネットワーク、配置、DB・ストレージ方式、TLS、Secrets、registry、監視、ログ、復旧手順の確認
- 開発：Dockerfile、stack定義、CI/CD、healthcheck、resource limit、環境ごとの差分管理の受け取り
- テスト：機能、worker停止、manager障害、registry停止、更新失敗、ロールバック、DB復元、証明書期限切れ、容量不足
- 移行・検収：移行対象と除外対象の決定、件数確認、マスタ提供、データ確認の協力義務、受け入れテストでの復旧手順の実行
設計では、ファイアウォール設定とバックアップの成果物も確認します。完成条件には、コンテナが起動するだけでなく、再起動や再配置の後も業務を継続できる状態を含めます。復元不能が検収後に判明する事態を避けるため、復旧は実地で確かめます。
Docker Swarmのシステム発注費用の相場
Docker Swarmのシステム開発には、日本向けの標準価格表がありません。そのため、ここで示すのは、社内Q&Aの業務システム相場と、コンテナ基盤・DevOpsの一般的な工数をもとにした推定レンジです。発注前のたたき台として使うもので、特定の金額を約束するものではありません。
金額を左右するのは、アプリを新規開発するか既存システムを移行するかです。データ量、SLA、監査要件、24時間運用の有無によっても変わります。
規模別の初期費用と開発期間の目安
初期費用と期間は、規模や必要な機能によって異なります。下に挙げる金額と期間は、推定の目安です。
- 学習・PoC：1〜2台でCompose移植などを行う場合、50万円〜150万円程度、2〜4週間
- 小規模本番：3〜5台で基盤と運用を整える場合、200万円〜500万円程度、1〜3か月程度
- 業務システム：認証、DB・外部連携、移行、試験、教育を含む場合、500万円〜1,500万円程度、3〜6か月程度
- 高要件の本番：災害対策や24時間運用などを含む場合、1,500万円〜5,000万円以上、6〜12か月程度
学習・PoCは、既存Composeの移植、イメージ化、Swarm基本設定、簡易デプロイが前提です。一方、小規模本番は、managerとworkerを分け、registryやTLS、CI/CDを整える想定です。その想定には、監視、バックアップ、リリース手順も含まれます。
業務システムの推定レンジには、認証やDB連携、バッチ、外部連携を含みます。加えて、データ移行、権限、障害試験、運用教育も含みます。
高要件の本番では、ステージング分離、厳格な監査ログ、性能・負荷試験が必要になる可能性があります。
これらは公開されたDocker Swarmの定価ではなく、要件に応じた見積もりレンジとして使うものです。
月額インフラ費用と初期構築費の切り分け
クラウド仮想サーバーの料金は、開発費とは別に毎月かかります。AWS LightsailのLinux/Unix公開料金は、公開ページで容量別に示されています（出典: Amazon Lightsail Pricing、2026年8月確認）。
- 0.5GB：月額5米ドル
- 2GB：月額12米ドル
- 4GB：月額24米ドル
- 8GB：月額44米ドル
単純計算すると、検証用の2GB相当を5台置けば月額60米ドル相当になります。manager 3台とworker 2台を4GB相当で置く場合は、月額120米ドル相当が出発点です。
この試算は仮想サーバーだけの机上計算です。ロードバランサー、固定IP、バックアップ、監視、private registryも別途かかります。
オブジェクトストレージやDB、データ転送の費用に加えて、ログ保管、商用サポート、運用担当者の工数も別にかかります。
円換算は為替によって変わります。そのため、見積書には米ドル表記だけで済ませず、前提レートと月額の変動要因を明記してもらいます。
保守・運用費用に含める作業
社内Q&Aでは、年間保守を初期開発費の15〜20%程度とする目安が示されています。
- 更新・安全管理：Docker Engine・OS、イメージの脆弱性、証明書
- 監視・復旧：ログ監視、バックアップ、復元テスト、容量計画、障害一次対応
- リリース：本番反映の支援
15〜20%は一般的な目安です。実際の金額は、対応時間、対象環境、休日・夜間対応、SLAによって増減します。保守の範囲に、復元試験やアップデートが除外されていないかも確認します。
Swarmのライセンス費用が無料でも、manager quorumの復旧やDBの可用性、ノード障害時のデータ復旧が自動で解決するわけではありません。
初期見積もり、月額クラウド費、保守契約、障害対応のスポット費は、分けて比べます。そうすると、サーバー料金だけで判断する誤りを防げます。
RFP・要件整理で決めるDocker Swarm固有の項目
RFPの品質は、見積もりを比べられるかどうかと、追加費用の多少を左右します。Swarmの採用を決めていても、動かす対象や水準が曖昧なままだと、会社ごとに異なる前提で提案が出てきます。
アプリの機能要件と、基盤・運用の非機能要件は分けて書きます。そのうえで、最低条件と、提案会社に選択を任せる項目も区別して記載します。
可用性・性能・拡張性の数値定義
可用性と性能は、測定できる条件に置き換えます。サーバーの台数だけで決まるとは限らないためです。
- 可用性：月間稼働目標、許容停止時間、RTO、RPO
- 性能：ピーク時の同時アクセス数、API応答時間、負荷試験のデータ量・測定方法・合格基準
- 拡張性：レプリカ数、スケール条件、ゾーン配置、想定するクラウド障害
managerを3台置いても、同じ障害ドメインに集中させていれば、可用性は高まりません。
workerを増やしても、性能問題が解決するとは限りません。DB接続数やストレージIOPSがボトルネックになることもあります。外部API制限や帯域が原因になる場合もあります。
負荷試験の条件を発注前に合意しておくと、納品直前に性能の認識がずれるのを減らせます。
DB・ファイル・秘密情報の扱い
DBやファイル、秘密情報は、保存先と復旧方法を含めて設計します。レプリカを増やしても、安全とは限りません。
- DB：マネージドサービス、専用ノード、共有ストレージ、レプリケーション製品を比較
- ファイル：オブジェクトストレージや共有ストレージを含めて設計
- 秘密情報：パスワード、TLS鍵、SSH鍵、外部サービス認証情報を埋め込まず、Swarm secretsなどを使用
バックアップと復元、フェイルオーバー、整合性の責任者を決めておきます。アップロードファイルや帳票も、ノードのローカルディスクだけに置くと、再配置や故障時に参照できなくなるおそれがあります。
Docker公式では、Secretsは転送中と保存時に暗号化されると説明されています。また、許可したサービスだけが実行中にアクセスできます（出典: Docker Docs「Manage sensitive data with Docker secrets」、2026年確認）。
RFPには、registry認証、daemon socketへのアクセス、最小権限を含めます。イメージスキャンとログのマスキングも書き込んでおきます。
RFPに書く納品物と責任分界
納品物は「ドキュメント一式」とまとめず、内容や形式まで具体化しておきます。あわせて、発注者と受託者の準備事項と責任範囲も決めます。
- 設計・実装：構成図、設計書、Dockerfile、stack定義、環境変数、Secrets手順、CI/CD
- 運用・検収：監視・アラート、バックアップ・復元、障害対応、テスト結果、運用マニュアル
- 権利・引き継ぎ：ソースコード、IaC、ライセンス一覧
納品物の形式は、ファイル名や更新時期まで決めておきます。引き継ぎ会の回数も、ここで決めます。
発注者の協力事項として、クラウドアカウント、DNS、証明書を整理します。加えて、マスタデータやテストユーザーの提供、業務確認者の配置、移行データの品質確保も書き出します。
受託者は、担当作業と時期、第三者サービスの契約主体を示します。障害時の一次連絡先と夜間対応の有無も、明らかにしてもらいます。
個人情報を扱う場合は、個人情報保護委員会のガイドラインに沿って確認します。組織的・人的・物理的・技術的な安全管理措置と、委託先監督も見ておきます。
委託先の選び方と見積比較のポイント
委託先は、「Swarmを触ったことがある」という一言では判断できません。工程ごとの説明力で比べます。要件整理やコンテナ化、データ移行を説明できるかを確認します。加えて、セキュリティや監視、障害復旧、保守、他社への引き継ぎについても、具体的に話せるかを聞いてください。
公開事例が少なくても、担当エンジニアの経験や設計書のサンプルは、具体的に見せてもらいます。あわせて、障害訓練の内容と、現在サポートできるバージョンも確かめます。
実績と保守体制の確認項目
候補会社の経験と保守体制は、具体的な実績や現行サポート情報から確認します。回答は、守秘義務に配慮した範囲で求めます。
- 基盤経験：規模、manager・worker構成、DB・ファイルの扱い、クラウド
- 運用実績：監視、バックアップ、障害対応、運用期間
- 提案の幅：要件に応じてKubernetes、マネージドサービス、単一ホスト構成も比較できるか
2026年時点で、MirantisのMKEにはSwarm-only modeの資料があります。ただし、MKE 3.7.xの資料には、2025年8月29日でメンテナンス終了との注記があります（出典: Mirantis Docs「Deploy Swarm-only mode」、2026年確認）。
現行版のサポート期間、アップグレード経路、契約後の相談窓口も、製品名とあわせて確認します。
Portainerの公開事例では、SwarmとKubernetesを併用するエネルギー企業が、管理基盤の導入後に開発者生産性15%向上を掲げています。開発者コストの170万米ドル削減や、稼働目標99.99%も示しています（出典: Portainer「Global Energy Company」事例、2026年確認）。
個別企業の事例であり、自社の効果として約束される数字ではありません。
見積書の内訳と除外項目の比べ方
見積もりの内訳は、同じRFPの条件で横に並べて比べます。金額だけでなく、その前提も確認します。工数や単価、期間に加えて、環境数やノード数も見ます。
- 開発・調査：要件定義、現状調査、アプリ改修
- 基盤構築：Dockerfile、stack定義、クラスタ、ネットワーク、registry
- 運用準備：監視、バックアップ、移行、テスト、教育、保守
人月・人日や単価、担当ロールが明記されているかを確かめます。環境数やノード数、クラウド費、ライセンス費、旅費の記載も確認します。
安すぎる提案では、除外されている作業を確認します。要件定義や負荷試験、復元試験のほか、監視や夜間対応、脆弱性対応、移行リハーサルが含まれているかを見ます。
高額な提案にも注意が要ります。設計書やIaCが納品されず、保守時間が大きい場合があるためです。
回答表、前提・制約・除外事項、検収条件を一緒に比べます。追加変更の単価も並べると、見積もりの見かけ上の差を見分けられます。
発注前に避けたい提案と確認方法
費用や安全性を言い切る提案では、根拠となる設計と試験内容を確かめます。ライセンス費用が無料でも、運用設計が不要とは限りません。
- 費用の断定：「Swarmは無料なのでサーバー代だけ」
- 可用性の断定：「1台構成で本番も問題ない」
- DBの断定：「レプリカを増やせば安全」
manager quorum、ストレージ、バックアップ、監視、アクセス制御、障害復旧について質問します。回答が設計書やテスト計画に反映されているかを確認してください。
将来の人材確保や移行を説明しない会社は避けます。移行を急がない場合でも、イメージや設定、CI/CD、監視、データの責任分界を標準化し、別基盤へ移りやすい設計を提案できるかを見ます。
書類だけでは分からない実務力は、契約前の担当者面談や設計レビュー、障害時の連絡演習で確かめられます。
Docker Swarmのシステム発注でよくある質問（FAQ）
発注時によくある質問を、機能の可否に加えて、本番運用、費用、将来性の観点から取り上げます。
Docker SwarmとKubernetesはどちらを発注すべきですか？
中小規模のWeb/APIや社内業務システムで、Dockerとの連続性と少人数での運用しやすさを重視するなら、Swarmは比較候補です。大規模マルチテナントや高度なPolicyを重視するなら、Kubernetesも同じRFPで比較します。周辺製品の多さや多様な人材の採用を重視する場合も、Kubernetesを比較の候補に入れます。そのため、技術を先に固めず、要件と総保有コストで選びます。
Docker Swarmは1台構成でも本番利用できますか？
技術的には、1台のDocker EngineでもSwarm modeを有効にできます。ただし、manager障害時の管理系復旧やサーバー障害への耐性は限られます。
学習や短期PoC、停止を許容できる小規模用途と、本番の可用性要件を満たすmanager 3台または5台の構成は、分けて考えます。単一障害点、復旧手順、許容停止時間は、受け入れ条件に入れておきます。
発注から本番稼働まで何か月かかりますか？
既存Composeの小規模移植なら、PoCを2〜4週間程度で実施できる可能性があります。
認証やDB連携、外部連携、データ移行、非機能試験を含む業務システムは、要件定義から本番まで3〜6か月程度が推定の目安です。
対象範囲が広い場合や、監査・災害対策が必要な場合は、6〜12か月以上も想定します。まずは小さな検証を行い、そのうえで本番計画を確定します。
まとめ
Docker Swarmのシステム発注では、Swarmの構築に加えて、業務アプリ、DB、ファイルも範囲に含めます。
registryやネットワークは、監視やバックアップと合わせて一つのシステムとして定義します。セキュリティや保守も、同じ範囲に含めます。
自社の体制に合わせて、一括委託、分離発注、PoC先行のいずれかを選びます。RFPには、RTO・RPOと性能を数値で示します。データ移行、納品物、責任分界は、成果物の形で書き込みます。
発注前に決めるべき事項
まず、本番で求める可用性とデータ復旧の水準を決めます。そのうえで、初期費用、クラウドの月額費用、年間保守費用を分けて、同じ前提で複数社の見積もりを比べます。
ソースコードやstack定義、IaCは、納品物として契約に含めます。監視、バックアップ、テスト結果、運用手順も、契約に入れておきます。
PoCとRFP作成への着手
採用判断に迷う場合は、1サービスを対象にPoCを行います。ノード障害、ローリング更新、ロールバック、バックアップ復元を試すと、判断材料がそろいます。
PoCの結果は、RFPに反映します。Swarmを採用する場合でも、別基盤へ移行する場合でも、運用できる設計と契約を選んでください。
▼全体ガイドの記事
・Docker Swarmのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。