ハイブリッドクラウド開発の発注/外注/依頼/委託方法について

ハイブリッドクラウド開発の発注は、業務とデータの配置を決め、要件と責任範囲をそろえ、段階ごとに検証して移行する流れで進めます。

発注形態からRFP、契約、費用相場、委託先の選び方、発注後の進め方まで、発注側が押さえる点を順に並べます。全体像はハイブリッドクラウド開発の完全ガイドもご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

ハイブリッドクラウドの発注・外注の意味

ハイブリッドクラウドの発注・外注とは、複数の環境を業務基盤として構築・移行・運用してもらうことです。

対象にはオンプレミス、プライベートクラウド、パブリッククラウドがあります。

ネットワーク、ID、データ連携、監視、運用ルールも一体で設計します。そのため、サーバー購入とクラウド契約だけでは、安定運用はできません。

外注する業務の範囲

外注範囲は、社内に残す業務と専門会社に任せる業務に分けます。

先に分担を決めておくと、責任範囲と費用を説明しやすくなります。

現状調査：既存環境と業務の実態を把握する
設計・移行：配置、接続、ID、データを整える
アプリ改修：移行先に合わせてアプリを変更する
運用支援：監視、バックアップ、引き継ぎを担う

たとえば、基幹データの分類と業務の優先度は自社で決めておきます。また、SIerが接続設計や移行手順をつくり、自社が日々のアカウント申請を行うといった分担も可能です。

社内に24時間365日の監視要員や障害一次対応の要員を置けない場合は、運用込みのマネージドサービスを候補に入れます。

発注前に構成方針を決める理由

構成方針は発注前に決め、移行範囲と優先条件を委託先へ伝えておきます。前提を後からそろえると、見積もりや工期の組み直しが起きやすいためです。

環境の複雑さ：環境が増えると、通信経路、権限、データ同期、監視画面、契約先も増えます
一律移行のリスク：既存ライセンスや低遅延要件を見落とすと、追加工事が起きることがあります
優先事項：事業継続、データ主権、ピーク対応、開発速度、レガシー共存の中から、優先事項は発注側が示します
移行仮説：「残す」「移す」「作り替える」の仮説を用意して、委託先に検証を依頼します
提案比較：製品名だけで依頼すると、各社の前提が異なり、見積もりや工期を比べられません

発注形態の選択肢（一括請負・段階発注・運用委託）

発注形態ごとに契約する範囲を整理できます。

発注形態は、要件がどこまで確定しているか、移行中にどんな不確定事項があるか、社内の管理体制はどうかで選びます。

既存環境の調査後に設計変更が起こりやすいため、成果物を段階ごとに確認する方式が適しています。

一括請負が向くケース

納品範囲と完成責任を明確にできる案件では、一括請負を選択肢にできます。

適用条件：納品物、作業範囲、受け入れ条件、期限を定義できることが前提です
利点と納品例：指定テストに合格した構成図、設定書、手順書を納め、稟議で総額を管理しやすい
注意点：現行仕様が不明だと価格や予備工数が増え、変更時に追加費用が生じやすい
分割案：現状調査と基本設計を準委任にし、構築部分を請負にする

納品例には、既存ネットワークに接続するクラウド環境の構築も含まれます。

準委任・段階発注が向くケース

準委任は、専門家の作業や支援を確保したうえで、調査や設計を進めながら合意を更新する方式です。

既存構成やアプリの依存関係が不明なときに適します。

現状調査で資産台帳と課題一覧をつくる
構想をまとめ、次の投資判断を行う
PoCで性能を測り、本番移行条件を定める
基本設計で構成図と責任分界を確定する

各フェーズの終了条件を決め、次へ進むための判断材料は成果物で確認します。

構築後の運用委託を分けるケース

構築会社と運用会社を分けると、運用費用の競争性を高め、特定ベンダーへの依存を抑えられます。

障害時にネットワークはA社、クラウドはB社、アプリはC社と分かれると、一次対応が遅れるおそれがあります。

別発注にする場合は、発注側が、監視の検知からエスカレーション、復旧判断、顧客報告までを一枚の責任分界図にまとめます。

ポイント

迷ったときは、要件がどこまで確定しているかを基準にします。納品範囲を決め切れる部分は一括請負に、調査や設計が必要な部分は段階発注に分けて考えます。

