デプロイモデルの選び方 ― オンプレ/クラウド/ハイブリッド ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第2弾として、システムを「どこに置いて、誰が運用するか」を決めるデプロイモデルについて解説する記事です。

物理機器を自社で持つか、クラウドを借りるか、両方を併用するか──この判断が初期コスト・運用コスト・セキュリティ・柔軟性をそっくり入れ替えます。本記事ではオンプレ／パブリック／プライベート／ハイブリッド／マルチクラウドの5形態と、規模別の推奨構成・選定フローを解説します。

このカテゴリの他の記事

システムをどこに置き、誰が運用するか

新規システムの計画段階で、アプリケーション形態の次に問われるのがここです。物理機器を自社で持つのか、クラウドを借りるのか、両方を併用するのか。選択次第で初期コスト・運用コスト・セキュリティ・柔軟性がそっくり入れ替わります。

2010年代前半は「オンプレかクラウドか」の二択でした。今はパブリッククラウド・プライベートクラウド・ハイブリッド・マルチクラウドと選択肢が多様化し、企業規模・業種・法規制・既存資産の有無で最適解が変わります。

特に日本の金融・公共系ではクラウド利用そのものに法的制約が絡み、単なる技術判断では済まない領域です。

デプロイモデルの選定は、CTOや情報システム部長レベルの経営判断に近いレイヤーの決定です。エンジニアだけで決めきれる話ではなく、法務・調達・経営を巻き込んで判断する必要があります。このことを最初に理解しておかないと、技術的には最適でも組織内で通らない提案を書くことになります。

デプロイモデルはビジネス・法規制・技術の三位一体で決まる戦略判断です。

主な5つの形態

デプロイモデルは大きく5つに分類されます。現代の企業システムは、これらのいずれか、または複数の組み合わせで成り立っています。

flowchart LR
    ON[オンプレミス<br/>自社で物理機器]
    PRIV[プライベートクラウド<br/>自社専用クラウド]
    HYB[ハイブリッド<br/>オンプレ+クラウド連携]
    PUB[パブリッククラウド<br/>AWS/Azure/GCP共有]
    MULTI[マルチクラウド<br/>複数クラウド併用]
    ON --> PRIV
    PRIV --> HYB
    HYB --> PUB
    PUB --> MULTI
    ON -. "管理範囲: 全部自社" .- LABEL_L[管理大]
    MULTI -. "管理範囲: 最小" .- LABEL_R[管理小]
    classDef onp fill:#fee2e2,stroke:#dc2626;
    classDef priv fill:#fef3c7,stroke:#d97706;
    classDef hyb fill:#f0f9ff,stroke:#0369a1;
    classDef pub fill:#dbeafe,stroke:#2563eb;
    classDef mul fill:#fae8ff,stroke:#a21caf;
    class ON onp;
    class PRIV priv;
    class HYB hyb;
    class PUB pub;
    class MULTI mul;

形態	内容
オンプレミス	自社で物理サーバーを持ち運用
パブリッククラウド	AWS/Azure/GCPなどを共有利用
プライベートクラウド	自社専用のクラウド環境
ハイブリッドクラウド	オンプレとクラウドを連携
マルチクラウド	複数のクラウドを併用

新規システムの大半はパブリッククラウドで建てますが、既存の大企業ではハイブリッドが現実解です。「全部クラウドに移行しました」は意外にも少数派で、日本の大企業の多くは基幹系にオンプレを残したまま、新規システムだけクラウドで建てる構成に落ち着いています。

オンプレミス

オンプレミス（on-premise）は、自社で物理的なサーバー・ネットワーク機器・ストレージを購入・設置し、データセンターや機械室で運用する伝統的な形態です。クラウドという概念が生まれる前は、これが唯一の選択肢でした。

メリット	デメリット
カスタマイズ性が極めて高い	初期コストが非常に高い
物理的隔離で高セキュリティ	機器調達に時間がかかる（数週間〜数ヶ月）
レイテンシを完全制御可	運用を全て自社で行う必要
既存資産を活用できる	災害・障害時の復旧が困難

