スキップしてメイン コンテンツに移動

AI時代の真のボトルネックはGPUではなく送電網である:韓国の26万台GPU計画と日本の電力認識の差異を中心に

AI時代の真のボトルネックはGPUではなく送電網である

AI時代の真のボトルネックはGPUではなく送電網である

韓国の26万台GPU計画と日本の電力認識の差異を中心に

AIインフラ競争を語るとき、私たちは通常、まずGPUの数量に注目する。どの国がNVIDIAのGPUを何枚確保したか、どの企業がBlackwellをどれだけ導入するか、何EFLOPS規模のAIスーパーコンピューターを構築するかがニュースの中心になる。

しかし、最近の状況を見ると、本当のボトルネックはGPU自体ではないかもしれない。GPUを確保しても、それを装着するデータセンター、そのデータセンターに供給する電力、そしてその電力を実際の場所まで送る送電網が準備されていなければ、GPUを稼働させることはできない。

韓国がNVIDIAから26万台以上の規模のGPUインフラを確保することに合意したという発表は、この問題を非常に鮮明に示している。NVIDIAの公式発表によると、韓国政府、サムスン電子、SKグループ、現代自動車グループ、NAVER Cloudなどが合わせて25万台を超えるNVIDIA GPUインフラを構築する予定である。具体的には、政府とクラウド事業者に5万台以上、サムスン電子に5万台以上、SKグループに5万台以上、現代自動車グループに5万台、NAVER Cloudに6万台以上という構成が提示されている。

この数字は、韓国のAI産業にとって非常に大きなチャンスである。しかし同時に、疑問も生じる。

「このGPUを、実際にどこで、どのような電力で、何年以内に稼働させることができるのか?」

26万台のGPUは単なるサーバーの購入ではない

26万台という数字は、単にサーバー室に機器を追加するレベルではない。BlackwellクラスのGPUは1枚あたりの消費電力が非常に大きく、これをラック単位でまとめると、従来のデータセンターとは異なる電力密度を要求される。

NVIDIAの最新GPUラックの電力使用量は、2020年代初頭の数十kW水準から、2025年には100kWを超える水準へと上昇しており、将来的には数百kWクラスのラックも現実的な範囲に入ってきている。韓国電力公社(KEPCO)の関係者もAIデータセンターの電力密度上昇を指摘し、今後は単一のデータセンターが原発1基分(約1GW)の電力を使用する時代が遠くないと言及した。

26万台全体を単純計算すると、GPU自体の電力だけで数百MWクラスになる。ここにCPU、メモリ、ストレージ、ネットワーク、電力変換損失、冷却、UPS、変電設備まで含めると、データセンター全体の負荷はさらに大きくなる。多くの報道や分析において、26万台のGPU規模のAIインフラのために約500〜800MW水準の電力が必要になる可能性があると推定されている理由がここにある。

ここで重要なのは、韓国にデータセンターがないという意味ではない。韓国にはすでに商業用データセンターやクラウドインフラが存在する。問題は、既存のデータセンターが26万台規模の新規AI GPUを即座に受け入れられる構造になっているかという点だ。

一般的なデータセンターとAIファクトリーは要求条件が異なる。AI学習用のGPUクラスターは、高密度ラック、大電力引き込み、液冷、高速ネットワークファブリック、大規模な変電設備、安定した電力品質を同時に要求する。したがって、「GPUを購入したから既存のセンターに入れればいい」という風には解決しない。

正確に言えば、韓国の問題は「センターがない」のではなく、「26万台規模の新規AI GPUを受け入れられるだけの高密度AIデータセンターと電力インフラを十分に早く準備できるか」である。

真のボトルネックは発電量よりも「電力の場所」だ

AIデータセンターの電力問題を話すとき、よく「電気が不足しているのか?」と尋ねられる。しかし、より正確な質問は、「必要な場所に、必要な時点で、必要な電力を供給できるか?」である。

韓国の場合、発電所は主に首都圏以外の地域にあり、データセンターの需要は首都圏に集中する傾向が強い。クラウド、AI推論、金融、インターネットサービス、大企業顧客、専門人材が首都圏に集中しているためだ。特にAI推論センターは、ユーザーとの距離が近いほど遅延時間を短縮できるため、首都圏への立地選好が強い。

一方、首都圏は電力自給率が低く、送電網の余裕も限られている。韓国電力の関係者は、新規の電力接続申請の約70%が首都圏に集中しているが、首都圏は外部の地域から電気を引き込まなければならない構造だと指摘した。また、345kVの送電線建設には通常13年かかることがあるのに対し、データセンターや再生可能エネルギー施設は2〜3年で建設できると説明した。

この時間差が核心である。GPUの購入とデータセンターの建設は比較的迅速に進められるが、送電線や変電所は地域の受容性、許認可、補償、環境影響評価、建設期間のためにはるかに長い時間がかかる。

