マイクロサービス基盤開発の発注/外注/依頼/委託方法について

マイクロサービス基盤の発注・外注では、サービス数を増やすことではなく、変更単位・障害単位・責任単位を明確にして、開発と運用を継続できる土台を委託することが成功の条件です。

既存のモノリスを分割したい企業や、新しい業務システムを複数チームで開発したい企業に向けて、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の選定、見積書の比較方法を解説します。マイクロサービスが自社に適しているかを判断する視点や、ERP・販売管理・WMSなどの既存システムを止めずに移行するための確認事項も扱います。

▼全体ガイドの記事
・マイクロサービス基盤開発の完全ガイド

マイクロサービス基盤とは何ですか？発注する価値はどう判断しますか？

マイクロサービス基盤は、受注、顧客、商品、在庫、請求などの業務領域を独立したサービスとして開発・配備・拡張するための共通環境です。APIゲートウェイ、認証・認可、コンテナ実行基盤、サービス間通信、データ管理、CI/CD、監視、障害対応、セキュリティまでを一体で設計する点が、単にアプリケーションを複数のコンテナに分ける作業と異なります。

発注時は「マイクロサービスを作ってください」とだけ伝えず、どこまでを共通基盤に含めるかを区切ります。たとえば、APIの入口、認証、サービス間のタイムアウトとリトライ、メッセージキュー、サービスごとのデータ所有権、デプロイパイプライン、集中ログ、メトリクス、分散トレーシング、シークレット管理を基盤の成果物として定義します。一方、業務ルールや画面、既存ERPとのデータ連携は、個別サービスや移行工程として別に見積もると比較しやすくなります。

複数の開発チームが並行してリリースする、機能ごとに変更頻度が大きく異なる、アクセスが急増する領域だけを個別に拡張したい、といった企業では、マイクロサービスの効果が出やすくなります。反対に、少人数で運用する単純なCRUD業務、変更が少ない社内システム、分割してもチームや責任者が増えない案件では、モジュラーモノリスやマネージドPaaSの方が適する場合があります。発注前に、導入目的を「サービス数」ではなく、リリース頻度、障害の影響範囲、復旧時間、チームの自律性などの業務指標で置き換えることが重要です。

発注前に整理すべき業務要件と非機能要件

見積もりの差は、技術の優劣よりも前提条件の違いから生まれます。RFPを作る前に、現在の業務フロー、既存システムの依存関係、移行対象データ、ピーク時の負荷、利用者、法令・監査要件を一枚にまとめます。未確定な項目は無理に決めず、候補案と確認方法を示しておくと、提案各社が同じ前提で見積もりを出せます。

まず、受注から出荷、請求までの業務を流れに沿って分解し、各工程で使うERP、販売管理、WMS、会計、認証基盤を対応づけます。そのうえで、変更が多い領域、障害が全社に波及する領域、データを保有する責任部署を記録します。たとえば在庫引当だけを高頻度に変更するなら、在庫サービスを候補にできますが、在庫と請求を同じ取引境界で必ず更新しなければならない場合は、分離による整合性リスクを先に検討します。

非機能要件は「高性能」「安全」「止まらない」と書くだけでは、会社ごとに解釈が変わります。稼働率、許容停止時間、目標復旧時間、ピーク時のリクエスト数、応答時間、ログ保存期間、バックアップの復旧ポイント、監査ログの対象を決めます。個人情報を扱うなら、開発環境への持ち出し可否、アクセス権限、国外での取扱い、再委託の承認、インシデントの報告時間も発注条件に含めます。

既存システムを段階移行する場合は、データ同期、二重更新の防止、並行稼働、切り戻し条件、旧システムの停止時期を要件にします。稼働後についても、クラウドの設定変更、脆弱性対応、アラートの一次受け、オンコール、障害時の指揮命令を明確にします。開発会社が作った監視を自社が運用できないと、基盤を分割した分だけ障害の切り分けが難しくなるため、運用訓練と引き継ぎ資料も成果物として扱います。

発注形態は一括委託・段階委託・クラウド併用から選びます

発注形態に正解はなく、社内の技術者数、移行の難しさ、納期、運用を内製化する意向で変わります。最初から全領域を固定価格で外注すると、サービス境界や非機能要件の変更が見積もりに反映されにくくなります。逆に、調査だけを長く続けると業務成果が見えません。基盤の不確実性を減らすフェーズと、本番の責任を負うフェーズを分ける考え方が現実的です。

