Kubernetes外注の判断軸5つ｜コンテナ基盤の提案書レビュー

開発会社から届いた 2 通の提案書には、どちらも「コンテナ化と Kubernetes 基盤への移行」と書かれています。けれども金額は 1,800 万円と 3,200 万円で、倍近い開きがあります。技術構成のページを読み比べても、この差が「何の差」なのかが分かりません。社内で唯一のインフラ担当者に相談しても「Kubernetes は経験がないので判断できません」という答えが返ってきます。稟議を起案できないまま、検討だけが数週間止まっている——そんな状況に置かれている方は少なくありません。

この状況が苦しいのは、単に知識が足りないからではありません。Kubernetes の外注には、他のシステム開発の外注とは違う独特の難しさがあります。それは、成果物が「動いているクラスタ」であり、設計が良いのか悪いのかが、障害が起きるかコストが跳ね上がるまで表面化しないという点です。検収の場でアプリケーションが正常に動いていても、それは設計の妥当性を何も保証しません。

さらに厄介なのは、その先にある構造です。構築が終わっても社内にクラスタを触れる人がいなければ、運用はそのまま同じベンダーに依存し続けることになります。つまり「技術的な妥当性を判断できない」という不安と、「一度任せたら抜けられなくなる」という不安が二重に重なっているわけです。多くの発注者が本当に恐れているのは見積の 1,400 万円の差ではなく、その後に続く数年分の見えない拘束のほうです。

この二つの不安は、技術を一から勉強し直さなくても解消できます。必要なのは Kubernetes の実装知識ではなく、提案書のどこを見て、何を質問し、契約書に何を書いておくかという「発注者側の型」です。回答の中身そのものを技術的に採点できなくても、回答の構造——要件と設計がひも付いて語られているか、責任の所在がフェーズごとに定義されているか——を見れば、妥当性はかなりの精度で切り分けられます。

本記事では、Kubernetes・コンテナ基盤の構築を外注する発注者に向けて、提案依頼の前に社内で決めておく 4 項目、よくある 3 つの失敗パターン、提案書レビューで使う 5 つの判断軸、そのまま会議で使える質問チェックリスト、費用構造と契約形態の考え方、外注先タイプ別の向き不向き、そして構築後の運用移管をどう設計するかまでを順に解説します。

Kubernetes・コンテナ基盤の構築を外注する前に社内で決める4項目

提案書を読み解けない原因の半分は、技術知識の不足ではなく、発注側の前提が言語化されていないことにあります。「何をどこまで移行したいのか」「運用は誰が担うのか」が曖昧なまま提案を受けると、各社が思い思いの前提でスコープを組むため、そもそも比較できない見積が並ぶことになります。まずは社内側の輪郭を固めるところから始めます。

Kubernetesを採用すべきかどうかの判断は本記事では扱いません

本記事は「Kubernetes の採用がすでに前提になっている」段階を対象にしています。そもそも自社のシステムに Kubernetes が必要なのか、コンテナ化だけで十分ではないのか、という一段手前の判断については、Kubernetesとは？発注者が知っておくべき仕組みと導入判断の基準で整理しています。採用の是非にまだ迷いがある場合は、先にそちらで採用判断の土台をつくってから本記事に戻ってくると、以降の判断軸が使いやすくなります。

なお、採用是非の検討をスキップしたまま外注先の選定に進むのは危険です。後述する失敗パターンのうち最も多いのが「要件に対して過剰な構成」ですが、その根っこは発注側が Kubernetes を採用する理由を自分の言葉で説明できていないことにあります。理由が言語化できていれば、提案が要件を超えたときに気付けます。

提案依頼の前に言語化しておきたい4項目

提案依頼（RFP）を出す前に、次の 4 項目を社内で文章にしておきます。完璧である必要はなく、「現時点ではこう考えている」というレベルで構いません。重要なのは、各社に同じ前提を渡すことです。

• 移行対象の範囲: どのアプリケーションを、どの順番で、いつまでに移すのか。全システムを一度に移すのか、まず 1 サービスだけ移して評価するのか。既存システムのうち移行しないものがあるなら、それも明記します
• 予算レンジと投資回収の考え方: 構築費だけでなく、移行後 3 年間のランニング費まで含めた総額でレンジを持ちます。何をもって投資が回収されたと判断するのか（運用工数の削減か、リリース頻度の向上か、スケーラビリティの確保か）も添えます
• 運用体制の希望: 将来的に自社で運用したいのか、運用は継続して外部に任せる前提なのか。この一点だけで、提案されるべき構成もドキュメントの厚さも変わります
• 成功指標: 「移行完了」ではなく、移行後に何がどうなっていれば成功なのかを数値か状態で書きます。デプロイ所要時間、障害復旧時間、月額インフラ費用など、測れるものを 2〜3 個選びます

この 4 項目のうち、外注の失敗に最も効くのは 3 つ目の「運用体制の希望」です。ここが白紙のまま提案を受けると、ベンダーは自社が運用を継続する前提で設計します。その設計は必ずしも悪意によるものではなく、単に「運用は我々が見る」という前提のほうが安全に組めるからです。結果として、社内に知見が残りにくい構成になります。

