プライベートクラウドとは？パブリック・オンプレとの違いとメリット

プライベートクラウドという言葉は、専用サーバーやオンプレミスと混同されやすく、社内で検討を始めた途端に意味の解釈がずれてしまいます。

この記事では、プライベートクラウドが指すもの、パブリッククラウドやオンプレミスとの違い、構築形態ごとの利点と注意点、選定時に確認すべき項目までを解説します。

プライベートクラウドとは？意味と基本の仕組み

プライベートクラウドは、単一の企業や組織が専用で利用するクラウド環境です。専用サーバーを1台借りることと同じだと思われがちですが、それだけでは条件を満たしません。必要なときに必要な量のリソースを利用者自身で確保できることに加え、複数の物理機器のリソースをまとめて一つの資源として扱えることが要件です。所有・管理の主体や設備の設置場所は、自社に限られません。第三者が管理する形や、社外の施設に設置する形も含まれます。

プライベートクラウドの定義（単一組織専用という意味）

プライベートクラウドは、単一の組織が専用で利用するために用意されたクラウド環境です。米国国立標準技術研究所（NIST）の定義では、プライベートクラウドは事業部門など、組織内の複数の利用者による専用利用を目的としてプロビジョニング（利用できる状態への準備）されます。その所有・管理・運用を担うのは、当該組織、第三者、またはその両者です。また、クラウド基盤はオンプレミスとオフプレミスのどちらにも設置でき、物理的な機器を自社で保有することは必須条件ではありません。

たとえば、経理部門と人事部門が同じ基盤上の異なる区画を使っていても、利用範囲が一社に限られていれば定義に当てはまります。AWSもプライベートクラウドを、すべてのリソースが分離され、単一の組織によって管理される環境と説明しています。また、内部クラウドや企業クラウドとも呼ばれます。

物理機器を専有しているかではなく、利用範囲が単一の組織に限られているかどうかが判断の軸です。

混同されやすい「VPC（仮想プライベートクラウド）」との違い

VPCとプライベートクラウドは、名称が似ていますが、指すものは異なります。Amazon VPCは、パブリッククラウド上に構築する、論理的に分離された仮想ネットワークです。利用者はIPアドレスの範囲やサブネットを設定し、ルーティングやゲートウェイ、フローログによる通信記録の取得などを制御できます。一方、プライベートクラウドは、利用範囲を単一の組織に限定したクラウドの提供形態を指します。ネットワークの構成方法を表す言葉ではありません。

VPC内で仮想マシンを動かしていても、その土台となる物理サーバーをほかの利用者と共有している場合があります。「プライベート」という名称だけで、物理機器の専有や運用主体が決まるわけではありません。AWSはVPCを、パブリッククラウド基盤内に構築できるプライベートなクラウド環境と説明しています。社内で検討する際は、ネットワークを分離したいのか、基盤全体を単一の組織で利用したいのかを切り分ける必要があります。

プライベートクラウドとパブリッククラウド・オンプレミスとの違い

「プライベート」と「パブリック」は、クラウドの提供範囲による区分です。一方、「オンプレミス」は、設備の設置場所や運用形態を表します。つまり、この3つは同じ基準で分けられた選択肢ではありません。それぞれの違いを詳しく見ていきましょう。

パブリッククラウドとの違い（単一組織専用か一般提供か）

両者の違いは、提供先が単一の組織に限られるか、一般の利用者に開かれているかという点です。パブリッククラウドは、利用規約に同意して登録すれば、原則として誰でも利用できます。基盤の維持管理は事業者が担い、可用性やサービス品質などは、サービスレベルアグリーメント（SLA、品質水準に関する取り決め）に定められます。利用者がデータセンターや物理サーバーを購入・所有し、維持する必要はありません。

たとえば、ファイル共有システムをパブリッククラウド上で動かす場合、一般には同じ物理基盤をほかの企業も利用します。一方、プライベートクラウドの提供範囲は、単一の組織に限られます。物理サーバーを専有しているかどうかだけでは、両者を区別できません。提供範囲がどこまで開かれているかで判断します。

