プライベートクラウド開発の発注/外注/依頼/委託方法について

プライベートクラウドの発注は、要件整理、同条件での見積比較、契約、段階的な構築・移行、運用引き継ぎの順に進めます。この順で段階ごとに決めておくと、運用に入ってからの行き違いを減らせます。

▼全体ガイドの記事
・プライベートクラウド開発の完全ガイド

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

プライベートクラウドの全体像

プライベートクラウドは、特定の企業や組織だけが使う専用のクラウド環境です。自社データセンターに置くオンプレミス型だけでなく、専用設備を預けるホステッド型や、専用リソースを使う形態も含まれます。

専用設備とクラウドらしい運用の組み合わせ

プライベートクラウドの利点を生かすには、サーバーを専用にするだけでなく、クラウドらしい運用を組み合わせる必要があります。特に、仮想マシンやコンテナをポータルやAPIから払い出せることが重要です。

• セルフサービス：利用者が環境を作成・削除できる画面やAPI。
• リソース管理：リソースをプールとして扱い、利用量を一覧で把握できる状態にする。
• 自動化と監視：自動プロビジョニングや監視を、日々の運用の流れに組み込む。

発注するときは、誰がどの画面やAPIから、何分以内に環境を作成・削除できるかまで決めておきます。ここが曖昧なままだと、払い出しの速さについて認識がずれたまま契約することになります。

専用にする範囲の絞り込み

専用環境にする範囲は、ワークロードごとに必要性を見極めて決めます。

• 専用環境に残す候補：機密性、低遅延、データ所在地、既存資産、業界規制。
• 変動負荷の処理：Webフロントや一時的な検証環境まで専用化すると、ピーク時に合わせた資産を抱えることになります。
• ハイブリッド構成：基幹DBや社内AI推論基盤を残し、変動負荷の高い処理をパブリッククラウドへ接続する方法。合理的な場合もあります。

AWSのVPCのような論理分離ネットワークは、専用の物理リソースを持つプライベートクラウドとは意味が異なります。そのため発注書には、物理専有か論理分離か、設備の所有者、障害時の交換担当を明記します。

プライベートクラウドの発注形態の選び方

発注形態は、1社へ設計から運用までまとめて依頼する方式、機器やクラウドを調達してSIerへ設計・移行を頼む方式、PoC後に本番へ進む方式に分かれます。たとえば、運用人材が少ない企業は、運用設計と引き継ぎを含むマネージド型を候補にし、5年TCOで比べます。

ターンキー型と、短期間で標準化したい企業

ターンキー型は、サーバーからネットワーク、仮想化基盤、監視、バックアップまでを一体で設計し、サービスとして使う方式です。窓口を一本化しやすいため、調達や設計の抜け漏れを抑えられます。

ただし、標準構成の外にある要件や他社への移行条件は、弱くなる場合があります。そのため、納品対象にAPIとデータ形式を含めます。設定情報や運用手順書も、納品対象として受け取ります。

SIerとクラウド事業者を組み合わせる方式

基幹のERPやDBが、WindowsやLinux、VMwareや社内ネットワークと複雑に絡む環境では、事業者から基盤を調達します。さらに、SIerには現行調査と移行、業務アプリの調整を依頼する分業が向きます。

どこまでを誰が受け持つかは、一次障害受付から機器交換、OSパッチ、仮想化基盤、DB、アプリまで、表にします。窓口が分かれると障害の切り分けに時間がかかるため、統合運用を担う会社も決めておきます。

不確実性が高い場合のPoCの先行委託

性能、バックアップ復元、既存VM移行、GPU利用、閉域接続のいずれかに不明点がある場合は、全社導入を急がず、代表的な非本番システムでPoCを行います。PoCで示してもらう内容には、動作確認の結果に加えて、想定IOPS、復元時間、RTO・RPOを含めます。さらに、運用者の作業時間や月額見積、失敗時の切り戻し条件も、示してもらう内容に加えます。

PoCを値引きの材料だけにすると、検証が浅くなりがちです。そのため、本番採用の判定基準と、不採用だった場合にPoCの結果を使える範囲を、契約に書いておきます。

