AKSの発注は、目的と責任範囲を定め、RFPとPoCで条件を確かめて進めます。工程に合う契約と委託先を選ぶと、追加費用や運用の抜けを抑えやすくなります。
より広い全体像は、Azure Kubernetes Serviceのシステム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・Azure Kubernetes Serviceのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Azure Kubernetes Serviceのシステムを外注する前の全体像
Azure Kubernetes Service（AKS）は、業務アプリ向けのマネージドKubernetesサービスです。コンテナー化した業務アプリを、Azure上で実行・更新・拡張できます。
ただし、アプリやワーカーノード、ネットワークは利用者側で設計します。データベースや監視、バックアップ、運用手順も、利用者の担当です。
AKSの責任範囲はMicrosoftと利用者で分かれる点
AKSの外注範囲は、Azureと発注者・開発会社で担当が分かれます。そのため、担当領域は切り分けて明記します。
- Azure側：コントロールプレーンの正常性監視と基本メンテナンス
- 利用者側：ノード、Pod、脆弱性、RBAC、秘密情報、復旧、アプリ障害の対応
Microsoft Learnは、AKSのノードを利用者が管理・保守するAzure仮想マシンとして説明しています（出典: Microsoft Learn「AKSにおけるセキュリティの概念」、2025年更新）。そのため、クラスターを構築するだけでは、稼働後の作業が残ります。
RFPには、OSとKubernetesの更新や、監視アラートへの一次対応の担当者を明記します。バックアップやリストア試験の担当者も、あわせて書きます。
AKSが向くシステムと過剰になりやすいシステム
AKSが適しやすいのは、アクセス数が変動するサービスや、複数のマイクロサービスで構成されるシステムです。独立してリリースする複数チームで開発する場合も、AKSが合いやすくなります。
- 混在環境：WindowsとLinuxのアプリケーション
- 変動する処理：イベント駆動のバッチやGPUワークロード
- 運用上の価値：自動スケール、段階的デプロイ、環境差分のコード管理
運用面の価値が業務に結びつく場合は、外注してAKSを導入する理由があります。
一方で、単一のWebアプリを少人数で運用する場合、AKSは過剰になることがあります。その場合は、Azure App ServiceやAzure Container Appsで、費用と運用負荷を抑えられることがあります。
開発会社には、AKSありきで提案せず、候補サービスとの比較結果や、AKSを採用しない場合に不足する点も説明してもらいます。
Azure Kubernetes Serviceのシステムに適した発注形態の選び方
発注形態は、完成品の一括受領、発注者との共同開発、継続的な運用委託に分けられます。
AKS案件では、業務要件もインフラ要件も、初期の段階で固まりにくいものです。そのため、すべてを一つの固定価格契約にまとめるより、工程ごとに発注形態を組み合わせるほうが安全です。
社内の意思決定を残す一括外注
社内のクラウド・Kubernetes担当者が少なくても、要件を決める責任者がいれば、一社に委託できます。
「全部お任せ」では、対象業務や移行データ、保守時間の解釈が会社ごとに変わります。納品物の範囲も、会社によって受け止め方が分かれます。そのため、RFPには対象外の範囲も書きます。
- 委託範囲：要件定義、設計、実装、移行、運用引き継ぎ
- 発注者：業務ルール、優先順位、予算、受入基準を決定
- 開発会社：AKS基盤、アプリ改修、CI/CD、テスト、ドキュメントを担当
Azureアカウントの所有者、ソースコードとIaCの権利を確かめます。障害時の連絡経路や、契約終了時の引き継ぎ条件も、あわせて取り決めます。
社内に技術を残したい企業向けの共同開発と運用委託
社内にアプリ担当者がいて、AKS設計やSREを補いたい場合は、共同開発や技術支援型の契約を検討します。
- 基盤整備：開発会社がランディングゾーン、クラスター、監視、デプロイパイプラインを整備
- アプリ開発：社内チームがアプリをリリース
- 内製化支援：設計レビュー、ペア作業、運用訓練を契約に含める
- 運用委託：24時間365日の監視や障害一次対応が難しい場合に追加
運用委託では、対応時間、一次切り分け、復旧作業まで範囲を確認します。そのうえで、エスカレーションや月次報告、Azure利用料の最適化まで決めます。「監視あり」と書くだけでは、範囲が伝わりません。
PoCから始める発注と技術リスクの確認
モノリスのコンテナー化、Windowsコンテナーの動作、ピーク時のスケールが不明な場合は、本開発の前に小規模なPoCを発注します。
- 技術確認：ビルド、イメージスキャン、デプロイ、ログ取得、データ接続
- 運用確認：負荷試験、ロールバック、ログ検索性、復旧時間
- 費用確認：月額Azure費用の試算
PoCの対象は、代表的な一つのサービスにします。そのうえで、提案書だけでは見えない制約を確かめます。本番へ進まない場合に残る成果物や、作成したIaC・コンテナー定義を本開発で再利用できる条件も、あわせて確認します。
成功条件は、画面が表示されるかだけでは足りません。デプロイ所要時間や同時接続数、脆弱性検出時の対応も、測定の対象に加えます。
RFP・要件整理によるAzure Kubernetes Serviceの発注範囲の決め方
RFPは、開発会社に同じ前提で提案してもらうための依頼書です。細かなKubernetesマニフェストまでは必要ありません。
まず、目的と対象範囲を分けて記載します。性能や可用性、セキュリティは、それぞれ別の項目として書きます。移行や運用、納品物も、項目ごとに分けて書きます。
未確定の項目は、「提案してほしい事項」として示します。そうすると、各社の提案の差が見えやすくなります。
業務目的と現行システムの情報の整理
AKS導入の目的は、測定できる業務目標に結びつけて書きます。「コンテナー化」は、その手段として位置づけます。
- 業務目標：繁忙期の応答時間維持、リリース頻度向上、拠点の手作業削減
- 現行情報：言語、OS、外部接続、DB、ファイル、バッチ、認証、ピーク時間、障害履歴
- 移行上の確認点：ローカル保存、固定IP連携、手作業のマスタ更新、夜間バッチ
- 業務の棚卸し：例外処理と表記揺れ
事例として、RelativityはWindowsアプリをAKS上のWindowsコンテナーへ移行しました。数百万行のコードを書き直さずに、デプロイサイクルを6か月から1日へ短縮したと、Microsoftが紹介しています（出典: Microsoft Learn「Windows AKSの顧客事例」、2025年）。
ただし、大規模な事例がそのまま再現できるとは限りません。自社では、更新速度や移行負担の軽減を発注目的に結びつける参考にします。
数値と運用条件で書く非機能要件
「安全に」「速く」「止めずに」のような表現は、そのままでは判断しにくいものです。そのため、非機能要件を目標値に置き換えて書きます。
- 性能と可用性：通常・ピーク時の同時接続数、応答時間、月間稼働率
- 復旧と保管：RTO（目標復旧時間）、RPO（目標復旧時点）、保管リージョン
- 運用条件：許容するメンテナンス時間
数値が未確定の場合は、現状値と希望値を分けて書きます。必要なノード数や費用の前提は、開発会社に提案してもらいます。
セキュリティ要件には、Private Clusterや閉域接続、Microsoft Entra IDとRBACを含めます。認証はWorkload Identity、秘密情報はKey Vaultで管理する方針を定めます。イメージスキャンやネットワークポリシーに加えて、監査ログと脆弱性の修正期限も指定します。
AKSの認証やAzureの機能があっても、アプリ権限の設定やログ確認は自動では完了しません。そのため、承認者と証跡の保管者も決めておきます。
RFPに含める運用範囲と納品物
AKSの発注では、構築の完了を終点にせず、運用と納品の範囲まで決めておきます。
- 運用要件：監視項目・閾値、オンコール時間、障害優先度、更新周期
- 継続運用：バックアップ頻度、リストア試験、容量計画、請求確認、月次報告
- 設計・構成：設計書、構成図、ネットワーク・権限一覧、IaC、Helm・マニフェスト、CI/CD定義
- 引き継ぎ資料：テスト結果、障害対応、バックアップ・リストア、運用手順
納品するIaCには、TerraformやBicepなどを含めます。ソースコードだけでなく、別の会社へ引き継げる状態になるかも確認します。ライセンスとアカウントの所有権も、契約書と合わせて確かめます。
24時間監視が不要な検証環境は、本番基幹系と同じ保守メニューにしないようにします。そうすることで、費用の適正化につながります。
Azure Kubernetes Serviceのシステム開発で選ぶ契約形態
AKSでは、要件が変わりやすい上流工程、成果物を定義しやすい実装、継続運用で契約を分ける方法が現実的です。
価格だけで選ぶと、仕様変更の追加費用や、開発会社が見込む高い予備費につながります。そのため、作業の性質に合わせて契約形態を選びます。
要件定義・PoC・技術支援に向く準委任契約
準委任契約は、作業時間や専門人材の提供を前提とする工程に使いやすい形です。
- 対象工程：要件定義、アーキテクチャ検討、PoC、設計レビュー、内製化支援
- 合意単位：月単位またはフェーズ単位
AKSへ移行できるサービスや、AutomaticとStandardの使い分けを検討する段階では、完成品としての成果を約束しにくいことがあります。
発注者の側でも、会議への参加や資料の提供、意思決定を担います。検証環境の利用とマスタ・仕様の確認も、発注者の役割です。
契約では、稼働時間に加えて、担当者の役割と作業報告を定めます。レビュー方法や成果物の扱いも、決めておきます。途中解約や再委託、秘密保持も、契約書で定めます。
完成責任を求める工程を準委任にすると、発注側と開発会社の認識がずれるため、注意が必要です。
仕様と受入基準を固めた実装に向く請負契約
請負契約は、成果物と受入条件を定義しやすい設計・実装・テストに適しています。
- ネットワーク：指定構成をIaCで再現する
- テスト：合意したテストケースに合格する
- アプリ：決めた画面とAPIを納品する
実装の途中で、別のサービス構成への変更や、想定以上の既存コード改修が判明することがあります。その場合は、変更管理が必要になります。
そのため、契約前に変更の定義と追加見積もりの単価を決めておきます。納期への影響と、発注者の承認者も定めます。なお、要件定義とPoCを準委任にして、仕様確定後の構築を請負にする方法もあります。
SLAと対応範囲を定めた保守・運用契約
本番稼働後は、月額固定の保守・運用契約にする場合が多いです。そのうえで、SLAと作業範囲を定めます。
- 対応条件：監視対象、受付時間、一次応答時間、復旧目標、計画メンテナンス
- 保守作業：Kubernetes更新、脆弱性対応、バックアップ確認、月次報告、障害時の追加作業
- SLAの対象：Azure基盤か、アプリの業務機能まで含むか
契約が終わるときは、設定やログを返却できるかを確認します。運用履歴や手順書も、返却の対象になるかを確かめます。
Azureサブスクリプションは発注者名義で保有し、開発会社には必要な権限だけを付与します。そうすると、委託先の変更や内製化がしやすくなります。
既存契約との責任分界は表にまとめ、Azure、開発会社、発注者の三者で認識をそろえます。
Azure Kubernetes Serviceのシステム開発費用と月額相場
AKSの費用は、開発会社へ支払う初期費用、Azureの月額費用、稼働後の保守・運用費に分けて考えます。
クラスター管理が無料の価格レベルでも、ワーカーノードのVMやディスク、ネットワークは別に課金されます。ロードバランサーやログ、DBも、別料金の対象です。バックアップやデータ転送も、課金の対象になります。「無料」だけを見て予算を組むと、課金分が漏れてしまいます。
規模別に見る開発・導入費のレンジ
リサーチノートの概算では、開発・導入費は学習・検証用のPoCから基幹刷新まで、規模によって大きく違います。
- PoC：学習・検証用で100万〜300万円程度
- 小規模本番：300万〜1,000万円程度
- 中規模：マイクロサービスや移行を含み1,000万〜3,000万円程度
- 大規模：基幹刷新で3,000万円〜1億円以上
上のレンジは、発注時に検討するための数字です。アプリ改修や基盤設計、テストを含み、移行や運用設計も範囲に入ります。AKS公式の固定価格ではありません。
費用は、サービス数や既存コード改修、データ移行で変わります。可用性ゾーンやPrivate Cluster、複数環境、Windowsノードも、費用に影響します。
負荷試験や監査要件、24時間運用も費用に影響します。「AKS構築一式」で頼むより、工程ごとに見積もりを求めるほうが比べやすくなります。見積もりは工程ごとに分け、要件定義やアプリ改修、ネットワークのように、工程名と金額を並べてもらいます。ID・セキュリティから運用設計までの各工程も、同じ形式で示してもらいます。
構成と利用量で変わるAzure月額
Azure利用料の概算は、構成の規模ごとに次のレンジで検討します。
- PoC：月3万〜15万円程度
- 小規模本番：月10万〜50万円程度
- 中規模マイクロサービス：月50万〜200万円程度
- 大規模構成：月200万〜1,000万円以上
価格レベルのFree、Standard、Premiumは、Microsoft Learnの2026年7月更新情報に基づいて説明します（出典: Microsoft Learn「AKS Free、Standard、Premiumの価格レベル」、2026年）。
Freeは開発・テスト向けで、StandardはアップタイムSLAが必要な本番向けです。一方で、PremiumはSLAと24か月の長期サポートを要する規制環境などが対象です（出典: Microsoft Learn「AKS Free、Standard、Premiumの価格レベル」、2026年）。
AKS Automaticは運用向けの既定値を備え、2025年9月に一般提供されました（出典: Microsoft Azure Blog、2025年9月16日）。
金額は、リージョンやVMサイズ、ノード数、稼働時間で変わります。転送量やDB、ログ保持期間、可用性構成も影響します。為替や購入契約も、金額に関わります。
発注時には、Azure料金計算ツールで金額を再計算します。価格レベルや運用モードは、安さだけでなくSLAと更新方針で決めます。
開発費と別に見積もる保守・運用費
保守費は、監視だけを含むか、障害対応・更新・改善・FinOpsまで含むかで変わります。リサーチノートの業務システム一般論では、初期開発費の年15〜20％程度とする考え方があります。
- 費用の目安：開発費3,000万円なら年450万〜600万円、月約37万〜50万円
- 上振れ要因：24時間監視、休日対応、SRE、セキュリティ調査、アプリ改修
- 見積区分：固定保守料金と作業時の従量費
Kubernetes更新や脆弱性対応は月額に含まれるか、障害復旧後の原因分析は別料金かを確かめます。
Azureリソースを増減させるときの承認者も、あらかじめ決めておきます。なお、検証環境の夜間停止や、安定稼働ノードの割引制度の検討は、運用開始後の改善項目として契約に含められます。
Azure Kubernetes Serviceの委託先選定と見積比較のポイント
委託先は、Azure対応を掲げるかだけでなく、AKSの本番運用経験で選びます。そのため、クラスター規模とノード構成、担当した役割、障害対応体制を確認します。
Kubernetes更新の方法や、アプリと基盤の責任分界も確かめます。実名事例を開示できない場合も、匿名化した構成と課題、対応範囲、運用期間を説明できる会社は比較しやすくなります。
AKSの本番経験と運用体制の確認
提案時には、製品機能だけでなく、担当者と手順を確かめます。証跡や実績も、あわせて見ます。
- 方式選定：AKS AutomaticとStandardを使い分ける条件
- 障害対応：本番のノード・Pod障害への対応手順
- 更新管理：KubernetesバージョンとOSイメージの管理者
- 脆弱性対応：検知から修正までの目標営業日数
大手SIerは、基幹連携や複数拠点の運用体制に強みを持つ場合があります。一方で、専門クラウド事業者は、AKSやDevOpsの設計・改善に強みを持つことがあります。
会社の規模だけでなく、業務理解や技術者の継続性、意思疎通、障害時の意思決定速度が自社に合うかも見ます。
同じ前提で工程別に比べる見積もり
見積もりの比較では、合計額より先に前提条件をそろえます。同じRFPを渡して、工程と費用項目を分けて提示してもらいます。
- 工程：要件定義、PoC、アプリ改修、AKS基盤、ネットワーク、セキュリティ
- 開発作業：CI/CD、テスト、データ移行、教育、保守
- 別費用：Azure利用料、作業費、外部ライセンス、24時間対応費
費用を別欄にすると、作業を外して安く見せた見積もりを見抜けます。
比較表には、工数または人日と単価、期間を置きます。担当人数や成果物、検収条件も、同じ表に入れます。前提や対象外、変更時単価も、書き添えます。
監視や保守、セキュリティ対応は、会社ごとに定義が違います。そのため、含む作業を文章で確かめます。バックアップや障害対応の範囲も、ここで確認します。
3社以上から提案を受ける場合も、価格だけでなく、質問の質とリスクの説明力を評価します。
小さな検証と段階発注による失敗リスクの抑制
発注後の増額や遅延につながる要因は、事前に洗い出しておきます。そのうえで、検証と社内体制を整えます。
- 技術・移行リスク：非ステートレスなアプリ、固定IP連携、データ品質
- 追加・調整リスク：監視やログ要件の追加、現場の承認遅れ
- 契約上の検証：PoC、移行試行、負荷試験、リストア試験を節目に設定
- 社内体制：業務、情報システム、セキュリティ、現場、契約・購買の担当者
これらは、AKSを導入しただけでは解消しません。質問への回答期限と意思決定者も、明確にしておきます。要件定義を外注しても、業務の優先順位や受入判断の責任は委託できません。
社内の協力作業を計画に含めると、納期と費用の見通しが安定します。
Azure Kubernetes Serviceの発注・外注でよくある質問
料金や責任分界は、契約や構成によって変わります。一般論は、自社のRFPと見積もりに置き換えて確認してください。
Azure Kubernetes Serviceのシステム開発を外注するといくらかかりますか？
PoCは100万〜300万円程度、小規模本番は300万〜1,000万円程度、中規模は1,000万〜3,000万円程度が検討レンジです。
Azure利用料と保守費は、別に発生します。金額はノード数やデータベース、監視で変わり、ネットワークや移行、24時間対応の有無でも変わります。そのため、工程別見積もりを取得してください。
社内にKubernetesの人材がいなくても外注できますか？
外注できますが、業務の優先順位、予算、受入判断を行う社内責任者は必要です。
開発会社には、要件定義や基盤構築、監視を依頼できます。障害対応や更新、内製化支援も、依頼の対象です。一方で、社内は業務知識と意思決定を担います。
24時間運用が必要なら、保守契約の対応時間とSLAを先に確認します。
AKS AutomaticとStandardはどちらを選べばよいですか？
選ぶ際は、自社標準に合うかと、本番化の進め方を基準にします。
- Standard：ノードプール、ネットワーク、Terraform・Helm・GitOpsを自社標準に合わせる
- Automatic：既定値や自動化を活かして早く本番へ進む
Automaticを選んでも、丸投げにはなりません。アプリやデータ、権限の責任分担を、RFPで確認します。監視ルールや障害対応の責任も、RFPに明記します。
開発会社には、自社の要件に合う理由を説明してもらいます。
AKSの発注は請負契約にすれば安心ですか？
契約形態を請負に決めるだけでは、安心とは限りません。要件定義やPoCは準委任、仕様確定後の構築は請負、稼働後は保守・運用契約とする方法があります。
契約形態だけでなく、成果物や受入基準、変更手順が具体的かを確認します。責任分界や障害対応、終了時の引き継ぎも、具体的に書かれているかを見ます。
まとめ
AKSを発注するときは、採用目的を明確にします。App ServiceやContainer Appsも含めて、選択肢を比べます。
PoCや一括外注、共同開発、運用委託の中から形態を選びます。そのうえで、業務要件と非機能要件をRFPに落とし込みます。
発注前の目的と責任分界の整理
費用は、開発・導入費、Azure月額、保守・運用費に分けて、構成と作業範囲をもとに再計算します。
- 発注条件：AKS本番経験、運用体制、契約形態、納品物、変更条件をRFPでそろえる
- 運用責任：アプリ、データ、セキュリティ、監視、更新、復旧の担当を合意する
AKSは、クラスター構築のあとも、アプリやデータを継続して運用する業務基盤です。そのため、責任分界と運用の出口まで合意したうえで、業務成果につながる提案を選びます。
工程別の見積もりと継続運用までの比較
同じ前提で3社以上から見積もりを取り、価格以外の条件も比べます。
- 比較項目：工程別工数、Azure利用料、保守範囲、受入基準
- 対象外作業：移行、監視、更新、復旧訓練に別費用がないか
運用後の改善と内製化の可能性も含め、長期的に協力できる委託先を選びます。
▼全体ガイドの記事
・Azure Kubernetes Serviceのシステム開発の完全ガイド
▼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を創業。