つまり、電力問題は「後で機器が増えたら考えればいい問題」ではない。AIデータセンターを計画する瞬間から、電力接続의可能性、変電所の位置、送電網の増設計画、冷却方式、地域の分散可能性を同時に検討しなければならない。

電力供給はいつから考慮すべきか?

結論から言えば、AIデータセンターや大規模なGPUクラスターを構築しようとする企業は、電力供給を今から考慮しなければならない。特に1〜2MW水準の小規模なGPUサーバー室ではなく、10MW以上、50MW以上、100MW以上の規模を考えているなら、電力の検討は事業計画の後期ではなく、最も初期の段階で行うべきである。

規模別にみると、以下のように分けることができる。

第一に、数十台から数百台のGPU水準の社内AIサーバーであれば、既存のIDC、クラウド、コロケーションを活用できる。この場合、電力は重要だが、事業全体を左右するボトルネックとまでは言えないかもしれない。ただし、高密度ラックを導入する場合は、ラックあたりの電力制限と冷却の限界を必ず確認しなければならない。

第二に、数千台のGPU規模になると、電力はすでに核心的な検討項目である。この段階では、機器の見積もりよりも前に、ラックあたりの電力、総IT負荷、PUE、冷却方式、電力引き込み容量、冗長化構成を計算しなければならない。既存のデータセンターに入居する場合でも、希望するだけの高密度エリアを確保できない可能性がある。

第三に、数万台のGPU規模になると、事実上データセンター事業ではなく電力インフラ事業に近くなる。この段階では、GPUの価格よりも、電力契約、変電所、送電網、土地、冷却水、地域住民の受容性、許認可のスケジュールが重要になる。

第四に、国家単位の数十万台のGPU計画は、送電網計画と産業政策を合わせて見なければならない。GPUの導入発表だけでは不十分だ。何MWをどの地域にいつ供給できるか、首都圏と地方をどのように分けるか、AI学習と推論のワークロードをどのように分散させるかまで設計しなければならない。

したがって、「電力はどのくらい後から考慮すればいいのか?」という質問に対する答えは明確だ。

大規模なAIインフラにおいて、電力は後から考慮する項目ではなく、GPUを購入する前から確定しておくべき前提条件である。

韓国ではなぜ今、電力問題が急浮上したのか

韓国でこの問題が急激に大きくなった理由は、NVIDIAの26万台GPU発表がきっかけとなったためだ。韓国は半導体、製造業、通信、インターネットプラットフォーム、自動車産業が強い。AIを製造、ロボット、自動運転、半導体プロセス、通信網、クラウドに適用しようとする需要も大きい。

しかし、これらのすべての需要が同時にGPUインフラを要求すると、送電網のボトルネックが浮き彫りになる。特に首都圏のデータセンターの許認可と電力接続の問題がすでに現実化している。最近の韓国メディアの報道によると、首都圏のデータセンターにおける電力供給審査で相当数が脱落しており、ソウル市内での通過事例は極めて稀であると指摘されている。首都圏以外の地域は相対的に通過率が高いが、データセンターの需要企業は依然として首都圏へのアクセス性を求めている。

結局、韓国の構造的な問題は以下の通りである。

  1. 需要は首都圏にある。
  2. 電力は地方で作られる。
  3. 送電網はすぐには増えない。
  4. AIデータセンターは従来のデータセンターよりはるかに大きな電力を要求する。
  5. GPUの導入速度は、送電網の拡充速度よりも早い。

この構造では、GPUを確保しても実際の稼働率が制限される可能性がある。機器を持ち込んでも電力の引き込みが遅れたり、ピーク電力の制限によってすべての機器を同時に最大性能で稼働させられない可能性が生じる。

日本は韓国とは少し異なるアプローチをとっている

日本も同様の問題を抱えているが、認識の方法は韓国と少し異なる。韓国はNVIDIAの26万台GPUやAIファクトリーの発表をきっかけに、「GPUはあるが電力は大丈夫か?」という形で問題が急浮上した。一方、日本はデータセンターや半導体工場の増加が、長期的な電力需要を再び押し上げる要因になるという観点からアプローチしている。

日本の経済産業省は、2026年度提出分からデータセンターの電力使用量、PUE、エネルギー消費原単位などを報告することを義務付け、一部の情報は事業者に公開することを求めている。また、2029年度以降に新設されるデータセンターには、PUE 1.3以下というより厳しい効率基準を要求する方針を提示した。従来は2030年度までにPUE 1.4以下が目標だったが、新規センターにはさらに高い基準を適用しようとしている。

