Anthropic、設立半年のクラウド新興Voltaと6年100億ドルの計算資源契約

概要 Anthropicは8月4日、AIクラウド新興企業Volta Infra Holdingsと6年間で100億ドル規模の計算資源契約を締結したと報じられた。Voltaは2026年初めに設立されたばかりで、わずか半年余りでAnthropicという大口顧客を獲得した形となる。契約の舞台となるのは、暗号資産マイニング企業Bitdeer Technologiesが運営するノルウェーのデータセンターで、水力発電による電力を活用し、Nvidiaの最新チップ「Vera Rubin」を搭載する。VoltaはNvidiaのCloud Partnerプログラムにも参加しており、以前から「あるAI研究機関と協業している」とほのめかしていたが、その相手先がAnthropicであることは今回のBloombergの報道で初めて明らかになった。 技術的な詳細と契約構造 データセンターの初期稼働容量は133メガワットで、提供体制は2フェーズに分かれており、2027年3月までに順次引き渡される計画だ。なおVoltaは、このノルウェー案件を皮切りに北米・欧州で合計1ギガワット超の近未来的な開発パイプラインを抱えているとされる。この契約と同時にVoltaは3億ドルのベンチャー資金調達も実施しており、Andreessen Horowitz、Altimeter Capital、Nvidia、Michael Dell氏らが出資者に名を連ね、企業価値は24億ドルに達した。さらにVoltaは、高額なAIチップの調達負担を顧客が賄えるよう、50億ドル規模の顧客向け融資枠も新設している。今回の発表を受けて、データセンターを運営するBitdeerの株価は14%急伸した。 背景と業界動向 Voltaを設立したのは、資産運用大手Brookfieldの元幹部らで、AIブームに伴う計算資源需要の急拡大を見込んで新会社を立ち上げた。Anthropicにとって今回の契約は、計算基盤を巡る一連の大型投資の一つに過ぎない。同社はGoogle、Amazon(追加で50億ドルを出資)、SpaceX、Broadcom、AMDなど複数のパートナーと計算資源やインフラ面での提携を進めており、OpenAIなど競合とのAI開発競争を見据えて計算能力の確保を急いでいる。一方で、AIラボとチップサプライヤーの間で相互依存が強まることについては、AI需要が期待通りに伸びなかった場合に財務的な損失が連鎖的に拡大するリスクがあると指摘する声も業界にはある。

August 6, 2026

クラウド市場、AI需要で8年ぶり43%成長 AWS28%維持、Google Cloudは15%へ上昇

概要 調査会社Synergy Research Groupが発表した2026年第2四半期のクラウドインフラ市場(IaaS・PaaS・ホスト型プライベートクラウドの合計)分析によると、市場規模は1430億ドル(1ドル160円換算で約22兆8800億円)に達し、前年同期比43%という成長率を記録した。この伸び率は8年ぶりの高水準であり、市場規模は3年前と比べて2倍以上に拡大している。急速な拡大の背景には、生成AIサービスの普及に伴うAIワークロード向けインフラ投資の急増があるとみられる。 シェアの推移 主要3社のシェアを見ると、首位のAWSは前四半期から変わらず28%を維持した。2位のMicrosoft Azureは1ポイント下落して20%となり、3位のGoogle Cloudは1ポイント上昇して15%に達した。3社合計のシェアはほぼ横ばいで推移しており、大きな順位変動は見られない。 分析と背景 Synergy Research Groupは、市場全体が記録的な高成長を続けているにもかかわらず、上位3社がシェアをほとんど落とさずにいる点を指摘している。これは、市場全体を押し上げているAI関連需要の恩恵を、大手クラウドベンダー自身が最も大きく取り込んでいることを示すものだといえる。新興のクラウドベンダーやニッチプレイヤーが台頭する余地よりも、既存の大手3社がAIインフラ投資を主導し、そのまま市場拡大の恩恵を享受する構図が続いている。 今後の見通し AI需要を背景とした高成長が続く中、AWS・Azure・Google Cloudの3社は今後もデータセンターやAI特化チップへの投資を拡大していくとみられる。各社のシェア争いは僅差の変動にとどまっているものの、市場全体のパイが急速に拡大していることから、絶対的な売上規模では各社とも大幅な伸びを記録している可能性が高く、今後の四半期報告でもAI投資動向が焦点となりそうだ。