オンプレは今も金融機関の中核システム・官公庁・医療機関・製造業の制御系には根強く残っています。理由は法規制・セキュリティ要件・レガシー資産の重さ。技術的な問題ではなく、動かせない事情があるケースが大半です。

「古いから残っている」のではなく、「残る理由があるから残っている」と見るのが正確です。

新規にオンプレを選ぶケースは、2026年時点ではほぼ稀です。ただし既存資産の上に機能追加する案件では、今もオンプレが選択肢として残ります。

パブリッククラウド

パブリッククラウドは、AWS・Azure・Google Cloud といった巨大事業者が提供するインフラを、複数企業で共有して利用する形態です。「初期投資ゼロ・従量課金」という構造が、2010年代以降のスタートアップ爆発を支えました。

メリット	デメリット
初期コストがほぼゼロ	カスタマイズに制限がある
従量課金制でコスト最適化	他社と物理リソース共有
即日から使用可能	厳格なセキュリティ基準を満たしにくい場合
自動スケール・リソース変更	ベンダーロックインのリスク

代表的なサービスは AWS EC2 / S3 / Lambda、Azure VM / App Service、GCP Compute Engine / Cloud Run。新規サービスの8割以上はパブリッククラウドで組まれており、事実上のデフォルト選択肢です。2006年のAWS EC2登場から20年経って、「新規はパブリッククラウド」の流れは揺るぎないものになりました。

新規プロジェクトはここから疑います。これ以外を選ぶなら「なぜパブリッククラウドではないか」を説明できる必要があります。説明できないなら、それは技術判断ではなく感情判断です。

新規プロジェクトはパブリッククラウドがデフォルトです。外すなら理由を1分で書き出すのが定石です。

プライベートクラウド

プライベートクラウドは、特定の企業・組織専用に用意された独立したクラウド環境です。「クラウドの柔軟性」と「専用環境の安全性」を両立させるアプローチで、金融・医療・官公庁で採用されます。

種類	説明
オンプレミス型	自社データセンターにクラウド環境を構築
ホスティング型	AWSなどのクラウド内に自社専用区画を作る（現在の主流）

今はホスティング型（AWS Outposts・Azure Stack等）が主流で、「物理的にはクラウド事業者の管理だが論理的には自社専用」という構造です。自社DCを建てる必要がないため、初期コストを抑えつつ専用環境の安全性を確保できます。

メリット	デメリット
パブリッククラウドの柔軟性	パブリックよりコスト増
セキュリティ基準を高められる	構築と運用に手間
他利用者の影響なし・安定性高	リソース調達が遅い場合あり

プライベートクラウドは「クラウドと専用環境のハイブリッド」です。規制業種で特に効きます。

AWSでのプライベートクラウド実現

AWSを例にとると、求められる分離レベルで使えるサービスが複数あります。「どこまで他と隔離する必要があるか」を要件から逆算して選ぶのが筋です。

サービス	分離レベル	用途
Amazon VPC	論理レベル（仮想ネットワーク）	最も基本的な分離
AWS PrivateLink	内部通信レベル	インターネットを経由しない通信
Direct Connect / VPN	外部通信レベル	専用線での接続
EC2 Dedicated Hosts	物理レベル	他社と物理サーバーを共有しない
AWS Outposts	拠点レベル	自社DC内にAWS環境

VPCでの論理分離は無料で、ほぼ全てのAWS利用者が使っています。Dedicated Hostsは物理サーバーを占有する上位オプションで、金融・医療で「物理共有不可」の要件があるときだけ採用する、最終兵器の類です。「念のため」で物理分離を選ぶとコストが数倍に跳ねます。

分離レベルは要件に応じて段階的に上げます。過剰は無駄に直結します。

ハイブリッドクラウド

ハイブリッドクラウドは、オンプレミス（またはプライベートクラウド）とパブリッククラウドを組み合わせて連携させる形態です。日本の大企業では、これが現実の中心形です。

「既存のオンプレシステムをそのまま残し、新規分だけクラウドで作る」「基幹系はオンプレ、フロント系はクラウド」「機密データはオンプレ・分析はクラウド」このあたりが典型パターンです。完全クラウド移行できない事情（既存資産・法規制・監査・経営判断）を抱えたまま、新規だけクラウド化する。それがハイブリッドの実態です。

