チップから系統まで：AIデータセンターの電力連鎖を分解する

一つの負荷に複数の系統がある

「AIデータセンターの電力」は一つの箱ではない。GPUは低電圧の直流を消費するが、キャンパスは中圧または高圧の交流を受け、保護し、熱を捨て、電力会社またはオンサイト発電の運転者と条件を結ばなければならない。その間に電源棚、バスウェイ、UPS、変圧器、開閉装置、フィーダー、冷却設備、制御、許認可、契約がある。各引渡し点で所有者、調達期間、故障様式が変わる。

国全体の需要見通しも個別地点の設計値ではない。DOEは2023年の米国データセンター消費を約176 TWh、2028年を325〜580 TWhと推計したが、これはシナリオ分析である（DOE, 2024）。特定変電所で利用できるMWも、特定ベンダーが勝つことも示さない。

容量の前に負荷台帳を作る

まずIT負荷を置き、仮定を表に出す。教材用に100 MWのIT負荷、PUE 1.20なら施設入力は120 MWとなり、20 MWが冷却、変換損失、照明、ポンプ等に配分される。ただし冗長構成、同時保守の基準、負荷の立上り、高調波、デマンド抑制は含まない。したがって「100 MWの申請」は、受電点で常時確保すべき電力をそのまま意味しない。

IT、変換損失、最暑条件の冷却、予備率、起動・ランプ、稼働時間、実際に遮断できる負荷を別行にする。各値が計測値、設計値、契約値、単なる仮定のどれかも明記する。これで企画資料を運転実績と取り違えない。

エネルギーと権限を上流へ追う

電気の連鎖は通常、送配電サービス、変電所とフィーダー、構内変圧器と開閉装置、UPSまたはDC変換、ラック配電、サーバー電源へ続く。熱の連鎖はサーバー熱、空気または冷却液ループ、ポンプと放熱、そして水・空気・冷媒の境界である。一箇所の制約だけで、他に発電容量があっても計算資源は止まり得る。

NERCは2024年の送電事故後に約1,500 MWのデータセンター負荷が同時に脱落した事例を挙げ、集合的な負荷挙動をモデル化する必要を説明した（NERC, 2025）。これは全データセンターの挙動を証明するものではなく、保護、事故時運転継続、ランプを誰が決め、誰がデータを持つかという問いである。

オンサイト発電は順序を変えられても、連鎖を消せない。系統増強の遅れを和らげる一方、燃料、排気許可、試運転、保守、予備電源が必要になる。FERCの大口負荷手続きは、20 MW超を概ね対象として調査、増強、信頼度、併設を検討している（FERC RM26-4）。一つのキャンパスにオンサイト運転計画と系統受電計画の両方が必要になる理由である。

演習

100 MW IT負荷を二通り描く。一方は系統だけ、他方は系統工事中にオンサイト電源を運転する。各箱に必要契約、支出の発生条件、受入試験、停止条件を書く。不明な日付を販売資料の予定で埋めない。

運転診断：どのMWが足りないのか

障害報告では「電力不足」をそのまま原因にしない。まずラックPDU、UPS入力、構内受電、冷却補機を同じ15分間隔で並べ、IT負荷と施設入力の差がどこで増えたかを見る。例えばITが80 MW、施設入力が98 MWなら、18 MWはその瞬間のPUE由来の差である。次に受電契約の上限、変圧器の連続定格、発電設備の試運転済み出力を別々に照合する。契約上120 MWでも、保守中の一系統を失えば運転可能な確定容量は下がり得る。

冷却も同じ台帳に置く。外気温上昇でチラーやポンプが数MW増えたのか、サーバー使用率の変化でIT負荷が増えたのかを分離しなければ、増設の責任者を決められない。負荷遮断が可能な系統と、停止するとデータ損失・安全上の問題を生む系統も区別する。これにより「100 MWキャンパス」という販売上の呼び名を、実際に運転できる電力と熱の境界へ戻せる。

数量例：PUEは設計値と運転値を分ける

100 MWのIT負荷でPUEを1.20と仮定すると施設入力は120 MWである。しかし、これを変圧器の必要定格として直ちに使ってはいけない。UPSの損失、冷却設備の最大消費、保守中に残る系統、将来の余地をどこに含めたかで必要な設備は変わる。例えば通常時はIT 80 MW、施設 96 MWでも、外気が高い時間だけ冷却が5 MW増えれば、同じIT負荷で101 MWになる。年平均のPUEが良好でも、受電契約・変圧器・発電機の設計にはピーク時の値が効く。

この例では、計器の配置も結論を変える。受電計、UPS出力計、冷却盤、ラックPDUを同じ時刻基準で採取すると、入力101 MWの内訳を説明できる。受電計だけでは、サーバーが増えたのか、冷却が増えたのか、UPSのバイパス運転が起きたのかを区別できない。計測値が欠ける場合、PUEは仮定として扱い、設備投資の確定値にしない。

小さな実験

一週間の15分データを用意し、IT、UPS入力、冷却、外気温を四列にする。ITを横軸、施設入力を縦軸に取り、外気温が高い点だけ色を変える。ITが同じでも施設入力が増える時間帯があれば、冷却または変換の条件を調べる。次に一系統を保守にした状態の単線図を重ね、通常時の余力と保守時の余力を別欄にする。この作業は将来の需要を予測するためではなく、どの設備が現在の制約かを判定するためのものである。

最後に、各制約へ「解除するための証拠」を割り当てる。受電は通電試験、冷却は性能試験、発電は燃料・系統連系・保守計画、契約は署名済み文書である。MWの数だけを並べず、測定点と受入条件を残す。

この対応表は、供給者・開発者・運転者の誰に次の行動があるかを明確にする。制約が移ったら、台帳も更新する。

更新日と根拠文書も必ず記録する。

1. 1GPUの直流負荷
2. 2ラック変換
3. 3構内配電
4. 4冷却と放熱

1. 1施設需要
2. 2系統連系またはオンサイト発電
3. 3燃料と信頼度の義務

1. 1調査または発表
2. 2実行済み契約
3. 3試運転
4. 4運転とキャッシュの証拠