August 6, 2026

Cloudflare、アイソレートとコンテナを動的併用するAIエージェント向けランタイム「@cloudflare/computer」を発表

概要 Cloudflareは「Agents Week」の一環として、AIエージェント向けの新しい実行環境ライブラリ「@cloudflare/computer」をプレビュー公開した。エージェントごとに専用のコンテナを割り当てる従来型のアプローチとは異なり、軽量な「アイソレート」とフルLinuxコンテナを動的に使い分けることで、効率性とスケーラビリティを両立させる狙いがある。オープンソースとして公開されており、ファイル操作やGitリポジトリ管理といった軽量なタスクはアイソレートで処理し、npmパッケージやネイティブバイナリの実行が必要な場合にのみコンテナへ切り替えるという、エージェント自身が実行環境を選択する仕組みを持つ。 技術的な詳細 @cloudflare/computerの中核には、SQLiteでバックアップされた仮想ファイルシステムがある。アイソレート実行環境では、シェルコマンドをJavaScriptに変換する「just-bash」という仕組みを用い、Cloudflareの動的ワーカー上でコードを実行する。一方、Linuxやnpm、ネイティブバイナリを必要とする処理ではコンテナを起動し、FUSE(Filesystem in Userspace)マウントを介してアイソレート側の仮想ファイルシステムとファイルを同期する。エージェントは「ファイル操作、データ処理、Gitリポジトリ管理ならアイソレートで実行可能。Linuxやnpm、ネイティブバイナリが必要ならコンテナを使用」という判断を自動的に行い、Cloudflareはこの設計により全作業のうちコンテナ利用を10%未満に抑えることを目標に掲げている。 背景と今後の展望 この取り組みの背景には、スケーリングに関する切実な課題がある。Cloudflareは「世界中のすべてのクラウドとハイパースケーラーにおいて、各ユーザーのエージェントに独立したコンテナ環境を提供できる計算資源は存在しない」と指摘し、コンテナ中心のアーキテクチャでは持続可能なスケールを実現できないとの立場を示す。Cloudflareは10年前のCloudflare Workers導入以来、アイソレート技術に投資を続けてきた企業であり、水平スケーリングのしやすさや高速な起動・終了、休止状態への移行、状態保存といった特性を活かす形で今回のハイブリッド設計に至った。同社はすでに、JavaScriptアプリケーションの構築・テスト・デプロイ、顧客向けドキュメント生成、ブラウザ操作を伴う複雑なタスクの実行など、アイソレートのみで完結する実運用例を複数報告しており、「最も有能なエージェントが共通に持つことは簡潔だ。自分で作業するコンピュータが与えられていることだ」との考えのもと、今後もエージェント向けインフラの拡充を進める方針とみられる。

August 6, 2026

Azure、新規Gen2 VMでセキュアブートとvTPMを既定で有効化する「Trusted Launch as Default」が正式提供

