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

Amazon EKSのシステムを発注・外注するなら、EKSを導入すること自体ではなく、業務要件、AWS基盤、アプリ、移行、運用までの責任範囲を先に分けて決めることが成功の近道です。

Amazon EKSはKubernetesのコントロールプレーンをAWSが管理するサービスですが、アプリケーション、データ、権限、監視、障害対応まで自動で完成するわけではありません。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較、発注後の運用引き継ぎまでを、発注者が確認すべき順番に沿って解説します。

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

Amazon EKSのシステムを発注する前に何を決めますか？

発注前に決めるべきなのは、「EKSを使って何を作るか」だけではありません。誰がどの業務を使い、どの水準で稼働させ、障害やコストの判断を誰が担うのかを決めておくと、会社ごとの見積条件をそろえやすくなります。AmazonのECサイトの仕組みを知りたい検索者と、AWSのAmazon Elastic Kubernetes Serviceを使ったシステムを開発したい発注者では目的が異なるため、ここでは後者を対象にします。

最初の相談で「EKSの構築をお願いします」と伝えるだけでは、委託先は必要なサービス数や運用体制を判断できません。「複数のマイクロサービスを独立してリリースしたい」「ピーク時だけ処理能力を増やしたい」「既存のKubernetes資産をAWSへ移したい」など、導入によって変えたい業務を一つずつ言葉にします。成果指標は、リリース頻度、障害からの復旧時間、ピーク時の応答時間、運用担当者の作業時間などにすると評価しやすいです。

高度なスケジューリング、多数のマイクロサービス、Kubernetes標準のマニフェスト、GPUや既存クラスターの活用が必要ならEKSが候補になります。一方、単一のWeb APIや小規模なバッチを少人数で運用する場合は、ECSやLambdaのほうが学習対象と障害箇所を減らせる可能性があります。RFPにはEKSを採用する案だけでなく、ECSやLambdaを採用した場合の費用、運用負荷、将来の拡張性も比較してもらうと、技術ありきの発注を防げます。

AWSはEKSのコントロールプレーンを管理しますが、アプリケーションの可用性、コンテナイメージ、データ、VPC設定、IAM、監視、バックアップ、運用判断は発注者側に残ります。EKS Auto Modeを使う場合はノードやロードバランサー、ストレージなどの管理範囲が広がりますが、アプリとデータの責任がなくなるわけではありません。委託先には構築範囲だけでなく、バージョンアップ、脆弱性対応、夜間障害、AWSへの問い合わせ、運用教育まで含めるかを確認します。

Amazon EKSの発注形態はどれを選びますか？

発注形態は、要件の不確実さ、自社の技術者、業務側の参加時間、既存システムの複雑さで選びます。最初から全工程を丸ごと委託する方法もありますが、PoC、要件定義、本番構築、移行、運用を分けると、判断をしながら投資を進めやすくなります。どの方式でも、自社が決める事項と委託先が実行する事項を表にしておくことが重要です。

社内にAWSやKubernetesの経験者が少なく、業務整理から運用設計まで一つの窓口に任せたい場合は、一括外注が候補です。要件定義、VPCとIAM、EKS、アプリ、CI/CD、監視、テスト、移行、教育を一社が統括できるため、会社間の責任分界を減らせます。特に既存VMやオンプレミスからの移行では、アプリ改修と基盤設計を別会社に分けるより、全体のPMを置いたほうが課題を追いやすいです。

ただし、業務の意思決定まで委託先に丸投げすると、現場が使わない機能や、データ品質を無視した構成が残る危険があります。発注者側には業務責任者、データ管理者、セキュリティ判断者を置き、週次で優先順位、未決事項、追加費用の見込みを確認します。

EKSの採用可否や性能が不明な場合は、代表サービスを一つ選んでPoCを発注し、結果を見て本番構築へ進みます。PoCの成果物には、コンテナ化したサービス、デプロイ手順、負荷測定、ログとアラート、権限分離、障害復旧、月額AWS利用料、残課題、本番化の再見積条件を含めます。クラスターが作成できたことではなく、本番で必要な品質を測れることが合格条件です。

