マイクロサービス基盤の発注は、まず業務要件を整理し、PoCで境界と運用を検証したうえで、責任範囲を定めて段階的に移行する流れで進めます。
この順で進めると、開発と運用を続けるための土台につながります。
▼全体ガイドの記事
・マイクロサービス基盤開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
マイクロサービス基盤の概要と発注する価値の判断
マイクロサービス基盤は、受注、顧客、商品、在庫、請求などを独立したサービスとして開発・配備・拡張するための共通環境です。
通信や認証の仕組み、実行環境、データ管理から、CI/CD・監視・障害対応、セキュリティまでを一体で設計する点が、アプリを複数のコンテナに分けるだけの作業との違いです。
共通基盤として発注する範囲
共通基盤に含める成果物は、通信・認証、データ・連携、運用基盤の3領域にまたがります。
- 通信・認証：APIの入口、認証、タイムアウト、リトライの定義
- データ・連携：メッセージキューと、サービスごとのデータ所有権の定義
- 運用基盤：デプロイパイプラインから、集中ログ、メトリクス、分散トレーシング、シークレット管理まで
業務ルールや画面、既存ERPとのデータ連携は、個別サービスや移行工程として切り分けて見積もります。そうすると、各社の提案を比較しやすくなります。
向いている企業と向かない案件
導入の目的は、リリース頻度や障害影響、復旧時間、チームの自律性などの業務指標で定めます。
- 効果が出やすい企業：複数チームが並行リリースし、機能ごとに変更頻度が異なる企業
- 個別拡張が必要な企業：アクセスが急増する領域だけを拡張したい企業
- 別方式が合う案件：少人数の単純なCRUD業務、変更が少ない社内システム、責任者が増えない案件
別方式が合う案件では、モジュラーモノリスやマネージドPaaSが適する場合があります。
発注前に整理すべき業務要件と非機能要件
見積もりの差は、技術の優劣より前提条件の違いから生まれるため、RFPの前に現状と未確定事項を整理しておく必要があります。
- 業務とシステム：業務フロー、既存システムの依存関係、移行データのまとめ
- 負荷と利用者：ピーク時の負荷と利用者の整理
- 法令・監査：法令や監査要件の記録
未確定の項目は無理に決めず、候補案と確認方法を示しておくと、提案各社が同じ前提で見積もれます。
業務単位の現状と目標状態
受注から出荷、請求までを工程ごとに分け、各工程で使うERP、販売管理、WMS、会計、認証基盤を対応づけます。さらに、変更が多い領域や障害が全社に波及する領域、データを保有する責任部署も記録します。
在庫引当だけを高頻度に変更するなら、在庫サービスが候補になります。ただし、在庫と請求を同じ取引境界で必ず更新する場合は、分離による整合性リスクを先に検討します。
可用性・性能・セキュリティの数値要件
「高性能」「安全」「止まらない」といった表現は、会社ごとに解釈が変わります。そのため、測定できる要件に置き換えて決めておきます。
- 稼働と復旧：稼働率、許容停止時間、目標復旧時間の数値
- 性能と記録：ピーク時のリクエスト数、応答時間、ログ保存期間、監査ログの対象
- バックアップ：復旧ポイントの設定
個人情報を扱う場合は、開発環境への持ち出しやアクセス権、国外での取扱い、再委託の承認、インシデント報告の時間も条件に含めておきます。
移行と運用の責任分界
段階移行では、データ同期や二重更新の防止、並行稼働、切り戻しの条件、旧システムの停止時期を先に決めておく必要があります。
稼働後は、クラウド設定の変更や脆弱性対応、アラートの一次受け、オンコール、障害時の指揮命令について、誰が担うかを明確にします。
自社で監視を運用できないと、分割した基盤で障害の切り分けが難しくなります。そのため、運用訓練と引き継ぎ資料も成果物に含めておきます。
一括委託・段階委託・クラウド併用の発注形態
発注形態は、社内の技術者数、移行の難しさ、納期、内製化の意向によって、案件ごとに選び分けます。
全領域を固定価格で外注すると、境界や非機能要件が変わったときに、その変更が見積もりに反映されにくくなります。
調査だけを長く続けても、業務成果は見えてきません。そこで、不確実性を減らす段階と、本番の責任を負う段階を分ける方法が現実的です。
責任の所在を一本化したい企業向けの一括委託
SIerや開発会社に、構想からドメイン分割、クラウド設計、アプリ開発、データ移行、運用設計までを任せる形です。社内に統括できる人材が少ない場合や、基幹システムを止められない場合には、窓口を一本化できます。
ただし、提案会社の標準構成が自社の要件に合うとは限りません。そのため、設計書、IaC、ソースコード、テスト結果、運用手順、アカウントの所有者を、契約前に決めておく必要があります。
クラウドを選び、パートナーを分ける方式
AWS、Google Cloud、Azureなどのクラウドを選び、公式サービスや認定パートナー、業務アプリの開発会社を組み合わせる方式です。社内標準がある企業や、将来の内製化を重視する企業に向いています。実行環境は、運用人員と可用性要件で比べます。
- Kubernetes系：EKS・GKE・AKSなどの候補
- マネージド環境：Fargate・Cloud Run・Container Appsなどの候補
クラウドベンダーは実行基盤を提供します。ただし、業務要件やサービス境界、移行、運用設計まで自動的に担うわけではありません。
PoCと段階発注による不確実性の削減
境界やデータ整合性、ピーク負荷、監視負担が読めない場合には、1業務だけを対象にスパイクやPoCを行います。その際は、動作確認だけで評価を終えないことが大切です。
- 時間：デプロイと障害検知・原因特定にかかる時間
- 復旧：データ不整合が起きたときの復旧方法
- 運用と費用：サービス追加時の工数とクラウド費の実測値
PoCの結果を次のRFPに反映し、本番基盤、移行、追加サービスを段階的に発注すると、過大な初期投資を避けられます。
RFPと要件整理で発注先に伝えるべき内容
RFPは、技術用語を並べるより、発注側の業務成果と各社が守る前提をそろえて示す資料です。
機能一覧に加えて、分割方針、データ所有者、API契約を示すと、提案の違いが見えてきます。イベント、デプロイ、監視、障害対応まで含めて初めて、提案を比べられます。
RFPに記載する目的・対象範囲・成果物
RFPには、背景と経営課題、対象業務、現行構成を記載します。さらに、目標KPI、移行対象、利用者と権限も記載します。
- 要件と計画：非機能要件、希望スケジュール、予算の考え方
- 納品と保守：納品物と保守範囲
サービス数は確定値ではなく候補として示します。そのうえで、提案側には境界と採用理由を説明してもらいます。
設計書、API仕様、データモデル、IaC、CI/CD定義を納品候補に加えます。テスト計画、監視ダッシュボード、障害手順、教育資料も候補に含めると、価格だけの比較を避けられます。
APIとデータ契約の責任者
APIとイベントの契約を定めるとともに、サービスごとにデータ所有者を置きます。
- API：認証、入力検証、エラー形式、タイムアウト、リトライ、互換性、バージョン管理の定義
- イベント：重複配信、順序変更、遅延、再処理、失敗時の隔離の取り決め
- データ：別サービスからのDB直接アクセスの禁止と、例外の期限、代替API、監査方法の記録
価格以外を含む提案書の評価項目
配点を事前に決めるとともに、価格以外の評価軸もそろえておくと、提案を比べやすくなります。
- 技術と業務：業務理解、分割・移行の妥当性、可用性、性能、セキュリティ
- 体制と成果物：運用体制、内製化支援、類似実績、納品物、再委託
- 価格：責任範囲と前提をそろえた比較
プレゼンでは、設計のトレードオフを問います。Kubernetesを採用するかどうかより、実行環境が要件と運用体制に合う理由や、障害時に誰が何分以内に判断するかを聞きます。
フェーズごとの契約形態と責任分界
初期の仮説は、設計や検証の中で変わりやすい領域です。そのため、「一式」契約では、仕様変更やクラウド費、障害対応、移行データ品質の責任が曖昧になります。
企画・アセスメントやPoC、基本設計の段階では、契約形態と受け入れ基準を分けて定めます。開発、移行、運用の段階も、工程ごとに分けておきます。
工程に合わせた請負契約と準委任契約の使い分け
請負契約は、合意した成果物の完成と検収を重視します。要件と受け入れ条件が固まった機能や基盤構築が対象で、前提が変わるときには手続きが必要です。
準委任契約は、専門家の作業や助言を一定期間依頼する形で、アセスメントやPoC、アーキテクチャ検討、内製チーム支援に適しています。
リサーチノートでは、請負は仕様変更のリスクが見積もりに反映され、準委任より1.3〜1.5倍程度高くなる傾向とされています。ただし、これは一般的な目安で、責任範囲や難易度によって変動します。
契約に落とし込む検収・変更管理・障害対応
検収では、画面の動作に加えて、負荷試験、障害注入、復旧訓練を確認します。さらに、脆弱性検査、ログ・トレース、バックアップ復元も見ます。
仕様変更の追加費用と納期を誰が承認するか、軽微な変更をどこまで含むかを、契約で決めておきます。
稼働後の対応は、一次対応や原因分析、暫定復旧、恒久対策、再発防止報告ごとに期限と担当を分け、SLAやSLOと結びつけます。
個人情報・再委託・国外移転の条項
個人データを扱う委託元には、委託先を監督する責任があります。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」が示す内容は、次の項目で確認します（2026年確認）。
- 委託先の安全管理：措置が委託元の求める水準と同等かどうかの事前確認
- 再委託の管理：相手方、業務内容、個人データの扱いの報告または承認、必要に応じた監査
- 契約・運用の確認：秘密保持、目的外利用の禁止、アクセス権、ログ、漏えい報告、返却・消去、国外拠点やクラウドの利用地域
契約条項に加えて、これらの確認事項を運用手順にも反映します。
マイクロサービス基盤の費用相場とコストの内訳
日本市場には、統一された標準価格表がありません。そのため、以下に示すのは、リサーチノートの2025〜2026年のクラウド公式料金、業務システム開発単価、公開情報から組み立てた推定レンジです。
金額は、サービス数だけでなく、可用性や既存連携、データ移行、監査、運用体制によっても変わります。レンジは予算計画に使い、正式な見積もりでは費目を分けてもらいます。
規模別の初期開発・移行費の推定レンジ
小規模から大規模まで、サービス数や構成ごとの初期費用と期間を示します。いずれも要件に基づく概算で、市場統計ではありません。
- PoC・小規模新規：3〜5サービス、マネージドPaaS、CI/CD、基本監視の構成で、500万〜1,500万円、1〜3か月
- 小〜中規模本番：5〜15サービス、API管理、RDB、非同期処理、検証・本番環境の構成で、1,500万〜4,000万円、3〜6か月
- 大規模案件：15〜50サービス、複数AZ、サービス別DB、DR、厳格な監査、基幹移行を含み、5,000万〜2億円超、9〜18か月となる可能性があります
人月で検算すると、エンジニア4〜6人を4〜6か月配置し、月単価を80万〜120万円と置いた場合の人件費は、約1,280万〜4,320万円です。このほか、PM、アーキテクト、QAが加わります。さらに、セキュリティレビュー、クラウド設定、移行、教育、予備費も加わります（出典: リサーチノートの業務システム開発単価整理、2026年）。
クラウド費・保守費・SRE費の内訳
ランニングコストは、コンテナのCPUやメモリ以外の基盤費と運用費まで含めて考えます。
- 実行・通信：実行環境、ロードバランサー、パブリックIPv4、データ転送
- データ・監視：DB、ストレージ、ログ、監視、バックアップ、脆弱性スキャン
- 運用人員：保守要員の費用の合算
小〜中規模本番は月30万〜150万円、大規模で冗長化やDR、監査、24時間対応を含む場合は月150万〜800万円超が推定レンジです。トラフィックと体制によって変わります。
AWSの公式料金では、標準サポート中のAmazon EKSクラスターは0.10米ドル／時間です。720時間換算で約72米ドルですが、EC2、EBS、ロードバランサーは別途かかります。IPv4、ログ、DB、AZ間通信も、同様に別途かかります（出典: AWS「Amazon EKSの料金」、2026年確認）。
Google CloudのCloud Runは、リソース使用量を100ミリ秒単位で課金します。同一リージョン内のGoogle Cloudリソースへのデータ転送は無料とされています。ただし、費用はネットワーク、VPC接続、DB、ログを含む総額で判断します（出典: Google Cloud「Cloud Run pricing」、2026年確認）。
検証環境と本番環境のコスト管理
検証環境では、夜間停止や短いログ保存、最小限のレプリカ、従量課金型の実行環境を検討します。一方で、本番は可用性や復旧時間を優先し、単純に安価な構成へは寄せません。
月次では、サービス別のクラウド費、リクエスト単価、ログ量、データ転送、未使用リソース、障害対応時間を確認します。FinOps担当者と開発・運用チームが、同じ数字を見ます。
サービス数が増えたこと自体は成果とせず、売上や業務時間、障害影響の削減を、費用と並べて評価します。
マイクロサービス基盤の委託先を選ぶポイント
適合性は、業務分割やデータ整合性、移行、障害対応、セキュリティ、運用引き継ぎを一つの設計として扱えるかで判断します。知名度やクラウド認定資格は、その判断を補う材料にとどまります。
SIer、クラウドベンダー、専門開発会社は、それぞれ役割が異なります。そのため、同じ評価表で責任範囲と成果物を確認します。
成果物単位で見る類似業務の実績
「導入した」という事例に加えて、分割対象や移行順、実行基盤、改善指標を確かめます。販売、在庫、顧客、請求など自社に近い事例を求め、可能であればアーキテクトや運用責任者に質問します。公開事例に数値がなくても、境界設計やデータ同期、切り戻し、障害対応を聞くことで、提案の再現性を判断できます。
開発力と運用力の分けた評価
開発と運用の経験は分けて確認します。Kubernetesについては、構築後の保守まで担えるかを質問します。
- 開発：API設計、コンテナ、IaC、CI/CD、データ移行、テスト自動化の経験
- 運用：SLO、分散トレーシング、ログ相関、アラート、オンコール、障害訓練、ポストモーテムの経験
- Kubernetes管理：アップグレード、権限、費用、脆弱性対応までの責任範囲
CNCFの2025年調査では、コンテナ利用者の82％が本番でKubernetesを利用しています（出典: CNCF「2025 Annual Cloud Native Survey」、2026年1月）。そのうえで、普及率だけで採用するのではなく、自社の運用能力と合わせて判断します。
セキュリティと引き継ぎの証跡
APIには複数のセキュリティリスクがあり、OWASP API Security Top 10 2023は、その具体例として次を扱っています（出典: OWASP API Security Top 10 2023、2026年確認）。
- 認可・公開：オブジェクト単位の認可不備や、過剰なデータ公開
- 業務フロー：機微な業務の流れへの無制限アクセス
- 接続と制限：SSRF、リソース消費の制限不足、安全でない第三者API利用
提案の段階では、脆弱性診断やAPIごとの権限テスト、シークレット管理、イメージスキャン、監査ログ、発見後の修正期限を確認します。
契約終了や委託先の変更に備えて、引き継ぐ資産の所有者を決めておきます。対象は、設計書、リポジトリ、パイプライン、TerraformなどのIaC、監視設定、クラウドアカウント、ドメイン、証明書、移行スクリプトです。受託会社の個人アカウントや特定ベンダーだけが管理する設定に頼ると、引き継ぎ費用と停止リスクが高まります。
見積書を比較するときのチェックポイント
合計金額を見る前に、各社が同じ範囲を見積もっているかを確かめます。条件が違う金額を横に並べても、比較にはなりません。
- 規模と環境：サービス数、環境数、リージョンの前提
- 可用性と移行：可用性、移行データ量、テストの種類の前提
- 運用とクラウド：運用時間、監視期間、クラウド費の前提
そのため、各社に共通の見積フォーマットを渡し、含むもの、含まないもの、前提、リスク、追加単価を分けて記載してもらいます。
開発・基盤・移行・運用の費目の分け方
費目をそろえておくと、会社ごとの計上先の違いを調整しやすくなります。
- 設計・開発：要件整理、アーキテクチャ、業務サービス
- 基盤・品質：API・認証、コンテナ、CI/CD・IaC、監視・ログ・トレース、セキュリティ、テスト
- 移行・運用：データ連携・移行、教育、保守
クラウド初期設定費、月額従量費、24時間対応、追加サービス単価は、別欄に分けます。そうすると、A社が開発費に含めた監視をB社が保守費に計上するといった差も調整できます。
見積もりの根拠と増額条件
見積もりの前提や不確実性を質問して、増額条件を把握します。
- 規模・期間：サービス数と期間の根拠
- 不確実性：検証すべき工程と、精度向上に必要な確認
- 移行・運用：移行失敗時の復旧担当と、月額に含む対応時間
- クラウド費：算定に使った負荷とログ量
曖昧な回答は、見積もりが安くても追加費用につながるおそれがあります。前提やリスク、代替案を示し、PoC後に本番費用を更新できる会社であれば、透明性があると評価できます。
避けたい提案と発注後のリスク
「必ず高速化する」「Kubernetesなら将来安心」のように、結論だけを示す提案には注意します。
- 境界・データ：業務責任と境界が一致せず、共有DBを残したまま分割する計画
- 通信・可観測性：全サービスを同期APIでつなぎ、ログやトレースを設けない計画
- 復旧・費用：切り戻し手順やクラウド利用料を含めない計画
契約前には、モジュラーモノリスやマネージドPaaSも比べ、採用しない理由を記録しておきます。発注後は、設計レビュー、リスク台帳、月次費用レビュー、障害訓練、セキュリティレビューを定例で行います。
投資効果は、技術の新しさよりも、変更を安全かつ迅速に届けられるか、障害影響を限定できるか、運用チームが継続できるかで測ります。
よくある質問（FAQ）
発注担当者からよく寄せられる疑問を取り上げます。
費用や技術の選択に加えて、内製化、既存システムとの連携、運用責任まで確認してください。
マイクロサービス基盤の発注費用はどのくらいですか？
推定レンジは、PoC・小規模新規が500万〜1,500万円、小〜中規模本番が1,500万〜4,000万円です。
大規模業務基盤は、初期開発・移行費として5,000万〜2億円超が目安です。これは市場統計ではなく、サービス数、移行、可用性、監査、運用体制を前提にした概算です。
正式な見積もりでは、開発、移行、基盤、保守、クラウド従量費を分けて確認します。
Kubernetesを使える会社に発注すれば安心ですか？
いいえ。Kubernetesの経験があるだけでは足りず、チーム数や可用性、負荷変動、ポータビリティ、運用人員に合うかを確認します。
Cloud Run、Fargate、Container Appsなども比べます。採用するなら、アップグレード、権限、監視、費用、障害対応の担当まで提案に含めてもらいます。
既存のモノリスやERPを止めずに外注できますか？
可能ですが、段階移行が前提になります。既存システムの外側にAPIを置き、変更頻度の高い領域から切り出していく、ストラングラーパターンを使います。
データ同期や並行稼働、切り戻し、業務部門の受け入れも工程に含めます。また、旧システムと新サービスが同じデータを更新する期間を短くします。そのうえで、復旧訓練を終えてから本番を切り替えます。
発注後に自社で運用するために何を準備すべきですか？
サービス責任者、クラウド管理者、セキュリティ担当、業務オーナーを置き、運用上の役割を決めます。
- 運用基準：SLO、アラートの受け方、障害時の連絡先
- 変更・費用：変更承認と費用確認の役割
- 引き継ぎ：設計書、ダッシュボード、アラート一覧、復旧手順、演習記録、ソースコード、IaC、教育の依頼
運用を外注し続ける場合も、責任分界と月額に含まれる対応時間を文書に残します。
まとめ
発注では、変更頻度や障害影響、データ責任者、運用能力を起点に委託範囲を決めます。技術名やサービス数は、その後に検討します。
RFPには、現状や目標、非機能要件を盛り込みます。API・データ契約、移行、運用、セキュリティ、成果物も、あわせて示します。こうして、各社が同じ前提で見積もれる状態をつくります。
最初の一歩は現状整理と小さな検証
発注に進む前に、費用の目安と検証の進め方を整理します。
- 初期費用：PoC・小規模は500万〜1,500万円、小〜中規模本番は1,500万〜4,000万円、大規模基盤は5,000万〜2億円超
- TCO：クラウド費、保守、SRE、移行、監査を含めた比較
- 小さく検証：全機能を最初から分割せず、1業務領域で境界、データ整合性、デプロイ、監視、復旧を検証すること
- 本番へ反映：検証結果を本番発注に反映する進め方が安全です
技術力と運用責任をあわせた委託先の選び方
類似業務の実績や境界・移行の説明、APIセキュリティを比べます。さらに、障害対応や再委託管理、費用内訳、成果物の所有権、内製化支援も確認します。
見積金額だけでなく、自社で運用できるか、障害時に責任者が動けるか、契約終了時に別会社へ移行できるかを確かめて契約します。
▼全体ガイドの記事
・マイクロサービス基盤開発の完全ガイド
▼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を創業。