落雷でAzure West US 2が約16時間停止、30超のサービスに影響——Copilot停止でAIのインフラ依存が鮮明に

概要 2026年5月29日、激しい雷雨がアメリカ西部を直撃し、Microsoftのデータセンター複数棟が同時に電力を失った。これによりAzureのWest US 2リージョンで04:24 UTC(日本時間13:24)から障害が始まり、20:18 UTC(翌日05:18 JST)に全サービスが復旧するまで約16時間にわたる大規模な停止が続いた。バックアップ発電機は正常に起動したものの、冷却システムが追いつかず一部エリアで温度が上昇し、復旧作業をさらに困難にした。 影響を受けたサービスはApp Service・Azure Functions・Azure Kubernetes Service・Azure Cosmos DB・Azure SQL Database・Azure Storageをはじめ30サービス以上に達した。なお同日の09:39〜17:05 UTCには、West US 2の停電とは別の要因(リクエスト負荷分散を担うバックエンドのメモリ逼迫)により、複数リージョンにまたがるAzure OpenAI Serviceの障害も発生している。Microsoftは05:00 UTCに雷雨を原因と特定して復旧に着手。10:00 UTC頃から電力の段階的な回復が始まり、18:15 UTCに電力が完全に復旧した後、最終的に20:18 UTCに全サービスが正常化した。Microsoftは72時間以内に予備的なポストインシデントレビュー(PIR)を公開するとしている。 Copilot停止が示したAIサービスのインフラ依存 今回の障害で特に注目されたのは、Microsoft Copilotの全面停止だ。CopilotはAndroidアプリをはじめ複数のMicrosoftプラットフォームで接続エラーやタイムアウトを起こし、コンシューマー・エンタープライズの双方に影響した。Copilotは一見するとMicrosoft 365に組み込まれたソフトウェアのように見えるが、その実体はアイデンティティ管理・オーケストレーション・モデルルーティング・ストレージ・検索・エンタープライズグラフアクセス・テレメトリ・ポリシー適用・リージョナルクラウドキャパシティといった多数のインフラ層に依存している。基盤インフラが揺らぐと、ユーザーにはアプリとして見えていても即座に使用不能になるという構造的な脆弱性が改めて浮き彫りになった。 ITチームへの教訓 この障害を受け、専門家はCopilotをはじめとするAIサービスを組織のインフラの一部として捉え直すよう警告している。具体的には次の4点が挙げられる。 AIをインフラとして扱う — Copilotを"便利なオプション機能"ではなく、生産依存のサービスとして位置づけ、レジリエンス計画・監視・フォールバックワークフローを整備する。 インシデントランブックを事前に用意する — どの業務プロセスがCopilotに依存しているかを明確化し、障害時のコミュニケーションプロトコルと代替手順を定めておく。 リージョン依存性を把握する — 「グローバル」に見えるサービスでも実際はリージョンに紐づいており、Azure Status PageやテナントのService Healthを平時から監視することが重要だ。 グレースフルデグラデーションを設計する — 顧客対応・インシデント処理・コンプライアンス・セキュリティ運用・経営判断など、ビジネスクリティカルな業務では非AI代替フローを温存する。 AIが業務基盤に深く組み込まれるほど、クラウドの可用性は競争力の一部となる。透明性の高いステータス通知、予測可能なフェイルオーバー、わかりやすい管理コントロールを備えたサービス設計が、今後の企業向けAI選定において重要な評価軸になると指摘されている。

June 1, 2026

CloudflareがカスタムエンジンでLLM推論インフラを刷新、プリフィル・デコード分離で低遅延を実現

