マルチクラウドとは｜設計の考え方と案件で求められるスキル

マルチクラウドとは｜定義とハイブリッドクラウドとの違い

マルチクラウドとは、2社以上のクラウド事業者のサービスを併用してアプリケーションを運用する構成を指します。Google Cloudの公式解説でも、What is multicloud?で「少なくとも2つのクラウドプロバイダーのサービスを使う状態」と定義されています。

混同されやすいのがハイブリッドクラウドです。こちらはパブリッククラウドとオンプレミス（または自社運用のプライベートクラウド）を組み合わせた構成を指します。軸が違うのです。マルチクラウドは「事業者が複数か」、ハイブリッドクラウドは「パブリックとプライベートをまたぐか」を見ています。

そして両者は排他ではありません。AWSとAzureを使いつつ、オンプレミスのデータセンターも残っている。この構成はマルチクラウドでありハイブリッドクラウドでもあります。

3つの構成を整理する

実態としてのマルチクラウドは「混在」に近い

厳密な定義より、現場感覚のほうが重要です。日本の案件で「マルチクラウド」と呼ばれる環境は、きれいに設計された二重構成であるとは限りません。本番はAWS、分析基盤だけGoogle Cloud、グループ会社の業務システムはAzure。この程度の混在を指してマルチクラウドと呼ぶケースも多く見られます。

Flexeraの2026 State of the Cloud Report（クラウド意思決定者753名が回答）では、回答企業の73%がハイブリッドクラウドを利用しており、そのうち33%が「複数のパブリッククラウド＋複数のプライベートクラウド」の組み合わせでした。この調査の範囲で言える限りですが、複数クラウドや複数環境の混在は珍しい構成とは言いにくい状況です。

ミニFAQ：2つのクラウドを使っていれば、それはマルチクラウドですか。

定義上はそうなります。ただし案件要件として意味を持つのは、クラウドをまたいで接続・認証・監視のいずれかを統合している場合です。単にSaaSが別クラウドで動いているだけなら、設計上のマルチクラウド課題はほとんど発生しません。

3大ベンダーはマルチクラウドをどう位置づけているか

ここが実務で効いてくる割に、日本語の解説記事ではあまり触れられていません。AWS・Google・Microsoftは、マルチクラウドについて同じことを言っていないのです。公式ドキュメントを読み比べると、立場の差がはっきり出ます。

※各社の公式ドキュメントを筆者が要約したものです。原文のニュアンスは各リンク先で確認してください。

AWS：利点が投資増を上回るときだけ

AWSの規範ガイダンスは、マルチクラウドを「利点が投資の増加を上回る場合にのみ検討することを推奨する」と位置づけています。採用を正当化できるケースとして挙げられているのは、特定ベンダーの差別化サービスが必要な場合と、単一事業者では満たせないデータ主権要件がある場合の2つです。

警告として挙げられているのも具体的です。各クラウドに対応できる人材の不足、コードのリファクタリングや専用線構築といった隠れたオーバーヘッド、そしてボリュームディスカウントが効かなくなることによるTCOの増加。クラウド事業者自身が「安易に増やすな」と書いている点は、読んでおく価値があります。

Google Cloud：マルチクラウドを重視した製品展開

Google Cloudは逆方向です。GKE EnterpriseでAWSやAzure上のKubernetesクラスタも含めて一元管理する、Cross-Cloud Networkでクラウド間を自社バックボーンで接続する、といった製品を揃えています。後発としてシェアを取る立場であれば、「全部うちに寄せてください」より「他社と併用しやすくします」のほうが入り口として自然です。

Microsoft：Azureを統合管理の中心に据える

MicrosoftのCloud Adoption Frameworkは、ハイブリッドとマルチクラウドを統合運用の文脈で扱います。中核はAzure Arcです。オンプレミスや他クラウドのサーバ・Kubernetesクラスタ・データベースをAzureのリソースとして投影し、Azure PolicyやAzure Monitorの統制下に置く。比喩的に言えば、Azureを管制塔に見立てるアプローチです。

立場の違いは案件要件に表れる