メリット	デメリット
古いシステムを残しつつクラウド活用可	コスト最適化しにくい
機密データだけ物理的に分離できる	システム構成・運用が複雑化
段階的なクラウド移行が可能	両方の専門知識が必要

ハイブリッドを選ぶ最大の理由は、「全部クラウド化したいが、既存資産を捨てられない」という組織の現実です。技術的な最適解ではなく、組織の過去と未来を繋ぐ折衷案として採用されます。

だから運用コストは高く、技術チームの負担も重い。これを「段階移行の中間地点」と位置付けて、最終的には単一クラウドに寄せる計画を持っているかどうかで、ハイブリッドが健全な選択になるか負債になるかが分かれます。

ハイブリッドクラウドは大企業の現実的な着地点です。全クラウド化は、やってみると意外に難しいものです。

マルチクラウド

マルチクラウドは、AWS＋Azure、AWS＋GCP のように複数のパブリッククラウドを組み合わせる形態です。「ベンダーロックイン回避」や「用途ごとに最適な製品を選ぶ」が目的ですが、運用難度は跳ね上がります。

メリット	デメリット
用途に合わせた最適サービス選択	システム構成・運用が複雑化
特定ベンダーへの依存を避けられる	コスト最適化が難しい
障害影響の分散	各環境毎に専門知識が必要

「計算リソースはAWS、AIはGCP、Office連携はAzure」のように、各ベンダーの強みを組み合わせるのがマルチクラウドの思想です。理想は美しい。ただし運用・監視・セキュリティを全環境で統一するのは極めて困難で、「やらないほうが良い」と判断されるケースが多数派です。

「念のためマルチクラウド」は典型的な甘い選択で、両クラウドの専門人材を確保できない中小規模では、導入の瞬間から運用負債を背負います。マルチクラウドを選ぶ実質的な下限は、専任インフラ人員3人以上。これ未満で選ぶと、アップデート追従・監視統合・権限管理だけで現場が溶けます。

マルチクラウドは明確な理由がある時だけ採用します。デフォルトで選ぶと運用コストが跳ねます。

オンプレ vs クラウドのコスト比較

「クラウドの方が安い」という刷り込みがありますが、規模と期間によってはオンプレのほうが安いこともあります。総保有コスト（TCO、Total Cost of Ownership）で比較するのが正確な判断基準です。

項目	オンプレ	パブリッククラウド
初期費用	数百万〜数億円	ほぼゼロ
月額費用	減価償却 + 電気代 + 運用人件費	従量課金
5年TCO（小〜中規模）	高い	安い
5年TCO（大規模・高負荷）	安い（長期）	高い（負荷増大で爆発的増加）

有名な事例として、Dropboxは2015〜2016年の「Magic Pocket」プロジェクトで自社ストレージ基盤をAWSから自前データセンターに戻し、数年にわたって年間数千万ドル規模のコスト削減を公表しています。Amazon内部ですら、一部のワークロードは自社DCに戻す動きがあります。

クラウドは「立ち上がりが早い・柔軟」には圧倒的ですが、大規模で使い込むとコストが跳ねる。万能ではありません。

ただしこれは「Dropbox規模」の話です。9割以上のサービスはDropbox規模に到達する前に閉じますし、到達するのも5〜10年かかります。「将来Dropbox規模になるから最初からオンプレ」は、典型的な早すぎる最適化で、ほぼ間違いなく失敗します。

クラウドは万能ではありません。ただしDropbox規模の話は9割の会社に関係ないのも事実です。

選定基準

選定はコスト・ビジネス特性・セキュリティ要件の三軸で決まります。典型ケースと推奨モデルを整理します。

ケース	推奨モデル
制約なし・コストと運用を抑えたい	パブリッククラウドのみ
データ保存場所に高セキュリティが必要	ハイブリッドクラウド
Google/Microsoft系との連携が必須	特定ベンダー寄せ or マルチクラウド
既存オンプレ資産が大きい	ハイブリッド（段階移行）
金融・医療・官公庁	プライベートクラウド / オンプレミス