概要 Cloudflareは、グローバルネットワーク上で大規模言語モデル(LLM)を高効率に実行するための新しいインフラストラクチャを発表した。このシステムの中核となるのは、同社が独自開発したカスタム推論エンジン「Infire」だ。LLMの処理を計算特性の異なる2つのフェーズに分離するアーキテクチャを採用することで、エッジ環境での低遅延なAI推論を実現するとしている。 プリフィル・デコード分離アーキテクチャ Cloudflareが採用した最大の技術的特徴は、モデルの推論処理を「プリフィル」と「デコード」の2フェーズに明確に分割し、それぞれを異なるハードウェアで処理する点にある。プリフィル段階は入力トークンを処理してKVキャッシュを構築する計算集約的な処理であり、デコード段階は出力トークンを逐次生成するメモリ集約的な処理だ。これら2つの処理を分離して最適化されたハードウェアに振り分けることで、全体的なスループットとレイテンシのバランスを向上させる。 Infireエンジンはパイプライン並列化とテンソル並列化を組み合わせて複数GPU間での処理を効率化しており、メモリ使用量の削減と起動・応答速度の高速化を実現している。実績として、Llama 4 Scoutは2基のH200 GPU上で、1兆パラメータを超えるKimi K2.5は8基のH100 GPU上での稼働が確認されている。 Unweightによるモデル圧縮と精度維持 もう一つの注目技術が「Unweight」システムだ。モデルの重みを15〜22%圧縮しながらも推論精度を損なわない仕組みで、ストレージ効率と推論速度の向上に寄与する。エッジ環境では帯域幅やメモリ容量が制約となるケースも多く、精度を犠牲にせずにモデルを軽量化できるこの技術はグローバル展開において重要な役割を担う。 背景と今後の展望 Cockroach Labsのレポートによれば、多くの企業はAIシステムの規模拡大や信頼性要件に対応できる体制が整っていないとされている。Cloudflareの新インフラはこうした業界課題に対して、エッジネットワークの地理的優位性とカスタム最適化エンジンを組み合わせることで応えようとするものだ。同社がグローバルに展開するエッジポイントでLLMを低遅延かつスケーラブルに提供できれば、AIアプリケーション開発者にとって新たなインフラ選択肢となる可能性がある。

May 30, 2026

SnowflakeがAWSと60億ドルの5年間戦略協定を締結、エンタープライズ向けエージェントAI展開を加速

概要 Snowflakeは2026年5月27日、Amazon Web Services(AWS)との多年にわたる戦略的協業契約を発表した。この契約の中核として、SnowflakeはAWS Gravitonコンピュートおよびに向けた5年間・60億ドルの投資コミットメントを表明した。これはSnowflakeの歴史上最大規模のクラウド支出契約であり、エンタープライズ向けエージェント型AI(Agentic AI)の本番導入を加速させることを目的としている。Snowflakeは同時に第1四半期の業績として前年比33%増となる13.9億ドルの売上高を達成しており、堅調な事業基盤を背景に大型投資に踏み切った形だ。 投資規模と市場背景 今回の60億ドルというコミットメントは、エンタープライズAI市場でのSnowflakeの地位確立を目指す大胆な賭けといえる。同社はAWS Marketplaceでの累計売上高がすでに70億ドルを超え、2025年カレンダー年だけで20億ドル以上の売上を達成するなど、AWS経由のビジネス拡大が著しい。グローバルで1万3,900社の顧客を持つSnowflakeは、AIのパイロット段階から本番稼働への移行という業界全体の課題に対し、インフラ整備と製品統合の両面から解決策を提示しようとしている。 技術的な詳細:Cortex AIとデータガバナンス 本協定の技術的な柱となるのが「Snowflake Cortex AI」だ。Cortex AIはSnowflake上のガバナンスされたエンタープライズデータに対して、データをセキュアな領域外に持ち出すことなく直接AI処理を実行できる。テキストからSQLへの変換、文書要約、感情分析、エンティティ抽出といった機能を備えており、AIの活用においてデータのセキュリティとコンプライアンスを担保するという企業ニーズに応えるアーキテクチャとなっている。Snowflake CEOのSridhar Ramaswamy氏は「AIは大きな期待を生んでいるが、企業にとっての真の課題と機会は、知能を行動に変えることだ」と述べ、ガバナンスされたデータにAIを直接適用することの重要性を強調した。AWS CEOのMatt Garman氏も「Snowflakeは初日からAWSの上に構築されてきた」と長年のパートナーシップを評価した。 展開拡大と今後の展望 今回の協定に伴い、Snowflakeはオークランド、ケープタウン、バンコク、AWS European Sovereign Cloudなど10の新規地域への展開も予定している。グローバル展開の加速により、地域ごとのデータ主権要件にも対応する構えだ。FetchやHexといった顧客事例でも、Snowflake on AWSを活用したAIアプリケーションのデプロイが進んでおり、エコシステムの実績積み上げが進んでいる。両社はSnowflake Summit 26においてエンタープライズAIに関する共同ビジョンをさらに具体的に示す予定であり、今後の製品統合の動向が注目される。

