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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』・『AWS1年生 クラウドのしくみ』も参考にしてみてください。

そもそもデプロイモデルとは何か

デプロイモデルとは、ざっくり言えば「システムをどこに置いて、誰が面倒を見るかの形態」です。

飲食店の出店形態を想像してください。自社ビルに出店（オンプレミス）すれば自由度は高いが建設費と維持費がかかります。テナント（パブリッククラウド）なら初期費用は安く設備も共用ですが、壁の色一つ変えるにもビルのルールに従います。自社ビルの一角をテナント風に整備する（プライベートクラウド）方法もあれば、自社ビルとテナントを併用する（ハイブリッド）パターンもあります。どの出店形態を選ぶかで、初期コスト・家賃・自由度・撤退のしやすさが全て変わる──デプロイモデルの選定はこれと同じです。

なぜデプロイモデルの選択が重要なのか

もしデプロイモデルを深く考えずに進めたらどうなるか。「とりあえずクラウド」で始めたら、半年後に法規制でデータの国内保管が必須と判明し、アーキテクチャを丸ごと作り直す──あるいは「うちはずっとオンプレ」で通したら、サーバー増設に3か月かかってビジネスチャンスを逃す。選択次第で初期コスト・運用コスト・セキュリティ・柔軟性がそっくり入れ替わります。

2010年代前半は「オンプレかクラウドか」の二択でした。今はパブリッククラウド・プライベートクラウド・ハイブリッド・マルチクラウドと選択肢が多様化し、企業規模・業種・法規制・既存資産の有無で最適解が変わります。特に日本の金融・公共系ではクラウド利用そのものに法的制約が絡み、単なる技術判断では済まない領域です。

デプロイモデルの選定は、CTOや情報システム部長レベルの経営判断に近いレイヤーの決定です。ビジネス・法規制・技術の三位一体で決まる戦略判断であり、エンジニアだけで決めきれる話ではありません。

主な5つの形態

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

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

オンプレミス

オンプレミス（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 Outposts・Azure Stack等）が主流で、「物理的にはクラウド事業者の管理だが論理的には自社専用」という構造です。自社DCを建てる必要がないため、初期コストを抑えつつ専用環境の安全性を確保できます。

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

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

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

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

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

ハイブリッドクラウド

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

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

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

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

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

マルチクラウド

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

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

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

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

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

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

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

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

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

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

選定基準

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

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

規模別の推奨構成

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

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

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

AI時代の判断軸 ― IaCで完結するか

AI駆動開発が前提になると、デプロイモデル選定では「IaCで完結するか」が非常に大きな比重を占めるようになります。

単一クラウドだとAIの精度が上がる理由

AIにインフラコードを書かせるとき、AWSだけ・GCPだけに閉じているプロジェクトと、両方混在しているプロジェクトでは精度に明確な差が出ます。単一クラウドなら、AIはそのクラウドのサービス名・設定パラメータ・IAM構造を一貫して扱えます。マルチクラウドになると、似て非なるサービス（例: AWS ALB と GCP Cloud Load Balancing）を混同したり、片方のベストプラクティスをもう片方に適用してしまうケースが増えます。

これは「マルチクラウドを絶対にやるな」という話ではなく、マルチクラウドを選ぶなら各クラウドのIaCを明確にリポジトリ・ディレクトリで分離する必要があるということです。AIに渡す文脈を明確に切り分けないと、混在した設定を生成されて障害の元になります。

IaCとAIの組み合わせで変わる運用

Terraform・CDK・Pulumiなどで構成をコード化しておくと、AIが以下のことをできるようになります。

• 構成変更のPR作成 — 「RDSのインスタンスタイプをdb.r6g.largeに上げて」と伝えるだけでIaCの差分PRが出てくる
• コスト影響の事前見積もり — infracost 等のツールと組み合わせて、変更前に月額コスト差を表示する
• セキュリティポリシーのチェック — IaCの静的解析（tfsec・checkov）をCIに組み込み、AIがポリシー違反の修正案を提示する

逆に、GUIでポチポチ設定している環境では、AIはインフラの現状を把握する手段がありません。「今の構成を教えて」と聞かれても答えられないため、AIの支援を受けられる範囲が極端に狭くなります。

「AIが書けるから複雑でもOK」ではなく、「AIが読み書きできる形でインフラを管理する」のが前提条件です。

選定の優先順位

1. 法規制・業種要件で除外される形態を確認（金融・医療・公共）
2. 既存オンプレ資産の重さを見積もる（捨てられないなら段階的ハイブリッド）
3. 運用人員の厚みでマルチクラウドを足切り（専門家2人未満なら単一クラウド）
4. IaC化できるかを判定軸にする — GUIでしか管理できない構成は将来のAI活用を阻害する
5. マルチクラウドを選ぶ場合はリポジトリ・ディレクトリを明確に分離 — AIに渡す文脈を混ぜない

やってはいけないこと

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

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

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

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

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

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

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

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

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

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

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

決定理由の残し方

デプロイモデルの選定は影響範囲が大きく、後から変更するコストも高いため、決定時点の判断根拠を ADRとして残すことを強く推奨します。以下に具体例を示します。

ADR はコードリポジトリの docs/adr/ に Markdown で保管し、PR レビューと同じフローで承認するのがおすすめです。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADR の最大の価値です。

この記事に関連する記事

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS クラウドコンピューティングとは も合わせて参考にしてください。

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