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

Dockerのシステム開発は、業務要件の整理とPoCでの検証から始めます。契約と委託先の選定を経て、移行と運用確認へ進みます。この順で進めると、過剰な構成を避けやすくなります。

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

Dockerのシステム開発を外注する前に知るべき全体像

Dockerではアプリをコンテナイメージにまとめ、レジストリに保管して各環境へ配布します。発注時は技術を指定するだけでなく、改善したい業務や可用性、セキュリティの水準まで決めておきます。

Dockerは業務システムではなく実行・開発基盤

Dockerは、業務システムそのものではなく、実行と開発の基盤です。基本要素は、役割を分けて把握しておきます。

  • Docker Engine:イメージからコンテナを起動する実行基盤。
  • Dockerfile:アプリ、ランタイム、ライブラリの構成を定めたファイル。
  • Compose:Web、API、DB、キャッシュなど複数コンテナをYAMLで定義し、開発環境や小規模な検証環境をまとめて起動する仕組み。

業務画面、帳票、権限、外部連携を作るアプリ開発費と、Docker基盤の設計費は、分けて見積もります。さらに、本番ではデータをコンテナ内に置かず、マネージドDBや専用ストレージへ分離する構成が一般的です。

業務で使えるシステムにするには、WAFやロードバランサー、ログ・メトリクス監視を含めて考えます。また、バックアップ、秘密情報管理、障害時の切り戻しも対象に入ります。

採用目的の業務成果と運用条件への置き換え

Dockerを採用する目的には、次のようなものがあります。

  • 環境差異を減らす
  • 再現可能なリリースにする
  • 移行先インフラを柔軟にする

Dockerを導入しただけで、開発費やクラウド費が自動的に下がるわけではありません。停止許容時間、同時利用者数、個人情報の有無、監査ログの保存期間、既存データの移行方法は、RFPに整理して記載します。

たとえば「月末に経理担当者が同時に使っても5秒以内に検索できる」のように、業務条件を具体化します。「障害から30分以内に復旧する」「退職者の権限を当日中に停止する」といった条件は、必要な設計や試験の中身を明らかにします。

Dockerを目的とせず、決めた業務条件を実現する選択肢として評価することが、発注を成功させる出発点です。

Dockerのシステム開発の発注形態の選び方

発注形態は、要件の確定度と社内IT人材に加え、スピードや運用責任も考えて選びます。完成品、個別開発、技術者支援のどれを選ぶかで、費用の発生方法と発注者の負担が変わります。

パッケージ・クラウドサービスの利用

業務の標準化度に応じて、採用する範囲を選びます。

  • 標準化しやすい業務:SaaSやパッケージを使い、Dockerは連携サービスや社内ポータルに限ります。
  • 標準機能で業務の八割を満たせる場合:独自開発の範囲を絞ることで、導入期間と初期費用を抑えられます。

パッケージを大幅に改修してコンテナ化する場合は、ライセンス条件とメーカーのサポート範囲を確認します。

新しい業務Webシステムでは、Dockerイメージをプライベートレジストリに置き、Amazon ECSやGoogle Kubernetes Engineなどへ配布する構成が候補になります。

AWS公式の料金説明によると、ECSのオーケストレーション自体には追加料金がなく、選んだコンピュート、ストレージ、ネットワークなどの利用分が課金されます(出典: AWS「Amazon ECS Pricing」、2026年8月確認)。あわせて、実行基盤と周辺サービスも見積もります。

請負・準委任・ラボ型開発の使い分け

請負契約は、成果物の完成と納品を重視します。画面、API、データ移行、コンテナ定義などの要件が固まり、受入条件を明確にできる案件に適しています。

開発中に業務要件を頻繁に変えると、追加費用や納期変更の協議が生じるおそれがあります。そのため、準委任契約は、専門家の稼働と業務遂行を委託する形で、調査、コンテナ化診断、設計、運用改善など変動しやすい工程に適しています。

ラボ型開発は、一定期間チームを確保し、優先順位を調整しながら進める形です。社内の意思決定者が毎週参加でき、継続して仕様を決められる場合に効果を発揮します。

PoCだけを外注する進め方

本番採用を判断できない場合は、全社移行ではなく、1業務または1サービスの技術検証を外注します。技術検証では、Dockerfile、Compose、CIの試作を行います。加えて、性能と脆弱性を確認するとともに、ログとバックアップ復元も見ます。

技術検証やDocker化PoCは100万〜300万円、期間は1〜2か月が概算の目安です。対象サービス数や既存コードの状態で変わるため、固定価格とは限りません。

