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

Docker Swarmのシステムとは、Dockerコンテナで構成した業務アプリケーションを複数ホストへ配置し、サービスの台数・通信・更新・障害復旧を一元管理する運用基盤です。

本記事では、Docker Swarm modeの基本から、業務システムに採用する判断基準、構成要素、開発の進め方、費用相場、セキュリティ、開発会社やベンダーの選び方まで、2026年時点で検討したいポイントを体系的に解説します。

Docker Swarmのシステムとは何ですか？全体像を解説します

Docker Swarmのシステムは、業務アプリケーションそのものではなく、複数のDocker Engineをクラスタとして束ねて、コンテナ化したサービスを本番運用するための基盤です。Docker Engineに組み込まれたSwarm modeを使うため、別のオーケストレーターを追加しなくても、サービスの配置や台数を宣言的に管理できます。Docker公式ドキュメントでは、Swarm modeを本番ランタイムとして利用する場合の機能として、クラスタ管理、サービスディスカバリ、内部ロードバランシング、ローリング更新などが説明されています（出典：Docker公式ドキュメント「Swarm mode」、2026年8月確認）。

Swarm modeと旧Docker Classic Swarmは別物です

現在、業務システムの検討対象として整理すべきなのはDocker Engineに内蔵されたSwarm modeです。過去にはDocker Classic Swarmという別の仕組みもありましたが、Docker公式ドキュメントでは積極的に開発されていないものとして区別されています。そのため、提案書やRFPでは「Docker Swarm」とだけ書かず、「Docker EngineのSwarm mode」と明記すると、対象技術の認識違いを防げます。

managerノードとworkerノードが役割を分担します

クラスタを構成するサーバーはノードと呼ばれ、全体の状態を管理して配置を決めるmanagerと、実際にコンテナを動かすworkerに分かれます。managerは「Webサービスを3つ稼働させる」「メモリを一定量までに制限する」といった望ましい状態を保持し、実際の状態との差分を検知すると、空いているノードへタスクを再配置します。workerに障害が発生した場合も、利用可能なノードがあれば指定したレプリカ数へ戻す動きが期待できます。

構成の種類は検証・小規模本番・高可用性の3パターンです

Docker Swarmの構成は、目的に応じて大きく3種類に分けて考えると整理しやすいです。1つ目は1〜2台で動作を確認する学習・PoC型、2つ目は3〜5台でWebやAPIを運用する小規模本番型、3つ目はmanagerを3台または5台にし、複数環境、監視、バックアップ、障害訓練まで組み込む高可用性型です。PoC型の構成をそのまま本番へ拡張できるとは限らないため、どの種類を作るのかを見積もりの前提に書きます。

Compose環境を複数台の本番構成へ広げます

開発者が使うDocker Composeは、1台の開発環境で複数コンテナをまとめて起動するのに向いています。一方、Swarm modeでは、複数ホスト上のサービスをクラスタ単位で配置し、ネットワークや更新方法まで管理できます。Composeファイルをそのまま本番へ持っていけば終わりではなく、イメージのレジストリ、healthcheck、Secrets、永続ボリューム、リソース制限、更新・ロールバック方針を追加で設計する必要があります。

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

Docker Swarmを採用する価値は、コンテナを起動できることではなく、複数台運用で必要になる配置、通信、更新、障害時の復旧をひとつの運用モデルにまとめられることです。特に、WebやAPI、管理画面、バッチ、キュー処理など、同じイメージを複数起動しやすいサービスと相性がよいです。反対に、データベースを単純に複製すれば可用性が上がるわけではないため、状態を持つサービスは別の設計として扱います。

Web・API・バッチなどのステートレスなサービスに向いています

ステートレスなサービスとは、どのコンテナで処理しても、外部に保存したデータを使って同じ結果を返せるサービスです。たとえば、商品検索API、社内ポータルのWeb画面、帳票生成のワーカーなどは、イメージを同じに保ち、セッションやファイルを外部の共有先へ移せば、複数レプリカで動かしやすくなります。ノードの入れ替えやローリング更新がしやすくなるため、平日日中に停止しにくい業務システムで効果を発揮します。

レプリカ数の変更とローリング更新ができます