オンプレミスとの違い（デプロイメントモデルと設置形態）

オンプレミスは設備の設置場所や運用形態を表す言葉であり、プライベートクラウドの対義語ではありません。自社の拠点やマシンルームに機器を設置して運用する形を、オンプレミスと呼びます。NISTの定義では、プライベートクラウドはオンプレミスにもオフプレミスにも構築できます。そのため、自社設備上にプライベートクラウドを構築することも可能です。

ただし、サーバーを仮想化して仮想マシンを数台稼働させるだけでは、プライベートクラウドとはいえません。Red Hatの解説では、仮想化によって物理機器のリソースを共有プールにまとめ、管理ソフトウェアによって使用状況などを一元管理するとされています。さらに、手作業を自動化し、利用者が必要なリソースを自ら用意できる仕組みを加えることで、プライベートクラウドが構成されます。設備の設置場所と、クラウドとしての機能を備えているかどうかは、分けて考える必要があります。

従来型オンプレミス・プライベートクラウド・パブリッククラウドの比較

3者は区分の基準が異なるため、単純には比較できません。違いを整理するには、提供範囲、設置場所と所有、クラウドとしての性質、拡張性、運用責任に分けて捉える必要があります。

比較項目	従来型オンプレミス（非クラウド）	プライベートクラウド	パブリッククラウド
利用対象・提供範囲	原則として自組織内	単一組織専用	一般の利用者・複数組織に提供
設置場所・所有	原則として自社拠点・自社所有	オンプレミス／オフプレミス、所有・管理主体は複数形態	プロバイダー拠点・プロバイダー管理
クラウド特性	必ずしも備えない	オンデマンド提供・リソースプール等を備える	オンデマンド提供・リソースプール等を備える
拡張性	機器調達・構築が必要	設計・契約・保有容量に依存	一般に迅速に増減しやすい
運用責任	主に自社	自社・第三者・共同など構成による	基盤は事業者、利用者との責任分界あり

従来型オンプレミスとプライベートクラウドの違いは、クラウドとしての性質を備えているかどうかです。一方、プライベートクラウドとパブリッククラウドは、提供範囲によって区別されます。

プライベートクラウドの主な構築・運用形態

プライベートクラウドは、設備をどこに置き、誰が基盤を管理するかによって、大きくオンプレミス型とホスティング／マネージド型に分けられます。分類の呼び方や提供の中身は事業者ごとに異なるため、名称だけで内容を判断せず、個別の条件を確かめてください。

ホスティング／マネージド型プライベートクラウドの特徴

ホスティング／マネージド型は、第三者のデータセンターなどに単一組織専用のクラウド環境を設置する形です。基盤の所有や管理は、事業者に委ねる、事業者と利用企業で分担する場合があります。

利用企業は機器を購入したり、自社だけで環境を構築したりする必要がありません。そのため、オンプレミス型よりも短期間で導入しやすいですし、月額料金で利用できるサービスもあります。専用線やVPNで接続できるほか、サービスによっては個別のカスタマイズにも対応しています。Red Hatは、第三者ベンダーが導入・構成・管理を担うこの形態を、人員やITスキルが不足している企業に適した提供方法と位置づけています。

接続方法には、クライアントVPNや拠点間VPN、専用線・閉域網による専用接続などがあります。サーバーの監視や障害対応、セキュリティアップデートの代行を組み合わせたサービスも一般的です。

なお、パブリッククラウド上に構築されることは必須条件ではありません。導入期間や費用、カスタマイズの範囲はサービスごとに異なるため、見積もりの段階で確認しましょう。

オンプレミス型プライベートクラウドの特徴

オンプレミス型は、自社の拠点や自社で管理する設備に、プライベートクラウド基盤を構築する形です。企業が自らハードウェアを調達し、環境を設計・構築します。サーバーのスペックやストレージ容量、ネットワーク帯域などのリソース構成から、冗長化や大規模災害への備えまで、自社の要件に合わせて設計できる点が特徴です。外部から切り離したネットワークで運用し、独自のセキュリティポリシーを反映することもできます。

