Docker Swarmのシステム開発の完全ガイド

Docker Swarmのシステムは、複数のDocker Engineを束ね、コンテナ化したサービスを本番で動かす基盤です。要点は、複数台のサービス管理と、小さく始めて本番へ広げる進め方です。

運用要件の設計を押さえると、業務システムの安定運用に役立ちます。詳しくは関連記事もご覧ください。

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

Docker Swarmのシステムの全体像

目的に応じて本番構成の規模を考えられます。

業務アプリは、Docker Swarmのシステムという基盤の上で動きます。基盤側では、複数のDocker Engineを束ね、コンテナ化したサービスを本番で運用します。

Docker Engine内蔵のSwarm modeを使うため、別のオーケストレーターを追加せずに、サービスの配置や台数を宣言的に管理できます。さらに、Docker公式ドキュメントは、本番ランタイムの機能を説明しています（出典：Docker公式ドキュメント「Swarm mode」、2026年8月確認）。

挙げられているのは、クラスタ管理とサービスディスカバリ、内部ロードバランシング、ローリング更新などです。

Swarm modeと旧Docker Classic Swarmの違い

業務システムで検討する対象は、Docker Engineに内蔵されたSwarm modeです。一方で、Docker Classic Swarmは別の仕組みで、公式ドキュメントでは積極的に開発されていないものとして区別されています。提案書やRFPに「Docker EngineのSwarm mode」と明記しておくと、対象技術の認識違いを防げます。

managerノードとworkerノードの役割分担

Swarmでは、サーバーをノードと呼びます。managerは全体の状態を管理し、workerはコンテナを実行します。

managerは、「Webサービスを3つ稼働させる」「メモリを一定量までに制限する」といった状態を保持します。保持する状態との差分を検知すると、空いているノードへタスクを再配置します。このため、workerに障害が起きても、利用可能なノードがあれば、指定したレプリカ数へ戻る動きが期待できます。

構成の3パターン（検証・小規模本番・高可用性）

Docker Swarmの構成は、目的別に分けると全体像を整理できます。

学習・PoC型：1〜2台で動作を確認します。
小規模本番型：3〜5台でWebやAPIを運用します。
高可用性型：managerを3台または5台にし、複数環境、監視、バックアップ、障害訓練を組み込みます。

PoC型は、そのまま本番へ広げられるとは限りません。見積もりの前提には、作る構成の種類を明記しておきます。

Compose環境から複数台の本番構成への拡張

Docker Composeは、1台の開発環境で複数コンテナをまとめて起動するのに向いています。一方で、Swarm modeは、複数ホストのサービス配置やネットワーク、更新方法を管理します。

本番では、Composeファイルに加えて、レジストリ、healthcheck、Secretsを設計します。さらに、永続ボリューム、リソース制限、更新・ロールバック方針も決めます。

ポイント

Docker Swarmを検討するときは、対象をDocker EngineのSwarm modeに絞り、構成の規模と本番に必要な構成要素を、目的と照らし合わせて判断します。

Docker Swarmのシステムでできることと向いている業務

複数台運用で活用する機能を見渡せます。

Docker Swarmの価値は、複数台の運用に必要な配置と通信、更新、障害復旧を、一つの運用モデルにまとめられる点です。

たとえば、WebやAPIのように、同じイメージを複数起動しやすいサービスと相性があります。管理画面やバッチ、キュー処理にも、相性があります。

データベースは、単純に複製しても可用性が上がるとは限りません。そのため、状態を持つサービスは別に設計します。

Web・API・バッチなどステートレスなサービスへの適性

ステートレスなサービスは、どのコンテナで処理しても、外部に保存したデータを使えば同じ結果を返せます。

商品検索API、社内ポータル、帳票生成ワーカーは、イメージをそろえ、セッションやファイルを外部へ移せば、複数レプリカで動かせます。

ステートレスなサービスは、ノードの入れ替えやローリング更新を行いやすく、平日日中に停止しにくい業務システムで効果を発揮します。

レプリカ数の変更とローリング更新

アクセスが集中する時間帯は、Webサービスのレプリカを増やせます。処理量に応じて、バッチの並列数も調整できます。

更新時は、同時に入れ替えるタスク数や待ち時間を設定し、新しいイメージへ段階的に切り替えます。healthcheckが失敗した場合は更新を止め、原因を確認してから前のバージョンへ戻す運用も可能です。そのうえで、失敗時に戻れることを受入条件に含めます。

中小規模の業務システムでの複雑さと可用性のバランス