アクセスが集中する時間帯だけWebサービスのレプリカ数を増やしたり、処理量に応じてバッチの並列数を調整したりできます。更新時は、同時に入れ替えるタスク数や待ち時間を設定し、段階的に新しいイメージへ切り替えます。新バージョンでhealthcheckが失敗した場合に更新を一時停止し、原因を確認してから前のバージョンへ戻す運用も可能です。更新の速さだけでなく、失敗時に戻れることを受入条件へ含めることが重要です。

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

Docker Swarmは、少人数のチームがDockerの知識を活かして複数台運用へ進みたい場合に、候補になりやすい基盤です。クラスタの台数、サービス定義、ネットワーク、更新を同じCLIと設定ファイルで扱えるため、導入教育や運用手順を比較的整理しやすいからです。ただし、将来的に多数のチームが同じ基盤を共有する、細かなポリシー制御が必要になる、周辺エコシステムを広く利用する、といった要件がある場合は、Kubernetesも早い段階から比較します。「簡単そうだから」ではなく、必要な運用機能を満たすかで判断します。

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

本番構成を考えるときは、アプリケーション、クラスタ管理、公開経路、データ保存、開発・運用の仕組みを分けて設計します。Docker Swarmを導入しても、データベースやバックアップの責任が自動的に解決するわけではありません。最初から「どこでコンテナを動かすか」だけでなく、「どのデータを、何分以内に、どの状態まで復旧するか」を中心に構成を決めます。

最低限そろえる7つの構成要素

基本構成は、クラスタ全体を管理する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設定まで範囲を明記します。

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

Docker Swarm自体のライセンス料金だけで開発費を判断することはできません。要件定義、既存アプリの改修、クラスタ構築、ネットワーク、監視、バックアップ、データ移行、試験、運用教育が費用を構成します。以下は日本向けの標準価格表ではなく、業務システムの規模とコンテナ基盤の工数から作った見積もりのたたき台です。データ量、SLA、既存環境、セキュリティ要件によって大きく変わるため、実際の発注では内訳を確認します。

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

初期費用はPoCで50万〜150万円、本番で200万円以上が目安です

学習・PoCであれば、1〜2台の非本番環境へ既存Composeを移し、イメージ化と基本デプロイを確認する範囲で50万〜150万円程度がひとつの目安です。3〜5台の小規模本番で、manager・worker、レジストリ、TLS、CI/CD、監視、バックアップ、リリース手順まで含めると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台を2GB相当にすると月60米ドル、3台のmanagerと2台のworkerを4GB相当でそろえると月120米ドルです。円換算は為替で変わり、実際にはロードバランサー、固定IP、バックアップ、監視、レジストリ、ストレージ、データ転送、サポート、運用人件費が加わります。

したがって、見積書では「クラウド利用料」と「構築・保守費」を分けて表示します。検証環境を夜間停止できるか、ログの保存期間を何日にするか、バックアップ世代をいくつ持つかでも月額は変わります。安いインスタンスを選ぶことより、RTO・RPOを守るために必要な構成を先に決めることが大切です。

年間保守費は初期開発費の15〜20％を起点に考えます

年間保守は、初期開発費の15〜20％程度をひとつの目安にできます。対象には、Docker Engineやベースイメージの更新、脆弱性対応、証明書更新、ログ容量の監視、ノード追加、バックアップ確認、復元テスト、障害一次対応、手順書の更新を含めます。24時間365日の監視や短時間の復旧を求める場合は、待機体制と対応時間を別途定義する必要があります。保守費を安く見せるために監視や復元テストを外すと、障害時の復旧費用が別に発生します。

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

コンテナを使うだけで安全になるわけではありません。ノードの認証、イメージの信頼性、秘密情報、ネットワーク公開範囲、権限、ログ、バックアップ、脆弱性対応を運用に組み込みます。個人情報を扱う業務システムでは、技術設定だけでなく、アクセス権限の承認、委託先との責任分担、点検と改善の記録まで必要です。

Secretsと最小権限で認証情報を守ります

