Metaの個人向けAIエージェント「Muse」を1億人が使えば、約158万個のCPUと800PBのメモリが必要になる――。Wccftechは2026年9月21日、そんな規模の試算を掲載した。利用者ごとに専用の仮想マシンを用意し、アプリを閉じた後も処理を続けるMuseは、AIの普及によってCPUやメモリの需要がどう変わるのかを考える具体例になる。

ただし、この数字はMetaの調達計画ではなく、利用者1人当たりの資源割当を単純に積み上げた試算だ。実際にどれだけの設備が必要になるのかを考えるには、同時に動くAIの数と、待機中にも保持しておくデータの量を分けて考える必要がある。

AD

800PBと10,000PBは何を意味する数字か

Wccftechの試算は、利用者1人当たり2vCPU、8GBのRAM、100GBのSSDを割り当てることを前提としている。vCPUは、仮想マシンから利用できるCPU資源を表す単位だ。同記事はX上の投稿を紹介しているが、この構成をMetaがすべての利用者に保証する固定仕様だと確認できる公式文書は見当たらない。1億人という利用者数についても、公式な実績や目標ではなく、試算上の仮定として読む必要がある。

この前提で単純計算すると、次のようになる。容量は十進表記とし、1PBを100万GB、1EBを1,000PBとしている。

対象 1人当たりの仮定 1億人分の計算 得られる総量
仮想CPU 2vCPU 1億×2 2億vCPU
RAM 8GB 1億×8GB 800PB
ストレージ 100GB 1億×100GB 10,000PB（10EB）

1億人に8GBずつ割り当てれば800PB、100GBずつなら10,000PBになる。ただし、これは利用者に割り当てる容量の合計であって、実際に800PBのRAMや10EBのSSDをそのまま購入する必要があるという意味ではない。

元記事には計算上の不整合もある。9月22日時点の記事本文ではRAMを100PBとしており、見出しの800PBと食い違っている。8GB×1億人に対応するのは800PBの方だ。また、約158万個というCPUの試算に対し、「10％だけが稼働する場合」を1,580万個としている。同じ条件で比例計算するなら約15.8万個となり、桁が合わない。

こうした誤記を修正しても、「利用者に割り当てる資源」と「実際に同時使用される資源」の間には大きな違いがある。100GBの保存容量を割り当てられても、すべての利用者が100GBを使い切るとは限らない。2vCPUを持つ仮想マシンも、常にCPUを使い切って動いているわけではない。こうした違いを考慮することが、巨大な割当総量を実際の設備需要へ置き換える際の出発点になる。

専用VMと物理CPUの専有は別の話

AWSの技術文書では、vCPUが物理コアに対応する場合と、SMTによるハードウェアスレッドに対応する場合を区別している。SMTは、一つの物理コアで複数の実行スレッドを扱う仕組みだ。したがって、2億vCPUという割当量から物理CPUの個数を計算するには、まず何を1vCPUとして数えるのかを決めなければならない。

Wccftechが示した約158万個という数字は、2億vCPUを126コアで割るとほぼ再現できる。ただし、同記事が挙げる「126コア」のCPUや、その数字の根拠は明確ではない。AMDが公表しているEPYC 9754は128コア、256スレッドだ。126という数字が管理用に予約したコアを差し引いたものなのか、単なる誤記なのかは判断できない。また、「Ryzen EPYC」という呼称も異なる製品系列を混同している。

仮に128コアのCPUを使い、1vCPUが1物理コアを占有すると仮定すれば、2億÷128で156.25万個になる。一方、1vCPUを1スレッドに対応させて256で割れば78.125万個だ。ただし後者は、vCPUを数える単位が変わっただけであり、同じ処理を半分のCPUでこなせることを意味するわけではない。実際の処理性能は、AIエージェントが何を実行するかによって変わる。

さらに、稼働中の仮想マシンでも、常にCPUを使っているとは限らない。外部サイトからの応答や、AIモデルによる推論結果を待っている時間もある。

CPU需要を概算するなら、利用者数に「同時に稼働する割合」と「稼働中のVMが平均して消費する物理コア相当量」を掛け、それを1個のCPUが提供できる処理能力で割る方が、必要な変数を把握しやすい。

説明用に式で表すと、次のようになる。

CPU個数＝利用者数×同時稼働割合×稼働VM当たりの平均コア消費÷（CPU当たりのコア数×設計上の目標利用率）

すべてのCPUコアを常時100%近くまで使う設計では、アクセスが集中した際に処理待ちが増えやすいため、求める応答時間に応じた余裕も必要になる。これはMuseの実際の内部構成を推定する式ではなく、元記事の単純計算には含まれていない変数を示したものだ。

利用者ごとに専用VMを割り当てることと、利用者ごとに物理CPUコアを専有させることは別の設計判断である。複数のVMでCPUを共有すれば必要な物理CPUの数を減らせる可能性はあるが、どこまで共有しても十分な性能を保てるかは、実際の負荷を測らなければ分からない。

AD

メモリとストレージは別々に見積もる

CPUの同時稼働率が10%になったとしても、RAM需要まで自動的に800PBから80PBへ減るわけではない。処理をしていないVMでも、OSや作業途中の状態をメモリ上に残すのであれば、その分の容量を確保する必要がある。CPUを使う時間を分散できることと、メモリを解放できることは別の問題だ。

たとえば1億人のうち10%が稼働中で8GBを使用し、残る90%の待機中VMにも1GBずつ常駐させると仮定する。この場合、必要なRAMは80PB＋90PBで170PBとなる。

待機中の1GBという数字は説明のための仮定であり、Museの実測値ではない。それでも、同時稼働率だけでは必要なメモリ量を決められない理由は分かる。待機中のVMをどこまで小さくできるかが、利用者数の増加に伴って重要になる。