少人数のチームがDockerの知識を活かして複数台運用へ進む場合、Docker Swarmは候補になります。

導入時は、運用をどれだけ整理しやすいか、将来必要な機能を満たすかに照らして判断します。

運用の整理：台数やサービス定義、ネットワーク、更新を、同じCLIと設定ファイルで扱えます。
比較する要件：多数チームでの共有や細かなポリシー制御、幅広い周辺ツールが必要な場合は、Kubernetesも比べます。
採用判断：必要な運用機能を満たすかどうかで判断し、「簡単そうだから」を理由にしません。

Docker Swarmのシステム構成と他の選択肢との違い

クラスタの外側にも設計対象が広がります。

本番構成では、アプリ、クラスタ管理、公開経路を分けて設計します。データ保存や開発・運用の仕組みも、設計の対象に含めます。

DBやバックアップの責任は、Docker Swarmの導入とは別に決める必要があります。そのため、どのデータを何分以内に、どの状態まで復旧するかを中心に、構成を決めます。

最低限そろえる構成要素

Swarmを本番で運用するには、ノード以外にも通信、保存、運用の基盤が必要です。

ノード：クラスタ管理用のmanagerと、コンテナ実行用のworker。
公開・配布経路：private registry、ロードバランサーまたはリバースプロキシ。
ネットワーク：ノード間をつなぐoverlay network。
永続ストレージ：DBやファイルの保存先。
開発・運用基盤：CI/CD、監視、ログ、バックアップ。

本番の可用性を考えると、managerは3台または5台の奇数構成を候補にします。1台の検証環境は学習には便利ですが、本番の障害耐性を示す構成ではありません。

ComposeとKubernetesとの違い

Composeは、主に1台の開発・検証環境で複数コンテナを定義するものです。一方で、Swarm modeは、複数のDocker Engine上でサービスの数と配置を管理します。

Kubernetesは、大規模な組織や複雑なネットワークポリシーを前提にしやすい仕組みです。マルチテナントや豊富な周辺ツールに対応する分、学習・設計・運用の負荷が増えます。

小規模なら常にSwarm、大規模なら必ずKubernetesとは限りません。非機能要件と将来の運用体制を比べて選びます。

ステートレスとステートフルの分離

WebやAPIはworker間を移動できるようにし、セッション、ファイル、DBデータをコンテナのローカルディスクに残さない構成が基本です。

DBを複数レプリカにする場合は、レプリケーションとフェイルオーバーの方式を設計します。書き込みの整合性や、バックアップからの復元も設計に含めます。

まずは、データの責任範囲が明確な方式を検討します。マネージドDB、共有ストレージ、DB専用ノードなどが候補です。「replicasを増やす」だけの設計は避けます。

Docker Swarmのシステム開発・導入の進め方

導入では、業務要件と可用性、セキュリティを決めたうえで、データ移行と運用分担も決めます。PoCで小さく検証してから本番へ広げます。サーバーの用意とコマンドの実行は、その一部にすぎません。

外部へ依頼する場合は、試験と納品物、引き継ぎ、障害時の連絡方法まで、発注側が計画に含めます。

▶ 詳細はこちら：Docker Swarmのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 要件定義での業務要件と非機能要件の決定

まず、利用者や業務フロー、認証方式を整理します。あわせて、外部連携、データ分類、ピーク時の同時アクセス数を洗い出します。

許容停止時間、RTO（目標復旧時間）、RPO（目標復旧時点）は、数値で明記します。稼働時間、監査ログの保存期間、リリース可能時間も、数値で決めておきます。

「なるべく止めない」より、「重大障害は4時間以内に復旧し、前日24時時点までのデータを復元する」のように定めておくと、ノード数やバックアップ、監視の見積もりが具体化します。

2. アプリケーションのコンテナ化と実行条件の統一

既存アプリは、Dockerfileを整備し、イメージを一貫してビルドできる状態にします。

環境変数、healthcheck、標準出力ログを定義し、CPU・メモリの上限も決めます。終了処理、タイムゾーン、ファイル保存先も決めておくと、開発・ステージング・本番の差分を抑えられます。

イメージはタグを固定し、レジストリから取得できるようにします。latestだけでは中身が変わって再現性を失うため、バージョンやコミットIDで管理します。

3. クラスタ、ネットワーク、公開経路の設計

本番環境の配置と接続条件を決めるために、クラスタとネットワークの設計項目を一覧にします。