コンテナ化・Kubernetes移行の進め方と、どのフェーズを外注するか

コンテナ化と Kubernetes 移行の進め方は、一般に次の 5 つのフェーズに分かれます。提案書を読むときは、その提案がどのフェーズを対象にしているのかを最初に確認します。

1. アセスメント: 既存システムの棚卸しと、コンテナ化の適性判定。どのアプリが移行しやすく、どれが困難かを見極めます
2. 移行対象の選定と設計: 移行順序の決定、クラスタ構成・ネットワーク・セキュリティの設計
3. 基盤構築: クラスタの構築、CI/CD パイプライン、監視・ロギング基盤の整備
4. 段階移行: アプリケーションのコンテナ化と、順次のカットオーバー。切り戻し手順の準備も含みます
5. 運用移管: ドキュメント引き渡し、運用体制の確立、内製化するならトレーニングと並走

見積の金額差は、この 5 フェーズのうち「どこまでを含んでいるか」で生まれていることが少なくありません。1,800 万円の提案がフェーズ 3 までで、3,200 万円の提案がフェーズ 5 まで含み、かつ監視基盤の作り込み範囲が広いのであれば、その差は妥当な差です。まず金額を比べる前に、フェーズの守備範囲を並べて比べてください。

また、すべてのフェーズを 1 社に任せる必要はありません。アセスメントだけを別の会社や個人に依頼して、その結果をもとに構築の RFP を出すという進め方も現実的な選択肢です。アセスメントを分離すると、構築を受注したい会社がアセスメントを兼ねることで生じる「大きく作りたくなる」バイアスを避けられます。

Kubernetes・コンテナ基盤の外注でよくある3つの失敗パターン

Kubernetes 導入の失敗が見えにくいのは、前述のとおり成果物が「動いているクラスタ」だからです。設計が過剰でも、権限設計が雑でも、ドキュメントが薄くても、平常時のシステムは問題なく動きます。問題が表面化するのは、障害が起きたとき、コストを精査したとき、そして担当ベンダーを替えようとしたときです。

ここでは、発注者側から見て特に影響の大きい 3 つの失敗パターンを整理します。自社の案件がどれに近いかを診断する目安として読んでください。

失敗パターン1｜要件に対して過剰な構成が提案され、構築費とランニング費が膨らむ

Kubernetes は柔軟な仕組みであるがゆえに、いくらでも作り込めます。マルチクラスタ構成、マルチリージョンでの冗長化、サービスメッシュの導入、独自の内部開発者向けポータルの構築——どれも技術的には正しい選択肢ですが、月間数万リクエスト規模のシステムにすべてを適用すれば、構築費もランニング費も要件に見合わない水準になります。

この過剰構成は、構築費として一度払って終わるものではありません。冗長化されたノード群、常時稼働する監視スタック、複数のクラスタ——これらはすべて毎月のクラウド利用料として積み上がり続けます。しかも運用対象が増えるぶん、保守委託費も高くなります。構築時の 1 回きりの支出に見えたものが、実態としては数年分の固定費を決めていたという構図です。

過剰構成が生まれる典型的な経路は 2 つあります。ひとつは、発注側が成功指標を示していないため、ベンダーが「将来どんな要求が来ても大丈夫な構成」を安全側に倒して設計するケースです。もうひとつは、提案が技術的な網羅性で評価されると想定して、機能を盛って差別化しようとするケースです。どちらも、要件と設計のひも付けを提案書に書かせることで見分けられます。

失敗パターン2｜引き渡し後にクラスタを触れる人がおらず、継続委託が固定化する

構築が完了し、検収も通り、システムは順調に動いています。それでも社内には Kubernetes を触ったことのある人が誰もいません。この状態は、外形上は何の問題もないため、しばらく誰も問題視しません。しかし実態としては、クラスタに変更を加えるあらゆる作業——設定変更、リソースの増減、バージョンアップ、障害対応——が構築ベンダー経由でしか実行できない状態です。

この状態が固定化すると、保守契約の更新交渉で発注者側の交渉力がほとんど働かなくなります。単価の見直しを求めても、乗り換え先を探すコストと引き継ぎリスクを考えれば現実的な選択肢にならないためです。Kubernetes 内製化を掲げていた企業が、数年経っても内製化に着手できていないという話は珍しくありません。

もうひとつ見落とされがちなのは、内製化を掲げること自体が解決策にはならないという点です。日経クロステックは、内製シフトを進めても発注者マインドが変わらなければ、社内の情報システム部門に丸投げするだけの「社内外注」に陥る危険があると指摘しています（無理解のまま進める内製シフトのリスク、「社内外注」に陥る危険も、日経クロステック）。内製化は「誰かに任せる先を社外から社内に変えること」ではなく、運用の責任と判断を自分たちで引き受けることを意味します。

失敗パターン3｜マネージドサービスと外注先の実績クラウドがずれている

EKS・GKE・AKS はいずれも Kubernetes のマネージドサービスですが、実務上の設計は周辺サービスとの組み合わせで大きく変わります。認証・権限管理、ロードバランサ、コンテナイメージのレジストリ、シークレット管理、ログの集約先——これらはすべてクラウドごとに別のサービスであり、ベストプラクティスも異なります。