May 30, 2026

EUがTech Sovereignty Packageを発表——米国クラウド依存からの脱却を法制化へ

概要 欧州委員会は2026年5月27日、「Tech Sovereignty Package」を発表した。この法案パッケージはCloud and AI Development Act(CADA)とChips Act 2.0を柱とし、EU加盟国政府・公共機関が保健、金融、司法といった分野の機密データを処理する際に、米国系クラウドプロバイダーの利用を制限することを目的としている。背景にあるのは、2018年に米国で成立したCLOUD Actの問題だ。同法はAWSやMicrosoft Azure、Google Cloudといった米国本社を持つ事業者に対し、データの物理的な保管場所を問わず、米国当局の要請に基づいてデータ開示を強制できる権限を与えている。Kiteworksが2026年に欧州・カナダ・中東のIT・セキュリティ専門家286人を対象に実施した調査では、欧州企業の32%が過去1年間に「データ主権インシデント」を経験しており、無断の越境転送が最も多く報告されたとされる。 「地理は管轄ではない」——既存の回避策が機能しない理由 これまで欧州企業や公共機関が採用してきた代表的な対策が、「GCC High in Frankfurt」モデルだ。米国系クラウドサービスをフランクフルトなどの欧州データセンターで稼働させ、欧州人スタッフが運営するという手法だが、Tech Sovereignty Packageの策定に関与した専門家はこれを明確に否定している。「地理は管轄ではない。米国企業が制御するエンクレーブである限り、CLOUD Actの到達範囲から逃れることはできない」という指摘が示すように、物理的なロケーションの分離だけではデータ主権の確保には不十分だ。新たなパッケージが求めるのは、アーキテクチャレベルでのデータ居住強制、監査証跡のエクスポートによるコンプライアンス証明、そして政府アクセス要請に対応する手順のテスト実施という3つの構造的管理策である。 調達基準の枠組み:SEALレベルによる主権認証 欧州委員会はすでに2025年10月にCloud Sovereignty Frameworkを立ち上げており、2026年4月には同框組みに準拠した4つのクラウドプロバイダー連合に契約を付与した。このフレームワークは「Sovereignty Effectiveness Assurance Levels(SEAL)」という8分野にわたる測定基準を設けており、法的コンプライアンス、運用の透明性、サプライチェーン、セキュリティ、EU規制への準拠などを評価する。レベルはSEAL-0からSEAL-4まで段階的に設定されており、SEAL-2はEUの法律に基づいてサービスが提供されること、SEAL-4は半導体からアプリケーションまでEU完結のサプライチェーンを意味する。今回の調達では最低SEAL-2が要件とされた。契約を獲得した4連合はいずれも欧州企業で構成されており、Post Telecom・OVHCloud・CleverCloud連合(ルクセンブルク・フランス、SEAL-3)、Schwarz Group傘下のStackIT(ドイツ、SEAL-3)、Iliad Group傘下のScaleway(フランス、SEAL-3)、Proximus・S3NS・Clarence・Mistral連合(ベルギー・フランス・ルクセンブルク、SEAL-2)が選ばれた。ベンダーロックイン防止のため、意図的に複数サプライヤーへ分散発注されている点も注目される。 法制化の難航と今後の課題 CADAはすでに複数回の延期を経ており、その要因として、EU内部での調整の複雑さ、米国ハイパースケーラーへの配慮を求めるトランスアトランティック交渉、そしてEU各機関間の方針対立の3点が挙げられる。欧州委員会は訴訟リスクを避けるべく、公共調達法・競争法・単一市場規制・国際協定との整合性確保に慎重に取り組んでいるとされる。欧州全体ではAWS・Azure・Google Cloudが約70%の市場シェアを占め、欧州系プロバイダーは15%にとどまる。Tech Sovereignty Packageの施行は、欧州クラウドプロバイダーの競争力回復を後押しするとともに、民間セクターの調達基準にも波及し、主権統制の実証が企業の競争優位になる時代の到来を告げている。一般市民の日常サービスへの即時影響は限定的だが、中長期的にはデータ安全性の向上とEU・米国・中国のデジタル交渉構図の変化が予測される。

