AIエージェントに複数のタスクを同時にこなさせようとすると、裏側では同時に何十、何百もの「サンドボックス」（AIエージェントがコードを安全に実行するための隔離された仮想環境）が立ち上がります。この仕組みはメモリを大量に消費し、スケールの壁になっていました。研究チームがMemory Compression for High-Fanout Agent Sandboxesという論文で、このボトルネックを最大8.7倍のメモリ圧縮で解決する手法「AgentZip」を発表しました。
背景と文脈
コーディングエージェントや自動化エージェントは、1つのタスクを処理する際に複数のサンドボックスを並行して立ち上げることがあります。これを論文では「high-fanout」（1つの起点から多数の実行が枝分かれする状態）と呼んでいます。例えば「このリポジトリのテストを全部直して」という指示1つから、ファイルごとに独立したサンドボックスが何十個も生成され、それぞれがコードを実行しながら検証を進める、といった使い方が典型例です。厄介なのは、これらのサンドボックスが完全に独立していない点です。同じテンプレートから複製され、似たような処理の流れをたどるため、メモリの中身にはかなりの重複が生まれます。ところが既存の圧縮技術はこの重複をうまく利用できていませんでした。論文は原因を3つに整理しています。まず圧縮方法そのものが、サンドボックス同士の似ているが完全には一致しないメモリページの類似性を活かせていないこと。次に、どのページを圧縮するかの判断が、処理落ち（ページフォールト）を恐れるあまり消極的になっていること。最後に、圧縮するタイミングがメモリ逼迫時に慌てて行われるだけで、エージェントが今どの処理段階にいるかを考慮していないことです。サンドボックスを1つ増やすたびにサーバーのメモリを圧迫するこの構造は、エージェントを大規模に運用する事業者にとって地味ながら深刻なコスト要因になっていました。
技術/ビジネス面
AgentZipはこの3つの課題に正面から取り組みます。第一に、同一テンプレート由来のサンドボックス間で似ているメモリページを横断的に見つけ出し、まとめて圧縮できるようにしました。第二に、圧縮対象を「完全に一致するページ」だけでなく「圧縮すれば得になるページ」全般に広げつつ、復元時に先読み（プリフェッチ）する仕組みを追加することで、圧縮を積極化してもアクセス遅延が起きにくいように設計しています。第三に、圧縮処理そのものを、エージェントがLLM（Large Language Model、大規模言語モデル）の応答を待っている「手すきの時間」に合わせて実行し、実際のツール実行を邪魔しないようにしました。結果として、LLMの学習・推論ワークロードを通じて、サンドボックスが占有するメモリを最大8.7倍削減しています。これは通常のLinuxの圧縮設定（2.1倍程度)と比べて大きな差です。さらに、先読みと実行段階を意識したスケジューリングにより、積極的な圧縮による処理速度の低下を最大3.1倍から1.40倍まで抑えつつ、メモリ削減効果はほぼ維持したとしています。従来型の圧縮では速度低下が3倍前後にまで悪化しがちだったことを踏まえると、体感できるほどの遅さを感じさせずにメモリを大幅に節約できる、という点がAgentZipの実用上の価値だといえます。
これからどうなるか
この技術が実用化されれば、同じサーバー台数でより多くのAIエージェントを同時に動かせるようになり、エージェント基盤のインフラコストが下がる可能性があります。特にClaude CodeやDevin系のような、1つの指示から複数のサブタスクを並行実行するコーディングエージェントを自社で運用している開発者にとっては、サンドボックスの並列数を増やしてもメモリ不足でクラッシュしにくくなる、という形で恩恵が及びそうです。もっとも、これは論文段階の成果であり、実際のクラウド基盤やオープンソースのエージェントランタイムに組み込まれるまでには時間がかかるでしょう。今後はKubernetesや既存のコンテナ基盤との統合が焦点になりそうです。また、メモリ効率が上がれば1台のマシンでより多くのエージェントを試せるようになるため、個人開発者が自宅サーバーやクラウドの小さなインスタンスでマルチエージェントを試す際のハードルが下がることも期待できます。
まとめ
AIエージェントの並行実行が当たり前になる中、サンドボックスのメモリ効率は見落とされがちな課題でした。AgentZipは重複除去・先読み・実行段階を意識したスケジューリングの組み合わせで、メモリ削減と速度低下の両立を示した点が注目に値します。
参考リンク
アイキャッチ画像: Photo by Nathaniel Shuman on Unsplash