Kubernetes 自体はオープンソースであり、どのクラウドでも動くという意味では中立です。しかし実際のプロダクション構成は周辺サービスに深く依存するため、「Kubernetes だからクラウドを自由に乗り換えられる」という期待は、そのままの形では成立しません。だからこそ、外注先がどのクラウドで実績を積んできたかが設計品質に直結します。

社内の標準クラウドが Azure なのに、提案元の実績がほぼ AWS に偏っているという組み合わせは要注意です。この場合、AKS の設計として自然な選択肢ではなく、AWS での慣れた構成を Azure に翻訳したような設計になりがちで、周辺サービスの選定に不自然さが残ります。実績の偏り自体は悪ではありませんが、「なぜこのクラウドで、この構成なのか」の説明を求めたときの回答の解像度で判断できます。

なお、複数の Kubernetes 環境が並存すること自体も運用負荷の要因になります。マイナビニュース TECH+ の記事では、約 80% の企業が 2〜3 種類の Kubernetes 環境を利用しており、統一的なガバナンスが課題になっていると紹介されています（クラウドネイティブ移行の落とし穴とは。複雑化するKubernetesの運用をどう制御する?、マイナビニュース TECH+）。すでに別部門で別のクラウドの Kubernetes を動かしている場合は、その事実を RFP に書いておくと提案の質が変わります。

発注者が押さえるKubernetes外注の5つの判断軸

ここからが本記事の主軸です。5 つの判断軸をそれぞれ「なぜ重要か」「提案書のどこを見るか」「どんな回答なら妥当と言えるか」の 3 点で整理します。

重要なのは、回答の技術的な中身を採点しようとしないことです。判定すべきなのは回答の構造です。たとえば選定理由が「弊社の実績が豊富だからです」で終わるなら、それは要件との対応が語られていないという意味で注意が必要な回答です。一方、「御社の要件のうちこの点があるため、この方式を選びました」という形になっていれば、技術内容を検証できなくても、少なくとも要件を起点に設計されていることは分かります。

判断軸1｜EKS・GKE・AKSの選定理由が要件と結び付いているか

なぜ重要か: マネージドサービスの選択は、その後の周辺サービス構成・運用手順・費用構造をまとめて決めてしまいます。あとから覆すコストが最も高い意思決定のひとつです。

提案書のどこを見るか: システム構成図ではなく、その手前にある「方式選定」「技術選定理由」の記述を見ます。ここが数行しかない提案書は、選定が検討の結果ではなく既定路線だった可能性があります。

どんな回答なら妥当か: 判定の目安は次の 3 点です。第一に、既存資産との整合が語られていること（すでに AWS 上に DB やストレージがあるなら EKS を選ぶ合理性がある、など）。第二に、社内の運用体制との整合が語られていること。第三に、その外注先が当該クラウドでの構築実績を具体的な件数・規模で示せることです。

課金構造の違いも確認します。3 サービスはコントロールプレーン（クラスタ全体を制御する管理基盤）の課金モデルが異なります。Amazon EKS は標準サポート中の Kubernetes バージョンで 1 クラスタあたり 0.10 USD/時間、標準サポート終了後の延長サポート期間は 0.60 USD/時間です（Amazon EKS の料金、AWS）。GKE は運用モード（Standard / Autopilot）にかかわらず 1 クラスタあたり 0.10 USD/時間のクラスタ管理手数料がかかり、無料枠として請求先アカウントごとに月 74.40 USD 相当のクレジットが提供されます（Google Kubernetes Engine の料金、Google Cloud）。AKS は Free レベルであればクラスタ管理の料金はかからず（ただし SLA なし）、SLA が必要な場合は Standard レベル、長期サポートが必要な場合は Premium レベルを選択します（AKS の Free、Standard、Premium 価格レベル、Microsoft Learn）。

提案書の見積で、これらのコントロールプレーン費用や AKS の価格レベル選択が明示されているかは、費用の詰め方の丁寧さを測る良い指標になります。

判断軸2｜監視・ロギング・CI/CDと運用体制の設計思想が示されているか

なぜ重要か: Kubernetes 基盤の実質的な価値は、クラスタが立ち上がることではなく、その上でアプリケーションを安全に素早く更新し続けられることにあります。監視・ロギング・CI/CD が薄い提案は、動くけれども運用できない基盤を作ります。

提案書のどこを見るか: 監視の項目に「Prometheus / Grafana を導入します」のようなツール名だけが並んでいないかを確認します。ツール名は設計思想ではありません。見るべきは、何を監視対象とし、どの閾値でアラートを出し、そのアラートを誰が受けて何をするのか、という一連の流れが書かれているかです。

どんな回答なら妥当か: 「どんな障害が起きたときに、誰に、どういう経路で通知が届き、一次対応として何をするか」を口頭で説明できれば妥当です。この説明が出てこない場合、監視は導入されても運用設計は含まれていない可能性があります。