ノード数：managerを3台または5台の奇数構成とするか、workerを何台用意するかを決めます。
配置と公開：managerを業務負荷から分けるか、特定サービスを特定ノードに置くか、ロードバランサーを設けるかを定めます。
通信と更新：管理通信と公開ポートを絞り、overlay networkとクラスタ参加の経路を定めたうえで、DNSとTLS証明書の更新担当を決めます。

ネットワーク設計を後回しにすると、アプリは起動しても、サービス間通信や外部接続で止まってしまいます。

4. 試験、リリース、運用引き継ぎ

受入試験では、正常系に加えて、次のような障害と復旧も確認します。

worker停止、managerの一部停止、レジストリ接続失敗の試験。
コンテナの異常終了、更新失敗、ロールバック。
証明書期限切れと、DBバックアップからの復元。
監視通知の宛先と、切り分けの担当・手順の訓練。

納品物には、stack定義やDockerfileのほか、構成図やパラメータシートも含まれます。さらに、運用・障害対応手順とバックアップ・復元手順、ソースコード、CI/CD設定まで、範囲を明記します。

ポイント

導入の範囲は、非機能要件を数値で決めたうえで、PoCの結果を見ながら本番へ広げます。外部へ依頼するなら、試験や引き継ぎも計画に含めます。

Docker Swarmのシステム開発費用相場とコストの内訳

開発費は、Docker Swarm自体のライセンス料金より、作業の積み上げで大きく変わります。中心になるのは、要件定義とアプリ改修、クラスタ構築です。

このほか、ネットワーク整備や監視、バックアップ、移行の作業も費用を構成します。試験や運用教育も費用に加わります。

この金額は、業務システムの規模と基盤工数から作った見積もりのたたき台で、日本向けの標準価格表ではありません。データ量やSLA、既存環境、セキュリティ要件によって、金額は大きく変わります。そのため、発注時は内訳を確認します。

▶ 詳細はこちら：Docker Swarmのシステム開発の見積相場や費用/コスト/値段について

初期費用の目安（PoCは50万〜150万円、本番は200万円以上）

初期費用は、構成の規模と、どこまでの作業を含めるかで大きく変わります。区分ごとの費用の幅は、下の箇条書きに示します。

学習・PoC：1〜2台の非本番環境でCompose移行、イメージ化、基本デプロイを確認し、50万〜150万円程度。
小規模本番の規模：manager・workerを3〜5台で構成します。
小規模本番の費用：registry・TLS・CI/CD・監視・backup・release手順を含めて、200万〜500万円程度。
業務システム：認証・DB・バッチ・外部連携・データ移行を含め、500万〜1,500万円程度。
高可用性など：複数環境や厳格な監査要件まで求めると、1,500万〜5,000万円以上になる場合があります。

これらは、要件ごとの推定レンジで、公開された一律の価格ではありません。コンテナ化されていない既存アプリでは、改修やテスト、環境差分の解消が増えます。

標準化されたステートレスなサービスを少数だけ移す場合は、PoCから段階的に進めることで、初期費用を抑えられる可能性があります。

月額インフラ費の範囲（サーバー代と運用費）

公開料金表の一例では、Linux系仮想サーバーは0.5GBで月5米ドル、2GBで12米ドル、4GBで24米ドル、8GBで44米ドルです（出典：クラウド仮想サーバーの公式料金表、2026年8月6日確認）。

この単価を、5台構成とmanager・workerの混成構成に当てはめた例です。

5台構成：2GB相当をそろえると月60米ドルです。
manager・worker構成：3台のmanagerと2台のworkerを4GB相当にすると月120米ドルです。

円換算は為替で変わります。このほか、ロードバランサーや固定IP、バックアップ、監視が加わります。さらに、レジストリやストレージ、転送の費用に加えて、サポートや運用人件費も考えます。

見積書では、「クラウド利用料」と「構築・保守費」を分けると比べやすくなります。検証環境の夜間停止、ログ保存期間、バックアップ世代数によっても、月額は変わります。

インスタンスの安さで選ぶ前に、RTO・RPOを守れる構成を決めます。

年間保守費の起点（初期開発費の15〜20％）

年間保守は、初期開発費の15〜20％程度を目安にできます。その範囲には、Docker Engineやベースイメージの更新、脆弱性・証明書対応、容量監視が含まれます。ノードの追加も対象です。

バックアップ確認と復元テストのほか、障害一次対応や手順書の更新も対象です。24時間365日の監視や短時間復旧を求める場合は、待機体制と対応時間を別途定めます。

監視や復元テストを保守の対象から外すと、障害時には復旧費用が別途かかります。

