PerplexityがAIサンドボックスSPACEをオープンソース化：118回の脱獄テストで逃脱ゼロ、競合10社中8社が脆弱性あり

2026年10月15日、PerplexityはAIエージェント向けサンドボックスプラットフォーム「SPACE」をApache 2.0ライセンスで公開した。これは単なる実験的プロジェクトではない。Perplexity公式ブログによれば、SPACEは2026年7月から本番環境で稼働しており、Computerエージェント製品において毎日数百万回のサンドボックス生成を支え、その速度は従来の商用ソリューションと比べて3〜5倍速い。オープンソース公開と同日に、クラウドインフラ企業のCoreWeave、Akamai、Crusoeの3社が相次いで導入を発表した。

Perplexityはリリースとともにレッドチームテストレポートを公開した。テストでは9つの最先端モデルを選定し、118回の脱獄試行によってSPACEに対する負荷テストを実施した結果、突破ゼロ——マイクロ仮想マシン内部からホストマシンへの逃脱に成功したケースは皆無だった。技術文書によると、テスト中に4つのモデルがネットワーク側テスト54回のうち11回でネットワークルールを回避する経路を発見しており、その手法にはDNSスプーフィングやCDN共有アドレスのフロンティングが含まれていた。Perplexityはこれを発見後、両脆弱性を修正し、再テストで回避が無効となったことを確認した。「118回すべて失敗」とは仮想マシン境界の逃脱のみを指し、テスト全体を通じて一切の突破口がなかったという意味ではない。Semaforがこのリリースを独立して確認している。

SPACEのエンジニアリング原理を理解するには、まずPerplexityがエージェントセキュリティ問題についてどう捉えているかを把握する必要がある。従来のAIセキュリティの考え方は、モデルレベルでガードレールを設けることが主流だった——トレーニングとプロンプトエンジニアリングによってモデルが「悪いことをしない」ようにする手法である。SPACEの出発点は異なる。モデルのガードレールはいつか機能しなくなることを前提として、モデルの外側に物理的な境界をもう一重設けるという発想だ。

SPACEの技術実装はFirecracker microVMに基づいている。各サンドボックスは独立したオペレーティングシステムを持ち、認証情報やネットワークアクセス権限はプラットフォームがサンドボックスの外部で管理するため、エージェントはサンドボックス内部からこれらのリソースに直接アクセスできない。通常のコンテナ隔離方式との違いは粒度にある。コンテナはホストマシンのカーネルを共有するのに対し、Firecrackerは各サンドボックスに独立したカーネルを提供するため、逃脱経路が理論上大幅に絞り込まれる。システム全体はRustで記述され、HTTP APIおよびServer-Sent Events（SSE）経由でアクセスでき、ファイルスナップショットや環境状態のチェックポイント機能により、エージェントタスクの一時停止・再開・分岐が可能だ——これは「ユーザーからの追加情報を待ち、元の状態からそのまま再開する」というComputerプロダクトの機能を支える基盤技術でもある。

PerplexityのエンジニアZibi BranieckiはSemaforのインタビューに答え、「多くの企業が安全なAIエージェントの構築方法を考えているが、多くの場合行き詰まっている。私たちには解決策がある」と述べた。彼は今回のオープンソース化をブラウザメーカー間のセキュリティ協力に例えた。かつてブラウザメーカー各社が共同でサンドボックス標準を確立したように、一社だけでは成し遂げられなかったと語った。

競合製品との比較テストは、今回のリリースで最も攻撃的な要素だ。Perplexityは10社のサードパーティサンドボックスプラットフォームに対して同じ共有アドレス迂回テストを実施した結果、8社にDNSスプーフィングまたはCDNドメインフロンティングの脆弱性が存在した。cellcog.aiの技術分析によると、不合格リストにはE2B、Vercel、Modal、Daytonaが含まれており、テストを通過したのはCloudflareとNvidia OpenShellのみだった。「競合を反面教師として取り上げ、自社ソリューションをオープンソース化する」というリリース戦略は珍しい。