RFPと要件整理で決めること

RFPは、業務成果と評価条件を候補会社へ同じように伝える資料です。必須要件と、提案を任せる要件は分けて記載します。

まずは、対象業務と利用者数、現行構成、データ量を整理します。そのうえで、ピーク時間や停止可能時間、セキュリティ要件、予算の考え方、希望時期も、提案の前提として書いておきます。

対象ワークロードと現行環境の洗い出し

まずは、サーバーごとにCPU、メモリ、容量、IOPS、帯域を記録します。OSやDB、保守期限、バックアップ方式、依存先も残しておきます。数値は平均値に加えて、月末や締め日のピークも確認します。

夜間バッチや障害時の再実行、5年後のデータ増加率も、あわせて押さえておく必要があります。既存VMを移すのか、コンテナ化やDB再設計まで行うのかによって、工数と契約責任が変わります。

セキュリティ、SLA、RTO・RPOの数値化

見積を比べられるように、RFPには次の要件を具体的に書きます。「安全に運用する」といった表現だけでは、提案の差が見えにくくなります。

• アクセスとデータ：保管場所、国外移転、管理者記録、MFA、特権ID承認、暗号化。
• 保護と復旧：脆弱性対応期限、ログ保存期間、バックアップ世代数、復旧時間、許容データ損失。

障害時の条件は、復旧開始までの時間やサービス復旧までの時間、許容するデータ損失を、RTO・RPOとして記載します。

ISMAPは、政府情報システム向けクラウドサービスのセキュリティ評価・登録制度です。民間の全プライベートクラウドに取得義務がある制度ではありません（出典: ISMAPポータル、2026年8月確認）。

政府・金融・医療などの要件が関係する場合は、登録状況に加えて、監査証跡やデータ所在地、受け持つ範囲、再委託先の管理も確認します。

納品物と契約終了時の出口

RFPには、納品物と、契約終了時に受け取る情報を明記します。

• 構築・運用の納品物：設計書、構成図、パラメータシート、ネットワーク設定、IaC、監視項目、運用手順、障害対応表。
• 引き継ぎ資料：バックアップ復元手順、教育資料、テスト結果。
• 契約終了時の受け取り：標準形式のデータ、バックアップを含む消去証明、設定情報、ログ、撤去・移行を支援する日数。

口頭の説明だけで引き継ぐと、担当者が替わったり委託先が変わったりするたびに、再調査の費用が生じます。移行先が未定でも出口の条件を決めておけば、特定のベンダーへのロックインを抑えられます。

発注・外注・委託の進め方の順番

一般的には、目的と対象範囲を整理してから、現行調査、RFP配布、提案・見積の比較、契約へと進みます。契約後は、基本設計、PoCまたは詳細設計、構築、移行リハーサル、本番移行、運用引き継ぎの順で行います。

発注先に任せきりにせず、社内の業務責任者と情報システム責任者が各段階を判定すると、後戻りを減らせます。

企画段階での3社以上への同条件提示

候補は、総合SIerや専用クラウド・データセンター事業者、仮想化・コンテナ基盤の認定パートナー、運用会社から選びます。

知名度だけでなく、同規模・同業界の実績、設計から移行までの範囲、24時間運用、一次請負会社を確認します。同じRFPを3社以上に配ると、価格や作業範囲の違いも比べられます。

設計・構築・移行の判定ゲート

設計から本番移行までは、段階ごとに成果を確認し、次に進んでよいかを判定します。

1. 基本設計：サーバー、ストレージ、ネットワーク、認証、監視、バックアップ、DR、開発者向けポータルの内容を固める。
2. 試験と判定：非本番環境での性能・権限試験、バックアップ復元、障害切替、パッチ適用の結果から、本番へ進むかを決める。
3. 段階移行：停止時間の短い開発環境や部門システムを先に移す。
4. 基幹DBの移行：データ同期、最終停止時間、切り戻し期限、業務部門の受入確認を、移行前に決めておく。

移行の完了は、VMを起動した日ではなく、業務処理とバックアップ復元を確認できた日と定義します。

運用開始後のKPIと引き継ぎ