契約には、成功条件と本番化の判断基準を記載します。成果には、起動だけでなく、指定した処理量での動作や再デプロイ、合意した脆弱性水準を含めます。さらに、別の担当者が手順書どおりに復旧できることも加えます。

ポイント

要件の確定度と社内IT人材の有無で、パッケージ、請負、準委任、ラボ型開発のどれを選ぶかが決まります。標準機能で足りる業務は、独自開発の範囲を絞るのが目安です。

Dockerのシステム開発・移行・運用の進め方

要件定義から設計・テスト、データ移行、本番切り替え、運用引き継ぎまでを4枚のパネルで示した図。
現行環境の診断から順に進める工程が分かります。

技術の選定より先に、業務と非機能要件を整理します。そのうえで、現行調査、試作、設計、開発、移行、運用引き継ぎの順に進めます。

既存システムでは、古いOSや固定ファイルパスなどへの依存を早い段階で見つけることが、納期と費用を守ることにつながります。

要件定義と現行環境の診断

要件定義では、業務面と現行環境の両方を確認します。

  • 業務の流れ:対象業務、利用者、業務フロー、画面、帳票、外部連携
  • 利用条件:データ量、利用時間帯、権限
  • 実行環境:OS、言語、フレームワーク、ミドルウェア
  • 既存資産:DB、ファイル共有、バッチ、ライセンスへの依存

コンテナ化で解決する課題と、Dockerでは解決しない課題を分けて記録します。加えて、可用性と性能、セキュリティの水準を決めておきます。監視やログ、災害対策、保守時間、障害時の連絡体制についても取り決めます。

復元の備えには、毎日のDBバックアップに加えて、復元目標時間、復元ポイント、実施担当、テスト頻度まで書いておくことが必要です。そうすると、ベンダーの見積範囲がそろいます。

Docker設計、アプリ開発、テストの確認範囲

Docker設計では、Dockerfileとベースイメージ、タグとダイジェストを決めます。さらに、レジストリ、ネットワーク、Volume、Secrets、実行先も決めます。

環境ごとの設定値を安全に切り替えられるか、機密情報をイメージに埋め込んでいないかも確認します。

実行基盤は、可用性や運用の複雑さに合わせて選びます。

  • Compose:小規模な単一ホストや検証
  • ECSなどのマネージド基盤:高可用性や自動スケール
  • Kubernetes:複雑なサービス運用

アプリ開発では、業務画面、API、認証、権限、帳票、外部連携を実装します。Docker設定が正しくても、業務ルールの認識がずれていれば業務では使えません。

受入テストでは、担当者が実データと業務手順で処理できるかを確認します。負荷と障害の試験は、別工程として見積もります。さらに、バックアップ復元と脆弱性スキャンの試験も対象に含めます。

データ移行、本番切り替え、運用引き継ぎ

移行・本番化では、次の作業を順に確認します。

  1. データ件数、欠損、重複、文字コード、日付形式、マスタの不整合を確認する。
  2. 移行リハーサルで所要時間とエラー件数を記録し、本番の切り替え手順と切り戻し条件を決める。

可用性が高く求められる業務では、段階リリースや並行稼働も候補になります。ただし、その分だけ検証費用と運用負担が増えます。

納品時には、ソースコードに加えて、再構築と運用に必要な次の成果物を受け取ります。

  • 構成とデプロイ:Dockerfile、Composeまたはオーケストレーターのマニフェスト、IaC、CI/CD
  • 環境と検証:環境変数一覧、監視設定、SBOM、テスト仕様書
  • 運用資料:障害対応手順、ライセンス一覧

担当者が退職しても再構築できることを引き継ぎ完了の条件にすれば、外注先を変更する際のリスクも抑えられます。

ポイント

既存システムの依存は早い段階で洗い出し、納期と費用の見通しを立てます。移行や本番化では、切り戻し条件と引き継ぎ完了の条件を事前に決めておくのが目安です。

RFPと契約形態の決め方

RFPに記載する業務目的、対象範囲、非機能要件、納品物を4枚のチェックカードで示した図。
共通の前提があると各社の提案を比べやすくなります。

RFPは、候補会社が同じ前提で提案と見積を出すための依頼書です。RFPでは技術用語よりも、業務目的、対象範囲、現状、希望時期、予算の考え方をそろえることが大切です。さらに、非機能要件、納品物、運用体制、提案期限も揃えます。