CI/CD については、マニフェスト（クラスタに適用する設定ファイル群）をどこで管理するかを必ず確認します。Git リポジトリで管理し、そのリポジトリの所有者が発注者側になっているかどうかは、後述する運用移管のしやすさに直結します。マニフェストがベンダー側の環境にしか存在しない状態は、実質的に基盤の設計図を預けているのと同じです。

判断軸3｜契約形態と責任分界点がフェーズごとに定義されているか

なぜ重要か: 責任分界点（どこまでが誰の責任範囲かの境界）が曖昧なまま進むと、障害発生時に「これはアプリの問題かインフラの問題か」の押し付け合いが起き、復旧が遅れます。

提案書のどこを見るか: 契約形態が全フェーズで一律になっていないかを見ます。アセスメントのような成果が事前に確定しない作業と、基盤構築のような完成義務を負わせるべき作業を同じ契約形態でくくると、どちらかに無理が出ます。

どんな回答なら妥当か: フェーズごとに契約形態が使い分けられており、かつ各フェーズの完了条件（何をもって終わりとするか）が文章で定義されていれば妥当です。契約形態そのものの考え方は後段の費用と契約形態のところで詳しく整理します。請負と準委任の選び分けの基本については請負と準委任の違いは？発注者が迷わず選ぶための判断フローも参考になります。

判断軸4｜引き渡しドキュメント・IaCコード・トレーニングがスコープに入っているか

なぜ重要か: この軸が、構築後に発注者側の選択肢が残るかどうかを決めます。ドキュメントとコードが手元にない状態では、内製化も乗り換えも現実的な選択肢になりません。

提案書のどこを見るか: 「納品物」「成果物一覧」の項目を見ます。ここに「構築済み環境一式」としか書かれていない提案は要注意です。

どんな回答なら妥当か: 少なくとも次の 4 種類が成果物として列挙されていれば妥当です。

• 設計ドキュメント: 構成図だけでなく、なぜその構成にしたかの判断理由を含むもの
• IaC コード: Terraform や CloudFormation など、インフラ構成をコードとして記述したもの（Infrastructure as Code）。手作業で構築された環境は再現も引き継ぎもできません
• Kubernetes マニフェストと CI/CD 設定: 発注者側の Git リポジトリで管理されていること
• 運用手順書: 日常運用・障害対応・バージョンアップの手順

トレーニングについては、成果物ではなくスコープの一部として明示されているかを確認します。内製化を志向するなら、引き渡し時の一括説明ではなく、構築期間中から発注者側のメンバーが作業に参加できる形になっているかが分かれ目です。

判断軸5｜バージョンアップ運用と運用移管の道筋がロードマップにあるか

なぜ重要か: Kubernetes は更新のペースが速く、放置できません。Kubernetes プロジェクトはマイナーバージョンを年に 3〜4 回のペースでリリースし、直近 3 つのマイナーリリースについてのみリリースブランチを保守します。パッチサポートの期間はバージョン 1.19 以降でおよそ 1 年です（Kubernetes Releases、Kubernetes）。マネージドサービス側にも同様の期限があり、Amazon EKS の場合は各マイナーバージョンについてリリース後 14 か月の標準サポートと、その後 12 か月の延長サポートが提供されます（Amazon EKS Kubernetes バージョン、AWS）。

つまり、バージョンアップは「いつかやる作業」ではなく、年 1 回以上は必ず発生する定常業務です。前掲の EKS 料金のとおり、延長サポート期間に入るとコントロールプレーンの単価が 6 倍になるため、対応の先送りは費用としても跳ね返ります。

提案書のどこを見るか: 保守・運用の章に、バージョンアップの実施頻度・実施主体・費用の扱い（月額保守に含むのか都度見積か）が書かれているかを確認します。

どんな回答なら妥当か: 「年 1 回のバージョンアップを保守契約に含む」「検証環境で先行検証し、本番適用は計画停止の枠で行う」といった具体性があれば妥当です。バージョンアップが都度見積になる場合は、その旨が明記され、概算レンジが示されていることを求めます。あわせて、構築完了から 1 年後・2 年後に運用体制がどうなっている想定なのかを、ロードマップとして語れるかどうかも見ます。

提案書レビューで使えるKubernetes外注の質問チェックリスト

ここでは、5 つの判断軸を提案書レビュー会議でそのまま使える質問文に落とし込みます。技術構成・費用構造・契約と保守の 3 分類で、各質問に判定の目安を添えました。すべてを聞く必要はなく、提案書を読んで曖昧だと感じた箇所から選んで使ってください。

技術構成に関する質問

• 「EKS（GKE / AKS）を選定した理由を、当社の要件のどの部分と対応させて説明していただけますか」

  • 妥当な回答の目安: 既存資産・社内体制・要件のいずれかとの対応が語られる
  • 追加確認が必要な目安: 「実績が豊富だから」「業界標準だから」のみで、要件への言及がない

• 「ノード構成とオートスケーリングの設定は、どのトラフィック想定に基づいていますか。その想定を外れた場合はどうなりますか」

  • 妥当な回答の目安: 想定値の根拠（現行システムの実測値など）と、上振れ・下振れ時の挙動が説明される
  • 追加確認が必要な目安: 想定値の出所が示されず、「余裕を持たせています」で終わる