この差は抽象論ではありません。発注元がどのベンダーのフレームワークに乗っているかで、案件で求められる成果物が変わります。Microsoft系のSIerが入っている現場ならAzure Arcでの統制設計が議題になりますし、Google Cloud主導ならGKE Enterpriseでのクラスタ統合が出てきます。参画前に「どのベンダーの流儀で統合しようとしているか」を聞くと、必要なスキルの当たりがつきます。

なぜマルチクラウドになるのか｜意図的な採用と、そうでない場合

結論から言うと、マルチクラウドには「選んだ結果」と「そうなってしまった結果」の2種類があります。案件の進め方が変わるため、最初に見分けてください。

意図的に選ぶ主な理由

• 差別化サービスの利用：基盤はAWSに置きつつ、BigQueryやVertex AIを使うためにGoogle Cloudを併用する、といった構成

• データ主権・規制対応：データの保管国や事業者を分ける必要がある場合

• 可用性とリスク分散：特定事業者の広域障害時にも事業を継続する設計

• 調達上の交渉力：単一事業者への依存度を下げ、契約条件の交渉余地を残す

意図せずマルチクラウドになるケース

Flexeraのレポートは、マルチクラウドの広がりについて「多くの場合は意図的ではない」と指摘し、要因としてM&A、アプリケーションチームのサイロ化、継承されたアーキテクチャを挙げています。現場で出会うのはこちらが多数派です。

• 買収した会社がAzureを使っていた

• 事業部ごとに別々のクラウドを選んで、気づけば3社に分散していた

• 前任のベンダーが構築した基盤が別クラウドに残っている

この場合、案件の本質は「マルチクラウド設計」ではありません。統合か、片寄せか、現状維持かを決める整理の仕事になります。技術選定より、現状把握とコスト試算のほうが比重を占めます。

ミニFAQ：意図しないマルチクラウドは、片寄せしたほうがよいのでしょうか。

一概には言えません。移行コストと、分散したまま運用し続けるコストの比較になります。判断材料としては、年間のクラウド費用、二重になっている運用作業の工数、人材確保の見通しの3点を数字にすると議論が進みます。片寄せを選ぶ場合の進め方はクラウド移行案件のフリーランス単価相場・必要スキル・獲得法で整理しています。

マルチクラウド設計の考え方｜5つの論点

設計の議題は、だいたい次の5つに収束します。どの案件でもこの順に確認すると漏れが出にくくなります。

1. クラウド間のネットワーク接続

まず決めるのは接続方式です。選択肢はインターネット経由のVPN、各社の専用線サービス（AWS Direct Connect、Azure ExpressRoute、Cloud Interconnect）、相互接続事業者のサービスの3系統に分かれます。

考慮点は帯域と遅延、そして冗長化です。クラウド間の物理的な距離とネットワーク状況によって遅延が発生し、同期的な通信を前提にした設計だと性能劣化につながります。IPアドレス帯の重複も実務では頻発します。別々に構築された環境を後からつなぐ場合、CIDRが被っていてそのままではルーティングできない、という事態は珍しくありません。

2. ID・権限管理の統合

クラウドごとに別のIAMユーザーを作る運用は、早い段階で破綻します。退職者のアカウントが片方のクラウドに残る、権限の棚卸しが二重になる、といった問題が起きるためです。

実務では、Microsoft Entra IDやOktaなどのIdPを認証の起点に置き、各クラウドへはSAMLやOIDCでフェデレーションする構成が選ばれます。設計時に詰めるのは、ロールの設計粒度と、監査ログをどこに集約するかです。境界防御から認証ベースの制御へ移行する考え方はゼロトラストとは｜境界型との違い・主要技術・案件動向を解説で扱っています。

3. 監視・ログの一元化

クラウドごとの標準監視（CloudWatch、Azure Monitor、Cloud Monitoring）をそれぞれ見る運用は、障害対応の初動を遅らせます。横断で見るダッシュボードを用意するのが基本方針です。

手段は大きく2つ。DatadogやNew Relicのような統合監視SaaSに寄せるか、PrometheusとGrafanaを自前で運用するか。SaaSは導入が速い代わりに、監視対象のホスト数やログ量に比例して費用が膨らみます。選定の観点はDatadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説にまとめてあります。

4. データ配置とegressコスト