段階発注は初期費用を下げるだけの方法ではありません。識別子の不一致、データ移行の難しさ、想定外の通信量、担当者の運用負担を早く見つけ、本番の手戻りを減らすためのリスク管理です。PoCが不合格だった場合にECSや別方式へ切り替える条件も、最初の契約書や発注書に記載します。

AWS基盤はクラウド専門会社、アプリは業務システム会社、監視やヘルプデスクは運用会社という分担も可能です。専門性を集めやすい反面、EKSとアプリの境界で不具合が起きたときに、原因調査が各社の押し付け合いになりやすいです。複数社で発注するなら、全体アーキテクチャ、API仕様、環境構成、監視項目、受け入れテスト、一次窓口を共通の設計書にします。

発注者が全体PMを担えない場合は、一社を統括会社に指定し、他社との調整を契約範囲に含めます。価格だけを理由に分割すると、会議、障害切り分け、仕様調整、責任確認の工数が増え、結果として一括発注より高くなることがあります。

Amazon EKSのRFPと要件整理では何を伝えますか？

RFPは機能一覧ではなく、業務課題、利用者、既存資産、性能、セキュリティ、運用、納品物、予算条件を同じ前提で比較する文書です。候補会社が都合のよい条件で見積もらないよう、必須要件、希望要件、対象外、発注者が提供する情報を分けて記載します。未確定の事項は空欄にせず、各社に仮定と追加費用を明示してもらいます。

利用者を開発者だけでなく、業務担当者、運用担当者、セキュリティ担当者、管理者に分け、それぞれが何を見て、何を操作し、どの判断を行うかを整理します。「システムを安定稼働させる」ではなく、「月末の請求処理を止めず、失敗時は30分以内に担当者へ通知する」のように、きっかけ、処理、完了条件、例外時の対応を書きます。

発注者が持つべき業務ルールや正解データを、委託先に丸ごと預けないことも大切です。マスタの所有部署、更新頻度、削除や訂正の承認者、個人情報の利用目的を整理し、データ移行の照合方法までRFPに含めると、後から「想定データが違う」という問題を減らせます。

既存アプリの一覧、サービス間の依存関係、ソースコード、実行環境、データベース、外部API、コンテナ化の可否、ピーク時のアクセス数、1日あたりの処理量を提示します。EKS側は、VPC、複数AZ、プライベートサブネット、Ingress、ECR、EBSやEFS、RDSなどの構成候補を示してもらい、どこまでを開発費に含めるかを明確にします。

性能要件は「高速」ではなく、レイテンシー、同時利用者数、エラー率、デプロイ時間、RTO、RPO、ログ保存期間で表します。監視はCPU使用率だけでなく、Podの再起動、ノード不足、デプロイ失敗、主要業務の成功率まで定義します。これらがない見積書は、安く見えても性能試験や運用設計が別料金になる可能性があります。

IAMの最小権限、EKSのアクセスエントリ、Pod Identity、KMSによる暗号化、イメージスキャン、監査ログ、脆弱性対応、バックアップ、秘密情報の管理方法をRFPに記載します。AWSを使うだけで自社サービスの法令対応が完了するわけではないため、個人情報の保存地域、委託先管理、監査証跡、漏えい時の連絡体制も自社のデータ分類と結び付けて確認します。

セキュリティ要件を納品直前のチェックにすると、設計変更と追加費用が発生しやすくなります。誰が権限申請を承認し、誰がログを確認し、脆弱性が見つかったとき何営業日以内に対応するかまで、運用手順と受け入れテストの条件にします。

Amazon EKSの開発ではどの契約形態を選びますか？