一方、導入や運用の負担は大きくなります。サーバーやネットワーク機器、ストレージの調達・設置には、1カ月から数カ月かかる場合があります。さらに、設計・構築・テストの期間も必要です。稼働後も、ハードウェアの故障を含む障害への対応や、脆弱性対策のためのアップデートを自社で行います。このように自社で担う範囲が広いため、設備投資と専門人材の確保が必要です。

プライベートクラウドを導入する4つのメリット

プライベートクラウドは、単一の組織が専用で利用する環境であり、自社の要件に合わせて設計・管理できるため、主に4つの利点があります。ここでは、セキュリティとコンプライアンス、性能、ネットワーク、運用ポリシーの順に解説します。ただし、得られるメリットの程度は、構成や運用形態によって異なります。

セキュリティ・コンプライアンス要件に合わせやすい

アクセス制御やネットワーク、データの配置先を自社のポリシーに沿って設計できるため、規制やコンプライアンスへの対応手段としてプライベートクラウドを選択できます。

セキュリティポリシーやコンプライアンス要件などにより、パブリッククラウドへ移行できない企業もあります。Red Hatは、その例として、医療・金融業界に適用される規制や予算上の制約などを挙げています。また、アクセスを制限できるプライベートクラウドは、パブリッククラウドよりも高いセキュリティ水準を実現できると説明しています。AWSも、機密性の高いデータを扱うためにプライベートクラウドを必要とする組織があると指摘しています。

たとえば、データを特定の区画に限定する、社外からの通信経路を制限する、監査ログの保存期間を自社基準に合わせるといった設計が可能です。

ただし、プライベートクラウドであれば安全とは限りません。物理インフラのセキュリティを自社と事業者のどちらが担うかは、構成によって異なります。一方、データの保護やアクセス管理などは、利用者側が責任を負います。セキュリティとコンプライアンスの要件を満たすには、適切な設計と継続的な運用が必要です。

性能要件を設計・管理しやすい

単一の組織向けにリソースの容量や配分を設計できるため、重要な業務システムの性能を自社の要件に合わせて管理できます。

Red Hatは、プライベートクラウドには未使用のリソースを抑えやすいという利点があると説明しています。リソースが物理的な設置場所に縛られないため、構成や再構成の自動化も可能です。さらに、利用状況に応じた効率的なリソース配分や、インフラ全体の可視化にもつながります。

たとえば、月末に負荷が集中する会計システムには多めのリソースを割り当て、開発環境への配分は抑えるといった調整ができます。

ただし、物理リソースを専有できるか、ほかの利用者の影響を受けないかは、サービスの構成によって異なります。契約前に、専有できる範囲を確認しましょう。

ネットワーク構成を要件に合わせやすい

ネットワークの分離やVPN・専用線の利用、インターネットに公開しない構成などを、自社の要件に沿って設計できます。

社内ネットワークとの接続方法も選択できます。専用線や閉域網は、安定した通信品質を確保しやすく、インターネットを介さずに接続できる点が特徴です。一方、拠点間VPNを利用すれば、専用線よりも費用を抑えて拠点のサーバーやPCと接続できます。

たとえば、外部公開が不要な基幹システムをインターネットから切り離し、拠点からの接続を閉域網経由に限定する構成が可能です。

ただし、閉域構成に対応できるか、どこまで閉域化できるかは、サービスや構成によって異なります。閉域網の利用はプライベートクラウドの必須要件ではないため、必要な場合は事業者へ明確に伝えましょう。

運用ポリシーを要件に合わせやすい

オンプレミス型を自社で運用する場合、システムの変更や更新、メンテナンスの方針を自社の都合に合わせやすくなります。

基盤を自社で保有・管理していれば、機器を更新する時期や計画停止の日程を、業務カレンダーに沿って設定できます。システム要件に応じた構成や運用方法も、自社内で決定できます。

たとえば、繁忙期を避けて保守作業を実施したり、検証が終わるまで更新を保留したりすることが可能です。

