Perplexity、AI エージェント用サンドボックスの難しさを再考
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
The New Stack AI
Perplexity は既存の隔離技術に依存せず、AI エージェントの長時間実行と状態管理の難解さを解決するため、Btrfs を活用した新プラットフォーム「SPACE」を公開し、スナップショットやフォーク機能を強化した。
AI深層分析を開く2026年8月4日 00:15
AI深層分析
キーポイント
状態管理への注力
Perplexity は単なる隔離ではなく、数日〜数週間にわたるセッションの一時停止、再開、分岐といった「状態」の管理こそが最大の課題だと判断し、これを解決するプラットフォームを構築した。
SPACE プラットフォームの公開
同社は 7 月 15 日、「Computer」エージェントプラットフォームの基盤となるサンドボックス「SPACE」をローンチし、既存のプレイヤーとは異なるスケールと要件に対応する設計を採用した。
Btrfs ファイルシステムの活用
システムのコアには Firecracker と Kubernetes を採用しつつ、スナップショットやフォークを低コストなメタデータ操作とするため、Linux のコピーオンライトファイルシステムである Btrfs を基盤として選定した。
パフォーマンスの向上
同社によると、既存のプロバイダーと比較して、パフォーマンス指標において 3 倍以上の速度向上を達成しており、分岐や異なるスレッドの実行が容易になっている。
パフォーマンスとコストの改善
既存プロバイダーと比較して、すべての重要指標で3倍以上の速度向上と大幅なコスト削減を実現した。チームはユーザーのクリティカルパスに直接影響するサンドボックス性能のため、P95およびP99の保証を調整するなどの遅延最適化に注力している。
重要な引用
"What we kept coming back to was recognizing our needs and the needs of an agent system at our scale were pretty different than what you see from the existing players."
"State is the hard part"
"That's been pretty key to a lot of the performance wins there"
"we've seen 3x or more speedups on all of the metrics that we care about for performance, and then pretty significant cost improvements too."
編集コメントを表示
編集コメント
Perplexity が「隔離」ではなく「状態管理」に焦点を当てた点は、実運用におけるエージェントの信頼性確保という課題への鋭い洞察である。Btrfs を活用したアプローチは、大規模なセッション操作におけるパフォーマンス向上の可能性を示唆しており、今後のエージェント基盤技術の方向性を示す事例となる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

