>
>
公開日
最終更新日
「オンプレミスとは何か」「クラウドへ移行すべきか」「生成AIを社内データで安全に使う場合、モデルをどこで動かし、データをどこに置くべきか」は、システム更改を担う情報システム部門にとって切り離せない論点です。結論から言うと、オンプレミスとクラウドは優劣で決めるものではなく、データの機密性、処理負荷の変動、復旧目標、運用体制、3〜5年の総保有コストで配置を決めます。
総務省の令和7年版情報通信白書は、2024年にクラウドサービスを利用した企業の割合を80.6%と示しています。一方で、クラウド利用が定着した現在は、VMwareのライセンス体系変更、データ転送費、為替影響、生成AIにおけるデータ主権を背景に、すべてをクラウドへ移すのではなく、オンプレミス・プライベート環境・パブリッククラウドを組み合わせる設計が増えています。
本記事では、オンプレの意味から責任共有モデル、ハイブリッド運用、クローズドAI、リフト＆シフトで起きやすいコスト増までを実務の判断順に整理します。
オンプレミスとは
オンプレミスとは、利用組織が統制する専用のIT基盤にサーバー、ストレージ、ネットワーク機器を配置して利用する形態です。
本記事のポイント
オンプレミスは、自社ビルだけでなく、外部データセンターの専用ラックや運用委託を含む専用環境です。
クラウドが必ず安く、オンプレミスが必ず安全という考え方は正しくありません。
負荷が安定する基幹処理や大量データ処理はオンプレミスを比較対象に残します。
変動負荷、短期検証、グローバル展開はクラウドを優先し、両方の条件がある業務はハイブリッド構成に分けます。
オンプレミスは英語の「on premises」に由来し、「構内・敷地内にある」という意味を持ちます。日本では「オンプレ」「自社運用」と呼ばれることがありますが、担当者が機器をすべて自分で保守することだけを意味しません。自社が所有するサーバーをコロケーション事業者のデータセンターへ設置する場合、または監視・障害一次対応を外部事業者に委託する場合も、利用組織が専用設備の構成・データ・運用方針を統制していればオンプレミスとして扱います。
オンプレミスで重要なのは、設備の所有者だけではありません。「どこに機器があるか」「誰が物理・論理アクセスを管理するか」「障害時に誰が復旧責任を負うか」「データをどこへ複製するか」を分けて決める必要があります。たとえば、自社所有のサーバーを外部データセンターに置き、24時間監視だけを委託する構成では、ハードウェア更改とデータ保護の最終責任は利用組織に残ります。
オンプレとクラウドの用語整理
クラウドは、ネットワーク経由でコンピューティング資源をサービスとして利用する形態です。仮想サーバーやストレージを利用するIaaS、アプリケーション開発・実行環境を利用するPaaS、完成済みの業務ソフトウェアを利用するSaaSに分けられます。
なお、オンプレミスとクラウドは完全な対義語ではありません。自社データセンターに仮想化基盤を構築してセルフサービス型で提供すれば、オンプレミス型のプライベートクラウドになります。反対に、クラウド事業者の専用ホストや専有テナントを利用する場合は、クラウドサービスでありながら他社との物理共有を避けられる場合があります。用語だけで結論を出さず、データ、処理、責任分界、契約条件を確認して構成を選びます。
オンプレミスが使われる業務領域
オンプレミスは、工場設備と連携する制御システム、低遅延が必要な映像解析、既存の専用ソフトウェアに依存する基幹業務、社内ネットワークで完結させたいファイル共有、機密文書を参照する生成AI推論基盤などで候補になります。特に毎日大量のデータを処理し、利用量がほぼ一定のシステムは、クラウドの従量課金とデータ転送費を含めて比較すると、専用環境が合理的になる場合があります。
ただし、オンプレミスは設備を保有するだけで安全性や低コストが実現するわけではありません。資産台帳、保守期限、脆弱性情報、特権ID、バックアップ、復旧訓練を継続できない場合は、物理設備を持つこと自体がリスクになります。
オンプレミスとクラウドの違い一覧
オンプレミスとクラウドの違いは、設備の置き場所ではなく、費用の発生時期、運用責任、拡張速度、データの流れで比較します。
比較項目 | オンプレミス | パブリッククラウド |
|---|---|---|
設備の配置 | 自社施設または専用データセンターのラックに機器を置きます。 | クラウド事業者のデータセンター上のサービスを利用します。 |
費用構造 | サーバー、ネットワーク、設置工事などの初期投資が先行します。 | 利用量に応じた月額・従量課金が中心で、初期投資を抑えやすいです。 |
調達速度 | 稟議、見積もり、発注、納品、構築が必要で、数週間〜数か月を要します。 | 契約と設定後、数分〜数日でリソースを利用開始できます。 |
拡張性 | 増設には機器選定、予算、調達、設置が必要です。 | 需要に応じて増減しやすく、一時的な負荷増に対応しやすいです。 |
性能・通信 | 構内で処理が完結すれば低遅延で、通信量を予測しやすいです。 | リージョン、回線、データ転送量、接続先サービスが性能と費用に影響します。 |
セキュリティ責任 | 物理対策、OS、ミドルウェア、監視、ID管理まで利用組織の責任範囲が広いです。 | 基盤保護は事業者、設定・ID・アプリケーション・データ保護は利用組織が担います。 |
データ所在地 | 設置場所と物理アクセス対象を把握しやすいです。 | 利用リージョン、バックアップ先、サポート時のアクセス条件を契約・設定で確認します。 |
障害対策 | 冗長化、予備機、保守契約、DRサイトを自ら設計します。 | 可用性ゾーンや複数リージョンを利用できますが、アプリケーションの冗長設計は必要です。 |
費用管理 | 減価償却、保守、電力、空調、人件費、更新費を含めて管理します。 | 利用料、ストレージ、転送、サポート、移行費、為替影響を含めて管理します。 |
責任共有モデルの違い
クラウドでは、クラウド事業者が設備を管理するため、利用企業のセキュリティ運用が不要になるわけではありません。AWSは責任共有モデルで、AWSがクラウド基盤の保護を担い、利用者がクラウド内のOS設定、ネットワーク設定、アクセス権、アプリケーション、保存データを保護すると説明しています。
オンプレミスでは、サーバールームやデータセンターの物理対策からOSパッチまで責任範囲が広がります。クラウドでは物理層の負担を減らせますが、公開設定、認証情報、暗号鍵、バックアップ設計の不備は利用企業側の事故になります。クラウド移行後も、資産管理と権限管理を止めない運用が必要です。
費用比較の考え方
月額料金とサーバー購入額だけを比べると、オンプレミスとクラウドの比較は誤ります。オンプレミスは、機器購入費、設置費、保守費、電力・空調費、ソフトウェアライセンス、運用人件費、更新時の撤去・移行費を含めます。クラウドは、コンピュート、ストレージ、バックアップ、監視、データ転送、サポート、ネットワーク回線、移行・改修費を含めます。
たとえばクラウド利用料が月額80万円の場合、利用料だけで5年間に4,800万円かかります。ここに移行作業、データ転送、サポート、監視サービス、為替変動の影響が加わります。一方、オンプレミスでは初年度に支出が集中しますが、負荷が安定している業務では5年間の支出を予測しやすくなります。この試算例はどちらが安いかを決める数字ではなく、稟議で比較すべき費目を可視化するための基準です。
一般的なサーバー価格の目安として、Spice Factoryは標準的なサーバー代を50万〜300万円程度、高性能サーバーでは500万円以上、構成によっては1,000万円以上と紹介しています。これは個別見積もりではなく参考値ですが、GPU、冗長電源、ストレージ、ネットワーク、保守を加えると初期費用が大きく変動することを示しています。
▲ オンプレミスとパブリッククラウドの主要項目における対比
オンプレミス回帰とハイブリッド運用の背景
現在のインフラ選定では、クラウド全面移行ではなく、データと処理特性に合わせて配置するハイブリッド運用が現実的な選択肢です。
クラウド利用の定着と再配置
総務省の令和7年版情報通信白書は、2024年に企業の80.6%がクラウドサービスを利用していると公表しています。クラウドはすでに例外的な技術ではなく、業務システムの標準的な選択肢です。だからこそ現在は、「クラウドを使うか」ではなく、「何をクラウドに置き、何を専用環境に残すか」が論点になっています。
JEITAの「ITユーザートレンド調査（2023）」では、担当ITシステムの運用形態として「プライベートクラウドのみ」が37%、「パブリッククラウドとオンプレミス」が22%、「オンプレミスのみ」が18%でした。この調査は2023年時点の結果ですが、単一の運用形態に統一するより、複数の基盤を組み合わせる企業が多いことを示しています。現在はさらに状況が変化している可能性があるため、次期更改では自社の利用実績と費用実績で再判定します。
同調査では、現在パブリッククラウドを利用していない企業のうち、過去に利用したがオンプレミスまたはプライベートクラウドへ戻した回答が58%でした。また、パブリッククラウドのみを利用している回答者の61%が、次期システムでオンプレミスまたはプライベートクラウド運用を検討中と回答しています。これはクラウドの失敗を意味するものではなく、処理負荷、コスト、規制、既存資産を踏まえて配置を再調整する動きとして捉えるべきです。
VMwareライセンス変更と脱VMware
Broadcomは2023年11月22日にVMwareの買収を完了し、同年12月11日にVMwareの永続ライセンス販売終了とサブスクリプション型への一本化を発表しました。VMwareライセンス変更の概要は、Broadcom 公式の製品ページや各販売代理店の解説ページで確認できます（内容は公開時期により更新されている場合があります）。
この変更では、従来のCPUソケット中心の考え方からCPUコア数を基準とする契約へ移り、製品もVMware Cloud FoundationやVMware vSphere Foundationなどのバンドルを中心に再編されました。既存環境の更新では、仮想マシン数だけでなく、物理CPUのコア数、最低購入単位、必要な管理・自動化機能、保守期限を一覧化します。ライセンス変更の詳細は契約時期・構成規模・購入チャネルによって異なるため、実際の更新費は販売代理店または Broadcom 公式ポータルで個別に見積もりを取得し、その数字を基に判断します。更新見積もりで5年TCOが許容範囲に収まるなら継続利用案を残し、収まらないなら代替仮想化基盤やクラウド移行を同じ条件で試算します。
脱VMwareの候補には、Nutanix AHV、Microsoft Hyper-V、Azure Stack HCI、KVM系基盤、パブリッククラウドのネイティブサービスがあります。ただし、仮想マシンの移行だけでは終わりません。バックアップ、監視、運用自動化、障害対応手順、管理者スキル、ソフトウェアライセンス監査までを移行対象に含めます。ハイパーバイザーの価格だけで比較すると、移行後の運用工数を見落とします。
ハイブリッド運用の役割分担
ハイブリッド運用は、基幹システムを必ずオンプレミスへ置く方式ではありません。業務単位で、安定負荷、機密性、低遅延、外部公開、短期検証、災害対策の要件を分けて配置する考え方です。
業務・処理の特性 | 優先して比較する配置 | 判断理由 |
|---|---|---|
負荷が年間を通じて安定し、大容量データを継続処理する | オンプレミスまたは専用プライベート環境 | リソース利用率と通信量を予測しやすく、長期TCOを算定しやすいためです。 |
アクセス数が急増減する公開Webサービス | パブリッククラウド | 短期間の増減や負荷試験に対応しやすいためです。 |
個人情報・設計情報を含む社内データ検索 | 閉域環境、専用クラウド、オンプレミス | データ経路、ログ、アクセス権を限定しやすいためです。 |
開発・検証・一時的な分析処理 | パブリッククラウド | 調達を待たずに開始し、不要になれば停止できるためです。 |
災害時だけ必要になる待機環境 | クラウドDRまたは複数拠点構成 | 常時フル稼働させない設計が可能なためです。 |
ハイブリッド化では、ID連携、ネットワーク、DNS、監視、ログ保管、バックアップ、データ同期、障害時の切り替え責任者を設計します。復旧手順を年1回以上テストできるなら連携範囲を広げ、テスト担当者を確保できないなら、重要データだけを同期するなど連携範囲を限定します。
生成AIにおけるオンプレミス活用
生成AIを機密データと組み合わせる場合は、モデル性能だけでなく、データがどこを通り、誰がアクセスできるかで実行環境を選びます。
クローズドAIとデータ主権
社内文書検索、設計情報の参照、顧客対応支援、ソースコードレビューに生成AIを使う場合、プロンプト、参照文書、回答ログに機密情報が含まれる可能性があります。外部AIサービスを利用する構成では、入力データの保存期間、モデル学習への利用条件、処理リージョン、委託先、管理者のアクセス範囲を契約・仕様で確認します。
自社ネットワーク内や専用の閉域環境でモデルを動かし、外部ネットワークへの通信を制御する構成は、クローズドAIまたはプライベートLLMと呼ばれます。オンプレミスのGPUサーバー、コロケーション環境、専用クラウドテナントにモデルを置けば、社内データを外部の公開AIサービスへ直接送信する範囲を抑えられます。
ただし、オンプレミスへ置くだけでは生成AIの統制は完了しません。利用者ごとのアクセス権、検索対象文書の権限継承、プロンプトログの保存、回答の監査、モデル更新、脆弱性対応、出力内容のレビューを運用へ組み込みます。人事文書を閲覧できない利用者が、RAGによる回答経由で内容を推測できる構成は避けます。
GPU基盤の調達と性能要件
大規模言語モデルをオンプレミスで動かすには、モデルサイズ、量子化方式、同時利用者数、応答速度、学習か推論かを先に決めます。70Bを超える大規模モデルを量子化なしで運用し、複数ユーザーからの同時アクセスを想定する場合、高VRAM・高スループットのGPUを複数搭載したサーバー構成が必要になるケースが多いため、モデルサイズ・量子化方式・同時利用者数を先に定義してから機材を選定します。INT4やINT8への量子化によってVRAM要件が大幅に下がる場合もあり、要件次第で単体GPUで対応できる構成もあります。
GPUサーバーは本体価格だけでなく、消費電力、冷却能力、ラック搭載重量、電源容量、保守部品、GPUドライバー、CUDAなどのソフトウェア互換性を含めて設計します。社内でGPU障害対応やモデル更新を担えない場合は、ハードウェア保守とAI基盤運用をどこまで委託するかを切り分けます。推論利用が中心で利用者数が限られるなら、小規模モデルや量子化モデルによる検証から始めることで、過大な設備投資を防げます。
国内企業の導入事例
また、株式会社Ippu Senkinは、青和信用組合に対して大規模言語モデル「gpt-oss-120b」に対応したオンプレミス環境の生成AIアシスタントを導入し、約120名の全組合員が利用できる基盤を構築したと公表しています。この事例では、モデル規模だけでなく、組織内の利用対象者を明確にし、閉じた環境で展開している点が特徴です。
オンプレミス生成AIの選定では、モデルを最も大きくすることを目的にしません。参照データの範囲、想定同時利用者数、回答品質、許容応答時間、GPU稼働率、運用担当者を先に定義します。利用者が限定され、社内文書検索が中心なら、モデルサイズより文書分割、検索精度、権限連携、回答根拠の表示を優先します。
オンプレミスのメリットとデメリット
オンプレミスは制御性と予測可能性に強みがありますが、初期投資と継続的な運用責任を引き受ける形態です。
オンプレミスのメリット
第一のメリットは、ハードウェア、ネットワーク、保存方式、監査ログ、バックアップ、認証連携を業務要件に合わせて細かく設計できることです。製造設備との連携、専用プロトコル、古い業務アプリケーション、特殊なストレージ要件がある場合は、クラウドの標準サービスより適合しやすいことがあります。
第二のメリットは、データ所在地と通信経路を把握しやすいことです。専用ラックや自社施設に置く場合、対象機器、物理アクセス、接続回線を明確に管理できます。機密データを社内ネットワークで処理し、外部通信を限定する設計は、データ持ち出し範囲を減らす選択肢になります。
第三のメリットは、大量データ処理における通信量の予測可能性です。動画、センサーデータ、バックアップ、AI学習用データを日常的に扱う場合、社内ネットワーク内で処理を完結させれば、外部へのデータ送信量に連動する費用を抑えやすくなります。処理量が安定している業務では、購入後の設備利用率を高めやすい点も利点です。
オンプレミスのデメリット
最大のデメリットは、初期構築費と調達期間です。サーバー、ストレージ、ネットワーク、ラック、電源、回線、設置工事、保守、ソフトウェアライセンスを準備するため、短期間の検証や急な需要増には対応しにくくなります。予算承認後に機器の納期が延びると、業務開始日も後ろ倒しになります。
ハードウェアの老朽化も避けられません。保守期限切れ、部品供給停止、OSやファームウェアのサポート終了、ラック電源不足、空調能力不足は、通常運用の中では見落とされやすい項目です。更改を障害発生後に始めると、移行テストと復旧対応が同時進行になり、選択肢が狭まります。
また、オンプレミスは無条件に安全ではありません。パッチ未適用、共有管理者ID、バックアップ未検証、ネットワーク機器の設定不備、監視漏れがあれば、物理的に社内にあるシステムでも侵害や停止が発生します。24時間監視を内製できない場合は、監視委託の対象機器、通知条件、一次切り分け、オンサイト保守、復旧目標を契約書と運用手順へ明記します。
オンプレミスが適する条件
次の条件が複数ある業務は、オンプレミスまたは専用プライベート環境を優先して比較します。
CPU、GPU、ストレージの利用率が年間を通じて高く、負荷変動が小さい場合
大量データを毎日処理し、外部への送受信量が大きい場合
工場・店舗・研究設備などと低遅延で連携する必要がある場合
外部ネットワークへの接続を最小化したい機密処理がある場合
機器保守、脆弱性対応、復旧訓練を内製または委託で継続できる場合
反対に、短期間しか使わない検証環境、利用者数が読めない新規サービス、海外拠点へ迅速に展開するシステムは、オンプレミスだけで対応しようとすると余剰設備が発生しやすくなります。
クラウドのメリットとデメリット
クラウドは調達の速さと拡張性に優れますが、利用設計と費用管理が不十分だと、従量課金と運用対象が増えます。
クラウドのメリット
クラウドの強みは、サーバーを購入せずに環境を用意できる点です。開発環境、負荷試験、データ分析基盤、災害復旧環境を短期間で開始でき、不要になれば停止・縮小できます。新規サービスの公開前に一時的にリソースを増やす、月末処理だけ性能を上げるといった運用も可能です。
また、クラウド事業者がデータセンター設備、物理サーバー、基盤ネットワークの保守を担うため、情シスは物理故障対応の一部から解放されます。複数リージョン、可用性ゾーン、マネージドデータベース、監視サービスを組み合わせれば、災害対策や保守自動化の選択肢を増やせます。
総務省が公表した令和7年版情報通信白書で企業のクラウド利用率が80.6%に達した背景には、初期費用削減だけでなく、利用開始の速さ、拡張性、保守・運用の外部化といった価値があります。クラウド導入の目的を「安くすること」だけに置くと、設計変更や運用改善の効果を評価できません。
クラウドのデメリット
クラウドは必ず安いわけではありません。常時稼働する大容量インスタンス、長期保存データ、複数リージョン間の通信、インターネットへのデータ送信、商用サポート、為替変動は、月額費用を押し上げます。特にオンプレミスでピーク負荷に合わせていた仮想マシンを、そのまま24時間クラウドで動かすと、利用率が低くても課金が継続します。
クラウドではサービスごとに料金体系が異なり、部署やプロジェクトが個別に契約すると、未使用リソースや重複したSaaS契約が残りやすくなります。クラウドサービス管理の考え方を取り入れ、アカウント、権限、契約、利用部門、費用負担先を一元化すると、不要な契約と放置リソースを発見しやすくなります。
可用性についても、クラウド事業者のデータセンターが冗長化されていることと、自社サービスが停止しないことは別です。単一リージョン、単一アカウント、単一のデータベースに依存する構成では、設定ミス、認証障害、アプリケーション障害、誤削除の影響を受けます。復旧時間目標と復旧時点目標を満たす構成を作り、バックアップからの復元試験まで完了して初めてDR対策として機能します。
費用最適化の運用
クラウド費用を継続的に管理する方法として、FinOpsがあります。FinOpsでは、財務、開発、運用の関係者が利用状況と費用を可視化し、事業価値に合わせてリソースを最適化します。
実務では、すべてのクラウドリソースへ「部門」「システム名」「環境」「費用負担先」「停止予定日」のタグを付けます。タグがあれば、月額費用が増えたときに、どの部門のどの環境が原因かを特定できます。開発環境が夜間・休日に不要なら自動停止し、安定利用のリソースは予約利用や長期契約の条件を比較し、利用率が低いリソースは縮小・削除します。
オンプレミスとクラウドの選び方
インフラの選定では、製品比較の前に業務要件と5年TCOの前提を揃えると、移行後の費用超過と運用不能を防げます。
選定チェックリスト
以下の項目を業務単位で埋めると、オンプレミス、クラウド、ハイブリッドのどれを比較すべきかを判断できます。
個人情報、営業秘密、設計情報、規制対象データを扱うか
データの保存先やバックアップ先を国・地域単位で指定する必要があるか
CPU、GPU、ストレージのピーク負荷と平均負荷はどの程度か
利用量は年間で安定しているか、繁忙期やイベントで急増するか
社内外へ転送するデータ量は月間でどの程度か
サービス開始までに許容できる期間は数日か、数か月か
24時間365日の監視、パッチ適用、障害対応を内製または委託で実行できるか
必要な復旧時間と、失ってよいデータ量を定義しているか
機器更新、移行、データ転送、ライセンス、人件費を含む5年TCOを試算したか
クラウド事業者や仮想化製品を変更する場合の出口戦略を持っているか
機密性が高く、負荷が安定し、構内システムとの低遅延連携が必要なら、オンプレミスまたは専用プライベート環境を先に比較します。短期間で立ち上げる必要があり、負荷変動が大きいなら、パブリッククラウドを先に比較します。両方の条件がある場合は、データ基盤と推論処理を専用環境へ置き、Web公開、開発、バッチ拡張をクラウドに分ける案を作成します。
3〜5年TCOの試算項目
TCO試算は、初期費用と月額料金を並べるだけでは不十分です。次の費目を同じ期間・同じ可用性要件で比較します。
費目 | オンプレミスでの確認内容 | クラウドでの確認内容 |
|---|---|---|
基盤費 | サーバー、GPU、ストレージ、ネットワーク、ラック、設置工事 | コンピュート、ストレージ、マネージドサービス、IPアドレス |
ソフトウェア費 | OS、仮想化、バックアップ、監視、セキュリティ、保守 | ライセンス持ち込み条件、SaaS、サポートプラン、監視サービス |
通信費 | 回線、拠点間接続、DR回線 | 専用線、インターネット接続、リージョン間通信、外向け転送 |
運用費 | 監視、障害対応、パッチ、資産管理、電力、空調 | 設定管理、権限管理、監視、請求分析、最適化、セキュリティ運用 |
移行・終了費 | データ移行、旧機器撤去、廃棄、データ消去 | アプリ改修、データ移行、二重運用、データ取り出し、契約終了時の移行 |
稟議では、オンプレミス更新、クラウド移行、ハイブリッドの3案を同じ条件で比較します。片方だけにDR環境や24時間保守を入れると比較が歪みます。復旧目標、利用者数、データ量、性能要件を共通条件にそろえたうえで、5年間の累計費用と年間運用工数を並べます。
国内企業の導入事例
マドラス株式会社は、クラウド型WMS「ロジザードZERO」を導入し、システムリプレイス費用を3割削減したと公表しています。この事例は、標準化できる倉庫管理業務ではSaaSを利用し、個別にサーバーを保有・更新する費用を見直す選択肢があることを示しています。成果は既存システムや導入範囲によって変わりますが、オンプレミス更新とSaaS利用を比較する際には、初期構築費だけでなく保守・更新工数まで評価する参考になります。
パナソニック デジタルは、統合データベース基盤にOracle Cloud Infrastructureを追加採用し、販売統計分析システムで年間7,000万円のコスト削減を実現したと公表しています。同社は、パナソニックグループ内でサーバー168台、容量540TB、25を超えるシステムがOCI上で稼働しているとも示しています。これは大規模なクラウド活用事例ですが、すべての企業に同じ効果が出るものではありません。対象システムの利用率、ライセンス、データ量、移行設計を分解して比較したことが成果の前提になります。
▲ 業務要件から最適なインフラ（オンプレ・クラウド・ハイブリッド）を選ぶ判断フロー
クラウド移行で失敗するパターンと対策
クラウド移行の失敗は、移行先の料金表だけを見て、利用率、通信量、運用手順、復旧方法を設計しないときに起こります。
リフトで止まるリフト＆シフト
リフト＆シフトとは、既存のオンプレミス環境をクラウドの仮想マシンへ移設し、その後にクラウド向けに最適化する手法です。問題は、移設しただけで最適化が止まることです。オンプレミス時代に余裕を持たせていたCPU、メモリ、ストレージをそのままクラウドで24時間稼働させると、利用率が低くても毎月の料金が発生します。
やってはいけないのは、ピーク時の構成をそのまま移し、月次の利用率確認をしないことです。移行前にCPU使用率、メモリ使用率、ストレージ増加量、ネットワーク転送量を最低3か月分取得します。平均利用率とピーク値を分けて記録し、ピーク負荷が短時間ならオートスケーリング、スケジュール停止、キュー処理、バッチ時間変更で吸収できるかを検討します。
アプリケーションをマネージドサービスやコンテナへ移せる場合は、改修費と運用削減効果を比較します。改修が難しく、負荷が安定しているシステムなら、無理にクラウドネイティブ化せずオンプレミス更新案を残します。
データ転送費の見落とし
クラウドの費用増で見落としやすいのが、データ転送です。社内システム、拠点、外部サービス、別リージョン、バックアップ先の間でデータを移動すると、通信量に応じた料金や回線費がかかる場合があります。大量のログ、動画、バックアップ、AI用データセットを毎日移動する構成では、コンピュート料金より転送費が大きくなることもあります。
対策は、移行前に通信フローを図にし、送信元、送信先、月間転送量、ピーク時間、暗号化方式、回線種別を一覧にすることです。データをクラウドへ集約するなら、処理も同じ環境へ寄せて往復通信を減らします。逆に、データの大半が構内に残る場合は、処理基盤までクラウドへ移す合理性があるかをTCOで比較します。
責任共有モデルの誤解
クラウド事業者がインフラを保護するため、自社のセキュリティ作業が不要になるという理解は誤りです。公開ストレージ、過剰な管理者権限、多要素認証の未設定、不要なアクセスキー、バックアップ未検証は、クラウドでも情報漏えいやサービス停止につながります。
利用開始時には、管理者アカウントの多要素認証、最小権限、操作ログの集中保管、暗号鍵の管理、バックアップ復元試験、退職者アカウント停止手順を標準化します。監査ログをAPIで取得できるサービスならログ基盤への自動収集を行い、API連携ができないサービスではCSV出力の定期保管と管理者レビューを運用へ組み込みます。
ハイブリッド構成の複雑化
オンプレミスとクラウドを組み合わせると、ネットワーク、ID、監視、請求、障害窓口が増えます。クラウド障害時にオンプレミスへ切り替える設計でも、DNS、データ同期、証明書、担当者連絡網、切り替え権限が未整備なら復旧できません。
対策として、構成図だけでなく、障害発生から復旧までの実行手順を作成します。少なくとも年1回は復旧訓練を行い、「誰が切り替えを判断するか」「どのデータ時点へ戻るか」「どの利用者へ連絡するか」を検証します。復旧訓練の人員を確保できない場合は、複雑な自動切り替えを増やすより、対象業務を重要なものに絞り、手順を確実に実行できる構成にします。
導入判断から運用開始までの実務手順
インフラ更改は、製品選定から始めず、業務要件、現状データ、TCO、検証、運用設計の順で進めると判断の根拠を残せます。
要件整理の段階
最初に対象業務を洗い出し、利用者数、利用時間、データ分類、保存期間、ピーク負荷、停止許容時間、復旧許容時間を記録します。この段階で「クラウド移行ありき」や「オンプレミス維持ありき」にすると、比較条件が歪みます。
データ分類では、公開情報、社内限定情報、個人情報、営業秘密、法令・契約で管理条件が定められた情報に分けます。社外へ持ち出せないデータがあるなら、データを残す場所と処理する場所を分ける構成も検討します。すべての処理を同じ基盤へ集める必要はありません。
現状把握とTCO試算の段階
次に、現行環境のCPU、メモリ、ストレージ、ネットワーク、バックアップ、ライセンス、保守契約、障害件数、運用工数を収集します。利用率を計測せずに新環境のサイズを決めると、過剰投資または性能不足が起きます。
試算期間は3〜5年とし、オンプレミス更新、クラウド移行、ハイブリッドの各案で条件を統一します。機器費、クラウド利用料、通信費、ソフトウェア、移行費、二重運用、運用人件費、監視、バックアップ、DR、契約終了時の移行費を含めます。VMware環境では、仮想化ライセンスの更新費と代替基盤への移行費を同じ期間で比べます。
検証と運用設計の段階
候補構成が決まったら、本番移行前に限定検証を行います。性能試験だけでなく、バックアップ復元、権限設定、監査ログ取得、障害通知、パッチ適用、運用引き継ぎまで確認します。性能が出ても、障害時に誰が何分以内に対応するかが決まっていなければ、本番環境としては完成していません。
対象業務とデータ分類を整理します。
現行の利用率、通信量、障害履歴、保守費を収集します。
オンプレミス、クラウド、ハイブリッドの3案で3〜5年TCOを試算します。
候補構成で性能、復元、ログ、権限、障害通知を検証します。
責任分界、連絡体制、費用管理、契約終了時の移行方法を決めます。
本番移行後は、利用率、費用、障害、復旧試験の結果を月次または四半期で見直します。
導入後の見直し基準
導入後は、当初試算と実績の差を確認します。クラウド費用が試算を超える場合は、タグ別の利用明細から原因を特定し、未使用リソースの削除、サイズ変更、停止スケジュール、データ配置の見直しを行います。オンプレミスで性能不足が起きる場合は、増設だけでなく、処理の分散、キャッシュ、データ保持期間、バッチ時間の見直しを比較します。
最初の一歩として、次回のサーバー更改やクラウド契約更新の対象から1業務を選び、現行の月間利用率と月間データ転送量を取得します。その数字を基に5年TCOを3案で並べると、オンプレミスかクラウドかという抽象的な議論を、実行可能な構成比較へ変えられます。
▲ 導入判断から運用開始までの4つの実務ステップ
よくある質問
オンプレミスの意味、費用、安全性、生成AI利用について、インフラ更改でよくある疑問に答えます。
オンプレミスは日本語で何と呼ばれるか
オンプレミスは「自社運用」や「構内設置」と説明されます。ただし、外部データセンターの専用ラックに機器を置き、監視・保守を委託する構成もあるため、自社だけで保守する方式と限定する説明は正確ではありません。
オンプレミスとクラウドのどちらが安全か
オンプレミスだから安全、クラウドだから危険とは決まりません。安全性は、アクセス制御、脆弱性対応、暗号化、監視、バックアップ、復旧訓練、委託先管理を実施できているかで決まります。
オンプレミスとクラウドのどちらが安いか
負荷が安定し、大量データを継続処理する業務ではオンプレミスが有利になる場合があります。短期利用や大きく変動する負荷ではクラウドが有利になりやすいため、移行費、通信費、保守、人件費、更新費を含む3〜5年TCOで比較します。
生成AIはオンプレミスで利用できるか
GPUサーバーとAIモデルを自社施設または専用環境へ配置すれば利用できます。機密データを外部サービスへ送る範囲を抑えられますが、GPU保守、電力・冷却、モデル更新、利用者権限、ログ監査を運用できる体制が必要です。
オンプレミスからクラウドへ移行するときの注意点
既存仮想マシンをそのまま移す前に、CPU・メモリ利用率とデータ転送量を測定します。復元試験、監査ログ、権限管理、障害時の連絡体制を検証し、要件を満たせない業務はオンプレミスまたは専用環境に残します。
まとめ
オンプレミスとは、利用組織が統制する専用環境にIT基盤を配置して利用する形態です。クラウドとの違いは、設備の所有形態だけではなく、費用構造、運用責任、拡張速度、データ所在地、障害対応にあります。
総務省が示す企業のクラウド利用率は80.6%に達していますが、VMwareのライセンス体系変更、生成AIのデータ主権、大容量データの転送費を背景に、基盤を再配置する企業もあります。負荷が安定する処理はオンプレミスや専用環境、変動負荷や短期検証はクラウド、両方の要件を持つ業務はハイブリッド構成で比較します。
明日から始めるなら、対象業務を1つ選び、CPU利用率、月間データ転送量、保守・ライセンス費、復旧要件を一覧化します。その数字を使ってオンプレミス更新、クラウド移行、ハイブリッドの5年TCOを並べると、自社に必要なインフラ構成を具体的に判断できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