一方、ホスティング／マネージド型では、変更できる範囲が事業者との責任分界や契約条件によって決まります。事業者に基盤の保守やアップグレードを任せれば、利用企業の負担は減りますが、自社で判断できる範囲は狭まります。運用負担の軽減と自社の裁量のどちらを重視するか、社内の運用体制を踏まえて判断しましょう。

プライベートクラウドのデメリット・注意点

プライベートクラウドを検討する際は、費用、拡張性、専門知識の3点に注意が必要です。ただし、それぞれの負担の大きさは、構築・運用形態によって異なります。

導入・運用費用が大きくなりやすい

専用環境の構築・維持が必要なため、パブリッククラウドよりも費用が大きくなる場合があります。

導入時には、ハードウェアやソフトウェアライセンスなどの費用がかかります。稼働後も、機器の保守やセキュリティ対策、アップグレード、電力、冷却などの費用が発生します。システムの更新や障害対応を担うIT人材も必要です。また、性能向上や老朽化への対応に伴い、機器の更新費用が生じることもあります。

オンプレミス型では、データセンターやマシンルームなど、設置場所の維持費も必要です。

ただし、初期費用や月額費用、従量課金の有無は、構築形態や事業者によって異なります。ホスティング型の多くは月額制で提供されるため、初期の機器調達費や設計・構築費を抑えられる場合があります。このように、構築形態によって費用の内訳は変わります。

拡張性・スケーラビリティに制約が生じる場合がある

自社保有の設備や専用の容量を使う構成では、大規模なパブリッククラウドほど迅速にリソースを増強できません。

リソースを増やすには、機器の調達や設置、設計、構築、テストが必要です。調達から設置までに1カ月から数カ月かかる場合もあります。そのため、需要に応じてリソースを自動的に増減できるパブリッククラウドと比べると、急激な需要の変化に対応しにくくなります。

たとえば、新規サービスの利用者が想定より早く増えた場合、パブリッククラウドなら短時間でリソースを追加できます。一方、自社保有の設備では、機器の調達が完了するまで増強できない可能性があります。

ホスティング型の拡張性は、事業者の提供方式によって異なります。サーバーやストレージの容量を後から追加できるサービスもあるため、追加方法と所要時間を事前に確認しましょう。

自社運用では専門知識・運用体制が必要

自社で構築・運用する場合は、クラウド管理基盤や仮想化、ネットワーク、セキュリティに関する知識と、それを支える体制が欠かせません。

プライベートクラウドの構築では、仮想化ソフトウェア、一元管理のためのソフトウェア、作業を自動化する仕組みなどを組み合わせます。AWSは、導入が複雑で時間を要するうえ、インフラと人材への多額の先行投資が必要になると説明しています。また、コーディングやエンジニアリングに関する高度な専門知識を持つ人材も必要です。

稼働後も、障害対応や脆弱性対策のためのアップデートが継続的に発生します。システムの重要度によっては、夜間や休日にも対応できる体制が求められます。

マネージドサービスを利用すれば、監視や障害対応、セキュリティアップデートなどの一部を事業者に委託できます。社内の人員とスキルを踏まえ、自社で担う範囲を決めましょう。

プライベートクラウドと組み合わせられる関連サービス

プライベートクラウドと、パブリッククラウドの機能や運用基盤をオンプレミス・エッジへ拡張するサービスは、同じものではありません。後者は、ハイブリッドクラウドや分散クラウドを実現するための選択肢です。ここでは、代表的な3つのサービスの位置づけを解説します。

AWS Outposts（ハイブリッドクラウド向けサービス）

AWS Outpostsは、AWSのインフラストラクチャやサービス、API、ツールを顧客の拠点へ拡張するフルマネージドサービスです。

顧客の拠点に設置されたコンピューティングとストレージについては、AWSリージョンの一部としてAWSが運用・監視・管理します。利用企業はAWSリージョンと同じAPIを使い、オンプレミス環境でアプリケーションを構築・実行できます。拠点内のリソースで処理するため、低遅延やローカルでのデータ処理が必要なシステムにも対応可能です。

