OpenAIのMac大量購入から考える、Agent CloudとAIDCの次のボトルネック
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.09.23.4
- 記事内容のSHA-256
d28b1d9f2706724a4fd00f1b00b298df26d664ffa5921e28187b9d86d3dcf132- 保存版のSHA-256
780d18b16d1619dbf0a84df60be2012c38b439bf128f1bcb01b49dbdeb680722
外部証明の最終検査結果は詳細を開くと表示します。
OpenAIのMac大量購入から考える、Agent CloudとAIDCの次のボトルネック
#OpenAIが数万台規模のMac miniとMac Studioを購入している――。 The Informationによれば、OpenAIはMac miniとMac Studioを数万台規模で取得し、主に強化学習やComputer-Use Agentの訓練に利用しているという。AnthropicもAWS経由でMac miniを利用していると報じられている。これはOpenAIやAppleが正式に台数を発表したものではないため「数万台」という数字自体は報道ベースだが、事実ならかなり異例の規模である。(The Information)
#このニュースを最初に見たとき、私はCodexやChatGPT Workのような機能をMac環境で学習・検証するためではないかと考えた。
#実際、Codexアプリは2026年2月2日にまずmacOS向けとして公開され、その約1か月後の3月4日にWindows版が追加された。Codexは単なるコード生成アプリではなく、複数のAgentを並行して動かし、長時間の仕事を任せるための「Agentの司令塔」として設計されている。(OpenAI)
#したがって、Mac上で実際にAgentを動かし、Xcode、Safari、Terminal、ファイルシステム、各種アプリを操作させ、その成功・失敗を集めるという用途は非常に自然である。
#しかし調べていくと、このMac大量購入にはもう一つ、より構造的な理由が見えてくる。 それは、
#macOSを大規模なAgent実行環境として用意しようとすると、物理的なApple製ハードウェアから逃げにくい
#という問題である。
##
モデルだけではAgentにならない
#これまでの生成AIは、巨大なGPUクラスタにモデルを置けばよかった。 ユーザーが入力する。 モデルが推論する。 結果を返す。 非常に単純化すれば、
#GPU／ASIC＋HBM＝AI
#だった。
#しかしAgentでは違う。 Agentは推論した後に、 ファイルを読む。 コードを書く。 ブラウザを開く。 アプリを操作する。 ビルドする。 テストする。 失敗したらやり直す。
#つまりAIに「仕事をする場所」が必要になる。
#OpenAI自身も2026年3月、Responses APIにhosted container workspaceとshellを組み込み、「モデルにコンピュータ環境を与える」ことをAgent化の重要な要素として説明している。そこではfilesystem、SQLite、network、Unix系ツールなどをAgentが利用し、複数のcontainer sessionを並列実行できる。(OpenAI)
#つまりAIDCには今後、
#AIの脳を動かす計算資源
#だけでなく、
#AIが仕事をする仮想PC
#まで大量に必要になる。
#ここから新しいAIインフラ需要が始まる。
##
WindowsとLinuxなら「100万PC」を物理的に置く必要はない
#Agentが100万体いるからといって、100万台のWindows PCを購入する必要はない。
#巨大なAMD EPYCやIntel Xeonサーバーを用意し、その上にVMを大量に作ればよい。
#MicrosoftのWindows Agent Arenaが分かりやすい。
#これはAI AgentにWindows 11を実際に操作させる研究環境だが、30GB程度のWindows 11 golden imageを作り、QEMU/KVM上のVMとして展開できる。ローカルではUbuntuやWSLから動かすことができ、Azure ML上では多数のWindows Agent環境を並列展開できる。(GitHub)
#つまり表面上は、
#Windows 11 Agent
#でも、
#その下は、
#Linux → Docker → QEMU/KVM → Windows 11
#という構造にできる。
#ここが非常に重要である。
#Windows自体には当然ライセンスが必要だ。
#Azure Virtual Desktopでも、Windows 10/11 EnterpriseやMicrosoft 365、Windows VDAなど、用途に応じた利用権が必要になる。Windows Serverの場合もライセンス体系が存在する。
#しかしMicrosoftのWindows Server Datacenterでは、物理コアを適切にライセンスしたサーバー上で無制限のWindows Server VMを実行できる仮想化権が用意されている。(Microsoft)
#つまりWindowsの制約は主として、
#「ソフトウェア利用権をどう購入するか」
#である。
#ハードウェアそのものは比較的自由だ。
#AMDでもIntelでもよい。 DellでもHPEでもSupermicroでもよい。 クラウド事業者が自分で最適化したサーバーでもよい。
#極端に言えば、
#Windowsという環境だけを仮想化して取り出せる。
##
macOSではOSと物理ハードが切れない
#macOSでは事情が大きく異なる。
#Appleの現行macOS Tahoe 26標準ライセンスでは、macOSはApple-branded computerで使用することが前提となっている。また通常条件では、既にmacOSを動かしているApple製コンピュータ上で、開発・テストなどの指定用途について追加最大2つのmacOS仮想インスタンスを実行できるとしている。
#さらにAppleは、macOSを非Apple製コンピュータへインストール・実行することを認めていない。Volume LicenseやAppleとの個別契約では条件が変わり得るため、大規模AI企業が必ず「2 VM」という条件で運用しているとは断定できない。しかし、macOSとApple製ハードウェアが強く結び付いていること自体は変わらない。
#AWS EC2 Macを見るとさらに分かりやすい。
#普通のEC2 VMとは違い、EC2 MacはDedicated Host上のbare-metal Macとして提供され、Dedicated Host一つにつきMac instanceは一つ、最低24時間の割り当て期間が設定されている。(AWS Documentation)
#要するに、
#Mac Cloudを作るためには、その下に本物のMacがいる。
#Windows Cloudなら、
EPYC
↓
Windows VM
Windows VM
Windows VM
Windows VM
とできる。Linuxならさらに軽く、
EPYC／ARM
↓
Container
Container
Container
Container
Container……
とできる。しかしmacOSでは、
Mac mini／Mac Studio
↓
macOS
↓
macOS VM
という物理的な床が残る。OpenAIが数万台のMacを必要としている理由を考えるとき、Unified MemoryのAI性能以上に、この制約は重要ではないかと思う。
##
一見するとAppleには巨大な追い風に見える
#ここだけを見ると、Appleには非常に有利だ。
#これまでは人間一人がMacを一台買えばよかった。
#Agent時代には、 人間が使うMac に加えて、 Agent学習用Mac Agent評価用Mac CI/build用Mac Cloud Mac Computer-Use Agent用Mac まで必要になる可能性がある。
#つまりAppleは、ユーザーだけではなくAIそのものを新しいMac利用者にできる。
#世界中にMacユーザーが存在し、Mac用アプリ、Safari、Xcode、Swift、macOS固有APIが存在する限り、OpenAIやAnthropicはmacOSを完全には無視できない。
#その最低限の互換性を確保するだけでも、数万台単位のMac需要が発生し得る。
#短期的には非常に強い。
#しかし私は、これをAppleの巨大な新TAMとそのまま考えることには慎重である。
#理由は、
#AIが巨大すぎるからだ。
##
AI時代では「計算資源効率を下げる制約」が致命傷になる
#クラウドコンピューティングが20年以上かけて追求してきたのは、
#一つの物理計算資源を、できるだけ多くの仕事へ使うこと
#だった。
#1台のPCに1 OS。 そこから、 1 Serverに数十VM。 さらに、 1 Serverに数百Container。 そしてServerless。
#物理ハードウェアを利用者から切り離し、CPU、RAM、Storage、Networkを必要な分だけ切り出す方向へ進んできた。
#AI時代には、この最適化圧力がさらに強くなる。
#なぜならAgentは一人一体では終わらないからだ。
#一人が10 Agentを動かす。 企業が1万Agentを動かす。 サービス全体で100万Agentが同時稼働する。 さらに将来は1000万Agentになるかもしれない。
#この世界では、
#1%の計算資源ロスですら巨大な金額になる。
#CPUが余っている。 RAMも余っている。 GPUも余っている。
#しかしライセンスやOSの制約のために、新しい物理マシンを追加しなければ次の環境を作れない。
#これはAIインフラ設計から見ると極めて嫌な性質である。
#最初の数万Agentなら問題にならない。
#100万、1000万へスケールした瞬間、
#「そのOSでなければならない理由」そのものが最適化対象になる。
##
Macを増やすのではなく「Macを使う時間を減らす」
#ここから重要な変化が起きる。
#例えばiOSアプリをAgentに作らせるとしても、全工程をMacで実行する必要はない。
#コード生成。 仕様解析。 画像処理。 Git操作。 依存関係調査。 Unit Testの一部。 ドキュメント生成。 Web検索。 バックエンド処理。
#これらの多くはLinuxでできる。
#最終的なXcode build、Simulator、Safari/macOS固有テスト、署名など、
#どうしてもMacでなければならない部分だけMacへ送ればよい。
#最適化されたAgent Cloudは、 90分 Linux 8分 Windows 2分 macOS のようなSchedulerへ向かう可能性がある。
#この場合、Agent市場そのものが100倍になっても、Macを使用する割合が20分の1になれば、Mac側の需要は5倍にしかならない。
#つまりMacが取り込めるTAMは、
#全Agent TAMではない。
#より正確には、
#Agent TAM × macOSでしか実行できない時間
#である。
#この「macOS必須時間」が将来どこまで圧縮されるかが、Appleにとって非常に重要になる。
##
100万Agentが動くと何が必要になるのか
#簡単なモデルを置いてみる。
#100万Agentを、 70%：軽量Agent 2 vCPU / 8GB RAM / 10GB workspace 25%：標準Agent 4 vCPU / 16GB / 30GB 5%：重量Agent 8 vCPU / 32GB / 100GB と仮定する。
#すると100万同時Agentは概算で、
#280万vCPU 約11.2PBの論理RAM 約19.5PBの作業Storage
#を要求する。
#Agentは常時CPUを100%使うわけではないため、仮に4:1程度のvCPU oversubscriptionが可能なら、物理CPUコアは約70万coreになる。
#超高密度サーバーと数TB級DRAMを組み合わせれば、数千台規模のサーバーへ圧縮できる可能性がある。
#ここで見えてくるのは、Agent Cloudの巨大TAMが「PC完成品市場」だけではないということである。
#従来、
#AIDC＝GPU＋HBM
#と考えがちだった。
#しかしAgent時代には、
#AIDC＝GPU＋HBM＋CPU＋DDR＋NAND＋Network＋大量の仮想コンピュータ
#へ変化する。
#これは非常に大きな違いである。
##
最大のボトルネックはGPUだけではなくなる
#この世界で面白いのは、CPU性能が毎世代上がっても、DRAM需要が簡単には消えないことだ。
#100万個の独立環境を作れば、それぞれに、 OS state filesystem browser state repository application memory cache temporary data が必要になる。
#CPUはoversubscriptionできる。
#Agentがモデルの返答を待っている間はCPUを別Agentへ渡せる。
#しかし、RAMに保持している状態やpersistent workspaceは簡単には消せない。
#そのためAgent Cloudでは、
#CPUよりDRAM容量がボトルネックになる可能性
#がある。
#同様にSSDも重要になる。
#OpenAIの現在のAgent向けcomputer environment自体、filesystemをAgentのworking contextとして使い、入力ファイル、中間データ、データベース、生成物などをcontainer内に置く構造になっている。(OpenAI)
#Agentが長時間化すればするほど、このstateは増える。
#したがってAgent時代は、HBMだけでなく、
#DDR5/DDR6 Enterprise NAND NVMe SSD
#への需要が強まる可能性がある。
##
Windowsは残る。しかし裏側ではLinuxが勝つ
#ではWindowsはどうなるのか。
#Macよりはかなり有利である。
#Windowsには巨大な企業アプリ市場がある。
#Excel。 PowerPoint。 Adobe系ソフト。 企業内legacy application。 Windows専用業務ソフト。
#したがってWindows Agentにも相当大きな市場が残るだろう。
#しかしWindowsがAgentインフラそのものを支配するとは限らない。
#先ほどのWindows Agent Arenaのように、
Linux host
↓
Container
↓
QEMU/KVM
↓
Windows VM
でWindows環境だけを切り出せるからだ。([OpenReview](https://openreview.net/pdf?id=W9s817KqYf&utm_source=chatgpt.com))さらにAgentが賢くなるほど、 ExcelをGUIでクリックする より、 xlsxを直接操作する。
#PowerPointをGUIで作る より、 pptxを直接生成する。
#アプリをクリックする より、 APIを呼ぶ。
#という方向へ進む。
#つまり、
#GUI → API / CLI / File Format
#への移行が起きる。
#そしてAPI、CLI、Containerの世界ではLinuxが圧倒的に強い。
#OpenAIが現在Agent用computer environmentにUnix shellとhosted containerを採用していることも象徴的である。(OpenAI)
#AnthropicのComputer Useデモ環境もUbuntu 22.04ベースのDocker containerにFirefox、LibreOffice、X11、ファイルマネージャなどを載せる構造になっている。(GitHub)
#表面ではWindowsやMacを操作していても、
#Agentインフラの地下ではLinuxが増え続ける。
#これは十分あり得る未来だと思う。
##
Linuxが強い理由は「Linuxブランド」ではない
#LinuxがAI時代に強い理由は、Linuxそのものが人気だからではない。
#削れるからだ。
#GUIがいらなければ消せる。 Audioがいらなければ消せる。 Browserだけ必要ならBrowserだけ載せる。 Pythonだけ必要なら小さなContainerにする。 より強い隔離が必要ならmicroVMにする。 GPUが必要ならGPU containerを割り当てる。 CPUだけならCPUだけにする。
#つまり、
#WorkloadにOSを合わせられる。
#これがAI時代には非常に強い。
#macOSのように、
#WorkloadをPlatformの制約へ合わせる
#構造とは逆である。
#計算資源として最終的に残るのは、ブランドではなく、
#制約の中で最も高効率に仕事を処理できるもの
#だからだ。
#GPUも同じだ。
#すべてを一種類のGPUで処理するのではなく、 Training向け。 Prefill向け。 Decode向け。 Embedding向け。 Video向け。 Network向け。
#用途ごとに最適化が進む。
#OSも同じ方向へ進むと考える方が自然である。
##
Appleにとって短期的な追い風、長期的な圧縮圧力
#したがって今回のOpenAIによるMac大量購入は、二つの全く違う意味を持っている。
#短期的には、
#macOSの閉じた構造がAppleに物理Mac需要を強制する。
#これはAppleに有利である。
#Mac Userが一定数存在する以上、AI企業はmacOS Agentを作らなければならず、そのためApple hardwareを確保する。
#しかし長期的には、
#その物理制約こそがMac使用時間を削減するインセンティブになる。
#Macが高い。 MacのVM密度を上げにくい。 汎用Serverへ移せない。
#ならば、
#「Macでなければできない処理は何か」
#を徹底的に分解する。
#そしてそれ以外をLinuxへ移す。
#AIは巨大である。
#巨大であるほど1%の非効率が問題になる。
#結果として、
#Macを大量に使う
#ことではなく、
#Macを最低限しか使わない
#ことが最適解になり得る。
#ここに短期と長期の逆転がある。
##
Apple自身も完全な閉鎖型Computeだけでは進んでいない
#ただし、この議論から「Apple SiliconはAIDCでは生き残れない」とまで断定するのは早い。
#Apple自身のPrivate Cloud ComputeはApple Siliconベースのサーバーを利用してきた。
#一方でAppleは2026年、PCCをApple自身のデータセンター外へ拡張し、Google CloudとNVIDIAを利用して新しいApple Intelligence workloadを実行する方針も明らかにしている。(Apple Security Research)
#つまりApple自身も、
#すべてを自社チップ、自社データセンターだけで完結させる
#のではなく、巨大化するAI需要に対して外部のスケーラブルな計算基盤を組み合わせ始めている。
#これは非常に象徴的だ。
#将来AppleがMac virtualization条件を大幅に変更したり、Agent Cloud向けApple Silicon serverを本格展開したりすれば、この分析は大きく変わる。
#逆に現在のようにApple hardwareとの強い結合を残すなら、macOSは巨大Agent市場全体を取るのではなく、
#Apple互換性が必要な最後の数%を担う高価格な特殊Compute
#へ向かう可能性がある。
##
Agent時代のAIDCは「仮想PC工場」になる
#従来のAIDCは、 AIを学習する工場だった。
#次のAIDCは、 AIを推論する工場になった。
#そしてAgent時代には、
#AIが働く仮想コンピュータを大量生産する工場
#になる。
#そのとき重要になるのは、GPUだけではない。
#CPU。 DRAM。 SSD。 Network。 Hypervisor。 Container。 Sandbox。 Scheduler。 OS license。 そして一部では実物のMacまで必要になる。
#しかし最も重要なのは、
#どの仕事をどの環境へ割り当てれば最も安く処理できるか
#というSchedulerである。
#最終形はおそらく、
Agent
↓
Scheduler
↓
OS非依存処理 → Linux container / microVM
Windows固有処理 → Windows VM
Apple固有処理 → macOS / physical Mac
推論 → GPU / TPU / AI ASIC
という分業になる。この構造では、Macがなくなるわけではない。
#むしろMacユーザーが存在する限り、一定のMac Compute TAMは残り続ける。
#しかし、
#Agent市場全体の成長率とMac Compute市場の成長率は同じではない。
#AI市場が巨大になるほど、Macである必要のない仕事をMacから追い出す経済圧力も巨大になるからだ。
##
結論――AI時代に勝つのは「最も自由に最適化できる計算資源」
#OpenAIが数万台のMac miniとMac Studioを購入したというニュースは、一見するとApple SiliconがAIインフラ市場へ本格進出したようにも見える。
#しかし私はむしろ逆のものを見ている。
#これは、
#macOSという環境をAIに与えるためには、今なお物理的なApple hardwareが必要になる
#ことを可視化したニュースではないだろうか。
#その制約は短期的にはAppleへMac需要をもたらす。
#しかしAIは巨大すぎる。
#100万、1000万のAgentを動かす世界では、利用率を下げる制約そのものがコストになる。
#そしてコストになったものは最適化される。
#Macが必要ならMacを増やす。
#しかしその次には必ず、
#Macを使わなくてもよい仕事をMacから外す
#という最適化が始まる。
#Windowsも同じ圧力を受ける。
#GUIそのものが不要になり、API、CLI、File Formatへ処理が移れば、その裏側はLinux containerへ集約できる。
#結果として、ユーザーの目に見える世界では、 Mac。 Windows。 各種アプリ。 が残り続けても、
#その地下では、
#Linux GPU / AI ASIC Server CPU DRAM NAND Ethernet
#がAgent社会を支える巨大な基盤になっていく可能性が高い。
#AI時代に最も強い計算資源とは、最もブランド力のある計算資源ではない。
#最も高性能な一種類のチップでもない。
#用途ごとに分解され、 必要なものだけを残し、 余計なものを削り、 最大限の密度でスケールできる計算資源である。
#OpenAIの数万台のMacは、AppleのAI勝利を示すニュースであると同時に、
#AI時代には「OSの物理的制約」までが計算資源の経済性として評価されるようになった
#ことを示すニュースなのかもしれない。
#以下をそのまま前の記事の「Agent時代のAIDCは『仮想PC工場』になる」の前後に追加できる定量章としてまとめます。特に、1億Agentまで行くと「VMを増やせばよい」という発想そのものが破綻し、DRAM・NAND・OS依存時間を削ることが必須になる点を中心にしています。
#追記――100万→1000万→1億Agentで、AIDCは何をどれだけ必要とするのか
#ここまでの議論を数量へ落としてみる。
#仮に、2027年に100万体、2028年に1000万体、2030年に1億体のAgentが同時に存在する世界を考える。
#ここでいう「同時Agent」は、すべてがCPUを100%使用しているという意味ではない。
#あるAgentはモデルの推論結果を待ち、あるAgentはWebサイトからの応答を待ち、あるAgentはファイルを書き込み、あるAgentはユーザーから次の指示を待っている。
#したがって、
#論理的に存在するAgent数
#と、
#その瞬間にCPU・DRAMを実際に消費しているAgent数
#は一致しない。
#この差をどこまで広げられるかが、Agent Cloudの経済性を左右する。
#現在の実例として、Amazon Bedrock AgentCoreのCode Interpreterは1セッションあたり 2 vCPU、8GB RAM、10GB disk を割り当てている。これは現在の比較的軽量なAgent実行環境の基準値として使える。(AWS Documentation)
#OpenAIもResponses APIにhosted container workspaceを組み込み、Agentごとにfilesystemやshell、networkなどを持たせ、必要に応じて複数container sessionを並列実行する構造を採用している。(OpenAI)
#つまりAgentが巨大化するときに増えるのはGPUだけではない。
#Agent一体ごとに存在する「小さなコンピュータ」そのものが増える。
#100万→1億Agentの前提
#ここではAgentを軽量、標準、重量の3種類に分け、平均的な実行環境を次のように置く。
#Agent自体は高度化するため、一体あたりの要求リソースは少し増える。
#一方でmacOS比率は、
#5% → 3% → 1%
#へ低下すると仮定する。
#これはMac市場が縮小するという意味ではない。
#Agent Cloud側が、 コード生成 → Linux Web処理 → Linux データ処理 → Linux 一般的なbrowser task → Linux Windows固有アプリ → Windows Xcode、macOS固有検証 → Mac というように処理を分解し、
#Macを必要とする時間そのものを圧縮していく
#と考えるからである。
##
まず「何も最適化しなかった世界」を考える
#もしAgent一体ごとに専用PCのようなVMを与え、そのRAMをすべて常時確保するとどうなるだろうか。
#Windows/Linux側だけで計算すると、
#2030年には、
#DRAM約1.7EB
#である。
#1EBは1000PBである。
#つまり、たった1億個の「PCに近いAgent環境」を単純に常駐させるだけで、
#1700PBものDRAM
#が必要になる。
#Workspaceも約4EBに達する。
#ここにはモデルweight、training data、embedding database、ユーザーのpersistent storageなどは含んでいない。
#単なるAgentの作業机だけである。
#この数字を見ると重要なことが分かる。
#1億Agent時代は、現在のVM設計をそのまま100倍、1000倍にするだけでは成立しない。
##
だから「Agentを眠らせる技術」が重要になる
#実際のAgentはCPUを常時使わない。
#モデル推論を待つ。 ネットワークを待つ。 APIを待つ。 人間を待つ。
#その間、Agent専用にCPU coreを固定しておく必要はない。
#そこで、 2027年：4 vCPUを1 physical coreへ集約 2028年：5 vCPU / core 2030年：8 vCPU / core 程度までoversubscriptionが進むと仮定する。
#さらにDRAMについても、 2027年：論理RAMの60%を物理常駐 2028年：40% 2030年：20% まで下げる。
#残ったstateは圧縮、共有memory、snapshot、NAND、remote memoryなどへ逃がす。
#これを入れると必要設備は次のようになる。
#ここでは15%程度のcapacity reserveも含めている。
#Server密度については、2027年約320 physical core/server、2028年480、2030年720相当まで高密度化すると仮定した。
#現在でもAMD EPYC 9005は1 socket最大192 core、12 channel DDR5を提供しているため、将来世代と複数socket、より高密度なrack設計を考えれば、この方向そのものは不自然ではない。(AMD)
#ただし2030年の値は製品ロードマップを断定するものではなく、Agent Cloudの規模を考えるためのモデル上の仮定である。
##
CPUより先にDRAMが問題になる
#この結果で非常に面白いのはCPUである。
#Agent数は、
100万
↓
1000万
↓
1億
と100倍になる。しかしCPUはwaiting timeを他のAgentと共有できる。
#Agent Aがモデルを待っている時間にAgent Bを走らせる。
#Agent Bがnetworkを待っている時間にAgent Cを走らせる。
#つまりCPUは比較的高いoversubscriptionが可能である。
#一方、難しいのがmemoryである。
#Agentが止まっていても、 開いていたrepository browser session database application state temporary files 認証状態 作業途中のデータ などは残しておかなければならない。
#だから、
#Computeは共有できてもStateは消えない。
#2030年の1億Agentを単純常駐させれば約1.7EB DRAMになる。
#そこで80%をDRAMから追い出したとしても、まだ約392PBの物理DRAMが必要になる。
#これはAgent Cloudにおいて、
#Server CPU以上にDRAM容量が重要になる
#可能性を示している。
##
DRAMから追い出したStateはどこへ行くのか
#もちろん消えるわけではない。
#多くはNANDへ行く。
#つまり、
DRAM最適化
↓
NAND需要増加
という関係が生まれる。Agentを休止させると、 Memory image Filesystem Browser state Application state Repository Cache Checkpoint などをSSDへ書き出す。
#そしてAgentを再開するときに読み戻す。
#このモデルでは2030年に必要なRuntime NANDだけで、
#約3.2EB
#になる。
#しかもこれはユーザーの長期保存データやAI training storageを除いている。
#したがってAgent時代には、
#HBM → DDR → NAND
#というmemory hierarchy全体への需要が増える可能性がある。
#GPU/ASICがAIの思考を担当する。 DDRが現在作業中のAgentを保持する。 NANDが休止中Agentの状態を保持する。
#この三層構造になる。
##
1億Agentは「DRAMを増やす」のではなく「DRAMに置かない」競争になる
#ここは非常に重要だ。
#1億Agentをすべて17GB RAMのVMとして常駐させる世界では、約1.7EB DRAMが必要になる。
#これはあまりに大きい。
#したがって2030年のAgent Cloudは、
#RAMを大量購入するだけでは成立しない。
#技術競争そのものが、
#「Agent一体あたり何GB必要か」
#から、
#「Agentを何GBしかDRAMに置かずに済むか」
#へ移るはずである。
#例えば、 OS imageは共有。 Libraryも共有。 Browser binaryも共有。 読み取り専用layerは共有。 Agent固有の差分だけ保持。 休止中AgentはNANDへ。 さらに長期休止ならobject storageへ。 必要になった瞬間だけmicroVMを立ち上げる。
#こうすると、
#1 Agent = 1 PC
#ではなく、
#1 Agent = 小さなState + 必要時だけ起動するCompute
#へ変化する。
#ここまで行くとAgent infrastructureは、従来のPC Cloudではなく、
#Serverless Computer Cloud
#に近づいていく。
##
Mac需要は「Agent数」より「Mac必須比率」で決まる
#次にMacを見る。
#ここでは便宜的に、
#1 physical Macあたり2つのactive macOS環境
#を処理できるものとし、さらに15%の予備capacityを入れた。
#これはOpenAIの実際の契約条件を示す数字ではない。
#Appleの標準macOSライセンスではApple製ハードウェアとの結合があり、通常条件では指定用途について最大2つの追加仮想macOS環境が認められている一方、service bureauなどには別の制約があり、Volume LicenseやAppleとの個別契約では条件が変わり得る。(Apple)
#AWS EC2 Macも現在、Dedicated Host上のbare-metal Macとして提供され、1 HostあたりMac instance一つという特殊な構造を取っている。(AWS Documentation)
#そのためここでは、法的上限ではなく「実効的なMac環境密度」の仮定として2環境/Macを使用する。
#この場合、
#2027年 100万Agent × Mac比率5% → 5万macOS Agent → 約2.9万Mac
#2028年 1000万Agent × 3% → 30万macOS Agent → 約17万Mac
#2030年 1億Agent × 1% → 100万macOS Agent → 約58万Mac
#となる。
#一見すると58万台は巨大である。
#しかしAgent市場全体は、
#100万 → 1億＝100倍
#になっている。
#Macは、
#約2.9万 → 約58万＝約20倍
#にしか増えていない。
#理由はMac依存率を5%から1%へ圧縮したからだ。
#つまり、
#Agent市場の成長率 ≠ Mac TAMの成長率
#になる。
##
Mac比率が0.1%まで落ちればさらに違う
#2030年に1億Agentが存在するとして、Mac依存率だけを変えてみる。
#ここにAppleの長期的な問題がある。
#Agent市場が100倍になっても、macOS依存率が、
5%
↓
0.1%
まで圧縮されれば、Macは2027年約2.9万台から2030年約5.8万台へ、
#わずか2倍程度
#にしかならない。
#Agent市場100倍に対してMac需要2倍である。
#逆にmacOS必須処理を5%残せれば約288万台になる。
#したがってAppleにとって重要なのは、
#Agent市場そのものを拡大することではない。
#AgentがmacOSでなければできない仕事をどれだけ残せるか
#である。
##
これはAppleにかなり厳しい競争になる可能性がある
#なぜならAIDC事業者にとっては逆のインセンティブがあるからだ。
#Macを使うと高い。 物理Macが必要になる。 Rack densityを最適化しにくい。 VM密度にも制約がある。 汎用EPYC serverへ移せない。
#ならば、
#Macである必要のない処理を全部Linuxへ移そう
#となる。
#Agent schedulerそのものが、
#「この仕事はMacでなければならないか」
#を判断するようになる可能性すらある。
#例えばiOSアプリ開発Agentでも、 仕様解析 コード生成 Git操作 Backend test 画像処理 documentation dependency analysis などはLinuxで行い、
#最後の、 Xcode build Simulator test Safari verification signing だけMacへ送る。
#MacはAgentのメインコンピュータではなく、
#特殊なacceleratorのような扱い
#になっていく。
#GPUを必要な処理だけGPUへ送るのと同じように、macOSが必要な処理だけMacへ送る。
#これはMac Compute TAMを大幅に圧縮する。
##
Windowsにも同じ最適化圧力がかかる
#ただし、この問題はAppleだけではない。
#Windowsもまた、Windowsそのものを操作する必要のない仕事をLinuxへ奪われる。
#Excelのセルをクリックするより、xlsxを直接編集する。
#PowerPointをGUI操作するより、pptxを生成する。
#Browserで管理画面を操作するより、APIを呼ぶ。
#GUIが人間のためのinterfaceである以上、Agentが十分賢くなれば、
#人間用interfaceを経由しない方が効率がよい。
#その結果、 macOS固有処理 → Mac Windows固有処理 → Windows VM それ以外 → Linux/container という構造が強まる。
#そしてWindows VMの下側もLinux/KVMで動かすことができる。
#最終的に最も巨大になるのは、
#OS固有環境ではなく、そのすべてを支える汎用AIDC
#である。
##
2030年に最大のTAMになるのは何か
#このモデルをそのまま読むと、1億Agent時代の追加TAMは非常に大きい。
#しかしその分布は従来のPC市場とは違う。
#ここには推論用GPU、TPU、AI ASIC、HBMを含めていない。
#つまり実際のAIDCではこの下にさらに、 GPU / ASIC HBM Scale-up network Scale-out Ethernet Optical Power Cooling が乗る。
#Agent時代とは、
#GPU需要の次にPC需要が来る
#というより、
#PCを構成していた機能そのものがAIDCへ吸収される
#時代なのだと思う。
#CPU。 DRAM。 SSD。 Filesystem。 OS。 Browser。 Application。 Network。 Identity。 Security。
#これらがAIDC内部へ移動する。
##
そして新しい最大ボトルネックは「State」になる
#LLM時代の中心的な問題は、
#Compute
#だった。
#巨大な行列演算をどれだけ高速に処理できるか。
#だからGPUとHBMが重要になった。
#Agent時代にはそこへ、
#State
#が加わる。
#100万、1000万、1億体のAgentが、
#「自分が今何をしていたのか」
#を保持しなければならない。
#1億Agentがそれぞれ、 Browser Filesystem Repository Application Authentication Task progress を持つ。
#そのStateをすべてDRAMへ置くことはできない。
#だから、
DRAM
↓
CXL / memory pooling
↓
NVMe SSD
↓
Object Storage
という階層化が進む可能性が高い。そしてAgentが起きたり眠ったりするたびに、大量のStateがこの階層を移動する。
#そのため将来的には、
#Memory capacity
#だけでなく、
#State migration bandwidth
#そのものがAIDCの重要な性能指標になる可能性がある。
##
1億Agent時代では「制約を持つCompute」が淘汰圧力を受ける
#この数量モデルから最も重要なのは、個別の予測数字ではない。
#スケールが変わると、
#計算資源効率を阻害する制約の意味が変わる
#ことである。
#1000台なら多少余っていてもよい。
#1万台でも許容できる。
#しかし1億Agentになれば、1%の無駄が100万Agent分になる。
#だから、 独立VMを持つ必要があるのか。 Windowsである必要があるのか。 Macである必要があるのか。 GUIを使う必要があるのか。 16GB RAMを常駐させる必要があるのか。 専用CPU coreを持つ必要があるのか。
#そのすべてが再検討される。
#そして最終的には、
#用途ごとに最も制約が少なく、最も細かく分割でき、最も高密度に実行できる計算資源へ仕事が移動していく。
#この意味で、OpenAIによる数万台のMac購入はAppleの巨大な新市場の始まりである可能性と同時に、
#Agent Cloudがスケールしたとき、閉じたOSと物理ハードウェアの結合がどれほど大きなコストになるかを初めて可視化した出来事
#なのかもしれない。
#100万AgentではMacを買えば解決できる。
#1000万AgentではMacを使う仕事を分解し始める。
#1億Agentでは、
#Macでなくてもできる処理をMacで実行すること自体が許されないほど、計算資源効率が重要になる。
#そしてその最適化の行き着く先では、表側にはMacやWindowsが残っていても、その地下には、 Linux GPU / AI ASIC Server CPU DRAM NAND Network という巨大な汎用計算基盤が広がっている。
#AIが巨大になるほど、ブランドではなく、
#どれだけ自由に分割し、共有し、眠らせ、再開し、別の計算資源へ移せるか
#が勝敗を決める。
#Agent時代のAIDCで本当に価値を持つのは、単なる「速いコンピュータ」ではない。
#1億個のコンピュータを、物理的には1億台用意せずに存在させられる仕組みそのもの
#なのである。
#この章では、現在のAWS AgentCoreの 2 vCPU / 8GB / 10GB を下限アンカーとして使い、将来部分は明示的なモデル仮定にしています。特に2030年の「392PB DRAM・3.2EB NAND」は予測値というより、1億Agent時代に何を最適化しなければならないかを見るストレステストとして読むのが適切です。
#特定銘柄の推奨・勧誘・投資助言を目的とするものではありません。投資判断はご自身の責任でお願いいたします。
#