概要 Microsoftは8月3日、Azureの新規Gen2仮想マシン(VM)およびスケールセットに対してセキュアブートと仮想TPM(vTPM)を標準で有効化する「Trusted Launch as Default(TLaD)」を正式提供開始(GA)したと発表した。ARMテンプレート、Bicep、Terraformなどどのクライアントツール経由でデプロイした場合でも、対象となる新規Gen2 VM・スケールセットはTrusted Launch構成でセキュアブートとvTPMが有効な状態で作成されるようになる。追加コストは発生せず、デプロイコード側で明示的な指定がない限りこの既定値が上書きされることもない。なお、AzureポータルやCLI、PowerShell経由の作成では、この機能のプレビュー登録の有無にかかわらず、以前からTrusted Launchが既定で有効になっている。 技術的な詳細 Trusted Launchはブートキットやルートキット、低レイヤーのマルウェア攻撃に対する防御を強化するための複数の協調したインフラ技術で構成される。中核となるセキュアブートはプラットフォームファーム上で実装され、信頼された発行元が署名したブートローダー・OSカーネル・ドライバのみを起動対象とすることで、ソフトウェアスタックの「信頼の起点(root of trust)」を確立する。署名の検証に失敗した場合、VMは起動しない。もう一方の柱であるvTPMはTPM 2.0仕様に準拠した仮想化TPMで、VMからは独立したセキュアな環境で動作し、鍵や測定値を保管する専用の金庫として機能する。vTPMはUEFI・OS・システム・ドライバに至るブートチェーン全体を測定し、リモートアテステーションを通じてMicrosoft Defender for Cloudと連携する。アテステーションに失敗した場合はブート整合性の問題を示す統合性アラートが発行される仕組みだ。対応VMサイズはB・D・E・F・L・NC/ND/NVファミリーなどx64およびArm64(Cobalt 100ベース)の主要シリーズに及び、すべてのパブリックリージョン、Azure Government、Azure Chinaリージョンで利用できる。 有効化の仕組みと注意点 Azureポータル・CLI・PowerShellでは従来どおり常にTrusted Launchが既定となる一方、ARMテンプレートやBicep、Terraformなど別のクライアントツール経由でTLaDを利用するには、サブスクリプション上でMicrosoft.Compute名前空間のプレビュー機能「TrustedLaunchByDefaultPreview」を登録する必要がある。API version 2025-11-01以降を使うと、Marketplaceイメージ・Azure Compute GalleryイメージがTrusted Launch対応であること、ディスクとVMサイズがTrusted Launchをサポートしていることなど一定の条件を満たす場合に自動的にTrusted Launchが適用される。条件を満たさない場合はエラーにはならず、Trusted Launchなしで通常どおりVMが作成される。既定を明示的にバイパスしたい場合はsecurityTypeパラメータをStandardに設定すればよい。また、既存のVMやスケールセットはTLaDの影響を受けず、この変更が適用されるのは新規デプロイのみである。なお既知の制限として、いったんTrusted Launchで作成したVMをM-seriesなど非対応のVMサイズファミリーへリサイズすることはできず、必要な場合はVMを割り当て解除したうえでAPI経由でsecurityTypeをStandardに変更する対応が求められる。 背景と今後の展望 Trusted Launch自体は既存の機能だが、これまでは利用者が明示的に有効化する必要があった。今回のGAにより、新規デプロイ時点でのセキュリティベースラインが自動的に底上げされ、意図せずセキュアブートやvTPMが無効なまま本番稼働するVMが減ることが期待される。Microsoft Defender for Cloudは従来からセキュアブートやvTPMが無効なVMに対して低重要度の推奨事項を出しているが、TLaDによって新規VMではそもそもこうした推奨事項が発生しにくくなる。既存VMについては別途「Enable Trusted launch on existing Gen2 VMs」などの手順に沿った移行が必要であり、既存フリートを含めた全面的な底上げには利用者側の対応が引き続き求められる点には留意したい。

August 5, 2026

AWS Interconnect、Oracle Cloud Infrastructure接続が一般提供開始 マルチクラウド接続を簡素化

概要 AWSは7月29日、複数のクラウドプロバイダー間をプライベート接続するサービス「AWS Interconnect」について、Oracle Cloud Infrastructure(OCI)対応を一般提供(GA)開始したと発表した。OCIは5月から公開プレビューとして先行サポートされており、今回正式にGAへ移行した形となる。AWS Interconnectとしては、既に対応済みのGoogle Cloudに続き2番目のマルチクラウド接続先となる。AWSは、複数のクラウドサービスを個別に組み合わせて接続を構築する「DIY型マルチクラウド」の複雑さを排除することを本サービスの狙いとして説明している。 技術的な詳細 AWS Interconnectはオープン仕様に基づいて構築されており、その仕様はGitHub上で公開されている。ユーザーはAWS Management Console、CLI、APIのいずれからでも接続を設定できる。現時点でのサービス提供リージョンはus-east-1(バージニア北部)のみとなっており、他リージョンへの展開時期は今回の発表では明らかにされていない。なお、具体的な料金体系やユースケースの詳細については、今回のアナウンスメントには記載がなく、公式ドキュメントの参照が推奨されている。 今後の展望 AWSはMicrosoft Azureについても2026年後半にAWS Interconnect対応を追加する計画を明らかにしている。これが実現すれば、AWS Interconnectは主要3大クラウド(Google Cloud、OCI、Azure)すべてとのプライベート接続をサポートすることになり、複数クラウドにまたがるワークロードを運用する企業にとって、クラウド間のネットワーク構築を大幅に簡素化する選択肢となりそうだ。