May 28, 2026

OpenTofu 1.12リリース、10年越しの動的prevent_destroyをTerraformに先駆けて実装

概要 OpenTofu 1.12.0が2026年5月14日にリリースされた。今回の目玉は、prevent_destroyライフサイクル引数を動的に設定できるようになったことで、これはTerraformのGitHubに2016年に起票されながらHashiCorpが一度も実装しなかった機能だ。コミュニティ主導のフォークとして誕生したOpenTofuが、商業的に管理されてきたTerraformを開発速度で上回っていることを象徴するリリースとなった。 動的prevent_destroyサポートの詳細 従来、prevent_destroyはハードコードが必須であり、本番環境と開発環境を同一のモジュールで管理しようとすると、すべての環境で同じライフサイクルルールが適用されるという制約があった。これを回避するにはモジュールを複製するしかなく、管理コストが増大していた。OpenTofu 1.12では、prevent_destroyに入力変数などの動的な値を参照できるようになり、環境ごとに異なるライフサイクルルールを単一のモジュールで適用できる。例えば本番環境ではprevent_destroy = true、開発環境ではprevent_destroy = falseといった設定を変数で切り替えることが可能になった。 その他の新機能と改善 プロバイダーチェックサムの改善により、tofu initの実行時にロックファイルへzh:とh1:両方のハッシュが自動で記録されるようになった。従来はtofu initでzh:ハッシュのみが書き込まれ、キャッシュやミラーに必要なh1:ハッシュを取得するために別途tofu providers lockコマンドを実行する必要があったが、この手間が不要になった。 -json-into=FILENAMEフラグが新たに追加され、機械可読なJSON出力を指定ファイルへ書き込みながら、端末には人間が読みやすい通常の出力を維持できるようになった。CI/CDパイプラインなどでのツール統合を容易にしつつ、オペレーターの可読性を損なわない改善だ。 また、destroy = falseメタ引数により、インフラを実際に削除することなくリソースをOpenTofuの管理状態から除外できるようになった。複数プロバイダーの依存関係がある場合のtofu initの並行インストール対応も行われ、初期化時間の短縮が図られている。 廃止予定 WinRMプロビジョナーは保守が行われていないGoライブラリへの依存を理由に非推奨となり、バージョン1.13での削除が予定されている。また、386およびARMの32ビットアーキテクチャのビルドも段階的に廃止される予定だ。

May 25, 2026

Cisco Secure Workload REST APIの最大深刻度脆弱性(CVE-2026-20223、CVSS 10.0)を修正

概要 Ciscoは2026年5月、Secure WorkloadのREST APIに存在する最大深刻度の脆弱性CVE-2026-20223(CVSSスコア10.0)に対するパッチを公開した。この脆弱性は「RESTAPIエンドポイントへのアクセス時における検証と認証の不備」に起因するもので、認証されていない遠隔攻撃者が細工したAPIリクエストを送信するだけで、サイト管理者(Site Admin)の権限でテナント境界を越えた機密情報の読み取りや設定変更が可能となる。影響はSaaS環境およびオンプレミスのCisco Secure Workload Clusterソフトウェアの両方に及び、構成に関わらず対象となる。 影響範囲とパッチ情報 脆弱性の影響を受けるバージョンと対応状況は以下のとおりである。 バージョン3.9以前:パッチは提供されず、修正済みバージョンへの移行が必要 バージョン3.10:3.10.8.3で修正済み バージョン4.0:4.0.3.17で修正済み 本脆弱性を緩和する回避策は存在しないため、該当バージョンを利用している組織は直ちにアップデートを適用することが強く推奨される。CiscoはこのCVEを自社の内部セキュリティテストを通じて発見しており、現時点で野外での悪用事例は確認されていない。 背景と注意点 今回の修正は、Cisco製品における認証バイパス系の脆弱性が相次いで報告されている文脈の中で発表された。直近では、Catalyst SD-WAN Controllerにおいても同様に最大深刻度(CVSS 10.0)の認証バイパス脆弱性CVE-2026-20182が明らかになっており、こちらは脅威アクター「UAT-8616」による実際の悪用が既に確認されている。Cisco Secure Workloadは主にクラウドワークロードのマイクロセグメンテーションや可視化に利用されるプラットフォームであり、攻撃者に管理者権限を奪取されると、ネットワーク内のセグメンテーションポリシーの変更や機密データへの不正アクセスなど、深刻な影響を招く可能性がある。早期パッチ適用と脆弱性管理プロセスの見直しが急務である。

