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

Docker Swarmのシステム発注では、Dockerコンテナで構成した業務システムを複数ホストへ配置し、可用性・セキュリティ・運用まで含めて委託範囲を決めることが成功のポイントです。

「Docker Swarmを使えば安く簡単に作れるのか」「どの会社へ外注すればよいのか」「見積書の金額をどう比較すればよいのか」と悩む担当者は少なくありません。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、受け入れ時の確認事項まで、2026年時点でDocker Swarmのシステム開発を依頼するための実務を順に解説します。

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

Docker Swarmのシステムとは何ですか？

Docker Swarmのシステムとは、Docker Swarmそのものを業務アプリケーションとして作ることではなく、Dockerコンテナ化したWeb、API、バッチ、キューなどを複数のサーバーへ配置して運用する業務システムの構成を指します。Docker Engineに組み込まれた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には「Docker EngineのSwarm modeを対象とする」と明記し、対象バージョン、OS、コンテナイメージの保管先、サポート期限も確認する必要があります。

発注対象は、アプリケーションの開発だけではありません。managerとworkerの台数・役割、private registry、ロードバランサーやリバースプロキシ、overlay network、TLS、DBとファイルの永続化、CI/CD、監視、ログ、バックアップ、障害時の連絡体制までを含めて考えます。WebとAPIのようなステートレスなサービスは複数ノードへ配置しやすい一方、DBやアップロードファイルを安易にコンテナへ置くと、コンテナの再配置時にデータを失うおそれがあります。

本番で高可用性を求める場合はmanagerを3台または5台の奇数構成にし、workerとは役割を分ける設計が候補になります。1台構成は学習やPoCには適しますが、manager障害から本番環境を復旧できる構成とは別物です。発注時には、可用性の目標を「何台落ちても稼働するか」「何分以内に復旧するか」という要件に置き換えてください。

発注形態はどれを選べばよいですか？

発注形態は、業務アプリと基盤を一括で任せるか、社内・別会社と分担するか、PoCから段階的に広げるかで選びます。Docker Swarmに詳しい会社を探すことも大切ですが、責任分界が曖昧なまま複数社へ分離発注すると、障害時に原因の押し付け合いが起きやすいため、先に自社の体制と運用力を整理することが重要です。

社内にインフラ担当が少なく、業務フローも含めて整理したい場合は、SI会社や開発会社へ要件定義、アプリ開発、Swarm構築、移行、保守を一括委託する方法が向いています。窓口が一つになるため、DBの接続、監視通知、リリース手順などの境界を調整しやすくなります。ただし、一式見積もりだけでは人員や成果物が見えにくいため、作業項目、担当者、テスト範囲、納品物、保守時間を分解して提示してもらいます。

アプリに強い会社とクラウド・インフラに強い会社を分けると、それぞれの専門性を活かしやすくなります。たとえば業務アプリ会社がDockerfile、healthcheck、ログ、環境変数を整備し、インフラ会社がクラスタ、ネットワーク、registry、監視、バックアップを構築する分担です。この場合は、イメージの脆弱性対応、障害一次切り分け、リリース承認、データ復旧の責任者を契約書と運用設計書に明記します。

発注者がプロジェクトマネジメントを担えない場合は、第三者のPMや上位SI会社を置く選択肢もあります。会社を増やすほど調整費と会議コストが増えるため、価格だけでなく、仕様変更や障害の意思決定が何営業日で行えるかを比べてください。

Swarmを採用するかKubernetesなどと比較中の場合は、最初から大規模な本番構築を依頼せず、1〜2台の検証環境で既存Composeの移植、ローリング更新、ロールバック、ノード停止、バックアップ復元を確認する方法が安全です。PoCの受け入れ条件に「技術的に動いた」だけでなく、復旧時間、運用担当者の手順理解、ログの追跡性、セキュリティチェックを含めます。

PoC後に本番へ進む場合は、PoCで作った定義をそのまま使える部分と、本番用に再設計する部分を分けて見積もります。検証を本番化するか、別会社へ引き継ぐか、採用を見送るかの判断基準を事前に決めておくと、不要な追加開発を抑えられます。