提供形態には、42Uラック型の「AWS Outpostsラック」と、1Uまたは2Uの「AWS Outpostsサーバー」があります。ラックはAWSが設置し、利用企業の電源とネットワークに接続します。主な用途は、規制や契約、情報セキュリティ上の理由からデータを特定の国・地域に保持する必要があるケースへの対応です。また、低遅延が求められる既存システムを段階的に移行する用途にも適しています。

つまり、Outpostsは一般的なプライベートクラウドではありません。AWSのパブリッククラウド環境を自社拠点まで拡張する、ハイブリッドクラウド向けのサービスです。

Azure Local（旧Azure Stack HCI）などの分散インフラ

Azure Localは、利用企業が保有する環境にAzureの機能を拡張する、Microsoftの分散インフラストラクチャ製品です。Azure Stack HCIはAzure Localに統合され、その機能が引き続き提供されています。

OEMパートナーが検証したベアメタルハードウェア上で動くフルスタックのインフラストラクチャソフトウェアとして提供され、Azure Arcを統合コントロールプレーンとして使うことで、コンテナーや仮想マシン、一部のAzureサービスを分散した場所で実行できます。監視、更新、セキュリティ保護はAzureポータルから行えます。

ハードウェアは利用企業が所有し、運用管理も担います。ソフトウェアの更新が公開されるとAzureポータルに通知され、利用企業が適用を開始する仕組みです。運用の一部または全部を、ソリューションベンダーへ委託することもできます。

Azure Localもプライベートクラウドそのものではなく、ハイブリッドクラウドや分散インフラを構成する選択肢の一つです。

国内事業者のホスティング／マネージドプライベートクラウド

国内事業者がデータセンターで提供するプライベートクラウドを選ぶ際は、データの所在地や設備の専有範囲、運用責任、ネットワーク、契約条件を確認する必要があります。

データが国内に保存されるだけで、データ主権やコンプライアンスの要件を満たせるとは限りません。日本オラクルの資料では、クラウドにおける主権を3つに分けています。データレジデンシーは、データが指定した地域に保存されるかという観点です。データ主権は、データが保存・処理される国の法規制が適用され、データへのアクセスを顧客が管理できるかを指します。運用上の主権は、クラウドを誰が運用するかという点です。

データの保存場所が国内でも、運用主体や顧客が管理できる範囲はサービスによって異なります。ハードウェアやクラウド管理基盤、OS、仮想マシンを誰が管理するのかという責任分界も、契約書や提案書で確認が必要です。

サービス名や「国内設置」という表示だけで判断せず、自社の要件と一つずつ照合しながら選定しましょう。

プライベートクラウドの選び方と費用の考え方

自社に合うプライベートクラウドを選ぶには、比較軸をあらかじめ決め、構築・運用費用の内訳を確認する必要があります。

選定時に確認すべき比較軸

主な比較軸は、設置場所とデータ所在地、所有・運用責任、拡張性、サポート範囲、セキュリティ・ネットワークです。

比較軸	確認ポイント
設置場所・データ所在地	オンプレミス／事業者データセンターの別、データ保管場所・適用法令の要件
所有・運用責任	ハードウェア、クラウド管理基盤、OS・VMなどを誰が管理するか
拡張性・容量設計	リソース追加の方法・所要時間、上限、将来の増強方法
サポート・SLA	監視、障害対応、更新、運用代行の範囲と責任分界
セキュリティ・ネットワーク	アクセス制御、VPN・専用線、閉域構成、ログ・監査要件への対応

比較条件は、サービスの仕様ではなく、自社の要件を基準に設定します。特定のハイパーバイザーや契約年数を一律の必須条件にすると、選択肢を不必要に狭める可能性があります。まずは軸ごとに要件を明確にし、各サービスの対応状況を並べて比較しましょう。

構築・運用費用を左右する主な項目

費用を構成する項目は、プライベートクラウドの形態によって異なります。

オンプレミス型では、ハードウェアの調達費やソフトウェアのライセンス費、設計・構築費、保守・運用費が主な項目です。データセンターやマシンルームの利用・維持費に加え、電力、冷却、物理セキュリティの費用も継続して発生します。