May 24, 2026

OpenTelemetryがCNCF Graduatedプロジェクトに昇格、可観測性の事実上の標準として正式認定

概要 Cloud Native Computing Foundation(CNCF)は2026年5月21日、OpenTelemetryをGraduatedプロジェクトとして正式に承認した。これはCNCFプロジェクトにおける最上位の成熟度ステータスであり、広範な本番環境への展開への準備が整ったことを示す。OpenTelemetryはメトリクス・ログ・トレースを収集するための統一API、SDK、標準規格を提供することで、観測性ツールのベンダー乱立問題を解消し、業界標準としての地位を確立してきた。 成長指標とエコシステムの規模 OpenTelemetryのGraduation達成を裏付ける数値は驚異的な規模に達している。2,800社以上の企業から1万2,000名超のコントリビューターが参加しており、240以上のCNCFプロジェクトの中でKubernetesに次ぐ第2位のプロジェクト速度を誇る。ダウンロード数も急増しており、JavaScriptのAPIは過去12ヶ月間で13億6,000万回、PythonのAPIは13億回のダウンロードを記録し、2026年4月には過去最高を更新した。Alibaba、Anthropic、Bloomberg、Capital One、eBay、FICO Softwareなどの大手企業が本番環境で採用しており、Google Cloud、AWS、Datadogも導入効果として特にベンダーロックイン解消を評価するコメントを寄せている。 技術的な進展 Graduation達成に向けて、OpenTelemetryは独立したセキュリティ監査とガバナンスレビューを完了している。最近の技術的な進歩としては、Kotlin言語サポートの追加と、Profiles機能がアルファ段階に達したことが挙げられる。ProfilesはアプリケーションのパフォーマンスプロファイリングデータをOpenTelemetryのシグナルとして統合するもので、メトリクス・ログ・トレースに続く4番目の主要シグナルタイプとして期待されている。統一されたAPIとSDKにより、組織はインストゥルメンテーション層を書き直すことなく監視バックエンドを切り替えることが可能になっている。 AIインフラ時代への展開 Graduationのタイミングは、生成AIおよびAIエージェントの急速な普及と重なっている。AIエージェントによる分散ワークフローの観測ニーズが急拡大する中、OpenTelemetryは「自律システムや生成AIアプリケーションを本番環境で監視するための共有基盤」として注目されている。Anthropicを含む主要AIプロバイダーがOpenTelemetryを採用していることからも、AIワークロードの可観測性標準としての位置付けが強まっている。CNCFのGraduationにより、今後さらに多くのAIインフラプロバイダーとの統合が進むことが見込まれる。

May 23, 2026

AWSデータセンター過熱で米国東部リージョンに大規模障害、Coinbaseなど主要企業に最大7時間の影響