• 「Kubernetes のマニフェストはどこで管理し、リポジトリの所有者と変更権限は誰になりますか」

  • 妥当な回答の目安: 発注者側の Git リポジトリで管理し、権限も発注者側にあると明示される
  • 追加確認が必要な目安: ベンダー側の管理環境に置かれる、または所有者が明確にならない

• 「クラスタへのアクセス権限とシークレット管理はどう設計されていますか。当社側の担当者はどの範囲まで参照できますか」

  • 妥当な回答の目安: 権限の分離方針と、発注者側に付与される権限が具体的に示される
  • 追加確認が必要な目安: 「弊社で一括管理します」のみで、発注者側の参照範囲が示されない

• 「段階移行の各ステップで、問題が起きた場合の切り戻し手順はどうなっていますか」

  • 妥当な回答の目安: ステップごとに切り戻しの可否と手順、判断基準が定義されている
  • 追加確認が必要な目安: 切り戻しに関する記述がない、または「発生しない前提」とされる

費用構造に関する質問

• 「構築費の内訳を、フェーズ別・作業内容別に分解して示していただけますか」

  • 妥当な回答の目安: 前述の 5 フェーズに対応する形で内訳が示され、各フェーズの工数根拠が説明される
  • 追加確認が必要な目安: 「基盤構築一式」のような大括りの計上が中心

• 「月額のクラウド利用料はどのトラフィック・データ量を前提に試算していますか」

  • 妥当な回答の目安: 前提条件が数値で明示され、前提が変わった場合の増減の目安も示される
  • 追加確認が必要な目安: 前提が書かれていない、または現行システムの実績と無関係な値になっている

• 「コントロールプレーンの課金と、ノード・ストレージ・ネットワークの課金は、それぞれ試算のどこに含まれていますか」

  • 妥当な回答の目安: 課金要素ごとに分解されており、クラスタ数が費用に与える影響も説明できる
  • 追加確認が必要な目安: クラウド利用料が単一の概算値でしか示されていない

• 「クラウド利用料が想定を超えた場合、どの時点で誰が気付き、どう報告されますか」

  • 妥当な回答の目安: 予算アラートの設定と、超過時の報告フローが運用設計に含まれている
  • 追加確認が必要な目安: 費用監視が運用スコープに入っていない

• 「複数クラスタ構成を提案されている場合、単一クラスタとの費用差はどの程度になりますか」

  • 妥当な回答の目安: 差額と、その差額を正当化する要件（環境分離要件など）がセットで語られる
  • 追加確認が必要な目安: 構成の必然性が説明されないまま複数クラスタが前提になっている

契約・保守に関する質問

• 「各フェーズの契約形態と、そのフェーズの完了条件を教えてください」

  • 妥当な回答の目安: フェーズごとに契約形態が使い分けられ、完了条件が文章で定義されている
  • 追加確認が必要な目安: 全フェーズが一律の契約形態で、完了条件が「作業の終了」としか書かれていない

• 「保守契約の SLA（サービス品質保証）と、障害発生時のエスカレーション経路・対応時間を教えてください」

  • 妥当な回答の目安: 受付時間・一次応答時間・重大度区分ごとの対応方針が明示される
  • 追加確認が必要な目安: 「営業時間内に対応します」のみで、重大度区分や応答時間の定義がない

• 「Kubernetes のバージョンアップは誰が、どの頻度で実施し、費用はどちらの負担になりますか」

  • 妥当な回答の目安: 実施主体・頻度・費用の扱いが契約書レベルで定義されている
  • 追加確認が必要な目安: 保守範囲に含まれるか都度見積かが曖昧なまま

• 「設計ドキュメント・IaC コード・マニフェストの著作権および利用権は、契約上どちらに帰属しますか」

  • 妥当な回答の目安: 発注者への譲渡、または発注者が第三者に開示・改変できる利用許諾が明記される
  • 追加確認が必要な目安: 帰属がベンダー側のまま、または契約書に記載がない

• 「契約を終了する場合、引き継ぎとして何をどこまで実施していただけますか。その費用は含まれていますか」

  • 妥当な回答の目安: 引き継ぎ期間・引き継ぎ資料の範囲・費用の扱いが契約条項として存在する
  • 追加確認が必要な目安: 終了時の取り決めが契約に含まれていない

最後の質問は、その場の空気としては聞きにくいものです。しかし、この質問への反応そのものが判断材料になります。誠実な会社は「終了時の条件を先に決めておくのは合理的です」と受け止めます。

Kubernetes・コンテナ基盤構築の費用相場と契約形態の考え方

費用については、単一の相場観を持つよりも「何が金額を決めているか」の構造を理解するほうが実務では役に立ちます。同じ「Kubernetes 基盤構築」でも、対象アプリケーション数と既存資産の状態によって工数は数倍変わるため、相場としての単一値はほとんど意味を持ちません。

構築フェーズ｜何が費用を決めるのか

構築フェーズの金額を左右する変数は、主に次の 4 つです。提案書の見積を見るときは、この 4 つがどう見積もられているかを分解して確認します。

