AIの値段はGPUだけで決まらない——HBM不足とHBF・GCRAMが示す「記憶の配置」

生成AIの導入費を考えるとき、私たちはモデルの利用料やGPUの台数から話を始めがちです。しかし、長い資料を読み、多くの利用者と会話し、複数のAIエージェントが同時に動くほど、費用と応答時間を左右する場所は演算器の外へ広がります。モデルの重みや会話の途中状態を、どこへ置き、どれだけ速く運び、いつ消すかという「記憶の配置」です。

2026年9月10日、Reutersは中国のAI半導体メーカーが高帯域幅メモリーの不足を受けて価格を引き上げていると報じました。同じ日、PC WatchはSandiskが提案する広帯域フラッシュ「HBF」を詳しく解説しました。DRAMを積むHBMだけへ大容量化を任せず、NANDフラッシュをAIアクセラレーターの近くへ積み、推論用のモデルやKVキャッシュを置く構想です。

さらに、Hacker Newsで9月12日に注目されたarXiv論文は、チップ内部でも一種類のメモリーですべてを賄わず、SRAMと高密度・低消費電力のGain Cell RAMを組み合わせる設計探索を示しています。市場、パッケージ、チップ内部という三つのニュースを重ねると、次のAI競争は「最速のGPUを何台買うか」だけでは説明できません。速い記憶、小さな電力で多く置ける記憶、電源を切っても残る記憶を、仕事の性質に合わせて分ける競争になっています。

これは半導体企業だけの話ではありません。日本企業がクラウドAI、社内推論基盤、AI搭載PCを選ぶときも、モデル名や一秒当たりのトークン数だけを見ると、混雑時の遅さ、長文利用の追加費用、電力、切り替えにくさを見落とします。調達の中心をGPU台数から「一件の仕事を終えるまでに、何をどこへ記憶するか」へ移す必要があります。

AI処理を支える半導体基板とメモリーのイメージ

結論——AI基盤は演算性能ではなく、四つの記憶時間で選びます

AIの記憶には、同じ「容量」という数字でまとめられない役割があります。計算の直前だけ必要なデータ、会話中に繰り返し読むデータ、複数の仕事で共有するモデル、監査や再実行のために長く残す記録です。必要な速さ、書き換え回数、保持時間、機密性が違います。

日本企業が最初に作るべきなのは、製品名の比較表ではなく、次の四つの時間を並べた業務表です。

記憶の時間	代表的な内容	重視する条件	消し方・戻し方
計算中	中間結果、演算器の近くで使う値	遅延、帯域、書き換え速度	処理終了時に破棄します
会話中	KVキャッシュ、検索結果、作業状態	容量、読み出し速度、利用者分離	セッション終了や期限で消します
運用中	モデルの重み、索引、共有知識	容量単価、起動時間、更新手順	版を戻せるようにします
証拠として保持	入力、出力、承認、変更履歴	完全性、検索性、保持期限	規程に沿って削除します

この表を作ると、HBMを増やすべき仕事と、SSDやフラッシュへ逃がせる仕事が分かれます。すべてを最速層へ置くと高価になり、すべてを安価な層へ置くと応答が遅くなります。大切なのは、一番速い部品を選ぶことではなく、遅くてもよいデータを正しく下の層へ移すことです。

AIのモデル・データ・実行場所を「選び直せる範囲」で整理した記事では、所有量より切替可能性が重要だと述べました。メモリー階層でも同じです。特定のGPUやクラウドだけで動く配置に固定すると、部品不足や料金変更がそのまま業務停止へつながります。容量、速度、電力、移行時間を一組で測ることが、実務上の選択肢を残します。

HBM不足が示すのは、AI価格のボトルネックが移動することです

HBMは、GPUやAIアクセラレーターの近くで大量のデータを高速に出し入れするためのメモリーです。一般的なDRAMを遠くに置く構成より広い帯域を得やすく、大規模モデルの学習と推論を支えてきました。GPUの演算器がどれほど速くても、次に計算する重みや途中状態が届かなければ待ち時間が生まれます。

Reutersの9月10日付記事は、中国のAI半導体メーカーがHBM不足を受けて値上げしていると伝えました。ここで重要なのは特定地域の価格だけではありません。AI半導体の供給力が、GPUダイの生産数だけで決まらず、先端メモリー、積層、接続、検査を含む一連の工程に左右されることです。