RFPに書くべき発注範囲と評価基準

RFPでは、業務の背景と課題、対象ユーザーと業務フローを明らかにします。加えて、必要機能、データ移行と外部連携、非機能要件も示します。権利と責任の分担も、あわせて定義します。

  • 成果物の管理:Dockerfileやイメージの所有権、レジストリの管理者、クラウドアカウントの名義
  • セキュリティ:脆弱性修正の責任と障害時の連絡先
  • 評価基準:要件理解、技術・移行、運用保守、体制、提案の具体性

たとえば、価格30点、提案内容25点、技術・移行20点、運用保守15点、体制10点のように、重みを先に決めておくと、最安値だけで選ぶ失敗を防ぎやすくなります。配点は、自社の優先順位に合わせて調整します。

契約書での成果物・変更・責任分界の定義

請負契約では、成果物と受入基準、検収期限を明確にします。さらに、保証範囲、瑕疵対応、仕様変更の手順も取り決めます。指定環境でのイメージ再現や脆弱性水準、監視と復旧手順は、受入条件にも含めます。

準委任では、月ごとの稼働時間と役割、定例会、成果報告を確認します。加えて、作業記録と秘密保持、再委託を取り決めます。さらに、知的財産と終了時の引き継ぎも確認します。

アプリの不具合、クラウド障害、イメージの脆弱性、利用者の誤操作ごとに、どこまでを誰が受け持つかを合意します。24時間監視や緊急対応は、通常保守とは別のSLAとして記載します。

納品物とアカウントの帰属の決め方

外注先の個人アカウントでAWSやレジストリを管理すると、契約終了時にアクセスできなくなるおそれがあります。

クラウドやソース管理、レジストリは、原則として発注者側の組織で契約・管理します。監視、ドメイン、証明書も、発注者側で持つことが基本です。

委託先には必要な権限だけを期間限定で付与し、退任時の無効化手順を設けます。

納品物には、ソースコードと次の設定・記録を含めます。

  • Dockerfile、Composeまたはマニフェスト、IaC、CI/CD
  • 環境構築手順、運用設計書、テスト結果、SBOM、ライセンス一覧
  • 障害対応手順、バックアップと復元の手順

将来の委託先が読めるように、バージョンと前提条件、秘密情報を置かない場所、更新責任も記載してもらいます。

ポイント

契約形態は要件の確定度で選び、成果物と責任分界、アカウントの帰属は契約前に決めておきます。これらが決まっていれば、契約終了後の移管にも備えられます。

Dockerのシステム開発を外注する費用相場

技術検証、小規模業務Web、既存システム移行、大規模基盤の初期費用レンジを4本の横棒で並べた図。
対象範囲が大きくなるほど費用レンジも広がります。

Docker開発には、公的な一律の料金表はありません。費用は、機能数と既存システム、データ移行の内容に、実行基盤、セキュリティ、保守時間を加えた合計で決まります。

2026年版の国内システム開発相場では、人月単価50万〜150万円程度が目安として紹介されています(出典: 秋霜堂株式会社「システム開発の費用相場」、2026年7月更新)。

会社の役割や専門性によって単価は変わるので、単価だけでは判断しません。

規模と対象範囲で分けた初期費用

初期費用と期間の概算レンジは、対象規模で異なります。

  • 技術検証・Docker化PoC:100万〜300万円、期間1〜2か月が目安です。
  • 小規模業務Web:300万〜800万円、期間3〜6か月が目安です。
  • 既存システムのコンテナ化・クラウド移行:500万〜1,500万円、期間4〜9か月が概算レンジです。
  • 大規模基盤:1,500万〜5,000万円以上になる場合もあります。

大規模基盤の費用は、複数サービス、高可用性、認証連携を含む場合の推定です。加えて、IaC、負荷試験、24時間運用を含めた場合の推定でもあります。

これは、業務システムの相場と、Docker化・移行・運用設計の工数を組み合わせた、提案前の金額です。確定額ではありません。

見積書は、作業ごとに分けてもらいます。要件定義、現行調査、アプリ開発、Docker基盤、クラウドなどの区分に加え、テストやリリース、文書、PMも分けます。「開発一式」では、脆弱性対応や切り戻し試験の有無が分かりません。

作業項目と人月、単価をそろえるとともに、前提と除外条件も明記してもらうことが欠かせません。

Dockerのライセンス費と開発費の切り分け