• 移行対象アプリケーションの数と複雑さ: 単純なステートレスの Web アプリと、状態を持つバッチ処理やレガシーなミドルウェアに依存するアプリでは、コンテナ化の難易度がまったく違います
• 既存資産の状態: ソースコードとビルド手順がドキュメント化されていて再現可能なのか、属人的な手順に依存しているのか。後者の場合、コンテナ化の前段に現状把握の工数が乗ります
• CI/CD と監視の作り込み範囲: 最低限のパイプラインを 1 本引くのか、複数環境・自動テスト・段階的リリースまで作り込むのか
• セキュリティ・コンプライアンス要件: ネットワーク分離、監査ログ、権限管理の厳格さは、そのまま設計と検証の工数になります

2 社の見積に大きな開きがある場合、この 4 変数のどこで差がついているかを聞くだけで、多くのケースでは説明がつきます。差の理由が「スコープの差」なのか、「体制の差（アサインされる人員のスキルと人数）」なのか、「リスク引受の差（固定価格で完成義務を負うか、実費精算か）」なのかを切り分けられれば、経営層への説明も組み立てられます。

段階的に移行する場合の費用の考え方については、クラウドネイティブ移行のコストと段階的な移行計画も参考になります。

運用フェーズ｜クラウド利用料と保守委託費の内訳

運用フェーズの費用は、クラウド利用料と保守委託費の 2 本立てで考えます。

クラウド利用料は、コントロールプレーンの料金、ノード（コンテナが稼働するサーバー）の料金、ストレージ、ネットワーク転送量に分かれます。このうちコントロールプレーンは前述のとおりサービスによって課金構造が異なり、クラスタの数に比例して増えます。開発・ステージング・本番で 3 クラスタを立てる構成は、運用上は分かりやすい反面、コントロールプレーン費用も 3 倍になります。名前空間による分離で足りる部分がないかは、費用面から検討する価値があります。

一方でノードの料金は、確保しているサーバーのスペックと台数で決まるため、こちらが利用料の主要部分を占めるのが一般的です。オートスケーリングの設定が適切なら、負荷に応じて台数が増減し、無駄が減ります。逆に、余裕を見て常時多めに確保する設定になっていると、その余裕分は毎月支払い続けることになります。

保守委託費については、何に対して支払っているのかを分解して確認します。監視のみなのか、一次対応まで含むのか、変更作業の実施まで含むのか。月額に含まれる作業量の上限（何時間まで、何件までか）が定義されているかも重要です。定義がない「一式」の保守契約は、いざ作業を依頼したときに追加見積になりやすく、逆に何も依頼しない月も同額を支払うことになります。

契約形態の使い分けと責任分界点

契約形態は、フェーズごとに性質が異なるため使い分けるのが基本です。一般的な型は次のとおりです。

• アセスメント: 準委任。調査の結果として何が出てくるかは事前に確定できないため、成果物の完成を約束させる契約はなじみません。期間と体制を決めて実施します
• 基盤構築: 請負。構築する対象と完了条件が定義できるフェーズです。完成義務を負う請負契約とし、契約不適合責任（納品物が契約内容に適合しない場合の責任）の対象範囲と期間を明記します
• 運用保守: 準委任 + SLA。継続的な役務提供であり、成果物の完成という概念になじまないため準委任とし、品質は SLA で担保します

ただし例外もあります。段階移行のフェーズは、移行してみないと分からない要素が多いため、請負で固定価格にすると見積にリスクプレミアムが厚く乗ります。移行対象を 1 つずつ切り出して個別に請負にする、あるいは準委任で進めて実費精算にするほうが、総額としては合理的になる場合があります。

責任分界点については、契約形態とは別に「運用の境界」を図にして合意しておくことを勧めます。アプリケーションのコードは発注者側、コンテナイメージのビルドは共同、クラスタとノードはベンダー側、といった具合に、レイヤーごとに責任を持つ側を明示します。この図があると、障害発生時の初動が速くなります。

Kubernetes外注先の選択肢別・向き不向き

外注先のタイプによって、得意な領域も、契約後に発注者側に残るものも変わります。ここでは 4 つのタイプについて、案件規模・社内体制・予算・スピード要件に照らした向き不向きを整理します。インフラ領域全般の外注先選びの考え方についてはインフラエンジニアを外注するには？費用相場・選び方・失敗しない発注手順でも整理されているため、あわせて参照すると全体像がつかめます。

外注先タイプの選択は、単に「誰が作るか」の問題ではありません。後述する運用移管のしやすさと直結しているため、出口をどう設計したいかとセットで考える必要があります。

受託開発会社・クラウドインテグレータに向くケース

複数アプリケーションの移行を含む大規模な案件、または社内にインフラ人材がほとんどいない場合に向いています。設計から構築、移行、運用までを一貫して任せられ、元請けとしての責任の所在が明確になるためです。

一方で、体制がしっかりしているぶん費用は高くなりやすく、また運用まで一貫して任せる前提で設計されるため、意識的に要求しなければ発注者側に知見が残りにくい傾向があります。この記事で挙げた判断軸 4（ドキュメント・IaC・トレーニング）を契約時にしっかり効かせることが、このタイプを選ぶ場合の要点です。