メモリ上の状態をストレージへ退避する仕組みは、すでにクラウドで実用化されている。Amazon EC2の休止機能では、RAMの内容をEBSのルートボリュームへ保存し、再開時に読み戻して処理を続けられる。休止中はインスタンスの利用料金が発生せず、保存先のストレージ容量に対して料金がかかる。状態を保持することと、CPUを動かし続けることを切り離す具体例だ。

ただし、Museがこの方式を採用していると公表されたわけではない。休止したVMはそのままでは処理を実行できないため、予定時刻や外部イベントに応じて再開する仕組みが必要になる。頻繁に起動すれば状態を読み戻す処理が増え、長時間休止させれば応答までの時間が延びる。メモリを節約する設計は、利用者が許容できる待ち時間と合わせて考える必要がある。

ストレージの10EBについても、利用者が実際に保存するデータ量とは分けて考えなければならない。仮に平均使用量が10GBなら、1億人分の利用者データは1,000PB、つまり1EBになる。これも規模感を見るための仮定であり、Metaの実使用量を示した数字ではない。

一方、実際の設備にはOSや管理用データも必要で、障害に備えた複製やバックアップも加わる。

Metaの設計説明では、VM内のデータを継続的にバックアップするとしている。利用可能な100GBをそのまま利用者数分の物理SSDとして用意する計算も、利用者が保存したファイルだけを見て設備容量を決める方法も正確ではない。メモリでは「どれだけを同時に保持するのか」、ストレージでは「何を、何世代・何部保存するのか」をそれぞれ考える必要がある。

AIの推論以外にもCPUを使う

MuseのVMには、Webブラウザを動かしたり、コードを実行したりする仕事がある。Metaが公表した構成では、利用者ごとの作業領域に加え、認証情報を扱うサービスや、操作・通信を監視するSentinelが存在し、永続的なアプリの状態はPostgresに保存される。一方、AIモデルの推論はVM外部の基盤へ接続して実行される。利用者ごとのVMだけで、AIに必要なすべての計算を処理する構成ではない。

この役割分担を見ると、AIの普及によってCPU需要が改めて注目される理由も分かる。AIモデルが「次に何をするか」を決めた後には、実際にプログラムを動かし、その結果を読み取り、次の操作へ進む処理が続く。

たとえば旅行の手配をAIに任せる場合、文章を生成するだけでなく、予約サイトを開き、条件を入力し、検索結果を読み取り、必要な情報を保存する処理が発生する。任せる仕事が長時間に及べば、その間の作業状態も保持しておかなければならない。

そのため、AIモデルの推論を高速化・低コスト化するだけでは、個人向けAIエージェント全体の運用コストは決まらない。VMを動かす時間やデータの保存容量も必要になり、処理に失敗してやり直せば、その両方の消費量が増える。

サービス全体の効率を評価するなら、生成した文章の量だけではなく、利用者から頼まれた仕事を一つ完了させるまでに、どれだけ計算資源を使い、どれだけ時間がかかったのかを見る必要がある。

CPUとGPUの需要を一定の比率で結び付けることも難しい。短い文書を作成する依頼と、複数のWebサイトを長時間巡回する依頼では、AIモデルの推論とブラウザ処理に使われる計算資源の比率が異なるからだ。

Museの利用者が増えれば、こうした新しい種類の処理が大量に発生する可能性がある。しかし、それを特定のCPUの販売個数へ換算するには、利用者がAIに実際にどのような仕事を任せるのかという情報が欠かせない。

AD

MetaのCPU調達と普及を支える条件

MetaはMuseを公開する以前から、CPUの調達先を広げている。AWSは4月24日の発表で、Metaとの契約に基づく導入が数千万のGravitonコアから始まると説明した。対象はAIを含むMetaのさまざまな処理で、複数段階にわたるAIエージェントの処理も用途として挙げられている。

ここで示されているのはCPUの「個数」ではなく「コア数」であり、Muse専用の発注数でもない。

AWSの説明には、Nitro基盤のベアメタル環境上でMetaが自社の仮想マシンを動かせることも含まれている。物理サーバーの資源をまとめて確保し、その上にMeta自身のサービス基盤を構築するという話だ。そのため、一般消費者向けのクラウドPC料金を単純に1億人分掛けても、Metaの実際の運用コストにはならない。

Armが3月24日に発表したArm AGI CPUでも、Metaは主導パートナー兼共同開発者と位置付けられている。Metaのアプリ群を支える基盤を最適化し、独自AIアクセラレーターのMTIAと組み合わせる構想だ。

これらはいずれも9月のMuse公開より前から進んでいた取り組みであり、Museの公開後の利用拡大によって契約が生まれたと解釈することはできない。それでも、AIエージェントを動かすためのCPU基盤へMetaがすでに投資を進めていたことは確認できる。

9月8日のMuse発表では、WhatsAppからMuseを利用できることも発表されている。普段使っているアプリからAIに仕事を依頼できる入口が用意される一方、日本での提供時期は未定だ。

利用者が増えるほど、設備計画で重要になるのは登録者数そのものよりも、アクセスが集中する時間帯に何人分の処理が同時に走るのかという点だ。

Museに必要なインフラの規模を考えるうえで重要なのは、ピーク時の同時稼働数、待機中に保持するメモリ量、利用者1人当たりの平均ストレージ使用量である。さらに、仕事を依頼してから完了するまでの時間も合わせて見れば、計算資源を節約した代わりに利用者の待ち時間が増えていないかも分かる。

待機中のコストを抑えながら、必要なときにはすぐに処理を再開できる仕組みを構築できるかどうか。それが、利用者ごとに専用の作業環境を持つAIエージェントを大規模に普及させるための重要な条件になる。