Docker公式料金(2026年8月確認)は次のとおりです(出典: Docker公式「Pricing」、2026年8月確認)。

  • Personal:無料
  • Pro:月払いは1ユーザー月額11米ドル、年払い表示は9米ドル
  • Business:1ユーザー月額24米ドル

Businessには、SSOやSCIMといった機能が含まれます。加えて、イメージとレジストリのアクセス管理や、強化されたコンテナ分離も含まれます。

1ドル150円と仮置きすると、Proは約1,350〜1,650円、Businessは約3,600円です。

為替や税、契約条件で変わるため、円換算の金額は固定値として扱いません。

この料金は主に開発者向けのサブスクリプションで、業務アプリ開発費とは別に払うものです。一方で、サーバー側では、レジストリ、実行環境、DB、ストレージ、ロードバランサーの費用が発生します。さらに、監視、ログ、バックアップ、通信の費用もかかります。

小規模本番のクラウド、監視、バックアップは月5万〜50万円、中規模の冗長構成は月50万〜300万円以上という推定レンジです。

リージョン、稼働時間、データ量、冗長化方式で変わるため、構成図に基づく個別見積が必要です。

保守費とランニングコスト

運用費にはサーバー利用料以外に、次の継続作業も含まれます。

  • 更新・脆弱性対応:イメージの再ビルド、OS・ライブラリ更新、脆弱性調査、証明書更新
  • 監視・保全:ログ保管、バックアップ確認、監視アラートの一次対応
  • 運用対応:障害復旧、軽微な改修

初期開発費の15〜20%を、年間保守費の目安とする考え方もあります。ただし、24時間対応や高いSLAは別途上乗せされるため、契約範囲を確認します。

Docker公式は、信頼できる最小ベースイメージを使い、依存関係のダイジェストを固定することを推奨しています。SBOMと署名付きのビルド証跡、CI/CDの権限分離、脆弱性分析、実行時監視も、これらと並ぶ推奨事項です(出典: Docker「Software Supply Chain Security Best Practices」、2026年6月)。

採用が進むほど、初期設計と運用の工数は増えます。その分は、重大な脆弱性や改ざんを見つけるために必要な費用として比較します。

ポイント

初期費用は対象規模で、保守費とランニング費は構成図で見積もるのが基本です。ライセンス料金だけで総額を判断せず、開発費と運用費を分けて比較します。

委託先選定と見積比較で確認すべきポイント

Dockerの知識だけで委託先を決めると、業務要件、データ移行、監視、契約終了後の引き継ぎが弱くなるおそれがあります。

Dockerfileを作れるかだけでなく、実行基盤、責任分担、納品物を具体的に説明してもらいます。

技術実績の構成・役割・運用の確認

実績を比べるときは、構成と運用の実態を確認します。

  • 規模・環境:サービス規模、クラウドまたはオンプレミス環境、運用期間
  • 構成:Web、API、DB、キャッシュ、レジストリ、CI/CD、監視、バックアップ
  • 運用実績:障害と脆弱性の対応担当。非公開案件は、匿名化した構成図や検証内容で確認します。

発注ナビの2026年版企業紹介では、AWS・Azure・GCP、Terraform、Ansible、Kubernetesなどを扱う企業を紹介しています。

業務Web、製造業、クラウド移行、PoCに強い実在企業も掲載されています。

掲載の情報は2026年版です(出典: 発注ナビ「Dockerの環境構築に強いシステム開発会社10社」、2026年版)。

公開情報は候補を絞るのに使えますが、掲載実績だけで最適と断定はできません。同じRFPで、直近の担当体制と見積を確認します。

同じ前提と粒度での見積比較

相見積もりは、前提と作業範囲を揃えて比較します。

  • 共通の前提:同じRFP、現行資料、データ件数、利用者数、希望時期
  • 費目の内訳:要件定義、設計、開発、インフラ、セキュリティ、テスト、移行、教育、保守
  • 見積範囲:含む項目と含まない項目

極端に安い見積では、要件定義や移行リハーサルが別料金になっていないかを確認します。監視や脆弱性対応、文書についても、別料金でないかを確かめます。

初年度の総費用と3年間の総保有コストも、あわせて比べます。

試算には、Dockerサブスクリプションやクラウドの従量課金を含めます。さらに、保守、追加ユーザー、レジストリ容量、ログ、バックアップ、夜間対応も含めて試算します。

利用者数とデータ量が2倍になる場合や、障害復旧を30分以内にする場合、別会社へ移管する場合の追加費用も質問しておくと、将来の予算を立てやすくなります。

セキュリティとベンダーロックインの評価