AI エージェント向けのサンドボックスは、すでに解決済みの課題のように思えるかもしれません。実際、AWS が Lambda サービスの基盤として開発したオープンソースのマイクロ VM 技術「Firecracker」のようなプロジェクトが、即座に強力な分離機能を提供していますし、エージェントワークロード用の管理型サンドボックスを販売するスタートアップも増えています。
それでも、Perplexity はあえてゼロから考え直すことにしました。同社チームは、困難な問題の本質は「分離」そのものにはないと確信していたからです。
7 月 15 日、同社は「SPACE」というサンドボックスプラットフォームをリリースしました。これは現在、知識作業用のエージェントプラットフォーム「Computer」の裏側で稼働しています。
imagePerplexity の Nate Kupp 氏
The New Stack のインタビューで、Perplexity インフラ担当副社長の Nate Kupp 氏は、真のエンジニアリング的挑戦は「状態管理」にあると語りました。つまり、何日にもわたるセッションを一時停止、再開、フォークする処理です。Computer AI アシスタントを利用するためにユーザーが起動する数百万ものサンドボックス間で、この状態を一貫して管理することが求められます。
「我々が何度も立ち返って認識したのは、自社の規模におけるエージェントシステムのニーズは、既存のプレイヤーのものとは大きく異なるということです」と Kupp 氏は話します。
同チームが目指したのは、単に数時間だけでなく、数日、あるいは数週間にもわたってタスクを実行し続けるエージェントです。そのセッションは、永続的で耐久性のあるアーティファクトとして存続する必要があります。
状態管理こそが最大の難関
SPACE は、スタックの最下層をゼロから作り直すことを目指しているわけではありません。Kupp 氏によると、同チームは Firecracker を中核コンポーネントとして採用し、クラウド上のデプロイには Kubernetes を利用しています。設計初期段階から、クラウドからオンプレミスのデータセンター、さらにはノート PC まで環境を跨いでポート可能であることが重要な目標の一つでした。
実際には、これらのマイクロ VM の上位にあるコントロールプレーンに多くの工数が割かれています。Computer のエージェントハーンがコンテキストをサンドボックス内に持ち込む際、システムはセッションを素早く一時停止・再開し、他のクラスター上で復元する必要があります。また、「ポータブルでフォーク可能」であることも必須です。これにより、異なる方向へ分岐して複数のスレッドを並行実行できるようになります。
その基盤となったのが、Linux のコピーオンライトファイルシステム「Btrfs」です。Btrfs を採用することで、スナップショットやフォークがフルコピーではなく、安価なメタデータ操作として実現されます。「これがパフォーマンス向上の鍵となりました」と Kupp 氏は語ります。また、「一時停止、再開、スナップショット、フォークという SPACE の中核となるオペレーションに、非常に自然な選択だった」とも述べています。
その上に構築されたのが、同社のローンチポストで説明されている「完全なセッション状態のローリングスナップショット」です。これにはライブメモリも含まれます。スナップショットは最大 1 分ごとに取得され、セッションは最長 1 週間まで巻き戻しが可能です。
Kupp 氏は、既存の競合他社と比較して「パフォーマンスに関わるすべての指標で 3 倍以上の速度向上を達成し、コスト面でも大幅な改善が見られました」と述べています。また、サンドボックスのパフォーマンスがユーザーのクリティカルパスに直結しているため、チームは P95 や P99 の保証値を調整するなど、遅延の尾部(tail latencies)対策にも多額の投資を行ったと説明しています。
「ステートフルなシステムを構築するのは極めて困難です」と Kupp 氏は指摘します。これは、数百万ものサンドボックスを実行しながらも、Perplexity が達成しなければならない耐久性や稼働率の保証を指しています。
トレードオフではなく調整可能なパラメータ
セキュリティとパフォーマンスの間のトレードオフについて、Kupp 氏は「それはトレードオフというよりも、顧客が制御しやすいよう、適切な場所に調整ノブ(knobs)を設置する必要があると考えた結果です」と語ります。各顧客は Salesforce、Slack、Snowflake など、異なるデータソースを独自の組み合わせで Computer に接続しており、それぞれに固有のリスクプロファイルが存在するためです。
RBAC やその他のエンタープライズ機能といった「最低限必要な要件」を超える部分において、チームはアジェンシーセキュリティ(agentic security)に注力しています。具体的には、下流システムへのアクセスを必要に応じて即時付与する仕組みや、個々のツール呼び出しレベルで制御を設定することなどが含まれます。
管理者はすべての書き込みアクセスを禁止できるため、エージェントがビジネスシステムに一切書き込むことはできません。これはモデルの挙動に任せるものではなく、プラットフォームレベルでの厳格な制限です。また、Computer は機密性の高いアクションを検知し、ユーザーへの承認を求めるようにフラグを立てます。
なお、SPACE では現在まだハードウェアベースの機密コンピューティングは採用されていませんが、Kupp 氏は同社がスタック全体を通じて NVIDIA と緊密に連携していることを明かしています。
あちこちに広がるサンドボックス
現在の SPACE のサンドボックスはほぼ均一で、Computer のワークロードに合わせて調整された標準サイズのみです。しかし Kupp 氏によると、これは変わる見込みです。「私たちはこれを API プロダクトとして提供していく予定で、より多様な外部ワークロードに対応できるよう、サンドボックスのサイズを柔軟に設定できるようにします」と述べています。
Perplexity はすでに 3 月に、マイクロ VM ではなく Kubernetes ポッド上で動作するエージェント向けのコード実行サービスである、より限定された Sandbox API を発表しています。現在はプライベートベータ版として提供中ですが、一般公開も近いでしょう。また同社は、Computer が今後は SPACE だけでなくサードパーティ製のサンドボックスでも動作すると明言しています。「スタックのあらゆるレベルで拡張ポイントを設計しました。サンドボックス層から API、MCP に至るまでです」と Kupp 氏は語っています。
Kupp 氏はさらに下流のレイヤーにも目を向けています。ローカルおよびハイブリッドなデプロイメントです。同社はすでに、ローカル AI ワークロード向けに NVIDIA の RTX Spark プラットフォームと提携しており、オーケストレーションをノートパソコンまで落とし込む取り組みを進めています。
同社は近日、Computer 向けの新しいオーケストレーターモデルの研究プレビューを発表しました。これはオープンソースの中国製モデル「GLM 5.2」をベースに、同社のハーン(harness)向けにポストトレーニングを施したバージョンです。
Kupp 氏によると、このモデルは「一部の最先端モデルと比較してコストが約 3 分の 1 で結果を出しました」とのこと。彼が描く最終的な姿とは、経済合理性に応じて作業を最適な場所にルーティングするオーケストレーターです。「ローカルで実行することも可能だし、クラウド上で遠隔実行もできます」。
しかしこのルーティングの問題は、より大きな課題と直面しようとしています。エージェントが担う業務が増えるにつれ、Kupp 氏は「GPU の不足だけでなく、CPU の不足にも制約が生じるようになる」と指摘しています。これまでの議論がほぼ GPU の枯渇に集中していた中、この見解は議論の軸をシフトさせるものです。もしエージェントのセッションが数時間から数週間にわたって延長され続けるなら、それらをホストする CPU ファームや、セッションを維持するための状態管理機構(state machinery)は、単なる配管設備ではなく、業界における次回のキャパシティ争奪戦の中心へと姿を変えていくことになります。
「ステートフルなシステムは構築が極めて難しい」:Perplexity の AI エージェントサンドボックスへの考え方
原文を表示

