OpenStackのシステム開発の発注/外注/依頼/委託方法について

OpenStackのシステム開発を発注・外注するなら、OSSの利用料だけで判断せず、物理基盤、ストレージ、ネットワーク、設計、移行、監視、アップグレードまで含む総保有コストと責任分界を先に決めることが重要です。

この記事では、OpenStackのシステムを外部へ委託する際の発注形態、RFPと要件整理、契約形態、2026年時点の費用目安、委託先の選び方、見積書の比較方法を順番に解説します。技術に詳しい担当者が社内にいない場合でも、発注前に確認すべき項目を整理できる構成です。

▼全体ガイドの記事
・OpenStackのシステム開発の完全ガイド

OpenStackのシステム発注・外注の全体像

OpenStackは、サーバー、仮想マシン、ネットワーク、ブロックストレージなどをAPIで管理するIaaS基盤です。アプリケーションを開発する会社へ丸ごと依頼するというより、Linux、KVM、分散ストレージ、ネットワーク、認証、監視、運用自動化に対応できるSIer、OSSサポート会社、ディストリビューター、MSPへ相談する案件になりやすいです。

見積依頼の段階で「OpenStackを構築してください」とだけ伝えると、委託先ごとに含める作業がばらばらになります。要件定義、サイジング、ハードウェア調達、OSとOpenStackの導入、NovaやNeutronなどの設定、Cephなどのストレージ、認証連携、監視、バックアップ、移行、テスト、教育、保守をどこまで含めるかを分けて記載する必要があります。

特に成果物には、構成図、パラメータシート、AnsibleやTerraformなどのIaC、監視設定、バックアップと復元の手順、障害時のRunbook、バージョンアップ手順、既知の制約、管理者教育の記録を含めます。納品後に別会社へ移管できる状態を作ることが、外注の失敗を防ぐ基本です。

OpenStackは、複数テナントへのセルフサービス、オンプレミスや専用設備でのデータ管理、APIによる大量のVM作成、コンピュート・ネットワーク・ストレージの統合、ベンダー中立性を重視する企業に向いています。一方、VMが少数で増加も見込まれない場合は、マネージドIaaSや既存の仮想化製品の方が短期間かつ低コストになる可能性があります。

OpenInfra Foundationの2025年年次報告では、OpenStackの本番利用コア数が5,500万超と報告されています（出典: OpenInfra Foundation「2025 Annual Report」、2025年）。大規模利用が続いていることは採用候補としての安心材料ですが、導入規模が小さい企業にも同じ構成が適するという意味ではありません。自社の利用量と運用体制を基準に判断します。

OpenStackの発注形態はどれを選べばよいですか？

結論として、要件が固まっている構築作業は請負、検証や設計を含む不確実性の高い工程は準委任、継続的な監視・障害対応は運用サービスとして切り分ける方法が現実的です。全工程を一つの契約に押し込むより、成果物と責任範囲を工程ごとに定義した方が、見積比較と品質管理がしやすくなります。

請負契約は、指定した構成のOpenStack環境を構築し、検査に合格した状態で引き渡すような工程に適しています。たとえば「コントローラーノードを冗長化する」「指定したイメージからVMを起動できる」「管理ネットワークとテナントネットワークを分離する」「障害試験後に所定時間内で復旧できる」といった受入基準を数値や操作手順で決めます。

ただし、既存VMware環境の移行台数、ネットワークの制約、Cephの性能、利用部門の権限設計などが未確定のまま固定価格にすると、変更管理が増えます。契約前に調査・PoC工程を置き、確定した範囲だけを請負にすることが、追加費用の不透明化を防ぎます。

準委任契約は、専門家の稼働に対して設計、調査、レビュー、技術支援を依頼する形です。OpenStackの採用可否、ディストリビューションの比較、サイジング、既存ネットワークとの接続、移行方式の検討など、答えを作業前に確定しにくい工程に適しています。

この形態では、成果物だけでなく会議体、担当者のスキル、稼働時間、レビュー方法、課題管理表の更新頻度を契約書や個別仕様書に記載します。時間を使っただけで設計品質が担保されるわけではないため、月次報告の項目や次工程へ進む判断条件を置くことが大切です。

