FMS 2026 | 全4回の第1回
AIの次なる制約は、計算能力だけではない
AIにおける次なる制約は、計算能力だけではありません。次に制約となるのはメモリです。エージェントが動き続けるには、システムが大量のコンテキストを保持し、必要な場所へすばやく移動させ、効率よく再利用できなければなりません。
業界では長年、これを「メモリの壁」と呼んできました。これは、プロセッサーの計算速度と、システムがプロセッサーに効率よくデータを供給する能力との間に広がり続けるギャップを指します。この壁は、すでにAIのパフォーマンスを左右する要因となっていました。エージェント型AIでは、その重要性がさらに高まります。メモリが、コンポーネントレベルのボトルネックにとどまらず、システムレベルの設計制約となるためです。
従来の推論は、1回のやり取りを中心に設計されていました。ユーザーが質問し、モデルが回答を生成し、セッションはおおむねそこで終了します。一方、エージェントの動作はそれとは異なります。エージェントは、目標を追跡し、より多くのコンテキストを保持し、ツールを呼び出し、他のエージェントと連携し、データソースにクエリを実行しながら、複数のステップにわたって作業を続けます。こうした継続的な動作により、メモリとストレージはAIインフラの中心的な要素となります。
エージェントは、インフラが保持すべき情報を変える
この変化は、先進的なAIシステムがどのように語られているかにも、すでに表れています。Anthropicのコンピューティング責任者であるジェームズ・ブラッドベリー氏は、Claudeが単に質問に答える段階を超え、コードベース全体の読み込み、次のステップの計画、ツールの呼び出し、軌道修正を行いながら、作業を最後まで進める段階へ移行していると説明しています。こうした各ステップによって、システムが保持し、再利用しなければならないコンテキストの量は増えていきます。
これが、アーキテクチャー上の大きな転換です。エージェントの能力が高まるにつれ、インフラには、計算を高速化するだけでなく、永続的で再利用可能なコンテキストをインテリジェントに階層化して支えることが求められます。メモリとストレージはコンピュートにより近い位置で機能する必要があり、その階層構造にも、個別のレイヤーの集合ではなく、1つの連携したシステムとしての動作が欠かせなくなります。
図1：AI革命。出典：IETF、Carnegie Mellon Institute
ワンタイムAIからリアルタイムAI、そして常時稼働型AIへ
この変化は、時間という視点から捉えることができます。学習はワンタイムの処理でした。モデルを構築し、実行を完了したら、その処理はそこで終わります。推論はリアルタイムになりました。ユーザーがプロンプトを入力し、回答を待つという形です。エージェント型AIは、常時稼働型です。エージェントは、推論、APIの呼び出し、ツールの使用、データベースへのクエリの実行、他のエージェントと連携を行いながら、多くのステップにわたって作業を進め続けることができます。
この変化は急速に進んでいます。Gartnerの予測によると、2026年末までに、エンタープライズアプリケーションの最大40%に、タスク特化型のAIエージェントが統合される見込みです。これは、2025年の5%未満から大きく増加することになります。重要なのは、エージェントを追加するアプリケーションの数だけではなく、エージェントがインフラにもたらす変化です。つまり、エージェントが、単発のプロンプトを継続的な作業へと変えるという点です。
図2：GPUは推論し、CPUは実行する。出典：マイクロン
2つのスタックに共通する1つのメモリ課題
これをGPUのスケーリング問題として捉えたくなるかもしれません。しかし、より有効なのは、システム全体として捉える見方です。エージェント型AIは、メモリに制約される2つのスタックが連携して動作することに依存しています。
GPUスタックは、推論と生成を担います。そのためには、モデルの重み、アクティブなトークン、コンテキストに高速にアクセスできることが必要です。一方、CPUスタックは、オーケストレーションを担います。具体的には、ツールの呼び出し、データベースクエリ、エージェント間の連携、状態管理、モデルに関連するワークフローを処理します。エージェント型AIは、この両方に同時に継続的な負荷をかけます。
推論側が滞れば、モデルは待機します。実行側が滞れば、エージェントは待機します。いずれの場合も、ユーザーエクスペリエンスは損なわれ、リソース使用率も低下します。そのため、エージェント型AIでは、メモリの壁が2つの場面で現れます。1つは推論、もう1つは実行です。
図3：KVキャッシュのスケーリングはLLM本体を上回る。出典：スケーラブルで効率的なLLM推論のためのKVキャッシュ最適化戦略、vLLMエンジニアリングブログ
KVキャッシュが決定的な制約要因になる理由
KVキャッシュは、推論側にかかる負荷を具体的に示します。図3に示すように、25万6,000トークンのコンテキストウィンドウでは、1セッションあたり約22GBのKVキャッシュが必要になる場合があります。単独で見れば対応可能に思えるかもしれませんが、AIサービスは同時処理を前提に設計されています。インフラの使用率を維持するため、同時に多数のユーザーにサービスを提供します。
同時ユーザー数が64人になると、同じワークロードは約1.4TBまで膨らむ可能性があります。1,000人のユーザーでは、約22TBに達する可能性があります。100万トークンのコンテキストでは、1セッションあたり約88GBが必要になり、1,000件の同時セッションでは90TB近くに達する場合があります。
そのため、GPUメモリだけで全体の負荷を支えることはできません。HBMは、アクセス頻度が最も高く、アクティブなトークンに不可欠です。DRAMは、より大きなワーキングセットに必要な容量を提供できます。NANDは、永続性とスケーラビリティを支えます。設計上の課題は、パフォーマンス、容量、効率の最適なバランスが得られる場所にデータを配置し、これらの階層を連携させることです。
図4：エージェント型AIは従来型コンピューティングの100倍のトラフィックを生み出す。出典：Google（ブログ）、DigitalOcean（コミュニティ）
実行側にも独自のメモリの壁がある
実行は、2つ目の負荷要因となります。エージェントは推論するだけではありません。行動もします。APIを呼び出し、ドキュメントを検索し、データを取得して、計画を更新するとともに、ツールをまたいで作業を調整します。それぞれのアクションにより、GPUスタックの外側でメモリ移動とストレージアクセスが発生します。
これにより、CPUスタック周辺のトラフィックパターンが変わります。従来型アプリケーションでは、ユーザーリクエストをきっかけにアクティビティが一時的に集中することがあります。一方、エージェント型ワークロードでは、このアクティビティが多くのステップにわたって継続します。その結果、従来のフローに比べて、ツール呼び出し、データベースクエリ、ドキュメントストアへのアクセスがはるかに多く発生します。
したがって、GPUを増強するだけでは解決になりません。CPU側にも、推論スタックへのデータ供給を維持しつつ、エージェントを止めずに動かし続けるための帯域幅、容量、ストレージ性能が必要です。推論と実行は、連動してスケールさせる必要があります。
図5：KVキャッシュ階層の再定義 出典：マイクロン
壁を突破するには、連携した階層構造が必要
メモリの壁は、物理的な制約によって生まれたものです。今やエージェント型AIは、その壁に対して、推論と実行という2つの方向から同時に圧力をかけています。この壁を突破するには、単にあらゆるリソースを増やすだけでは不十分です。必要なのは、適切なメモリを、適切な場所に、適切なタイミングで、適切な用途に配置することです。
そのためには、HBM、DRAM、NAND、そしてエージェントが依存するデータインフラ全体にわたって、連携した階層構造を構築する必要があります。もはや、メモリとストレージを裏方のインフラとして扱うことはできません。どちらもAIシステムの設計において、戦略的に重要な要素です。
第2部では、このアーキテクチャがどのような姿へ進化する必要があるのかを取り上げます。また、HBM、DRAM、NANDが連携し、エージェントが効率的に推論、実行、スケーリングを続けられるよう支える連携型メモリ階層こそが今後の道筋となる理由について考察します。