Docker Swarmのシステム発注・外注はどう進めますか？

発注を成功させるには、技術用語を並べる前に業務上の目的と非機能要件をそろえ、RFPで複数社へ同じ条件を渡すことが大切です。要件定義、提案比較、契約、設計・開発、テスト・移行、保守開始の順に進め、各段階で発注者が確認する成果物を決めておきます。

RFPには、業務の目的、利用者と権限、画面・API・バッチの範囲、既存システムとの連携、データ移行量、想定ユーザー数、ピーク時の同時アクセス数、稼働時間、許容停止時間、RTOとRPO、監査・個人情報の扱いを記載します。特に「高可用性」「安全に運用」といった抽象語は、manager台数、バックアップ頻度、復旧テスト、監視通知の時間などに置き換えてください。

既存Compose環境がある場合は、Composeファイル、Dockerfile、環境変数一覧、外部サービス、データベース容量、ログの保管期間、リリース頻度、現在の障害履歴を添付します。発注者側で準備できない情報があれば、現状調査を別作業として見積もるよう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を移植し、イメージ化、Swarm基本設定、簡易デプロイを行う場合は、50万円〜150万円程度、期間は2〜4週間が一つの目安です。3〜5台の小規模本番で、managerとworkerの分離、registry、TLS、CI/CD、監視、バックアップ、リリース手順まで整える場合は、200万円〜500万円程度、1〜3か月程度がたたき台になります。

認証、DB連携、バッチ、外部連携、データ移行、権限、障害試験、運用教育を含む業務システムでは、500万円〜1,500万円程度、3〜6か月程度が推定レンジです。本番とステージングの分離、災害対策、厳格な監査ログ、性能・負荷試験、24時間運用まで必要な場合は、1,500万円〜5,000万円以上、6〜12か月程度になる可能性があります。これらは公開されたDocker Swarmの定価ではなく、要件に応じた見積もりレンジとして利用してください。

クラウドの仮想サーバー料金は、開発費とは別に毎月発生します。たとえばAWS LightsailのLinux/Unix仮想サーバー公開料金は、公開ページ上で0.5GBが月額5米ドル、2GBが12米ドル、4GBが24米ドル、8GBが44米ドルです（出典: Amazon Lightsail Pricing、2026年8月確認）。計算上、検証用に2GB相当を5台なら月額60米ドル相当、3台のmanagerと2台のworkerを4GB相当で置けば月額120米ドル相当が出発点になります。

ただし、この試算は仮想サーバーだけの机上計算です。ロードバランサー、固定IP、バックアップ、監視、private registry、オブジェクトストレージ、DB、データ転送、ログ保管、商用サポート、運用担当者の工数は別にかかります。円換算は為替で変動するため、見積書では米ドル表記のままにせず、前提レートと月額の変動要因を明記してもらいます。

保守費用には、Docker EngineやOSの更新、コンテナイメージの脆弱性対応、証明書更新、ログ監視、バックアップ、復元テスト、容量計画、障害一次対応、リリース支援を含めます。社内Q&Aでは、年間保守を初期開発費の15〜20%程度とする目安が示されていますが、これは一般的な目安であり、対応時間、対象環境、休日・夜間対応、SLAによって増減します。月額保守を安く見せるために復元試験やアップデートを除外していないか確認してください。

Swarmはソフトウェアのライセンス費用が無料でも、manager quorumの復旧やDBの可用性、ノード障害時のデータ復旧を自動的に解決するわけではありません。初期見積もり、月額クラウド費、保守契約、障害対応のスポット費を分けて比較すると、安いサーバー料金だけで判断する誤りを防げます。

RFP・要件整理で決めるべきDocker Swarm固有の項目は何ですか？

RFPの品質は、見積もりの比較可能性と追加費用の少なさを左右します。Docker Swarmを使うことを先に決めても、何をどの水準で動かすかが曖昧なら、会社ごとに異なる前提で提案されます。アプリの機能要件と基盤・運用の非機能要件を分け、最低限の条件と提案会社に任せる選択項目を分けて記載します。