24時間365日の監視、アラート一次対応、障害切り分け、バックアップ確認、パッチ適用、容量管理、定期レポートまで委託する場合は、構築契約とは別に運用サービスの条件を確認します。2025年7月にRackspace Technologyが専用のマネージドなOpenStack Businessを発表したように、インフラを所有せず運用専門会社へ任せる選択肢もあります（出典: Rackspace Technology「Rackspace OpenStack Business」、2025年）。

一方で、マネージドという言葉だけでは対応範囲が分かりません。停止判断を誰が行うのか、緊急変更の承認者は誰か、脆弱性の通知から適用まで何時間か、計画停止はどのように連絡するか、データのバックアップと復元試験を誰が実施するかをSLAや運用設計書で確認します。

RFP作成前に整理すべきOpenStackの要件

RFPは、委託先に同じ前提で提案と見積を出してもらうための文書です。技術用語を並べるだけではなく、何を実現したいのか、どの条件を満たせば受入とするのか、誰が運用するのかを具体化します。情報が不足している項目は「提案で補完してほしい事項」として分けておくと、各社の設計力も比較できます。

まず、どの部門が何のためにOpenStackを使うのかを明らかにします。開発環境の払い出し、顧客向けサービス、分析基盤、AIや高性能計算、災害対策用の待機環境では、必要な可用性や拡張性が異なります。利用者数、テナント数、1日あたりのVM作成数、利用するOS、GPUやベアメタルの有無、将来3年の増加率を記載します。

停止した場合の業務影響も重要です。目標復旧時間のRTO、復旧時点のRPO、許容できる計画停止時間、障害時の連絡先、業務ごとの優先順位を整理します。単に「高可用性」と書くのではなく、コントローラーノード、ネットワーク、ストレージ、電源、データセンターのどこまで冗長化するかを決めます。

OpenStack公式の論理アーキテクチャでは、各サービスが共通のIdentityサービスで認証し、API、メッセージブローカー、データベースなどを組み合わせて動作します（出典: OpenStack公式「Logical architecture」、2026年）。RFPでは、Nova、Neutron、Glance、Cinder、Swift、Keystone、Horizon、Ceilometerなどの採用範囲を固定するだけでなく、必要な機能と性能を記載します。

既存環境との接続では、Active DirectoryやLDAP、DNS、IPアドレス管理、既存ルーター、FW、ロードバランサー、ストレージ、バックアップ製品、監視製品、CI/CDとの連携を洗い出します。VMwareから移行する場合は、ゲストOS、スナップショット、ネットワーク、バックアップ、ライセンス、移行停止時間の差異もRFPに含めます。

非機能要件には、可用性、性能、拡張性、セキュリティ、運用性、移行性、監査性を含めます。たとえば「VM払い出しを申請から何分以内に完了するか」「同時に何台のVMを作成できるか」「障害発生から何分以内に検知するか」「バックアップを何世代保持するか」「復元試験を何か月ごとに実施するか」といった形です。

セキュリティは製品名だけでは完了しません。OpenStack公式のSecurity Guideは、Public、Guest、Management、Dataという4つのセキュリティドメインを整理し、TLS、認証・認可、テナント分離、監査ログ、ハイパーバイザーの強化などを検討項目にしています（出典: OpenStack公式「Security Guide」、2026年）。個人情報や顧客機密を扱う場合は、委託先のアクセス権、ログの保管場所、事故時の報告、データ消去までRFPに書きます。

OpenStackの発注・外注を進める手順

発注は、候補会社を探して見積を取るだけではなく、採用判断、PoC、設計、構築、移行、受入、運用移管を一つの流れとして管理します。技術の検証を省いて価格だけで決めると、本番稼働後に性能不足や運用負荷が判明し、結果として追加費用が発生しやすくなります。

候補会社は、OpenStackの実績だけでなく、利用するディストリビューション、KVM、Ceph、OVNまたはOpen vSwitch、Ansible、Terraform、Linux、監視、バックアップ、ネットワーク設計まで確認して選びます。OpenStackの導入実績があっても、希望するバージョンや構成を現在提供していない場合があるため、実績の年、担当チーム、現在のサポート可否を確認します。

候補は最初から一社に決めず、少なくとも複数社へ同じRFPを渡します。大規模な専用基盤ならディストリビューターや大手SIer、OSSの深い解析が必要なら専門会社、運用を外部化したいならMSPというように、案件の課題と会社の得意領域を対応させます。