運用開始後は、容量使用率や環境の払い出し時間、バックアップ成功率、復元テスト、パッチ期限、重大障害の復旧時間を、月次で確認します。

初月から完璧に自動化しようとせず、手作業を残す場合も、いつまでに自動化するかをロードマップにまとめます。

引き継ぎ時には、社内担当者が障害連絡、権限申請、復元、証明書更新、容量追加を演習します。手順書だけで作業できて、委託先が結果を確認した状態を、完了の条件とします。

請負・準委任・サービス利用の使い分け

構築と継続運用で契約を分けることがあります。完成条件が固まった構築は請負に、調査や要件整理、技術支援、運用改善は準委任に、設備や基盤の継続利用はサービス契約にすると、責任と価格が明確になります。

請負契約の完成条件と変更ルール

請負契約では、合意した成果物を完成させる責任を委託先に求めやすくなります。ただし、要件が曖昧なままだと、変更のたびに追加費用や納期延長が生じます。

そのため、受入基準や性能値、テスト範囲を、契約書と別紙に記しておきます。未達時の是正や仕様変更の承認者、追加見積の算定方法も、同じ場所に残します。

準委任契約が向く調査や伴走支援

準委任契約は、作業や専門知識の提供を受ける契約です。未知の要件を整理する段階に適します。

現行調査、RFP作成支援、PoC、アーキテクチャレビュー、移行計画、運用改善は、成果を一つの完成物に固定しにくい作業です。そのため、準委任契約が合っています。

稼働時間や担当者のスキル、作業範囲、報告頻度を明確にします。成果物、再委託、情報管理も、契約で決めておきます。作業時間の多さだけでなく、何を判断できる状態にできたかを、月次で確認します。

サービス利用契約のSLAと受け持つ範囲

マネージド型の料金とSLAは、提供範囲と自社の停止許容時間に照らして確認します。

• 月額・年額の対象：設備、ソフトウェア、保守、監視、サポートの範囲。
• SLAの適合性：標準SLAが自社の業務停止許容時間に合うか。
• 対象外や例外：計画メンテナンス、不可抗力、設定ミス、回線障害、復元、セキュリティ事故の扱い。

AWS Outpostsサーバーは、3年契約を基本に、全額前払い、一部前払い、前払いなしから選べます。

また、配送、インフラストラクチャサービスによる保守、ソフトウェアのパッチとアップグレードは、料金に含まれます（出典: AWS Outpostsサーバー料金、2026年8月確認）。

一方で、OS、Outposts上のAWSサービス、サポートは別途確認が必要です。各社の見積では、「月額込み」の範囲をそろえて比べます。

プライベートクラウドの費用相場とコスト内訳

費用は、構成や契約期間、設置場所に加えて、ライセンス、冗長化、移行対象、運用時間によって変わります。そのため、一律の相場はありません。下に示すのは、公開事例と業務システム開発の人月単価をもとにした、2025〜2026年時点の概算です。

税や回線、電力、アプリ改修、データ移行を含むかどうかで、金額は変わります。そのため、この概算は予算取りの目安として使い、発注前に内訳を取り直します。

小規模から中規模の費用目安

規模別の推定費用と期間は、構成や移行範囲をそろえたうえで比べます。

• 小規模：既存設備を活用し、専用VM数台をマネージド型で使う場合、初期100万〜500万円、月額20万〜100万円程度。
• 中規模：4〜8ホスト、冗長ストレージ・ネットワーク、バックアップ、移行を含み、初期500万〜2,000万円、月額100万〜400万円程度。
• 構築期間：小規模は1〜3か月、中規模は3〜9か月程度。調査や移行リハーサルが長いと延びます。

IDCFの公開事例では、3年契約・7ホスト構成のプライベートクラウドで、初期50万円、月額380万円です。ネットワーク、100TBベアメタルサーバー、HAマネージドファイアウォール、ハウジングを含む一構成の価格です（出典: IDCフロンティア「IDCFクラウドプライベートクラウドTypeV2020活用例」、2026年8月確認）。この公開価格は、一般的な相場を示すものではありません。

大規模・DR・GPU案件の費用規模

