マルチクラウドとは｜ビジネスサイドのための IT 用語集

 マルチクラウドとはマルチクラウドは複数の事業者のパブリッククラウドを併用する形態です。パブリッククラウドは事業者が一般の利用者に開放して提供するクラウドを指し、AWS（Amazon Web Services）やGoogle Cloudが該当します。

たとえば、基幹の業務システムはAWSで稼働させ、データ分析はGoogle Cloudで実行し、社内の文書管理はMicrosoftのクラウドで運用する構成です。

AWSの定義では、2つ以上のクラウド事業者を同時に利用していればマルチクラウドに該当します。
事業者ごとに得意なサービスを選択でき、1社への依存も軽減できます。

配送を複数の運送会社に依頼する状況と類似しており、地域や料金で依頼先を選択できる反面、伝票の書式や問合せ窓口が会社ごとに異なります。
ハイブリッドクラウドは自社で保有するサーバーやデータセンターなどの設備とパブリッククラウドの組み合わせによる形態で、マルチクラウドとは区別します。

自社のデータセンターとAWS、Google Cloudを併用する構成のように、両方に該当する場合もあります。
 組織での併用と1つのシステムの分散マルチクラウドという語は性質の異なる2つの状態を指します。
組織での併用: システムや部署ごとに別の事業者のクラウドを利用する状態
1つのシステムの分散: 1つのシステムを複数の事業者のクラウドに分散して構成する状態
組織での併用は既存の資産、部署ごとの導入、合併・買収などの経緯で生じる場合があります。併用そのものを理由に1社へ統一する必要はない一方、クラウドごとの運用と管理の手間は継続します。
1つのシステムの分散は構成の複雑化に伴い、費用と運用の負担が増加しやすくなります。
デジタル庁の政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針も同じ区別をしています。

1つの情報システムが主に利用する基盤のクラウドを複数の事業者に分散して構成するマルチクラウドは避けるべきとし、システムごとに異なるクラウドを利用する併用は問題ないとしています。
この方針の対象は政府の情報システムですが、民間企業でマルチクラウドを検討する際もこの区別は参考になります。

マルチクラウドを議論するときは、どちらの意味かを最初に確認すると、議論の対象の混同を防止できます。
 複数のクラウドを併用する理由併用の理由には既存システムが別の事業者上にあること、既存の契約、担当者の得意なクラウド、企業の合併や買収も含まれます。

意図して選択する場合と、経緯の結果として併用が生じる場合の両方があります。
特定の事業者にしかない分析機能や生成AIのモデルの利用
部署ごとの導入や合併・買収で引き継いだ別のクラウドの資産
必要な国や地域、認証に対応したサービスが既存の事業者にない場合の補完
 効果用途ごとに最適なサービスを選択できる
互いに依存しない別々のシステムなら、1社の障害や値上げの影響範囲を分離できる
引き継いだシステムを再構築せずに継続利用できる
データと処理を現実的な費用で移行できる状態なら、価格交渉の選択肢になる
 コストとリスク複数のクラウドの併用には管理の複雑化、攻撃を受けうる範囲の拡大、費用管理の困難さ、複数のクラウドに精通した人材の不足という課題があります。

導入後の運用と人材の面では、次の負担が継続します。
人材: 権限管理、監視、セキュリティ設定の作法がクラウドごとに異なり、担当者に複数の知識が必要
運用: 監視と障害対応の手順はクラウドごとに異なり、原因の特定に時間を要する場合がある
セキュリティ: 設定箇所が増加し、設定の不備による情報漏えいの余地が拡大
費用の把握: 請求書が事業者ごとに発行され、全体の費用と内訳を把握しにくい
転送料金: サービスによっては、クラウドの外へ転送するデータ量に応じて従量で課金
機能の制約: 両方で稼働させるために共通の機能だけを利用すると、各クラウド固有の機能を放棄することになる
AWSのインターネットへのデータ転送は、中国と米国政府向けの地域を除く、対象のサービスと地域の合算で月100GBまで無料で、超過分は従量で請求されます。

AWSから他のクラウドへ大量のデータを常時同期する構成では、無料枠を超えた分の料金が継続的に発生します。
 判断のポイント 障害対策として1つのシステムを複数のクラウドへ分散すべきか多くのシステムでは不要です。