見落とされやすいのがここです。クラウドから外へ出る通信（egress）には料金がかかります。クラウドをまたいでデータを頻繁にやり取りする設計にすると、転送料金が運用コストの無視できない割合を占めることがあります。たとえば、アプリはAWS、分析基盤はGoogle Cloud、ログ保管はさらに別クラウドという構成で常時データを連携させると、転送料金が積み上がりやすくなります。

AWSの規範ガイダンスも、アプリケーションをできるだけデータの近くに配置し、ネットワーク遅延を最小化することを勧めています。「処理はA社、データはB社」という分割は、設計として素直ではありません。

なお、2024年3月にAWSが他社クラウドへ全面移行する顧客向けにデータ転送料を無償化すると発表し、Google Cloud・Azureも同様の措置を取っています。ただしこれは申請ベースで、原則として全ワークロードの移行とアカウント解約が条件です。日常運用で発生するegress料金が無料になるわけではない点は、コスト試算で必ず区別してください。EUではData Actによる切り替え手数料の規制も進んでいますが、適用されるのはEU域内の取引であり、日本国内の案件にそのまま当てはまるものではありません。

5. IaCとデプロイの共通化

同じ構成を2つのコンソールで手作業管理するのは、現実的ではありません。TerraformやOpenTofuのように複数クラウドのプロバイダーを扱えるツールでコード化するのが定石です。AWSの規範ガイダンスでも、可能な限り共通のオーケストレーション・デプロイツールを使うことが挙げられています。

ただし「同じツールで書ける」と「同じコードが動く」は別です。リソース定義はクラウドごとに別物なので、共通化できるのはモジュールの構造やCI/CDのパイプライン、命名規則やタグ設計までと考えるのが現実的です。基礎はTerraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説、ライセンス面の選択肢はOpenTofuとは｜Terraformとの違い・ライセンスと選定基準で確認できます。

ミニFAQ：Kubernetesを使えばマルチクラウドの移植性は確保できますか。

アプリケーション層の移植性はかなり高まります。ただしロードバランサー、ストレージクラス、IAM連携、マネージドDBはクラウド固有です。Kubernetesは移植性の土台にはなりますが、それだけで完結はしません。仕組みはKubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説を参照してください。

マルチクラウドのアンチパターン3つ

設計の失敗には型があります。レビューで指摘される頻度が高いものを3つ挙げます。

全ワークロードを両対応にする

「いつでも移せるように」という理由で、すべてのシステムを2クラウド対応で作る。これは投資対効果が合いにくい設計です。AWSの規範ガイダンスがワークロード単位の判断を勧めているのも同じ理由で、必要なものだけを対象にするほうが合理的です。実際に切り替える可能性が低いシステムまで両対応にすると、開発速度と運用工数の両方を失います。

マネージドサービスを捨てて「最小公倍数」で作る

どのクラウドでも動くようにと考えると、各社固有のマネージドサービスを避け、仮想マシンとオープンソースだけで構築する方向に傾きます。移植性は上がります。その代わり、クラウドを使う最大の利点である運用委託を手放すことになります。DBもキューも監視も自前で面倒を見る構成は、少人数チームでは重荷です。

ロックイン回避そのものを目的にする

ベンダーロックインの回避はマルチクラウドの代表的な動機ですが、目的化すると判断を誤ります。問うべきは「ロックインされているか」ではなく、「切り替えが必要になったとき、いくらと何か月かかるか」です。この見積もりができていれば、ロックインは管理可能なリスクになります。できていない状態で分散だけ進めると、複雑性というコストを先払いして、移行性は大して上がっていない、ということが起こります。

案件で求められるスキル

結論として、マルチクラウド案件で評価されるのは「複数クラウドを知っていること」ではありません。クラウドをまたいだときに発生する課題を、1つでも解いた実績です。

土台になるスキル

• 1つのクラウドでの設計・運用経験：まず軸足が要ります。2つを浅く触った経歴より、1つを深く、もう1つを実務で触れた経歴のほうが通ります

• ネットワークの基礎：VPN、専用線、ルーティング、CIDR設計。マルチクラウドの課題は接続まわりに集中します

• IaC：Terraform等でのコード管理は、ほぼ前提条件になります

• ID連携：SAML／OIDCでのフェデレーション設計とロール設計

