OpenStackのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

OpenStackのシステム開発は、要件を整理して方式を選び、設計・開発とテストを進めたうえで、段階的に移行して運用に定着させる流れで進みます。運用担当者を早い段階から関わらせ、PoCで不確実性を減らしておくと、後戻りの少ない基盤になります。

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

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

OpenStackのシステム開発の全体像

OpenStackは、データセンターの計算資源、ネットワーク、ストレージをプール化し、APIや画面から仮想マシンやベアメタルを提供するIaaS基盤です。

OpenStackが支えるのは、プライベートクラウドや通信事業者のNFV基盤、研究・AI向け計算基盤などです。業務アプリそのものを作るためのものではないため、この違いを押さえると開発範囲を見積もれます。

OpenInfra Foundationの2025年年次報告では、利用者調査に基づく本番利用コア数が5,500万を超えたと報告されています（出典：OpenInfra Foundation「2025 Annual Report」、2025年）。

利用実績が大きいことと、自社への適性は別の論点です。採用は保守体制と運用要件をもとに判断し、古い技術だからといって候補から外す必要はありません。

主要サービスとシステム構成

Novaは仮想マシンを作成・配置し、Neutronは仮想ネットワークやルーターを管理します。また、Keystoneは認証・認可・テナントを管理し、Glanceは仮想マシンのイメージを扱います。

• ストレージ：Cinderは永続ブロック、Swiftはオブジェクトを扱います。
• 画面：Web画面はHorizonが提供します。
• 追加機能：必要に応じて、Octavia、Ironic、Manila、Barbicanを加えられます。

構成は層ごとに分けて設計します。具体的には、制御・計算の層と、ネットワーク・ストレージの層、運用の層があります。ネットワーク層はNeutronとOpen vSwitchなどで組み、各層の冗長化も決めます。さらに、障害ドメインや容量拡張の方法も決めて、本番運用に備えます。

採用に向く企業と向かない企業

セルフサービスや資源管理の要件を見て、OpenStackが適するかを判断します。

• 複数テナント：各テナントへ仮想マシンを提供したい場合。
• 設備管理：データ所在地や構成を細かく管理したい場合。
• 資源統合：VM、ベアメタル、ストレージをAPIで扱いたい場合。

標準APIを長く使いたい場合や、特定の仮想化製品への依存を抑えたい場合も候補です。一方で、VMが数台から10台未満で増加の予定も少ない場合は、別の方式が候補になります。

セルフサービスやマルチテナントが不要な場合や、インフラ担当者を確保できない場合も、別の方式が候補になります。こうした場合、マネージドIaaSやPaaSの方が短期間かつ低コストで済む可能性があります。

なお、Kubernetesはコンテナ管理、OpenStackはIaaS基盤です。コンテナ中心ならKubernetes、VMや物理資源のセルフサービス中心ならOpenStackを検討します。

OpenStackのシステム開発の進め方

開発は6つのフェーズで進みます。運用担当者を早い段階から参加させ、PoCで不確実性を減らします。

運用設計を後半で始めると手戻りが大きくなるため、運用の検討は初期から進めます。

6つのフェーズは、要件の確定から運用の仕組み化まで、それぞれ異なる作業を担います。

1. 要件整理：採用目的と非機能要件の決定
2. 方式選定：構築方式と構成の比較
3. 設計・開発：基盤と自動化の構築
4. テスト：正常系と障害時の動作の確認
5. 段階移行：低リスクの環境からの稼働
6. 運用定着：手順とアップグレードの仕組み化

各フェーズの完了条件を文書にしておくと、次の工程へ進む判断が明確になります。

フェーズ1：要件整理と採用目的・非機能要件の確定

業務上の目的を具体的にすることから始めます。目的がはっきりすると、OpenStackが必要な要件と、他のサービスでも満たせる要件を分けられます。

目的の例は、払い出しを半日から30分以内にすること、部署ごとの利用量を可視化すること、顧客データを社内設備から出さずに運用することです。

要件整理では、規模や可用性などの条件を洗い出し、次の観点ごとに記録します。

• 規模・性能：VM数と増加率、CPU・メモリ・GPUのピーク、容量とIOPS、同時利用者数。
• 可用性：許容停止時間、RTO・RPO、テナント分離。
• 既存環境：認証、VMware・KVM、ネットワーク接続。
• 運用・保護：機密度、ログ保持、バックアップ世代、サポート時間。

平均値に加えて、月末やキャンペーン、災害復旧時の最大値も記録します。成果物は業務・非機能要件と現行環境図です。ほかに、データ分類、移行対象台帳、責任分界案を作ります。

イメージの更新者や脆弱性パッチの適用時間、障害時の一次切り分け担当は、この段階で決めておきます。未決定のまま進めないことが大切です。