「止まらないシステム」ではなく、月間の稼働目標、許容停止時間、RTO、RPO、ピーク時の同時アクセス数、API応答時間、レプリカ数、スケール条件を記載します。3台のmanagerを置く場合でも、同じ障害ドメインに集中していれば可用性は高まりません。異なるゾーンへ配置するか、クラウド障害をどこまで想定するかも提案依頼に含めます。

workerを増やせばすべての性能問題が解決するわけではありません。DBの接続数、ファイルストレージのIOPS、外部APIの制限、ネットワーク帯域がボトルネックになる場合があります。負荷試験のデータ量、測定方法、合格基準を発注前に合意すると、納品直前の「遅い・足りない」という認識違いを減らせます。

DBは、複数コンテナへ単純にレプリカを増やせば安全になるものではありません。マネージドDB、DB専用ノード、共有ストレージ、レプリケーション製品のどれを使うかを比較し、バックアップ、復元、フェイルオーバー、整合性の責任者を決めます。アップロードファイルや帳票も、ノードのローカルディスクにだけ保存すると再配置や故障時に参照できなくなるため、オブジェクトストレージや共有ストレージを含めて設計します。

パスワード、TLS鍵、SSH鍵、外部サービスの認証情報はDockerfileやソースコードへ埋め込まず、Swarm secretsなどの仕組みを使います。Docker公式では、Secretsは転送中と保存時に暗号化され、許可したサービスだけが実行中にアクセスできると説明されています（出典: Docker Docs「Manage sensitive data with Docker secrets」、2026年確認）。加えて、registry認証、daemon socketへのアクセス、最小権限、イメージスキャン、ログのマスキングもRFPに含めてください。

納品物は、クラスタ構成図、設計書、Dockerfile、stack定義、環境変数一覧、Secretsの登録・更新手順、CI/CD設定、監視・アラート設定、バックアップと復元手順、障害対応手順、テスト結果、運用マニュアル、ソースコード、IaC、ライセンス一覧まで具体化します。「ドキュメント一式」だけでは不足しやすいため、ファイル名や形式、更新時期、引き継ぎ会の回数も決めます。

発注者が用意するクラウドアカウント、DNS、証明書、マスタデータ、テストユーザー、業務確認者、移行データの品質を協力義務として整理します。受託者側は、どの作業を誰がいつ行うか、第三者サービスの契約主体、障害時の一次連絡先、夜間対応の有無を示します。個人情報を扱う場合は、個人情報保護委員会のガイドラインに沿って、組織的・人的・物理的・技術的な安全管理措置と委託先監督を確認します。

委託先の選び方と見積比較のポイントは何ですか？

委託先は「Swarmを触ったことがある」という一言では判断できません。業務要件の整理、コンテナ化、データ移行、セキュリティ、監視、障害復旧、保守、他社への引き継ぎまで一貫して説明できるかを確認します。公開事例が少ない場合でも、担当エンジニアの経験、サンプルの設計書、障害訓練の内容、現在サポートできるバージョンを具体的に聞いてください。

候補会社には、過去に担当したコンテナ基盤の規模、managerとworkerの構成、DBやファイルの扱い、クラウド、監視、バックアップ、障害対応、運用期間を、守秘義務に配慮した範囲で説明してもらいます。Docker Swarmを指定する場合でも、要件に応じてKubernetes、マネージドサービス、単一ホスト構成を比較できる会社のほうが、技術を目的化しにくくなります。

2026年時点では、MirantisのMKEにSwarm-only modeの資料がありますが、MKE 3.7.xの資料には2025年8月29日でメンテナンスを終了した旨の注記があります（出典: Mirantis Docs「Deploy Swarm-only mode」、2026年確認）。このように、製品名だけでなく現行版のサポート期間、アップグレード経路、契約後に相談できる窓口を確認します。Portainerの公開事例では、Docker SwarmとKubernetesを併用するエネルギー企業が、管理基盤の導入後に開発者生産性15%向上、開発者コスト170万米ドル削減、99.99%の稼働目標を掲げていますが、個別企業の事例であり、自社の効果として約束される数字ではありません（出典: Portainer「Global Energy Company」事例、2026年確認）。