企業の見積書では「GPU利用料」の一行に見えても、その背後ではメモリー容量と帯域がインスタンスの種類を分けています。長い文書を入力し、同時利用者を増やし、エージェントが何度も外部情報を読み直すと、会話中の状態が膨らみます。モデル本体が同じでも、利用者ごとに保持するKVキャッシュが増えれば、同じ装置でさばける件数は減ります。

そのため、安いモデルへ切り替えただけでは総額が下がらない場合があります。入力を必要以上に長くし、同じ資料を毎回読み込み、途中状態を長く保持すれば、メモリーとデータ移動の負担が残るからです。逆に、必要な資料だけを検索し、会話を仕事単位で閉じ、再利用できる索引を共有すれば、モデルを変えなくても負担を減らせます。

調達時には、ピーク時の一秒当たりトークン数だけでなく、次の数字を同時に求めます。

最初の回答が始まるまでの時間
次のトークンが出る間隔と、そのばらつき
同時利用者を増やしたときに保持できる文脈量
長文入力一件が占有するメモリーと保持時間
モデル更新時に重みを読み込み直す時間
一件の仕事が完了するまでの電力量と費用
容量不足時に短い文脈や別モデルへ戻す時間

数字が平均値だけなら、月末や朝会前の混雑が隠れます。中央値に加え、遅い上位一割の応答時間を見ます。生成開始が速くても途中で詰まるのか、最初は待つが出力は安定するのかも分けます。利用者が感じる遅さと、基盤で起きている不足を結び付けるためです。

データセンターでサーバーとメモリーの配置を管理するイメージ

HBFは「HBMを全部置き換える魔法」ではなく、読み出し中心の層です

PC Watchが解説したHBFは、HBMのDRAMダイをNANDフラッシュへ置き換え、AIアクセラレーターの近くへ大容量を配置する構想です。記事によれば、Sandiskは同じ積層枚数ならDRAMより大きな容量を狙え、読み出し帯域もHBMに近づけられると説明しています。電源を切っても内容が残る不揮発性も、DRAMとの大きな違いです。

Sandiskが示したエージェントAI推論のエミュレーションでは、Qwen3-480B-A35Bを使い、HBF搭載側はGPU当たり4TB、HBM搭載側はGPU当たり192GBとしました。記事では、HBFを搭載した四つのGPUパッケージと、HBMを搭載した八つのGPUパッケージが、定常状態でほぼ同じ出力性能になったと紹介されています。

ただし、この結果を「HBFなら実機でGPUを必ず半減できる」と読んではいけません。Sandiskが示した条件でのエミュレーションであり、メモリー総量もHBF側16TB、HBM側約1.5TBと大きく違います。部品費、遅延、故障時の復旧、書き込み寿命、実アプリのアクセス傾向まで含む製品比較ではありません。

HBFの価値を理解しやすいのは、AI推論を「プリフィル」と「デコード」に分ける見方です。プリフィルは入力全体を処理し、最初のトークンやKVキャッシュを作ります。並列演算の負担が大きく、演算性能が効きます。デコードは、既存のKVキャッシュを読みながら次のトークンを順番に作ります。計算だけでなく、大きな状態を繰り返し読む能力が重要になります。

PC Watchの記事では、書き換えが多いデータをHBMへ置き、モデルの重みや大容量のKVキャッシュなど読み出し中心のデータをHBFへ置く階層構成も紹介しています。プリフィルにはGDDR SDRAM、デコードにはHBFを割り当てる案もあります。一種類のメモリーの弱点を無理に消すのではなく、工程ごとに役割を分ける発想です。

一方、NANDフラッシュには書き換え寿命があります。学習ではモデルの値を頻繁に更新するため、読み出し中心の推論と同じ扱いはできません。HBFのサンプル出荷は2027年中の予定とされ、共通仕様も策定途中です。今すぐ購入できる完成品の性能として予算へ入れる段階ではありません。

それでも、日本企業が今から学べることはあります。頻繁に変えるデータと、ほとんど読んで使うだけのデータを分けることです。社内検索なら、原文、検索索引、利用者の質問、検索結果、回答、監査ログを別々に扱います。すべてを会話中の高速メモリーへ載せ続ける必要はありません。

チップ内部でも「速い一種類」から異種混載へ進みます

arXivに公開された「Heterogeneous Memory Design Exploration for AI Accelerators with a Gain Cell Memory Compiler」は、さらに小さな範囲を扱います。研究チームは、AIアクセラレーターのチップ内部で、SRAMとGain Cell RAMを組み合わせる設計を探索するOpenGCRAMコンパイラーを提示しました。