新規スタートアップ・個人開発なら、「迷うな、パブリッククラウドだ」特別な理由なしにオンプレを選ぶのは時代錯誤で、採用にも悪影響が出ます。2026年時点で「オンプレ中心」の会社に若手エンジニアを集めるのは、年々難しくなっています。

規模別の推奨構成

同じ「パブリッククラウド」でも、組織規模によって組むべき構成が変わります。月額コストの目安と、そこに見合う運用体制をセットで見るのが現実的です。

組織フェーズ	月額インフラ費目安	推奨構成	専任インフラ人員
MVP・個人開発	〜5万円	単一パブリッククラウド・1リージョン・マネージド中心	0人（兼任）
初期スタートアップ	5万〜50万円	単一クラウド・マルチAZ・IaC化必須	0.5人（兼任）
中規模 SaaS	50万〜500万円	単一クラウド・マルチAZ + DR用2リージョン	1〜3人
大企業基幹系	500万〜	ハイブリッド（既存資産+クラウド）・専用線・AWS Organizations	5人〜
金融・公共・医療	業種次第	プライベートクラウド or ハイブリッド + コンプライアンス認定	10人〜

マルチクラウド・ハイブリッドを選ぶ実質的な下限は、専任インフラ人員3人以上。これ未満で選ぶと、両クラウドのアップデート追従・監視統合・権限管理だけで現場が溶けます。「将来に備えて」でマルチクラウドを先取りするのは典型的な甘い選択で、必要になってからでも遅くありません。

単一クラウドで困る規模になるまでは「一つに寄せる勇気」が運用を救います。

マルチクラウド・ハイブリッドの鬼門

ここで事故が起きる典型パターンを整理します。特にハイブリッド・マルチクラウドは「導入した瞬間から運用コストが倍増する」ため、禁じ手を避けるだけで大怪我を防げます。

禁じ手	なぜダメか
「念のため」でマルチクラウドを初期採用	両方の専門家雇用・監視統合・SSO統合で、コストと複雑さが線形でなく指数的に増える
オンプレとクラウドで同じIP帯を使う	VPN/専用線接続時にルーティング衝突で接続不能。CIDR設計は最初に統合する
ハイブリッドの運用手順を片方だけ整備	オンプレだけRunbookがあってクラウド側は手作業、の逆も破綻の元
クラウドとオンプレの認証基盤を二重化	パスワード・権限の同期ずれで監査で詰まる。AD / IdPを単一化して連携する
データ転送量（egress、送信量）を見積もらずハイブリッド構築	クラウド→オンプレの月次データ移送だけで数百万円の請求になる事例が定番
マルチクラウド + 独自抽象化レイヤ自作	「クラウド中立」の自作ラッパーは半年でメンテ限界。Kubernetes以外で自作は筋が悪い

コスト比較は3年TCO（総保有コスト）で計算するのが標準です。Dropboxが AWS から自社DCへ「戻した」判断は、数年単位のTCOで初めて成立する話で、数ヶ月の請求だけを見て結論を出すと必ず間違えます。

ハイブリッド／マルチクラウドは人員3人未満で選ばない。運用が回らず機能しません。

AI時代の視点

AI駆動開発（バイブコーディング）が前提になると、デプロイモデル選定の最大軸は「IaCで完結するか」一点に収束します。オンプレの手作業・独自運用ツール・ベンダー固有のGUIコンソールはAIから操作できません。

一方、コードで全て表現できるパブリッククラウドは圧倒的に有利です。AIがTerraform・CloudFormation・Bicepのコードを書き、人間はレビュー・方針決定に集中する。この構図が標準になります。

AI時代に有利	AI時代に不利
パブリッククラウド + IaC全面採用	オンプレ・手作業構築
単一クラウドに寄せる（AIの文脈が集中）	マルチクラウド（設定分散・AIがハルシネーション）
コンテナ + Kubernetes manifest	GUI前提のPaaS管理画面
ハイブリッドでもIaCで境界を明示	オンプレが「触れるブラックボックス」のまま残る

ハイブリッド・マルチクラウドは運用複雑性が高く、AIでもその複雑性は消えません。「AIが書けるから複雑でもOK」ではなく、「AIが書ける範囲にアーキテクチャを保つ」のが新しい設計原則です。

AI時代の鉄則は「全てコードで表現できる」こと。コード化できないレガシーは負債として扱います。

