Perplexity、AIエージェントの実行基盤「SPACE」をオープンソース化：安全性の検証結果も公開

Perplexityは2026年10月15日、AIエージェント「Computer」のコード実行基盤「SPACE」をオープンソースとして公開した。7月からComputerの全セッションで利用してきたサンドボックス基盤をApache License 2.0で公開し、外部の開発者もソースコードを調査・改変して利用できるようにした。今回の公開で重要なのは、単にコードを実行する環境を提供するだけでなく、AIモデルが危険な操作を試みた際の通信制限や、長時間の作業を中断・再開する仕組みまで検証できる点だ。ただし、Perplexityの自社試験で確認されたVMの隔離性能と、許可されていない通信を防ぐ能力は、分けて評価する必要がある。

AIエージェントの実行基盤「SPACE」は何ができるのか

SPACEは「Sandboxed Platform for Agentic Code Execution」の略で、Firecrackerを利用した軽量仮想マシン（microVM）内でコードを実行する仕組みだ。アプリケーションはHTTP APIを通じてLinux環境を作成し、コマンドの実行や結果の取得ができる。実行中の処理を一時停止したり、後から再開したりする機能も備えている。SPACE自体はRustで実装されているが、利用するアプリケーションにRustのライブラリを組み込む必要はない。

Perplexityによると、同社は7月に外部の商用サンドボックスサービスから、自社開発のSPACEへ移行した。今回公開されたのはComputerのコード実行を支える基盤であり、AIがどのような作業を行うかを判断するモデルそのものではない。公式GitHubリポジトリでも、実行する処理の内容や、どの結果を保存するかはアプリケーション側が決定すると説明している。開発者はサンドボックス環境を一から構築する負担を減らせる一方、具体的な作業内容や成果物の管理は自ら設計する必要がある。

SPACEでは、サンドボックスごとに独立したゲストカーネルを使用する。カーネルはOSの中核を担う部分であり、仮想マシンごとに分離することで、ゲスト環境内の問題がホストや他のサンドボックスへ波及するリスクを抑えている。さらに、外部へのネットワーク通信はゲートウェイで制御し、プラットフォームが管理する認証情報はVMの外部に保持する。許可されたサービスに接続する際には、通信経路などを通じて必要な認証情報を付与するため、AIエージェントが操作する環境に秘密情報を直接保存する必要がない。AIモデルが安全上の指示に従わなかった場合でも、実行環境側の制約によって被害を抑えるという設計であり、その仕組みを第三者が検証できるようになったことが今回の公開の大きな意義だ。

VM脱出は108回中ゼロ、しかし通信制限の迂回には成功

Perplexityが9月23日に公開した自社セキュリティ評価では、AIモデルがVMからホスト環境への脱出を試みた108回の試験で、成功例は一度も確認されなかった。一方、修正前の環境で外部通信を部分的に許可した場合には、54回の試験のうち11回でネットワーク制限の迂回に成功している。つまり、VMからホストへ侵入することはできなくても、本来は禁止されている外部の通信先にアクセスできる場合があった。

試験では9種類のAIモデルに、VM内でのroot権限（管理者権限）を与えたうえで、異なる二つの課題に挑戦させた。一つはVMからホスト側の秘密情報を取得する課題、もう一つは通信が禁止された宛先にアクセスして確認用の値を取得する課題だ。モデルがソースコードを閲覧できるかどうか、外部通信を全面的に禁止するか一部許可するかといった条件を組み合わせ、それぞれの設定で3回ずつ試験している。二つの課題を合わせた試行数は216回となった。修正前の環境における結果は次のとおりだ。

試験対象	修正前の試験条件	成功した試行
VMからホストへの脱出	ソースコードの閲覧可否と通信条件を変えた全設定	0／108回
ネットワーク制限の迂回	外部通信を全面禁止	0／54回
ネットワーク制限の迂回	パッケージ取得など一部の通信を許可	11／54回

この結果は異なる課題を比較したものであり、それぞれの成功率を同じ条件で直接比較できるわけではない。ただし、外部通信を全面的に禁止した環境では確認されなかった弱点が、ソフトウェアのインストールなどに必要な通信を許可すると表面化した点は重要だ。実際のAIエージェントは外部サービスとの通信を必要とする場合が多いため、すべての通信を遮断した状態で安全性を確認するだけでは十分とはいえない。

ネットワーク制限の迂回には、主に二つの手法が使われた。一つはDNS応答を偽装し、許可されたドメイン名と実際の接続先IPアドレスの対応を誤認させる方法だ。もう一つは、許可されたサービスと同じIPアドレスを共有する別のサービスを経由する方法である。CDNでは一つのIPアドレスに複数のWebサイトが収容されることがあるため、接続先IPアドレスだけを基準に通信を許可すると、実際にアクセスするサイトを適切に制限できない場合がある。