発注前に整理する要件とRFPの項目

三つの領域をそろえると提案を同じ前提で比べやすくなります。

RFPは、業務目的と制約を伝え、同じ前提で提案と見積もりを受けるための書類です。製品を指定するものではありません。実装が未確定でも、範囲や目標、条件を整理しておけば比較の精度が上がります。

業務要件と現行環境の整理

RFPに盛り込む業務要件、現行資産、目標、制約を洗い出します。

業務と規模：対象業務、利用者、拠点、処理量、繁忙期、停止可能時間、連携先
現行資産：サーバー台数、OS、データベース、ミドルウェア、保守期限、外部接続、バッチ、ファイル連携、認証方式。手作業や夜間バッチも調べます
業務目標：「クラウド化」を掲げるより、月末処理の短縮、災害時の再開時間、開発環境の準備期間などで定めます
制約と未定事項：RTO・RPO、許容遅延、保管地域、個人情報・機密情報の有無。未定なら確認事項として明記します

業務目標や制約は見積もりと契約に影響するため、RFPに反映します。

技術要件と運用要件の書き分け

技術要件と運用要件を分け、提案各社が同じ条件で見積もれるようにします。

技術条件：接続方式、帯域、冗長化、認証、暗号化、バックアップ、監視、ログ保存、脆弱性対応、同期、性能、可用性
通信と連携：VPNか専用線か、許可する通信、通信断時も継続する機能を定めます。Web/APIと基幹DBの同期遅延、再送、二重登録も含みます
運用条件：アカウント発行者、パッチ適用者、障害検知・復旧開始時間、月次報告の内容
引き渡し：設計書、IaC、構成情報、監視設定、ログの帰属と引き渡し条件。後回しにすると、他社へ移すときに情報が不足しやすい

提案書と見積書の提出形式

提案書と見積書は、各社の内容を同じ前提で比べられる形式にそろえます。

提案書：配置方針、移行方式、基盤、工程、体制、リスク、前提、運用範囲、切り戻し方針
見積もり項目：調査、設計、構築、アプリ改修、データ移行、テスト、教育、運用開始支援、月額費用
内訳と未確定事項：作業、工数、単価、数量、期間、除外事項をそろえ、未確定の費用は想定レンジと決定時期を示します

「一式」でまとめた提案は比べにくくなります。一方で、項目別にそろえておくと、技術の差と見積もり範囲の差を判断できます。

ポイント

未確定の事項は推測で埋めず、確認事項として明記します。そうしておけば、各社の提案を同じ前提で比べられます。

契約形態と責任分界の決め方

契約では完成責任に加えて、クラウドからアプリまでの各領域について管理者を決めておく必要があります。クラウド事業者とSIerでは責任範囲が異なるため、サービス名だけで判断できません。

請負契約の検収条件

請負契約では、納品物と検収条件、変更時の手続きを、あらかじめ確定しておきます。

納品物：構成図、パラメータシート、IaCコード、テスト仕様書・結果、移行計画、運用手順書
検収基準：性能、可用性、バックアップ復元、障害通知、権限設定の受け入れ条件
変更管理：依頼者、影響評価、追加費用の算定、承認者、納期変更の扱いを定めて、口頭依頼の膨張を防ぎます
追加作業：移行中に見つかった古い連携仕様や追加のセキュリティ対策を、標準作業と分けて記録します

準委任・運用契約の責任とSLA

準委任と運用契約では、委託先の役割と、自社が判断する範囲を分けて定めます。

準委任：作業時間と役割を決め、委託先の成果責任と自社の判断範囲を区分する
運用項目：監視、一次切り分け、復旧支援、定例会、報告書、パッチ、脆弱性対応、バックアップ確認
SLA：稼働率、障害重要度、検知・連絡・復旧開始時間、計画停止、各社や再委託先の障害の扱い
RTO・RPO：自社業務の許容値として定め、テストで確かめられる条件にする

データ・知的財産・終了条件

契約の時点でデータと知的財産の扱いを決め、終了時の移行条件まで確認しておきます。