また、日本はAIデータセンターの増加に対応し、原発の再稼働や建て替え、電力供給の安定性についても再議論している。ロイターの報道によると、経済産業省は2040年代までに老朽化した原発2〜5基、2050年代までに最大14基の建て替えが必要になる可能性があるという政策提言を打ち出した。その背景には、AIデータセンターなどによる電力需要の増加がある。

つまり、日本はこの問題を「GPU確保の競争」として捉えるのではなく、「長期的な電力需要、データセンターの効率、立地の分散、原発・再生可能エネルギー・送電網を含むエネルギー政策」として捉えている。

韓国が産業政策やAI競争の観点から電力ボトルネックを急速に認識し始めたのに対し、日本はエネルギー政策や効率規制の観点から、比較的制度化された方法で対応していると言える。

これからはGPUの数量よりもMWが重要になる

AIインフラ競争の指標は変化している。過去には「GPUを何枚確保したか」が重要だった。これからは「何MWを確保したか」「いつ系統接続が可能か」「ラックあたり何kWを安定して冷却できるか」「PUEはいくらか」「電力単価はいくらか」がより重要になる。

特にAI学習は、大規模なGPUを長時間高負荷で稼働させる。AI推論は、ユーザー数が増えるにつれて継続的な電力需要を生み出す。ここにAIエージェント、画像・動画生成、ロボット、自動運転、デジタルツインが拡散すれば、GPUの使用量はさらに増加する。問題は、半導体の生産能力だけが増えても、AIインフラが自動的に拡張されるわけではないという点だ。

  • GPUは工場で作れるが、送電網はそれほど早く作れない。
  • GPUは数ヶ月単位で納品されるが、送電網は数年から10年以上かかることがある。
  • サーバーは購入すれば済むが、電力の接続権利や地域の受容性は金だけでは解決できない。

これが、今後のAI産業において電力がボトルネックになる理由である。

企業が今すべきこと

AIインフラを準備する企業であれば、GPUの見積書だけを見るのではなく、以下の項目をまず確認しなければならない。

  1. 必要な総IT負荷をMW単位で計算する。GPUの数量、サーバー構成、ネットワーク, ストレージ、CPU、メモリ、冷却方式を含め、実際の施設電力を推定する必要がある。
  2. PUEを保守的に見積もる。液冷を適用する場合でも、運用初期には理想的な数値が出ないことがある。電力の設計は楽観的に行ってはならない。
  3. 首都圏の立地が必ず必要なワークロードと、地方に送ることができるワークロードを分ける。大規模な学習は電力条件が良い地域に送り、低遅延の推論はユーザーに近い場所に配置するようなハイブリッド構造が必要である。
  4. 電力の接続可能時期をGPUの導入スケジュールと合わせて確認する。GPUが先に導入され、電力が後から準備されれば、資産が眠ることになる。逆に電力を確保してもGPUが遅れれば、データセンターの投資効率が低下する。
  5. 系統に優しい運用を考慮する。AI学習作業は時間シフトが可能な場合が多い。電力ピーク時間帯を避ける、地域間でワークロードを移動する、UPSやESSを活用して系統の負担を軽減するなどの方法が今後重要になる。

結論:AIインフラは今や電力産業である

韓国の26万台GPU計画は、AI産業の機会であると同時に、電力インフラの限界を露呈した事例である。この問題を「韓国にデータセンターがない」という風に単純化してはならない。韓国にはすでにデータセンターがある。しかし、26万台規模の新規AI GPUを高密度かつ安定して運用するには、従来とは異なる規模の電力インフラが必要である。

核心は、電力の総量よりも位置と時間である。必要な場所に、必要な時点で、必要な品質の電力を供給できるかどうかが、AI競争力の核心になっている。

韓国はNVIDIA GPUの確保を機に電力のボトルネックを急速に認識しつつある。日本はデータセンターの電力 demand 増加を長期的なエネルギー政策、PUE規制、原発建て替えの議論と結びつけて見ている。アプローチは異なるが、結論は同じだ。

これからのAI競争は、GPUの競争であると同時に、送電網の競争である。 GPUを確保できる国は増えるかもしれない。 しかし、そのGPUを安定して稼働させるための電力と送電網を持つ国は限られるだろう。

したがって、AIインフラを計画する企業や国家は、今から電力を見るべきである。後から考慮すればいい付帯条件ではなく、GPUを導入する前に確定しておくべき核心条件である。

コメント

このブログの人気の投稿

面倒くさいORACLEの文字化け状況

