LASSIC Media らしくメディア
コンテナ化・Kubernetes移行の開発を外注する進め方｜既存アプリのモダナイズ範囲と費用の判断軸
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- コンテナ化・Kubernetes移行は「リプラットフォーム」に分類される移行戦略で、既存アプリをそのまま移すリフト&シフトとは技術スコープが異なります。
- 外注前に「アプリの可搬性」「チームのスキルギャップ」「ビジネス継続性リスク」の3軸でモダナイズ範囲を絞り込むことが費用の最適化につながります。
- 外注先の選定では、Kubernetes認定資格（CKA/CKAD）の保有状況、CI/CDパイプライン構築実績、移行後の運用サポート体制を確認することが大切です。
目次
コンテナ化・Kubernetes移行とは — リプラットフォームの位置づけ
コンテナ化・Kubernetes移行とは、既存のアプリケーションをDockerコンテナにパッケージし、Kubernetes（K8s）でオーケストレーションする形態に移行する取り組みを指します。クラウド移行戦略の分類では「リプラットフォーム」に相当し、既存インフラをそのままクラウドに移す「リフト&シフト（Rehost）」とは技術的な難易度・投資額が大きく異なります。
Kubernetesはもともとコンテナ化されたワークロードの管理を自動化するオープンソースプラットフォームとして、2014年にGoogleによって公開されました*1。自動スケーリング、ローリングアップデート、セルフヒーリング（障害時の自動復旧）といった機能が標準で備わっており、大規模な本番環境で広く採用されています。
クラウド移行戦略6Rとリプラットフォームの関係
クラウド移行の計画策定では、アプリケーションごとに最適な移行パターンを選択する「6R」（Rehost・Replatform・Refactor・Re-purchase・Retire・Retain）という分類が広く参照されています。このうち「Replatform（リプラットフォーム）」は、アプリケーションの基本的なアーキテクチャを維持しながら、動作環境だけをクラウドネイティブ（コンテナ・マネージドサービス等）へ移行する戦略です。
コンテナ化・Kubernetes移行はこのReplatformに分類されます。コードを大幅に書き直す「Refactor（リファクタリング）」よりも変更範囲が限定的で、既存アセットを活用しながら運用効率を高められる点が特徴です。
コンテナ化で何が変わるか
従来の仮想マシン（VM）ベースの構成では、アプリケーションとOSが密結合しており、環境ごとの差異が「動作環境依存バグ」を生みやすい状態でした。コンテナ化によってアプリケーションとその依存ライブラリがDockerイメージとしてパッケージされるため、開発環境・ステージング・本番の差異を大幅に縮小できます。
Kubernetesを組み合わせることで、コンテナの自動スケーリング（トラフィック増減に応じたPod数の調整）、ローリングアップデート（無停止デプロイ）、障害時のセルフヒーリングが実現します。Kubernetes公式ドキュメントによれば、これらの機能は宣言的な設定ファイル（マニフェスト）によって管理されます*1。
モダナイズの範囲をどう決めるか — 外注前に整理すべき3つの判断軸
コンテナ化・Kubernetes移行を外注する前に、「どのアプリをどこまでコンテナ化するか」という範囲の合意が重要です。範囲が曖昧なまま発注すると、スコープ拡大による追加費用や工期超過が起きやすくなります。以下の3つの判断軸で整理することを推奨します。
判断軸1 — アプリの可搬性とステートレス度
コンテナ化に適しているのは、外部の状態（ファイルシステム・セッション・ローカルDB）に依存しない「ステートレス」なアプリケーションです。セッション情報をサーバ内メモリに保持するWebアプリや、ローカルディスクへの書き込みに依存するバッチ処理は、コンテナ化の前に設計変更が必要になるケースがあります。
まず対象アプリのアーキテクチャを棚卸しし、「すぐにコンテナ化できるもの」「事前改修が必要なもの」「コンテナ化よりVM継続が現実的なもの」の3区分に分類することがスコープ絞り込みの出発点です。
判断軸2 — チームのKubernetesスキルギャップ
Kubernetes（K8s）の運用には、マニフェスト（YAML）の読み書き、クラスタのネットワーク設計（Service・Ingress）、セキュリティ設定（RBAC・NetworkPolicy）など広範な専門知識が求められます。CNCF（Cloud Native Computing Foundation）のAnnual Survey 2023（回答者988名・2023年8〜12月実施）によると、Kubernetesを本番運用または評価中と回答した組織は全体の84%に上りますが*2、同時に運用スキルの習得が普及の課題として挙げられています。
社内にCKA（Certified Kubernetes Administrator）やCKAD（Certified Kubernetes Application Developer）の資格保有者がいない場合は、移行設計から運用移管まで含めた包括的な外注スコープで発注することが現実的です。
判断軸3 — ビジネス継続性リスクとスコープ分割
本番稼働中のシステムをコンテナ化する際は、移行中のサービス断リスクを最小化する計画が欠かせません。全アプリを一括で移行する「ビッグバン移行」は、技術的な検証が不十分な場合に大規模障害につながるリスクがあります。
外注先と協議するうえでは、まず負荷の低いサービス・バックエンドAPIからコンテナ化し、段階的にフロントエンド・ステートフルサービスへ展開するフェーズ分割アプローチを選択することが大切です。各フェーズで切り戻し手順（ロールバック計画）を合意してから発注スコープを確定すると、リスクを抑えられます。
Kubernetes移行の外注プロセス — 5フェーズの進め方
コンテナ化・Kubernetes移行の外注は、以下の5フェーズで進めるのが一般的です。各フェーズで発注側と受注先が何を担うかを明確にすることが、スコープ漏れを防ぎます。
フェーズ1 — 現状調査・移行可否アセスメント
既存アプリのアーキテクチャ、外部依存（DB・ストレージ・認証サービス）、ビルド・デプロイフロー、非機能要件（可用性・レスポンスタイム）を棚卸しします。外注先に現状ドキュメント（構成図・CI/CDパイプライン仕様・インフラ設定）を提供できる状態にしておくことが、アセスメントの精度を高めます。
このフェーズのアウトプットは「移行難易度マップ」と「フェーズ分割案」です。発注側はこれを受け取ってから全体の外注スコープと優先順位を確定します。
フェーズ2 — コンテナ化設計（Dockerfile・マニフェスト設計）
アセスメント結果をもとに、各アプリのDockerfileとKubernetesマニフェスト（Deployment・Service・ConfigMap・Secret等）を設計します。このフェーズでは「コンテナイメージのベースOS選定」「レイヤー構成によるイメージサイズ最適化」「環境変数によるコンフィグ外部化」が主な設計作業です。
Kubernetes公式ドキュメントによれば、Deploymentリソースが宣言的に管理することで、ローリングアップデートやロールバックの制御が可能になります*1。設計段階でこれらの動作を確認するテスト計画を合わせて作成しておくことを推奨します。
フェーズ3 — CI/CDパイプライン構築とテスト環境
コンテナ化したアプリを継続的にデリバリーするために、CI/CDパイプライン（GitHub Actions・GitLab CI・Jenkins等）とコンテナレジストリ（Docker Hub・AWS ECR・Google Artifact Registry等）を整備します。テスト環境（ステージングクラスタ）でのE2Eテスト、ロードテスト、セキュリティスキャン（コンテナイメージの脆弱性スキャン）もこのフェーズに含めます。
発注側はテスト項目・合格基準を事前に定義し、受注先と合意することが品質担保に直結します。「合格基準が曖昧なまま本番移行に進んで障害が発生した」というケースは外注失敗の典型パターンです。
フェーズ4 — 本番クラスタ構築・移行（ブルーグリーン/カナリア）
本番Kubernetesクラスタ（AKS・EKS・GKEなどマネージドサービスが一般的）を構築し、段階的にトラフィックを切り替えます。「ブルーグリーンデプロイメント」（旧環境と新環境を並走させてトラフィックを一括切替）または「カナリアリリース」（新バージョンへ段階的にトラフィックを移行）のどちらを採用するかは、サービスの可用性要件と移行コストのトレードオフで決まります。
Kubernetesアーキテクチャでは、Control Plane（kube-apiserver・etcd・scheduler・controller-manager）がクラスタ全体の状態を管理し、Worker Node上のkubeletがPodを実際に動作させます*4。本番クラスタ設計では複数ノードにわたる高可用性構成を採用することが推奨されます。
フェーズ5 — 運用移管・監視体制の確立
移行完了後の運用体制の確立が、外注成功の最後の関門です。アラート設定（PodのCrashLoopBackOff検知・リソース使用率監視）、ログ集約基盤（Fluentd/Loki等）、ダッシュボード（Prometheus/Grafana等）を整備し、社内運用チームへのドキュメント・トレーニングを実施します。
外注先に運用保守も継続委託する場合は、SLA（サービスレベル合意）・対応窓口・エスカレーションフローを契約書に明記することが大切です。「構築だけ外注して運用は内製」という場合は、移行プロジェクト期間中に社内担当者が外注先から知識移転を受けるOJT計画を合意します。
費用の目安と外注先選定の判断軸
コンテナ化・Kubernetes移行の外注費用は、対象アプリの数・複雑度・フェーズ範囲によって幅があります。以下はあくまで市場参考値であり、一次資料ではありません。実際の発注時には複数社への見積もり取得を推奨します。
規模別の費用レンジ（市場参考値・一次資料ではない）
| 規模感 | 対象アプリ例 | 費用レンジ（参考） | 期間目安 |
|---|---|---|---|
| 小規模（単一サービス） | マイクロサービス1〜3本、社内ツール | 数百万円〜 | 2〜4か月 |
| 中規模（複数サービス） | Webアプリ＋API＋バッチ処理 | 1,000万円〜3,000万円程度 | 4〜8か月 |
| 大規模（エンタープライズ） | 基幹系を含む複数ドメイン | 5,000万円以上 | 12か月以上 |
上記の費用には、アセスメント・設計・開発・テスト・移行作業が含まれます。その後の運用保守費用（クラスタ管理・監視・アップデート対応）は別途見積もりが必要です。
外注先選定で確認すべき5つのポイント
コンテナ化・Kubernetes移行の外注先を選定する際は、以下の5点を確認することを推奨します。
- Kubernetes認定資格の保有状況：CKA（Certified Kubernetes Administrator）またはCKAD（Certified Kubernetes Application Developer）の資格保有エンジニアがプロジェクトにアサインされるか確認します。
- CI/CDパイプライン構築実績：GitHub Actions・GitLab CI・ArgoCD等のツールを用いた継続的デリバリー環境の構築経験を確認します。
- 対象クラウドのマネージドK8s実績：AWS EKS・Azure AKS・Google GKEのうち、自社が利用するクラウドでの構築経験を確認します。
- 移行後の運用サポート体制：構築完了後の保守委託や知識移転トレーニングを提供できるかを確認します。
- 元請（プライムベンダー）としての責任範囲：パートナー企業への再委託が発生する場合、一次窓口として責任を持つ元請体制かどうかを確認します。複数ベンダーへの分散発注は管理コストが増大します。
| 比較軸 | 内製（自社エンジニアで対応） | 外注（専門パートナーに委託） |
|---|---|---|
| 初期コスト | 人件費＋トレーニング費が発生。 既存業務と並行するため工期が長くなりやすい。 |
プロジェクト費として固定化しやすい。 スコープを絞ることでコスト最適化が可能。 |
| スキル | K8s認定資格・実務経験の習得に時間がかかる。 学習中はミスのリスクが高まる。 |
認定エンジニアが初日から参画可能。 実績ベースのベストプラクティスを適用できる。 |
| リスク | 設計ミスや設定ミスによる本番障害リスクが高い。 担当者が退職した場合のナレッジ消失リスクもある。 |
契約上の責任・SLAで品質を担保できる。 外注先への依存度（ベンダーロック）は管理が必要。 |
| ナレッジ蓄積 | 中長期的に社内に知見が蓄積される。 | 知識移転・ドキュメント整備を契約に含めることで 社内ナレッジを補完できる。 |
外注失敗を防ぐ — よくある3つの落とし穴
コンテナ化・Kubernetes移行の外注では、技術的な難易度だけでなく「発注の進め方」に起因する失敗が起きやすいです。よくある3つの落とし穴を整理します。
落とし穴1 — ステートフルサービスをそのままコンテナ化するリスク
セッション情報をサーバ内メモリに保持するWebアプリや、ローカルファイルシステムへの書き込みに依存するサービスをそのままコンテナ化すると、Podが再起動・再スケジュールされたときにデータが消失する問題が生じます。コンテナは本来ステートレス（状態を持たない）な実行環境として設計されており、永続データはKubernetes PersistentVolume（PV）やクラウドマネージドDBへの外出しが必要です。
アセスメントで「ステートフル度の高いアプリ」と判定された場合は、コンテナ化前に状態の外部化リファクタリングを実施するか、Kubernetes StatefulSetリソースを用いた設計を採用する必要があります。この判断を外注先任せにすると、仕様の認識齟齬から追加費用が発生します。
落とし穴2 — 監視・ログ設計を後回しにするリスク
Kubernetesはネイティブなログ永続化ストレージを提供しないため、別途ログ集約基盤の設計が必要です*3。移行フェーズ完了後に「本番でPodが異常終了したが原因特定ができない」という状況は、監視設計を後回しにした場合の典型的なリスクです。
アラート設定（CPU/メモリ使用率・Pod再起動回数・エラーレート）とオブザーバビリティ基盤（Prometheus＋Grafana等）を本番移行前に構築することを、外注スコープに明示的に含めることを推奨します。
落とし穴3 — 発注側の関与が薄くベンダーロックインが生じるリスク
「外注したから後はお任せ」という姿勢でプロジェクトを進めると、クラスタ設定・マニフェスト・CI/CDパイプラインが外注先ベンダー固有の設計で構築され、後から別のパートナーへ切り替えることが困難になるリスクがあります。
この問題を防ぐためには、定期的なレビュー会議への発注側の参加、設計ドキュメント・構成図の共有、リポジトリの発注側管理（外注先にはアクセス権のみ付与）という3点を契約段階で合意することが大切です。発注側エンジニアが移行後に自走できる状態を目指すことが、外注費用の継続増大を防ぎます。
まとめ — コンテナ化・Kubernetes移行外注の3つの判断軸
本稿では、コンテナ化・Kubernetes移行を外注するための進め方を整理しました。要点を3点にまとめます。
第一に、「リプラットフォーム」の技術スコープを正確に理解することです。リフト&シフトとは異なり、コンテナ化にはDockerfile設計・K8sマニフェスト・CI/CD構築・監視基盤の整備が伴います。このスコープを発注前に明確化することが費用精度の前提です。
第二に、「アプリの可搬性・スキルギャップ・ビジネス継続性リスク」の3軸でモダナイズ範囲を絞り込むことです。全アプリを一括移行するのではなく、フェーズ分割で段階的に移行することがリスク低減につながります。
第三に、外注先選定でKubernetes認定資格・CI/CD実績・元請体制を確認することです。構築完了後の知識移転・運用サポートを契約スコープに含めることで、長期的なベンダー依存を軽減できます。
よくある質問
コンテナ化とKubernetes移行は同時に外注する必要がありますか。
同時に進めることは必須ではありません。まずDockerコンテナ化（Dockerfileの作成・イメージのビルド・テスト）を先行させ、動作確認が取れた段階でKubernetesへの移行設計を進めるフェーズ分割アプローチも有効です。ただし、コンテナ化とK8s移行を別々のベンダーに依頼すると認識齟齬が生じやすいため、一貫して担当できる元請（プライムベンダー）に委託することを推奨します。
既存のオンプレミスアプリをKubernetesに移行する際、どのくらいの期間がかかりますか。
移行期間はアプリケーションの数・複雑度・ステートフル度によって変わります。単一サービスの小規模移行では2〜4か月、複数サービスにわたる中規模移行では4〜8か月が市場参考値として挙げられます（一次資料ではありません）。ただし、アセスメントで「ステートフル依存が高い」「外部連携が複雑」と判定された場合はさらに延長する可能性があります。アセスメントフェーズ完了後に外注先から提示されるスケジュールで判断することを推奨します。
KubernetesはAWS・Azure・GCPのどのクラウドで使うのが適していますか。
AWS（EKS）・Azure（AKS）・Google Cloud（GKE）はいずれもマネージドKubernetesサービスを提供しており、基本的な機能差は小さいです。既に利用しているクラウド環境に合わせて選択することが一般的で、コスト面では既存の割引契約（EDP/EA等）を活用できる既存クラウドを継続するケースが多く見られます。マルチクラウド対応が要件の場合はKubernetes自体のポータビリティを活かせますが、運用複雑度は上がります。
コンテナ化・Kubernetes移行の外注費用を抑えるにはどうすればよいですか。
費用を抑えるためには、まず「全アプリを一括移行しない」ことが大切です。可搬性が高く影響範囲の小さいサービスからフェーズを絞って発注し、実績・手順書を積み上げてから次フェーズに進む方法が有効です。また、外注スコープにアセスメントを含め、移行難易度を正確に把握してから本移行の見積もりを取得することで、見積もり段階でのスコープ過大を防げます。
Kubernetes移行後の運用保守も外注できますか。
外注可能です。クラスタのバージョンアップ対応（Kubernetesは年数回のマイナーバージョンリリースがあります）、Pod障害対応、セキュリティパッチ適用、監視ダッシュボードの管理といった運用保守を継続委託するケースは実務上よく見られます。契約時にSLA（応答時間・復旧目標）・対応範囲・エスカレーションフローを明文化することが、運用品質の担保につながります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：The Kubernetes Authors「What is Kubernetes? — Kubernetes Documentation」（2014年公開・2026年参照）
- *2 出典：CNCF「CNCF Annual Survey 2023」（2023年8〜12月実施・回答者988名・スクリーニング済み実利用組織対象）
- *3 出典：The Kubernetes Authors「Logging Architecture — Kubernetes Documentation」（2026年参照）
- *4 出典：The Kubernetes Authors「Cluster Architecture — Kubernetes Documentation」（2026年参照）