本番構築の前に、代表的なVM作成、ネットワーク設定、認証連携、イメージ管理、バックアップ復元、ノード障害、監視通知、API操作を小さく試します。PoCの目的は「画面からVMが作れた」と確認することではありません。想定した性能、復旧時間、運用手順、内製担当者の理解度が、定めた基準を満たすかを検証します。

PoCの成果物には、採用した構成と不採用にした構成、測定条件、測定結果、残課題、追加費用の可能性、基本設計へ引き継ぐ事項を含めます。PoCが失敗した場合に本番契約を見直せるよう、検証工程と本番工程の契約を分ける方法も有効です。

移行は、開発・検証環境、停止しても影響が小さい業務、重要業務、災害対策環境の順に段階化します。既存VMの棚卸し、OSの互換性、ネットワークアドレス、ストレージ性能、バックアップ、監視、ライセンス、切り戻し方法を確認し、移行リハーサルで実測します。停止時間を想定だけで書かず、実際に測ることが大切です。

受入試験では、正常系だけでなく、コントローラー障害、コンピュートノード障害、ストレージ容量逼迫、認証サービス停止、ネットワーク断、バックアップからの復元、権限の誤設定を試験します。試験項目、期待結果、実測結果、未解決の制約、受入者の署名または承認記録を残します。

OpenStackは構築して終わりではありません。公式リリースは約6か月サイクルで更新され、2026.1 Gazpachoは2026年4月1日に公開された維持版です（出典: OpenStack公式「OpenStack Releases」、2026年）。発注時点で、どのリリースを採用し、いつまで保守し、どの方法で次のリリースへ移行するかを決めます。

引き継ぎでは、構成管理リポジトリ、CI/CDの定義、秘密情報の管理方法、証明書の更新手順、監視の閾値、容量計画、障害連絡網、月次点検票、パッチ適用履歴を共有します。担当者向けの操作研修だけでなく、障害を想定した訓練を実施し、発注先が変わっても運用できる状態を確認します。

契約書で定める責任分界と成果物

OpenStackでは、アプリケーション、ゲストOS、仮想化ホスト、OpenStackサービス、ネットワーク、ストレージ、データセンター、クラウド管理者の責任が重なります。契約書に「基盤は委託先が対応」とだけ書くと、障害時に原因調査の範囲が曖昧になります。レイヤーごとに、設計、変更、監視、復旧、脆弱性対応の担当を決めます。

成果物は、基本設計書、詳細設計書、構成図、設定値一覧、IaCコード、テスト仕様書と結果、移行計画、バックアップ設計、セキュリティ設計、運用手順、障害時Runbook、教育資料、ライセンス一覧、既知の問題一覧に分けて確認します。ソースコードや設定を納品するのか、委託先の標準テンプレートだけを渡すのかも明記します。

対象外作業も重要です。ハードウェアの設置、回線費用、データセンター費、既存ネットワークの改修、アプリケーション改修、データクレンジング、休日の移行立会い、追加のセキュリティ試験、商用サブスクリプションなどが別料金になる場合があります。見積書の備考欄だけでなく、契約の前提条件として合意します。

SLAでは、受付時間、一次回答時間、復旧目標、重大度の定義、連絡手段、エスカレーション、計画停止、報告書の期限を定めます。「24時間対応」と書く場合も、常駐なのか電話受付なのか、復旧まで含むのか、部品交換やオンサイト対応を含むのかを確認します。

OpenStackの設定変更は、ネットワークや認証に影響することがあります。変更申請、影響評価、承認、実施、テスト、記録、切り戻しを標準化し、緊急変更の扱いも決めます。追加要件が出た場合の単価、見積再提出の期限、優先順位の決め方を契約に含めると、口頭依頼による費用増加を防げます。

OpenStackの発注費用相場とコストの内訳

OpenStack単体の国内統一相場は公開されていないため、以下は業務システム共通の費用目安、OpenStackの構成要素、公開されている料金例を組み合わせたRFP前の予算仮置きです。実際の金額は、ノード数、冗長化、ストレージ容量、GPU、移行台数、データセンター、商用サポート、運用時間で大きく変わります。特定の金額を確約する相場ではありません。