契約形態は、要件が固まっているか、成果物を検収できるか、仕様変更が多いかで選びます。EKSの構築費だけを一つの金額にまとめると、未確定の非機能要件や移行条件が追加請求につながりやすいため、要件定義、PoC、本番構築、保守を分けて契約する方法も有効です。

請負契約は、合意した成果物を完成させ、検収することを重視する契約です。EKSでは、設計書、TerraformやCDKなどのIaC、Kubernetesマニフェスト、CI/CD定義、監視設定、テスト結果、Runbook、バックアップ復元手順、教育資料を成果物として列挙します。単に「クラスター構築完了」とせず、負荷試験の条件、障害復旧の確認、権限のレビュー、ロールバックの実演まで検収条件に含めます。

要件変更が多い案件で請負範囲を広くし過ぎると、変更管理のたびに調整が必要になります。発注時点で未確定の事項、変更を受け付ける手順、追加費用の単価、納期への影響、発注者の遅延があった場合の扱いを契約書に明記します。

準委任契約は、一定の業務を専門家が遂行することを重視する契約です。要件整理、アーキテクチャ検討、移行計画、運用改善、内製化支援のように、作業量や成果の形が変わりやすい工程で使いやすいです。発注者は、稼働日数、担当者の役割、会議体、報告内容、対応時間、作業記録を確認し、何を依頼した時間なのかを管理します。

準委任だから成果物を曖昧にしてよいわけではありません。設計レビューの記録、課題一覧、決定事項、構成案、PoC結果、次工程の見積条件など、各月または各フェーズで残す成果を合意します。自社に知識を残すことが目的なら、担当者とのペア作業やレビュー参加も契約範囲に入れます。

本番稼働後は、KubernetesやEKSのバージョンアップ、ノードやイメージの更新、脆弱性対応、監視、障害一次対応、AWS利用料の確認、月次レポートを保守運用の範囲に含めます。EKS Auto Modeはノードのパッチやライフサイクル管理を広げられますが、アプリの可用性や監視設計まで自動化するものではないため、委託先との役割分担を残します。

24時間365日の監視を付ける場合は、通知を受ける時間帯、一次切り分け、エスカレーション、復旧目標、報告書、再発防止の範囲を確認します。平日日中の問い合わせだけで十分なシステムに過剰な契約を付けないことも、TCOを抑える判断です。

Amazon EKSのシステム開発費用とAWS利用料の相場

Amazon EKSの費用は、開発会社へ支払う初期費用、AWSの月額利用料、稼働後の保守費用を分けて考えます。EKSクラスターを作る費用だけで比較すると、ネットワーク、ノード、ストレージ、ロードバランサー、ログ、データ転送、運用設計の差が見えません。以下の開発費はEKSの公式定価ではなく、リサーチノートとクラウド基盤案件の構成要素から算出した目安です。

学習やPoCは100万〜300万円、期間は1〜2か月が一つの目安です。単一サービスのコンテナ化、開発用クラスター、最低限のCI/CD、負荷や障害復旧の検証を想定し、本番SLAや大規模な監視は含めない前提です。標準的な本番基盤は500万〜1,500万円、期間は3〜6か月が目安で、2〜3AZ、IAM、ECR、ロードバランサー、ノード、ログ、メトリクス、バックアップ、デプロイ手順などを含めて見積もります。

既存システムのコンテナ化と移行は1,500万〜5,000万円、期間は6〜12か月のレンジを見ます。複数サービス、データ同期、段階リリース、性能試験、障害訓練、運用引き継ぎが増えるためです。金融や医療級の統制、マルチアカウント、マルチリージョン、数十サービス以上の構成では5,000万円〜1.5億円以上、12〜24か月になる可能性もあります。これは案件条件から変動する推定であり、固定価格の断定ではありません。

AWS公式の料金情報では、標準サポートのEKSクラスター料金は1クラスター時間あたり0.10米ドルです。730時間を1か月として計算すると約73米ドルで、1米ドル150円と仮置きした場合は約1万1,000円です。ただし、これはコントロールプレーンの料金だけであり、EC2またはFargate、EBS、NAT Gateway、ロードバランサー、パブリックIPv4、データ転送、CloudWatchなどは別に発生します（出典: AWS公式「Amazon EKSの料金」、2026年確認）。