論文の要旨では、メモリーがシステムの費用と電力で占める割合が増えており、特性の異なる技術を組み合わせる必要性が述べられています。GCRAMはSRAMより高密度、低消費電力で、保持時間を調整できる選択肢として位置付けられています。OpenGCRAMは商用CMOS工程を対象にマクロの設計とレイアウトを生成し、面積、遅延、電力を設定ごとに評価します。

この研究も、GCRAMを載せた一般向け製品がすぐに登場するという発表ではありません。論文要旨が示すのは設計探索の道具と方向性です。製造歩留まり、長期信頼性、量産費、ソフトウェア対応、実際のAI処理での総合性能は別に評価する必要があります。

それでも、HBFと共通する考え方が見えます。速いが面積や電力の負担が大きい記憶だけでチップを埋めず、少し性質の違う記憶を混ぜ、データの寿命とアクセス頻度に合わせて置きます。大規模なデータセンターでも、チップ内部でも、設計の中心が「最大速度」から「適材適所」へ移っています。

企業のAI導入も同じ方向へ進めます。すべての問い合わせを最大モデルへ送り、全文を毎回載せ、長期間同じ会話へ追加し続ける構成は分かりやすい一方で、費用、遅延、情報混在を増やします。仕事を分類し、必要な記憶時間を変えれば、小さなモデル、短い文脈、検索、定型処理、人の判断を組み合わせられます。

一つの回答をモデル名だけで説明せず、構成・計算資源・権利・商業表示の配分で捉えた記事で扱った「AI供給票」へ、今回はメモリーの欄を加えます。どのモデルを使ったかに加え、何を高速層へ保持し、何を下位層へ移し、いつ消し、容量不足時にどう縮退したかを記録します。

複数の処理層を持つコンピューターでAIを運用するイメージ

日本企業は「一件の完了」をメモリーまで含めて測ります

インフラ担当者だけがメモリーを見る運用では、現場の使い方と費用がつながりません。利用部門は「回答が遅い」「長い資料を読ませたい」と伝え、基盤側はGPU使用率やメモリー使用量を返します。しかし、どの仕事のどの段階が、何を保持しているかが分からなければ、増設か業務変更かを選べません。

そこで、測定単位をAPI呼び出し一回ではなく、仕事の完了一件へ変えます。例えば問い合わせ回答なら、資料検索、候補生成、根拠確認、承認、送信までです。契約確認なら、文書読取、条項抽出、過去版比較、例外審査、記録までです。途中でAIを十回呼んでも、送信や承認に届かなければ完了ではありません。

完了一件について、次の五つを記録します。

入力した文書量と、実際に参照された範囲を分けます。
モデルの重み、検索索引、会話状態、証拠ログの保存場所を分けます。
最初の応答時間、出力中の待ち時間、全工程の完了時間を分けます。
GPUだけでなく、メモリー、ストレージ、データ転送を含む費用を集めます。
容量不足や障害時に、短い文脈、別モデル、手作業へ戻った結果を残します。

この記録があれば、「高価なGPUを増やす」以外の改善を比べられます。古い会話を切り離す、文書を章ごとに検索する、共通索引を再利用する、夜間にモデルを読み込む、低頻度の記録を安価な保存層へ移すといった方法です。性能を落としたように見える変更でも、仕事全体の待ち時間と失敗が減る場合があります。

データの機密性も忘れてはいけません。高速層に残った会話状態は、保存ファイルだけを消しても別に残る可能性があります。共有キャッシュへ部署の異なる情報が混ざらないか、セッション終了後に消えるか、障害解析用の記録へ何が複製されるかを確認します。容量効率と情報分離を同時に設計します。

30日で記憶の無駄を一つ減らします

新しい半導体を待たなくても、現在のクラウドAIや社内基盤で記憶の配置を見直せます。最初から全社最適化を狙わず、長文を扱い、利用回数が多く、完了条件が明確な一つの仕事を選びます。

最初の10日——何を何分持っているかを見える化します

入力文書、検索結果、会話履歴、生成途中の状態、完成物、監査ログを列挙します。それぞれについて、必要な利用者、読み書きの頻度、保持時間、削除条件を書きます。「念のため全部残す」は理由にせず、再実行、法的保持、品質改善、利用者の再開など目的を分けます。