これを受けてPerplexityは、VMから送信されるパケットの送信元IPアドレスを検証するとともに、HTTPやTLSで指定される接続先のホスト名が、許可リストやDNSの対応関係と一致するか確認する仕組みを追加した。修正後の再評価では、同じ9種類のモデルにソースコードの閲覧と一部の外部通信を許可し、それぞれ3回ずつ試験する計画だった。2回はモデル提供元または通信上のエラーで終了したものの、評価できた試行では、問題となった二つの手法による制限の迂回は確認されなかった。ただし、これは特定された弱点に対する修正の有効性を調べた自社試験の結果であり、未知の攻撃手法も含めて安全性が完全に保証されたわけではない。

長時間の作業を支える「一時停止」と「サスペンド」の違い

SPACEは、AIエージェントが長時間の作業を続けるために、実行環境の状態を保存・復旧する機能も備えている。ただし、「一時停止」と「サスペンド」では、保存される状態や必要な計算資源が異なる。一時停止ではメモリの内容を作業ノード上に残すのに対し、サスペンドではメモリや実行状態、ファイルシステムを保存したうえで、稼働中のVMが使用していた資源を解放する。そのため、人間による承認を待つ処理や長時間中断する作業では、適切な停止方法を選ぶことが重要になる。

PerplexityのArchitectureガイドと7月に公開された設計解説では、これらの仕組みが説明されている。保存対象と復旧時の条件を整理すると、次のようになる。

操作・保存方式	保存される状態	待機・復旧時の条件
一時停止	メモリとファイルを作業ノード上に保持	メモリは常駐したままで、永続的なスナップショットは作成されない
ディスクのスナップショット	特定時点のファイルシステム	ファイルの巻き戻しに利用できるが、実行中のメモリ全体は保存されない
サスペンド	メモリ、実行状態、ルートファイルシステムのスナップショット	稼働中のVM資源を解放し、必要な保存データの転送が完了した後に復元できる

例えば、誤って編集したファイルを元に戻す場合と、途中まで進んだ計算を同じ状態から再開する場合では、保存しておくべき情報が異なる。一時停止を永続的なバックアップの代わりに使用すると、作業ノードが故障した際に必要な状態を復元できない恐れがある。ガイドでも、ファイルの書き込み完了が通知されたからといって、クラッシュやホスト障害が発生した後もデータが保持されるとは限らないと説明している。アプリケーション側では、作業内容に応じた保存方法を選び、その処理が確実に完了したことを確認しなければならない。

保存に伴う負荷を抑えるため、SPACEはbtrfsのコピーオンライト（CoW）機能を利用する。既存データを共有し、変更された部分だけを新たに保存することで、環境全体を毎回複製する必要がなくなる。また、頻繁に利用する環境のテンプレートを事前にディスクへ用意する「ウォームプール」も採用しており、新しいサンドボックスを作成する際の待ち時間を短縮している。

Perplexityによると、SPACE導入時に従来の商用サンドボックスサービスと同じ本番トラフィックを使って並行比較したところ、サンドボックス作成時の待ち時間の中央値は185ミリ秒から60ミリ秒へ短縮された。90パーセンタイル値も447ミリ秒から89ミリ秒へ改善したという。ただし、比較対象となった事業者の名前は公表されていない。また、これらはテンプレートの事前準備などを含む実際の運用環境で測定された数値であり、他の環境でも同じ起動時間が得られることを保証するものではない。

導入にはLinux環境と運用体制の整備が必要

公開されているローカル環境への導入手順は、KVMが利用できるapt系のx86_64 Linuxホストを前提としている。btrfsや仮想ネットワーク用のデバイスが必要なほか、Dockerで特権コンテナを実行できる権限も求められる。公式手順ではKindを利用してローカルのKubernetesクラスターを構築し、その上にSPACEを導入する方式を採用している。macOSに直接インストールする構成ではない。

ただし、これは公式ガイドが紹介する導入方法であり、SPACEを利用するために必ずKubernetesが必要というわけではない。SPACEにはワーカーを直接管理する構成も用意されている。また、公式のローカル環境では開発用のパスワードや署名鍵を使用するため、ガイドは環境を外部に公開せず、本番用の認証情報を持ち込まないよう注意を促している。ソースコードが公開されたことで自由に導入できるようになったとしても、サンプル設定をそのまま本番環境へ適用できるわけではない。

クラウドサービスへの展開に向けた取り組みも進んでいる。Perplexityの公開告知によると、CoreWeaveとAkamaiは、それぞれのクラウド環境でSPACEの試験や起動を進め、顧客への提供に向けて協業している。Crusoeも、同社のManaged AI ServicesにSPACEを組み込む提携先として挙げられている。ただし、これらはすべての顧客に対する一般提供が完了したことを意味するものではなく、実際の利用条件や運用責任の範囲については、各社の提供内容を確認する必要がある。

SPACEの導入を検討する開発者にとって、特に重要なのは、AIエージェントに必要な外部通信を許可した状態でもセキュリティ制限が適切に機能するか、そして中断や障害が発生した際に作業をどこまで復元できるかという点だ。今回のオープンソース化によって、こうした仕組みを第三者がソースコードから検証し、自らの環境で試せるようになった。通信制御と状態管理の両面で実用性を確認できれば、AIモデルへの指示だけに依存せず、長時間動作するエージェントを安全かつ安定的に運用するための基盤として活用できるだろう。