オンプレミスとクラウドの使い分け：企業インフラで「戻す」判断はいつ正しいのか

オンプレミス（オンプレ）とは、サーバー・ストレージ・ネットワーク機器を自社の施設または契約したデータセンターのラックに置き、自社で所有・運用する形態です。クラウドは事業者が所有する設備を従量課金で借りる形態で、IaaS（仮想マシンやストレージ）、PaaS（マネージドDBや実行環境）、SaaS（アプリケーション）に分かれます。クラウドから「戻す」判断が正しいのは、負荷が平坦で予測でき、データ量が大きく、運用できる人が社内にいる、という3条件がそろったワークロードに限られ、それ以外の回帰は5年分の費用表の見誤りであることがほとんどです。

オンプレミスとクラウドの定義：責任範囲で整理する

「どこにあるか」より「どこまで自社が面倒を見るか」で分けると判断がぶれません。オンプレでは建物と電源からアプリまで全部が自社の責任で、コロケーション（データセンターのラック貸し）に置いても建物と電源が事業者に移るだけです。クラウドは責任共有モデルで、IaaSではOSより上、PaaSではアプリとデータ、SaaSでは設定とデータだけが自社に残ります。残った責任の中で最も事故が多いのは、どの形態でも「権限設定」と「公開範囲の設定」です。

比較軸：費用・拡張性・運用負荷・セキュリティ・法規制

費用比較で必ず崩れるのは、オンプレ側で人件費と予備機を、クラウド側でegressとログ保管を、それぞれ数えない見積もりです。オンプレのTCOには、機器本体、保守契約、電力（機器の消費電力に空調分を上乗せ）、ラックや回線、監視やバックアップのソフト、運用担当者の工数、5年後の更新費用を入れます。クラウドのTCOには、コンピュート、ストレージ、データ転送出、バックアップとログの保管、サポートプラン、そして基盤を見張る担当者の工数を入れます。両方に人件費が入って初めて、同じ土俵の表になります。

クラウドから戻すときのデータ転送出（egress）料金は、回帰そのものの費用です。数十TBを移す見積もりを取らずに機材を先に買うと、二重払いの期間が伸びます。執筆時点では主要事業者が解約に伴う持ち出しの転送料金を条件付きで免除する制度を設けているので、適用条件と申請手順を移行計画に組み込んでください。

クラウド回帰（リパトリエーション）が起きる背景

クラウドの価格体系は「変動する負荷を、使った分だけ払う」ことに最適化されています。24時間365日、CPU使用率60%で5年間動き続ける基幹DBは、この価格体系の恩恵をほぼ受けず、弾力性に対する割増を払い続けます。リザーブドインスタンスやSavings Plans（AWS）、Reserved VM Instances（Azure）、確約利用割引（Google Cloud）で差は縮まりますが、1〜3年の前払い契約をする時点で「負荷が平坦だと分かっている」ことを認めているわけで、それならオンプレとの比較に乗せるのが筋です。

2つ目はデータの重力です。数百TBの動画・CADデータ・ログを置き、それを頻繁に社外へ取り出す用途では、ストレージ料金よりデータ転送出の料金が効きます。3つ目はGPUで、推論を常時回す用途では自社GPUサーバーの方が安くなる一方、学習のように数週間だけ大量に使う用途はクラウドが向きます。4つ目は規制で、データの所在や事業者の認証を求める業界では、国内リージョンかオンプレに限定されます。

海外では、自社ブログでクラウドからの撤退と削減額を公開している企業もあり、それが「回帰」の議論を広げました。同じ時期に、仮想化基盤のライセンス体系の変更を機にオンプレからクラウドへ、あるいはProxmoxのような別の基盤へ移る企業も増えています。つまり回帰は流行ではなく、ワークロードごとの再計算の結果で、会社単位で「全部戻す」「全部クラウド」と決める話ではありません。

判断フレームワーク：ワークロード特性で決める

「戻す」候補が挙がったら、次の6点に答えられるかで判断します。答えられない項目が1つでもあれば、戻す前にその答えを作るのが先です。

