コンテナ管理基盤の発注・外注は、業務課題と対象範囲を定め、要件と責任分界を順に決めていく流れで進みます。
この順に決めておくと、稼働後の運用まで見通した導入につながります。全体像は、コンテナ管理基盤開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・コンテナ管理基盤開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
コンテナ管理基盤の発注・外注前に決める事項
コンテナ管理基盤は、コンテナランタイムやオーケストレーターなどを組み合わせた共通プラットフォームです。レジストリ、ネットワーク、ストレージも構成要素です。さらに、CI/CD、監視、セキュリティも含まれます。
発注時は、作るものだけでなく、運用担当と本番障害時の判断者も決めておく必要があります。担当が決まっていないと、障害の発生時に誰が判断するかで手間取ります。
業務課題で定める導入目的
最初に決めるのは、解決したい業務課題です。Kubernetesの採用は、その課題を解く手段のひとつとして考えます。業務課題の例には、環境差異や繁忙期の処理能力があります。
ほかにも、チーム間のデプロイ標準化や障害復旧の自動化などが挙げられます。目的が技術の採用だけだと、クラスタの維持や監視に費用をかけても、開発速度や可用性が良くならないおそれがあります。
発注書やRFPには、導入後に確認できる指標を置きます。デプロイ時間や許容停止時間は、その代表例です。目標復旧時間と月間運用工数も、指標として書いておきます。
基盤構築費とアプリ改修費の切り分け
見積では、プラットフォームの構築と既存アプリのコンテナ対応を分けて出してもらいます。
- 基盤側：クラスタ、ネットワーク、レジストリ、権限、CI/CD、監視、バックアップ、運用手順
- アプリ側：設定外出し、ログ出力、ファイル保存先、ヘルスチェック、セッション管理、データベース接続、性能試験
- 移行区分：「そのまま移行」「設定変更で移行」「設計変更が必要」の三段階で洗い出すと、見積を比べやすくなります
この切り分けを省くと、発注後にアプリ改修やデータ移行の追加費用が膨らみやすくなります。
たとえば、コンテナ内へのファイル保存や単一サーバー前提のバッチ処理は、基盤の設定を変えるだけでは直らず、アプリ側の改修が必要になります。
発注形態の選び方
発注形態は、要件の確定度と社内技術者数で決めます。そのうえで、運用を内製する意思と納期の厳しさも考慮します。特に、要件が曖昧なまま一括請負で発注すると、途中の変更で費用が増えやすくなります。
要件の範囲が明確なのに準委任だけで進めると、予算と納期の管理が難しくなります。また、企画・PoCと本番構築で発注形態を変えるやり方も有効です。
成果物と受入条件を確定できる場合の請負契約
請負契約は、合意した成果物を完成させ、検査と受入を経て納品する形態です。契約では、成果物と合格基準を具体的に決めておきます。
- 成果物：開発環境・本番環境のクラスタ構成、Terraformなどの構成ファイル、CI/CD
- 運用・報告：監視ダッシュボード、運用手順書、テスト報告書
- 受入条件：障害復旧、切り戻し、バックアップ復元、権限、脆弱性スキャン
完成の判断に使えるよう、各条件の合格基準を具体的に書いておきます。「高可用」や「安全」といった表現は、そのままでは判断材料になりにくいからです。
クラウド料金や外部ライセンスについては、請負金額に含めるか、実費精算にするかを分けて記載します。
要件探索や技術支援に向く準委任契約
準委任契約は、専門家の知見や作業時間の提供を受ける形態です。
- 要件探索：アプリのコンテナ化可否調査、EKS・GKE・AKS・OpenShiftの比較、RFP作成、PoC評価
- チーム設計：社内担当者と外部エンジニアが同じチームで設計する場合にも使いやすい
- 成果物・記録：準委任でも納品物を決め、週次課題一覧や設計判断の履歴、構成図、検証結果、次段階の見積前提を運営ルールに含めます
成果物や記録を残さず稼働時間だけで管理すると、議論の繰り返しや特定の担当者への依存が見えにくくなります。
調査・PoC・本番の段階発注
段階発注にすると、全社や全システムを一度に対象とせず、効果を確かめながら投資できます。また、各段階に終了条件を置いておくと、期待した効果が出なかった場合に、次の投資を止めたり方式を変えたりできます。
- 第一段階は、現状診断と方式選定です。
- 第二段階は、代表サービスを使ったPoCです。
- 第三段階は、本番基盤の構築と移行です。
- 第四段階は、運用の改善です。
PoCは、コンテナが起動したことだけでは成功とは言えません。確認したいのは、標準手順でのデプロイや障害時の切り戻し、負荷増加への追随です。ログ・メトリクスによる原因調査と、月額費用の試算も、あわせて確かめます。
PoCを準委任で行い、方式と要件が固まってから本番構築を請負で発注すると、変更リスクを抑えられます。
RFPと要件整理で伝える内容
RFPは、会社に提案を依頼するための資料です。技術仕様をすべて発注者が書く必要はありません。
業務背景や制約が曖昧だと、各社が異なる前提で見積もることになります。そのため、RFPには現状と目的、対象範囲を書きます。
非機能要件や希望スケジュール、予算の考え方も加えます。さらに、求める成果物と評価基準も記載します。
現状のアプリ・ネットワーク・運用の洗い出し
現状欄には、発注先が移行範囲を判断できる情報を書きます。
- アプリ構成：言語・フレームワーク、実行環境、データベース
- 連携・認証：外部接続、バッチ、ファイル連携、認証方式
- 負荷・監視：ピーク時アクセスと現在の監視方法
サーバー台数だけでは足りず、サービス間の依存関係と、障害時にも止められない処理も整理しておきます。
コンテナ化の対象外も、あわせて明記します。たとえば、既存データベースは当面マネージドサービスに残す、基幹ネットワークは変えない、Windows専用ミドルウェアは別環境で維持するといった条件があります。
対象外が伏せられていると、提案会社は安全側に見積もり、費用が高くなることがあります。また、認識の食い違いから、後で作業が追加される可能性もあります。
可用性・性能・セキュリティの数値基準
非機能要件は発注後に費用差が出やすいため、種類ごとに数値や基準を決めておきます。
- 可用性・災害対策：稼働率、許容停止時間、RTO、RPO
- 性能・拡張性：同時接続数、応答時間、ノード数、ピーク倍率
- 運用・セキュリティ：ログ、バックアップ、脆弱性対応、通知
性能は同時接続数と応答時間で、拡張性は想定ノード数とピーク倍率で定めます。運用面では、ログ保管期間や監査ログの改ざん防止、バックアップ世代数を決めます。さらに、脆弱性修正期限と夜間通知方法も定めます。
セキュリティでは、レジストリの脆弱性スキャン、イメージ署名、SBOMを要件に含めます。加えて、RBACとSecretの保管場所を定めます。NetworkPolicyや非root実行、Podの権限制限も定めます。
KubernetesのPod Security Standardsは、Privileged、Baseline、Restrictedの3段階です。
発注者は、本番ワークロードの目標レベルを提案依頼時に確認します（出典: Kubernetes公式ドキュメント、2026年確認）。
提案書の評価基準の事前共有
提案の重点を揃えるため、評価項目と配点の考え方をRFPで共有します。
- 方式・移行：方式の妥当性と既存アプリの移行計画
- 運用・安全性：運用設計、セキュリティ、将来の内製化支援
- 実行体制：体制、実績、費用、提案の具体性
配点例は、技術方式と移行計画が30%、運用・セキュリティが25%です。体制と実績、費用は各20%、提案の具体性は5%です。ただし、配点は自社の事情に合わせて決めます。
見積書に加えて、前提条件・対象外・リスクの一覧と、工程表、体制図を出してもらいます。さらに、責任分界表、運用後の月次費用、クラウド料金の変動要因も求めます。
同じ様式で回答を依頼すると、安くても作業範囲が狭い提案と、必要な運用を含む高額な提案を見分けやすくなります。
契約形態と責任分界の決め方
契約では、名称よりも中身を具体的に決めることが大切です。作業範囲、成果物、変更手続き、費用負担は、必ず明記します。
障害対応や知的財産、秘密保持の扱いも、契約で決めておきます。加えて、再委託と終了時の引き継ぎも含めます。
コンテナ管理基盤には、多くの層が関係します。たとえば、クラウドとOS、Kubernetesの層があります。さらに、アプリや監視、ネットワークの層も関わります。
「基盤の障害」に見える事象でも、原因はアプリやクラウドの設定にある場合があります。
責任分界表によるクラウド・基盤・アプリの分担
責任分界表には、基盤とアプリの運用に関わる作業を書きます。
- クラウド・基盤：アカウント、ネットワーク、クラスタ更新、ノードのパッチ
- アプリ・データ：コンテナイメージ、アプリ設定、データベース
- 運用：監視通知、バックアップ、障害一次対応
各項目の担当は、発注者、受託会社、クラウド事業者のいずれかで書きます。特に、24時間365日の監視は、検知、一次切り分け、復旧作業のどこまでを依頼するかで考えます。
Kubernetesにはサポート期限があるため、計画的な更新と、検証環境でのリグレッションテストが必要です。
たとえば、EKSは標準サポートが1クラスタあたり1時間0.10ドル、拡張サポートが0.60ドルと案内されています（出典: Amazon EKS料金ページ、2026年確認）。
更新を先送りすると、管理料が上がる場合があります。そのため、更新の担当と時期、失敗時の切り戻しを契約に含めておきます。
内製化・解約・移行時の持ち出し条件
将来の内製化や別会社への移管に備え、持ち出す資産と管理者を明確にします。
- コード・構成：Gitリポジトリ、IaC、Kubernetesマニフェスト、コンテナイメージ
- 運用資産：監視設定、ログ、バックアップ、設計書、アカウント情報の管理者
契約終了時は、引き渡しの形式も決めておきます。受託会社だけが管理者権限を持つ状態は、障害時にも解約時にも大きなリスクになります。
クラウドロックインを避けたい場合は、Kubernetes標準のマニフェストで移行できる範囲と、クラウド固有サービスへの依存を確認します。
データのエクスポート方法と、移行リハーサルの回数も確かめます。
共通化の対象は、必要な範囲に絞って構いません。ただし、移行できない設定や独自ツールがあれば、その理由と代替策を設計書に残しておきます。
コンテナ管理基盤の費用相場
標準価格はなく、費用は対象サービス数、クラスタ数、可用性で変わります。さらに、アプリ改修量や監視時間も費用を左右します。データ移行やセキュリティ要件も、費用に関わる要素です。
このレンジは、リサーチノートに基づく企画用の目安です。特定案件の確定価格ではありません。見積では、基盤構築、アプリ改修、クラウド実費、運用保守を分けて出してもらいます。
規模別の初期導入費の幅（100万円台から数千万円以上）
初期費用は対象範囲で変わります。企画段階では、規模と構成に応じたレンジを参考にします。
- 検証・PoC：1クラスタ、1〜3サービス、基本レジストリとデプロイで100万〜300万円程度
- 開発・検証環境：CI/CD、権限、ログ、メトリクス、テンプレートを備え300万〜800万円程度
- 本番基盤：マルチゾーンやLB、バックアップ、監視を含みます。SLOや運用手順、段階移行も含めて、800万〜2,000万円程度です。
- 複雑な構成：ハイブリッド、複数クラスタ、災害対策、監査、既存アプリの大規模移行が重なると2,000万〜5,000万円以上
- 追加開発：マイクロサービス化やデータベース分割を含む場合、さらに1,000万〜5,000万円以上
検証・PoCと開発・検証環境のレンジは、大幅なアプリ改修や24時間運用を含まない目安です。
初期費用と分けるクラウド料金と運用委託費
クラウド実費は、クラスタ管理料のほかに利用分も加算されます。そのため、費用項目と月額の目安を分けて確認します。
GKEのクラスタ管理料は1クラスタあたり1時間0.10ドルです。また、請求アカウントごとに月74.40ドルの無料クレジットがありますが、計算リソースなどは無料になりません（出典: Google Cloud GKE料金ページ、2026年確認）。
クラウド利用料は構成によって幅があるため、月額の見積では利用料の内訳を確認します。
- 主な利用料：ノード、ディスク、ロードバランサー、パブリックIPv4
- 通信・運用費：リージョン間通信、ログ、監視、バックアップ、レジストリ、外部通信
- 中小規模の本番：ノード3〜6台、ロードバランサー、ストレージ、ログ、バックアップ、監視を含み、月10万〜50万円程度
- 冗長・大規模構成：複数環境、大量ログ、データ転送、GPU、複数リージョンで月50万〜200万円以上
この推定は、為替やリージョン、インスタンスタイプによって変わります。正式な見積では、各クラウドの料金計算ツールで検証します。
監視や障害一次対応を外注すると、クラウド実費とは別に運用保守費がかかります。パッチやクラスタ更新、月次報告も対象になります。
費用は、夜間・休日対応と対応時間で変わります。アラート件数やオンコール条件も、費用を左右します。
「月額保守一式」のような一括の形より、作業ごとの金額を比べられます。そのため、見積は平日日中と夜間一次対応に分けてもらいます。障害復旧と改善作業も、別々に出してもらいます。
5年TCOによる自社運用とマネージドサービスの比較
方式は初期構築費だけでなく、5年間の総保有コスト（TCO）で比べます。比較項目を並べると、運用方式の違いが見えてきます。
- 自社運用：クラウドや機器の利用料、更新、障害対応、監視にかかる費用です。教育、採用、休日対応の人件費も含みます。
- マネージド：制御プレーンの保守は減らせますが、固有の料金やクラウド依存、追加のサポート契約が発生する場合があります
- 5年の比較費目：初期・月額費、年次更新、ライセンス、障害時費用、解約・移行費
たとえば、AWSのCAFU事例では、EKSを含むモダナイズによって、エンジニアの生産性が100%以上向上し、インフラ費が50%以上削減されたと報告されています（出典: AWS CAFU導入事例、2026年確認）。
企業ごとに構成やチーム、移行期間が異なります。そのため、この数字を自社の効果として約束できる数字ではありません。
委託先の選定と見積比較で確認するポイント
委託先には、Kubernetesの知識に加えて、アプリ移行やネットワーク、セキュリティを一つの計画にまとめられる力が求められます。監視や運用設計も含め、それらを一つの計画として描ける会社を選びます。
候補には、製品ベンダーやクラウド事業者があります。国内SIerやDevOps支援会社もあり、得意領域は会社ごとに異なります。そのため、必要な役割を分解して候補を選びます。
課題と成果で見る実績の確認
実績は、構築数だけでなく、クラスタ規模や対象業務、運用体制で確認します。加えて、移行前の課題、サービス数、停止を避ける方法を聞きます。さらに、データ移行や障害訓練、移管後の体制、改善指標も確かめます。
事例を公開できない場合でも、匿名化した構成や工程、課題を説明できる会社はあります。一方で、製品名だけで受託範囲や成果を説明する会社には注意が必要です。
可能であれば、担当予定のリードエンジニアと面談し、障害時の判断や変更管理について質問します。
見積の前提・範囲・リスクの横並び比較
見積の作業項目を同じ粒度にそろえて、各社の範囲を比べます。
- 設計・構築：現状調査、方式設計、クラスタ、ネットワーク
- 開発・検証：CI/CD、監視、セキュリティ、アプリ改修、テスト
- 移行・運用：移行、教育、運用設計
各社の対象、対象外、工数、担当を確認します。金額が低くても、アプリ改修や移行リハーサルが対象外であれば、単純には比べられません。
前提条件と変更時の単価も確認します。見積条件には、サービス数、環境数、クラスタ数を記載します。
加えて、リージョンやログ量、データ容量を書きます。夜間作業と会議回数も含めます。
前提変更による追加費用や納期への影響、発注者が用意する情報も明記してもらいます。また、見積の有効期限や為替変動、クラウド料金改定の負担者も決めておきます。
運用開始後の体制と引き継ぎ
構築後も、提案に継続的な運用作業と支援体制を含めてもらいます。
- 継続保守：クラスタ更新、ノードのパッチ、イメージの脆弱性対応
- 運用確認：監視ルールの見直し、コスト確認、バックアップ復元テスト
- 稼働後支援：30日・60日・90日の支援と月次報告
提案書には、稼働後30日・60日・90日の支援と月次報告を記載してもらいます。障害時の連絡経路と担当者教育も、あわせて書いてもらいます。
外注先に任せる場合でも、発注者側にサービスオーナーを置きます。サービスオーナーは、予算と可用性、セキュリティを決める役割です。変更の優先順位も、この役割が決めます。
定例会では、障害件数を確認します。加えて、未適用パッチやサポート期限、クラウド費用も見ます。さらに、SLOや未解決リスク、次月の変更予定を取り上げます。
2026年時点で発注時に確認したい最新動向
2026年の発注では、採用実績に加えて、サポート期限やセキュリティ標準を確認します。さらに、AI・GPUとクラウド間の移行性も見ておきます。
CNCFの2025年Annual Cloud Native Surveyでは、コンテナ利用者の82%が本番環境でKubernetesを利用していると報告されています（出典: CNCF Annual Cloud Native Survey 2025、2026年1月公表）。ただし、普及が進んでいても、運用が簡単になるとは限りません。
バージョン更新とサポート期限の見積計上
Kubernetesは、新機能だけでなく、発注時点のバージョンとサポート期限も確かめます。
- 最新パッチ：Kubernetes 1.34は2026年6月時点で1.34.9
- 保守日程：メンテナンスモードは2026年8月27日開始、2026年10月27日終了
日程は、公式リリース情報に掲載されています（出典: Kubernetes公式リリース情報、2026年確認）。
発注時点の最新版に固定せず、更新を計画として組み立てます。その計画には、クラウドの提供状況や更新頻度を入れます。アプリ互換性と検証環境も、計画に含めます。
RFPには、期限の何か月前に更新計画を出すかを書きます。あわせて、互換性試験の担当と、更新中の停止回避策も記載します。
更新が保守対象外だと、期限直前に追加の発注が必要になります。そのため、年次更新作業と検証環境の費用は、初回見積に含めておきます。
マネージドサービスの分担とSLA
マネージドKubernetesでは、制御プレーンの一部を事業者が管理します。一方で、残る責任もあります。
- アプリ・ノード：運用の責任
- ネットワーク・権限：設定と管理の責任
- 監視・データ：監視とデータ管理の責任
たとえば、GKE AutopilotとリージョナルStandardの制御プレーン可用性は99.95%です。また、AKS Standard tierのAPIサーバーSLAは、ゾーンなしで99.9%、ありで99.95%です（出典: Google CloudおよびMicrosoft Learn公式資料、2026年確認）。
SLAの数字だけでなく、対象範囲を確認します。APIサーバーが稼働していても、Podやデータベースが止まれば業務は続けられません。外部APIやDNS、デプロイパイプラインも、業務を支える要素です。
クラウドのSLA、受託会社の対応時間、自社の業務SLOは、分けて説明してもらいます。そのうえで、障害時の連絡と引き継ぎを手順にしておきます。
よくある質問
発注・外注でよくある質問をまとめました。自社の要件にそのまま当てはめるより、RFPや提案比較の論点として使うのが適しています。
コンテナ管理基盤を外注するならKubernetesは必須ですか？
必須ではありません。サービス数が少なく、複雑な配置や高度なオーケストレーションも必要ない場合は、マネージド実行環境が適する場合があります。
候補には、ECSやCloud Run、Azure Container Appsなどがあります。
Kubernetesは、複数チームの標準化や複数サービスの自動配置が要件にある場合に比べます。さらに、複雑なデプロイやマルチクラウド、オンプレミス連携が求められるときも、比較の対象になります。
発注前に予算をいくら確保すればよいですか？
企画用レンジはPoCが100万〜300万円程度、開発・検証環境が300万〜800万円程度、本番クラウド基盤が800万〜2,000万円程度です。
これらは、構築範囲やアプリ改修量で変わる目安です。クラウド実費や運用保守、ライセンスを分けて、複数社に確認します。データ移行と夜間対応も加えたうえで、5年TCOで予算化します。
コンテナ管理基盤の委託先は何社に見積を依頼すべきですか？
同じ要件で比較できるなら、3〜5社程度に提案を依頼すると、方式と費用の幅を押さえられます。社数が多すぎると、質問対応や評価の負担が増します。
候補は、クラウドや製品の専門性に加えて、アプリ移行や運用の実績で絞ります。セキュリティや内製化支援の実績も、判断材料になります。そのうえで、同じRFPと見積様式で比べます。
構築後の運用も同じ会社に外注すべきですか？
同じ会社なら設計意図を引き継げて、障害調査も早く進みます。一方で、特定会社への依存を抑えるには、運用手順やIaC、監視設定を確保します。管理者権限と移管訓練も、あわせて確保します。
24時間対応が必要か、平日日中の監視で足りるかは、業務への影響から決めます。契約期間と解約時の引き継ぎ条件も、明確にしておきます。
まとめ
発注時は、Kubernetesを先に指定せず、業務課題と対象アプリ、可用性を整理します。そのうえで、開発体制と運用時間を踏まえた方式の提案を求めます。
ECSなどのマネージド実行環境やマネージドKubernetesには、それぞれ向き不向きがあります。OpenShiftや自社運用にも、適した場面と合わない場面があります。そのため、技術の新しさだけで決めると、費用と運用負担が見合わなくなります。
発注前のRFPと比較表の準備
RFPには、現状と導入目的、非機能要件を書きます。さらに、対象外や希望工程、受入条件を加えます。加えて、責任分界、運用範囲、クラウド料金の前提、終了時のデータ返却もまとめます。
見積は、基盤構築やアプリ改修、クラウド実費、運用保守に分けて出してもらいます。初期費用だけでなく、5年TCOと更新費も比べます。
金額が安い提案ほど、対象外の作業と発注者側の作業を確認してください。
構築後まで見据えた委託先の選定
委託先は、構築後の移行や運用、契約終了時まで見据えて選びます。発注者側にもサービスオーナーを置き、継続して管理します。
- 委託先の確認：移行、セキュリティ、監視、障害対応、クラスタ更新
- 引き継ぎ：運用移管と解約時の持ち出し
- 定例管理：費用、SLO、脆弱性、サポート期限、未解決リスク
基盤を作って終わりにせず、業務の変化に合わせて安全に改善できる運用を、契約と計画に含めます。外注を成功させるうえで、これが最も確実な方法です。
▼全体ガイドの記事
・コンテナ管理基盤開発の完全ガイド
▼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を創業。