Nvidia Rubin CPX発表——長文推論専用GPUで新カテゴリ確立
Nvidia は 2026 年 5 月、年次開発者向けイベントで新カテゴリの GPU「Rubin CPX」を発表した。CPX は "Context Processing eXpert" の略称で、1M〜10M トークンの超長文・長尺動画・大規模コードベース推論専用 に設計された世界初の専用 GPU だ。次世代プラットフォーム「Vera Rubin」の構成要素として位置づけられ、汎用の Rubin GPU と組み合わせて使用することで、現行の Blackwell B200 比でトークン推論コストを約 10 倍削減、MoE（Mixture of Experts）学習時の必要 GPU 数を 4 倍削減 という劇的なコスト効率を実現する。
提供開始は 2026 年下半期、対応クラウドは AWS、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructure（OCI） の主要 4 社が一斉スタートを切る予定だ。Hopper H100 が「汎用 AI GPU」の代名詞となり、Blackwell が「フロンティアモデル学習・推論」の標準になったように、Rubin CPX は「長文コンテキスト推論の業界標準」を狙う製品ラインアップとして投入される。
本稿では、Rubin CPX の技術的位置づけ、Hopper / Blackwell / Rubin GPU との詳細比較、なぜ「専用 GPU」という分割設計が必要になったのか、日本のクラウド事業者・AI スタートアップへの影響、そして「1M+ コンテキスト処理のコモディティ化」が引き起こす次の構造変化までを、CTO・GPU 調達担当・AI スタートアップ経営者の視点で深掘りする。
Rubin CPX とは何か——「Disaggregated Inference」を物理化した GPU
Context Processing eXpert の名前が示すもの
Rubin CPX の最大の特徴は、汎用 GPU の延長線上にある製品ではなく、「プロンプトの前段処理（prefill）専用」に最適化された SKU だという点にある。LLM の推論プロセスは大きく 2 つのフェーズに分解できる。
- Prefill フェーズ: ユーザーからの入力プロンプト全体を読み込み、各トークンの Key-Value（KV）キャッシュ を生成する段階。入力長に比例して計算量と必要メモリ帯域が増えるため、並列度が高く、メモリ帯域支配型 の計算特性を持つ。
- Decode フェーズ: KV キャッシュをもとに次のトークンを 1 つずつ逐次生成する段階。バッチ内のリクエストを束ねて FLOPS を稼ぐ、低レイテンシ・コア演算支配型 の計算特性。
従来の H100 / B200 はこの 2 つを同じハードウェアで処理してきたが、入力 1M トークン超のような超長文プロンプトが現実的になると、prefill 段階だけで GPU メモリ帯域がボトルネックになり、decode のコア演算が空転する非効率が顕著になっていた。
Rubin CPX はこの prefill フェーズに特化した GPU で、HBM4 メモリの帯域を最優先、attention 演算のサブシステムを物理的に拡張、KV キャッシュ生成のスループットを最大化 する設計になっている。一方、最終的なトークン生成は同じラック内の Rubin GPU（decode 担当） に KV キャッシュをパイプライン転送することで処理する。
この図は、Rubin CPX が prefill 専用 GPU として汎用 Rubin GPU と分業する仕組みを示しています。
Disaggregated Inference は何が革新的か
prefill と decode を異なる GPU に分割するアプローチは、研究界では「Disaggregated Inference（分離型推論）」と呼ばれ、過去 2 年ほどソフトウェア最適化として注目されてきた。代表的な実装としては DeepSeek が公開した推論システムや、vLLM 系のプロジェクトに最近導入された分散実行モードがある。
ただし、これまでは「同じハードウェアを論理的にどう使い分けるか」というソフトウェア工夫の領域だった。Nvidia の Rubin CPX が画期的なのは、この発想を ハードウェアアーキテクチャの分割として物理化した 点にある。prefill 専用にメモリ帯域と attention ユニットを盛り、decode 用の FLOPS と低レイテンシ最適化は別ダイに任せる——いわば「GPU クラスタの中で役割分担が固定された専用ノード」を作ったのだ。
この設計のメリットは大きく 3 つある。
- コスト効率: prefill フェーズが帯域支配なら、decode 用の高 FLOPS コアは不要。逆も然り。必要な機能だけに集中したダイは同価格帯で 2〜3 倍の実効性能を出せる。
- 電力効率: 冗長な演算ユニットを切り捨てることで、1 トークンあたりの消費電力が大幅に下がる。データセンターの kW あたり収益が改善する。
- メモリの大胆な設計: HBM4 を「prefill のためだけ」に積めるため、メモリ容量を増やしても汎用 GPU としての設計バランスを崩さずに済む。
Nvidia 公式の数字によれば、Rubin CPX + Rubin GPU の組み合わせは、Blackwell B200 単体構成と比べて 1M トークン入力時の推論コストを約 1/10 に削減 する。これは単なる世代更新では到達できない水準で、アーキテクチャ分割という根本変更があってこそ実現する数字だ。
性能とコスト——B200・H100 との比較
主要 4 製品スペック比較表
| 項目 | Rubin CPX | Rubin GPU | Blackwell B200 | Hopper H100 |
|---|---|---|---|---|
| アーキテクチャ | Rubin (専用ダイ) | Rubin | Blackwell | Hopper |
| 主用途 | 長文 prefill 専用 | 汎用学習・decode | 汎用学習・推論 | 汎用学習・推論 |
| メモリ | HBM4 大容量 | HBM4 | HBM3e 192GB | HBM3 80GB |
| 想定コンテキスト | 1M〜10M tokens | 〜1M tokens | 〜200K tokens | 〜128K tokens |
| 1M トークン推論コスト (相対) | 約 10 | 約 45 | 100 (基準) | 約 180 |
| 学習効率 (MoE) | 補助役 | 標準の 1/4 GPU | 標準 | 高 GPU 数必要 |
| 提供開始 | 2026 H2 | 2026 H2 | 2025 (出荷中) | 2023 (出荷中) |
| 想定ラック構成 | Rubin GPU と混載 | Rubin CPX と混載 | 単体 | 単体 |
| 主要クラウド | AWS, GCP, Azure, OCI | 同左 | 全主要クラウド | 全主要クラウド |
| ターゲット顧客 | 長文・動画・コード推論 | フロンティアモデル学習 | フロンティア学習・推論 | 汎用 AI ワークロード |
数字は Nvidia 公式発表値および業界推定値をベースにした相対指標。1M トークン入力時の推論コストは、Blackwell B200 を 100 とした場合の相対値で、Rubin CPX 単体ではなく Rubin CPX + Rubin GPU 混載構成 での値だ。Hopper H100 は 1M トークンを単発でさばける構成ではないため、複数 GPU で擬似的に処理した場合のコスト推定。
この棒グラフは、長文プロンプト 1M トークンを処理する際の相対コストが Blackwell B200 から Rubin CPX 構成で 10 分の 1 まで圧縮される様子を示しています。
MoE 学習時の GPU 数 4 倍削減のからくり
Nvidia は CPX の発表と同時に「MoE 学習に必要な GPU 数を 4 倍削減できる」とアピールしている。これは一見、CPX が学習にも使えるかのように読めるが、実態は少し異なる。
MoE モデルの学習では、ルーター層が各トークンを複数の "Expert" サブネットワークに振り分ける。Expert 間の通信負荷は学習バッチサイズと総トークン数に比例して増えるため、超長文を学習データに含めるケースほど通信が支配的になり、必要 GPU 台数が膨れ上がる。
Rubin CPX は、学習プロセス内の「コンテキスト処理段階」を肩代わり することで、ルーターと Expert に流すトークン量を圧縮し、必要な Rubin GPU の台数を 4 分の 1 程度に削減する。要は学習ジョブの中で prefill 相当の処理を CPX に逃がし、本体の学習ループは Rubin GPU で回す、というハイブリッド構成だ。
この設計が意味するのは、長文データを使うほど CPX のメリットが大きくなる こと。長尺の動画・論文・コードベースで MoE モデルを継続学習させたい企業にとっては、CPX の有無で学習コストが大きく変わる構造が生まれる。
Vera Rubin プラットフォーム——クラウド 4 社の展開ロードマップ
2026 年下半期から 2027 年にかけてのリリース順
Nvidia は Rubin CPX を単体製品としてではなく、Vera Rubin プラットフォーム の構成要素として位置づけている。Vera は CPU 側のコードネームで、Rubin が GPU 側、CPX が長文専用ダイという三段構造だ。
主要クラウド事業者の対応スケジュールは以下の通り。
- 2026 Q3: Nvidia と一部パートナー（Lambda、CoreWeave 等）に先行提供開始
- 2026 Q4: AWS と Google Cloud が一般顧客向け提供開始
- 2027 Q1: Microsoft Azure と Oracle Cloud Infrastructure（OCI）が追随
- 2027 H2: エンタープライズ向けに本格普及、日本国内のクラウド事業者も合流見込み
この図は、Vera Rubin プラットフォームの段階的な展開ロードマップを時系列で示しています。
クラウド料金は「コンテキスト処理量」ベースに変わる可能性
現在の GPU クラウドの課金モデルは、GPU 時間（H100 1 枚を 1 時間使うと $X） が主流だ。しかし Rubin CPX のように prefill と decode が物理的に分かれた構成では、ユーザーの実際の利用パターンに応じて課金粒度を細かくする方が事業者にとって合理的になる。
具体的には、以下のような料金体系が登場する可能性がある。
- コンテキスト処理料金: 入力トークン数に比例する prefill フェーズの利用料
- 生成トークン料金: 出力トークン数に比例する decode フェーズの利用料
- キャッシュ保持料金: 生成済み KV キャッシュをセッション間で保持する場合の保管料
これは OpenAI API や Anthropic API がすでに採用している「入力トークン料金 / 出力トークン料金」の構造に近い。Rubin CPX を採用するクラウドが増えれば、IaaS レイヤーでも同様の細分化が進む可能性が高い。
「実際に使ってみた」できないので、筆者の所感
Rubin CPX は 2026 年下半期提供開始のため、本稿執筆時点で筆者が物理的に触れる手段はない。代わりに、現在 AWS で Hopper H100 / Blackwell B200 を借りて長文推論ワークロードを回している筆者の経験から、CPX に期待する点と懸念点を整理しておく。
期待できる点
- 1M+ コンテキストの常用化: H100 で 128K、B200 で 200K 程度のコンテキスト窓が現実的だった環境から、1M〜10M が「コスト的に許容範囲」になる。RAG（Retrieval-Augmented Generation）の「事前検索 + 短文プロンプト」というアーキテクチャを根本から見直し、長文を丸ごと投げる方式が経済的合理性を持つ。
- コードベース全体投入の現実化: 100 万行規模のモノレポを一発で読み込ませて影響範囲分析・リファクタリング提案を出すユースケースが、コスト面で「気軽に試せる」レベルに下がる。
- 動画 AI の経済性改善: 1 時間動画の全フレーム解析を行うと現状の B200 ではコストが膨大だが、CPX 構成では 10 分の 1 に近づく。動画検索・編集 AI のスタートアップにとっては事業計画の前提が変わるレベルのインパクト。
懸念点
- 混載ラックの可用性: Rubin CPX は単体では機能せず、Rubin GPU と組み合わせる必要がある。クラウド側がどのような混載比率でラックを組むかによって、長文ワークロードのキューイング時間が変わる。
- ソフトウェアスタックの追従: CUDA / cuDNN / TensorRT-LLM が CPX の prefill 専用 API をどこまでスムーズに抽象化するか。アプリケーション開発者が直接 CPX を意識しなくて済むかは、Nvidia のソフトウェア出来次第。
- 競合 GPU の対抗策: AMD MI355X、Google TPU v8、AWS Trainium 3 などが「同等の Disaggregated アーキテクチャ」を追従できるか。CPX が事実上の独占となる期間がどれだけ続くか。
特に最後の点については、CPX のような専用ダイ設計は競合にとって追従が難しい。AMD MI355X はまだ汎用設計の延長線上にあり、Google TPU v8 も pod 内の役割分担はソフトウェア層に依存している。Nvidia がハードウェアレベルで分割を物理化したことで、競合との性能ギャップが一段広がる可能性がある。
1M+ コンテキスト処理のコモディティ化が意味するもの
筆者がもっとも強調したいのは、Rubin CPX の発表が「長文コンテキストはもはやフロンティア機能ではなく、コモディティ機能になる」ということだ。
2024 年時点では「100 万トークン文脈」は Google Gemini 1.5 だけが提供する特殊な機能だった。2025 年に DeepSeek V4-Pro や xAI Grok 4.3 がフロンティア水準で 1M を実装し、2026 年現在では「1M はフロンティアモデルの標準スペック」になった。そして Rubin CPX が物理レイヤーから 1M〜10M のコスト構造を破壊することで、2027 年には「長文文脈は、検索やキャッシュと同じく、当たり前のインフラ機能」になる。
これが意味するのは、「長文を扱える」こと自体がプロダクトの差別化要因にならなくなる 未来だ。RAG 専業のベンダー、ベクトル検索エンジン、長文サマリーツールなどは、根本的な存在意義を再定義する必要が出てくる。一方で、長文を前提とした新しい体験——たとえば「ユーザー個人の生涯ログを丸ごと文脈に入れたパーソナル AI」「企業の全資料を恒常的に参照する社内 AI」——は、コスト的に成立する領域に入ってくる。
日本での影響——国内クラウド事業者と AI スタートアップ
さくらインターネット / KDDI / NTT データの選択肢
経済安全保障の観点から、日本政府は GENIAC プログラムを通じて国内クラウド事業者の GPU 調達を支援している。さくらインターネットの「さくらの高火力」、KDDI 系の AI データセンター、NTT データのソブリンクラウドはいずれも H100 / H200 ベースの構成を展開しているが、Rubin CPX 対応にどのタイミングで踏み切れるかが今後の競争力を左右する。
特に重要なのは、Rubin CPX が「GPU 単体ではなく Vera Rubin プラットフォーム全体の調達」を求めること。CPU（Vera）、GPU（Rubin）、専用ダイ（CPX）の三段構成を整える必要があり、ラック単位の投資額が H100 時代よりさらに大きくなる。資金力のない事業者は、CPX に対応せず汎用 Rubin GPU だけで戦う選択肢を取らざるを得ない可能性がある。
逆に、Microsoft Azure の日本リージョンや Google Cloud の東京リージョンが先行して CPX を提供すれば、長文 AI ワークロードはハイパースケーラーに集約される圧力が強まる。国内クラウドが「長文以外の汎用 AI ワークロード」で差別化するか、Rubin CPX 対応に踏み切るかは、各社の事業戦略次第だ。
国内 AI スタートアップへのインパクト
国内の AI スタートアップにとって、Rubin CPX の登場は 追い風と逆風の両面 がある。
追い風となるケース:
- 動画 AI 系: PFN や Sakana AI の動画解析プロジェクトは、1 時間級の動画を丸ごと投げる処理が経済的に成立する。コスト構造が劇的に改善する。
- 長文ドキュメント AI 系: 法務テック、契約書レビュー、医療カルテ解析などの長文ドメインは、RAG に頼らず原文を全文投入する方式が現実解になる。
- コード AI 系: 国内モノレポを抱える大企業向けに、コードベース全体解析を提供するスタートアップは、CPX 経由で大規模顧客にも対応できる体力が付く。
逆風となるケース:
- RAG 専業ベンダー: 長文を扱える基盤モデルが安価になると、「事前検索 + 短文プロンプト」というアーキテクチャを売る独自価値が縮小する。Pinecone、Weaviate 系のサービスはより付加価値の高い役割（メタデータ管理、アクセス制御、監査ログ等）にシフトを迫られる。
- オンプレ前提の GPU 調達: Rubin CPX を含む Vera Rubin プラットフォームのオンプレ調達は、最低投資額が H100 時代の数倍に膨らむ。資本効率の観点から、AWS / GCP / Azure の従量課金に乗る方が合理的になる場面が増える。
日本から Vera Rubin プラットフォームを利用する手順
Rubin CPX は 2026 年下半期から AWS / Google Cloud / Azure / OCI で順次提供される。日本リージョン対応については正式発表時点で明確なロードマップは出ていないが、過去の B200 ロールアウト実績を踏まえると、東京リージョンへの展開は 提供開始から 3〜6 ヶ月遅れ が標準的なペースになる見込みだ。
AWS から Vera Rubin インスタンスを利用する想定手順
- AWS アカウントで EC2 Capacity Reservation を申請 (Vera Rubin インスタンスは初期は限定提供のため、事前リザーブが必要)
- 対応リージョンを選択 (us-east-1 など主要リージョンから順次展開、東京は数ヶ月遅れ)
- Vera Rubin インスタンスタイプを起動 (CPX 混載構成のインスタンスタイプが新設される見込み、命名規則は
p7-cpx.*系が予想される) - NVIDIA NeMo / TensorRT-LLM の最新版をデプロイ (CPX の prefill 専用 API は、ソフトウェアスタックから自動的に活用される設計)
- 長文ワークロードの A/B 比較 (B200 比でコスト・レイテンシを実測し、本番切り替えを判断)
AWS の GPU インスタンス調達には、長年の課題として「日本リージョンでの確保困難」がある。Rubin CPX を確実に使いたい場合は、米国リージョンでの本番稼働も視野に入れた設計を行うことを推奨する。
AWS は CPX 提供で先行するクラウドのひとつで、長文 AI ワークロードを本格的に動かしたい企業にとっては最優先で押さえておきたい選択肢だ。
Google Cloud / Azure / OCI の選択ポイント
- Google Cloud: TPU v8 と Rubin CPX のハイブリッド構成を提供する見込み。Gemini ファミリーとの統合が深く、Vertex AI 経由でマネージドに使いたいユーザー向け。
- Microsoft Azure: OpenAI との連携が強く、GPT-5 系モデルの長文版を Azure 経由で利用するワークロードに最適化される可能性。
- OCI: 価格競争力で他社をリードする傾向があり、特にバッチ推論や夜間処理用のスポット型ワークロードでは要検討。
筆者の見解・予測——2027 年の GPU 業界はどう変わるか
Rubin CPX の登場は、単なる Nvidia の新製品ではなく、GPU 業界の構造変化を加速させるトリガー になる。筆者が考える 2027 年に向けた予測は以下の通りだ。
予測 1: 「prefill / decode 分離」が業界標準になる
Rubin CPX が示した Disaggregated Inference のハードウェア実装は、AMD・Google・AWS が追従せざるを得ない方向性だ。AMD は MI400 系で同様の専用ダイ設計を投入する可能性が高く、Google TPU v9 もこの方向に進むと予想される。2027 年末には「汎用 GPU 1 種類で全部やる」アーキテクチャは時代遅れと見なされるようになるだろう。
予測 2: 推論コスト 10x 削減が「価格戦争」を引き起こす
トークン推論コストが 10 分の 1 になれば、API 提供事業者は値下げ余力を持つ。OpenAI、Anthropic、Google が 2027 年に「コンテキスト 1M 以上は実質無料」のような攻めた価格戦略を打ち出す可能性が現実味を帯びる。これは消費者向け AI（ChatGPT、Claude、Gemini）のサブスクリプション料金にも波及し、月額 $20 が「無制限長文」の標準ラインになる。
予測 3: 「長文 AI スタートアップ」のカテゴリーが急成長
長文を経済的に扱える環境が整うことで、これまで「コストが見合わない」と諦められていた領域に新規参入が起こる。具体的には、生涯学習ログを参照するパーソナル AI、企業の全議事録を統合する経営支援 AI、動画コンテンツ丸ごと解析の編集 AI など、長文を前提とした新しい体験を提供するスタートアップ が 2027 年〜2028 年にかけて勃興する見込み。
予測 4: 日本国内クラウドは「特化型 GPU」で生き残る道を模索
ハイパースケーラーが Rubin CPX で長文推論を独占する流れに対抗するため、国内クラウド事業者は「特化型 GPU の選択肢を提供する」方向に振れる可能性が高い。たとえば、エッジ推論専用、低レイテンシ専用、データ主権重視のソブリン構成など、汎用性を捨てて尖った価値を提供する戦略だ。
まとめ——CTO・AI 担当者が今すぐ取るべきアクション
Nvidia Rubin CPX の発表は、GPU 業界の構造変化を象徴する出来事だ。技術担当者・経営者が今すぐ着手すべきアクションは以下の通り。
- 長文ワークロードの棚卸し: 自社の AI ユースケースのうち、コンテキスト長が制約になっている案件をリストアップする。Rubin CPX が来ることで「経済的に成立する」案件がどれだけあるかを試算する。
- GPU 調達戦略の見直し: 2026 年内に H100 / B200 の大量調達を計画している場合、Vera Rubin プラットフォームへの移行コストを含めて TCO を再計算する。短期的には B200、長期的には Rubin CPX という二段階戦略が合理的な可能性がある。
- 長文プロンプト前提のアーキテクチャ検証: RAG ベースの実装を「長文一括投入方式」に切り替えた場合の精度・コストを早めに検証する。CPX 本格提供前に PoC を回しておくと、提供開始時に競合より早く本番展開できる。
- クラウド契約の柔軟性確保: Vera Rubin インスタンスは初期は限定供給のため、AWS / GCP / Azure 横断で調達できる契約形態を整えておく。単一クラウドへのロックインは避けたい。
- 長文 AI 領域のスタートアップ機会探索: 自社でプロダクトを作る場合、「長文を経済的に扱える」前提で何が可能になるかをブレインストーミングする。動画・コード・ドキュメントの各ドメインで未開拓のニッチが多く残っている。
Rubin CPX は単体の製品ではなく、AI インフラの世代交代を加速するキャタリストだ。半導体・GPU・クラウド・AI スタートアップのいずれの立場でも、今後 12 ヶ月の意思決定にこの新カテゴリの登場をどう織り込むかが、競争力を左右することになる。
クラウド経由で Vera Rubin / Rubin CPX を本格活用したい企業は、まず AWS など主要クラウドのアカウントを整備し、Capacity Reservation 制度や Savings Plan の活用余地を検討するところから始めるのが現実的な第一歩になる。