セキュリティでは、次の管理策を確認します。

  • イメージ管理:ベースイメージの出所、依存バージョン固定、イメージスキャン
  • ビルド保護:SBOM、署名、ビルド証跡、秘密情報の外部管理、最小権限
  • 実行環境の監視:レジストリのアクセス制御、ログと実行時監視

例として、Trivyなどのスキャン、SBOM、SLSA Provenance、Cosignが挙げられています。加えて、ビルド時の最小権限と、ECRの権限管理も示されています。

これらは同レポートの例です(出典: デジタル庁「CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート」、2025年改定)。

特定ベンダーだけが読める独自設定への依存は、避けます。発注者が管理できる状態にするため、ソース、イメージ、Dockerfileを確認します。IaC、CI/CD、監視設定も、発注者の管理下に置きます。

契約には、クラウドアカウントの所有権、OSSライセンス、再委託先、契約終了後の移管費を記載します。運用手順とデータの出口がなければ、Dockerを採用しても移行の自由度は高まりません。

ポイント

委託先は、Dockerの経験より、業務要件と移行、運用までを担当できるかで判断します。見積は同じRFPと粒度でそろえ、総額と見積範囲の違いを比べます。

よくある質問

費用や技術選定、運用について、よくある疑問をまとめました。

自社の要件に当てはまらない場合は、候補会社との初回相談で前提を確認します。

Dockerのシステム開発を外注するといくらかかりますか?

技術検証は100万〜300万円、小規模業務Webは300万〜800万円が概算レンジです。

既存システムのコンテナ化とクラウド移行は、500万〜1,500万円が目安です。

総額は、機能数、既存コード、データ移行、可用性、セキュリティ、24時間運用の有無で変わります。Dockerのライセンス料金だけでは、総額を判断できません。

Dockerを使うならKubernetesも導入すべきですか?

必ずしも必要ではありません。単一ホストや小規模な検証にはCompose、運用負担を抑えた本番にはECSなどのマネージド基盤が候補になります。

複数サービスの自動復旧や高度な運用が必要な場合は、Kubernetesを検討します。

担当者が少ないまま先に導入すると、学習、監視、更新の費用が増えます。そのため、要件と体制を見て選びます。

既存のJavaやPHPのシステムもDocker化できますか?

多くの場合は可能です。ただし、Docker化の前に、既存システムの次の点を調べます。

  • 環境依存:OSや固定ファイル、ローカル保存に頼っている箇所
  • 古い部品:古いミドルウェアや商用ライセンスの条件
  • 周辺の仕組み:バッチ処理や外部機器との接続

また、状態を持つDBやファイルは、外部サービスへ分離し、接続設定とバックアップを見直す場合があります。

最初は1サービスでPoCを行い、起動だけでなく、性能やデータ永続化、障害復旧も試験します。

委託先にDockerの実績があれば安心ですか?

Dockerの実績に加えて、業務要件とDB移行、クラウドとネットワークを担当できるかを確かめます。さらに、CI/CD、セキュリティ、監視、障害対応、文書納品まで任せられるかも確認します。

担当メンバーや運用時間、障害時の責任分界、契約終了時の移管方法を質問します。そのうえで、同じRFPで複数社を比べます。

まとめ

Dockerを目的にせず、業務成果、停止許容時間、データ、セキュリティ、社内の運用体制をもとに、採用範囲を決めます。

パッケージやクラウドで足りる範囲と、Docker化する範囲、スクラッチ開発する範囲を分けると、過剰な構成を避けやすくなります。

発注前のRFPと比較軸の整備

RFPには、業務要件や現行環境、データ量を書き込みます。さらに、非機能要件、希望時期、予算、納品物、運用範囲、責任分界もまとめます。要件がどの程度決まっているかに応じて、請負、準委任、ラボ型開発のどれが合うかを選びます。

見積は、開発費に加えて、Dockerサブスクリプションやクラウド、レジストリの費用を含めます。さらに、監視、バックアップ、保守、移管費も含めた総額で比べます。

PoCから本番へ進める段階的な進め方

委託先は、Dockerの技術名だけでなく、業務理解や移行経験で評価します。さらに、セキュリティ、運用保守、体制、納品物、引き継ぎも評価の対象です。

まず1サービスのPoCで、再現性や性能、脆弱性、復旧を確認します。その結果をもとに、本番の範囲と費用を決めます。発注者側も、業務ルールやマスタ、移行データを準備します。受入担当を決めたうえで、委託先と成功条件を定義します。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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