一方、ホスティング／マネージド型では、初期設定費や月額利用料、追加リソースの利用料が中心です。さらに、専用線やVPNなどのネットワーク費用、監視や障害対応などの運用支援費が加わります。

同じ規模の環境でも、運用を委託する範囲や閉域接続の有無によって総額は変わります。一律の相場で判断せず、要件を固めたうえで複数の事業者から見積もりを取り、費用の内訳や条件まで比較しましょう。

KAGOYAのプライベートクラウド活用事例

KAGOYAのプライベートクラウド関連サービスを採用した2社について、導入前の課題、選んだ構成、導入後の効果を紹介します。

業務システム基盤への活用事例

株式会社シジャム・ビーティービーは、業務システムとサービスの基盤として、KAGOYAの3Tier仮想化環境を導入しました。同社は、RPAツールの販売・導入支援・保守と、BPO（ビジネス・プロセス・アウトソーシング）サービスを主な事業としています。

導入前の課題は、既存基盤の安定性でした。利用していたパブリッククラウドでシステムが停止し、データベースを復旧したものの、同様の事象が3回ほど続いたといいます。メモリーの追加にも失敗したため、同社は別の基盤を検討しました。ほかの利用者の影響を避けるため、移行先には物理的に分離された専有環境を求めていました。

KAGOYAが提案したのは、ベアメタルサーバー（物理サーバー）上に同社専用の仮想環境を構築するパッケージプランです。仮想基盤の導入と初期構築が済んだ状態で提供され、VPNの構築や初期設定のサポートも受けられます。構成には仮想化ソフトウェアのVMware、サーバー、ファイアウォール、バックアップが含まれています。FortiGateによってVPNを設定しやすい点も評価されました。

採用の決め手は、既存サービスで実感していた使いやすさとサポートへの安心感、導入負担と費用を抑えられるパッケージ構成、VPNを含む初期構築を任せられることの3点です。同社は品質・費用・納期に満足しており、短期間で利用を開始できる点を高く評価いただきました。

VMware移行による安定運用の実現事例

株式会社エコー・システムは、自社パッケージサービスの基盤をクラウド化した後、冗長構成へ移行して安定性を高めました。同社は、業界特化型のクラウドサービスや自社パッケージを開発・提供しています。

導入のきっかけは、昼食の注文管理をIT化したいという顧客からの相談でした。数千人規模での利用も想定される「お弁当EDIシステム」を開発するにあたり、安定稼働を支えるインフラが必要になりました。

共有型の仮想環境には性能面の懸念があったため、物理サーバーを専有できるKAGOYAのベアメタルサーバーを採用しました。その後、冗長性を高めるため、「プライベートクラウドパッケージ HA」へ移行しています。このサービスは、vSphereによる仮想環境が構築された状態で提供されるため、初期設定の負担を抑えられます。ホストサーバーに障害が発生した場合は、仮想サーバーが別のホストで自動的に再起動し、停止時間を短縮します。

同社は、構成の自由度やサポートの速さを評価しています。リモートKVM（遠隔から物理サーバーを操作する仕組み）の提供や作業依頼への対応が速く、営業担当者と技術担当者へ細かな点まで相談できたため、トラブルなく短期間でクラウド化できたと評価いただきました。

まとめ

プライベートクラウドは、単一の組織が専用で利用するクラウド環境です。設備の設置場所や所有・管理の主体は一つではなく、オンプレミスに構築する形も、事業者のデータセンターを利用する形もあります。物理サーバーの専有だけで決まる区分ではありません。パブリッククラウドとは提供範囲が、従来型オンプレミスとはクラウドとしての性質を備えているかどうかが異なります。

選定時には、セキュリティ・コンプライアンス、費用、社内の運用体制、データの所在地に関する要件を明確にします。そのうえで、専有範囲や責任分界、拡張方法、サポート範囲を比較し、構築・運用形態と事業者を絞り込みましょう。

KAGOYAでは、専有ハードウェア上に仮想環境を構築した「プライベートクラウド Suite」を提供しています。自社に適した構成や費用を確認したい方は、資料をご覧のうえ、お気軽にご相談ください。