• コスト管理：料金体系の読み解きと、egressを含めた試算

AWSの規範ガイダンスが検討項目として挙げているのも、スキルセット、追加のオーバーヘッド、監視・管理の一元化、IaCと自動化、コンプライアンス、TCOの6点です。求められるスキルの輪郭はこれとほぼ重なります。

職務経歴書での書き方

「AWS・Azure・GCPの経験あり」という並列の書き方は、強みが伝わりません。どのクラウドが主で、どれを従として扱ったか。そして統合で何を解いたかを書いてください。

たとえば「AWSを主基盤とし、買収会社のAzure環境を統合。Entra IDを起点にしたフェデレーション設計とTerraformでの構成管理の共通化を担当」と書けば、役割と成果が一読で伝わります。曖昧な並列は、面談で必ず深掘りされます。

単価面では、マルチクラウドの経験そのものが上乗せ要因になるというより、クラウド設計・移行・コスト最適化といった上流の役割に就けるかどうかが効きます。クラウド系の単価レンジはAWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説やSREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安で整理しています。自分の経歴でどのレンジを狙えるか把握したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

ケース別｜フリーランスがマルチクラウド案件に関わる3つの入り方

マルチクラウド「専門」の募集はほとんど見かけません。別の看板の案件に、マルチクラウド要素が含まれている形が一般的です。入り方は3つに整理できます。

ケース1：移行・統合案件

M&A後の基盤統合や、事業部ごとに分散した環境の整理。求められるのは現状調査、移行計画の策定、段階的な切り替えです。技術力と同じくらい、関係者の調整と現状把握の能力が問われます。詳細はクラウド移行案件のフリーランス単価相場・必要スキル・獲得法を参照してください。

ケース2：コスト最適化・FinOps

複数クラウドに費用が分散すると、全体像が見えなくなります。ここを可視化して削減提案まで持っていく役割です。マルチクラウドだからこそ必要とされる仕事で、egressやアイドルリソースの棚卸しが中心になります。FinOps・クラウドコスト最適化案件｜単価相場と必要スキル・参入方法で具体的な進め方を扱っています。

ケース3：プラットフォーム／SRE

複数環境を開発チームに統一的な形で提供する役割です。KubernetesとIaCが中心的なスキルになります。監視統合やセキュリティ基準の横断適用も守備範囲に入ります。職種の輪郭はプラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違いが参考になります。

なお、どのクラウドから経験を積むかという参入順序そのものは本記事の範囲外です。最初の1つを選ぶ段階の方はクラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸を先に読んでください。

マルチクラウド案件 参画前チェックリスト

商談や面談で確認しておくと、参画後のミスマッチを減らせます。

IaCがなく手作業で運用されている現場では、設計より先に現状のコード化が必要になります。この見立てを面談時に持てると、工数の提示がぶれません。

まとめ

マルチクラウドとは2社以上のクラウドを併用する構成であり、目的化するものではなく、要件から逆算して必要な範囲だけ採用するものです。案件で評価されるのは知識の広さではなく、クラウドをまたいだ課題を解いた実績です。

• マルチクラウドは「複数事業者の併用」、ハイブリッドクラウドは「パブリックとプライベートの併用」。軸が違う

• AWSは抑制的、Google Cloudは推進的、Microsoftは統合運用型と、ベンダーの公式スタンスは一致していない

• 現場で遭遇する多くはM&Aや組織都合による「意図しないマルチクラウド」。まず経緯を確認する

• 設計論点は接続・ID・監視・データ配置とegress・IaCの5つ

• 全ワークロードの両対応、最小公倍数設計、ロックイン回避の目的化は典型的な失敗パターン

• 職務経歴書では主従を明確にし、統合で何を解いたかを書く

次のステップとしては、現在の主軸クラウドを1つ決めたうえで、2つ目についてIAMとネットワークの対応関係から押さえるのが効率的です。参入順序から整理したい場合はクラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸、単価の全体像は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？を参照してください。

参照した一次情報は以下のとおりです。

• AWS 規範ガイダンス｜マルチクラウド

• Google Cloud｜What is multicloud?

• Microsoft Cloud Adoption Framework｜Unified hybrid and multicloud operations

• Flexera｜2026 State of the Cloud Report