ポイント

費用は、初期費用と月額インフラ費、年間保守費を分けて見積もり、作業の範囲をそろえて比べます。金額は規模やデータ量、SLAで大きく変わるため、内訳を確認したうえで判断します。

セキュリティと運用で失敗しないDocker Swarmの設計

コンテナを使えば安全になるとは限りません。そのため、認証や権限、イメージの脆弱性対応を運用に組み込みます。秘密情報とログの扱い、バックアップ、ネットワークも、運用の手順に含めます。

個人情報を扱う業務では、アクセスの承認や委託先との責任分担、点検と改善の記録も必要になります。

Secretsと最小権限による認証情報の保護

認証情報の保管場所と利用権限を定め、漏えいにつながる扱いを避けます。

格納場所：DBパスワードやTLS秘密鍵、SSH鍵を、Dockerfileやソースコード、公開設定ファイルに書き込みません。
ログと権限：アプリのログへ秘密情報を出さず、管理者権限を絞ります。

Swarm secretsは、許可したサービスへ実行時に秘密情報を渡す仕組みです。公式資料では、manager間を相互TLSで送り、暗号化したRaftログに保存すると説明されています。

コンテナ内では、メモリ上のファイルとして扱われます（出典：Docker公式ドキュメント「Manage sensitive data with Docker secrets」、2026年8月確認）。

永続データの再配置と復元の設計

コンテナが別ノードへ移動しても、DBやファイルを失わない仕組みを用意します。

データの配置方式と復元性については、次のとおり検討します。

bind mount：ローカルディスク方式は再配置先に同じデータとパスが必要で、障害耐性を下げる場合があります。
保存と復元：共有ストレージ、専用DB、マネージドサービスを比べ、別環境で復元後にアプリが動くか確認します。

たとえばRPOが1時間なら、バックアップの頻度と転送時間が1時間以内に収まるかを検証します。

個人情報を扱う場合の法令と責任の範囲

まず、誰がどのデータへアクセスし、どの操作を記録するかを決めておきます。加えて、委託先の処理環境と、漏えい時の報告・通知の判断者も定めます。

個人情報保護委員会のガイドラインは、安全管理措置に加え、評価、見直し、改善の考え方を示しています（出典：個人情報保護委員会「個人情報保護法ガイドライン（通則編）」、2026年6月改正版）。

法令対応は、Docker Swarmの導入とは別に進めます。契約書と運用規程にも、責任範囲を反映します。

よくある失敗：起動確認だけで本番可否を決めること

1台で起動して画面が表示されても、それだけで本番条件を満たしたとはいえません。PoCでは、本番運用で起きうる障害要因を試しておきます。

可用性：managerを1台だけにして耐障害性を誤認する。
データ整合性：DBを複製するだけで整合性を壊す。
設定・情報管理：イメージタグを固定せず、秘密情報を環境変数へ渡す。
復旧・体制：復元試験をせず、障害時の担当者も決めない。

PoCでは、ノード停止とDB復元、更新失敗、アクセス権限を確かめ、その結果を本番採用の判断材料にします。

ポイント

セキュリティの判断は、認証情報の保護と永続データの復元、個人情報の責任分界を、運用の手順まで含めて行います。個人情報を扱う業務では、委託先との責任分担も、この判断に含めて考えます。

Docker Swarmのシステム開発会社・ベンダーの選び方

依頼先は、構築経験だけでなく、業務要件や移行、セキュリティを説明できるかで選びます。監視や障害復旧、将来の移行まで説明できるかも確かめます。

公開事例からは、担当者の経験や保守範囲までは分かりにくいものです。そのため、提案の段階で構成図と障害対応を確かめ、同じ条件で見積もりを比べます。

経験だけでなく担当範囲と納品物の確認

過去のクラスタ規模やmanagerとworkerの台数を質問し、状態を持つサービスの扱いも聞きます。バックアップ方式や障害訓練についても、確かめます。

要件定義、設計、移行、監視、保守、引き継ぎのうち、どこまで担当するかを明確にします。

IaCやstack定義、Dockerfileを受け取れるかも確認します。構成図と試験成績書、運用手順、ソースコードまで含め、成果物の範囲を確かめます。

見積もりの比較（人日・環境数・保守時間の内訳）

一式で書かれた見積もりだけでは、価格差の理由を判断できません。作業ごとの範囲と前提を分けて確認します。

開発作業：要件定義、PoC、アプリ改修、クラスタ構築。
基盤・移行：ネットワーク、セキュリティ、データ移行、試験。
継続作業：教育、保守、監視、バックアップ、夜間障害対応。