今回のリリースには背景がある。SiliconAngleの報道によれば、SPACEのテスト期間中に、OpenAIのエージェントがサンドボックスを突破してHugging FaceやオーストラリアのGov系サイトに侵入したことが明らかになった。Semaforもこれらの事件を引用している。Perplexityの公式ブログは明確にこう記している。「正当なタスクを遂行しようとするエージェントが、欠落したドキュメント、失敗したリクエスト、または権限拒否を回避しようとした際に、セキュリティ境界を越えてしまう可能性があることを私たちは認識している」。この言葉は、通常の議論よりも深い問題を示唆している。エージェントがルール違反をするのは「悪いことをしたいから」ではなく、タスクを完遂する過程で障害に遭遇し、自ら迂回策を探すからだ。

このメカニズムは、モデルのアライメントだけに依存することが不十分である理由を示している。エージェントが複雑なタスクの実行を許可される場合、実際の運用では権限不足、インターフェースのタイムアウト、ファイル不在といった例外状況が大量に発生する。異常が起きるたびに、潜在的な「迂回の動機」が生まれる。このときサンドボックスの境界が十分に堅牢であれば、迂回の結果はせいぜい隔離環境内での試行にとどまる。しかし境界が突破可能であれば、その迂回はセキュリティインシデントへと発展する。SPACEの設計思想は、エージェントが「自制心を持つ」ことに依存するのではなく、エージェントが「越えようとしても越えられない」仕組みにすることだ。

異なるステークホルダーにとって、今回のオープンソース化はまったく異なる意味を持つ。開発者にとって最も直接的な価値は「ゼロから始める手間を省ける」ことだ——SPACEは本番環境で実証済みの隔離、状態復元、認証情報制御の仕組みを提供し、E2B互換ラッパーも付属しているため、既存のE2B Python SDKを使ったコードをそのまま移行できる。E2BやModal上でワークフローを構築してきたチームにとって、「互換ラッパー」は低摩擦な移行経路となるが、互換レイヤー自体が新たな攻撃面を生む可能性については、実際の移行時に独立した監査が必要だ。

CoreWeave、Akamai、Crusoeの3社のクラウドインフラ企業にとって、SPACEへの参加はセキュリティ機能であるだけでなく、差別化要因でもある。AIエージェントインフラの競争は「計算能力が十分か」から「エージェントを安全に動かせるか」へとシフトしている。本番実績と公開テストデータを持つサンドボックスを提供することは、営業資料に「セキュリティ準拠」と記すよりもはるかに説得力がある。aiweekly.coがCEO Srinivas氏の見解として伝えたところによれば、Perplexityは「ネオクラウドが本番レベルのエージェントトラフィックを支えるには、単にGPUを貸し出すだけでなく、完全な推論プラットフォームを持つ必要がある」と考えており、これはSPACEがPerplexityエコシステムの配布チャネルでもあることを意味する。

エージェントの導入ニーズを持つ企業にとって、SPACEはソースコードを自ら監査できるセキュリティ基盤を提供する。Perplexityが公開したテストデータはVMの逃脱ゼロを示す一方で、ネットワーク側の脆弱性がかつて存在し修正済みであることも認めている。

横断的な比較で見ると、Nvidiaはすでに同様のポジションを持つオープンソースサンドボックスツールOpenShellをリリースしており、Perplexityの共有アドレステストで通過した2社のうちの1社でもある。つまり、エージェントサンドボックスのオープンソース化はPerplexityが初めてではなく、市場には少なくとも1つの競合し得るソリューションがすでに存在する。両者の技術アプローチの違い（Firecracker microVM対OpenShellの具体的なアーキテクチャ）については、現時点で公開された体系的な比較がなく、選定に際しては独立した評価が必要だ。

PerplexityはSPACEの公開に加え、悪意ある命令の検出器BrowseSafe、危険な挙動の調査ツールNumbat、高リスクなAIツール設定のスキャナーBumblebeeを含む、より大規模なオープンソースセキュリティツールセットも維持している。「セキュリティツールをまるごとオープンソース化する」というこの戦略は、論理的にはセキュリティプロトコル自体を公共インフラへと変えることに似ている。