フェーズ2：方式と構成の選定

要件に合う方式を選ぶため、構築・提供の形態と運用条件を並べて比較します。

• 方式：自前構築、商用ディストリビューション、マネージド専用クラウド、既存クラウド継続。
• 自前構築：Kolla-Ansible、OpenStack-Ansible、Charmed OpenStackなど。
• 商用製品：リリース、サポート期間、更新方法、Linux・Ceph・KVM・機器との対応。
• 比較軸：3年または5年のTCO、工数、復旧、サポート、IaC、標準API、改造、移管。

小規模で単純なVM環境では、冗長化や監視を含む固定費が割高になる場合があります。

PoCでは、VMを起動するだけでなく、構成・運用・障害対応の動作も確認します。

• 検証項目：イメージ登録・更新、権限変更、ネットワーク分離、バックアップ復元。
• 障害・連携：計算ノード障害、監視アラート、API、証明書更新、ローリングアップグレード。
• 評価指標：払い出し・復元・作業・切り分け時間、1VMあたりの月額TCO。

フェーズ3：設計・開発による基盤と自動化の構築

設計・開発では、基盤の配置と可用性を決めたうえで、ネットワーク、セキュリティ、自動化を具体的にし、納品物までを一貫して定めます。

• 構成設計：制御・計算・通信・保存・監視・バックアップの論理・物理配置。
• 可用性：コントローラー冗長化、Ceph等の分散ストレージ、電源・ラックの障害ドメイン。
• ネットワーク：管理網とデータ網を分離し、容量拡張単位を決める。
• セキュリティ領域：公式ガイドの4ドメインを自社網に対応付ける。
• 自動化：AnsibleやTerraformで再現可能な構築にする。

公式ガイドのセキュリティドメインは、Public、Guest、Management、Dataの4つです（出典：OpenStack公式「Security Guide」、2026年7月更新）。

TLS、Keystoneの認証・認可、RBAC、テナント間の通信制御を設計します。あわせて、イメージの脆弱性スキャンや秘密情報と鍵の管理を明記します。監査ログやバックアップ暗号化も、同じ設計書に残しておきます。

安全性は、上の項目を具体的に決めてはじめて確保されます。手作業による設定変更は再現できないため、復旧や更新の妨げになります。

納品対象は、構成図、パラメータシート、API・ポート一覧です。加えて、IaCリポジトリやイメージ手順を渡します。監視・バックアップの設定や変更履歴、既知の制約も、納品範囲に含めます。

フェーズ4：テストによる正常系と障害時の動作の確認

テストでは、利用操作と障害時の挙動をシナリオにまとめ、結果を本番移行の判断材料にします。

• テスト区分：単体、API・認証連携、総合、業務部門の受入。
• 利用操作：VMの作成・削除・停止・再起動、ボリューム接続、網・権限変更、イメージ更新。
• 障害試験：制御・計算ノード停止、ストレージ障害、経路切断、認証停止、バックアップ復元。

障害試験では、RTO・RPOを測り、切り替えと切り戻しが実際にできるかを確かめます。結果は画面キャプチャやログと合わせて残し、未解決の制約は移行の判断に使います。

受入条件には、障害の検知と復旧時間、性能、権限を含めます。ほかに、ログ検索、復元、手順の再現性も条件に入れます。

性能試験では、ピーク時のCPU待ちとストレージ遅延を記録します。帯域と同時作成数も測り、容量計画の基準にします。

フェーズ5：段階移行によるリスクの抑制

移行は段階を踏んで進め、まず対象の順序と切り戻し条件を明確にします。互換性や承認者も、あらかじめ決めておきます。

• 移行順：開発・検証、低リスク業務、バックアップ・DR用途、重要業務。
• 互換性：VMware等からの移行時はOS、ディスク、網、バックアップ、監視、ライセンス、停止時間を確認。
• 計画：VM優先順位、事前バックアップ、方法、停止時間、切り戻し、担当、連絡網、利用者告知。
• 稼働判定：未解決障害、制約、暫定対応、引き継ぎ、監視・バックアップを確認。

切り戻しの条件は数値で決めておきます。たとえば、ログイン不可が15分続く場合や、決済遅延が基準を超える場合などです。

稼働の承認は、開発会社だけに任せず、顧客側の承認者、運用責任者、セキュリティ担当者が行います。各担当が個別に承認する形にすると、稼働後に「聞いていない」という食い違いを防げます。

フェーズ6：運用定着とアップグレードの仕組み化

日常の運用と更新の計画、引き継ぎ資料を整え、改善を続けられる状態にします。

• Runbook：申請、VM払い出し、イメージ承認・廃棄、権限の洗い出し、容量追加。
• 日常対応：証明書更新、脆弱性対応、障害切り分け、エスカレーション、月次報告。
• 引き継ぎ：設計書、IaC、設定、監視、ログ、障害履歴、更新手順、制約、責任分界。
• 独自改造：上流へ戻せるか、保守期限、他社移管可否を記録。