見積比較では、総額の安さよりも、要件定義、現状調査、アプリ改修、Dockerfileとstack定義、クラスタ構築、ネットワーク、registry、監視、バックアップ、移行、テスト、教育、保守の各金額を横並びにします。人月・人日、単価、担当ロール、期間、環境数、ノード数、クラウド費、ライセンス費、旅費などの前提が示されているかを確認してください。

極端に安い提案では、要件定義、負荷試験、復元試験、監視、夜間対応、脆弱性対応、移行リハーサルが除外されていないか確認します。反対に高い提案でも、設計書やIaCが納品されず、保守の時間だけが大きい場合があります。RFPに対する回答表、前提・制約・除外事項、追加変更の単価、検収条件をセットで比較すると、見積もりの見かけ上の差を正しく判断できます。

「Swarmなら無料なのでサーバー代だけで済む」「1台構成で本番も問題ない」「DBもレプリカを増やせば安全になる」と断定する提案には注意が必要です。費用を抑えられる可能性があることと、運用設計が不要であることは別です。manager quorum、ストレージ、バックアップ、監視、アクセス制御、障害復旧を質問し、回答が設計書やテスト計画に反映されるかを確かめます。

また、Docker Swarmだけを使うことを前提にして、将来の人材確保や移行を説明しない会社も避けます。移行を今すぐ実施する必要はなくても、イメージ、設定、CI/CD、監視、データの責任分界を標準化し、Kubernetesなど別基盤へ移りやすい設計を提案できるかを見ます。契約前に担当者の面談、設計レビュー、障害時の連絡演習を行うと、書類だけでは分からない実務力を確認できます。

Docker Swarmのシステム発注でよくある質問（FAQ）

ここでは、Docker Swarmのシステムを発注するときに特に質問されやすい点をまとめます。機能の可否だけでなく、本番運用、費用、将来性の観点で判断してください。

中小規模のWeb/APIや社内業務システムで、Dockerとの連続性と少人数での運用しやすさを重視するなら、Swarmは比較候補になります。大規模マルチテナント、高度なPolicy、多数の周辺製品、多様な人材採用を重視するなら、Kubernetesも同じRFPで比較してください。最初から技術を固定せず、要件と総保有コストで選ぶ方法が安全です。

技術的には1台のDocker EngineでSwarm modeを有効にできますが、manager障害時の管理系復旧やサーバー障害への耐性は限られます。学習、短期PoC、停止を許容できる小規模用途と、本番の可用性要件を満たす3台または5台のmanager構成は分けて考えます。発注時は、単一障害点、復旧手順、許容停止時間を受け入れ条件に入れてください。

既存Composeの小規模移植なら、PoCを2〜4週間程度で実施できる可能性があります。認証、DB連携、外部連携、データ移行、非機能試験を含む業務システムでは、要件定義から本番まで3〜6か月程度が推定の目安です。対象範囲が広い場合や監査・災害対策が必要な場合は6〜12か月以上も想定し、先に小さな検証を行ってから本番計画を確定します。

まとめ

Docker Swarmのシステムを発注するときは、Swarmの構築作業だけでなく、業務アプリ、DB、ファイル、registry、ネットワーク、監視、バックアップ、セキュリティ、保守までを一つのシステムとして定義します。発注形態は自社の体制に合わせて一括委託、分離発注、PoC先行を選び、RFPではRTO・RPO、性能、データ移行、納品物、責任分界を数値と成果物で示してください。

第一に、本番で求める可用性とデータ復旧の水準を決めます。第二に、初期費用、クラウドの月額費用、年間保守費用を分け、同じ前提で複数社の見積もりを比較します。第三に、ソースコード、stack定義、IaC、監視、バックアップ、テスト結果、運用手順を納品物として契約に含めます。

採用判断に迷う場合は、1サービスを対象にPoCを行い、ノード障害、ローリング更新、ロールバック、バックアップ復元を実際に試すことをおすすめします。その結果をRFPへ反映し、Docker Swarmを採用する場合も、別基盤へ移行する場合も、運用できる設計と契約を選んでください。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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