1つのクラウドの中で複数のデータセンターや別の地域へ分散する対策は、2社目の構成や人材を維持する必要がないため、先に検討するほうが費用対効果は高くなります。
1つのクラウドの中でも、地域拠点全体に及ぶ大規模な障害は発生します。

2025年10月にはAWSの米国東部の地域拠点で障害が発生し、完全な復旧まで半日以上かかりました。障害の起点はデータベースサービスのDNS（Domain Name System）設定の不具合です。
このような障害に備えて1つのシステムを2社のクラウドで稼働可能な状態に維持するには、切り替え先の構成とデータの同期・復旧の手段を常に整備し、切り替えの訓練を継続的に実施する必要があります。

費用は待機用の設備、データの同期と転送、監視、訓練、両方のクラウドに対応できる人材の合計で見積もります。
ログインや決済を外部の1社に依存している場合、その外部サービスが停止すると、アプリだけを分散しても停止は回避できません。
災害対策の選択肢としては同じ地域内の複数データセンターへの分散、別の地域へのバックアップ、別の地域で最小構成を待機させる方式がデジタル庁の基本方針に示されています。
判断は次の順序で実施します。
何時間までの停止と、どの時点までのデータの喪失なら事業として許容できるかを決定する
1つのクラウドの中での分散やバックアップで、その水準を達成できるかを確認する
達成できない場合に限り、2社目のクラウドで削減できる年間の損失と、2社目を維持する年間の費用を、同じ期間で比較する
2社目で削減できる損失と維持費用の比較まで必要になるのは、決済や社会基盤に近いシステムのように、停止による影響が重大で許容時間の短いものに限られます。
一方、障害時のお知らせページだけを別の事業者に配置しておく程度の分散は、費用が少額で効果が明確です。

ドメインの管理や配信の仕組みを本体と共有していると、その仕組みに障害が発生した場合に同時に停止するため、お知らせページは本体と障害原因を共有しない構成にします。
 ベンダーロックイン回避のためにシステムを最初から複数のクラウド前提で構築すべきか移行先や移行の期限が確定していない段階では、原則として不要です。

ベンダーロックインは一般に、特定の事業者への依存が深化し、他社へ移行しにくくなる状態を指す語として使用されます。

両方で稼働させるための共通化の手間は構築と改修のたびに発生する一方、乗り換えは発生するか不確実なため、手間が過大になりがちです。
デジタル庁の基本方針の整理では、データの移行性と導入の過程を含めた透明性が担保され、合理的な価格体系が公開されていれば、ベンダーロックインには該当しません。

ただし、この整理に該当しても、移行の費用や事業者固有の機能への依存は解消されません。
代わりに、データを標準的な形式で抽出できるかの確認、設定のコード化、移行費用の概算の3点を準備しておきます。
全データをAWSから移管する顧客はインターネットへの転送料金を免除される場合があり、移行費用の概算に影響します。

免除されるのは転送料金で、システムの改修や移行作業の費用は別に発生します。
 部署ごとに別のクラウドを利用している状態は問題か併用そのものは問題ではありません。

問題になるのは契約、管理者の権限、費用がクラウドごとに分散し、誰も全体を把握していない状態です。
まず全クラウドの契約と請求の一覧を作成し、管理者アカウントの棚卸しと退職者の権限削除を同じ手順で運用します。

そのうえで、各クラウドの保守と障害対応を誰が担い、クラウド間のデータ連携を誰が管理するかを決定できるかどうかで、管理可能な社数を評価します。

担当者が少数で各クラウドに保守の担当を配置できない場合は、主に利用するクラウドを1社に決定し、新規のシステムは原則としてそのクラウドで構築する方針が現実的です。
 クラウド基盤の分散を検討しなくてよい場合業務アプリをインターネット経由で利用するサービスを複数契約しているだけなら、基盤の分散を検討する必要はありません。

デジタル庁の基本方針も特定機能に特化した他のクラウドの併用は問題ないとしています。

ただし、契約、利用者の権限、個人情報の取扱状況は、契約するサービスごとに管理が必要です。