学習・PoCや単一ノードの検証は、100万〜300万円程度を予算仮置きにします。3〜5ノードの小規模本番で、高可用性、基本的な監視、バックアップ、運用手順まで含める場合は、500万〜1,500万円程度が一つの検討レンジです。いずれも既存機器を使えるか、設計と教育を含めるかで変動します。

5〜20ノード程度の業務基盤では、Cephなどの分散ストレージ、複数環境、認証・ネットワーク連携、IaC、既存VM移行を含めて1,500万〜5,000万円程度を仮置きします。マルチサイト、DR、GPU、ベアメタル、24時間365日運用、大量移行まで含む大規模案件では、5,000万円〜2億円以上になる可能性があります。これはリサーチノートに基づく類似システムからの推定で、個別見積の代わりにはなりません。

ランニング費用は、ハードウェアの償却またはホスティング料、OSや商用ディストリビューションのサブスクリプション、電力・回線・データセンター、監視・バックアップ・ログ保管、障害対応・パッチ・アップグレード・教育に分けます。OSSのライセンス料が無料でも、これらの費用と人材費が不要になるわけではありません。

Canonicalが公開するCharmed OpenStackの料金例は、3年間のハードウェア、一般的なホスティング、フルマネージドサービスを配賦したサンプルで、VMの種類により1時間あたり0.0132米ドルから0.1059米ドルが示されています（出典: Canonical「Charmed OpenStack」、確認時点2026年）。利用ハードウェア、地域のホスティング費、構成、給与費で変動する参考例であり、日本の小規模導入にそのまま当てはめないようにします。

一般的な業務システムの保守費を初期費用の年15〜20％程度とする目安がありますが、これはOpenStack固有の公定相場ではありません。OpenStackでは、対応時間、ノード数、変更回数、アップグレードの有無、オンサイト対応、SLAの厳しさで変わるため、年額だけでなく月次の作業内容と上限を確認します。

見積を比較する際は、初期構築費だけでなく、機器の更新、容量追加、商用サポート、運用委託、障害時の時間外対応、脆弱性対応、アップグレード、教育、撤去・移管まで足し合わせます。小規模なOpenStackを自社運用すると、技術者が別の業務から割かれる社内人件費も発生します。

各社の提案には、同じノード数、同じVM数、同じストレージ容量、同じ可用性、同じ対応時間を入れてもらいます。ハードウェアを購入する案、マネージドサービスを利用する案、既存設備を再利用する案を分け、3年と5年の支出、残存資産、契約終了時のデータ返却費用を横並びにすると、安価に見える提案の前提も見えます。

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

見積金額が低い会社を選ぶのではなく、同じ要件に対する前提、作業範囲、リスクの説明、運用体制、成果物を比較します。OpenStackのシステムでは、設計と運用の品質が数年後の費用に影響するため、提案書の読みやすさだけでなく、技術者との質疑応答で判断します。

OpenStackの担当者に、NovaやNeutronの知識だけでなく、Linux、KVMやQEMU、Ceph、データベース、RabbitMQなどのメッセージング、L2・L3ネットワーク、ロードバランサー、監視、バックアップ、IaCの経験を確認します。障害事例を聞くときは、症状、切り分け、暫定対応、恒久対応、再発防止まで説明できるかを見ます。

また、現行のOpenStackリリースと今後のアップグレード経験を確認します。公式リリースが6か月周期で進む以上、古いバージョンを一度構築した経験だけでは運用力を判断できません。担当者の退職や交代に備え、複数名体制、バックアップ担当、エスカレーション先を提案書に記載してもらいます。

見積書の比較項目は、要件定義、現状調査、基本設計、詳細設計、PoC、構築、テスト、移行、教育、運用設計、保守開始に分けます。担当者の役割、期間、工数、単価、諸経費、機器費、ライセンス費、クラウド費、税、予備費を分けると、各社がどこに費用を置いているかが分かります。

「一式」や「別途」が多い場合は、何が含まれるかを質問します。想定ノード数を超えたときの追加単価、VM移行1台あたりの費用、休日作業費、データ転送費、監視対象追加費、サポート契約の更新費、アップグレードの費用を確認します。価格差が大きいときは、安い会社へ値下げ交渉する前に、同じ範囲を見積もっているかを調べます。

OpenStackを採用しても、特定会社の独自パッチや独自運用ツールに依存すると、移管時の費用が大きくなります。標準APIを使っているか、独自改造の箇所と理由を説明できるか、変更をアップストリームへ還元できるか、設定とコードを納品するかを確認します。