SIerや開発会社に、構想、ドメイン分割、クラウド設計、アプリ開発、データ移行、運用設計まで任せる方式です。社内にプロジェクトを束ねる人材が少ない場合や、基幹システムを止められない場合は、窓口を一本化できる利点があります。ただし、提案会社の標準構成が自社の要件に合うとは限りません。設計書、IaC、ソースコード、テスト結果、運用手順、アカウントの所有権を誰が持つかを契約前に確認します。

AWS、Google Cloud、Azureなどの実行基盤を選び、クラウドの公式サービスや認定パートナーと、業務アプリの開発会社を組み合わせる方式です。既に社内でクラウド標準がある企業や、将来の内製化を重視する企業に向きます。EKS・GKE・AKSのようなKubernetes系、Fargate・Cloud Run・Container Appsのようなマネージド実行環境を、運用可能な人員と可用性要件で比較します。クラウドベンダーは実行基盤を提供しますが、業務要件の整理、サービス境界、移行、運用設計を自動的に担うわけではありません。

サービス境界、データ整合性、ピーク負荷、監視の負担が読めない場合は、最初に1業務だけを対象にスパイクやPoCを実施します。PoCの評価項目は、動いたかどうかだけでは足りません。デプロイに要する時間、障害を検知して原因を特定する時間、データ不整合時の復旧方法、1サービス追加時の運用工数、クラウド費の実測値を記録します。結果を次のRFPに反映して、本番基盤、移行、追加サービスを段階的に発注すると、過大な初期投資を避けられます。

RFPと要件整理で発注先に伝えるべき内容

RFPは技術用語を並べる資料ではなく、発注側が達成したい業務成果と、提案各社が守るべき前提をそろえる資料です。マイクロサービス基盤では、アプリ機能の一覧だけでなく、分割方針、データの所有者、API契約、イベントの扱い、デプロイ方式、監視と障害対応まで含めて初めて提案を比較できます。

記載する順番は、背景と経営課題、対象業務、現行構成、目標KPI、移行対象、利用者と権限、非機能要件、希望スケジュール、予算の考え方、納品物、保守範囲が基本です。サービス数は確定値でなく候補として示し、提案側には「どの境界を採用し、その理由は何か」を説明してもらいます。設計書、API仕様、データモデル、IaC、CI/CD定義、テスト計画、監視ダッシュボード、障害対応手順、教育資料を納品物の候補にしておくと、価格だけの比較になりません。

サービス間のAPIでは、認証方式、入力値の検証、エラー形式、タイムアウト、リトライ、後方互換性、バージョン管理を定義します。イベント連携では、重複配信、順序の入れ替わり、遅延、再処理、失敗時の隔離を決めます。データはサービスごとの所有者を置き、別サービスがデータベースへ直接アクセスしない原則をRFPに書きます。例外を認めるなら、期限、代替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、サービス別データベース、災害復旧、厳格な監査、既存基幹からの移行まで行う大規模案件では、5,000万〜2億円超、9〜18か月程度になる可能性があります。いずれも市場統計ではなく、要件に基づく概算です。

人月で検算すると、エンジニア4〜6人を4〜6か月配置した場合、エンジニア単価を月80万〜120万円と置くと、人件費だけで約1,280万〜4,320万円になります。ここにPM、アーキテクト、QA、セキュリティレビュー、クラウド設定、移行、教育、予備費が加わります（出典: リサーチノートの業務システム開発単価整理、2026年）。単価や期間を一つの数字で断定せず、体制、期間、成果物の前提を同時に比較します。

ランニングコストは、コンテナのCPUとメモリだけではありません。実行環境、データベース、ストレージ、ロードバランサー、パブリックIPv4、データ転送、ログ保存、監視、バックアップ、脆弱性スキャン、保守要員を合計します。小〜中規模本番では月30万〜150万円、大規模で冗長化、DR、監査、24時間対応を含める場合は月150万〜800万円超という推定レンジがありますが、トラフィックと運用体制によって変動します。

