本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第2弾として、システムを「どこに置いて、誰が運用するか」を決めるデプロイモデルについて解説する記事です。
物理機器を自社で持つか、クラウドを借りるか、両方を併用するか──この判断が初期コスト・運用コスト・セキュリティ・柔軟性をそっくり入れ替えます。本記事ではオンプレ／パブリック／プライベート／ハイブリッド／マルチクラウドの5形態と、規模別の推奨構成を解説します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』・『AWS1年生 クラウドのしくみ』も参考にしてみてください。
この記事の結論
- 新規はパブリッククラウドがデフォルト
- ハイブリッド・マルチクラウドは明確な理由と専任3人以上の体制がある場合だけ
- IaCで完結する単一クラウド構成に寄せる
- コスト上限アラートを初日に設定する
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもデプロイモデルとは何か
デプロイモデルとは、ざっくり言えば「システムをどこに置いて、誰が面倒を見るかの形態」です。
飲食店の出店形態を想像してください。自社ビルに出店（オンプレミス）すれば自由度は高いが建設費と維持費がかかります。テナント（パブリッククラウド）なら初期費用は安く設備も共用ですが、壁の色一つ変えるにもビルのルールに従います。自社ビルの一角をテナント風に整備する（プライベートクラウド）方法もあれば、自社ビルとテナントを併用する（ハイブリッド）パターンもあります。どの出店形態を選ぶかで、初期コスト・家賃・自由度・撤退のしやすさが全て変わる──デプロイモデルの選定はこれと同じです。
なぜデプロイモデルの選択が重要なのか
もしデプロイモデルを深く考えずに進めたらどうなるか。「とりあえずクラウド」で始めたら、半年後に法規制でデータの国内保管が必須と判明し、アーキテクチャを丸ごと作り直す──あるいは「うちはずっとオンプレ」で通したら、サーバー増設に3か月かかってビジネスチャンスを逃す。選択次第で初期コスト・運用コスト・セキュリティ・柔軟性がそっくり入れ替わります。
特に日本の金融・公共系ではクラウド利用そのものに法的制約が絡み、単なる技術判断では済まない領域です。デプロイモデルの選定はビジネス・法規制・技術の三位一体で決まる経営判断に近いレイヤーの決定で、エンジニアだけで決めきれる話ではありません。
主な5つの形態
デプロイモデルは大きく5つに分類されます。現代の企業システムは、これらのいずれか、または複数の組み合わせで成り立っています。
| 形態 | 内容 |
|---|---|
| オンプレミス | 自社で物理サーバーを持ち運用 |
| パブリッククラウド | AWS/Azure/GCPなどを共有利用 |
| プライベートクラウド | 自社専用のクラウド環境 |
| ハイブリッドクラウド | オンプレとクラウドを連携 |
| マルチクラウド | 複数のクラウドを併用 |
新規システムの大半はパブリッククラウドで建てますが、既存の大企業ではハイブリッドが現実解です。「全部クラウドに移行しました」は意外にも少数派で、日本の大企業の多くは基幹系にオンプレを残したまま、新規システムだけクラウドで建てる構成に落ち着いています。
それぞれの使いどころ
パブリッククラウド ― 新規のデフォルト
パブリッククラウドは、AWS・Azure・Google Cloudといった巨大事業者のインフラを複数企業で共有する形態です。「初期投資ゼロ・従量課金・即日利用開始」という構造が2010年代以降のスタートアップ爆発を支え、新規サービスの8割以上がここで組まれる事実上のデフォルトです。弱点はカスタマイズの制限とベンダーロックインですが、これ以外を選ぶなら「なぜパブリッククラウドではないか」を1分で説明できる必要があります。説明できないなら、それは技術判断ではなく感情判断です。
オンプレミス ― 残る理由があるから残る
オンプレミスは、自社で物理サーバーを購入・設置して運用する伝統的な形態です。カスタマイズ性と物理的隔離は最強ですが、初期コスト数百万円〜・調達リードタイム数週間〜・運用の全自社負担という代償を払います。今も金融機関の中核システム・官公庁・製造業の制御系に根強く残っていますが、それは「古いから残っている」のではなく、法規制・セキュリティ要件・レガシー資産という「残る理由があるから残っている」のです。新規にオンプレを選ぶケースは2026年時点ではほぼ稀です。
プライベートクラウド ― 規制業種の専用環境
プライベートクラウドは、特定の組織専用に用意されたクラウド環境で、金融・医療・官公庁で採用されます。現在の主流は、AWS等のクラウド内に自社専用区画を作るホスティング型です。分離レベルには段階があり、無料で使える論理分離（VPC）から、インターネットを経由しない通信（PrivateLink）、専用線接続（Direct Connect）、物理サーバー占有（Dedicated Hosts）まで、要件から逆算して選びます。「念のため」で物理分離を選ぶとコストが数倍に跳ねるため、過剰な分離レベルは無駄に直結します。
ハイブリッドクラウド ― 大企業の現実的な着地点
ハイブリッドクラウドは、オンプレとパブリッククラウドを連携させる形態で、日本の大企業では現実の中心形です。「基幹系はオンプレ、フロント系はクラウド」「機密データはオンプレ・分析はクラウド」が典型パターンで、既存資産を捨てられない組織の過去と未来を繋ぐ折衷案として採用されます。その分、運用コストは高く両方の専門知識が要ります。これを「段階移行の中間地点」と位置付けて最終的に単一クラウドへ寄せる計画を持っているかどうかで、健全な選択になるか負債になるかが分かれます。
マルチクラウド ― 明確な理由がある時だけ
マルチクラウドは、AWS+Azure・AWS+GCPのように複数のパブリッククラウドを併用する形態です。「計算リソースはAWS、AIはGCP、Office連携はAzure」と各ベンダーの強みを組み合わせる思想で、理想は美しいのですが、運用・監視・セキュリティを全環境で統一するのは極めて困難です。実質的な下限は専任インフラ人員3人以上。これ未満で「念のため」採用すると、アップデート追従・監視統合・権限管理だけで現場が溶けます。
コストの真実 ― クラウドは常に安いわけではない
「クラウドの方が安い」という刷り込みがありますが、規模と期間によってはオンプレのほうが安いこともあります。有名な事例として、Dropboxは2015〜2016年の「Magic Pocket」プロジェクトで自社ストレージ基盤をAWSから自前データセンターに戻し、年間数千万ドル規模のコスト削減を公表しています。クラウドは立ち上がりの速さと柔軟性には圧倒的ですが、大規模で使い込むとコストが跳ねる──万能ではありません。
ただしこれは「Dropbox規模」の話です。9割以上のサービスはその規模に到達する前に閉じますし、到達するにも5〜10年かかります。「将来Dropbox規模になるから最初からオンプレ」は典型的な早すぎる最適化です。コスト比較をするなら、初期費用だけでも月額だけでもなく、3年TCO（総保有コスト）で計算するのが標準です。
どう選べばいいのか ― 規模別の3シナリオ
個人開発・スタートアップなら ― パブリック一択+コストアラート
ここは迷う余地がないと思います。単一パブリッククラウド・1リージョン・マネージドサービス中心で組んでしまいましょう。特別な理由なしにオンプレを選ぶのは時代錯誤ですし、採用にも悪影響が出てしまいます。唯一最初にやるべき防御がコスト上限アラート（AWS Budgets等）の設定です。初期スタートアップに成長したら、マルチAZ化とIaC化を必須にします。
中小SaaSなら ― 単一クラウドに寄せる勇気
単一クラウド・マルチAZ・IaC全面採用が基本形で、可用性要件が上がったらDR用の2リージョン目を足します。「将来に備えて」のマルチクラウド先取りは典型的な悪手で、必要になってからでも遅くありません。単一クラウドで困る規模になるまでは「一つに寄せる勇気」が運用とAI生産性の両方を救います。
大企業・規制業種なら ― 段階移行のハイブリッド
既存オンプレ資産が大きいなら、ハイブリッドで段階移行するのが現実解です。専用線（Direct Connect）+AWS Organizations等の統制を整え、CIDR設計と認証基盤（AD/IdP）は最初に統合しておきます。金融・医療・公共はプライベートクラウドやコンプライアンス認定込みの構成が前提になり、データ保管地域の法要件（GDPR等）の確認も必須です。
規模別の目安
| 組織フェーズ | 推奨構成 | 専任インフラ人員 |
|---|---|---|
| MVP・個人開発 | 単一クラウド・1リージョン・マネージド中心 | 0人（兼任） |
| 初期スタートアップ | 単一クラウド・マルチAZ・IaC必須 | 0.5人（兼任） |
| 中規模SaaS | 単一クラウド・マルチAZ+DR用2リージョン | 1〜3人 |
| 大企業基幹系 | ハイブリッド・専用線・Organizations | 5人〜 |
| 金融・公共・医療 | プライベートクラウド or ハイブリッド+認定 | 10人〜 |
AI判断軸 ― IaCで完結するか
AI駆動開発が前提になると、デプロイモデル選定では「IaCで完結するか」が非常に大きな比重を占めます。
単一クラウドだとAIの精度が上がる
AIにインフラコードを書かせるとき、単一クラウドに閉じているプロジェクトと複数混在のプロジェクトでは精度に明確な差が出ます。単一ならAIはサービス名・設定パラメータ・IAM構造を一貫して扱えますが、マルチクラウドでは似て非なるサービス（AWS ALBとGCP Cloud Load Balancing等）を混同したり、片方のベストプラクティスをもう片方に適用してしまうケースが増えます。マルチクラウドを選ぶなら、各クラウドのIaCをリポジトリ・ディレクトリで明確に分離し、AIに渡す文脈を混ぜないことが必須になります。
IaCとAIの組み合わせで変わる運用
Terraform・CDK等で構成をコード化しておくと、「RDSのインスタンスタイプを上げて」と伝えるだけでAIがIaCの差分PRを作り、infracost等と組み合わせて変更前に月額コスト差を見積もり、tfsec・checkovの静的解析違反の修正案まで提示できるようになります。逆にGUIで設定している環境では、AIはインフラの現状を把握する手段がなく、支援を受けられる範囲が極端に狭くなります。「AIが読み書きできる形でインフラを管理する」ことが全ての前提条件です。
やってはいけないこと
ハイブリッド・マルチクラウドは導入した瞬間から運用コストが倍増するため、禁じ手を避けるだけで大怪我を防げます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 「念のため」でマルチクラウドを初期採用 | 専門家雇用・監視統合でコストが指数的に増える → 単一クラウドで始め、必要になってから足す |
| オンプレとクラウドで同じIP帯を使う | VPN/専用線接続時にルーティング衝突で接続不能 → CIDR設計を最初に統合する |
| 認証基盤を二重化する | パスワード・権限の同期ずれで監査に詰まる → AD / IdPを単一化して連携する |
| データ転送量（egress）を見積もらない | クラウド→オンプレの月次データ移送だけで数百万円の請求事例が定番 → 設計段階で試算する |
| 「クラウドが安い」の一点でオンプレ全移行 | 規模次第でオンプレが安いこともある → 3年TCOで比較する |
| データ保管地域を確認しない | GDPR等で海外リージョン保管が法令違反になる → 規制要件を最初に確認する |
筆者メモ ― 週末の請求書事件
検証環境を金曜夜に立ち上げ、週末に落とし忘れたまま月曜を迎え、月末に想定の10倍の請求書が来た──クラウド移行初期の会社で珍しくない事件です。特にGPUインスタンス・大型RDS・NATゲートウェイを「ちょっと試すだけ」で起動し、停止を忘れるパターンが定番です。クラウドの「使った分だけ」という看板を信じて油断すると、NATゲートウェイ・ELB・未使用のEIPのような「使っていない時間も課金される」種類のリソースでやられます。
対策は単純で、コスト上限アラート（AWS Budgets、GCP Billing Alerts）を必ず設定し、閾値超過で即通知を受ける仕組みにしておくことです。これを入れていないクラウド運用は、事故が起きるのは時間の問題と見ていいです。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 基本のデプロイモデル（クラウド / オンプレ / ハイブリッド）
- クラウドベンダーの選定（AWS / GCP / Azure / 国産）
- 分離レベル（共有 / 論理分離 / 物理分離）
- データ保管場所（国・リージョン・規制対応）
- 既存システムとの連携方式
- コスト上限とモニタリング
- 災害対策・BCP要件
決定理由の残し方
デプロイモデルの選定は影響範囲が大きく、後から変更するコストも高いため、決定時点の判断根拠をADRとして残すことを強く推奨します。以下に具体例を示します。
| 項目 | 内容 |
|---|---|
| タイトル | 本番環境をコンテナ（ECS Fargate）で運用する |
| ステータス | 承認済み |
| コンテキスト | 現行の EC2 手動構築ではデプロイに30分以上かかり、環境差異による障害が年3回発生している。運用負荷を下げつつデプロイ速度を改善したい |
| 決定 | AWS ECS Fargate を採用し、全サービスをコンテナ化する |
| 理由 | ・EC2のOS管理・パッチ適用が不要になり運用工数を月20時間削減できる ・コンテナイメージで環境を固定し「開発では動くが本番で動かない」を排除できる ・Fargate はサーバーレスのためオートスケールの設定が最小限で済む |
| 却下した代替案 | EKS（Kubernetes）→ チーム4名で運用するにはオーバーヘッドが大きい。Lambda → 既存アプリがステートフルで移行コストが過大 |
| 結果 | コンテナ化により CI/CD パイプラインの整備が前提となる。Dockerfile の標準化とイメージスキャンの導入が追加タスクとして発生する |
ADRはコードリポジトリの docs/adr/ にMarkdownで保管し、PRレビューと同じフローで承認するのがおすすめです。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADRの最大の価値です。
この記事に関連する記事
まとめ
本記事はシステムを「どこに置いて、誰が運用するか」を決めるデプロイモデルの選び方を解説しました。如何だったでしょうか。
新規プロジェクトはパブリッククラウドが圧倒的なデフォルトで、ハイブリッド・マルチクラウドは明確な理由と人員体制がある場合に限定するのが2026年の健全解です。AI時代では、IaCで完結する単一クラウド構成の優位がさらに強まっています。
次回はパブリッククラウドを選んだ後の最大の決定、「クラウドベンダー選定」（AWS / Azure / GCP）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS クラウドコンピューティングとは も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（13/95）