Kubernetes に関して評価するなら、対象クラウドでの構築実績の件数と規模、クラウドベンダーのパートナー認定や資格保有者の人数、そして CNCF エコシステム（Kubernetes 周辺の運用ツール群）の運用経験が判断材料になります。

フリーランスのKubernetes・SREエンジニアに向くケース

移行対象が限定的で、社内にプロジェクトを進行できる担当者がいる場合に向いています。実務経験のある個人が入ることで、設計の判断を都度説明してもらいながら進められるため、社内に知見が残りやすいという特徴があります。費用面でも、同等のスキルを組織経由で確保する場合と比べて抑えられる傾向があります。

注意点は、元請けとしての完成責任を個人に負わせにくいことと、稼働時間に上限があることです。障害時の 24 時間対応を個人に期待するのは現実的ではないため、運用体制は別途設計する必要があります。また、スキルの見極めは発注者側で行う必要があるため、判断できる人が社内にいることが前提になります。

内製化を志向する企業にとっては、構築を丸ごと任せるのではなく、社内メンバーと並走してもらう形が有力な選択肢になります。

SES・常駐型に向くケース

期間が読みにくく、要件が動きながら進むプロジェクトで、かつ社内に指揮を執れる担当者がいる場合に向いています。継続的に人員を確保できるため、運用フェーズまで見据えた体制を組みやすいのが利点です。

一方で、成果物に対する責任は原則として発注者側が負うため、技術的な妥当性を判断できる人が社内にいないと、判断軸 1 で挙げた「要件と設計のひも付け」を誰も検証しない状態になりかねません。Kubernetes のように設計の良し悪しが後から効いてくる領域では、このリスクは小さくありません。

組み合わせる場合の設計例

実務では、単一のタイプに絞る必要はありません。フェーズごとに使い分ける設計が現実的な解になることが多くあります。

• アセスメントのみ独立: アセスメントをフリーランスまたは別会社に依頼し、その結果をもとに構築の RFP を出す進め方です。構築受注の意向が設計判断に影響することを避けられます
• 構築は受託、運用は自社 + 伴走: 基盤構築を受託開発会社に請負で発注し、運用は自社で担いながらフリーランスの SRE に伴走してもらう形です。運用のノウハウを社内に蓄積しつつ、判断に迷ったときに相談できる体制を確保します
• 構築と初期運用は一括、段階的に内製へ: 構築ベンダーに運用も一定期間任せつつ、その期間中に社内メンバーが並走して習熟します。並走期間と習熟の到達目標を契約に書き込むことが前提です

いずれの設計を採る場合も、マニフェストと IaC コードの所有権が発注者側にあることが土台になります。ここが担保されていない限り、どの組み合わせを選んでも実質的な選択肢は増えません。

運用移管の出口設計｜内製化と継続委託を契約前に決める

多くの発注者が最も恐れているのは、構築が終わったあとに選択肢がなくなることです。技術的にはオープンソースの Kubernetes を使っていても、運用の知見と設計情報が特定のベンダーにしかなければ、実質的にはロックインされた状態です。この構造そのものの理解にはベンダーロックインの考え方が役に立ちます。

重要なのは、この出口を「構築が終わってから考える」のではなく、契約前に決めておくことです。出口の選択が、構築段階で作るべきドキュメントの厚さも、必要なトレーニングも、契約に書くべき条項も変えるためです。ここでは 3 つのルートと、どのルートでも共通して必要な契約条件を整理します。

出口A｜内製化ルート

構築後 1〜2 年で自社運用に移行するルートです。長期的な運用コストを抑えられ、システム改善のスピードも上がります。

ただし、成立には条件があります。第一に、運用を担う人員を確保できる見込みがあること。採用が進んでいない状態で内製化だけを掲げても実現しません。第二に、その人員が構築期間中から作業に参加できること。引き渡し時の説明会だけで運用できるようになる領域ではありません。第三に、経営として運用に人を割き続ける合意があることです。

契約に反映すべき事項は、並走期間（構築完了後、ベンダーと発注者が並行して運用にあたる期間）の長さ、トレーニングの回数と対象範囲、そして並走期間中に発注者側が自ら手を動かす作業の定義です。「レビューに同席する」だけでは習熟しないため、どの作業を発注者側が主担当として実施するかまで具体化します。

内製化を選ぶ場合こそ、前述の「社内外注」に陥る危険を意識する必要があります。運用の判断と責任を引き受ける体制になっているか、単に作業の実施場所が社内に移っただけになっていないかを、移行の途中で点検してください。

出口B｜継続委託ルート

運用を継続的に外部に委託するルートです。人員を確保できない場合には現実的な選択であり、内製化より劣る選択肢というわけではありません。専門性の高い運用を安定して受けられる利点があります。

このルートで契約前に握るべきなのは、価格と品質が長期にわたって適正に保たれる仕組みです。具体的には、SLA の定義、契約更新時の単価見直し条項、作業量の上限と超過時の扱い、そして年次での運用報告（実施した作業・発生した障害・改善提案）の義務づけです。