障害の概要と原因 2026年5月、AWSの米国東部(バージニア北部)リージョン「us-east-1」において、単一データセンターの冷却装置故障に起因する過熱障害が発生した。AWSは「データセンター内の温度上昇によりアベイラビリティゾーン内のインスタンスに支障が生じた」と公式に認めたものの、詳細な根本原因については調査中とした。障害の影響範囲はus-east-1内の6つのアベイラビリティゾーンのうち「use1-az4」に集中し、EC2インスタンスとEBSボリュームが電力供給を失う形で停止した。us-east-1は世界で最も利用されているAWSリージョンの一つであるため、障害の波及範囲は広く、150以上のクラウドサービスが影響を受けた。 影響を受けたサービスと企業 障害はAWS IoT Core、Amazon EKS、Elastic Load Balancing、Amazon Redshiftをはじめ多数のマネージドサービスに及んだ。これらの多くは復旧作業が進んだ一方、Amazon ElastiCache、Amazon Managed Streaming for Apache Kafka(MSK)、Amazon OpenSearch Service、Amazon SageMakerについては復旧に時間を要した。冷却システム容量の回復作業が予想を上回る難航を見せたため、完全復旧の目処が立てにくい状況が続いた。 企業への影響では、仮想通貨取引所のCoinbaseが最も注目を集めた。同社はマルチアベイラビリティゾーン構成を採用していたものの、取引エンジンはレイテンシ最小化のために単一ゾーンで運用されており、これがリージョンレベルの障害に対応できない盲点となった。結果として取引サービスと国際取引所が約7時間にわたって利用不可となった。スポーツベッティングのFanDuelはNBAの試合中にサービスがオフラインになるという最悪のタイミングで障害に直面し、CME Groupでも機関投資家向けトレーディングプラットフォームでのログイン障害や遅延が報告された。 クロスリージョン災害復旧戦略の重要性 今回の障害は、「高可用性(HA)」と「災害復旧(DR)」が解決する問題の本質的な違いを改めて浮き彫りにした。マルチAZ構成は同一リージョン内の単一障害点を排除するが、リージョン全体に影響が及ぶような事象には対応できない。AWSのサービスクレジットは月額コンピュート費用の約10%をカバーするにとどまり、失われた収益・規制リスク・顧客信頼への補償はない。 専門家が推奨する対策として、リージョン間レプリケーションの整備(目標RPO:10分以内)、セカンダリリージョンへの自動フェイルオーバー計画の策定、そして定期的なDR手順の検証が挙げられている。シングルリージョン依存のアーキテクチャを採用している組織は、今回の障害を機にクロスリージョン戦略の導入コストと事業継続リスクを再評価する必要がある。

May 22, 2026

英国CMAがMicrosoftのビジネスソフトウェアに対しSMS調査を正式開始――クラウド・AI市場での支配力を9か月かけて審査

概要 英国の競争・市場庁(CMA)は2026年5月14日、Microsoftのビジネスソフトウェア慣行に関する9か月間の正式調査を開始した。この調査は、Microsoftが英国のデジタル市場規制上の「戦略的市場地位(SMS)」に指定されるべきかどうかを判断するもので、結論は2027年2月頃に公表される見通しだ。SMS指定を受けた場合、CMAはMicrosoftに対して競争促進のための行動指針(Pro-competitive Interventions)を課す権限を持つことになる。 CMAの最高経営責任者であるSarah Cardell氏は「ビジネスソフトウェアは英国経済が機能するうえでの要です。これらの市場がどのように発展しているかを理解することが目的であり、英国の組織が選択肢、イノベーション、競争力のある価格から利益を得られるよう確保したい」と述べ、調査の意義を強調した。 調査の対象範囲 CMAが今回審査する分野は広範にわたる。具体的には次の5点が主な論点となっている。 製品バンドル慣行――Microsoftのアプリケーションが第三者製品に対して競争上の優位を得ているかどうか 統合バリア――MicrosoftとサードパーティSaaSプロバイダー間の互換性制限 デフォルト設定――顧客が代替ビジネスソフトウェアへ乗り換えることを妨げる既定設定 AI統合――Microsoft CopilotなどAI機能の組み込み方と、競合他社が同等に統合できるかどうか ソフトウェアライセンス慣行――特にAWS・Google Cloudなど競合クラウド基盤上でのホスティングに関するライセンス条件 調査対象製品はMicrosoft 365などの生産性ソフトウェア、Windows OS(PC/サーバー)、SQL Serverなどのデータベース管理システム、セキュリティソフトウェア群と幅広い。 背景――クラウド市場調査からの流れ 今回の調査は突然始まったわけではなく、CMAが長期にわたって続けてきたクラウド市場監視の延長線上にある。CMAは2025年7月にクラウドサービス市場調査(Market Investigation)を終了しており、その過程でMicrosoftとAmazon Web Services(AWS)に対してクラウドの出力(エグレス)料金の修正と製品間相互運用性の改善を求めていた。両社は2026年3月にこれらの条件に合意し、その時点ではSMS指定を回避したが、その後もMicrosoftのビジネスソフトウェア全体に対する競争懸念は払拭されなかった。なお、AWSは今回の調査でもSMS指定の対象からは外れている。 今後の見通し CMAは2027年2月までに調査結論を出す予定だ。仮にMicrosoftがSMS指定を受ければ、CMAは製品バンドルの解除やライセンス条件の変更、相互運用性の強制開放といった措置を命じる可能性がある。AIが業務ソフトウェアに深く組み込まれていく中で、WindowsやTeams、Copilotの組み合わせが競合他社の市場参入を阻む「囲い込み構造」を形成しているかどうかが、今後の審査の核心となる見通しだ。欧州委員会や各国規制当局も同様の問題意識を持っており、今回のCMAの動向は国際的な規制議論にも影響を与えそうだ。