契約終了時には、VMイメージ、ボリューム、バックアップ、ログ、構成情報、IaC、証明書、アカウント情報をどの形式で返却するか、返却と消去にいくらかかるかを決めます。委託先の変更、クラウドへの移行、オンプレミスへの戻しを想定した出口条件があると、長期の選択肢を維持できます。

OpenStackはOSSだから安全、または商用サポートだから安全、と単純には言えません。認証・認可、ネットワーク分離、TLS、イメージの検査、ハイパーバイザーの強化、秘密情報、監査ログ、バックアップ暗号化、脆弱性情報の確認とパッチ適用を運用に組み込みます。

個人情報、医療情報、金融情報、顧客機密を扱う場合は、個人情報保護法上の安全管理措置、委託先の監督、事故時の連絡・報告、データの所在と消去を法務・情報セキュリティ部門と確認します。政府調達や業界基準が関係する場合も、OpenStackの採用だけで適合するわけではなく、サービス提供者と運用体制を含む個別評価が必要です。

よくある質問

OpenStackの外注では、費用だけでなく、導入規模、社内の運用人材、移行対象、サポートの必要時間を合わせて考える必要があります。ここでは、発注前によくある疑問へ直接回答します。

OpenStackはオープンソースソフトウェアですが、発注費用が無料になるわけではありません。サーバー、ストレージ、ネットワーク、冗長化、設計、構築、監視、バックアップ、アップグレード、商用サポート、運用人材の費用が必要です。

外注は可能ですが、VM数が少なく、マルチテナント、APIによるセルフサービス、オンプレミス制御、将来の大幅な拡張が不要なら、マネージドIaaSや別の仮想化基盤の方が適する場合があります。PoCで運用工数と3年TCOを確認し、OpenStackを採用する合理的な条件を説明できる状態にしてから本番発注へ進みます。

単一ノードの検証なら1〜2か月、3〜5ノードの小規模本番なら3〜6か月、既存VM移行や分散ストレージを含む中規模基盤なら6〜12か月を目安にします。大規模・マルチサイト・DR案件は12〜24か月以上になる可能性があります。要件確定、機器調達、ネットワーク変更、移行停止時間、受入試験の範囲によって変わるため、候補会社へ工程別の根拠を提出してもらいます。

構築範囲と受入基準が固まっている作業は請負、調査、設計、PoC、技術支援のように不確実性が高い作業は準委任が基本です。実際には、要件整理・PoCを準委任、確定後の構築を請負、監視と障害対応を運用サービスに分ける方法が比較しやすくなります。契約条件は案件の実態に合わせて法務や専門家へ確認します。

まとめ

OpenStackを採用する理由が、単に「OSSで安そうだから」になっていないかを確認します。複数テナント、セルフサービス、API連携、オンプレミスでの制御、長期的な拡張性など、他の選択肢と比較して得たい価値を言葉にします。同時に、構築後のアップグレード、障害対応、脆弱性対応を社内で担うのか、委託先へ任せるのかを決めます。

候補会社へ同じRFPを渡し、初期構築費だけでなく、機器・サブスクリプション・監視・バックアップ・運用・アップグレードを含むTCOを比較します。成果物、SLA、責任分界、独自改造、契約終了時のデータ返却と他社移管まで確認できれば、導入後に「聞いていた範囲と違う」となるリスクを抑えられます。

OpenStackのシステムを発注・外注する際は、まず採用目的と規模を確認し、要件整理とPoCで不確実性を減らします。そのうえで、請負、準委任、マネージドサービスを工程ごとに使い分け、RFPには業務要件、技術要件、非機能要件、移行、セキュリティ、成果物、運用条件を記載します。

費用は、PoCで100万〜300万円、小規模本番で500万〜1,500万円、中規模で1,500万〜5,000万円、大規模で5,000万円〜2億円以上という推定レンジを出発点にできます。ただし、これは公開された国内統一相場ではないため、ハードウェア、ストレージ、移行、サポート、監視、アップグレードを含む3年から5年のTCOで比較します。最終的には、技術者の体制、SLA、成果物、責任分界、撤退・移管条件まで確認して委託先を決定します。

▼全体ガイドの記事
・OpenStackのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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