ORACLEはそもそもUTF-8をサポートしてほかの言語はサポートはしているって書いてますが親切ではないようです。 現在サーバー側は昔からUS7ASCIIに設定して日本語を入れてしまい、データは7ビットASCIIモードで読み取りながら日本語のコートがOS側とクライアント側で変換しない必要があります。 クライアント側で文字化けの解決にはNLS_LANGの設定が効くクライアントが必要ですが、一部の有料クライアントにはサポートするようです。 接続構造は参考に https://www.oracle.com/technetwork/jp/content/charcterset-250314-ja.pdf の19スライドのように クライアントからNLS_LANGをUS7ASCIIに設定しても その設定した言語にもらったUTF-8のデータをクライアントが変換すると NLS_LANGを設定しても意味がないようです。 ORACLE SQL Developerがこの様です。 ODBCと直接接続は必ずUTF-8に変換してしまうのでUS7ASCIIになっているDBからはクライアントをいくら変換しても文字化けのままです。 必ずOCI接続を通じてクライアント側から読み取らないとUS7ASCIIは勝手に変換されますね。 この全ての条件が満たした無料クライアントはA5mk2の2.9.1バージョンだけですね。 A5MK2 ver.2.9.1 : https://a5m2.mmatsubara.com/download/a5m2_2.9.1_x64.zip 2.9.1 バージョンでサーバーを設定する場合Uicode変換を強制に無視するオプションがあります。 多分このバージョンの時点ではUTF-8をメインにして設計したDBが少なかったから文字化け対応のためできたオプションでしょう。 しかし、A5mk2の新しいバージョンにもまた結果の変換をしないオプションがなくなって文字化けしてしまいます。開発者はもうUTF-8ではないDBはないと思ってるでしょう。まだまだ残ってますよ~。 クライアント側からの変換などに参考になればと思います! まだ直接お仕事になさってますか? もう遅いです!ソフトウェアロボットにお仕事を任せてどの位自分の作業分量が減ってるかをご確認ください! https://talklowy-jp.b...

コピペができないときチェックすべきこと! :: よく迷うUiPathのコツ

UiPath( https://uipath.com )はMicrosoft社のWWFを改良した製品なのでVisual Studioより初心者向けに使いやすくなっている。 しかし、初心者がそのまま使うにはかなりのハドルがある。 理由は基本開発者向けの開発ツールを無理やり便利に作ってみたとしても開発の概念と考え方がないと結構躓くことが多い。 そのなかで私もよく迷ったりしていることの一つを整理しとく。 基本Activityはすぐコピぺができるので多数のUiPath Studioを開いて開発してたりする。 ここでコピペをしても反応ないときがよくある。 この場合はこれをチェックすること! 1.Sequenceがなく一つのActivityしかないところにはペーストできないのが多い。 例えば、ifの処理ボックスにはSequenceが最初はない。 そのボックスに一つのActivityはペーストできるのに2個目からはなぜか反応ない。 それで分からないまま新しいActivityを追加してたりしたが、 あそこにSequenceを入れたら解決ができるのだ! 2.正常にペーストできるはずのところに反応ない。 この場合はPackageが合わなくペーストが効かないケースが多い。 DESIGN>Manage Packagesをクリックしてコピー元のパッケージにインストールされているのにコピー先にインストールされてないパッケージを探す! パッケージを一々見るのが難しい!と思ったら メモ帳からファイルがあるフォルダにあるproject.jsonファイルを開いてみる! あそこにJSONの形式でインストールされたパッケージが見えるので比較しやすくなる! ちなみにコピペをすると変数の宣言が大変だと思うが、 そこでもコツがあるのだ! 変数の宣言はなるべく細かくしてSequence単位で管理できるようにする。 全てに影響がある変数はしょうがないから一番広く宣言するけど。 初心者向けの説明だと、 Variablesというところをクリックして変数を開いたらScopeという範囲が見える! 大体Sequenceボックスの名前を変えてないのでSequenceがすらりと表示されてるはずが、Sequenceボックスの名前を付けてたら見やすくなる。 あ...

UiPath - Excelのシート名が存在した場合の処理

UiPath.Excel Activityは活用方法によってかなり強力ですが、隠れて探せない項目が多すぎて困ったりします。 公式ドキュメントもいまいちだし…。 Excelを自動化するには協力なUiPathの機能の中でSheetの判断処理を残します。 今まではシートがあったら何とかしようとしたら見つける方法が分からなく、ErrorのExceptionで判断したりしましたが、 workbook.GetSheets.Contains("<sheet name>") があったのをいまさら見つけました; 早速試してみましたが、 messageboxにworkbookとか書いてみても出てこない…。 これはExcel Application Scopeを利用しなければなりませんでした! まずExcel Application ScopeにExcelファイルを登録! Excel Application Scope Activityの属性にOutputにwbを入力して変数に入れます。 変数に入れてからMessageBoxに wb.GetSheet.Contains("Sheet1") を入力してみると成功! 「wb.」をおした時点でいっぱい出てきましたね。 ググってみても詳しく出て着なかったのでここにまず記録 giip - Free UiPath and Rpa Integrated Orchestration Service https://giipasp.azurewebsites.net