August 4, 2026

Kubernetes v1.37の変更点先行公開、kubectl runの一部フラグ非推奨化やipvsモード段階的廃止へ

概要 Kubernetesプロジェクトは7月31日、次期バージョンv1.37で予定されている主な変更点を公式ブログで先行公開した。今回のリリースでは大型の新機能追加よりも、既存機能の非推奨化や整理が中心となっており、kubectl runコマンドの--filename(-f)フラグの非推奨化、Static PodからのSecret/ConfigMapへのAPIリソース直接参照の禁止、そしてkube-proxyのipvsモードの段階的廃止という3つの変更が柱となっている。いずれもすぐに動作が壊れるものではないが、クラスター管理者やスクリプトの保守者は早めに対応を計画しておく必要がある。 kubectlとStatic Podの変更 kubectl runの--filenameフラグは、生成されるPodが常にコマンドライン引数(Pod名や--imageなど)から構築される仕様上、ファイル指定自体に意味がないという理由から非推奨化される。代替コマンドの使用が想定されるが、公式ブログでは具体的な置き換え先は明示されていない。 またkubeletでは、APIサーバーを経由せずノード上の設定ファイルから直接生成されるStatic Podについて、configMapRefやsecretRefなどのフィールドを用いたAPIリソースへの参照が厳密に禁止される。Static PodはAPIリソースへのアクセスを前提とした設計になっておらず、これまでバグによりconfigMapRef/secretRefでの参照が実際には機能せず黙って無視される状態だったものを是正する措置で、これに伴い暫定的な回避手段だったPreventStaticPodAPIReferencesフィーチャーゲートも削除される。該当する設定を使っている場合は、Static Podでの直接参照ができなくなるため、他の方法での対応を検討する必要がある。 kube-proxy ipvsモードの段階的廃止 もう一つの大きな変更が、kube-proxyのipvsモードの非推奨化だ。ipvsモードはv1.8で、iptablesモードのパフォーマンス課題を解決する目的で導入された経緯があるが、カーネルのIPVS APIだけではKubernetes Servicesの仕様を完全に実装できず、内部的にはiptablesにも依存し続けているという構造的な問題を抱えていた。この点は「KEP-3866」でも指摘されており、iptables・ipvs双方の課題を解決する後継としてnftablesベースのプロキシ実装が進められている。 廃止はv1.37から段階的に進む。v1.37ではログに非推奨警告が出力されるのみでデフォルトの動作は変わらないが、v1.40でipvsモードがデフォルト無効化(フィーチャーゲート経由での有効化は可能)され、v1.43でサポートが完全に削除される予定だ。現在ipvsモードを利用しているクラスターの管理者は、kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}'などでモード設定を確認し、iptablesモードやnftablesモードへの移行計画を早めに立てておくことが望ましい。 今後の展望 今回予告された変更はいずれも即座に破壊的な影響を及ぼすものではないが、v1.37はこれらの非推奨化サイクルの起点となる。特にipvsモードの廃止は複数バージョンにまたがる長期計画であり、大規模クラスターほど移行に時間を要する可能性がある。あわせて、cgroup v1のサポート廃止も継続中の課題として挙げられており、モダンなLinuxディストリビューションとcontainer runtimeへの更新が引き続き推奨されている。正式なv1.37のリリースノートは今後公開される予定で、詳細な移行ガイドの追跡が求められる。

August 4, 2026