応答時間は、最初の文字が出るまで、生成中、根拠確認、承認待ちへ分解します。GPU使用率が低いのに遅い場合、データ読み込み、検索、ネットワーク、キューが原因かもしれません。逆に出力は速くても、毎回全文を読み込む費用が膨らんでいる場合があります。

次の10日——高速層から一種類だけ下ろします

更新頻度が低く、読み出し中心のデータを一つ選びます。古い会話、参照頻度の低い資料、共通の製品説明、完了済み案件の中間状態などが候補です。検索索引や安価な保存層へ移し、必要な部分だけ高速層へ戻します。

変更前後で、完了時間、費用、誤回答、根拠到達率、再開時間を比べます。単にメモリー使用量が減ったことを成功にしません。検索漏れが増え、担当者が資料を探し直すなら、全体では悪化しています。利用者の作業を別の場所へ押し出していないかを見ます。

最後の10日——容量不足を起こし、縮退します

試験環境で同時利用を増やし、長文入力を重ね、設定した容量上限へ近づけます。どの仕事を待たせ、どの文脈を短くし、どのモデルへ切り替えるかを事前に決めます。無言で回答品質を下げたり、別地域へデータを送ったりしません。

縮退時には、利用者へ現在の制約を短く示します。「添付資料のうち関連章だけを対象にします」「過去の会話を閉じて新しい案件として始めます」「回答候補まで作り、送信判断は人へ戻します」と伝えます。元の構成へ戻す条件と時刻も記録します。

この試験で見るのは、最大負荷に耐えたかだけではありません。容量不足を早く検知し、重要な仕事を選び、情報境界を守り、通常運用へ戻れたかです。高性能な部品を増やす前に、足りないときの優先順位を決めておくと、部品不足やクラウド障害が事業停止へ直結しにくくなります。

毎月見る七つの指標

完了一件当たりの記憶費：高速メモリー、保存、転送を含む費用です。
最初の応答時間：入力から最初の出力までの時間と上位一割の遅さです。
出力間隔の安定性：生成中の詰まりや混雑によるばらつきです。
高速層の再利用率：モデルや索引を有効に共有できた割合です。
不要保持時間：仕事完了後も中間状態が残っていた時間です。
情報分離違反件数：別利用者、別案件、別部署の状態が混ざった件数です。
縮退後完了率：容量を減らしても別経路で仕事を終えられた割合です。

指標はインフラ担当者の節約競争に使うものではありません。メモリーを減らした結果、根拠が消えたり、人の待ち時間が増えたりすれば意味がありません。費用、速度、品質、情報分離、復旧を同じ画面で見ます。

AI基盤の費用と応答時間をチームで確認するイメージ

参考にした情報

Reuters「China's AI chipmakers raise prices as high-bandwidth memory shortage bites」（2026年9月10日、HBM不足とAI半導体価格への影響を確認）
PC Watch「NAND積層でHBM超えの大容量、SandiskのHBFが推論GPUを半減」（2026年9月10日、HBFの構造、推論エミュレーション、用途別の階層構成、2027年のサンプル予定を確認）
arXiv「Heterogeneous Memory Design Exploration for AI Accelerators with a Gain Cell Memory Compiler」（OpenGCRAM、SRAMとGCRAMの異種メモリー設計探索、面積・遅延・電力の評価範囲を確認）
Hacker NewsのAI新着フィード（2026年9月12日、上記研究が技術者コミュニティで再注目された経路を確認）

最後に——次のAI見積書には、記憶の行を加えます

AIの性能表は、モデル名、パラメーター、GPU、トークン速度を中心に作られてきました。しかし、HBM不足、HBFの大容量構想、GCRAMの設計探索が同時に示しているのは、計算そのものより、計算へデータを届け、途中状態を保ち、不要になったら下ろす設計の重要性です。

HBFもGCRAMも、今日の社内基盤を直ちに置き換える完成品ではありません。だからこそ、将来技術の数字をそのまま購入理由にせず、現在の仕事を分解する材料として使えます。何を頻繁に書き換えるのか、何を繰り返し読むのか、何を電源断後も残すのか、何を仕事の終了とともに消すのかを決めます。

次にAI基盤の提案を受けるとき、「GPUは何台ですか」に加えて、「一件の仕事で、どのデータを、どの記憶層へ、何分置き、容量不足のときはどこへ戻しますか」と尋ねられるでしょうか。その答えが費用、応答時間、削除、縮退までつながっていれば、AI投資は半導体の最大値を買う競争から、日本の現場で仕事を止めずに完了する設計へ変わります。