DBパスワード、TLS秘密鍵、SSH鍵などをDockerfile、ソースコード、公開設定ファイルへ書き込まないでください。Swarm secretsを使うと、許可したサービスだけへ実行時に秘密情報を渡せます。Docker公式ドキュメントでは、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台で起動した、画面が表示された、という確認だけでは本番運用に必要な条件を満たしません。代表的な失敗は、managerを1台だけにして可用性を誤認する、DBをレプリカ数だけ増やして整合性を壊す、イメージタグを固定しない、秘密情報を環境変数へ直接渡す、監視はあるが復元試験をしていない、障害時の担当者が決まっていない、といったものです。PoCでは「ノード停止」「DB復元」「更新失敗」「アクセス権限の確認」を必ず実施し、本番の判断材料にします。

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

依頼先を選ぶときは、「Docker Swarmを構築できるか」だけでなく、業務要件、データ移行、セキュリティ、監視、障害復旧、将来の移行まで説明できるかを確認します。公開事例の数だけでは実際の担当者の経験や保守範囲が分からないため、提案段階で構成図と障害対応の考え方を確認し、複数の見積もりを同じ条件で比較します。

経験だけでなく担当範囲と成果物を確認します

ヒアリングでは、過去に担当したクラスタの規模、managerとworkerの台数、ステートフルなサービスの扱い、採用したバックアップ方式、障害訓練の内容を質問します。回答が「構築して終わり」ではなく、要件定義、設計、移行、監視、保守、引き継ぎのどこまで含むのかを明確にします。納品物として、IaC、stack定義、Dockerfile、CI/CD設定、監視設定、構成図、試験成績書、運用手順、ソースコードを受け取れるかも確認します。

見積もりは人日・環境数・保守時間の内訳で比較します

一式見積もりだけでは、どこを削った結果の価格なのか判断できません。要件定義、PoC、アプリ改修、クラスタ構築、ネットワーク、セキュリティ、データ移行、試験、教育、保守を分け、環境数と人日、単価、前提条件を記載してもらいます。特に、バックアップや監視、脆弱性対応、夜間障害の扱いが「対象外」になっていないかを確認します。安価な提案ほど、対象外の作業と追加単価を先に見ることが大切です。

将来の引き継ぎとKubernetes移行の説明を求めます

2026年時点でSwarmを採用する場合は、数年後も同じ基盤を使うのか、別のオーケストレーターへ移行する可能性があるのかを先に話し合います。Composeやstack定義を標準的に保ち、アプリと基盤の責任を分け、データ移行手順を文書化しておけば、将来の選択肢を残せます。依頼先には、移行を前提にした設計の考え方、移行時に作り直す部分、引き継ぎ後に自社で変更できる範囲を具体的に説明してもらいます。

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

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

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クラスタの構築が必要だと説明されています。

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

まず1つのステートレスなサービスをコンテナ化し、registryから取得して複数ノードへデプロイします。そのうえで、ローリング更新、更新失敗からのロールバック、worker停止時の再配置、Secretsの権限、ログと監視、バックアップからの復元を確認します。PoCの目的を「起動できた」ではなく「障害時に決めた時間内で復旧できた」と定義すると、本番移行の判断がしやすくなります。

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

Docker Swarmのシステムは、Dockerコンテナで構成した業務アプリケーションを、複数ホスト上で安定して運用するための選択肢です。managerとworkerの役割分担、サービスのレプリカ管理、overlay network、サービスディスカバリ、ローリング更新、ロールバックを活用できます。特に、Web・API・バッチなどのステートレスなサービスを中心とする中小規模の業務システムでは、既存のDocker知識から段階的に本番運用へ進めやすい点がメリットです。

最初にPoCで障害復旧とデータ保護を試します

採用を決める前に、1サービスの小さなPoCから始め、要件・費用・運用体制を確認します。3または5台のmanager構成、DBとファイルの永続化、Secrets、監視、バックアップ、ノード障害、更新とロールバックを検証し、結果を本番設計へ反映します。開発会社やベンダーへ依頼する場合は、初期構築費だけでなく、保守、復元訓練、納品物、責任分界、将来の引き継ぎまで比較してください。

費用と依頼先は運用まで含めて比較します

費用相場は、PoCなら50万〜150万円、小規模本番なら200万〜500万円、業務システムなら500万〜1,500万円程度を出発点にできます。ただし、クラウド料金だけでなく、監視、バックアップ、復元試験、脆弱性対応、障害対応を含めた総保有コストで判断します。設計と運用の責任分界を明確にし、将来の引き継ぎや基盤移行にも対応できる提案を選ぶことが、長期的な失敗を防ぎます。