担当者が手順を実際に使い、そこで出た改善点を手順に反映して、初めて運用が定着します。

設計書やIaC、設定値を、顧客側の担当者が読める状態にしておきます。監視ルールやログの見方、障害履歴、更新手順も、残しておきます。

OpenStackは6か月ごとにリリースされ、2026.1 Gazpachoは保守対象のSLURP版です。

2026.1は2026年4月1日に公開され、2026.2 Hibiscusは同年9月30日予定です（出典：OpenStack公式「OpenStack Releases」、2026年8月確認）。

版を選ぶ際は、最新かどうかに加えて、サポート期限と周辺ソフトとの互換性を確認します。更新方法や検証環境、停止時間も、計画に含めます。

OpenStackのシステム開発にかかる費用相場

OpenStack単体の国内統一相場や、公開された標準見積はありません。そのため、業務システムの一般的な目安、必要な構成要素、公開TCO試算に基づく予算の仮置きを、RFP前の参考にします。

ハードウェア、データセンター、回線は、条件により別途増額されます。GPUや既存VMの移行も、条件によって増額の対象になります。商用サブスクリプションや24時間365日運用も、条件により増額されます。

規模別の初期構築費と期間の目安

規模ごとの推定レンジは、対象範囲と期間を合わせて見ます。PoCから大規模案件までを4つの区分に分けて示します。

• PoC・単一ノード：100万〜300万円、1〜2か月程度。
• 小規模本番：3〜5ノードで500万〜1,500万円、3〜6か月。
• 中規模業務基盤：5〜20ノードで1,500万〜5,000万円、6〜12か月。
• 大規模案件：5,000万円〜2億円以上、12〜24か月以上となる可能性。

PoCは、基本APIやVM作成、ネットワークの確認が中心で、本番の冗長化や移行は含みません。

小規模本番の目安には、HA設計と、Nova・Neutron・Keystone・Cinderの構成が入ります。監視とバックアップも対象です。

中規模では、Cephなどの分散ストレージや複数環境を想定します。既存の認証やネットワーク、DBとの連携も対象です。IaCや移行も含む想定です。

大規模では、複数拠点やDR、GPUを含む場合があります。ベアメタルや監査の要件も入ることがあります。24時間運用や段階移行も、含まれる場合があります。

費用は対象と期間からの推定で、資料の整備状況や移行台数、停止可能時間によって変わります。GPU・高速ストレージや24時間サポートを含めるかでも変わります。

見積もりは、構成設計と移行、テストを一つにまとめず分けてもらいます。教育と運用設計も、別々の項目にします。

ランニング費用と5年TCOの考え方

5年TCOを比べるときは、初期費用とは別に、運用の要素と前提条件を分けて整理します。

• 基盤・契約：機器償却またはホスティング、Linux等の契約、商用サポート。
• 日常運用：監視、バックアップ、脆弱性スキャン、障害対応、更新、教育、運用委託。
• 5年TCO：初期費用、5年分の運用費、機器更新、サポート、移行・撤退、教育。

比べる際は、ライセンス料に加えて、物理資源や冗長化も含めます。人材や保守も、同じ比較に入れます。

Canonicalは、ハードウェアや一般的なホスティング費、フルマネージドサービスを3年間で配賦したVM費用を試算しています（出典：Canonical「Charmed OpenStack」、2026年8月確認）。

1vCPU・4GBは1時間あたり0.0132米ドル、8vCPU・32GBは1時間あたり0.1059米ドルです。

試算はベースラインの例で、機器や地域のホスティング費、給与によって変わります。日本の単独導入価格として扱わないでください。

保守費を初期費用の年15〜20％程度から仮置きする考え方は、業務システム共通の目安です。

これはOpenStackの運用委託費を保証する相場ではありません。24時間365日対応や厳格なSLAは、別見積もりにします。現地対応や複数拠点DRも、別に見積もります。

OpenStackの見積もりを取る際のポイント

見積もりを依頼する際は、ノード数に加えて、運用の責任範囲と移行の難しさも伝えます。

RFPには、現行構成図、VM台帳、利用者・テナント数を記載します。容量と増加率、ネットワーク、RTO・RPOも記載します。

セキュリティ基準と監視・バックアップの状況も書き添えます。希望稼働時期と社内運用の人数も、記載します。

要件と成果物の範囲のそろえ方

各社を同じ条件で比べるため、見積もりに含める成果物を明記します。

• 設計・構築：設計書、構成図、パラメータシート、IaC。
• 運用準備：イメージ手順、監視・バックアップ設定、Runbook。
• 移行・引き継ぎ：テスト仕様、移行計画、教育資料、引き継ぎ記録。