AWSの公式料金では、標準サポート中のAmazon EKSクラスター料金が0.10米ドル／時間で、720時間換算では約72米ドルです。ただし、EC2やEBS、ロードバランサー、IPv4、ログ、データベース、AZ間通信などが別途発生します（出典: AWS「Amazon EKSの料金」、2026年確認）。Google CloudのCloud Runはリソース使用量を100ミリ秒単位で課金し、同一リージョン内のGoogle Cloudリソースへのデータ転送は無料とされていますが、ネットワーク、VPC接続、DB、ログなどを含めた総額で判断します（出典: Google Cloud「Cloud Run pricing」、2026年確認）。

検証環境は夜間停止、短いログ保存、必要最小限のレプリカ数、従量課金型の実行環境を検討します。本番では可用性や復旧時間を優先し、安価な構成へ単純に寄せないことが大切です。月次ではサービス別のクラウド費、リクエスト単価、ログ量、データ転送量、未使用リソース、障害対応時間を確認し、FinOpsの担当者と開発・運用チームが同じ数字を見る状態を作ります。サービスを増やすこと自体を成果にせず、売上や業務時間、障害影響の削減と費用を並べて評価します。

マイクロサービス基盤の委託先を選ぶポイント

会社の知名度やクラウドの認定資格だけでは、発注先の適合性を判断できません。マイクロサービスでは、業務の分割、データ整合性、移行、障害対応、セキュリティ、運用引き継ぎを一つの設計として扱えるかが重要です。SIer、クラウドベンダー、専門開発会社は役割が異なるため、同じ評価表で責任範囲と成果物を確認します。

実績紹介では、単に「マイクロサービスを導入した」と書かれた事例ではなく、何を分割し、どの順番で移行し、どの実行基盤を使い、どの指標が改善したかを確認します。販売、在庫、顧客、請求など自社に近い業務の事例を依頼し、可能なら担当アーキテクトや運用責任者に質問します。公開事例に数値がない場合も、サービス境界の考え方、データ同期、切り戻し、障害対応の実態を聞くことで、提案の再現性を見極められます。

開発工程では、API設計、コンテナ、IaC、CI/CD、データ移行、テスト自動化の経験を確認します。運用工程では、SLOの設計、分散トレーシング、ログ相関、アラートの優先度、オンコール、障害訓練、ポストモーテムの運用を確認します。Kubernetesを使える会社でも、クラスタを作って終わりではなく、アップグレード、権限管理、コスト管理、脆弱性対応まで責任を持てるかを質問します。CNCFの2025年調査では、コンテナ利用者の82％が本番環境でKubernetesを利用していると報告されています（出典: CNCF「2025 Annual Cloud Native Survey」、2026年1月）。普及率だけを理由に採用せず、自社の運用能力と合わせて判断します。

APIはサービスをつなぐ入口である一方、認可不備、過剰なデータ公開、リソース消費の制限不足、第三者APIの安全でない利用などのリスクを抱えます。OWASP API Security Top 10 2023では、オブジェクト単位の認可不備や、機微な業務フローへの無制限アクセス、SSRFなどが扱われています（出典: OWASP API Security Top 10 2023、2026年確認）。提案時は、脆弱性診断の範囲、APIごとの権限テスト、シークレット管理、イメージスキャン、監査ログ、脆弱性発見後の修正期限を確認します。

また、契約終了や委託先変更に備えて、設計書、リポジトリ、パイプライン、TerraformなどのIaC、監視設定、クラウドアカウント、ドメイン、証明書、データ移行スクリプトを誰が保有するかを決めます。受託会社の個人アカウントや特定ベンダーだけが管理できる設定に依存すると、引き継ぎ費用と停止リスクが高まります。

見積書を比較するときのチェックポイント

見積比較では、合計金額の安さより、同じ範囲を見積もっているかを最初に確認します。サービスの数、環境数、リージョン、可用性、移行データ量、テストの種類、運用時間、監視期間、クラウド費の前提が違えば、金額を横に並べても意味がありません。提案各社に同じ見積フォーマットを渡し、含むもの、含まないもの、前提、リスク、追加単価を分けて記載してもらいます。

見積書は、要件整理・アーキテクチャ設計、業務サービス開発、APIゲートウェイと認証、コンテナ実行基盤、CI/CDとIaC、監視・ログ・トレース、セキュリティ、データ連携・移行、テスト、教育、保守に分けます。さらに、クラウド初期設定費と月額従量費、24時間対応の有無、追加サービス単価を別欄にします。これにより、A社が開発費に含めた監視をB社が保守費に計上しているといった差を調整できます。