Amazon、時価総額3兆ドル突破 AWS売上37%増の好決算が株価を押し上げる

概要 Amazonの時価総額が初めて3兆ドルを突破し、約3.08兆ドルに到達した。Apple、Microsoft、Nvidia、Alphabetに続く5社目の「3兆ドルクラブ」入りとなる。2024年6月に2兆ドルを達成してから約2年での大台突破であり、背景にはAI需要を追い風にしたクラウド事業AWSの急成長を含む、市場予想を上回る第2四半期決算がある。株価は決算発表を受けた金曜日に約15%急騰し、月曜日にはさらに約5%上昇して285ドル前後の史上最高値をつけた。2営業日での上昇率は20%を超える。 決算のポイント 第2四半期のAWS売上高は422億ドルで、前年同期比37%増と18四半期ぶりの高い伸び率を記録し、ウォール街の予想を約20億ドル上回った。全社売上高は2006億ドルとなり、市場予想の1964.7億ドルを上回った。広告事業の売上も198億ドルと26%増加し、好調な収益源となっている。調整後1株当たり利益は1.97ドルとなり、市場予想の1.82ドルを上回った。また契約バックログは前四半期の3640億ドルから4960億ドルへと積み上がっており、AWSの需要が今後も継続することを示唆している。 資本支出と今後の展望 Amazonは2026年の設備投資(CapEx)計画を、2月に示していた200億ドルから220億ドルへと引き上げた。CEOのアンディ・ジャシー氏は、メモリー価格の上昇がこの20億ドルの増額の主な要因だと説明しており、増額分はデータセンターやAIインフラの整備に充てられる見通しだ。AWSの急成長は、生成AI関連の設備投資が実際の収益として結実し始めていることを示す事例として市場から注目されており、巨額のAI投資を続ける同業他社にとっても業績と投資回収のバランスを占う材料となりそうだ。

August 4, 2026

Cloudflare、リーダー不要の合意アルゴリズム「QuePaxa」採用の新サービス「Meerkat」を発表

概要 Cloudflareは、同社の330以上のグローバルデータセンター間で内部の制御プレーン状態を安全に同期させるための新しい分散合意サービス「Meerkat」を発表した。Meerkatは「QuePaxa」と呼ばれる合意アルゴリズムを採用しており、これは世界規模の本番環境でQuePaxaを初めて採用する試みとなる。現時点ではまだ実験段階で、本番環境への展開は行われておらず、まずは内部利用にとどめる方針だという。 既存の合意アルゴリズムが抱える課題 Cloudflareの内部サービスの多くは、複数のデータセンターにまたがって同じ状態を読み書きする必要があり、異なる読み取り者が矛盾した状態を見ることがないという強い一貫性(リニアリザビリティ)が求められる。しかし、Raftに代表される従来のリーダーベースの合意アルゴリズムは、広域ネットワーク環境では課題を抱えている。リーダーとなったレプリカだけが書き込みを受け付けられる仕組みのため、リーダーに障害が発生すると新しいリーダーが選出されるまで書き込みができなくなる。さらに、広域ネットワークでは遅延が予測しづらく、適切なタイムアウト値の設定が難しいという問題もある。 QuePaxaの技術的な特徴 QuePaxaはこうした課題を解決するために、リーダーを必要としない設計を採用している。すべてのレプリカが常に書き込み可能な状態にあり、単一障害点が存在しない。クライアントは複数のレプリカに対して同時に提案を送ることができ、それらの提案が破棄されるのではなく建設的に相互作用する仕組みになっている。また、進捗がタイムアウトによって停止しないよう設計されているのも特徴だ。Cloudflareによれば、悪条件下ではRaftと比較して約10倍高いスループットを達成できるという。 アーキテクチャとしては、各レプリカが共有ログを維持し、ログの各スロットには最大1つのイベントが記録される。合意アルゴリズムによって最新のスロットが決定され、すべてのレプリカが同一のログを持つことが保証される仕組みだ。読み取り処理もこのログを経由することで、一貫性が確保されている。合意決定には原理的に1〜3回のラウンドトリップが必要となるが、レプリカを地理的に近接配置する、複数の操作を1つの提案にまとめてバッチ化する、古いデータの許容度に応じて新しい合意ラウンドを省略する「ステイルリード(stale read)」、CAS(Compare-And-Swap)風の操作で複数操作を1ラウンドにまとめるトランザクション機能などにより、レイテンシの低減を図っている。 想定用途と今後の展開 現在Meerkatは、AIモデルインスタンスの保存場所といったリソース配置情報や、どのレプリカがデータベースへの書き込み権を持つかといったリーダーシップ情報など、比較的アクセス頻度の低い制御プレーン情報の管理を想定している。一方で、一般的なデータベースのような高頻度アクセスが必要なシステムへの適用は想定していないとしている。Cloudflareは最大50レプリカ規模での概念実証に成功しており、リーダーが常に障害を起こす状況下でもエラー率が増加しないことを確認したという。今後はQuePaxaアルゴリズムの詳細解説記事の公開、Rust実装の形式検証、クラスタ管理や最適配置方法論の確立、査読論文の準備などを進める予定で、今後1年間で関連記事を複数公開するとしている。