Sandboxes for AI agents may feel like a solved problem. After all, projects like Firecracker, the open-source microVM technology AWS built to power its own Lambda service, provide strong isolation off the shelf, and a growing roster of startups sells managed sandboxes for agent workloads.
Still, Perplexity decided to go back to the drawing board because the team there was convinced that isolation isn’t actually where the hard problems are.
On July 15, the company launched SPACE, the sandbox platform that now runs underneath Computer, its agent platform for knowledge work.
imageNate Kupp of Perplexity
In an interview with The New Stack, Nate Kupp, Perplexity’s vice president of infrastructure, says the real engineering went into managing state — that is, pausing, resuming, and forking agent sessions that can sometimes run for days or weeks — across the millions of sandboxes that Perplexity’s users spin up to use its Computer AI assistant.
“What we kept coming back to was recognizing our needs and the needs of an agent system at our scale were pretty different than what you see from the existing players,” Kupp says.
The team wanted agents “to pause and resume and run tasks for not just hours but then days and weeks,” he says, with those sessions living on as persistent, durable artifacts.
State is the hard part
It’s important to note that SPACE doesn’t try to reinvent the lowest layers of the stack. Kupp says the team uses Firecracker as its core building block and Kubernetes for its cloud deployments, with portability across environments, from the cloud to on-premises data centers to the laptop, as a design goal from the start.
Most of the work actually sat in the control plane above these microVMs. As Computer’s agent harness brings context into a sandbox, Kupp says, the system has to pause and resume sessions quickly, bring them back up on other clusters, and keep them “portable, forkable, so that we can branch off and run different threads in different directions.”
The foundation for that turned out to be Btrfs, the Linux copy-on-write filesystem, which makes snapshots and forks cheap metadata operations rather than full copies. “That’s been pretty key to a lot of the performance wins there,” Kupp says, and “was a very natural fit” for the pause, resume, snapshot, and fork operations SPACE is built around. “We did some early prototypes, very quickly found this was just a great fit, and have run with it,” he says.
On top of that sits what the company’s launch post describes as rolling snapshots of full session state, live memory included. Those snapshots happen as often as every minute, and a session can rewind up to a week.
Compared with the incumbent providers, Kupp says, “we’ve seen 3x or more speedups on all of the metrics that we care about for performance, and then pretty significant cost improvements too.” The team also spent heavily on tail latencies, he says, tuning P95 and P99 guarantees because sandbox performance sits directly in the user’s critical path.
“Stateful systems are incredibly hard to build,” Kupp says, pointing to the durability and uptime guarantees Perplexity has to hit while running millions of sandboxes.
Knobs, not trade-offs
When it comes to the trade-offs between security versus performance, Kupp argues that “it’s less trade-offs and more where we’ve had to think about putting the knobs in the right places for our customers to control.” Since every customer plugs Computer into a different mix of Salesforce, Slack, Snowflake, and other data sources, each with its own risk profile.
Beyond what he calls the “table stakes” work of RBAC and other core enterprise features, Kupp says the team is focused on agentic security, including provisioning just-in-time access to downstream systems and setting controls at the level of individual tool calls.
An admin can disallow any write access, so an agent can’t write into a business system at all, he says, a hard, platform-level restriction rather than something left to model behavior. Computer will also flag sensitive actions and raise them to the user for approval. One thing SPACE doesn’t use yet is hardware-backed confidential computing, though Kupp notes the company works closely with Nvidia across its stack.
Sandboxes everywhere
SPACE’s sandboxes today are largely homogeneous, one standard size tuned for Computer’s workloads. That will change, Kupp says, because “we will be offering this as an API product,” with flexibility over sandbox sizing for more heterogeneous external workloads.
Perplexity already announced a narrower Sandbox API in March, a code execution service for agents built on Kubernetes pods rather than microVMs, with a private beta to follow. The company also says Computer will soon work across third-party sandboxes, not just SPACE. “We’ve thought about these extension points at every level of the stack, from the sandbox layer to the APIs and MCPs,” Kupp says.
Kupp is also looking down the stack, at local and hybrid deployments. Perplexity has been partnering with Nvidia on the chipmaker’s RTX Spark platform for local AI workloads, he says, to bring orchestration down to the laptop.
The company recently released a research preview of a new orchestrator model for Computer: a version of GLM 5.2, the open-source Chinese model, post-trained for its harness.
Kupp says it delivered results at “a third of the cost of some frontier models.” The end state here, he explains, is an orchestrator that routes work wherever the economics make sense. “You can run it locally. You can run it remote in the cloud.”
That routing question is about to collide with a bigger one. As agents take on more of the work, Kupp says, “we’re really going to see a constraint on not just GPUs but CPUs too,” shifting a conversation that so far has been almost entirely about GPU scarcity. If agent sessions keep stretching from hours to weeks, the fleets of CPUs that host them, and the state machinery that keeps those sessions alive, start to look less like plumbing and more like the industry’s next capacity fight.
The post “Stateful systems are incredibly hard to build”: How Perplexity thinks about AI agent sandboxes appeared first on The New Stack.
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み