もはやクラウドは、現代の企業活動において不可逆的なインフラとなった。AWS（アマゾン ウェブ サービス）、Microsoft Azure、Google Cloud（GCP）の3大プラットフォームが市場の大部分を占める中、世界中の企業がその上でビジネスを構築している。日本においても「脱オンプレミス」は長年のスローガンであり、多くの企業がクラウド移行を推進してきた。オンプレミス時代には数年がかりであった新システムの導入が、クラウド時代には数週間で立ち上がる。この圧倒的な「俊敏性」こそが、クラウドがもたらした最大の価値であった。
しかし、単一のクラウドに全面的に依存すれば、そのサービスで発生した障害、突然の価格改定、あるいはサービス仕様の変更といった影響を、回避する術なく受け入れなければならない。2021年9月に発生したAWS東京リージョン関連のDirect Connect障害では、約6時間にわたり国内の広範なサービスに影響が及んだ。また、同年、Peach Aviationが経験した予約システム障害も、単一のシステム依存のリスクを象徴する出来事であった。開発元が「マルウェア感染」を原因と公表し、復旧までに数日を要したこのトラブルでは、航空券の購入や変更手続きが全面的に停止し、多くの利用者に混乱をもたらした。
こうしたリスクを回避し、また各クラウドの「良いとこ取り」をするために、企業がマルチクラウド戦略を採用するのは合理的な判断である。事実、Flexeraの2024年のレポートによれば、世界の企業の89％がすでにマルチクラウド戦略を採用しているという。しかし、この急速な普及の裏側で、企業側の「統治（ガバナンス）」は全く追いついていないのが実情だ。
アイデンティティとアクセス管理（IAM）、システムの監視、各国のデータ規制への対応、そしてコスト管理。複数のクラウドを組み合わせることは、単なる足し算ではなく、組み合わせの数に応じて複雑性が爆発的に増加することを意味する。マルチクラウドという合理的な選択は、同時に「統治困難性」というパンドラの箱を開けてしまったのである。この深刻な問題はまず、目に見えないインフラ層、すなわちネットワーク構成の迷路から顕在化し始めている。
接続と権限の迷宮：技術的負債化するインフラ
マルチクラウド戦略が直面する第一の壁は、ネットワークである。クラウドが一種類であれば、設計は比較的シンプルだ。VPC（AWSの仮想プライベートクラウド）やVNet（Azureの仮想ネットワーク）といった、そのクラウド内部のネットワーク設計に集中すればよかった。しかし、利用するクラウドが二つ、三つと増えた瞬間、考慮すべき接続経路は指数関数的に増加する。
例えば、従来のオンプレミス環境とAWS、Azureを組み合わせて利用するケースを考えてみよう。最低でも「オンプレミスからAWSへ」「オンプレミスからAzureへ」、そして「AWSとAzure間」という3つの主要な接続経路が発生する。さらに、可用性や地域性を考慮してリージョンを跨いだ設計になれば、経路はその倍、さらに倍へと膨れ上がっていく。
問題は経路の数だけではない。マルチクラウド環境では、クラウド間の通信が、各クラウドが定義する仮想ネットワークの境界を必ず跨ぐことになる。これは、同一クラウド内部での通信（いわゆる東西トラフィック）と比較して、遅延や帯域設計上の制約が格段に表面化しやすいことを意味する。オンプレミスとの専用線接続（AWS Direct ConnectやAzure ExpressRouteなど）や、事業者間のピアリングを経由する構成では、各プロバイダーが提供するスループットの上限、SLA（品質保証）の基準、さらには監視・計測の粒度までがバラバラである。
平時には問題なくとも、ピーク時の分析処理や夜間の大規模なバッチ転送などで、突如としてボトルネックが顕在化する。そして、障害が発生した際、この複雑なネットワーク構成が原因特定の遅れに直結する。国内の金融機関でも、北國銀行がAzure上に主要システムを移行する「フルクラウド化」を推進し、さらに次期勘定系システムではAzureとGCPを併用するマルチクラウド方針を掲げるなど、先進的な取り組みが進んでいる。しかし、こうした分野では特に、規制対応や可用性設計における監査可能性の担保が、ネットワークの複雑性を背景に極めて重い課題となっている。
そして、このネットワークという迷路以上に深刻な「最大の落とし穴」と指摘されるのが、IAM（アイデンティティとアクセス管理）である。AWS IAM、Microsoft Entra ID（旧Azure Lively Listing）、GCP IAMは、それぞれが異なる思想と仕様に基づいて設計されており、これらを完全に統一されたポリシーで運用することは事実上不可能に近い。
最も頻発し、かつ危険な問題が「幽霊アカウント」の残存である。人事異動、プロジェクトの終了、あるいは外部委託先の契約満了に伴って、本来であれば即座に削除されるべきアカウントが、複雑化した管理の隙間で見落とされてしまう。監査の段階になって初めて、数ヶ月前に退職した社員のアカウントが、依然として重要なデータへのアクセス権を持ったまま放置されていた、といった事態が発覚するケースは珍しくない。
これは単なる管理上の不手際では済まされない。権限が残存したアカウントは、内部不正の温床となるだけでなく、外部からの攻撃者にとって格好の侵入口となり、大規模な情報漏洩を引き起こす致命的なリスクとなる。Flexeraの調査でも、マルチクラウドの普及は進む一方で、セキュリティの統合や運用成熟度は低い水準にとどまっていることが示されている。特に厳格な統制が求められる金融機関において、監査でIAMの統制不備が繰り返し問題視されている現実は、この課題の根深さを物語っている。
データ主権とAI規制：グローバル化が強制するシステムの分断
マルチクラウド化の波は、企業の積極的な戦略選択によってのみ進んでいるわけではない。むしろ、グローバルに事業を展開する企業にとっては、各国のデータ規制が「多国籍マルチクラウド体制」の採用を事実上強制するという側面が強まっている。
EU（欧州連合）の一般データ保護規則（GDPR）は、データの域内保存を絶対的に義務づけてはいないものの、EU域外へのデータ移転には標準契約条項（SCC）の締結など、極めて厳格な要件を課している。一方で、米国のCLOUD Act（海外データ適法利用明確化法）は、米国企業に対して、データが国外に保存されていても米国法に基づきその開示を命じ得る枠組みを定めている。さらに中国では、個人情報保護法（PIPL）やデータセキュリティ法がデータの国外持ち出しを厳しく制限し、複雑な手続きを要求する。日本もまた、2022年の改正個人情報保護法で、越境移転時の透明性確保を義務化するなど、データガバナンスへの要求を強めている。
この結果、グローバル企業は「EU域内のデータはEUリージョンのクラウドへ」「米国のデータは米国クラウドへ」「中国のデータは中国国内のクラウドへ」といった形で、各国の規制（データ主権）に対応するために、意図せずして複雑なマルチクラウド体制を構築せざるを得なくなっている。
もちろん、企業側も手をこまねいているわけではない。Snowflakeのように、AWS、Azure、GCPの3大クラウドすべてに対応したSaaS型データ基盤を活用し、物理的に分断されてしまったデータを論理的に統合・分析しようとする試みは活発だ。しかし、国ごとに異なる規制要件をすべて満たし、コンプライアンスを維持しながら、データを横断的に扱うことは容易ではない。規制とマルチクラウドの複雑性が絡み合った、新たな統治課題がここに浮き彫りになっている。
そして今、この複雑なデータ分断の構造に、生成AIや機械学習という新たなレイヤーが重ねられようとしている。AIの導入において、大規模なモデル学習と、それを活用した推論（サービス提供）を、それぞれ異なるクラウドで実行する試みは、一見すると効率的に映る。学習には潤沢なGPUリソースを持つクラウドを選び、推論は顧客に近いリージョンや低コストなクラウドで実行する、という考え方だ。
だが現実には、この構成が「監査対応」の難易度を劇的に引き上げる。学習データがどのクラウドからどのクラウドへ移動し、どのモデルがどのデータで学習され、その推論結果がどの規制に準拠しているのか。この監査証跡を、複数のクラウドを跨いで一貫性を保ったまま管理することは極めて困難である。製薬大手のノバルティスがAWSやMicrosoftとの協業で段階的なAI導入を進めている事例や、国内の製造業で同様の構成が試みられている動向からも、この「マルチクラウド特有の監査証跡管理」が共通の課題となりつつあることがわかる。加えて、2024年8月に発効したEUのAI法など、データだけでなくAIそのものへの規制が本格化する中で、この統治の困難性は増す一方である。
ブラックボックス化する現場：監視の穴と見えざるコスト
統治困難性がもたらす具体的な帰結は、まず「障害対応の遅延」という形で現場を直撃する。障害が発生した際に最も重要なのは、迅速な原因の特定と切り分けである。しかし、マルチクラウド環境では、この初動が格段に難しくなる。
なぜなら、Amazon CloudWatch、Azure Monitor、Google Cloud Operations Suiteといった各クラウドが標準で提供する監視基盤は、当然ながらそれぞれのクラウドに最適化されており、相互に分断されているからだ。収集されるログの形式、データの粒度、監視のインターフェースはすべて異なる。障害発生の通報を受け、IT担当者が複数の管理コンソールを同時に開き、形式の違うログデータを突き合わせ、相関関係を探る。単一クラウドであれば数分で特定できたはずの原因が、この「監視の分断」によって何時間も見えなくなる。
DatadogやNew Relicといった、マルチクラウドを一元的に監視できるサードパーティーツールが市場を拡大している背景には、まさにこの構造的な課題がある。しかし、ツールを導入したとしても、各クラウドの根本的な仕様の違いや、ネットワークの複雑な経路すべてを完全に可視化できるわけではなく、「監視の穴」が残存するリスクは常につきまとう。
こうした監視や障害対応の困難さは、単なる技術的な課題にとどまらず、やがて経営を圧迫する「見えざるコスト」となって跳ね返ってくる。コスト管理（FinOps）の複雑化である。CPU時間、ストレージ利用料、APIコール回数、そして特に高額になりがちなクラウド間のデータ転送料。これら課金体系はクラウドごとに全く異なり、複雑に絡み合う。
請求書のフォーマットすら統一されていないため、IT部門は毎月、異なる形式の請求書を読み解き、どの部門がどれだけのコストを発生させているのかを把握するだけで膨大な工数を費やすことになる。結果としてコストの最適化は進まず、予算超過が常態化する。HashiCorpが実施した調査では、実に91％の企業がクラウドの無駄な支出を認識していると回答し、さらに64％が「人材不足」を最大の障壁と挙げている。複雑化する運用に対応できるスキルセットを持った人材は圧倒的に不足しており、現場は疲弊している。
Synergy ResearchやOmdiaの調査によれば、クラウドインフラ市場は依然として年間20％を超える高い成長を続けている。この市場全体の拡大は、皮肉なことに、各クラウドの課金体系や監査要件の「差異」を企業組織の内部にさらに深く浸透させ、統治困難性の“母数”そのものを押し広げている。
このマルチクラウドがもたらす統治課題は、すべての産業に共通する一方で、その“顔つき”は業種ごとに異なる形で現れている。
最も厳格な要件が課される金融業界では、決済や市場接続におけるミリ秒単位の低遅延と、24時間365日の高可用性、そして取引記録の完全な監査証跡が同時に求められる。このため、オンプレミスや国内クラウドを主軸にしつつ、AIを用いた不正検知やリスクモデル計算のみを外部クラウドで行うといった二層構造が見られるが、ここでの課題は「速さと証跡」という二律背反の同期である。
製造業では、サプライチェーン全体の最適化がテーマとなる。生産ラインのデータ（OT）はエッジ側で即時処理し、設計や物流のデータ（IT）はクラウドで統合する。この際、ティア1からティアnに至る多数の取引先や外部委託がシステムにアクセスするため、クラウドを跨いだ権限管理の不備がセキュリティ上の重大な弱点となりやすい。
公共セクターでは、日本のガバメントクラウドが示すように、継続性と説明責任が最重要視される。複数のクラウドサービスを前提とした設計が求められるため、システムが特定のクラウドにロックインされない「可搬性」や「監査性」の確保が主要な課題となる。
小売業界では、顧客行動の即時分析と販促の即応性が競争力を決める。レコメンドAIや在庫連携など、業務機能単位で最適なクラウドやSaaSを選ぶため、結果的にマルチクラウド化が進む。ここでは障害発生時に、トランザクションのどの部分がどのクラウド層に起因するのかを追跡できなくなる問題が深刻であり、統合的なサービスレベル目標（SLO）管理が求められる。
また、教育・研究分野では、研究室単位や助成金ごとに利用するクラウドが異なり、事務系システムはMicrosoft 365、研究用AIはGCP、論文データ共有はAWSといった「意図せぬマルチクラウド」が常態化しやすい。ここでは、入れ替わりの激しい研究者や学生のアイデンティティをいかにライフサイクル管理するかが、コンプライアンスの鍵を握っている。
金融は規制適合性、製造はサプライチェーンの透明性、公共はデジタル主権。産業ごとに直面する課題は異なっていても、その根底にあるのは「複雑性の統治能力が、そのまま企業の競争力と相関している」という共通の現実である。
マルチクラウドは、リスクを分散し俊敏性を高める「資産」にもなれば、利便性を求めて無秩序に拡張した結果、やがて制御不能な「負債」へと転じる危険もはらんでいる。未来を決めるのは、どの技術を導入したか、ではない。その技術が必然的にもたらす複雑性を、持続的に統治できる組織体制と能力こそが、マルチクラウド時代における企業の真の競争力を左右しつつある。
