電力、炭素、系統制約

対象本文

第17章のdata center電力統計、系統制約、SCI型算定境界、cloud providerのcarbon配賦方法、GPU burstの説明用仮定を補います。

収集方法

2026年7月10日にIEA Energy and AI、Ireland Central Statistics Office、Commission for Regulation of Utilities、SCI Specification v1.1、AWS/Google Cloud/Microsoftの顧客向け炭素算定方法を確認しました。2026年7月28日に、AI data centerの電力供給architectureを整理したLeeほかのreview、同論文が参照する大規模同期学習の電力安定化研究、GoogleとNVIDIAの高電圧DC構想、およびNLRの学習・微調整・推論の電力プロファイル測定を追加確認しました。提供者算定値、施設実測、統計、本文の仮定、将来構想を混在させません。

現在の答え

産業全体と系統

IEA Energy and AI (2025)は、世界のdata center電力消費を2024年約415TWh、2030年約945TWhと見通します。これはscenarioを含む世界全体の集計であり、特定cloud、region、workloadの消費電力ではありません。

Ireland CSOは、2025年のmetered electricity consumptionでdata centreが全体の23%を占めたと報告しました。Ireland CRUの新規接続policyは、所在地の系統制約、onsite generation/storage、demand flexibility、追加renewable electricity等を接続判断に含めます。ここから言えるのは、compute需要がpriceだけでなく、場所、時間、接続可能性という物理制約を受けることです。

エネルギー量と電力プロファイル

期間の平均電力に時間を掛ければ運用時エネルギーEを得られますが、その集計では最大電力、変化率、周期、測定間隔が消えます。Choukseほかは、数万GPUを同期させる学習で、計算相と通信相の切り替えが大きな電力変動を生むことを本番データで示しました。これは大規模同期学習の知見であり、一般のagent推論の波形ではありません。

Vercellinoほかは、H100基盤上の学習、微調整、offline/online推論を0.1秒間隔で測り、公開した電力プロファイルを施設全体のmodelへ接続しました。こちらも特定hardware、benchmark、施設modelの結果ですが、kWhだけでなく、最大電力、変化率、測定間隔を別欄に残す理由を具体化します。本書の成果あたり強度には、個別研究のWやkWを転記せず、該当する基盤で得た時系列または提供者の配賦方法を使います。

Eの内側にある電力供給

Leeほかのreviewは、次世代AI data centerの変化を、rack内の高電圧DC化、施設内DC配電、系統interfaceの更新という三層で整理しています。この階層は、SCIのEへ何を含めたかを点検する地図として使えます。

検討されている構造算定境界で確認すること
rack48/54V級から±400VDCまたは800VDCへ上げ、電源と蓄電をcompute rackから分けるIT loadだけか、rack内変換と待機・蓄電も含むか
施設AC/DC変換段を減らし、施設内DC buswayとenergy storageを接続する配電損失、保護、蓄電、冷却を含むか
系統interface中電圧系統から施設DC配電までの変換と制御を見直す受電・変換設備、系統制約、負荷平準化を含むか

GoogleはMt Diabloで±400VDCのsidecar power rackを、NVIDIAは800VDCの施設配電を公式資料として示しています。どちらも高密度rackへ向けた提供者の構想・roadmapです。そこに示された効率改善率を共有cloud上の個別agentへ移さず、「変換段をどこへ置き、何をEに含めるか」を読む資料として使います。MV-SSTなど系統interfaceの技術はreview上も信頼性、保護、標準化が残る研究・開発課題であり、本書は採用済みの一般解として扱いません。

算定方法

SCI v1.1は、SCI=(O+M)/RO=E×Iとして、operational energy E、location/timeに応じたcarbon intensity I、embodied emissions M、functional unit Rを分けます。本書はこれを設計比較の記録形式として使い、認証適合を主張しません。

資料主な境界比較時の注意
AWS Customer Carbon Footprint Tool methodologyAWS service利用をdata center energyとemissionsへ配賦対象service、Scope、region、更新時期を確認
Google Cloud Carbon Footprint methodologylocation-based/market-based等の方法とcustomer allocationproject/product/location粒度と更新方法を確認
Microsoft Azure emissions methodologyAzure usageをemissionsへ配賦しdashboardへ集計Scope、service coverage、allocation、reporting lagを確認
SCIsoftware systemとfunctional unitを利用者が定義provider dashboard値をそのままEMへ読み替えない

三社は共有設備を利用者へ配賦する方向で共通しますが、対象Scope、service、場所・時間粒度、market-based/location-based、embodied emissions、更新方法は同じではありません。請求額からkWhを逆算しないこと、方法版を結果と一緒に保存することが重要です。

本文の説明用仮定

本文の「full稼働300W、待機50W、1日2時間処理」は、特定GPU/serverの実測ではなく、E=P×tとidle時間の影響を説明する仮定です。常時起動300W×2h + 50W×22h = 1,700Wh、burst側300W×2h = 600Whという算術は正しい一方、50Wの待機値、power proportionality、cold start、共有hostの配賦は実測していません。この比率をcloud serviceの炭素削減率へ外挿しません。

serverlessのscale-to-zeroが直接示すのは、利用者への論理割当または課金の解除です。provider全体の物理電源、他tenantへの再配分、renewable matching、総排出がゼロになったことではありません。成果あたり強度と総排出を並べて判断します。

調査の入口

このreviewはrack、施設、系統interfaceを一続きに読むための地図として使います。2026年6月提出のv1でIEEE投稿中のため、製品構想と測定結果は次の一次資料・原著研究へ遡ります。

一次資料

既知の未知

変更履歴