August 4, 2026

熊本震度7の地震でTSMCとトヨタが操業停止、半導体・自動車のサプライチェーンに打撃

概要 2026年7月29日午後4時27分頃、熊本県でマグニチュード7.1の地震が発生した。震源の深さは約16キロメートルで、宇城市と氷川町では最大震度7、TSMCの日本子会社JASM(Japan Advanced Semiconductor Manufacturing)が拠点を置く菊陽町でも震度5相当の揺れを観測した。地震発生直後、JASM熊本工場は従業員を避難させ、トヨタも福岡県内の宮田・神田・小倉の3工場を停止するなど、日本経済を支える半導体・自動車両業界の生産拠点が相次いで操業を止めた。人的被害も大きく、道路損壊や大規模停電・断水も発生しており、政府は今後1週間程度、同規模の地震への警戒を呼びかけている。 半導体・自動車業界への影響 TSMCは「All personnel were safe」とした上で、地震力が相対的に高かったため設備の検査・較正に相応の時間を要するとし、建設中だった第2ファブ予定地への影響はなく追加検査後に作業を再開したと説明した。トヨタは当初、宮田・神田・小倉の3工場を水曜夜から金曜まで停止し、金曜に安全性と部品供給状況を再評価した上で8月3日の稼働再開を検討する方針を示した一方、別の記事では地域内の3工場(レクサス、ハイブリッド、エンジン生産)が8月5日まで停止するとも報じられており、状況が日々更新されていたことがうかがえる。トヨタ広報は「The situation, including aftershocks and recovery efforts, is changing daily」と述べ、余震の状況次第で対応を変えていく姿勢を示した。ホンダも熊本のオートバイ工場の操業停止を延長して損傷箇所の修理を進めたほか、日産は熊本の2工場で部品納入遅延により生産を部分停止、三菱自動車も岡山工場の一部生産を停止するなど、影響は九州域外にも波及した。 被害状況とインフラへの影響 ルネサス エレクトロニクスは熊本の2工場で天井パネルの落下、壁のひび割れ、水漏れを確認し、ソニーグループも半導体生産を一時停止した。一方でアイシンは2016年の熊本地震の際とは異なり、耐震対策により建屋や設備に大きな構造的損傷がなかったとしている。人的被害は深刻で、死者数は当初13人と伝えられたのち34人まで拡大したと報じられ、イオンモール熊本での爆発事故では最終的に7人が死亡したと報じられているほか、日本製紙の工場事故では煙突倒壊などの被害により9人が死亡した。インフラ面では約3万6900戸が停電、約8万4000戸が断水、約9500戸でガス供給が停止し、鉄道・航空便にも運休が相次いだ。 サプライチェーンへの影響と今後の見通し 熊本県が位置する九州は日本の自動車・半導体産業の重要拠点であり、地域の産業生産の約5分の2を占めるとされる。野村総合研究所のエコノミストは「The negative impact on production activity and supply chains will likely be relatively temporary」と分析し、被害額は1兆円を下回る見通しを示した。一方、みずほ銀行のアナリストは、日本企業が度重なる地震やコロナ禍を通じて培った調達先の多様化がサプライチェーンの耐性を高めたと指摘しつつ、半導体産業の拠点集中度の高さから「波及効果は大きい可能性がある」と警告している。保険業界の試算では、ブルームバーグ・インテリジェンスによると保険金請求額が11億ドルを超える可能性があるとされる。今回はアイシンなど一部企業で2016年の熊本地震の際と比べ耐震対策により設備損傷が抑えられたとされる一方、政府による余震警戒の呼びかけが続く中、各社の生産再開状況とサプライチェーンへの実際の影響が今後の焦点となる。

