クラウド・オン・クラウド

クラウド・オン・クラウドとは、土台となるクラウドの上に、さらに別のクラウドサービスを重ねて使う考え方である。
たとえば、AWSやGoogle Cloud、Microsoft Azureのような基盤の上で、自社の業務サービスやデータ分析、認証、配信、監視などを組み合わせて提供する。

これは、自分で全部を持つのではなく、必要な部分だけを借りて組み合わせる発想だ。
ビジネスで例えるなら、次のようになる。

構成	例え
オンプレミス	自社で土地を買い、建物を建て、厨房設備を揃え、配達車両も所有する
クラウド単体	レンタルキッチンを借りて、自社で調理し、自社で配達する
クラウド・オン・クラウド	レンタルキッチン（AWS）で調理し、配達はUber Eats（Cloudflare）、評価管理はGoogle（Datadog）に任せる

要するに、オンプレミスは全部自前、クラウド単体は土台を借りて中身を自分で回す、クラウド・オン・クラウドはその中身も含めて複数の専門サービスを組み合わせるという違いである。

クラウド・オン・クラウドの仕組み

ある写真保存アプリを例に考えてみよう。

この会社は、写真を保管するためのサーバーを自分では買わない。巨大なクラウド会社の設備を借り、その上で自社アプリを動かす。利用者は「写真アプリ」を使っているつもりでも、その裏側では他社のクラウドが土台になっている。これが「クラウドの上のクラウド」である。

cloud_on_cloud1 | UX TIMES — クラウド・オン・クラウドのイメージ

さらに今は、その土台がより細かく分業化されている。

機能	借りる相手（代表例）
写真を保存する場所	Amazon S3（AWSのストレージ）
ログイン・認証	Auth0 や Firebase Authentication
支払い・決済	Stripe
世界中へ高速配信	Cloudflare（CDN）

この会社は「借り物の部品」を組み合わせ、一つのサービスに仕上げる。すべてを自前で作らず、得意な会社の力を積み重ねる。これが現代のサービスの作り方である。

特徴のまとめ

専門会社が提供する部品を組み合わせて作れる
初期費用・手間が少なく、アイデアを素早く形にできる
土台が止まると、上に乗った自社サービスも止まる
一社依存は弱点になるため、複数社を併用して備えることもできる

どう生まれたか ― 進化の3ステップ

クラウド・オン・クラウドに、明確な「提唱者」はいない。誰かが論文で名付けた言葉ではなく、技術の進化のなかで自然と使われるようになった言葉である。

第1段階：すべてを自前で持っていた時代

かつては、サービスを作る会社が自らサーバーやネットワーク機器を購入していた。サーバールームを用意し、電源をつなぎ、壊れたら自分で直す。このことをオンプレミス（On-Premises）という。

新サービスを始めるには、まず大きな先行投資が必要だった。

初期費用の例：

サーバー機器：200〜1,000万円
ネットワーク機器：50〜300万円
ストレージ：100〜500万円
工事・設備費：100〜300万円
合計：500〜3,000万円規模

さらに月々の運用費として、電気代・回線費用・保守契約・人件費などで月額60〜130万円が必要だった。

第2段階：機械を「借りられる」時代へ

2006年ごろ、Amazon が「サーバーを時間貸しする」サービスを開始した。これが後の AWS である。機器を買わずとも、必要なときに必要なだけ借りられる。この「借りる」発想こそ、クラウドの始まりだった。

コストの変化：

初期投資：ほぼ0円（アカウント開設のみ）
月額費用：10〜30万円から開始可能
使った分だけ支払う従量課金制

この変化により、スタートアップでも大企業と同じインフラを使いやすくなった。

第3段階：仕組みごと「借りられる」時代へ

やがて機械だけでなく、「ログインの仕組み」「決済の仕組み」といった完成済みの部品まで借りられるようになった。会社は土台を一から作る必要がなくなった。

構成例と費用：

基盤クラウド（AWS等）：月8〜20万円
CDN（Cloudflare）：月2〜8万円
認証サービス（Auth0）：月1〜5万円
監視・ログ管理：月3〜10万円
合計：月15〜50万円

そしてクラウド・オン・クラウドへ

「借りた土台の上に自社サービスを乗せる」のが当たり前になり、さらにそのサービスを別の会社が部品として借りる。クラウドの上にクラウドが積み重なっていく。この何層にも重なった状態を、人々は自然と「クラウド・オン・クラウド」と呼ぶようになった。

UXの観点での重要性

クラウド・オン・クラウドは、単なる裏側の設計の話ではない。複雑な技術を利用者から隠し、使い心地をやさしくするという点で、UXデザインと深く関わっている。

複雑さを隠す ― 利用者は裏側を知らなくても、やりたいことに集中できる
一貫した操作感 ― 裏で複数クラウドが動いても、利用者には「一つのサービス」として届く
始めやすさ ― 専門知識がなくても、分かりやすい画面で迷わず使い始められる
拡張性と快適さの両立 ― 高い拡張性を活かしつつ、速く安定した体験を提供できる

具体的な事例 ― 毎日使うあのサービス