バージョンの拡張サポートを使う場合は1クラスター時間あたり0.60米ドル、730時間で約438米ドルとなる料金例もあります。AWS公式のEKS Auto Mode例では、EC2費用1,046.82米ドルにAuto Mode管理費125.62米ドルが加わり、合計約1,172米ドルです。実際の金額はリージョン、インスタンスタイプ、稼働時間、通信量、ログ量で変わるため、見積書ではAWS料金と開発会社の費用を分離して提示してもらいます（出典: AWS公式「Amazon EKSの料金」、2026年確認）。

初期開発後は、保守費用を開発費の10〜20％程度で仮置きする方法があります。ただし、24時間365日監視、アプリ改修、バージョンアップ、脆弱性対応、障害訓練、AWSのコスト最適化をどこまで含めるかで変わります。予算化では、開発費、AWS利用料、保守費、追加改修費、社内担当者の教育工数を分け、1年目と2年目以降のTCOを比較します。

大規模な公開事例は自社の見積もりにそのまま当てはめません。AWSが公開するMiroの事例ではコンピュート費80％削減、開発者の保守負荷60〜70％削減が報告されていますが、規模や移行前の運用方式が異なります。Adaの事例でもコンピュートコスト15％削減や、アップグレード期間を最大5か月から5日に短縮した実績が示されています。自社では同じ数値を約束せず、PoCで現状との差を測定します（出典: AWS公式Miro・Ada導入事例、2024年公開）。

Amazon EKSの委託先選定と見積比較のポイント

委託先は、EKSの構築経験だけでなく、アプリのコンテナ化、AWSネットワークとIAM、Kubernetesのアップグレード、可観測性、セキュリティ、FinOps、運用引き継ぎまで確認して選びます。AWS認定や会社規模だけで決めず、自社と似たサービス数、データ量、規制、運用時間帯の事例を見せてもらいます。公開できない事例でも、課題、担当範囲、成果物、体制、運用期間を説明できる会社は比較しやすいです。

候補会社には、「EKSのバージョンアップを誰が、どの頻度で行うか」「ノード障害とアプリ障害をどう切り分けるか」「脆弱性が見つかったコンテナを何時間以内に更新するか」「夜間に誰が通知を受けるか」「IaCとRunbookをどう引き継ぐか」を質問します。Auto Modeを提案された場合も、ノードの直接アクセスが制限されること、AWSが管理する範囲、アプリ側に残る監視と復旧の責任、追加の管理費を説明してもらいます。

2026年はEKS Auto Modeの自動化やEKS Capabilities、Provisioned Control Planeなど選択肢が増えています。Provisioned Control Planeでは、AWSが2026年3月に99.99％のSLAと8XL階層を発表し、大規模AIやHPC向けの選択肢を広げました。一方で、必要な規模でなければ費用と設計の複雑さが増えるため、最新機能を使う理由と使わない理由を両方提案できる会社を選びます（出典: AWS公式「Amazon EKS announces 99.99% Service Level Agreement and new 8XL scaling tier」、2026年3月）。

見積書は総額だけでなく、要件定義、基本設計、詳細設計、基盤構築、アプリ改修、データ移行、テスト、教育、運用開始の工程に分けてもらいます。各工程で担当する人数と期間、成果物、検収方法、前提条件、含まれない作業を確認します。特に性能試験、セキュリティ診断、バックアップ復元、AWSアカウント設定、監視、夜間対応、バージョンアップ、追加の環境作成は、別料金になっていないかを見ます。