1. 5年TCOを両側で、人件費・予備機・egress・更新費用込みで出したか。
2. 深夜3時にディスクが壊れたとき、誰が交換するか（保守契約の駆けつけ時間を含めて）。
3. クラウド側の契約（リザーブド、年間契約）の残期間と、戻すためのデータ転送出の費用を見積もったか。
4. 仮想化・ストレージ・ネットワーク・バックアップを設計できる人が社内に2人以上いるか（1人は属人化）。
5. DR（災害復旧）をどこで、どの復旧時間目標で組むか決めたか。
6. 5年後の更新時に、また同じ判断ができる体制が残っているか。

「クラウドの請求書が高いから戻す」は、多くの場合タグ付けと未使用リソースの整理で解決する問題です。後述のFinOpsの可視化を先に3か月回し、それでも平坦な負荷に対して割高だと確認できてから、回帰の見積もりに進んでください。

ハイブリッド構成の例

ハイブリッドで最初に組む価値があるのは、ID連携とバックアップの2つです。ID連携は退職者処理とMFAを1か所に集め、バックアップはオンプレの最大の弱点である「同じ建物に全部ある」状態を安く解消します。Proxmoxを基盤にした3-2-1の具体的な組み方はProxmox Backup Serverで3-2-1ルールを実現するで、クラウド側をコードで管理する入り口はTerraformで始めるIaCで扱っています。ハイブリッドの落とし穴は、両側をつなぐ回線とID基盤が単一障害点になることで、専用線やVPNの冗長化と、IdP停止時の緊急アクセス手段を先に決めておきます。

FinOpsの基本：可視化・最適化・ガバナンス

FinOpsは、クラウド費用を財務・技術・事業部が共同で管理する運用の枠組みで、FinOps Foundationは Inform（可視化）→ Optimize（最適化）→ Operate（運用・ガバナンス）の3段階を繰り返すと整理しています。順番が重要で、可視化を飛ばして最適化に入ると、削っていい資源と削ってはいけない資源の区別がつきません。

同じ規律はオンプレにも必要です。オンプレの「買ってしまえば無料」という感覚は、電力・保守・更新費用を誰も数えていないだけで、稼働率10%のサーバーが5年間電気を食う構図はクラウドの放置インスタンスと同じです。ラックの消費電力と各サーバーの使用率を毎月記録するだけで、次の更新時に台数を半分にできることは珍しくありません。全社のITコスト構造の見直し方はITコスト削減の進め方に、事業者への依存の扱いはベンダーロックインとの付き合い方にまとめています。

よくある質問

オンプレとクラウドはどちらが安い？

ワークロードによります。負荷が平坦で5年以上動くものは、人件費まで含めてもオンプレか長期割引付きクラウドが安くなりやすく、負荷が変動するものや短期のものはクラウドが安くなります。比較は必ず5年TCOで、オンプレ側に人件費・保守・電力・更新費用、クラウド側にegress・ログ保管・運用工数を入れて行います。

クラウドに向かないシステムは？

回線が切れても止められない現場系（工場の制御、店舗のPOS、監視カメラ）、データの所在が規制や契約で縛られるもの、大容量データを頻繁に社外へ出すもの、そして負荷が完全に平坦な基幹DBです。逆に、メール・ID・コラボレーションのような共通機能は自社で持つ理由がなく、SaaSに寄せます。

ハイブリッドの注意点は？

両側をつなぐ回線とID基盤が単一障害点になることです。VPNや専用線を冗長化し、IdPが止まったときの緊急アクセス用アカウントを用意し、どのデータがどちらにあるかの台帳を持ちます。運用チームも二重になりがちなので、監視とバックアップは両側を1つの画面で見られる形にします。

まとめ

オンプレかクラウドかは会社の方針ではなく、ワークロードごとの再計算で決めます。負荷が平坦・データが重い・現場依存・規制ありのものはオンプレ側に寄せ、変動する・短期・共通機能はクラウドとSaaSに寄せる。「戻す」判断は、FinOpsの可視化を3か月回し、人件費と更新費用込みの5年TCOで割高だと確認でき、深夜の故障対応を誰がやるか答えられたときだけ正しい判断になります。その前に組むべきは、ID連携とオフサイトバックアップという、どちらの置き場所でも必要になるハイブリッドの土台です。

次に読む

• ITコスト削減の進め方：SaaS・クラウド・保守費を見直す手順
• ベンダーロックインとの付き合い方：回避すべきケースと許容すべきケース
• Proxmoxのバックアップ戦略：Proxmox Backup Serverで3-2-1ルールを実現する