週末の請求書事件（業界事例）

検証環境を金曜夜に立ち上げ、週末に落とし忘れたまま月曜を迎え、月末に想定の10倍の請求書が来た。というケースは、クラウド移行初期の会社で珍しくありません。特にGPUインスタンス・大型RDS・NATゲートウェイを「ちょっと試すだけ」で起動し、停止を忘れるパターンが定番です。

クラウドは「使った分だけ」という看板を信じて油断すると、「使っていない時間も課金される」種類のリソースでやられます。NATゲートウェイ・ELB・EIP（未使用の固定IP）がその代表格で、立ち上げた本人が気づかないうちに毎日数千円が溶けていく、というのがこの手の事件の相場です。

対策は単純で、コスト上限アラート（AWS Budgets、GCP Billing Alerts）を必ず設定し、月額の閾値を超えたら即通知を受ける仕組みにしておく。これを入れていないクラウド運用は、事故が起きるのは時間の問題と見ていいです。

クラウドの「従量課金」は、使っていなくても課金される部品があります。コストアラート必須です。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• 基本のデプロイモデル（クラウド / オンプレ / ハイブリッド）
• クラウドベンダーの選定（AWS / GCP / Azure / 国産）
• 分離レベル（共有 / 論理分離 / 物理分離）
• データ保管場所（国・リージョン・規制対応）
• 既存システムとの連携方式
• コスト上限とモニタリング
• 災害対策・BCP（Business Continuity Plan、事業継続計画）要件

よくある失敗

• 「クラウドが安い」で全移行 → 請求書に驚愕 ― 使い方次第でオンプレのほうが安い規模は実在します。TCO計算を飛ばすと痛い目を見ます
• オンプレ資産があるのに全クラウド化を目指す ― 既存資産が無駄になり、移行中のダブル運用で運用チームが疲弊します
• マルチクラウドを中途半端に導入 ― 結局どのクラウドも使いこなせず、全てが中途半端。典型的な筋が悪い選択です
• データ保管地域を確認せず違反 ― GDPR（General Data Protection Regulation、EUの個人情報保護規制）等で海外リージョンのデータ保管が問題化するケースがあります
• ハイブリッド運用の複雑さを軽視 ― オンプレとクラウドの整合を取るだけで運用チームが溶けていきます

最終的な判断の仕方

デプロイモデルの選定は、技術判断ではなくビジネス判断です。コスト・規制・既存資産・経営方針が絡むため、「技術的に最適」だけで選ぶと組織内で通りません。

最初に確認すべきは法規制と既存資産、次に運用できる人員の厚み、そのうえで技術要件を当てはめる。この順番を守れば、現実解から大きく外れません。

新規はパブリッククラウド一択が今のデフォルトです。ハイブリッドは「移行できない理由がある」時の現実解、マルチクラウドは「明確な理由がある」時の選択肢、という序列が定まりました。AI駆動開発の観点では、IaCで完結する構成（単一クラウド ＋ コード管理）の優位が決定的で、オンプレ・マルチクラウドの運用複雑性はAIでも消せません。

選定の優先順位をまとめると次の通りです。

1. 法規制・業種要件で除外される形態を確認（金融・医療・公共）
2. 既存オンプレ資産の重さを見積もる（捨てられないなら段階的ハイブリッド）
3. 運用人員の厚みでマルチクラウドを足切り（専門家2人未満なら単一クラウド）
4. IaC化できるかを将来負債の判定軸にする

新規は「単一パブリッククラウド + IaC」から疑わない。ハイブリッド・マルチは「払える組織」の贅沢品です。

まとめ

本記事はシステムを「どこに置いて、誰が運用するか」を決めるデプロイモデルの選び方を解説しました。如何だったでしょうか。

新規プロジェクトはパブリッククラウドが圧倒的なデフォルトで、ハイブリッド・マルチクラウドは明確な理由と人員体制がある場合に限定するのが2026年の健全解です。AI時代では、IaCで完結する単一クラウド構成の優位がさらに強まっています。

次回はパブリッククラウドを選んだ後の最大の決定、「クラウドベンダー選定」（AWS / Azure / GCP）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。