クラウド・オン・クラウドは、特別な会社だけの話ではない。私たちが毎日使うサービスの多くが、この仕組みで動いている。

Netflix は自社で巨大なデータセンターを持たず、Amazon のクラウド（AWS）の上で世界中に動画を配信している。同社はデータベースを Amazon Aurora へ移行したことで、コストを約28%削減し、性能を最大75%向上させたと AWS が公式に発表している。土台を借りることは、単なる手軽さだけでなく、実際のコスト削減にもつながっている。

同様に、Slack のようなビジネス向けソフトウェアも、AWS のグローバルインフラを活用し、毎週数十億ものメッセージを届けている。

これらの会社は、土台づくりに時間を使わず、サービスの中身を磨くことに全力を注いでいる。それが優れたUXを生む理由の一つだ。

メリットと注意点

クラウド・オン・クラウドは手軽に使えるメリットがある一方、注意する点もある。

観点	メリット	注意点
スピード	機材の準備が不要で、素早く始められる	―
費用	少額で始め、必要に応じて拡張できる	土台と自社サービス両方の費用が重なり、計算が複雑になる
機能	土台の安全・監視機能をそのまま使える	―
使い心地	複雑さが隠れ、シンプルに使える	―
安定性	災害対策などを実装しやすい	土台で障害が起きると、上のサービスも止まる
責任の所在	―	障害時に、どちらの責任か判断しづらい
乗り換え	―	特定の土台に頼りすぎると、後で他社へ移りにくい
コスト予測	―	従量課金のため、トラフィック急増時に予想外の請求が来ることがある

オンプレミスとの比較で見えるトレードオフ

クラウド・オン・クラウドとオンプレミス（サーバーやネットワーク機器を自前で設置・管理する方式）では、どちらを選ぶべきか。その答えは、ビジネスの段階と優先順位で決まる。

クラウド・オン・クラウドが有利な場合：

スタートアップで初期投資を抑えたい
市場投入スピードが最優先
トラフィックの変動が大きい
ビジネスモデルが変化しやすい

オンプレミスが有利な場合：

5年以上の長期利用が確実
大規模で安定したトラフィック（月間データ転送10TB以上）
データを外部に出せない規制がある（金融・医療など）
初期投資の予算が確保できる

実際の選択例： 多くの企業は、安定性が求められる基幹システムはオンプレミス、新規サービスはクラウドというハイブリッド構成を採用している。これにより、安定性とスピードの両立を図っている。

便利さの裏にある「もろさ」― Cloudflare の大規模障害

クラウド・オン・クラウドには弱点もある。土台を借りているということは、その土台が倒れれば、上に乗った自社サービスも一緒に倒れるということである。

それを世界に見せつけたのが、2025年11月18日に起きた Cloudflare の大規模障害だった。

Cloudflare は、Webコンテンツを迅速に、効率よくユーザーに配信するためのネットワークサービスだ。原因は、攻撃を見分ける仕組み（Bot Management）が使う設定ファイルが、ある不具合で異常に肥大化し、システムが処理しきれずに停止したこと。外部からの攻撃ではなく、内部の不具合がきっかけだった。

Cloudflare は世界中の膨大なサイトの土台を支えている。そのため、一見まったく無関係なサイトが、同時に表示できなくなった。利用者から見れば「自分のサイトが壊れた」ように見えても、本当の原因は、共通して借りていた土台にあったのである。

ビジネスへの具体的な影響

Cloudflare のような重要なインフラで障害が起きると、影響は甚大である。

売上損失の試算例：

中規模ECサイト：1時間の障害で50〜200万円の売上損失
大規模ECサイト：1時間の障害で500〜3,000万円の売上損失
SaaSサービス：売上損失に加え、顧客の信頼低下・解約リスク

重要な点として、自社で契約しているAWSやAzureは正常稼働していても、Cloudflareが止まれば顧客は一切アクセスできないことである。復旧も自社ではコントロールできず、Cloudflare側の対応を待つしかない。

cloud-on-cloud3 | UX TIMES — Cloudflare障害の影響

リスク軽減策とそのコスト

賢い作り手は、リスクを軽減するために以下のような対策を講じている。

対策	内容	追加月額コスト
マルチCDN構成	Cloudflare + Fastly など複数CDNを併用し、障害時に自動切り替え	+5〜10万円
ダイレクトアクセス経路	CDN経由とダイレクトアクセスの両方を用意	設計・運用工数
リアルタイム監視	複数地点からの死活監視、即座にアラート	+5〜15万円
事業継続計画（BCP）	障害時の対応フロー、顧客への告知体制	初期50〜200万円

コストの現実： リスク対策を万全にすると、基本月額の1.5〜2倍のコストになる。しかし、1時間の障害で数百万円の損失が出る可能性を考えれば、必要な投資と言える。

同じことは Amazon や Google の巨大クラウドでも起こりうる。土台でひとつ不具合が起きれば、その上の世界中のサービスがまとめて止まる。

これはクラウド・オン・クラウドの宿命とも言える。だからこそ賢い作り手は、複数社の土台を併用したり、一部が止まっても全体が倒れない工夫をしたりして備えているのである。

クラウド・オン・クラウド Cloud on Cloud