大規模案件とGPU・AI案件は、構成ごとに次の費用幅を見込みます。

• 大規模案件：複数拠点、HA、DR、基幹DB、24時間監視、移行を含み、初期2,000万〜1億円超、月額300万〜1,500万円超。
• GPU・AI案件：ターンキー基盤や専用データセンター設計で、初期3,000万円〜数億円、月額100万円〜数千万円となる可能性があります。

GPU台数やストレージ性能、冷却、電源、モデル運用、保守契約によって差が大きいため、特定の金額を相場として断定できません。

2026年6月にHPEは、S k y株式会社がHPE Private Cloud AIを1か月で導入した事例を公表しました。この事例は、機密データを扱うオンプレミスAI環境です（出典: HPE公式発表、2026年6月）。

事例は、サーバーやストレージ、ネットワーク、アクセラレーテッドコンピューティング、ソフトウェアを統合したターンキー型です。さらに、GreenLake Flex Solutionsによる従量利用も採用しています。ただし、この事例は納期の参考にはなりますが、価格は非公開のため費用相場には換算しません。

初期費用ではなく5年TCOでの比較

初期費用だけが安い提案では、ライセンス更新やサポート、夜間対応、増設単価、電力・ラック費が別料金になる可能性があります。

• 初期・基盤費：ハードウェア、仮想化・コンテナ基盤のライセンス、設計・構築、データ移行。
• 継続運用費：監視・保守、回線、データセンター、バックアップ、DR、教育、ライセンス更新、サポート、夜間対応、増設単価、電力・ラック費。
• 終了・社内費用：撤去・移行、障害対応、社内運用人材の人件費。
• 5年分の算定：初期費用に、月額費用の60か月分と更新費、保守料、増設費、障害対応費、人件費、終了時の移行費を足し合わせる。

冗長化やDRは設備を二重化するため、初期費用も継続費も増えます。見積に「別途」と残る項目は、金額が未確定でも算定方法を確認します。

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

見積額だけで選ぶと、対象外作業や前提条件の違いを見落としがちです。そこで、7つの観点で評価し、なかでも価格、技術適合性、移行計画は、見積の中身と照らして確かめます。残る4つは、運用の責任と契約の範囲、契約終了後の扱いに関わる点です。

• 運用体制：24時間運用の範囲と、担当チームの体制。
• セキュリティ：RFPに書いたアクセス管理と、保護・復旧の条件。
• 契約条件：請負、準委任、サービス利用のどれか、SLAの対象外や例外。
• 出口：契約終了時に受け取るデータと、撤去・移行の支援。

重要な要件には、最低合格ラインを設けます。

実績の確認は担当チーム単位

実績は、同規模のホスト数や同業界のデータ管理、移行対象のOS・DBを特に確認します。ほかに確かめるのは次の項目です。

• RTO・RPO：障害時の復旧時間と、許容するデータ損失。
• 障害件数：これまでの障害の発生状況。
• 復旧実績：障害から復旧させた実際の事例。

大手の導入実績があっても、一次請負会社や設計者、移行責任者、運用チームが同じとは限りません。そのため、予定担当者を提案会議に招き、障害時の判断や追加要件への対応を質問します。

見積の粒度をそろえた比較

比較条件と費目をそろえ、各社の提案範囲を並べて確認します。

• 構成条件：サーバー台数、CPU・メモリ、容量・性能、帯域、バックアップ世代、DRサイト。
• 作業条件：監視・保守時間、移行対象、テスト範囲。
• 費目：機器、ライセンス、設計、構築、移行、教育、月額運用、追加単価。

差額が大きいときは、値下げの前に対象外を確認します。たとえば、24時間監視が平日日中のみ、バックアップは復元試験なし、DRは切替訓練なし、アプリ改修は対象外、といった場合があります。

値引き後も、SLAや品質、担当者数を維持できる根拠を示してもらいます。

ロックインと運用リスクの質問事項

候補の方式ごとに、契約後の価格や移行、運用上のリスクを確認します。