契約上の権利と管理：データ所有権、バックアップ先、国外移転、再委託、監査、秘密保持、事故報告、ログ保存期間、設計書・コードの利用権
個人情報：安全管理措置、再委託先、データ所在地、削除方法を、法務と情報セキュリティの部門で確かめる
契約終了時：データ返却形式、アカウント移管、秘密情報の削除証明、DNS・証明書の切り替え、引き継ぎ期間を定める

出口条件を契約に含めておくと、ベンダーの変更やオンプレミスへの切り戻しを選択肢として残せます。

ポイント

契約前に、誰がどの領域を管理し、何をもって検収とするかを文書に残しておきます。変更の手続きと、データ返却などの出口条件まで書き込めていれば、契約後のずれを減らせます。

ハイブリッドクラウド発注の費用相場と内訳

費用は、サーバーやクラウド料金だけでは決まりません。調査や設計、移行などの作業と、ライセンスや運用などの費用を合算し、初期費用と月額費用を分けて考えます。

公的な一律の価格表はありません。以下の数字は、リサーチノートの業務システム開発情報を基にした、RFP前の予算検討用の編集部推定です。

構成規模で300万円から数億円以上に広がる初期費用の幅

初期費用の推定レンジは構成規模で変わるため、次の目安をRFP前の予算検討に使います。

小規模：300万〜800万円程度。既存サーバー1台から数台にWebやバックアップを追加し、VPNやAPIで接続する想定
中規模：800万〜3,000万円程度、期間4〜9か月程度が推定目安。基幹系を残してWeb/API、分析、災害対策を追加する想定
大規模：3,000万円〜1億円超。複数システム移行、アプリ改修、コンテナ化などを含む
高可用性・規制対応：金融・公共・製造では1億〜数億円以上になる可能性がある

小規模の主な内訳は、調査や基本設計、接続や認証などです。

環境が整理済みであれば、期間は2〜4か月程度です。

複数拠点、閉域接続、冗長化が増えるほど、調査と試験の工数も増えます。

移行、監視、性能試験が加わると、その分だけ作業も膨らみます。

月額費用の規模別の目安（固定費を含む）

月額費用は、クラウド利用料以外の固定費も含めて、規模別の推定レンジで検討します。

小規模：月10万〜50万円
中規模：月50万〜300万円
大規模：月300万円以上

これらはリサーチノートの推定で、前提によって大きく変わります。そのため、クラウド利用料と回線、運用人員を中心に、各費用を合算して見積もります。オンプレミス保守や監視、バックアップ、ライセンスも対象です。

専用線の帯域、データ転送、バックアップ保持期間、DRサイト、24時間運用は、それぞれ個別に確かめます。従量課金の単価だけでは、総額を判断できません。

AWS「How AWS Pricing Works」の価格例は、国内案件の相場にそのまま置き換えられません。

AWS Outpostsのカスタマイズ例では、3年契約のEC2構成が月額7,148.67米ドルです（出典：AWS「How AWS Pricing Works」）。

また、別のEC2構成は月額7,359.69米ドルです。同資料では、11TBのEBSを1GBあたり月額0.30米ドルとしています（出典：AWS「How AWS Pricing Works」）。

これらは為替や税を含まない参考値です。

専用オンプレミス型の基盤は、小規模なクラウド利用と費用の桁が変わる場合があります。

2026年時点の料金モデル

サービスごとに、料金モデルと必要な運用条件を確かめます。

Azure Local：物理プロセッサコアを基準に課金し、追加Azureサービスは別料金
EKS Hybrid Nodes：AWS管理のEKSコントロールプレーンに、自社のオンプレミスやエッジのノードを接続
利用料金：最低料金・初期コミットなし。接続ノードのvCPU時間課金（出典：Amazon EKS「Hybrid Nodes overview」）

Azure Localは仮想CPU課金ではありません（出典：Microsoft Learn「Azure Local billing and payment」）。

既存機器を使えるか、検証済みの構成か、ゲストOSのライセンスや保守はどうかを確かめます。

見積もりでは、VM数に加えて、物理コア数や機器、OS、サポートを並べます。

また、安定したネットワーク接続と、自社側でのノードやOSの管理が必要です。料金とあわせて、運用体制も見積もります。

ポイント