「このサービス数と期間にした理由は何ですか」「どの工程が不確実で、何を検証すれば精度が上がりますか」「データ移行の失敗時に誰が復旧しますか」「クラウド費はどの負荷とログ量で算定していますか」「運用開始後の月額に何時間の対応が含まれますか」と質問します。回答が曖昧な会社は、安い見積もりでも後から追加費用が発生する可能性があります。逆に、前提、リスク、代替案を明示し、PoCの結果で本番費用を更新できる会社は、見積もりの透明性が高いと評価できます。

「マイクロサービスにすれば必ず高速化する」「Kubernetesを採用すれば将来安心」といった結論だけを示す提案には注意が必要です。サービス境界が業務責任と一致していない、共有データベースを残したまま分割する、すべてのサービスを同期APIでつなぐ、ログやトレースがない、切り戻し手順がない、クラウド利用料を含めない、といった計画は、稼働後の負担を見えにくくします。

契約前には、代替案としてモジュラーモノリスやマネージドPaaSを比較し、採用しない理由も記録します。発注後は、設計レビュー、リスク台帳、月次の費用レビュー、障害訓練、セキュリティレビューを定例化します。技術の新しさではなく、業務の変更を安全に早く届け、障害の影響を限定し、運用チームが継続できるかで投資効果を測定します。

よくある質問（FAQ）

最後に、発注担当者から特に多い疑問を整理します。費用や技術選択だけでなく、内製化、既存システムとの連携、運用責任まで含めて回答を確認してください。

推定レンジでは、PoC・小規模新規で500万〜1,500万円、小〜中規模本番で1,500万〜4,000万円、大規模業務基盤で5,000万〜2億円超が初期開発・移行費の目安です。これは市場統計ではなく、サービス数、移行、可用性、監査、運用体制を前提にした概算です。正式見積もりでは、開発費、移行費、基盤費、保守費、クラウド従量費を分けて確認します。

いいえ、Kubernetesの経験だけでは十分ではありません。自社のチーム数、可用性、負荷変動、ポータビリティ、運用人員に合うかを確認し、Cloud RunやFargate、Container Appsなどのマネージド実行環境も比較します。採用する場合も、アップグレード、権限、監視、費用、障害対応を誰が担うかまで提案に含めてもらうことが重要です。

可能ですが、段階移行の計画が必要です。既存システムの外側にAPIを置き、変更頻度の高い領域から切り出すストラングラーパターンを使い、データ同期、並行稼働、切り戻し、業務部門の受け入れを工程に含めます。移行中に旧システムと新サービスが同じデータを更新する期間を短くし、復旧訓練を終えてから本番切り替えを行います。

サービス責任者、クラウド管理者、セキュリティ担当、業務側のオーナーを置き、SLO、アラートの受け方、障害時の連絡先、変更承認、費用確認の役割を決めます。発注先には、設計書だけでなく、ダッシュボード、アラート一覧、復旧手順、演習記録、ソースコードとIaCの引き渡し、教育を依頼します。運用を外注し続ける場合も、責任分界と月額に含まれる対応時間を明文化します。

まとめ

マイクロサービス基盤の発注では、技術名やサービス数から入らず、変更頻度、障害影響、データの責任者、運用能力を起点に委託範囲を決めます。RFPでは現状、目標、非機能要件、APIとデータ契約、移行、運用、セキュリティ、成果物をそろえ、提案各社が同じ前提で見積もれる状態を作ります。

費用は、PoC・小規模で500万〜1,500万円、小〜中規模本番で1,500万〜4,000万円、大規模基盤で5,000万〜2億円超という推定レンジを参考にしながら、クラウド利用料、保守、SRE、移行、監査を含むTCOで比較します。最初から全機能を分割するのではなく、1つの業務領域で境界、データ整合性、デプロイ、監視、復旧を検証し、その結果を本番発注に反映する進め方が安全です。

委託先を選ぶときは、類似業務の実績、サービス境界と移行の説明、APIセキュリティ、障害対応、再委託管理、費用の内訳、成果物の所有権、内製化支援を比較します。見積金額だけでなく、発注後に自社が運用できるか、障害時に責任者が動けるか、契約終了時に別会社へ移行できるかまで確認してから契約してください。

▼全体ガイドの記事
・マイクロサービス基盤開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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