ソースや自動化スクリプトの所有権、リポジトリの引き渡し、独自改造の範囲も契約前に決めます。

物理機器、データセンター、回線が対象外になる場合があります。VM移行やGPUドライバーは、除外されることがあります。商用ライセンスやバックアップ・監視製品も、見積もりに入らないことがあります。

24時間対応や休日作業も含まれないことがあります。対象外を把握して、追加費用を予算に反映しておきます。

発注先の実績と責任分界の比較

発注先は、基盤に対応できる会社から選びます。アプリのスクラッチ開発会社とは、対応範囲が異なります。

各社の実績は、要件定義や設計、構築の段階と、移行、運用・保守の段階に分けて比べます。役割分担も確認します。

• 候補先：SIer、OSSサポート会社、ディストリビューター、MSP。
• 技術・実績：対応製品・版、Ceph・KVM・Neutron、VMware移行実績。
• 支援範囲：設計から運用までの範囲、24時間対応、障害窓口。
• 責任分界：機器、OpenStack、OS、アプリ、網、バックアップ、脆弱性、更新。

責任分界表で各項目の監視・判断・復旧担当を明確にします。個人の経験だけに頼らず、チーム体制と担当交代時の引き継ぎ方法も確認します。

追加費用とベンダーロックインの抑制

費用が増える要因は見積もり時に確認し、変更条件を明確にします。移行対象の増加、ネットワーク変更、性能不足による機器追加は、費用増につながります。

独自機能の本体改造や、後からの24時間運用も、費用を押し上げる要因です。

• 見積条件：前提、数量、単価、作業時間、リスク予備費、変更時単価、再見積もり条件。
• 移管性：標準API・部品・再現可能なIaCを優先し、改造の目的・影響範囲・保守期限・更新方針を記録。
• 契約事項：設計書・設定・スクリプト・監視データ・障害履歴の引き渡し、移管協力、ライセンス・知財、データ返却・消去。

OpenStackのシステム開発でよくある質問

採用の可否や期間、人材、既存環境からの移行について、発注前に判断する材料をまとめます。

OpenStackはOSSなので無料で導入できますか？

ソフトウェアはオープンソースですが、システム全体を無料で運用できるわけではありません。

物理機器、ネットワーク、ストレージのほか、冗長化や監視も必要です。さらに、バックアップやサポートにも費用がかかり、更新や教育も対象になります。ライセンス料と構築・運用を含むTCOを分けて比べます。

OpenStackのシステム開発にはどのくらいの期間がかかりますか？

PoC・単一ノードは1〜2か月、小規模本番は3〜6か月、中規模は6〜12か月、大規模・複数拠点は12〜24か月以上が推定目安です。

VM移行やネットワーク変更、DRが加わると、期間はさらに延びます。審査や利用者教育も期間を延ばす要因になるため、要件整理や受入、段階移行も計画に含めます。

社内にOpenStackの専門人材がいなくても導入できますか？

導入は可能ですが、構築後の運用体制を先に決めておく必要があります。たとえば、設計・構築だけを外部に委託し、障害解析や更新は社内で担う方法があります。

24時間監視までMSPに委託するかどうかで、費用と契約が変わります。IaCとRunbookを整えるほか、教育や伴走支援も使い、担当が替わっても運用できる状態を目指します。

VMware環境からOpenStackへ移行できますか？

移行できる可能性はありますが、全VMを同じ手順で移せるとは限りません。

• 事前確認：OS、ディスク形式、ネットワーク、バックアップ、監視、ライセンス、停止時間を台帳で洗い出し。
• 試行：開発・検証環境や低リスクのVMからの段階的な試行。
• 本番準備：事前バックアップ、移行後の性能確認、切り戻し条件、旧環境の保持期間を決めます。

まとめ

OpenStack開発は6段階で進みます。要件整理に始まり、運用定着で仕上げます。

採用理由は、セルフサービスやマルチテナントといった要件に結びつけて確認します。データ主権やAPIによる資源管理も、判断材料になります。VMが少なく人材も限られる場合は、マネージドIaaSなども比べます。

予算の仮置きは、PoCが100万〜300万円、小規模本番が500万〜1,500万円です。中規模は1,500万〜5,000万円、大規模は5,000万円〜2億円以上です。

上の金額は、国内の統一相場ではなく、条件によって変わる目安です。金額は、機器や移行、サポートの扱いで左右されます。監視やバックアップ、24時間運用の有無も、費用に響きます。

見積もりでは、構築費に加えて5年TCOを確認します。責任分界と成果物を確かめ、更新と他社への移管の条件も見ておきます。PoCで復旧や運用工数を測り、役割を契約とRunbookに記します。

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

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