費用は初期費用と月額費用に分け、回線や転送、運用人員などの固定費も含めて比べます。公開の価格例は参考値として扱い、自社の条件で再見積もりを取って予算を決めます。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や資格の数だけでなく、既存環境を調べ、配置方針を決め、移行後も運用できるかで選びます。

提案チームに、業務から運用まで各分野の担当者がそろっているかも確かめます。

同規模・同業種の実績の確認

実績を確かめるときは、既存の基盤や拠点数、データ量について質問します。RTOとRPOの扱いも聞きます。移行方式と運用体制も、あわせて質問します。

金融、公共、製造、店舗など近い事例があれば、公開できる範囲で、課題や期間、移行後の運用、残った課題を聞きます。

ただし、類似事例がなくても、PoCや調査で検証する提案があるかは確かめます。社名だけで判断せず、担当責任者の役割や、再委託先が受け持つ範囲も確認します。

同じ前提での3年TCO比較

同じ条件で総所有コスト（TCO）と作業範囲をそろえ、提案の差を見ます。

少なくとも3年間の費用：構築、クラウド、オンプレミス保守、回線、転送、バックアップ、監視、ライセンス、人員、障害対応、機器更新、撤去・移行
比較条件：提案を自社WBSに合わせ、各社の前提と除外事項を別欄に記録する
作業範囲：移行リハーサルや障害試験の回数、切り戻し、設計書、教育、運用引き継ぎの有無

専用線や転送、手厚い運用を別計上すると、総額が高くなる場合があります。そこで、同じ条件で再見積もりを依頼し、除外作業による価格差を見分けます。

セキュリティと運用の実効性

委託先のセキュリティ管理と、障害時に機能する運用体制を確かめます。

情報保護：データ分類、暗号化、鍵管理、MFA、最小権限、特権ID、脆弱性管理、ログ監査
委託管理：バックアップ、インシデント対応、再委託先を含む管理範囲
運用の証拠：障害訓練や復元テストの記録、監視画面、夜間連絡体制、変更管理手順
障害時の応答：想定障害に対し、誰が何分以内に何をするか説明してもらう

IPAは2026年3月27日に中小企業の情報セキュリティ対策ガイドライン第4.0版を公開しました。今回の改訂は、サプライチェーン全体への攻撃を踏まえたものです（出典：IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」）。

公開事例から読み取る移行条件

公開事例は、自社との条件の違いを見極めて、移行方針を考える材料にします。

事例の確認点：何を残し、何を移し、どの基盤で運用したか
日本生命保険相互会社の事例：既存資産を活かしてリフト・アンド・シフトを進め、新規システムではクラウドも選択肢にする（出典：IBM「日本生命保険相互会社」）
自社との違い：データ量、停止可能時間、既存ライセンス、拠点間ネットワーク、担当者スキルを比べる

事例をそのまま再現できるとは限りません。そこで、同じ成果に必要な追加条件を委託先に質問し、RFPの前提を補正します。

条件が違えば、費用と期間も変わります。事例は、導入の成果だけでなく、移行条件を読むために使います。

発注後の進め方と失敗を防ぐチェックポイント

工程の節目で課題を確認し、次へ進む判断を行います。

発注後は、現状調査と基本設計から始め、PoCと詳細設計・構築を経て移行リハーサルへ進みます。その後は、本番切り替えから安定化を経て、運用引き継ぎに移ります。

各工程に自社の判断ゲートを設けます。前工程の課題を解消してから次へ進むことで、品質を守れます。

小さなPoCでの通信・性能・運用の確認

影響範囲を限定した業務や開発環境でPoCを行い、全システムは一度に移しません。対象を絞ると、検証の負担を抑えられます。

接続・同期：通信断や同期遅延、認証失敗を確かめる
復旧・監視：復元手順と監視通知を試す
費用・操作：クラウド費用と現場の操作性を測る

本番に近いデータ量、権限、ピーク時間、障害条件を、一部でも再現しておきます。そのうえで、採用条件と中止条件を先に定め、結果に応じて構成を変えられる余地を残します。

切り替えと切り戻しの事前準備

本番切り替えから通常運用まで、復旧判断と確認項目を順に決めておきます。