あわせて、乗り換え可能性を担保する条項を必ず入れます。ドキュメントとマニフェストが常に最新の状態で発注者側のリポジトリに存在すること、契約終了時に引き継ぎを実施する義務があること、その引き継ぎ費用の扱いが定められていることの 3 点です。乗り換えるつもりがなくても、乗り換えられる状態を保つこと自体が交渉力になります。

出口C｜ハイブリッド（一次対応は社内、二次以降は委託）

一次対応（アラートの受信、定型的な復旧手順の実施、影響範囲の切り分け）は社内で担い、二次以降の調査・恒久対策・設計変更は外部に委託する形です。社内に一定の知見を残しながら、深い専門性が必要な部分は外部に任せられるため、多くの中堅企業にとって現実的なバランスになります。

このルートの設計で肝心なのは、一次と二次の境界を文章で定義することです。「一次対応で解決しない場合に二次へ」という書き方では、判断の基準が人によってぶれます。実務上は、対応時間の上限（一次対応を開始して 30 分で解決しない場合はエスカレーション）と、対象作業のリスト（設定変更を伴う対応は二次）の両面から定義すると運用しやすくなります。

あわせて、一次対応を担う社内メンバーが必要な権限を持っているかを確認します。権限がないまま一次対応の責任だけを負う体制は機能しません。

どのルートでも契約に入れておきたい4条件

3 つのルートのどれを選ぶ場合でも、次の 4 条件は契約書に入れておく価値があります。これらは将来の選択肢を残すための最低限の担保です。

1. 成果物の帰属と利用権: 設計ドキュメント・IaC コード・Kubernetes マニフェスト・CI/CD 設定について、発注者が第三者に開示・改変・再利用できることを明記します
2. ドキュメントの更新義務: 運用委託期間中も、構成変更に応じてドキュメントとコードを最新に保つ義務を課します。これがないと、引き渡された資料は数か月で実態と乖離します
3. 契約終了時の引き継ぎ義務: 終了通知から一定期間、後任のベンダーまたは発注者側への引き継ぎを実施する義務と、その費用の扱いを定めます
4. リポジトリと権限の所有: Git リポジトリ、クラウドアカウント、クラスタへの管理者権限が発注者側に帰属することを明記します。ベンダー側にはあくまで委任された権限が付与される形にします

これらの条件は、ベンダーとの関係を敵対的にするものではありません。むしろ、条件が明文化されていることで、双方が余計な疑心暗鬼を持たずに長期の関係を築けます。交渉の場でも「将来の体制変更に備えて標準的に入れている条項です」と説明すれば、通常は問題なく受け入れられます。

まとめ｜Kubernetes・コンテナ基盤の外注判断で最初にやる3つのこと

Kubernetes・コンテナ基盤の外注は、技術的な妥当性を発注者自身が採点できないという点で、確かに難しい発注です。しかし、判断できないのは技術の中身であって、提案の構造や契約の条件は発注者の領分です。要件と設計がひも付いて語られているか、責任の境界がフェーズごとに定義されているか、引き渡し後に選択肢が残るか——これらは専門知識がなくても検証できます。

そして、本当に守るべきなのは構築費の数百万円ではなく、その後の数年間にわたる選択肢です。ドキュメントとコードが手元にあり、乗り換えの道が開いている状態を保てていれば、たとえ同じベンダーに継続して委託し続けるとしても、それは「選んだ結果」であって「選べなかった結果」ではありません。

最後に、明日から実行できる 3 つのアクションにまとめます。

1. 社内の前提 4 項目を文章にする: 移行対象の範囲、予算レンジと投資回収の考え方、運用体制の希望、成功指標。特に「運用体制の希望」は各社の提案の形を変えるため、必ず言語化して伝えます
2. 手元の提案書にチェックリストを当てる: 技術構成・費用構造・契約と保守の 3 分類から、曖昧だと感じた箇所の質問を選び、次回のレビュー会議で投げます。回答の技術的な正しさではなく、要件との対応が語られるかという構造で判定します
3. 出口ルートを選び、契約条項に落とす: 内製化・継続委託・ハイブリッドのどれを目指すかを先に決め、成果物の帰属、ドキュメントの更新義務、契約終了時の引き継ぎ義務、リポジトリと権限の所有の 4 条件を契約書に反映します

この 3 つを終えた時点で、止まっていた検討は動き出せる状態になります。2 社の見積差は「スコープ差・体制差・リスク引受の差」に分解され、経営層に説明できる形になっているはずです。

関連情報

外部人材やパートナー企業への発注を検討されている方は、発注前の要件整理や比較検討にお使いいただけるお役立ち資料をご用意しています。お役立ち資料の一覧からダウンロードいただけます。

Kubernetes・コンテナ基盤の移行について、要件の整理段階からご相談されたい場合は、お問い合わせフォームよりご連絡ください。提案内容の妥当性の確認や、体制の組み方についてのご相談も承っています。

関連記事

• Kubernetesとは？発注者が知っておくべき仕組みと導入判断の基準
• インフラエンジニアを外注するには？費用相場・選び方・失敗しない発注手順
• ベンダーロックインとは？回避戦略と開発会社の選び方