May 21, 2026

BlackstoneとGoogleがTPUベースのAIインフラ合弁会社を設立——50億ドル初期投資でNVIDIA依存低減へ

概要 GoogleとBlackstoneは2026年5月19日、米国内でGoogleのTPU(Tensor Processing Unit)をコンピュート・アズ・ア・サービスとして提供する合弁会社の設立を共同発表した。Blackstoneが50億ドルの初期出資を行い、レバレッジを含めた総額は約250億ドルに達する見込みだ。2027年までに500MW(メガワット)のデータセンター容量を稼働させることを目標としており、急増するAI需要に対応する大規模インフラ投資として注目されている。合弁会社のCEOにはGoogle出身のBenjamin Treynor Slossが就任予定で、同氏はGoogleにおけるSRE(サイト信頼性エンジニアリング)の創設者としても知られる。 戦略的背景:NVIDIA依存からの脱却 今回の取り組みの核心は、データセンター向けGPUで圧倒的シェアを持つNVIDIA製品への依存を低減することにある。AI向け計算需要の急拡大とともに、NVIDIAのH100やB200といったGPUは需給が逼迫し、価格高騰が続いている。GoogleのTPUはGoogleが自社AI/MLワークロード向けに独自開発した専用アクセラレータであり、特定の推論・学習ワークロードにおいてGPUと同等以上の性能を発揮する。この合弁会社を通じてTPUを外部顧客に広く提供することで、GoogleはTPUのエコシステムを拡大しつつ、AI インフラ市場における差別化を図る。 資金構造とデータセンター計画 Blackstoneによる50億ドルの自己資本投資に加え、レバレッジ(借入)を組み合わせることで総投資規模は約250億ドルに達する計画だ。AI特化のデータセンターとしては異例の大規模投資であり、Blackstoneにとっても同社のデータセンター・インフラ投資戦略の延長線上に位置づけられる。2027年までに500MWの容量を稼働させる計画は、大規模言語モデルの学習・推論に必要な電力需要を見据えたもので、立地・電力調達・冷却設備の確保が今後の重要課題となる。 今後の展望 TPUベースのクラウドプラットフォームが大規模に展開されれば、AIインフラ市場の競争構図に変化をもたらす可能性がある。現在のAIクラウド市場はAWS、Azure、Google Cloudの三強がNVIDIA製GPUを基盤として競っているが、今回の合弁会社がTPUという代替コンピュートを大規模に提供することで、GPU中心の市場構造に楔を打ち込む形となる。一方、TPUのソフトウェアエコシステム(主にJAXやTensorFlowへの依存)はNVIDIA CUDAと比較してまだ限定的であり、顧客獲得においては技術的な移行コストが課題となる見通しだ。

May 20, 2026