切り替え手順、停止時間、最終バックアップ、データ整合性確認、告知、監視強化、判断者を決める
切り戻し条件と期限を数値で定め、事前に実行する。一度も実行していない計画は、障害時に使えるとは限りません
切り戻し先のデータが古い場合、取引の再処理時点、二重登録防止、利用者への案内を決める
安定化期間に性能、ログ、費用、問い合わせ、権限、バックアップ復元を確認して通常運用へ移る

丸投げ・隠れ費用・ロックインの防止

失敗を防ぐには、発注範囲と責任分界、意思決定の方法を設計しておく必要があります。

起こりやすい失敗：目的のない丸投げ、回線・転送費の見落とし、要件膨張、切り戻し未検証、運用人材不足
引き継ぎ情報：構成図、アカウント台帳、設定値、IaC、データ形式、API仕様、監視ルール、運用手順を自社で読める形で受け取る
出口条件：3年後の引き継ぎに必要な成果物とデータ返却方法を決め、変更・移行費用と条件を契約前に把握する

課題は、特定サービスを採用すること自体より、変更や移行の費用や条件が分からないことです。そのため、契約と体制を整えておきます。

ポイント

各工程の終わりに自社の判断ゲートを設け、前工程の課題が残るときは次へ進まないと決めておきます。切り戻しの条件も、本番前に一度は実行して確かめておきます。

よくある質問（FAQ）

発注では、費用、社内体制、クラウドの選び方、責任分界について疑問が出てきます。よくある質問に回答します。

ハイブリッドクラウドの外注費用はいくらですか？

初期費用の推定レンジは、小規模で300万〜800万円、中規模で800万〜3,000万円、大規模で3,000万円〜1億円超です。

月額の目安は、小規模で10万〜50万円、中規模で50万〜300万円、大規模で300万円以上です。サーバーや回線、データ量、可用性、運用時間によって変わります。

正式な予算は、同じRFPをもとに複数社から見積もりを取って確定します。

社内にクラウド人材がいなくても発注できますか？

発注はできます。ただし、業務要件を決める担当者と、委託先を管理する責任者は社内に必要です。データの配置や許容停止時間を決めるのは自社だからです。

障害時に業務の継続を判断するのも自社です。そのうえで、調査や設計レビューは外部に依頼し、運用手順と教育を通じて社内に知識を残す方法が現実的です。

AWSとAzureなど、どのクラウドを選べばよいですか？

製品を先に決めず、自社の条件に合う候補を比べます。

比較条件：データ所在地、既存OS・DB、認証、ネットワーク、社内スキル、必要サービス、運用体制
Azure Local：Microsoft環境や物理コア課金を前提にオンプレミス基盤を運用する場合の候補
EKS Hybrid Nodes：AWSやEKSを中心にオンプレミスノードも統合する場合の候補

候補ごとに3年TCO、移行難度、出口条件を比較して決めます。

機密情報をクラウドに置いても問題ありませんか？

問題の有無は、一律には決められません。まず、データ分類、暗号化、鍵管理者を確かめます。そのうえで、アクセス権やログ、保管地域、再委託、バックアップの扱いも確認します。

事故報告や監査権限も確認したうえで、社内規程と法令、契約要件に合う配置を決めます。個人情報については、委託先や国外の第三者への提供の確認が必要な場合があります。

情報セキュリティ部門と法務部門には、RFPの作成段階から参加してもらいます。

まとめ

クラウド製品を比べる前に、業務とデータの配置、継続水準を決めておきます。そのうえで、RFPには調査、ネットワーク、ID、移行、監視、運用を分けて書き込みます。

契約と見積もりの範囲・責任・出口

要件が不確かな段階では、調査やPoCを準委任にし、納品物が明確になった構築を請負に分ける方法が有効です。

回線や転送、バックアップ、監視、ライセンス、運用を含めた3年TCOで比べます。さらに、構成図やIaC、手順書、データ返却、再委託、切り戻し条件を契約に入れます。

構築後の運用まで見た委託先の選び方

同規模・同業種の移行経験や既存基盤を確かめます。セキュリティとネットワークの扱いも見ます。障害対応と社内への引き継ぎも確かめます。

全面刷新を急がず、効果とリスクを測れる範囲から段階的に発注すると、長期運用につなげられます。

▼全体ガイドの記事
・ハイブリッドクラウド開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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