マイクロサービスの発注は、業務の境界とデータの責任を整理することから始まります。RFPと契約を固めたうえで段階的に開発と移行を進めると、運用できる構成を選びやすくなります。
発注前の要件整理、契約と役割分担、費用相場、委託先の比較の順に見ていきます。
▼全体ガイドの記事
・マイクロサービスのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
マイクロサービスのシステムを発注・外注する前の全体像
マイクロサービスとは、受注や在庫などの業務機能を独立したサービスに分け、APIやイベントで連携させる構成のことです。
発注で成果を左右するのは、サービス数よりも、業務ごとの持ち主と、障害時に業務を続けるための条件を決めておくことです。
マイクロサービス化が向いている企業・向いていない企業
向き不向きは、業務の変更頻度とチーム体制、運用上の条件から判断します。
- 変更頻度が異なる業務：サービスごとに開発と拡張を分けられる
- 自律した複数チーム：API契約や監視を共通ルールでそろえて運用する
- 少人数の運用体制：機能追加が少なく、障害対応や常時監視が難しいなら、モジュラーモノリスやパッケージ、SaaSが安全な場合もある
たとえば、注文が急増する販売機能と、月次処理が中心の会計機能は、別々に拡張できます。
一方で、サービスを分けると、ネットワーク障害やデータ整合性への対応が増えます。また、分散ログとサービス間認証も、新たに扱う必要があります。そのため、技術の採用だけを発注の理由にせず、変更頻度と負荷の偏り、障害許容度、内製化の意思を発注前に確認しておきます。
パッケージ・クラウド・スクラッチの組み合わせ
発注形態は、業務ごとに組み合わせて決めます。すべてをオーダーメイドにするか、SaaSにするかの二択で考える必要はありません。
- 独自性の高い業務：受注体験や在庫最適化を、スクラッチで作る
- 標準業務：会計・勤怠・認証は、SaaSやパッケージでまかなう
- 新規事業：2〜3サービスのPoCや実用MVPから始める方法もある
実際には、標準業務のSaaSと独自機能のスクラッチをAPIで連携させる構成が現実的です。
PoCには、マネージドコンテナやサーバーレスも使えます。
クラウド基盤は、ECSやFargateなどのマネージドコンテナ、EKS・AKS・GKEなどのKubernetes、サーバーレスを比べます。
Kubernetesは標準化や大規模運用に向いています。ただし、更新やRBAC、ネットワーク、監視の専門性が必要です。
CNCFの「Annual Cloud Native Survey 2025」では、コンテナ利用者の本番環境におけるKubernetes利用率が82%と報告されています。
この数値は導入の成功を示すものではないため、自社の運用能力と委託先の支援範囲を合わせて考えます。
発注前にRFPと要件を整理する方法
見積の精度を上げるには、技術用語よりも、業務上の目的と制約をRFPで伝えることが大切です。
サービス数や製品を先に固定すると、モジュラーモノリスなど別案を提案しにくくなります。
RFPには、課題、対象業務、現行資産を記載します。
RFPには、達成指標、納期、予算の考え方も入れます。
業務境界とデータ所有者の決め方
要件整理では、業務の担当範囲を洗い出したうえで、データの所有者と整合性の条件を決めます。
- 業務を洗い出す：受注・商品・在庫・入出荷・請求・顧客を挙げ、責任部署・変更頻度・利用者・ピーク時間・外部連携・個人情報を記録する
- データ所有者を決める：正となるデータを持つサービスと、その更新権限を定める
- 整合性の制御を決める：決済の冪等性キー、再送の重複排除、Sagaなどの補償処理を要件化する
受注サービスに注文状態を、在庫サービスに引当可能数を持たせると、API設計や障害対応が安定します。
即時整合性が必要な処理と、数秒から数分の遅延を許容する処理を分けます。
不整合を手作業で直す前提のRFPでは、運用費とリスクを過小評価しやすいので、注意が必要です。
RFPに書く機能要件・非機能要件・移行条件
RFPでは、機能、非機能、移行の要件を分けて書くと、提案を比較しやすくなります。
- 機能要件：操作・APIデータ・業務ルール・外部連携・権限差
- 非機能要件：負荷（通常・ピーク）・応答・稼働・復旧時間・時点目標・バックアップ期間・監査・診断・個人情報の保管
- 移行条件：移行件数・停止可能時間・並行稼働・切り戻し・旧システムの終了時期
- 対象範囲：最初の対象と将来の候補範囲を分ける
「高性能」と書くより、平日12時台の毎分件数と95パーセンタイルの応答秒数を書くと、提案同士を比べられます。
APIファサードやストラングラーフィグを使うと、ビッグバン方式を避け、新旧のシステムを併存させられます。
PoCから本番へ移る判定基準
PoCの成功は、APIが動くかどうかだけでなく、業務、障害、開発の3つの面から判定します。
- 業務：担当者が実際の業務シナリオを最後まで通せる
- 障害：再送や切り戻しを行い、監視で原因を特定できる
- 開発：チームが安全にデプロイする体制がある
成果物には、実装コードのほか、API・イベント仕様、構成図を含めます。さらに、IaC、テスト結果、運用手順と残課題一覧も入れます。
本番移行の判定には、負荷試験と契約テスト、セキュリティ診断を含めます。
バックアップ復元と障害訓練も、判定の対象にします。
発注の時点で、PoCの期間と本番化の見積条件、本番化しない場合の成果物の扱いを、分けて合意しておきます。
契約形態と役割分担の決め方
要件が変わりやすい工程と、成果物を固定しやすい工程が混在しています。そのため、企画・要件定義、設計・開発、保守・運用それぞれの性質に合わせて、契約と、どこまでを誰が受け持つかを設計します。
工程ごとの準委任と請負の使い分け
工程がどれだけ不確かか、成果物がどこまで決まっているかに応じて、契約形態を使い分けます。
- 準委任：知見や作業を受け、要件整理や優先順位が変わる開発向け
- 請負：完成責任を定め、仕様と受入条件を決めやすい機能や移行向け
準委任では、作業時間と体制、役割を明確にします。さらに、会議体と成果物も決めておきます。
発注者側にも意思決定者が必要です。成果物の完成を無条件に約束するのではなく、進捗と品質を確認する仕組みを設けます。
分散トランザクションや非機能要件が曖昧なままだと、追加変更や受入拒否が起きやすくなります。そこで、要件定義は準委任、確定機能の実装は請負、運用監視は別契約とする組み合わせも比べます。
契約書の成果物・知的財産・運用分界
契約では、成果物と所有権、運用の分担を具体的に定めます。
- 成果物：コード、API・イベント定義、テスト、IaC、監視画面・設計書・手順書
- 所有と知財：アカウント・リポジトリ・イメージ・ログ・データ、再利用部品の利用条件
- 運用分界：一次切り分けと監視時間、通知、復旧目標、脆弱性対応、費用上限・追加単価
- 役割分担：委託先と自社の担当を、RACIのような表に記録する
再利用部品については、改修権、第三者への引き渡し、契約終了後の利用条件を確認します。
サービスが増えても、依存更新や証明書更新、ログ保管は続きます。さらに、バックアップ復元と災害復旧訓練も発生します。
契約に含める内製化支援と引き継ぎ
将来、内製化や複数ベンダー化を目指すなら、技術移転を契約に含めます。
- 開発支援：設計レビューやペア作業に参加する
- 運用訓練：運用当番や障害訓練を行う
- 知識共有：月次の共有会、コード・IaC説明会、手順書の更新
読めない構成図や、特定のベンダーしか扱えない環境は、移管時の負担になります。そのため、引き継ぎの完了は、説明会を開いた時点ではなく、自社の担当者がデプロイや原因調査、復元を実行できる状態で判断します。
開発会社には、技術力に加えて、標準化や文書化への姿勢を確認します。また、運用教育や、契約終了時の移管への姿勢も見ておきます。
マイクロサービスのシステムの費用相場とコストの内訳
マイクロサービスには、公的な標準価格表がほとんどありません。費用はサービス数だけでは決まらず、連携や移行、可用性などの条件で変わります。そこで、ピーク負荷やセキュリティ、運用時間、内製化を含む総保有コストで考えます。
ここで示すレンジは、リサーチノートの業務システム相場を基に、マイクロサービス固有の基盤・テスト・運用工数を組み合わせた編集用の推定です。
初期開発費の規模別レンジ
規模ごとの費用感をつかむため、初期費用の目安となるレンジを見ていきます。
- PoC・小規模MVP：500万〜1,200万円程度
- 実用MVP・部門導入：1,000万〜2,500万円程度
- 中規模業務システム：2,000万〜5,000万円程度
- 全社基幹の段階モダナイズ：5,000万〜1億5,000万円超
初期費用は、規模と含める機能や作業の範囲をそろえて比べます。
- PoC・小規模MVP：2〜3サービス、API、認証、簡易CI/CD、マネージドDB
- 実用MVP・部門導入：3〜8サービス、非同期処理、監視、権限、既存連携
- 中規模業務システム：8〜15サービス、基盤、イベント連携、移行、冗長化、運用設計
- 全社基幹の段階移行：15〜30以上のサービス、基幹連携、監査、SLA、複数リージョン
全社基幹の場合、期間は12〜24か月以上になる可能性があります。ただし、各レンジは公開された専用の相場ではありません。最終金額はRFPと設計後の見積で決まり、記載したレンジを超えることもあります。
人件費・基盤費・移行費の分け方
見積の内訳をそろえるため、費用は人員と開発作業、基盤、付随作業に分けて見ます。
- 人員：PM、アーキテクト、SE、プログラマー、テスター
- 開発作業：クラウド設計、アプリ実装、データ移行、テスト
- 付随作業：セキュリティ診断、ドキュメント、教育
リサーチノートの比較軸では、人月単価がおおむね50万〜200万円です。役割別に見ると、PMが90万〜150万円、SEが65万〜110万円です。プログラマーは50万〜90万円、テスターは45万〜80万円程度のレンジです。
単価に加えて、各役割の人数と期間、稼働率、成果物を確認します。
基盤費には、実行環境やDB、ロードバランサーを含みます。さらに、NATやメッセージング、監視、ログも入ります。WAFやバックアップ、サポート契約も、基盤費の対象です。
小規模のマネージドコンテナ・サーバーレスは月5万〜30万円程度という推定があります。一方で、常時稼働の複数サービスに監視やWAFを含める中規模構成は、月30万〜150万円程度の推定です。
通信量やログ量、リージョン、冗長化によって変わるため、上限アラートと利用量の前提を書面で確認します。
保守・運用費を初期開発費と分けた積算
一次Q&Aの整理では、保守費は初期開発費の年15〜25%程度とされていますが、全案件に共通するわけではありません。
必要な体制を比べるには、対応時間と対象作業を分けて確かめます。
- 対応時間：平日日中か、24時間365日の監視・障害対応か
- 対象作業：脆弱性対応や制度変更を保守に含むか
- 継続作業：依存更新・秘密情報更新・ログ・契約テスト・障害訓練・クラウド費最適化
- 総額比較：運用費・追加変更単価・夜間対応費・クラウドアカウント費を5年程度で試算
5年程度の計画で試算すると、提案どうしの総額の違いが見えてきます。初年度だけでなく、2年目以降のTCOも、発注前に比べておく必要があります。
委託先の選定と見積比較のポイント
委託先には、業務要件や移行、SLAまで説明できる力が必要です。セキュリティや運用、内製化についても説明できるかを確かめます。そのうえで、構成図よりも、障害対応や受入条件、追加費用、成果物の引渡しが具体的かを見ます。
業務と成果で見る実績
実績と自社の提案を照らし合わせ、業務条件と成果の測り方を確かめます。
- 実績の条件：業務境界・ピーク負荷・運用体制・改善内容を質問する
- 自社のKPI：リリース頻度・変更リードタイム・障害影響・平均復旧時間・夜間バッチ・クラウド費
AWSの導入事例では、ミスミグループ本社が、受注・発注・入出荷などの6業務グループ、約30アプリケーションのマイクロサービス層を構築したと説明されています。
同事例では、開発スピードを3倍に高め、オンライン受注確定の応答時間を44%減らしたと報告されています（出典: AWS「株式会社ミスミグループ本社」導入事例）。
報告された効果は、同社の規模と移行計画、チーム体制、クラウド活用を前提にした個別事例です。
提案では、導入前後で測れるKPIを示してもらいます。「拡張性が高い」「開発が速い」といった言葉だけでは、成果の判定方法が足りません。
同じ前提条件と内訳での相見積もり比較
各社の見積条件をそろえ、内訳と価格差の理由を確かめます。
- 共通前提：RFP・現行資料・ピーク負荷・SLA・移行範囲をそろえる
- 見積内訳：企画・設計・開発・移行・テスト・診断・教育・保守を分ける
- 不明点：「一式」と書かれた人数や期間、成果物、前提、除外事項、追加単価を具体的に示してもらう
- 価格差：試験・ログ・復元・診断・データ整備・切り戻し・休日対応を確認する
価格差が大きいときも、安い会社をすぐに選ばず、除外項目を確かめます。また、過剰なサービスメッシュやマルチリージョンは、業務効果と運用人材に見合うかを再検討します。
提案時に行う障害・セキュリティ・運用の質問
提案の場では、セキュリティ、可観測性、障害対応を、具体的な質問に分けて確かめます。
- アクセスと通信：ゲートウェイ後のサービス単位認可、mTLS等の保護、秘密情報をイメージやログに混ぜない
- ログと診断：分散トレース・構造化ログ・個人情報のマスキング・保存期間・通知先
- 障害時の動き：在庫照会、イベント二重配送、決済後の状態未更新への対応
- 復旧操作：遅延、タイムアウト、再送、部分停止、ロールバックの説明
OWASPの資料は、ゲートウェイ・サービス・業務コードの複数層で守る考え方を示しています（出典: OWASP「Microservices Security Cheat Sheet」）。
診断を再委託する場合は、品質管理や資格、実績も確かめます。
経済産業省は、2025年4月施行の「情報セキュリティサービス基準第4.1版」を公表しています（出典: 経済産業省「情報セキュリティサービス審査登録制度」）。
正常系だけでなく、障害時の動きまで説明できれば、実運用を理解している可能性が高まります。
よくある質問
費用や技術の選択は案件ごとに変わります。そのため、回答のレンジと判断条件をRFPに反映させるとよいでしょう。
マイクロサービスのシステム開発はどの会社に外注すればよいですか？
業務要件、基盤、移行からセキュリティ、運用、内製化まで、一つの計画で説明できる会社を選びます。クラウド認定や導入社数だけでなく、類似業務の実績と障害対応を見ます。さらに、成果物の引渡しや契約終了時の移管も確かめます。
マイクロサービスのシステムの費用は最低いくらですか？
2〜3サービスのPoC・小規模MVPは、リサーチノートに基づく編集用の推定で、500万〜1,200万円程度が検討の目安です。認証や既存連携を含めると、金額は変わります。移行や負荷試験、監視、診断まで含めると、さらに変わります。
本番化の追加作業と月額運用費まで含めて比べてください。
請負契約なら納期と品質を必ず保証してもらえますか？
請負は合意した成果物の完成を目的としますが、要件が曖昧なままだと、納期や品質の保証が難しくなります。そのため、探索的なPoCは準委任、仕様が確定したあとは請負とし、受入条件と変更管理、遅延時の扱いを決めます。
既存のモノリスをすべてマイクロサービスへ移行すべきですか？
移行の範囲は、業務ごとに切り出す部分と残す部分で決めます。すべてを移行する必要はありません。
- 切り出す業務：変更頻度が高く、事業効果を測定しやすく、既存システムとの境界を定義しやすい業務
- 残す領域：安定した低変更領域はモノリスやパッケージに残す判断も合理的
移行後の運用体制とデータ整合性を確かめたうえで、範囲を広げていきます。
まとめ
発注時は技術の選定から始めず、まず業務と変更頻度を整理します。そのうえで、データの所有や障害許容度、運用体制を見極めます。
方式を比べて、マイクロサービスにする範囲を絞ります。RFPには、要件や移行、PoCの判定基準をまとめます。
契約では、準委任と請負を使い分け、成果物と知的財産を明確にします。障害対応や追加変更、内製化支援の扱いも、あらかじめ決めておきます。
推定では、PoC・小規模MVPが500万〜1,200万円、中規模で2,000万〜5,000万円です。全社基幹の段階モダナイズは、5,000万〜1億5,000万円超です。条件が変われば、見積を取り直します。
初期費だけでなく、クラウドや監視、保守などを含めたTCOで比べます。ログやセキュリティ、教育、移行の費用も、保守・運用費の積算項目に沿って含めます。
委託先は、業務成果と障害復旧、セキュリティや運用体制、成果物の透明性で評価します。
RFPと比較条件をそろえておくと、見積の抜け漏れや将来の運用負担を把握でき、自社に合う発注先を選べます。
▼全体ガイドの記事
・マイクロサービスのシステム開発の完全ガイド
▼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を創業。