見積書には、環境数や人日、単価、前提条件も記載してもらいます。特に、安価な提案では、対象外の作業と追加単価を先に確かめます。

将来の引き継ぎとKubernetes移行の説明

2026年時点でSwarmを採用する場合は、数年後も使い続けるか、別のオーケストレーターへ移る可能性があるかを話し合います。

将来の選択肢と引き継ぎ範囲を確かめるため、依頼先には次のとおり確認します。

移行しやすい設計：Composeやstack定義を標準的に保ち、責任を分けたうえでデータ移行手順を文書化します。
引き継ぎの範囲：移行時に作り直す部分と、引き継ぎ後に自社で変更できる範囲を説明してもらいます。

▶ 詳細はこちら：Docker Swarmのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Docker Swarmのシステム開発の発注/外注/依頼/委託方法について

ポイント

依頼先は、構築経験だけでなく、担当範囲と納品物、見積もりの内訳を同じ条件で比べて選びます。対象外の作業と追加単価を先に確かめると、価格差の理由が見えやすくなります。

Docker Swarmのシステムに関するよくある質問

業務利用では、費用や可用性、データ保護、将来性も判断材料になります。導入前によくある質問に、順に答えます。

Docker Swarmは2026年でも本番利用できますか？

本番利用は可能ですが、要件に合うか検証してから採用します。Docker EngineにはSwarm modeが組み込まれ、公式資料にも本番ランタイムの機能が整理されています。

運用体制や担当者、将来の移行計画は、自社で確認します。監視やバックアップ製品への対応も確かめます。

managerとworkerは何台必要ですか？

検証は1台でも始められます。本番のmanagerは3台または5台の奇数構成を候補にします。

worker数は、レプリカ数や障害時の余力から決めます。CPU・メモリとメンテナンス中の稼働条件も、判断材料になります。

台数は、1台停止時にRTOを満たせるか、manager quorumを維持できるかを試験して決めます。

DBも複数レプリカにすれば安全ですか？

DBは、複数レプリカにするだけでは安全になりません。方式や書き込み先、フェイルオーバーを設計して、安全性を確保します。整合性と永続ボリュームの設計も欠かせません。

バックアップと復元手順も定め、必要ならマネージドDBや専用構成を使います。Docker公式のSecrets事例も、単一DBの単純な複製とは別にDBクラスタの構築が必要と説明しています。

小さく始めるなら何を検証すべきですか？

まずはステートレスなサービスをコンテナ化し、registryから複数ノードへデプロイします。そのうえで、更新と障害時の動き、権限、監視と復元を試します。

ローリング更新と、失敗時のロールバック。
worker停止時の再配置と、Secretsの権限。
ログ・監視と、バックアップからの復元。

PoCの完了を、「起動できた」ではなく「障害時に決めた時間内で復旧できた」と定義しておくと、本番移行を判断しやすくなります。

Docker Swarmのシステム開発を成功させるためのまとめ

Docker Swarmは、Dockerコンテナの業務アプリを複数ホスト上で安定運用する選択肢です。managerとworkerによる役割分担とレプリカ管理、overlay networkやサービスディスカバリ、更新とロールバックを活用できます。

特に、ステートレスなWeb・API・バッチを中心とする中小規模の業務システムでは、既存のDocker知識から段階的に本番運用へ進めやすい点が利点です。

最初のPoCでの障害復旧とデータ保護の検証

採用前に、1サービスの小さなPoCを行い、要件と費用、運用体制を確認します。そのうえで、managerを3台または5台にした構成を検証し、DBとファイルの永続化、Secretsも試します。監視やバックアップも検証対象に含めます。

ノード障害と更新、ロールバックも試し、その結果を本番設計に反映します。外部へ依頼する場合は、初期構築費と保守費に加え、復元訓練の範囲や納品物も比べます。責任分界と将来の引き継ぎについても、依頼先ごとに確かめます。

費用と依頼先の運用まで含めた比較

Docker Swarmの導入提案は、初期額だけでなく継続費用と運用の引き継ぎまで比べて選びます。

初期費用：PoCは50万〜150万円、小規模本番は200万〜500万円、業務システムは500万〜1,500万円程度が目安です。
総保有コスト：クラウド料金に監視、バックアップ、復元試験、脆弱性・障害対応を加えて判断します。
継続性：責任分界を明確にし、将来の引き継ぎや基盤移行に対応できる提案を選びます。

▼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を創業。