• VMwareの契約条件：サブスクリプション化されたライセンス、最低コア数、更新価格、既存契約、認定パートナーの支援範囲。
• 移行と継続性：価格改定、移行先、必要スキル、設定の持ち出し方法。
• 代替方式：OSSを含むOpenStack、Kubernetes、OpenShift、Azure Stack HCI、専用ホステッド型も候補です。
• 運用責任：自社の運用人材、障害時のコード・設定修正者、パッチ責任者、終了時のデータ形式。

Broadcomは2025年6月にVMware Cloud Foundation 9.0の一般提供を発表しました。同製品は、データセンターやエッジ、マネージド環境を一貫した運用モデルで扱う方向性です（出典: Broadcom公式発表、2025年6月）。

導入費が安い方式でも、運用費まで安いとは限りません。そのため、候補会社から回答を得て比べます。

よくある質問（FAQ）

発注前によくある疑問への回答をまとめます。最適な形は、規制や既存資産、運用人材によって変わります。そのため、回答はRFPの確認項目に置き換えて使ってください。

プライベートクラウドはどの企業にも必要ですか？

プライベートクラウドが必要かどうかは、企業によって異なります。機密管理や低遅延、専用設備、既存資産の継続利用、監査要件が重要で、パブリッククラウドの論理分離では満たしにくい場合に候補になります。

変動負荷の大きい処理や標準サービスは、パブリッククラウドと組み合わせます。そうして、全体の費用と運用負荷を抑えます。

発注予算はどのくらい準備すればよいですか？

推定レンジは、小規模の初期100万〜500万円、中規模の500万〜2,000万円、大規模の2,000万〜1億円超です。

これは構成と範囲に基づく概算です。設備やライセンス、移行、DR、24時間運用によって大きく変わるため、初期費用と月額を分けたうえで、5年TCOと終了時の移行費まで予算に含めます。

何社に見積を依頼すればよいですか？

まず3社以上へ同じRFPを提示し、必要に応じて、異なる技術方式の会社を加えます。総合SIer、専用クラウド事業者、認定パートナー、運用会社を含めると、比較しやすくなります。

見積の数を増やすことより、現行調査の情報と評価基準をそろえるほうが大切です。

構築と運用を同じ会社へ委託すべきですか？

専門人材が少なく、障害窓口を一本化したい場合は、設計・構築・移行・運用を同じ会社か統合運用チームへ委託すると、障害時の窓口も管理もまとめられます。

一方で、既存ネットワークやアプリに強い会社と、設備・基盤に強い会社を分けたほうが適切な場合もあります。その場合は、受け持つ範囲やエスカレーション、変更承認、SLA違反時の扱いを、契約間でそろえます。

まとめ

発注前の専用性と運用責任の最終確認

専用設備が必要な理由を、ワークロードごとに説明できるようにします。そのうえで、セルフサービス、バックアップ、監視、障害対応、容量計画の担当者を決めます。

説明できない要件は製品名で埋めず、提案を任せる範囲と社内で守る条件とに分けます。

最初に行う現行環境の洗い出しと5年TCO算定

まず現行情報をまとめ、複数社の提案から自社に合う発注形態を判断します。いきなり大規模な設備を発注する形は避けます。

発注準備から委託先比較までは、次の順で進めます。

1. 現行環境の洗い出し：対象システム、性能データ、停止許容時間、セキュリティ条件、契約期限を一覧にする。
2. 方式を比較：専用設備の必要性と、機密性・低遅延の目的、自動化、監視、バックアップ、障害対応を確かめる。
3. 5年TCOを算定：オンプレミス継続、専用ホステッド、マネージド型、パブリッククラウド、ハイブリッドを並べて比べる。
4. 同条件で提案を比較：性能、容量、セキュリティ、RTO・RPO、移行手順、成果物、SLA、責任分界、終了時のデータ返却をRFPに記し、横並びで比べる。
5. 委託先を選定：3社以上の見積で、担当チームの実績、移行・運用体制、ライセンス更新、ロックイン、出口条件を評価する。
6. 実行計画を確認：PoC、段階移行、運用引き継ぎを含む提案を比べ、運用で困らないように条件をそろえる。

▼全体ガイドの記事
・プライベートクラウド開発の完全ガイド

▼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を創業。