複数社を比較する際は、同じRFP、同じサービス数、同じデータ量、同じRTOとRPOを渡します。安い見積もりの会社には対象外項目とリスクを、高い見積もりの会社には必要な作業と省略可能な作業を説明してもらいます。単価だけでなく、見積の透明性、変更時のルール、担当者の経験、納品後の支援を含めて評価すると、発注後の追加費用を抑えやすいです。

納品物には、アーキテクチャ図、構成パラメーター、IaC、マニフェスト、CI/CD定義、IAM設計、監視定義、アラートの判断基準、バックアップと復元手順、障害対応Runbook、費用確認手順、アップグレード計画を含めます。管理画面で手作業をした結果だけを納品されると、担当者が変わったときに再現できません。リポジトリの所有権、AWSアカウントの管理者、秘密情報の保管場所、ライセンスの扱いも契約前に確認します。

内製化を目指す場合は、委託先に任せきりにせず、設計レビュー、ペア作業、障害訓練、アップグレードの実演に自社担当者が参加します。引き継ぎ期間、問い合わせ窓口、保守終了後の対応、追加改修の単価まで明らかにしておくと、特定の担当者や会社に依存し続けるリスクを減らせます。

よくある質問（FAQ）

Amazon EKSの発注では、サービスの機能よりも、費用の分け方、責任範囲、運用の引き継ぎに関する質問が多くなります。ここでは、発注前に確認しやすい代表的な疑問へ直接回答します。

PoCは100万〜300万円、標準的な本番基盤は500万〜1,500万円、既存システムのコンテナ化と移行は1,500万〜5,000万円が目安です。要件、サービス数、データ移行、SLA、監視、セキュリティ、運用時間で変わる推定レンジのため、AWS利用料と開発会社の費用を分けた見積もりを取得してください。

不要にはなりません。Auto Modeはノード、ロードバランサー、ストレージ、ネットワークなどの管理範囲を広げられますが、アプリケーション、コンテナ、データ、VPC設定、アクセス権限、監視、障害時の業務判断は利用者側に残ります。発注時には、AWSが担う範囲と、委託先または自社が担うDay 2運用を分けて確認します。

成果物と検収条件を固められる本番構築は請負契約、要件整理やPoC、運用改善のように作業内容が変わりやすい工程は準委任契約が候補です。どちらを選んでも、成果物、作業範囲、変更管理、納期、検収、追加費用、責任分界を明記します。実務では、要件定義を準委任、確定した本番構築を請負に分ける組み合わせもあります。

同じRFPを使って2〜4社程度に相談し、価格だけでなく、要件への質問の質、EKSを使わない案の有無、運用と引き継ぎの説明、見積の透明性を比べると判断しやすいです。候補が多過ぎる場合は、公開事例、AWSやKubernetesの専門性、対応可能な運用時間帯で絞り、最終候補に詳細見積とPoC計画を依頼します。

Amazon EKSのシステム発注・外注・委託方法まとめ

Amazon EKSの発注では、まずEKSで解決したい業務課題と、ECSやLambdaではなくEKSを選ぶ理由を整理します。次に、PoC、本番構築、移行、保守のどこまでを委託するかを決め、RFPには業務フロー、サービス数、データ、性能、権限、セキュリティ、RTOとRPO、運用時間帯、納品物を記載します。

委託先を選ぶときは、EKSの構築経験だけでなく、アップグレード、監視、障害対応、コスト最適化、セキュリティ、データ移行、内製化支援を確認します。見積書は工程、成果物、含まれない作業、AWS利用料、保守費、変更単価を横並びにし、安さの理由と高さの理由を質問します。高機能な構成を入れることより、現場が運用でき、事業のKPIを改善できることを優先します。

採用に迷う場合は、代表サービス一つを使って、デプロイ、スケール、ログ、権限、障害復旧、費用を測定します。PoCで得た結果を本番の見積条件と運用設計に反映し、発注者側にも業務責任者と運用責任者を置きます。EKSの導入を目的にせず、安定稼働、開発速度、復旧時間、総保有コストという成果につながる形で外注を進めることが大切です。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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