August 3, 2026

企業ITの過半数が社外施設で稼働、Uptime Institute調査でAIが人材・コスト危機を加速と判明

概要 データセンター業界の調査機関Uptime Instituteが7月29日に発表した第16回年次グローバルデータセンター調査によると、企業ITワークロードのうちコロケーションやクラウド、SaaSなどサードパーティ施設で稼働する割合が46%に達し、自社データセンター(44%)を初めて上回った。残る10%はITルームやサーバーキャビネットなど小規模な自社設備が占めている。この調査は1,600人以上の回答者、800以上のデータセンター運営事業者を対象に実施されたもので、Uptime Instituteは2028年までにこの差が48%対42%へとさらに拡大すると予測している。企業がクラウドやコロケーションへワークロードを移管する流れは長年指摘されてきたが、自社施設の比率を上回ったのは今回の調査が初めてとなる。 AIが押し上げるコストと容量予測の不確実性 背景にあるのはAI需要によるインフラ需要の急拡大だ。経営陣の79%が依然としてコストについて何らかの懸念を示しており、コストを「最大の懸念事項」に挙げる割合こそ前年の44%から38%へと低下したものの、懸念自体が解消されたわけではない。より顕著なのは容量予測の難しさで、将来の需要を見通せないと答えた事業者は76%に上り、前年から大きく上昇した。あわせて電力供給の確保についても64%が懸念を表明しており、Uptime Instituteの幹部は、AIが「コスト、容量予測、電力、人材という複数の別々のリスクを圧縮している」と指摘する。事業者はAI訓練向けの高密度クラスターと、従来型のCPUベースのエンタープライズワークロードという性質の異なる2つの市場に同時対応せざるを得ず、段階的な設備投資や柔軟な計画立案に頼る動きが強まっているという。 ラック電力密度と障害コストの上昇 AI関連ワークロードの拡大は、物理インフラの設計にも表れている。モーダル(最頻値)のラック電力密度は2025年の9kWから2026年には11kWに達し、平均値も7.5kWから7.8kWへと上昇した。120kWや1MW級という極端な高密度ラックを導入する事業者も現れているが、30kWを超えるラックを持つ事業者は19%から24%への増加にとどまり、大多数の施設ではまだ少数派である。一方、障害発生時の経済的インパクトは深刻さを増しており、最大障害の復旧コストが10万ドル以上に達したケースは57%から71%へと急増した。重大な障害を過去3年以内に経験した事業者自体は前年より3ポイント減の47%とやや改善しているが、ひとたび障害が起きた際の損失規模は拡大している。 深刻化する人材不足とサステナビリティへの対応 インフラの拡大ペースに人材確保が追いついていない実態も浮き彫りになった。有資格候補者の確保に難しさを感じる事業者は53%に上り、前年の46%から悪化した。特に電気系統の技術者とジュニアクラスの運用スタッフの採用が難航しているという。一方でサステナビリティ面では、水使用量を追跡する事業者が47%から53%に増加するなど一定の進展が見られるものの、サプライチェーン全体を含むスコープ3排出量を追跡している事業者はわずか21%にとどまり、環境負荷の全体像把握はまだ発展途上にある。Uptime Instituteの調査結果は、AI時代のインフラ需要が単なる規模拡大にとどまらず、コスト構造、人材戦略、電力調達のあり方までも根本から問い直していることを示している。

August 3, 2026