OpenStackの発注は、採用目的と要件を整理し、PoCと基本設計で不確実な点を検証してから、契約、構築、移行、運用移管へ進めるのが基本の流れです。
各段階の責任範囲を明確にしておくと、作業の抜けや追加費用の不透明化を防げます。
▼全体ガイドの記事
・OpenStackのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
OpenStackのシステム発注・外注の全体像
OpenStackは、サーバー、仮想マシン、ネットワーク、ブロックストレージなどをAPIで管理するIaaS基盤です。
発注先は、Linux、KVM、分散ストレージなどに対応できる企業になりやすいです。運用面では、ネットワーク、認証、監視、運用自動化への対応も求められます。候補には、SIer、OSSサポート会社、ディストリビューター、MSPが挙げられます。
発注範囲の広がり
見積では、基盤構築のほかに必要な作業範囲も含めて明確にします。
- 基盤構築：要件定義、サイジング、機器調達、OS・OpenStack導入
- 環境設定：Nova・Neutron、Ceph、認証連携、監視、バックアップ
- 導入後作業：移行、テスト、教育、保守
成果物には構成図、パラメータシート、AnsibleやTerraformなどのIaC、監視設定を含めます。
外注で失敗しないためには、別会社へ移管できる状態で納品されることが欠かせません。そのため、復元手順、障害時Runbook、更新手順、既知の制約、管理者教育の記録も納品に含めます。
発注前に確認する採用理由
OpenStackを採用するかは、自社が重視する利用条件と照らし合わせて決めます。
- セルフサービス：複数テナントへの提供
- データ管理：オンプレミスや専用設備での管理
- 統合・中立性：APIによる大量VM作成、計算・網・ストレージの統合
VMが少数で増加も見込めない場合は、マネージドIaaSや既存製品のほうが、短期間かつ低コストになる可能性があります。
OpenInfra Foundationの2025年報告では、本番利用コア数が5,500万超です（出典: OpenInfra Foundation「2025 Annual Report」、2025年）。
大規模での利用は安心材料になります。ただし、小規模企業に同じ構成が合うとは限らないため、利用量と運用体制で判断します。
OpenStackの発注形態の選び方
要件が確定した後の構築は請負、不確実性の高い設計や検証は準委任、監視と障害対応は運用サービスで、契約を分けます。
工程ごとに成果物と責任範囲を定めれば、見積の比較と品質管理の両方がやりやすくなります。
請負契約の完成条件と受入基準
指定した構成を構築し、検査に合格して引き渡す工程には、請負が適しています。
- 冗長化：コントローラーノードを冗長化する
- 起動確認：指定イメージからVMを起動できる
- ネットワーク：管理用とテナント用を分離する
- 復旧試験：障害試験後の復旧時間を定める
受入基準は、数値や操作手順で具体的に決めます。
VMware移行台数、ネットワーク制約、Ceph性能、権限設計が未確定のまま固定価格で契約すると、後からの変更が増えます。そこで、契約前に調査とPoCを置き、確定した範囲だけを請負にすると、追加費用の不透明化を防げます。
準委任契約が向いている設計・検証・技術支援
準委任は、専門家の稼働に対して、設計、調査、レビュー、技術支援を依頼する形式です。
- 採用検討：OpenStackの採用可否、ディストリビューション比較
- 設計検討：サイジング、既存網との接続
- 移行検討：移行方式の検討
成果物に加えて、会議体、担当者のスキル、稼働時間、レビュー方法、課題管理表の更新頻度も契約に記載します。稼働時間を決めても、それだけで設計品質が保証されるわけではありません。そのため、月次報告と次工程へ進む判断条件も定めておきます。
マネージドサービスによる運用責任の外部化
構築契約とは別に、継続運用の委託条件を確認します。
- 監視・対応：24時間365日の監視、一次対応、障害切り分け
- 日常運用：バックアップ確認、パッチ適用、容量管理
- 報告：定期レポート
- 判断・承認：停止判断者と緊急変更の承認者
- 対応期限：脆弱性通知から適用までの時間、計画停止の連絡、バックアップ・復元試験の担当者
Rackspace Technologyは2025年7月、専用のマネージドOpenStack Businessを発表しました。
出典: Rackspace Technology「Rackspace OpenStack Business」、2025年。対応範囲は、SLAや運用設計書で確認します。
RFP作成前に整理すべきOpenStackの要件
RFPは、各社に同じ前提で提案と見積を依頼する文書です。
RFPには、実現したいこと、受入条件、運用担当を具体的に書きます。一方で、まだ決まらない事項は提案で補ってもらう事項として分けておくと、各社の設計力も比べられます。
利用者と業務影響から見る業務要件
どの部門が何のために使うのかを明らかにします。用途によって必要な可用性や拡張性は異なるため、まず用途を押さえておきます。
- 利用状況：利用者数、テナント数、1日あたりのVM作成数
- 環境条件：OS、GPUやベアメタルの有無、将来3年の増加率
- 業務用途：開発、顧客向けサービス、分析、AI・高性能計算、災害対策
停止時の影響を踏まえ、目標復旧時間のRTO、復旧時点のRPO、許容停止時間を整理します。そのうえで、連絡先と業務の優先順位を定め、冗長化する範囲を決めます。
冗長化の対象が、コントローラー、ネットワーク、ストレージ、電源、データセンターのどこまでかを明記します。
技術要件の構成要素と接続条件
OpenStack公式の論理構成では、各サービスが共通Identityで認証し、API、メッセージブローカー、DBなどと動作します（出典: OpenStack公式「Logical architecture」、2026年）。
RFPには、採用するサービスと、必要な機能や性能を書いておきます。
- OpenStackサービス：Nova、Neutron、Glance、Cinder、Swift、Keystone、Horizon、Ceilometer
- 社内接続：AD・LDAP、DNS、IP管理、ルーター、FW、ロードバランサー
- 運用連携：ストレージ、バックアップ、監視、CI/CD
- VMware移行：ゲストOS、スナップショット、ネットワーク、バックアップ、ライセンス、停止時間の差異
非機能要件の数値と試験方法
非機能要件には、可用性、性能、拡張性、セキュリティが含まれます。このほか、運用性、移行性、監査性も対象です。
- 性能：VM払い出し時間、同時作成台数
- 障害対応：障害検知時間
- バックアップ：保持世代数、復元試験の頻度
- セキュリティ：OpenStack公式Security GuideのPublic、Guest、Management、Dataの4領域
- 対策：TLS、認証・認可、テナント分離、監査ログ、ハイパーバイザー強化（出典: OpenStack公式「Security Guide」、2026年）
個人情報や顧客機密を扱う場合は、委託先のアクセス権、ログ保管場所、事故報告、データ消去についてRFPに記載します。
OpenStackの発注・外注を進める手順
発注は、採用判断からPoC、設計、構築、移行、受入、運用移管までを、一つの流れで管理します。
価格だけで決めて技術検証を省くと、本番後に性能不足や運用負荷が見つかり、追加費用につながりやすくなります。
技術領域と運用範囲で見る候補会社
候補会社については、実績と、希望する版や構成を現在サポートできるかを確かめます。
- 基盤技術：ディストリビューション、KVM、Ceph、OVN・Open vSwitch、Linux
- 自動化・運用：Ansible、Terraform、監視、バックアップ、ネットワーク設計
- 実績・体制：実績の年、担当チーム、サポート可否
同じRFPを複数社へ渡して比べます。課題と得意領域を対応させ、大規模な専用基盤ならディストリビューターや大手SIer、OSSの解析なら専門会社、運用の外部化ならMSPを候補にします。
PoCと基本設計による不確実性の低減
PoCでは、本番前に基盤操作と継続運用を小さく試します。
- 基盤操作：VM作成、ネットワーク、認証、イメージ管理、API操作
- 継続運用：バックアップ復元、ノード障害、監視通知
想定性能、復旧時間、運用手順、内製担当者の理解度が基準を満たすかを確認します。画面からVMを作れるかは、その一部にすぎません。
成果物には、採用・不採用構成、測定条件、結果を記録します。残課題、追加費用の可能性、基本設計への引継ぎ事項も残します。
PoCがうまくいかなかった場合に本番契約を見直せるよう、検証と本番の契約を分けておく方法もあります。
段階的な移行と受入試験
移行は、開発・検証環境、停止の影響が小さい業務、重要業務、災害対策環境の順に進めます。
- 既存VM、OS互換性、ネットワークアドレス、ストレージ性能、バックアップを洗い出す
- 監視、ライセンス、切り戻し方法を確認し、移行リハーサルで停止時間を実測する
- 試験結果と未解決の制約を確認し、受入者の承認記録を残す
受入試験では、正常系だけでなく、コントローラー障害、コンピュートノード障害、ストレージ逼迫、認証停止、ネットワーク断も試します。さらに、バックアップ復元や権限の誤設定も確認し、期待結果と実測結果を記録します。
運用移管とアップグレード計画までを含む受注範囲
公式リリースは約6か月周期です。2026.1 Gazpachoは2026年4月1日公開の維持版です（出典: OpenStack公式「OpenStack Releases」、2026年）。
- 採用版：採用するリリース
- 保守期限：いつまで保守するか
- 更新方法：次のリリースへの移行方法
これらは発注時に決めておきます。そのうえで、引継ぎの際は、構成管理、CI/CD、秘密情報、証明書更新、監視閾値、容量計画を共有します。
- 運用情報：障害連絡網、月次点検票、パッチ履歴
- 担当者支援：操作研修、障害訓練
発注先が変わっても運用を続けられる状態かを確認します。
契約書で定める責任分界と成果物
アプリ、ゲストOS、仮想化ホスト、OpenStack、ネットワーク、ストレージなどでは、責任が互いに重なります。
「基盤は委託先が対応」という書き方のままだと、障害の調査で誰の担当かが曖昧になります。そこで、設計、変更、監視、復旧、脆弱性対応を、レイヤーごとに定めておきます。
成果物と対象外作業の一覧
成果物は、設計・構築、試験・移行、運用・管理に分けて確認します。
- 設計・構築：設計書、構成図、設定値一覧、IaC
- 試験・移行：試験仕様と結果、移行計画
- 運用・管理：バックアップ・セキュリティ設計、手順、Runbook、教育資料、ライセンス、既知の問題
納品物にソースコードや設定を含めるのか、標準テンプレートだけにとどめるのかも明記します。
対象外作業は別料金になる場合があります。そのため、機器設置、回線、データセンター、既存網・アプリ改修については、契約の前提条件として合意しておきます。データ整備、休日移行立会い、追加試験、商用サブスクリプションも、どちらが負担するかを決めておきます。
SLAと変更管理による運用中の期待値の調整
SLAと変更管理で、運用中の対応条件と追加費用の境界をそろえます。
- 応答・復旧：受付時間、一次回答、復旧目標、重大度の定義
- 連絡・現地対応：連絡手段、エスカレーション、計画停止、報告期限、部品交換、オンサイト対応
- 変更手順：申請、影響評価、承認、実施、試験、記録、切り戻し
- 追加要件：緊急変更の扱い、単価、見積期限、優先順位
「24時間対応」と書かれていても、常駐か電話受付か、復旧まで含むか、部品交換やオンサイト対応を含むかは、それぞれ確認が必要です。
追加要件の単価、見積の再提出期限、優先順位も契約に含めます。そうすれば、口頭での依頼による費用増加を防げます。
OpenStackの発注費用相場とコストの内訳
OpenStackの国内統一相場は公開されていません。そのため、業務システムの目安や構成要素、公開料金例をもとにした予算の仮置きとして扱います。
金額は、ノード数、冗長化、容量、GPUによって変わります。そのほか、移行台数、設備、サポート、運用時間も金額を左右します。確約された相場ではありません。
規模別の初期構築費の目安
規模別の予算仮置きは次のとおりです。類似システムからの推定であり、個別見積の代わりにはなりません。
- 学習・PoC・単一ノード：100万〜300万円程度
- 小規模本番：3〜5ノードで500万〜1,500万円程度
- 業務基盤：5〜20ノード程度で1,500万〜5,000万円程度
- 大規模：5,000万円〜2億円以上の場合あり
小規模本番の目安は、高可用性、基本監視、バックアップ、運用手順を含む場合のものです。既存機器を使えるかどうかや、設計と教育を含むかどうかで金額は変わります。
業務基盤は、Ceph、複数環境、認証・網連携、IaC、既存VM移行を含む想定です。大規模案件では、マルチサイト、DR、GPU、ベアメタル、24時間365日運用、大量移行を含む場合があります。
ランニング費用の五つの項目
ランニング費用は、基盤、ソフトウェア、運用作業に分けて確認します。
- 機器・場所：機器償却またはホスティング料
- ソフトウェア：OSや商用ディストリビューションのサブスクリプション
- 設備：電力、回線、データセンター
- 監視系：監視、バックアップ、ログ保管
- 保守運用：障害対応、パッチ、更新、教育
OSSは無料でも、運用費や人材費は必要です。
Canonicalの料金例ではVM種別により1時間0.0132〜0.1059米ドルです（出典: Canonical「Charmed OpenStack」、確認時点2026年）。
この例は、3年間の機器、一般的なホスティング、フルマネージド費用を配賦したものです。機器、地域、構成、給与費によって変わるため、日本の小規模導入にはそのまま当てはめられません。
一般的な業務システムの保守費は初期費用の年15〜20％程度という目安がありますが、OpenStack固有の公定相場ではありません。
保守費は、対応時間、ノード数、変更回数、更新、オンサイト、SLAによって変わります。そのため、月次作業と上限を確認しておきます。
初期費用ではなく3年から5年のTCOでの比較
初期構築費だけでなく、3年から5年のTCOで比べます。
- 継続費：機器更新、容量追加、サポート、運用委託、時間外・脆弱性対応
- 終了までの費用：アップグレード、教育、撤去・移管、自社運用の社内人件費
- 提案前提：ノード数、VM数、ストレージ容量、可用性、対応時間を統一
- 調達案：機器購入、マネージド利用、既存設備再利用
3年・5年の支出、残存資産、契約終了時のデータ返却費を並べて見ると、価格の前提が見えてきます。
委託先の選定と見積比較で確認するポイント
同じ要件に対する前提、作業範囲、リスク説明、運用体制、成果物を比べて選びます。
設計と運用の品質は将来の費用に影響するため、技術者との質疑応答も判断材料になります。
担当チームの周辺技術の守備範囲
担当チームが周辺技術と障害対応の経験をどこまで持つかを確認します。
- 基盤技術：Nova・Neutron、Linux、KVM・QEMU、Ceph、DB、RabbitMQ
- 接続・運用：L2・L3網、ロードバランサー、監視、バックアップ、IaC
- 障害対応：症状、切り分け、暫定・恒久対応、再発防止
現行リリースへの対応や更新の経験も確認します。公式リリースは6か月周期です。そのため、古い版の構築経験だけでは運用力を判断しきれません。
退職や交代に備え、複数名体制、代替担当、エスカレーション先を提案書に記載してもらいます。
見積書の作業と前提の比較
見積は、工程と費用項目を分けて比べます。
- 作業工程：要件定義、調査、設計、PoC、構築、試験、移行、教育、運用設計、保守開始
- 人件・諸経費：役割、期間、工数、単価、諸経費
- 個別費用：機器、ライセンス、クラウド、税、予備費
- 追加作業：想定ノード数超過時の追加単価、VM移行1台あたり、休日作業費
- 追加運用費：データ転送、監視対象追加、サポート更新、アップグレード
「一式」や「別途」が多い見積では、含まれる範囲を質問します。価格差が大きいときは、値下げの交渉に入る前に、同じ範囲で見積もられているかを確かめます。
ベンダーロックインと撤退条件
独自パッチや運用ツールへの依存を確認し、移管しやすい条件を整えます。
- 独自要素：標準API、改造箇所と理由、上流還元の可否
- 納品物：設定とコード
- 返却データ：VMイメージ、ボリューム、バックアップ、ログ、構成情報、IaC、証明書、アカウント情報
契約終了時の返却形式と消去費用を定めておきます。委託先の変更、クラウド移行、オンプレミス復帰を想定して出口条件を決めておくと、選択肢を残せます。
セキュリティと法令対応の確認範囲
OSSや商用サポートがあるという理由だけでは、安全性は判断できません。安全性は、製品の種類ではなく、次の対策が講じられているかで確認します。
- 基盤対策：認証・認可、網分離、TLS、イメージ検査、ホスト強化
- 情報管理：秘密情報、監査ログ、バックアップ暗号化
- 脆弱性対応：情報確認とパッチ適用
個人・医療・金融情報や顧客機密を扱う場合は、個人情報保護法上の安全管理措置、委託先の監督、事故時の連絡・報告を確認します。
データの所在と消去についても、法務部門や情報セキュリティ部門と確認します。政府調達や業界基準に適合するかは、OpenStackの採用とは別に判断します。提供者と運用体制も、個別に評価します。
よくある質問
費用、導入規模、社内人材、移行対象、サポート時間を合わせて考えます。
OpenStackは無料なので発注費用も安くなりますか？
OpenStackはOSSですが、発注費用が無料になるわけではありません。サーバー、ストレージ、ネットワークが必要です。加えて、冗長化、設計、構築、監視、バックアップも必要です。
OpenStackの更新、商用サポート、運用人材にも、費用がかかります。
小規模な会社でもOpenStackを外注できますか？
外注は可能です。VM数が少なく、マルチテナントやAPIによるセルフサービスが不要な場合もあります。
オンプレミスでの制御や将来の大幅な拡張が不要なら、マネージドIaaSや別の仮想化基盤が適する場合もあります。
PoCで運用工数と3年TCOを確認して、採用の合理性を説明できてから、本番発注へ進みます。
OpenStackの発注から本番稼働まで何か月かかりますか？
本番稼働までの期間は、規模や移行条件によって異なります。
- 単一ノード検証：1〜2か月
- 小規模本番：3〜5ノードで3〜6か月
- 中規模：VM移行や分散ストレージを含み6〜12か月
- 大規模・マルチサイト・DR：12〜24か月以上の場合あり
期間は、要件確定、機器調達、ネットワーク変更、移行停止時間、受入試験の範囲によって変わります。そこで、候補会社には工程別の根拠を提出してもらいます。
請負と準委任はどちらを選べばよいですか？
構築範囲と受入基準が確定した作業は請負、不確実性の高い調査・設計・PoCは準委任が基本です。
要件整理とPoCは準委任、確定後の構築は請負、監視と障害対応は運用サービスという分け方もできます。
契約条件は案件に合わせて、法務や専門家へ確認します。
まとめ
発注前に固める採用理由と運用体制
採用理由を「OSSで安そうだから」で終わらせず、複数テナント、セルフサービス、API連携など、得たい価値を明確にします。
アップグレード、障害、脆弱性への対応は、社内で担うか委託先に任せるかを決めておきます。
同じ前提と出口条件での見積比較
採用目的と規模を確認し、要件整理とPoCで不確実性を減らします。
- 発注形態：請負、準委任、マネージドサービスを工程ごとに使い分ける
- RFP：業務・技術・非機能要件、移行、セキュリティ、成果物、運用条件を記す
- 費用目安：PoCで100万〜300万円程度、小規模本番で500万〜1,500万円程度
- 大きな規模：中規模で1,500万〜5,000万円程度、大規模で5,000万円〜2億円以上になる可能性
費用は類似システムからの推定で、国内統一相場ではありません。機器、ストレージ、移行、サポート、監視、アップグレードを含む3年から5年のTCOで比べます。
技術者体制、SLA、成果物、責任分界を確認します。そのうえで、独自改造、データ返却、他社移管、撤退条件も確かめ、委託先を決めます。
▼全体ガイドの記事
・OpenStackのシステム開発の完全ガイド
▼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を創業。