Docker Swarmの開発会社は、Dockerを扱えるかに加え、要件整理から基盤、データ、監視、障害復旧、将来の移行まで説明できるかで選びます。
- Docker Swarmとコンテナ基盤、永続データの設計
- 監視、障害復旧、セキュリティ、将来移行への対応
- 業務要件、運用体制、発注前に確認する事項
取り上げるのは、開発会社、商用管理ツール、基盤提供者、クラウド、SIerの6社です。各社の特徴、向いている企業、依頼前の確認事項、費用の考え方も紹介します。
▼全体ガイドの記事
・Docker Swarmのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Docker Swarmのシステム開発でパートナー選びが重要な理由
Docker Swarmは、Docker Engineに組み込まれたクラスタ管理機能です。複数のDocker Engineをswarmとしてまとめ、サービスの望ましい状態、レプリカ数、配置条件、更新方法などを宣言的に管理できます。
さらに、Docker公式も、Swarm modeを本番の実行環境として使う場合の機能として案内しています（出典: Docker Docs「Swarm mode」、2026年8月確認）。
適切なパートナー選定が成否を分ける理由
Docker Swarmを導入すると、WebやAPIのコンテナを複数ノードに分散し、障害時に別ノードへ再配置できます。しかし、コンテナが動くことと、業務システムを安全に継続運用できることは別問題です。managerはクラスタ全体の状態を保持するため、可用性を求める本番環境では3台または5台の奇数構成が候補になります。
データベースやファイル、バッチの扱いを決めずに移行すると、ノード障害のあとにデータが読めない、処理が二重に実行される、アップロードファイルが見えないといった問題が起きます。セッションや外部連携の扱いも、移行前に決めておく必要があります。
Docker公式によると、3台のmanagerは1台、5台のmanagerは2台までの同時損失に耐えられますが、managerを増やしても性能が単純に上がるわけではありません（出典: Docker Docs「How nodes work」、2026年8月確認）。manager数の判断を、業務の許容停止時間や予算と結び付けられる会社が必要です。
発注前に確認すべきポイント
発注前には、Docker Swarmを使う理由と、使わない場合の代替案を整理しておきます。既存のDocker Composeを本番へ広げるのか、最初から複数サービスの業務システムを作るのかで、必要な工数は大きく異なります。
RTOとRPO、許容停止時間、同時アクセス数を先に言葉にすると、会社ごとの提案を比較しやすくなります。個人情報の有無、監査ログ、バックアップ保持期間も伝えておくと、提案の差が見えてきます。
納品物にはDockerfile、stack定義、IaCを含むかを確かめ、監視設定、バックアップ手順、障害対応手順、ソースコード、設計書の扱いも決めておきます。Swarmの初期構築だけを安く見せ、運用設計や復旧訓練を別料金にする提案もあり得ます。初期費用、月額インフラ費、年間保守費を分けて見積もることが、発注後の予算差異を抑えるポイントです。
株式会社ripla｜コンサルから開発まで一気通貫で支援
株式会社riplaは、コンサルティングから開発までを一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出と、システムの定着支援に強みがあります。
営業、顧客、生産、販売管理など、幅広い基幹システムの構築・導入実績があります。加えて、企業の業務要件に合わせて柔軟に対応できる体制を整えています。
特徴と強み
riplaの強みは、基盤の導入そのものではなく、業務の成果から逆算してシステムを設計できる点です。Docker Swarmを採用する場合も、まず業務フローと利用者、データの流れを整理します。そのうえで、Web・API・バッチなどのステートレスなサービスと、データベース・ファイルなどのステートフルなデータを分けて考えます。
業務側の担当者と開発側の認識をそろえながら、必要な範囲でコンテナ化を進められます。Swarmの導入が目的化しないため、Kubernetesやマネージドサービスを含めた比較も行いやすくなります。
既存の手作業やExcel運用は、そのまま移すのではなく、どこを標準化し、どこを個別対応するかを検討して進められます。さらに、導入後の定着まで見据えて、利用者教育や運用ルールを設計しやすい点も、業務システムを初めてコンテナ化する企業に適しています。
得意領域・実績と依頼前の確認事項
営業、顧客、生産、販売管理など、複数部門をまたぐ基幹システムの構築や導入を相談したい企業に向いています。Docker Swarmの公開案件があるかだけで判断せず、managerとworkerの構成、データベースの配置、外部ストレージ、監視・バックアップを提案書に含められるかを確かめてください。ローリング更新とロールバックの試験も、同じ提案書に入るかを見てください。
既存業務の理解が必要な会社では、要件定義の成果物と、発注者側が準備するマスタやデータ移行の範囲を、先に明確にしておきます。また、PoCから小規模本番へ段階的に進めたい場合は、1サービスを移行して障害・復元・更新を試す計画にすると、技術と業務の両面を評価できます。
Mirantis｜Docker系の商用管理とサポートを重視する企業向け
Mirantisは、Docker Enterpriseの系譜を持つコンテナ基盤ベンダーです。公式ドキュメントにはSwarm-only modeの説明があり、Kubernetesを使わない構成を選べる考え方が示されています。
Docker Swarmの運用を自社で抱えず、商用の管理レイヤー、権限管理、クラスタ運用、サポートを組み合わせたい企業にとって、比較しやすい候補です。
特徴と強み
商用サポートの契約先を明確にし、複数クラスタの管理や企業向けのアクセス制御を重視する場合にメリットがあります。また、自社の運用担当者が少なく、障害時に製品ベンダーへ問い合わせる窓口が必要な企業にも適しています。
一方で、Swarm-only modeの旧バージョン資料にはメンテナンス終了の注記もあります。そのため、記事掲載時点の現行製品でSwarmがどこまでサポートされるかを、必ず確認してください（出典: Mirantis Docs「Deploy Swarm-only mode」、2026年8月確認）。
得意領域・実績と依頼前の確認事項
製品のライフサイクル、対応するDocker Engineのバージョン、バックアップと復元、サポート時間、障害時のエスカレーションを確認することが重要です。
MKEや周辺製品を導入する場合でも、業務アプリの改修、DB移行、監視設計を誰が担当するのかは、別途決める必要があります。見積もりでは、ライセンス費用に加えて、クラスタ構築、既存Composeからの移行、ユーザー・ロール設計、脆弱性対応、運用教育を分けてもらいます。
将来Kubernetesへ移行する可能性がある企業は、MKEの現行サポート方針と、stack定義やコンテナイメージを他の基盤へ持ち出せる範囲も確認してください。
Portainer｜UI・RBAC・レジストリ管理で運用を標準化
Portainerは、Docker、Docker Swarm、Kubernetes、Podmanなどのコンテナ環境を、Web UIで管理するベンダーです。公式ドキュメントでは、Business Editionの機能として、Role-Based Access Control、レジストリ管理、専用サポートを案内しています。
CLIの操作に加えて、複数チームの権限やデプロイ操作を画面で統一したい場合に、検討しやすい会社です。
特徴と強み
現場の開発者が毎回SSHでサービスを操作する運用を減らし、チーム単位で見られる環境や操作権限を整えたい企業に向いています。Docker SwarmとKubernetesを併用する組織では、管理画面と権限モデルを共通化する選択肢になります。
公式の導入事例には、SwarmとKubernetesをまたぐ環境で、15％の開発者生産性向上、170万ドルの開発者コスト削減、99.99％の稼働目標を掲げた企業の例があります。ただし、これは個別事例の成果であり、そのまま自社へ適用できる数字ではありません（出典: Portainer公式Case Study、2026年8月確認）。
得意領域・実績と依頼前の確認事項
Portainerを選ぶときは、画面を入れるだけで終わらせず、誰がどの環境へどの操作を行えるかを設計します。そのうえで、開発・ステージング・本番の分離と、レジストリの認証を確認してください。さらに、イメージの承認フロー、監査ログ、緊急時のCLI利用も確認します。
また、Portainerは業務アプリケーションの要件定義やデータ移行を代わりに担うものではありません。そのため、UIを使う範囲、製品ライセンス、導入支援、24時間対応、Docker Engine自体の更新責任を分けて見積もれるパートナーを選ぶことが大切です。
Amazon Web Services（AWS）｜VM上に柔軟な自己管理基盤を構築
Amazon Web Services（AWS）は、Docker Swarmのマネージドサービスを提供する会社ではありません。一方で、EC2やLightsailなどの仮想マシン上に自己管理クラスタを構築できるため、インフラの候補になります。
VPCやセキュリティグループ、ロードバランサーを組み合わせられます。バックアップ、監視、IAMも加えることで、検証環境から本番環境まで段階的に拡張できます。
特徴と強み
公開料金をもとに初期予算を立てやすい点が、AWSの特徴です。LightsailのLinux/Unix仮想サーバーは、2026年8月確認時点で0.5GBが月額5ドル、2GBが12ドル、4GBが24ドル、8GBが44ドルです。
Lightsailロードバランサーは月額18ドルと案内されています（出典: AWS「Amazon Lightsail Pricing」「Lightsail load balancer」、2026年8月確認）。
たとえば、3台のmanagerと2台のworkerを4GB相当で用意する机上計算では、仮想サーバーだけで月額120ドルです。ロードバランサーを加えれば月額138ドルになりますが、これはバックアップ、監視、レジストリ、ストレージ、データ転送、運用人件費を含まないため、実際のTCOとは異なります。安いサーバー料金だけで比較しないことが重要です。
得意領域・実績と依頼前の確認事項
AWSを使う場合は、どこまでを誰が担うかを、RFPで明確にします。対象は、クラウドのアカウント、ネットワーク、ノード、コンテナ基盤です。EC2で高い自由度を取るのか、Lightsailで小さく始めるのか、データベースをRDSなどのマネージドサービスに分離するのかで、設計と費用が変わります。
依頼先には、マルチAZ配置、manager quorum、ノード障害、バックアップ復元を含む見積もりを求めます。IAMの最小権限、ログ保存、証明書更新、データ転送費も、同じ見積もりに含めてもらいます。AWSの設定作業とアプリケーションの改修を同じ会社に任せる場合は、障害時にどこまで一次対応するかも確認してください。
株式会社NTTデータ｜大規模業務とハイブリッドクラウドの設計を重視
株式会社NTTデータは、公共、金融、製造、通信などの大規模業務システムを扱うSIerです。
公式のクラウドサービスページでは、既存環境の調査、クラウド移行のFit & Gap整理、インフラ構築、システム開発、運用までを支援する、ハイブリッドクラウドの考え方が説明されています。
Docker Swarmを指定する場合は、コンテナ基盤に加えて業務全体の信頼性を重視する企業が比較しやすい候補です。
特徴と強み
複数の業務部門、厳格なセキュリティ要件、既存オンプレミスとの接続、長期保守をまとめて検討したい企業に向いています。
クラウドを借りるだけでなく、SLA、運用体制、データの所在、移行ロードマップまで含めて設計したい場合に、総合的な提案を受けやすい会社です。
得意領域・実績と依頼前の確認事項
NTTデータへ相談する場合は、Docker Swarmの実装担当部署、対応するEngineやクラウドのバージョン、構築後の運用窓口を確認します。公開情報がクラウド全般の実績を示していても、Swarmの案件実績を意味するとは限りません。
Swarmを採用する理由と、Kubernetesやマネージドコンテナサービスを採用しない理由を、技術面と費用面の両方で説明できるかを見ます。また、大規模案件では、要件定義、基本設計、詳細設計、移行、受入試験、運用引き継ぎの各成果物を分けて見積もります。
24時間365日の監視が必要な場合は、一次対応と二次対応、Dockerやクラウドの製品問い合わせの責任を明記しておくと、障害時の連絡が滞りにくくなります。
SCSK株式会社｜開発・基盤・運用をつないで長期利用を支援
SCSK株式会社は、システム開発、ITインフラ構築、保守運用を幅広く扱うSIerです。
公式には、クラウドネイティブを、開発や運用を柔軟かつ迅速にするアプローチと位置付けています。インフラ基盤からアプリケーション、運用までが対象です。
Docker Swarmの専業ベンダーではありません。ただし、業務システムのライフサイクル全体を見て比較したい企業には、適した候補です。
特徴と強み
アプリケーション開発とインフラ運用を別会社に分けず、運用状況の把握、監視、障害対応、継続的な改善まで考えたい場合に、相談しやすい会社です。
SCSKの公式発信では、開発・運用プラットフォームの統一や、運用管理システムを用いたマネージドサービスの考え方が示されています。さらに、コンテナ導入後の担当者不足を懸念する企業にとって、運用体制を含めて比較できる点が強みです。
得意領域・実績と依頼前の確認事項
SCSKへ依頼する場合は、Swarmの構築担当とアプリ担当、運用担当の役割を確認します。開発と保守の契約が別なら、Docker Engineの更新、コンテナイメージの脆弱性対応、証明書更新、バックアップ復元テストを、どの契約に含めるかを決めておきます。
特に業務システムでは、どの指標を見たいかを具体的に決めます。サービスのreplica数、コンテナ再起動、ノードのディスク、overlay networkを監視対象にします。外形監視、DBの接続数、バックアップの成否も含めたうえで、通知を受けた後の対応時間まで合意します。
SCSKが持つ一般的なクラウドネイティブや運用の知見を、Swarm固有の設計へ落とし込めるかを確認することが大切です。
Docker Swarmのシステム開発会社・ベンダー選びのポイント
取り上げた6社は、同じ種類の会社ではありません。riplaやSIerは業務要件から開発・運用を相談する相手で、MirantisやPortainerはコンテナ基盤の管理・運用を補強する相手です。Dockerは標準技術の基準にあたり、AWSは実行基盤を提供する相手です。
役割を分けて比較すると、どこまでを一社に任せ、どこからを自社で担うかが明確になります。
実績と経験の確認方法
実績を確認するときは、「Dockerの導入実績があります」という説明だけで受け取らないようにします。Docker Engine内蔵のSwarm modeを使ったのか、Classic Swarmや単一ホストのComposeなのか、業務アプリを何サービス動かしたのかを聞きます。
可能なら、匿名化した構成図、managerとworkerの台数、DBの配置を提示してもらいます。加えて、障害訓練、保守期間、引き継ぎ方法も、できれば示してもらいます。
技術力と専門性の評価
技術面では、コンテナを起動できることより、失敗したときの設計を重視します。たとえば、SecretsにパスワードやTLS鍵を埋め込まず、サービスごとに必要な情報だけを渡せるか、イメージをダイジェストで固定できるか、registry停止時にどう復旧するかを確認します。
DockerのSecretsは、ソースコードやDockerfileへ機密情報を置かず、サービス単位で扱うための機能です。また、DBやファイルをhost bind mountだけに置く提案は、ノードが変わったときの復旧方法を確認します。
DB専用ノード、マネージドDB、共有ストレージ、バックアップからの復元を比較し、RTO・RPOを満たすかを検証します。なお、大規模なマルチテナントや複雑なPolicy、周辺製品の豊富さが必要なら、Kubernetesも比較対象に含められる会社を選ぶと安心です。
プロジェクト管理体制の確認
管理体制では、要件定義の責任者、技術設計者、アプリ担当、インフラ担当、運用窓口を確認します。非機能要件を後回しにすると、性能、監視、バックアップ、セキュリティの追加対応が後半に集中し、仕様変更と費用増加につながります。
そのため、要件定義書に同時接続数、許容停止時間、データ分類、監査ログ、保守時間を入れてもらいます。費用の目安は、学習・PoCなら50万〜150万円、小規模本番なら200万〜500万円です。認証・DB連携・バッチ・外部連携を含む業務システムなら500万〜1,500万円、高可用性や厳格な監査対応まで含めると1,500万〜5,000万円以上で、いずれも見積もりのたたき台です。
これはDocker Swarm専用の公定価格ではなく、要件やデータ移行量で変わる推定レンジです。年間保守は初期開発費の15〜20％程度を目安にしつつ、対応時間と範囲を確認してください。
Docker Swarmのシステム開発に関するよくある質問
Docker Swarmの会社選びでは、導入の可否だけでなく、運用と将来性も確かめる必要があります。発注前によく寄せられる疑問に、順に答えます。
2026年もDocker Swarmを採用して問題ありませんか？
小規模から中規模のWeb・APIや社内業務システムで、Dockerとの連続性と運用の分かりやすさを重視するなら、採用候補になります。ただし、将来の人材確保、監視製品、サポート範囲、Kubernetesへ移行する境界を先に確認し、PoCで障害・復元・更新を試してから本番を判断することが大切です。
Docker Swarmのシステム開発費用はいくらですか？
PoCは50万〜150万円、小規模本番は200万〜500万円、認証・DB・バッチ・外部連携を含む業務システムは500万〜1,500万円以上が、一つの目安です。
インフラ料金だけでなく、要件定義やアプリ改修、データ移行を含めて比べてください。監視、バックアップ、復元試験、運用教育、保守も同じ見積もりに入れると、会社ごとの差が見えます。要件が固まる前の数字は、正式見積もりではなくたたき台です。
DBをDocker Swarm上で動かしてもデータは失われませんか？
Docker Swarmに配置しただけで、DBのデータが自動的に安全になるわけではありません。そのため、DB専用ノード、マネージドDB、共有ストレージ、バックアップと復元試験を組み合わせ、コンテナが別ノードへ移動してもデータを参照できる構成を設計します。
RTO、RPO、バックアップ保持期間、復元手順を受入条件に入れてください。
開発会社には何を質問すればよいですか？
まず、「Swarm modeとClassic Swarmのどちらを扱うか」「managerは何台か」「DBとファイルをどこへ置くか」「障害時のRTO・RPOは何か」を聞いてください。さらに、「Secrets、registry、監視、バックアップを誰が運用するか」「納品物は何か」「Kubernetes移行や他社引き継ぎに対応できるか」も確認します。
過去の案件では、構成図と障害対応の手順を見せてもらうと、実務経験の違いが見えてきます。
まとめ
Docker Swarmのシステム開発では、「Swarmを使える会社」を探すだけでは不十分です。
株式会社riplaをはじめ、Mirantis、Portainer、AWS、NTTデータ、SCSKは、それぞれ業務開発、管理ツール、クラウド、SI・運用という異なる役割を持っています。そのため、自社の課題がどの役割に当たるのかを整理してから、相談先を選ぶことが大切です。
最初に決める項目
最初に、業務フロー、データ分類、同時アクセス数を整理します。さらに、許容停止時間、RTO・RPO、監査要件も整理します。そのうえで、ステートレスなWeb・API・バッチと、DB・ファイルなどのステートフルなデータを分け、3 manager＋workerの本番候補を検討します。
小規模なPoCでローリング更新、ロールバック、ノード停止、バックアップ復元を確認すると、採用判断の精度が上がります。
見積もりと会社比較の進め方
見積もりは、初期構築費、クラウド費、商用ライセンス、データ移行費を分けて取得します。監視・バックアップ、運用教育、年間保守も、別々の項目として出してもらいます。
会社ごとに、担当範囲、実際のSwarm経験、成果物、障害対応、将来のKubernetes移行を同じ質問で比較してください。また、Docker 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を創業。