ネオクラウド最前線――AIの自己改善時代、計算資源市場で何が起きているのか
エージェント・データ基盤 AIモデル・知能 AIインフラ・産業 考察・仮説
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.10.21.2
- 記事内容のSHA-256
426bbf1e990481c32c6af814a4addd41476ae4ff21a5f5da6e685d371f6b161a- 保存版のSHA-256
0c90598774b44191d4e59e14c80fcbd800967c3baf5d9fd7b84cdab5de9d5b43
外部証明の最終検査結果は詳細を開くと表示します。
ネオクラウド最前線――AIの自己改善時代、計算資源市場で何が起きているのか
#異常な社債利回り、巨額の設備投資、急成長する売上。CoreWeaveとNebiusの技術、強化学習の先行研究、そして次世代AI Factoryの競争構造を読み解く。
#2026年10月17日
#はじめに――ネオクラウドという奇妙な市場
#ネオクラウドの社債が、異常な利回りで取引されている。
#2026年10月16日のReutersによると、CoreWeaveの一部社債の流通市場利回りは15～16%程度まで上昇した。（Reuters：CoreWeaveの社債・資金調達問題、2026年10月16日）
#正確には、すべての社債がこの利回りで新規発行されたわけではない。既発債の価格下落によって、流通利回りが大幅に上昇したのである。
#それでも、信用市場がこの企業の資金調達と返済能力に対して、非常に高いリスクを織り込み始めていることは確かだ。
#一方で、そのCoreWeaveの事業は急速に拡大している。
#2026年第2四半期の売上高は約25.8億ドル。前年同期から約2倍へ拡大し、受注残高は1,042億ドルに達した。（CoreWeave：2026年第2四半期決算）
#しかし同じ四半期に行った設備投資は、約94億ドル。
#さらに2026年通年の設備投資見通しは350億～390億ドルに引き上げられた。
#Nebiusでも、2026年第2四半期の売上高は約5.82億ドルとなり、前年同期比454%の成長を記録している。（Nebius：2026年第2四半期決算）
#売上が異常な速度で増えている。
#しかし、その成長を実現するための資金需要もまた、異常な速度で増えている。
#この企業群は、果たして将来その借入を返済できるのだろうか。
#もちろん、それは誰にも確定できない。
#将来のモデル性能、計算単価、GPUの更新速度、電力設備の供給、顧客の継続的な支出、金融環境によって結果は変わる。
#しかし、将来の株価や倒産確率を当てることより、ずっと有益なことがある。
#今、足元ではどのような計算需要が発生しているのか。どこに技術的なボトルネックがあり、それを解決するために企業は何を開発しているのか。そして、どのような構造へ市場が進んでいるのか。
#こちらは公開情報から、かなり具体的に調べることができる。
#特に興味深いのは、AIが強化学習、エージェント、継続的な改善、そしてAI自身による研究開発へ進むことで、計算資源に求められる機能が変化していることである。
#GPUを大量に並べるだけでは、もはや十分ではなくなりつつある。
#今回はCoreWeaveとNebiusを中心に、両社のクラウド製品の中身、その技術的な役割、先行研究との対応、クラスタ運用能力、SemiAnalysisの評価、OpenAIとAnthropicの内製化を整理する。
#そして最後に、カスタムチップやEDAツールで起こり始めているような、設計・実行・検証・改善の循環そのものが競争優位性になる構造が、ネオクラウドにも形成されているのではないかという問題を考えていく。
#第1章 ネオクラウドは、何を販売しているのか
#1-1. GPUを保有している企業が、すべて同じ事業をしているわけではない
#最初に、ネオクラウドの事業を区別しておきたい。
#一般にネオクラウドとは、AI向けのGPU計算資源を中心に提供する新興クラウド事業者を指す。
#しかし、同じAIインフラ企業でも、実際に販売しているものは異なる。
#例えばApplied Digitalは、GPUクラウドを高度化することよりも、巨大なGPUシステムを安定稼働させるための施設を建設・提供する事業に重点がある。
#一方CoreWeaveやNebiusは、GPUを利用するためのソフトウェアやネットワーク、ストレージ、ジョブ管理、推論環境まで提供する。
#したがって、これらの企業をGPU保有台数や契約MWだけで比較することは適切ではない。
#どこで付加価値を生み出しているのか、どの部分が顧客にとって代替しにくいのかを分ける必要がある。
#1-2. 何が変わり始めているのか
#これまでのAI計算需要は、大きく二つに分類できた。
#一つは巨大なモデルを作るための学習。
#もう一つは完成したモデルを利用するための推論である。
#しかし、現在はこの二つの境界が曖昧になり始めている。
#AIエージェントが実際の仕事を行い、その結果から学習する。
#学習したモデルを再び実行し、さらに新しい結果を収集する。
#モデルを本番環境へ配備した後も、推論、観測、評価、データ整備、再学習、検証が継続する。
#つまり、AIは完成したモデルを動かすだけでなく、動かしながら改善していくシステムになりつつある。
#この変化が、ネオクラウドの製品開発と直接つながっている。
#第2章 強化学習の基本――Rollout・Trajectory・Trainer・Sandbox
#ここから技術の中身へ入る。
#まず、強化学習の計算基盤で何が行われているのかを整理する。
#2-1. Rolloutとは何か
#Rolloutとは、現在のAIモデルに課題を解かせ、その試行と結果を収集する処理である。
#例えばプログラミングAgentへ、「あるソフトウェアの不具合を修正してほしい」と依頼したとする。
#Agentはコードを読み、修正案を考え、ファイルを書き換え、テストを実行する。
#テストに失敗すれば、エラーを確認して再びコードを修正する。
#これを何度も繰り返し、最後に不具合を修正できたか判定する。
#この一連の試行がRolloutである。
#そして、その試行中に発生した状態、行動、ツールの出力、モデルの生成Token、最終結果などを記録したものが Trajectory（軌跡・経験データ） である。
#通常のチャットでは、一回のモデル呼び出しで処理が終わる場合も多い。
#しかしエージェントでは、一つのTrajectoryの中でモデルが何十回も呼び出されることがある。
#その間に外部API、ファイル操作、検索、テスト環境などが実行される。
#つまり、Rolloutは単純なトークン生成ではない。
#モデル推論と実行環境が交互に動き、最終的な結果を出すまでの複合処理なのである。
#2-2. Sandboxとは何か
#Sandboxとは、AIが生成したプログラムや操作を、隔離された環境で安全に実行するための仕組みである。
#例えば、Agentが誤って重要なファイルを削除するコマンドを生成したとしても、その影響を隔離環境内に閉じ込める。
#強化学習では、同じ課題に対して何百・何千というRolloutを並列実行することがある。
#そのため、一つのSandboxを使い回すだけでは足りない。
#大量の隔離環境を起動し、各Agentが作業を行い、結果を保存し、環境を初期化する必要がある。
#ここで使われる計算資源はGPUだけではない。
#コードの実行、テスト、依存ライブラリのインストール、ファイル操作では、CPU、DRAM、SSD、ネットワークが重要になる。
#したがって、GPUのToken生成速度が高速でも、Sandbox側が遅ければ学習全体が進まない。
#これが、最近のAgentic RLでCPUとGPUの混合計算が注目される理由である。
#2-3. Trainerとは何か
#Rolloutで経験を収集したら、次にモデルを改善する。
#その役割を担うのがTrainerである。
#Trainerは収集したTrajectoryと報酬を使用し、モデルの重みを更新する。
#例えば、同じ課題に対して複数のRolloutを生成し、成功したものと失敗したものを比較する。
#GRPOなどの手法では、グループ内の報酬差から相対的なAdvantageを計算し、出力確率を調整する。
#ここで重要なのは、Rollout中に行動しているモデルと、重みを変更しているTrainerが、異なる計算環境で動いている場合があることだ。
#Trainerの更新にはForward、Backward、Optimizer処理が必要である。
#大量の重み、勾配、Activation、Optimizer状態を保持し、複数GPU間で通信する。
#そのため、推論とは異なるメモリ容量と通信性能が必要になる。
#2-4. 一つの強化学習サイクル
#基本的な流れは次のようになる。
#現在のモデル → Rollout生成 → Sandbox実行 → Trajectory収集 → Reward評価 → Trainer更新 → 新しいモデル → 次のRollout
#ここに、学習アルゴリズムとは別の技術的な問題が生まれる。
#例えばRolloutの生成に10分、Trainerの更新に6分かかるとする。
#同期式であれば、単純化すると一回の反復に16分かかる。
#しかし、RolloutとTrainerを異なるGPUで並行実行できれば、定常状態では遅い方の工程が全体の周期を決めるようになる。
#概念的には、
#と表現できる。
#もちろん、実際にはデータ転送、待機、重みの鮮度、Jobの失敗、評価時間なども関係する。
#それでも、この式は重要な意味を持つ。
#Rolloutを高速化したとしても、今度はTrainerがボトルネックになる可能性がある。
#逆にTrainerを高速化すれば、今度はRolloutが不足するかもしれない。
#ネオクラウド各社の技術開発は、まさにこのようなボトルネックの移動に対応している。
#第3章 先行研究から見る、強化学習インフラの進歩
#現在のCoreWeaveやNebiusの技術は、突然生まれたものではない。
#2024年から2026年にかけて、強化学習の実行基盤に関する研究が集中的に進んでいる。
#ここでは特に重要な研究を取り上げる。
#3-1. HybridFlow――学習と推論を効率よく接続する
#2024年9月に公開された HybridFlow: A Flexible and Efficient RLHF Framework は、大規模RLHFの実行効率を改善する研究である。
#学習と推論では、モデルをGPUへ分散配置する方法が異なる。
#そのため、同じモデルの重みを推論用配置と学習用配置の間で変換する際に、通信とメモリの負担が発生する。
#HybridFlowは、計算とデータ依存関係を分離して管理し、3D-HybridEngineによってモデルの再配置を効率化した。
#対象実験では、既存方式に対して1.53～20.57倍のスループット改善を報告している。
#非常に大きな差があるのは、比較したアルゴリズムと環境が異なるためであり、一般的な学習が20倍になるという意味ではない。
#この研究は、オープンソースのRL基盤であるverlへ接続されている。
#3-2. AReaL――RolloutとTrainerを非同期化する
#2025年5月公開の AReaL: A Large-Scale Asynchronous Reinforcement Learning System for Language Reasoning は、今回のテーマで特に重要な研究である。
#従来の同期式では、すべてのRolloutが完了するまでTrainerが次の更新を始められない。
#特に一つの長いTrajectoryが残っていると、ほかのRolloutが終わっていても全体が待機する。
#AReaLは、Rollout WorkerとTrainer Workerを分離し、経験生成と学習更新を非同期に実行する仕組みを導入した。
#これによってGPUの待機時間を減らせる。
#ただし、非同期化には新しい問題がある。
#Trainerがモデルを更新しても、Rollout側が古いモデルの重みを使用している可能性があることだ。
#これを Policy Staleness（方策の古さ） という。
#古いPolicyで生成された経験を使い続けると、学習効率や安定性が低下する場合がある。
#AReaLはこの問題を制御しながら、同数GPUによる同期式の比較対象に対して最大2.57倍の高速化を報告した。
#重要なのは、非同期化するだけでは不十分であり、どれくらい古い経験を許容して学習するかを制御する必要があることだ。
#3-3. WAR――Rolloutの高速化はGPU負荷によって方法が変わる
#2026年7月の WAR: Workload-Aware Rollouts for Synchronous Agentic Reinforcement Learning は、Rollout生成を直接高速化する研究である。
#WARが示した重要な点は、最適な推論高速化方法がGPUの混雑状態によって変わることだった。
#負荷が低い場合は、SuffixDecodingを利用する。
#これは過去のTrajectoryから、次に続きそうなToken列を候補として利用する方式である。
#追加のDraft Modelを必要としないため、余剰計算能力を使いやすい。
#一方、GPU負荷が高い場合は、KVキャッシュを意識したスケジューリングの方が重要になる。
#大量のリクエストを処理しているときに、投機的デコードを追加しても必ずしも効率が上がらないからだ。
#WARはこの二つを負荷に応じて切り替え、対象実験で低負荷時1.4倍、高負荷時最大1.6倍のRolloutスループット改善を報告した。
#この研究は、NebiusのToken FactoryやCoreWeaveの推論ルーティングと強く接続する。
#3-4. Tree Training――同じ文章を何度も学習しない
#Rolloutの効率化だけではない。
#Trainer側にも、大きな重複計算が存在する。
#例えば同じPromptから16件のRolloutを生成する場合、各Trajectoryには共通のPrefixが含まれる。
#通常の学習では、その共通部分を複数回計算することになる。
#2025年11月の Tree Training: Accelerating Agentic LLMs Training via Shared Prefix Reuse は、共通部分を木構造として扱い、ForwardとBackwardの両方で再利用する方式を提案した。
#これにより、対象実験で総学習時間を最大3.9倍短縮した。
#単に計算結果を使い回すだけでなく、共有した部分について勾配を正しく伝播させる必要がある点が重要である。
#3-5. psRL――ボトルネックがTrainer側へ移る可能性
#2026年8月に公開された psRL: Efficient Training for Agentic AI via Training-Time Prefix Sharing は、さらに興味深い問題を扱っている。
#著者らは、Agentic RLにおいてボトルネックがRolloutからTrainer更新へ移りつつあると指摘した。
#Tree構造やStep-wise RLによって、以前より効率よく学習サンプルを生成できる場合がある。
#しかし大量のTrajectoryを作れるようになると、今度はそれらをTrainerが処理する工程が遅くなる。
#psRLは、分散GPU環境で共有Prefixを再利用しながら、GPU間の負荷分散とKVキャッシュ管理を最適化する。
#対象のProduction Traceを使った評価では、既存方式に対して最大5.2倍のスループット改善を報告した。
#ただし、これは研究上の結果であり、すべての強化学習でTrainerが律速になっているという意味ではない。
#3-6. Agent LightningとProRL Agent――Rollout自体を独立したサービスへ
#さらに重要なのが、エージェント実行環境と学習基盤を分離する研究である。
#Microsoft ResearchなどによるAgent Lightningは、既存のAgentプログラムを大幅に書き換えずに、RL学習へ接続できる仕組みを提案した。
#また2026年3月公開のProRL Agentは、Rollout生成そのものを独立したAPIサービスとして扱う。
#Trainerは必要なTrajectoryを要求し、実際のモデル推論、Sandbox、環境管理はRolloutサービスが実行する。
#これは、ネオクラウドが単なるGPU時間ではなく、学習に使用できる経験データを生成するサービスを提供する未来と接続する。
#ProRL Agent（Microsoft Research）
#3-7. 先行研究から見えてくるもの
#これらの研究を並べると、変化の流れが見えてくる。
#重要なのは、ある工程が改善されると、別の工程が新たな制約になることだ。
#そして、この複数のボトルネックをまとめて解決する方向へ、CoreWeaveとNebiusが進んでいる。
#第4章 CoreWeave――AIの改善サイクル全体を取り込む
#CoreWeaveの戦略を理解するうえで、最も重要な製品がForgeである。
#2026年9月30日、CoreWeaveはAI開発基盤 CoreWeave Forge を発表した。（CoreWeave Forge）
#Forgeの基本的な考え方は、モデルやAgentの実行結果を、そのまま次の改善へつなぐことである。
#従来のAI開発は、学習、評価、配備、本番推論という順序だった。
#しかしAgentの時代には、本番環境に配備した後も、実際の仕事から多くの失敗・成功データが生まれる。
#その情報を分析して、次のモデルを改善する。
#Forgeはこれらを、一つの連続したワークフローに統合しようとしている。
#4-1. Forgeの構成
#Forgeの中心的な流れは次のとおりである。
#Run → Observe → Curate → Improve → Evaluate → Repeat
#Runでは、モデルやAgentを実行する。
#Observeでは、Agentの行動、Tool Call、遅延、失敗などを記録する。
#Curateでは、収集したデータを学習・評価へ利用できる形に整える。
#ImproveではSFT、RL、Distillationなどによってモデルを改善する。
#Evaluateでは新旧モデルを比較し、改善が本当に成立したかを検証する。
#最後に新しいモデルを再び配備する。
#このループ全体を支えるのがForgeである。
#4-2. Weights & Biases――研究実験の履歴を管理する
#CoreWeaveが買収したWeights & Biases（W&B）は、AI研究の実験管理に強みを持つ。
#モデルの学習率、Batch Size、Optimizer、Loss、評価結果、Checkpoint、使用したDatasetなどを対応付けて記録する。
#例えば実験Aより実験Bの性能が高かった場合、何を変更したから改善したのかを追跡できる。
#これは単なるDashboardではない。
#研究者が何度も実験を繰り返す際、その履歴を再利用する基盤である。
#Forgeへ統合されることで、研究結果と実際の本番Agentの評価を接続できるようになる。
#4-3. Agent Lens――本番Agentの失敗を分析する
#Agent Lensは、Agentの実行履歴をTraceとして記録し、失敗原因を分析する製品である。
#例えばプログラミングAgentであれば、ファイル検索、コード生成、Tool Call、Sandbox実行、テスト失敗などを調べる。
#重要なのは、失敗を分類し、評価データセットへ変換できることだ。
#同じ問題が繰り返し発生しているなら、モデルの再学習が必要なのか、検索方法やHarnessを変更すべきなのかを検討できる。
#ただしAgent Lensは、危険な操作を必ず実行前に遮断するセキュリティ境界そのものではない。権限制御、隔離、監査は別途必要になる。
#4-4. ART・Serverless RL――RolloutとTrainerを管理する
#CoreWeaveには、Agent Reinforcement Trainer（ART）というRLフレームワークがある。
#ARTはAgentのRolloutを生成し、報酬を計算し、Trainerへ渡してモデルを更新する工程をつなぐ。
#Serverless RLでは、Rollout用GPUと学習用GPUを分離し、それぞれの計算を効率よく動かせる。
#CoreWeaveは特定の比較で、自己管理の学習環境に対して約1.4倍の学習速度と最大40%の費用削減を報告している。
#これには、複数の学習Jobで共有するGPUプールを効率的に利用する効果が含まれる。
#ただし、すべてのRLで1.4倍の改善になるという意味ではない。
#4-5. AOM――Trainerの計算自体を高速化する
#2026年6月、CoreWeaveは ART-Optimized Megatron（AOM） を公開した。
#この技術は、先ほどのTree TrainingやpsRLと強く接続する。
#複数Trajectoryに共通するPrefixを再利用し、Trainer側の重複計算を削減する。
#さらにAttention KernelやSequence Packing、並列化を最適化する。
#CoreWeaveは、旧Unsloth Backendとの特定比較で、Training Stepの処理量を最大12倍に改善したと報告している。
#また、共有Prefixによる処理量改善は約6.8倍と報告されている。
#ただし、比較条件やLoRAの実装方式が異なるため、12倍と6.8倍を単純に掛け合わせることはできない。
#AOMが重要なのは、単にGPUを増やすのではなく、Trainerが無駄に実行していた計算を削減していることだ。
#4-6. RL Rollouts――新しい重みを止めずに反映する
#2026年10月5日、CoreWeaveはRL Rolloutsの詳細を公開した。
#Trainerがモデルの重みを更新した後、推論環境へ新しいCheckpointを反映する必要がある。
#従来はモデルの再デプロイに時間がかかり、その間にRollout生成が停止する場合があった。
#RL RolloutsはNVIDIA DynamoとvLLMを利用し、実行中の推論環境へ新しい重みを反映する。
#Checkpoint全体に加え、差分更新にも対応する。
#NVIDIA、you.comとの共同実験では、Checkpoint反映を従来の再デプロイ方式と比べて約15倍高速化したと報告している。
#これはモデルのToken生成が15倍になったという意味ではない。重みの反映工程に関する改善である。
#2026年10月時点ではPreviewであり、商用環境のあらゆるモデルで検証済みというわけではない。
#CoreWeave：Closing the Inference to Post-Training Loop
#4-7. Sandboxes――Agentの実行環境を大規模に供給する
#CoreWeaveは、Agentのコード実行や検証に使用するSandboxesも提供している。
#この製品では、大量の隔離環境を並列に起動できる。
#IBM Researchによる数千Sandbox規模の利用事例や、MistralによるGPU学習とCPU Sandboxの併設事例が紹介されている。
#これはAgentic RLの新需要と直接接続する。
#モデル推論を高速化するだけではなく、推論の結果として発生するコード実行や環境操作を、低コストで大量に処理する必要があるからだ。
#第5章 SUNKとMission Control――CoreWeaveの本当の基盤は、GPU運用そのものにある
#ForgeはAI研究開発の改善基盤だが、その下には巨大な計算設備を運用するシステムが存在する。
#その中核がSUNKとMission Controlである。
#5-1. SUNK――SlurmとKubernetesを統合する
#SUNKは Slurm on Kubernetes の略である。
#Slurmは大規模学習やHPC向けのジョブ管理に強く、Kubernetesはコンテナ化されたサービスの配備・管理に強い。
#SUNKはこの二つを組み合わせる。
#これによって、巨大なTrainer Job、Rollout用推論サービス、CPU Sandbox、評価サービスなど、性質の異なる計算を管理しやすくする。
#特に大規模学習では、どのGPUを一つのJobへ割り当てるかが重要になる。
#MoEモデルではGPU間通信が多く発生し、ネットワークトポロジーによって性能が変わるためだ。
#SUNKはGPUの接続関係を考慮したジョブ配置や、優先度・ライフサイクル管理に対応する。
#ただし、SUNK自身がRLアルゴリズムを高速化するわけではない。
#WARやAOMが高速化した計算を、実際の大規模クラスタで効率よく動かすための基盤である。
#2026年4月にはSUNK Self-ServiceとSUNK Anywhereの機能拡張が発表され、CoreWeave以外のクラウド環境でもSUNKを利用する方向が進んでいる。
#5-2. Mission Control――計算設備そのものを観測・修復する
#Mission ControlはGPUクラスタの監視・診断・運用基盤である。（CoreWeave Mission Control）
#GPU、ネットワーク、ストレージ、ラック、冷却、電力設備などの状態を取得する。
#特に大規模学習では、完全に故障したGPUだけでなく、正常に動いているように見えて実際には遅くなっているGPUが問題になる。
#このようなGPUをStragglerと呼ぶ。
#同期学習では遅いGPUを待つ必要があるため、一部の性能低下がJob全体の速度に影響する。
#Mission Controlは、こうした異常を検出し、原因を調査する。
#さらにCoreWeaveは、内部のPerformance Lakeへ複数Jobの性能データを蓄積している。
#ここには、設備の正常な状態と異常な状態を比較するための知識が蓄積される。
#この部分については後ほど詳しく取り上げる。
#5-3. ラック全体をソフトウェアで制御する
#CoreWeaveはさらに、ラックそのものを管理する製品を開発している。
#Valveyは液冷の流量、温度、圧力、漏水などを監視・制御する技術。
#Rackyは電源、冷却、各種センサーを統合するラック管理基盤。
#RLCCはラックのファームウェア、構成、健全性、運用・復旧を管理する。
#重要なのは、GPU、ネットワーク、冷却設備を別々の機械ではなく、一つのプログラム可能な計算システムとして扱っていることだ。
#次世代のVera Rubinのようなラックスケールシステムでは、このような技術が重要になっていく。
#第6章 Nebius――推論の内部にあるボトルネックを一つずつ取り除く
#CoreWeaveが開発・学習・評価・改善の循環全体を統合する方向へ進んでいるのに対して、Nebiusは推論の実効効率を高度化する製品投資が際立っている。
#ただしNebiusも大規模学習を提供しており、推論専業というわけではない。
#違いは現在の技術投資で特に重視されている部分である。
#6-1. Token Factory――推論を実用的なサービスへ変える
#Nebius Token Factoryは、オープンモデルをAPIや専用エンドポイントで利用するためのマネージド推論サービスである。
#単にモデルをGPUへ読み込むだけではない。
#リクエストのルーティング、Batching、KVキャッシュ管理、量子化、推論Kernel、動的スケーリング、監視などを組み合わせている。
#ここでNebiusは、異なる階層の最適化技術を取り込んでいる。
#6-2. Eigen AI――モデルとKernelを最適化する
#2026年6月に買収を完了したEigen AIは、モデル・推論Runtimeの最適化に強みを持つ。
#量子化、Attention Kernel、Sparsity、投機的デコードなどを利用し、GPUの実効性能を高める。
#これらを独立した機能ではなく、モデルとGPUの構成に応じて調整できることが重要になる。
#量子化でメモリ転送を削減しても、Kernelが非効率なら必ずしも速度は上がらない。
#投機的デコードも候補Tokenの採択率が低ければ、追加計算の負担が大きくなる。
#そのため、低レベルのモデル最適化とServingシステムの統合が重要になる。
#6-3. ClarifaiとInferize――GPUが待つ時間を減らす
#Nebiusは2026年5月、Clarifaiの中核チームを迎え、推論・計算資源オーケストレーション技術のライセンスを取得した。
#Clarifai全社を買収したわけではない。
#さらに10月1日にはInferizeの買収を発表した。（Nebius：Inferize買収）
#Inferizeが重視するのは、巨大モデルのCold Startと動的スケーリングである。
#モデルを新しいGPUへ配置する際には、重みの読み込みやRuntimeの初期化に時間がかかる。
#その間GPUは十分なトークンを生成できない。
#NebiusはInferizeを統合することで、モデル起動・Scale-out・学習時の重み更新に伴う待機を減らそうとしている。
#ただし、2026年10月時点でInferizeの技術がToken Factoryのすべての環境に完全統合され、どれだけ費用を削減したのかまでは確認できない。
#6-4. KVキャッシュRouting――同じGPUでも性能が変わる
#Nebiusが公開した2026年2月の実験は、非常に興味深い。
#3つのvLLMレプリカに対し、通常のKubernetes RoutingとKVキャッシュを考慮したRoutingを比較した。
#結果は次のとおりである。
#モデルもGPUも同じである。
#違うのは、次のリクエストをどのGPUへ送るかという管理方式だ。
#Agentは同じ文脈を何度も再利用するため、KVキャッシュが残っているGPUへ次のリクエストを送ることで、Prefillの再計算を減らせる。
#これは、GPUの演算性能を向上させずに、実効的な仕事量を増やせることを示している。
#ただし、通常のKubernetes Routingとの比較であり、最適化されたすべての競合Routingより優れていると証明したものではない。
#6-5. Soperator――Nebiusも大規模学習基盤を持つ
#NebiusにはSoperatorという製品もある。
#これはSlurmをKubernetes上で管理するためのOperatorで、2024年にオープンソースとして公開された。（Nebius：Soperator）
#Kubernetesによる構成管理と、Slurmによる大規模学習ジョブの管理を組み合わせる。
#特に特徴的なのが、共有root filesystemを使った環境管理である。
#複数ノード間のソフトウェア構成差異を抑え、研究者が同じ環境を利用しやすくする。
#また、NebiusはPapyraxというJAX/XLAベースの分散学習基盤も持つ。
#したがって、Nebiusは推論だけを行う会社ではない。
#大規模学習、Post-training、クラスタ管理まで対応できる。
#6-6. NebiusもAgentic RLのボトルネックへ踏み込んでいる
#2026年9月28日、Nebiusは In agentic RL, faster tokens are not enough という技術報告を公開した。
#この研究では、長時間のAgentic RLでTrainerが必要なTrajectoryを待ってしまう問題を分析している。
#GLM-5.2、B300 GPU 32基、Terminal-Bench系ワークロードを使用し、Rollout生成、Routing、Sandbox、Groupの完了順序を最適化した。
#固定された重みを使ったBatch収集試験では、256件のTrajectoryを揃える時間が591.8秒から196.1秒に短縮された。
#ただし、候補として投入するTrajectory数も512件から2,048件へ増加している。
#したがって同じ計算量で約3倍になったと理解するのは適切ではない。
#これは、余剰候補を生成して遅いTrajectoryを待たずに済ませる効果も含む。
#さらにNebiusは、更新したPolicyを推論側へ段階的に反映する方法も検証した。
#しかし、その検証はモデルの全重み更新とTrainerのBackward・Optimizer処理を含む完全なEnd-to-End RL学習ではない。
#この違いは重要である。
#それでも、Nebiusが推論の高速化だけでなく、Trainerへ有効なTrajectoryを供給する速度を改善しようとしていることは明確である。
#第7章 CoreWeaveとNebius――二社は異なる方向から同じ市場へ向かっている
#これまでの製品群を比較すると、両社の違いが分かる。
#CoreWeaveは、研究者が実験を設計し、Rolloutを生成し、Trainerで学習し、評価して配備するまでの工程を、一つの製品体系にまとめようとしている。
#Nebiusは、推論Kernel、KVキャッシュ、モデル起動、動的スケーリング、Routingなど、実行中のボトルネックを深く最適化している。
#しかし両社とも、相手の領域へ進出している。
#NebiusはAgentic RLの学習基盤を開発している。
#CoreWeaveも投機的デコード、推論最適化、Prefix Routingなどを開発している。
#したがって、長期的には「学習のCoreWeave」「推論のNebius」という単純な棲み分けではなくなる可能性が高い。
#両社は異なる入口から、継続的に学習・改善するAIを、どれだけ低コストで動かせるかという同じ問題へ向かっている。
#第8章 SemiAnalysisのClusterMAX 3.0は何を示したのか
#ここで第三者評価を見ておこう。
#2026年9月23日、SemiAnalysisは ClusterMAX 3.0 を公開した。
#同評価では77事業者を対象として取り上げ、市場全体では323事業者を追跡している。
#さらに200件超のネオクラウド利用者インタビューを実施した。
#評価項目には、GPU計算性能だけでなく、ネットワーク、ストレージ、Slurm、Kubernetes、ヘルスチェック、監視、サポート、セキュリティなどが含まれる。
#8-1. CoreWeaveとNebiusがPlatinum
#今回、CoreWeaveとNebiusの二社が最上位のPlatinum評価を獲得した。
#CoreWeaveは三回連続のPlatinumであり、SemiAnalysisは引き続き同社を技術的な基準を示す事業者として評価している。
#一方NebiusもGoldからPlatinumへ上昇した。
#Nebiusについては、Slurmのトポロジー認識、ヘルスチェック、ソフトウェア構成、監視などが高く評価されている。
#Synthetic Error Injectionでは、不健全なノードを自動復旧させる動作も確認された。
#ただし、対象のGB300ラックでは復旧まで約8時間40分を要している。
#この数字は、その試験条件での実測であり、Nebiusの全障害に共通する平均復旧時間ではない。
#8-2. 成熟度の違いを読む
#重要なのは、Platinum評価が同じだからといって、ForgeとToken Factoryの性能が同等だと判断できるわけではないことだ。
#ClusterMAXが主に評価しているのは管理型クラスタの品質である。
#RL PlatformやAgent Sandbox、推論API、学習・評価の改善サイクル全体については、同じ条件の総合比較ではない。
#またSemiAnalysisは、フロンティアラボのクラウド運用人材の高さにも注目している。
#OpenAIとAnthropicの求人のうち、職務説明にKubernetesを含む募集給与レンジを合算すると、約2,777万～4,269万ドルに達すると説明している。
#これはすでに支払われている給与総額ではない。
#既存社員の人件費、株式報酬、福利厚生なども含まれない。
#それでも、大規模AIクラスタの運用がどれほど高度な専門領域になっているかを示す数字である。
#中小AIラボが同じような運用チームを持つことは容易ではない。
#そこで、高品質なGPUクラスタを運用してくれるネオクラウドの価値が生まれる。
#第9章 OpenAIとAnthropicは、どこまでクラウドを内製しているのか
#ここはネオクラウドの将来を考えるうえで重要だ。
#OpenAIやAnthropicは、CoreWeaveのようなクラウドを利用している。
#しかし、そのことはクラウドの管理ソフトウェアまで全面的に外部委託していることを意味しない。
#9-1. OpenAIは複数クラウドを横断する管理基盤を内製している
#OpenAIの公式求人「Compute Foundations」には、かなり具体的な仕事内容が記載されている。
#複数のクラウド事業者、データセンター、GPU世代を横断して、計算資源を管理するKubernetesベースのControl Planeを開発している。（OpenAI：Compute Foundations求人）
#さらにBare Metalの起動、Firmware、Driver、設備の割当、アップグレード、復旧まで担当する。
#つまりOpenAIは、外部クラウドを利用するだけの企業ではない。
#自社の研究・製品に必要な計算環境を、複数事業者にまたがって制御するソフトウェアを開発している。
#9-2. Anthropicも独自Schedulerを開発している
#Anthropicの公式求人「Staff+ Software Engineer, Kubernetes Platform」では、独自Schedulerを保有し、数千のアクセラレータをまとめて配置するためのGang Scheduling、Topology-aware Scheduling、Kubernetes API Serverやetcdの大規模化を行っていると明記されている。（Anthropic：Kubernetes Platform求人）
#つまり、SUNKやSoperatorが提供する機能と重なる領域を、Anthropic自身も開発している。
#またAnthropicはAWS Trainium、Google TPU、NVIDIA GPUなど異なる計算基盤を組み合わせている。
#ここから読み取れるのは、巨大なフロンティアラボほど、研究アルゴリズムと計算基盤を共同最適化する必要があるということだ。
#9-3. ではCoreWeaveは何を担っているのか
#CoreWeaveはOpenAIと直接契約している。
#2025年9月の追加契約までを合計すると、OpenAIとの契約価値は最大約224億ドルに達する。
#さらに2026年4月にはAnthropicとも複数年契約を発表した。
#しかし公開情報からは、OpenAIやAnthropicがCoreWeaveのSUNK、Forge、ART、Mission Controlのどこまでを直接利用しているかは分からない。
#フロンティアラボが独自Schedulerを使用し、CoreWeaveがGPU・ネットワーク・物理設備に近い運用を担当する構造も考えられる。
#一方、契約によってはCoreWeave側がより広い管理範囲を担うかもしれない。
#重要なのは、計算設備の購入・契約と、クラウドの制御権限は別だということだ。
#OpenAIはCoreWeaveの計算資源を購入していても、研究・学習・配備を自社ソフトウェアで制御できる可能性がある。
#この分担は、個別契約の管理責任や権限が非公開であるため、確定できない。
#9-4. NebiusではMicrosoft・Metaとの関係が重要
#Nebiusが公開している大型契約の相手にはMicrosoftとMetaがいる。
#一方、OpenAIやAnthropicとの直接契約については、今回確認した公開資料では裏付けを得られなかった。
#MicrosoftはOpenAIとも関係があるため、Microsoft経由でNebiusの計算資源が利用される可能性は考えられる。
#しかし、MicrosoftがNebiusから購入したGPUでOpenAIのモデルを実際に動かしているという証拠はない。
#このため、NebiusのMicrosoft契約をOpenAI向け需要として計上すべきではない。
#同様に、GPUを購入した企業と、実際にそこでモデルを動かす最終顧客は区別する必要がある。
#9-5. フロンティアラボの内製化は、ネオクラウドの終わりを意味するか
#私は、必ずしもそうではないと考える。
#理由は、ソフトウェアの内製と物理的な計算容量の内製は異なるからだ。
#フロンティアラボがKubernetes、Trainer、推論Runtimeを自社開発しても、施設の建設、受電、GPU設置、液冷、部品交換、現地保守などのすべてを自社で行う必要はない。
#また、総計算需要が増加するなら、自社設備が増えても外部クラウドへの支出が増え続ける可能性がある。
#ただし、独自ASICや自社施設の比率が増えることで、ネオクラウド側の価格交渉力が低下する可能性はある。
#ネオクラウドにとっては、どの部分で顧客に不可欠な価値を提供できるのかが問われることになる。
#第10章 Astra級AIが登場すると、研究・開発の改善速度はどう変わるか
#ここからは、もう一段先の変化を考える。
#AI研究にAI自身が参加するようになると、モデルを改善する工程そのものが高速化される可能性がある。
#2026年9月に発表されたGPT-6 Astraでは、実際の研究コードのバグ修正、Kernelの最適化、Post-trainingなど、AI研究開発に関係する能力が評価されている。（OpenAI：GPT-6 Astra）
#例えばOpenAIの内部研究デバッグ評価では、Astraは41件の実際の研究課題に対して78.05%のスコアを記録した。
#これは研究開発全体の78%を自動化したという意味ではない。
#しかし、経験豊富な研究者が数時間から数日を要した問題の一部を、AIが解決できるようになっている。
#さらにOpenAIは2026年9月6日、社内での研究Agent利用が増加し、実験の設計・実行・分析にAIが深く関与していることを公表した。（OpenAI：Research acceleration）
#Anthropicも2026年8月時点で、ClaudeがAI研究開発タスクの26%で主導的な役割を担っていると報告している。
#ただし、同社は完全自律で研究を実行できていると説明しているわけではない。
#10-1. 二つの改善ループが接続する
#これまでのAI研究では、モデルを改善するループが中心だった。
#Rollout → Trainer → 評価 → 改善モデル
#しかし、AI自身が研究できるようになると、別のループが加わる。
#研究Agent → 仮説 → コード作成 → 実験 → 結果分析 → 新しい研究案
#この二つが接続すると、AIが研究方法を改善し、その研究によってさらに能力の高いモデルを開発するという循環が成立し得る。
#これは再帰的自己改善へ向かう経路の一つである。
#ただし、実際の研究能力が際限なく加速するという証拠があるわけではない。
#研究の品質、検証、計算資源、データ、ハードウェア、安全性などの制約は残る。
#10-2. ネオクラウドにとって何が変わるか
#高性能AIが研究コードを生成し、複数の実験を管理できるようになると、人間の研究者一人当たりの計算資源需要が増える可能性がある。
#従来なら一つの実験を行っていた時間で、十個の候補を試せるようになるかもしれない。
#一方、AIが研究計画をより上手に選択できれば、不要な実験を減らす可能性もある。
#つまりAIの性能向上は、GPU需要の増加要因にも減少要因にもなる。
#重要なのは、効率化によって新しく経済的に成立する研究・業務がどれだけ増えるかだ。
#そして、AI研究Agentの能力が向上するほど、大量のJobを実行し、結果を記録し、正しい評価を返す計算基盤の重要性も高まる可能性がある。
#これはCoreWeaveのForge、SUNK、ARIA、Mission Controlの製品構成と強く接続する。
#Nebiusでも、Eigen AI、Inferize、Papyrax、Token Factoryを使った推論・学習基盤の高速化が、同じ循環に貢献し得る。
#第11章 カスタムチップとEDAの協業に、次の堀のヒントがある
#2026年、OpenAIはBroadcomなどと共同開発した独自推論ASIC「Jalapeño」の性能を公開した。
#ここでは、実際のモデル推論で得られたワークロード特性をチップの設計へ反映し、ハードウェアとソフトウェアを共同最適化している。（OpenAI：Jalapeño・OpenAI：The full stack behind abundant intelligence）
#OpenAIはさらに、Synopsysとの協業も発表した。
#2026年9月30日のGPT-Synopsys提携では、OpenAIのフロンティアモデルと、SynopsysのEDAツール・設計専門知識を統合する。（Synopsys：OpenAIとのGPT-Synopsys協業）
#AIは設計案を生成するだけでなく、EDAツールを動かし、結果を解析し、次の改善案を作ることが期待されている。
#ここで重要なのは、AIが高性能になったからといってEDAツールが不要になるわけではないことだ。
#AIが多くの設計案を作れるようになるほど、その案が実際に成立するかを検証するためのツールが重要になる可能性がある。
#この構造を、ネオクラウドへ接続して考えてみたい。
#11-1. ネオクラウドにも、同じ種類のループが形成されている
#ネオクラウドは、GPUを設置した後に大量の実運用データを取得できる。
#GPUの温度、クロック、エラー、NVLink、InfiniBand、ストレージ帯域、冷却流量、電源状態、Firmware、Jobの成功・失敗などである。
#これらの情報を利用すれば、より高度な故障検出、配置、保守、ラック設計が可能になる。
#そして、その改善結果を次のGPU世代へ反映できる。
#つまり、
#設備導入 → 実運用 → 異常検出 → 原因分析 → 改善 → 次世代設備導入
#という循環である。
#ここには、半導体の設計・製造・検証ループと似た構造がある。
#ただし、同じ強さの独占性が生まれるとは限らない。
#KubernetesやSlurmはオープンソースであり、ハイパースケーラーも大量の運用データを持っているからだ。
#第12章 CoreWeaveが公開した、実際のAIによる設備運用改善
#2026年10月15日、CoreWeaveは非常に興味深い技術記事を公開した。
#Agents on live hardware: reason where you must, engineer everywhere else
#この内容は、まさに今回探していた、ネオクラウドの独自データとAIによる改善ループの具体例である。
#CoreWeaveは、データセンターから発生する約500万件/日の信号を処理し、故障の兆候を見つける仕組みを紹介している。
#しかし、すべての信号をLLMで直接判定するわけではない。
#12-1. AIが検出器を作り、検出器が本番で動く
#CoreWeaveは、AIエージェントを使って過去の故障データを調べ、特徴量を設計し、機械学習モデルや閾値を組み合わせた検出器を作成した。
#その検出器を、過去の確定した障害データで検証する。
#本番では、毎回LLMに判断させるのではなく、検証済みの決定的なプログラムを動かす。
#そして検出器が異常と判断した一部の事例だけを、AIエージェントと運用エンジニアが詳しく調査する。
#重要なのは、AIによる柔軟な分析と、再現性のある本番システムを分離していることだ。
#さらに、実際の物理設備に影響する判断には人間の確認を残している。
#この仕組みは、AI時代のセキュリティ研究で議論してきた、外部の権限制御・監視・監査とも接続する。
#12-2. 何が独自の堀になるのか
#この事例で重要なのは、AIエージェントそのものより、AIへ渡すことができるデータである。
#長年蓄積した設備の故障履歴。
#実際に故障を調査したエンジニアの判断。
#どの異常が本当に問題で、どれが誤検知だったのかという記録。
#修復した後に正常な性能へ戻ったのかという検証結果。
#これらを対応付けた情報は、単にGPUを購入しただけでは獲得できない。
#どのような条件で設備が壊れ、何をすれば復旧できるのかという実世界の知識である。
#CoreWeaveはMission Controlに長期のTelemetryを蓄積し、Performance Lakeや内部ナレッジベースと接続している。
#このデータをAIに分析させることで、次の検出器を改善できる。
#ここに非常に興味深い循環がある。
#AIが強くなるほど、運用データを分析する能力が向上する。
#しかし、そのAIへ渡す良質な実運用データは、誰でも簡単に取得できるわけではない。
#したがって、高性能AIの普及によってソフトウェアを作る費用が下がっても、実測・検証データを持つ事業者の価値は残る可能性がある。
#12-3. NVIDIA・サーバーメーカーとの改善ループ
#CoreWeaveは、GPU設備の検収段階でも独自技術を使用している。
#FLCCやNLCCを通じて、GPU、ネットワーク、Firmware、性能、障害などを検査する。
#さらにNVIDIAやサーバーメーカーと共同で、設備を本番投入する前に問題を発見する取り組みも公表している。
#ここでは、実運用で発見された問題が、次の診断・設計・製造検査へ戻される。
#これはOpenAIとBroadcomのような、チップ設計と実ワークロードの改善ループに近い。
#ただし、NVIDIA自身も多数のクラウド事業者から情報を得られる。
#したがってCoreWeaveが製造・設計データを独占できるわけではない。
#CoreWeaveの強みは、顧客向けの実運用まで含めた設備の検証・運用・修復能力を、継続的に改善できることにある。
#第13章 Nebiusにも独自の堀はあるのか
#Nebiusにも同じ種類の技術的な堀がある。
#Soperatorによるクラスタ管理だけではなく、GPUの品質検査、ヘルスチェック、障害ノードの隔離、復旧などを自社で開発している。
#またNVIDIAとの共同開発や、推論Runtimeの最適化技術を取り込むことで、低レベルから推論性能を改善する能力を高めている。
#しかしNebiusには、CoreWeaveと少し異なる将来戦略がある。
#2026年7月15日、Nebiusはインフラパートナー方式を発表した。
#これは、外部の事業者が土地、施設、GPUを保有・運営し、その上へNebiusのAIクラウドソフトウェアとサービスを導入するというモデルである。
#これが成功すれば、Nebius自身が設備のすべてを購入しなくても、サービス収益を得られる可能性がある。
#ただし、ここに別の問題も生まれる。
#外部パートナーの設備を管理する場合、誰がGPUの詳細Telemetryを保有するのか。
#誰が故障原因を調査し、その結果を次のクラウド改善へ利用できるのか。
#Nebiusが設備を保有していなくても、運用データと修復結果を十分に取得できれば、改善ループを維持できるかもしれない。
#反対に、物理設備の詳細な情報がパートナー側に閉じていれば、そのループは分断される可能性がある。
#つまり、資産軽量型クラウドにおける堀は、設備の所有権だけでなく、運用データへのアクセスと改善の実行権限に左右される。
#これは、今後のNebiusの技術・事業モデルを評価するうえで重要な観測点になる。
#第14章 ネオクラウドに残る堀を、三つに分けて考える
#ここまでの議論から、長期的な競争優位性は三種類に分けられる。
#第一：ソフトウェアの堀
#SUNK、Soperator、推論Runtime、実験管理、Trainer、Agent管理などである。
#現在は高度な専門技術が必要であり、研究開発費も大きい。
#しかし、Astra級AIによるコード開発・検証が進めば、ソフトウェアの一部は競合も再現しやすくなる可能性がある。
#そのため、単に優れたSchedulerを保有していることだけでは、永続的な差別化にならないかもしれない。
#第二：実運用データと検証能力の堀
#GPUの故障履歴、稼働特性、性能異常、修復結果、ラックの熱特性、ネットワーク問題などである。
#これらは実設備を稼働させ、長期間観測する必要がある。
#さらに、正しい原因・修復方法と対応付けて初めて価値が高まる。
#Astra級AIが進歩するほど、こうしたデータを使った改善を効率化できる可能性がある。
#つまり、実運用データの蓄積が、次の設備改善を加速する循環になる。
#第三：物理設備・顧客・制度上の堀
#電力接続、土地、データセンター、液冷、次世代GPUの調達、長期顧客契約、セキュリティ、主権AI対応などである。
#これらはAIが高性能になっても、コードを書く能力だけでは代替できない。
#もちろん、電力や土地にも永続的な独占性があるわけではない。
#しかし、設備を受電可能な状態にして、実際に稼働させるまでには時間が必要である。
#この時間差が、物理的な競争優位性になる場合がある。
#14-1. 最も深い堀は、三つを接続した場所に生まれる
#私が最も重要だと考えるのは、第二と第三の堀をソフトウェアが接続する部分である。
#単にGPUを大量に保有するだけではなく、実際の設備を管理し、故障を検証し、次の設計へ改善を反映できる。
#さらにその技術を別の施設や次世代GPUへ展開できる。
#この仕組みが成立するなら、ネオクラウドは単なるGPUレンタル企業ではなくなる。
#AI Factoryを設計・稼働・改善するための運用技術を保有する企業へ変化することになる。
#ただし、AWS、Google、Microsoft、Metaなどのハイパースケーラーも同種の運用技術と膨大なデータを持つ。
#そのため、CoreWeaveやNebiusの堀は、小規模なネオクラウドに対しては深くても、ハイパースケーラーに対して絶対的とは限らない。
#ここは慎重に評価する必要がある。
#第15章 巨大フロンティアラボの内製化と、ネオクラウドの新しい顧客市場
#OpenAIとAnthropicがクラウドの制御技術を内製化しても、ネオクラウドが不要になるとは限らない。
#ソフトウェアを自社開発しても、外部の電力・施設・GPUを利用する合理性が残るからだ。
#一方、クラウドを全面的に内製しない企業や研究所にとっては、完成度の高いAI計算基盤の価値が高くなる。
#ここには三つの有力な市場がある。
#15-1. 研究機関・大学・中小AIラボ
#大規模な研究組織でなければ、OpenAIやAnthropicと同じような専用インフラチームを保有することは難しい。
#SUNKやSoperatorのような管理型学習基盤は、研究者がインフラ構築に費やす時間を減らすことができる。
#また、Rollout、Sandbox、Reward、Trainerを一体で利用できれば、強化学習環境の開発負担も減らせる。
#15-2. 企業の独自AI基盤
#企業が独自データを利用してモデルを学習・運用する場合、推論だけでなく、評価、監査、権限制御、継続学習が必要になる。
#この場合、ネオクラウドはGPU時間だけでなく、企業向けのマネージドAI基盤を提供する立場になれる。
#ただし、既存のAWS、Azure、GCPとの競争は避けられない。
#企業のデータ、認証、アプリケーションをすでに保有するハイパースケーラーには、強い顧客基盤があるからだ。
#15-3. 主権AI・地域AI基盤
#国家や地域が、自国の法制度や管理権限のもとでAI計算基盤を運用する需要も考えられる。
#Nebiusは2026年9月、Palantirとの主権AI提携を発表している。
#Nebiusの計算・推論サービスを、Palantirの企業向け環境へ統合する構想である。
#ただし、主権AIとは国内にGPUを設置するだけではない。
#データの管理、法的管轄、暗号鍵、運用権限、外部からのアクセス、サプライチェーンまで関係する。
#この市場で勝つには、高性能なGPUだけでなく、企業・政府の信頼と継続的な運用能力が必要になる。
#第16章 計算資源の逼迫はいつまで続くのか
#最後に、需要と供給の問題へ戻ろう。
#2026年8月のCBRE調査では、北米主要8データセンター市場の空室率は1.4%だった。
#建設中の容量は約7.48GWで、その80.4%はすでに事前契約されている。
#これは施設容量の逼迫を示している。
#ただし、データセンターの空室率と、実際のGPUの稼働率は異なる。
#すでに借りられている施設でも、GPUが完全に設置・稼働しているとは限らない。
#また、最新世代GPUの供給が不足する一方、古いGPUには空きがある可能性もある。
#したがって、計算資源不足を一つの数字で判断することは難しくなっている。
#CBRE：North America Data Center Trends H1 2026
#16-1. AIの効率化は需要を減らすのか
#これは一概には言えない。
#例えば推論効率が2倍になり、同じ仕事量を半分のGPU時間で処理できるようになれば、必要な計算量は減る。
#しかし同時に、以前は費用が高すぎて成立しなかった用途が、新しく実行可能になる。
#AI研究Agentが増え、企業が大量のAgentを利用し、継続学習や評価が頻繁に行われるようになれば、総計算需要はむしろ増える可能性がある。
#一方、高性能モデルによって不要な実験や失敗が減るなら、計算需要は抑制される。
#重要なのは、モデルの効率改善率そのものではない。
#効率化によって、どれだけ新しい仕事と研究が経済的に成立するようになるかである。
#16-2. 設備建設は、ソフトウェアほど速くならない
#AIの研究・推論ソフトウェアは、数週間から数か月単位で改善される場合がある。
#しかし、データセンターの土地、受電、変圧器、液冷設備、建設、許認可には、年単位の時間が必要になる場合がある。
#そのため、計算需要が先に増えれば、施設の逼迫が長期化する可能性がある。
#一方、現在計画されている設備が数年後に一斉に完成すると、特定の地域やGPU世代では供給過剰になる可能性もある。
#需要があることと、すべての投資が回収できることは違う。
#第17章 Gartnerの警告と、ネオクラウドの投資回収
#2026年10月14日、GartnerはAIインフラ投資に関する厳しい予測を発表した。
#同社は、現在の設備投資ペースが続く場合、2030年末までに3.5兆ドル超のAIインフラ投資が減損リスクにさらされる可能性があると分析している。
#さらに、2030年までにネオクラウド事業者の80%超が独立した事業者としての運営を終えると予測している。
#これは将来の確定事項ではなく、特定の設備投資・収益予測に基づくシナリオである。
#独立運営の終了には、買収・統合なども含まれ得る。
#Gartnerは同時に、AI最適化IaaS市場が2027年の660億ドルから2030年の1,740億ドルへ拡大すると予測している。
#つまり、市場そのものは大きく成長しても、参加企業すべてが利益を得られるわけではないということである。
#17-1. どの企業が利益を獲得するのか
#ここまで分析した技術は、確かにクラウドの性能を改善する。
#しかし、その改善が企業の利益として残るかは別問題である。
#例えばCoreWeaveがSUNKによってGPUの実効稼働率を改善しても、顧客との契約が固定料金なら、改善効果の多くは顧客の学習時間短縮として現れるかもしれない。
#NebiusがToken Factoryを高速化しても、競争によってToken単価が大幅に低下すれば、売上成長へ直結しないかもしれない。
#逆に、ソフトウェア改善によってGPU当たりの処理量が増え、空いた容量を別の顧客へ販売できれば、利益に貢献する可能性がある。
#したがって、今後は単純なGPU利用率だけでなく、次の点が重要になる。
#顧客の仕事1件当たりの総費用をどれだけ下げられるか。
#その改善によって、クラウド事業者自身がどれだけの利益を獲得できるか。
#そして、
#その利益が、GPU設備の減価償却、更新投資、資金調達費用を上回るか。
#この三つを分けて分析する必要がある。
#第18章 今後のネオクラウド分析で重要になる新しい指標
#これまでのGPU保有台数、契約額、MW、売上成長率だけでは、次の競争を十分に評価できない。
#そこで、今後は以下のような指標を追うことが有効だと考える。
#特に重要になるのは、有効な仕事を完了するまでの総費用である。
#AI研究であれば、一定の品質改善を達成するための総費用。
#企業向けAgentであれば、安全性と正確性の基準を満たす仕事1件当たりの総費用。
#これにはモデル推論、Sandbox、評価、再実行、失敗回復、監視、ストレージなどを含める。
#そして企業の収益性については、その費用改善を料金、稼働率、顧客維持率へ変換できているかを見る。
#これは現在のネオクラウドを、単なるGPUレンタル企業として評価する方法とは大きく異なる。
#おわりに――AI Factoryの運用能力そのものが、次の競争領域になる
#ネオクラウドは異常な速度で拡大している。
#設備投資は巨額になり、社債利回りは信用市場の警戒を示している。
#しかし同時に、売上と契約残高も急速に増加している。
#この巨額の設備投資を、すべての企業が将来回収できるのか。
#それはまだ分からない。
#しかし公開情報をたどると、この市場が単にGPUを大量に確保する競争ではなくなりつつあることは分かる。
#強化学習ではRolloutとTrainerの非同期化が進み、KVキャッシュ、Sandbox、モデルの重み更新、実験管理までが最適化の対象になっている。
#CoreWeaveはForge、ART、AOM、SUNK、Mission Controlを組み合わせ、AI研究・学習・評価・運用の循環を統合する方向へ進んでいる。
#NebiusはEigen AI、Inferize、Token Factory、Soperator、Papyraxなどによって、推論と学習の実効処理量を高める技術を積み上げている。
#SemiAnalysisのClusterMAX 3.0では、両社が最上位のPlatinum評価を獲得した。
#しかし、フロンティアラボも自社のクラウド管理技術を開発している。
#OpenAIとAnthropicがモデル研究と計算基盤を共同最適化するほど、ネオクラウドの独自ソフトウェアが持つ付加価値には競争圧力が生じるかもしれない。
#さらにAstra級AIが研究コード、Kernel、Scheduler、監視システムを改善できるようになれば、従来のソフトウェア開発能力だけでは、長期的な堀になりにくくなる可能性もある。
#では、何が残るのか。
#私は、実際の設備を運用することでしか得られないデータと、そのデータから検証可能な改善を生み出し、次の設備へ反映する仕組みが重要になると考えている。
#これはOpenAIとBroadcomによるJalapeño、OpenAIとSynopsysによるEDA協業で起き始めている変化に近い。
#AIの能力が向上すると、設計案や改善案を生成する費用は下がる。
#しかし、その案が実際に正しいかを判断するには、信頼できる実行環境と検証データが必要になる。
#ネオクラウドでも同じだ。
#GPUの障害履歴、ネットワークの異常、液冷の実測、ラックの性能、復旧結果、長時間学習の挙動。
#こうしたデータを使って、次世代のGPUクラスタをより速く立ち上げ、安定稼働させる。
#その技術が実際の性能改善へつながり、顧客の信頼と利益を生む。
#ここに、次世代のネオクラウドが持ち得る独自の堀が存在するのではないだろうか。
#そして、この堀を自社設備だけでなく、研究所、企業、主権AI、地域のAI Factoryへ展開できるなら、ネオクラウドはGPUを保有して貸し出す事業から、AI Factoryそのものを稼働・改善させる技術を販売する事業へ進化する可能性がある。
#もちろん、それが高い投資収益率を保証するわけではない。
#技術的な競争優位性、計算需要、金融市場の評価は別々に動く。
#だからこそ、今後は株価や社債利回りだけではなく、足元の技術開発、設備の商用化、クラスタの有効生産性、顧客の仕事の成功率を追っていく必要がある。
#未来の設備投資がすべて回収できるかは分からない。
#しかし、AIが自らの研究・実行・検証・改善を繰り返す時代へ進むなかで、計算資源に何が求められ、どの技術が必要になり、どこに新しいボトルネックが現れているのか。
#その変化は、すでに公開されている研究と製品の中に現れている。
#そして私たちが今見ているのは、GPUクラウドの競争というよりも、AIの改善サイクル全体を支える新しい産業基盤の形成過程なのかもしれない。
#調査基準日：2026年10月17日。 本文では、企業発表の性能値、第三者評価、学術研究の実験結果、将来予測を区別している。技術の公開・Preview・正式提供・商用収益化は異なる段階であり、投資判断においてはそれぞれを独立して検証する必要がある。
##
補足：NVIDIAとネオクラウドの関係――強力な支援か、過度な依存か
#2026年6月27日、SemiAnalysisは興味深い報告を公開した。
#複数のネオクラウド経営者が、AMD製GPUやTPU、NVIDIA以外のネットワーク機器を採用すると、NVIDIAから最新GPUの優先割当やIPO・資金調達支援などで不利益を受けるのではないかと懸念しているという。
#実は、同様の疑惑は以前から報じられている。
#2024年8月1日（日本時間8月2日）、The Informationは、米司法省がNVIDIAの市場支配力に関する競合企業からの苦情を調査していると報道した。競合GPUを購入した顧客への供給制限や価格面での不利益、NVIDIA製GPUとネットワーク機器の抱き合わせなどが問題視されていた。
#さらに2024年12月には、EU競争当局もNVIDIAの製品抱き合わせに関して顧客や競合企業へ質問状を送ったとReutersが報じている。
#ただし、これらは疑惑や当局による情報収集の報道であり、実際に違法な報復行為が認定されたことを意味しない。
#また、SemiAnalysisの2026年6月の投稿には反論もある。
#Lambdaの共同創業者・CTOであるStephen Balabanは、今回の報告は正確ではないと批判した。Lambdaを含む多くのネオクラウドがNVIDIA以外のネットワーク機器を採用しており、NVIDIAから出資を受けた企業の中にも代替アクセラレータを提供する事業者が存在すると指摘している。
#Balabanは、NVIDIAが広く採用される理由について、複数クラウド間でコードを移植しやすいエコシステムの価値も挙げている。
#一方、NVIDIAがネオクラウドに対して強い影響力を持つこと自体は確かだ。
#NVIDIAは単なるGPU供給者ではない。Nebiusへの20億ドルの出資、CoreWeaveの未販売計算容量に対する購入保証、次世代GPU・ネットワークの共同検証などを通じて、技術供給だけでなく資金調達と需要確保にも関与している。
#ここには二面性がある。
#NVIDIAとの協業は最新技術への早期アクセスやクラスタ運用能力の向上につながり、強力な競争優位性になり得る。
#しかし、GPU調達、資金調達、顧客需要まで一社への依存が強まれば、競合製品を採用する自由度が制約される可能性もある。
#現時点ではNVIDIAによる具体的な報復は確認されていない。しかし、経営者が報復を恐れることで投資判断が変わるなら、それ自体が市場競争に影響する可能性がある。
#NVIDIAと深く共同開発できる能力と、NVIDIAが支援を変更しても競争力を維持できる能力は、分けて見る必要がありそうだ。
##
参考資料
#- SemiAnalysisによる報告（2026年6月27日）
- Stephen Balabanによる反論（投稿転載を含む参照ページ）
- The Information：NVIDIAへの米司法省の調査報道（2024年8月1日、米国時間）
- Reuters：EU当局によるNVIDIAの抱き合わせ取引調査報道（2024年12月4日）
特定銘柄の推奨・勧誘を目的とするものではありません。投資判断はご自身の責任でお願いいたします。
#