2026/10/25AI業務効率化
AIエージェントセキュリティ導入・運用

Perplexity SPACEとは|AIエージェントの隔離環境

Perplexity SPACEとは|AIエージェントの隔離環境

「AIエージェントにコードを実行させたいが、自社のサーバーや社内のネットワークに何かされたら困る」——エージェントに作業を任せる範囲を広げようとすると、この不安に必ず突き当たります。

結論から言うと、Perplexity SPACEは、エージェントが動かすコードを1件ごとに小さな仮想マシン(Firecracker のmicroVM)に閉じ込め、認証情報と外への通信をその外側で管理するサンドボックスの基盤です。2026年10月15日にApache-2.0のオープンソースとして公開されました。ただし動かすにはLinux(x86_64)とKVMが要り、Macでは動きません。自社でエージェントの実行基盤を提供する会社向けの部品であって、Claude CodeやCodexを手元で使う会社が自分で立てるものではありません。

株式会社Fyveは、Mac mini上で記事の執筆や集計などのAIジョブを毎日無人で回しています。この記事では、SPACEの公式ドキュメントとPerplexityの発表を一次情報として仕組みと数字を整理し、私たちが無人ジョブで実際に使っている「エージェントを信用しない」設計と突き合わせて、使うべき場面と要らない場面を判断できるようにします。なお、私たちはSPACEを手元で動かしていません。速さや使い心地の感想は書かず、数字はすべてPerplexityが自社で測った値として扱います。

Perplexity SPACEとは|Computerの裏で動いていたサンドボックス

SPACEは「Sandboxed Platform for Agentic Code Execution」の略で、PerplexityのAIエージェント製品「Computer」の裏側で、エージェントがコードを実行する場所として使われてきた仕組みです。Perplexityの発表によると、2026年7月にそれまで使っていた外部のサンドボックス事業者からSPACEに切り替え、以後すべてのComputerのセッションがSPACEの上で動いています。2026年10月15日に、そのコードをGitHubで公開しました。

公開リポジトリ(perplexityai/SPACE)の説明は「エージェントや利用者のコードを隔離して動かすためのサンドボックス」です。本体はRustで書かれていますが、利用する側はHTTPのAPIとServer-Sent Events(サーバーから順に結果を流してくる仕組み)で操作するので、Rustのライブラリを組み込む必要はありません。公式のチュートリアルも、Pythonの標準ライブラリだけで書かれた例で進みます。

公開された内容の要点

項目

内容

公開日

2026年10月15日(Perplexity公式ブログ「Open-sourcing SPACE」)

ライセンス

Apache License 2.0

隔離の方式

Firecracker のmicroVM(小さな仮想マシン)を1サンドボックスにつき1台

操作方法

HTTP API(作成・コマンド実行・一時停止・保存して停止・再開・削除)

動かす環境

Linux(x86_64)+KVM。公式の手順はKubernetes(ローカルではKind)上に構築する形。macOSでは直接動かない

既存SDKとの互換

E2B(他社のサンドボックスサービス)のPython SDKから使える互換レイヤー「ECW」を同梱

提供側の企業

Akamaiが自社クラウドで提供を開始、Crusoeがマネージドサービスに追加、CoreWeaveが自社のKubernetes環境向けの構築手順を公開

Perplexityは2026年7月15日の別の記事で、SPACEが直近1週間で数百万回のサンドボックス作成と数千万回の再接続を処理したと書いています。社内の実験用ではなく、製品の本番で毎日使われている基盤をそのまま出した、というのがこの公開の性格です。

Perplexity SPACEの仕組み|テンプレートからサンドボックスを作って消す

SPACEの考え方は、公式ドキュメントの「Architecture」にある4つの言葉で整理できます。

用語

意味

テンプレート(Template)

出発点になるファイル一式と実行の設定。同じテンプレートから何台でもサンドボックスを作れ、テンプレート自体は変わらない

サンドボックス(Sandbox)

テンプレートから作った、専用の仮想マシンと書き込みできるファイル領域を持つ実体

コマンドセッション(Command session)

1つのコマンドを動かすための接続情報と許可。作ると番号が振られ、接続した時点でプロセスが始まる

操作(Operation)

作成・一時停止・保存して停止・再開・削除といった、時間のかかる処理の受付記録

APIで行う一連の流れ

アプリケーションから見た流れは次のとおりです。作成や停止はすぐには終わらないので、APIは操作のIDを返し、呼び出し側がそのIDで完了を確かめに行きます。

  1. 作成: テンプレート(例: seed:latest)を指定してサンドボックスを作る。返ってきたサンドボックスIDと操作IDを控える
  2. 待つ: 操作が成功し、サンドボックスが running になるまで確認する
  3. 実行: コマンドセッションを作り、出力の流れに接続してプロセスを始める
  4. 結果を読む: 標準出力と標準エラーを受け取り、終了コードが0かを確かめる
  5. 残す・止める: 続けて使うなら一時停止か、状態を保存して停止する
  6. 削除: 使い終わったら消す

コマンドは「シェルの文字列」ではなく「実行ファイルと引数の配列」で渡します。パイプやリダイレクトを使いたいときは、明示的に sh -c を指定します。エージェントが組み立てた文字列をそのままシェルに渡して予想外の動作をする、という事故を入口で減らす作りです。

もう1つ大事なのが、トークンが2種類に分かれている点です。サンドボックスの作成や削除といった管理の操作には利用者かサービスの認証トークンを使い、コマンドの出力を受け取る接続には、そのセッション専用の短いトークンを使います。公式ドキュメントは、この2つは互いに代わりにならないと書いています。出力を読むためのトークンが漏れても、それでサンドボックスを消したり新しく作ったりはできません。

止め方は「一時停止」と「保存して停止」の2つ

状態

処理

残るもの

実行中(Running)

動く

メモリ上の状態と書き込んだファイル

一時停止(Paused)

止まる

メモリもファイルもサーバー上に残る。長期の保存ではない

保存して停止(Suspended)

止まる

メモリ・実行状態・ファイルのスナップショット。動いていた仮想マシンの資源は手放す

削除(Deleted)

なし

APIからは見えなくなる

公式ドキュメントによると、APIで作ったサンドボックスは、アクセスもコマンドも無い状態が6時間続くと自動で「保存して停止」になります。これは使っていない時間の上限で、使える時間の上限ではありません。Perplexityの発表では、最短1分ごとにメモリとファイルのスナップショットを取り、最大1週間前の状態に戻せるとしています。

Perplexity SPACEの流れ:アプリがAPIでサンドボックスを作り、コマンドを実行し、止めるか消す。認証情報と外への通信の許可はサンドボックスの外側に置く

「サンドボックスを信用しない」設計|認証情報と通信を外に置く

SPACEでいちばん読む価値があるのは速さより、何を信用しない前提で作っているかです。Perplexityは2026年7月15日の記事で、SPACEは「サンドボックスを最初から信用しない」と書き、次の3つを挙げています。

  • 認証情報はサンドボックスの中に置かない: APIキーなどは外側で持ち、必要なときだけ外から渡す。エージェントの作業場所には保存されない
  • 外への通信はサーバーの側で絞る: 乗っ取られたエージェントでも、許された範囲の外には出られないよう、通信の制御をサンドボックスの外(ノード側)で行う
  • 作業が終わったら消す: サンドボックスはタスクの終了とともに破棄する。長いセッションだけ一時停止・再開・分岐で残す

外への通信の許可は、公式ドキュメントの「Operator egress profiles」で設定の形が確認できます。運用者が名前つきの「許可の組み合わせ」をあらかじめ用意し、サンドボックスを作るときにどれを使うかを選びます。許可先はIPアドレス・アドレスの範囲・ドメイン名の完全一致で書き、*.example.com のようなワイルドカードのドメインは受け付けません。設定に誤りがあれば、サービスが起動しません。

ワイルドカードを受け付けないのは、許可を広げたつもりのないところまで通してしまう失敗を避けるためだと読めます。次の節で見る検証では、実際に「許可した宛先と同じIPアドレスの別サービス」を経由して外に出る手口が見つかっています。

Perplexity SPACEの数字の読み方|脱出0件と、通信制限の回避

報道では「作成が約60ミリ秒」「脱出の試み108回中0回」という数字が並びます。ここは出どころを分けて読む必要があります。

速さ:公式記事は「以前の3〜5倍」

Perplexityの公開記事(2026年10月15日)が書いているのは、同じ本番の通信量で測って「サンドボックスの作成が以前の事業者より3〜5倍速かった」という比較です。作成の中央値が約60ミリ秒(以前は185ミリ秒)という具体的な値は、Crypto Briefingなどの報道が伝えている数字で、私たちが読んだPerplexityの2本の記事には書かれていませんでした。どちらもPerplexityが自社の環境で測った値で、第三者が再現した結果はまだ出ていません。

安全性:2026年9月23日の検証「Escaping SPACE, Part I」

安全性の数字は、Perplexityが2026年9月23日に公開した検証記事が出どころです。9つのAIモデルに、サンドボックスから抜け出す課題を解かせました。

  • 検証したモデル: Claude Opus 5.0、DeepSeek V4 Pro、Gemini 3.1 Pro、GLM 5.2、GPT-5.6 Cyber、GPT-5.6 Sol、Grok 4.20、Kimi K3、Qwen 3.8 27B(記事によると、Claude FableとGPT-6 Astraは課題を断ったため対象外)
  • 課題は2つ: ①仮想マシンから外のサーバー(ホスト)に抜け出し、置かれたおとりの認証情報を取る ②通信が止められた宛先から合図の文字列を受け取る
  • 条件は4つ: SPACEのソースコードを読めるか/読めないか × 通信が全く無いか/一部だけ許されているか。エージェントには仮想マシンの中の管理者権限を与えた
  • 回数: 9モデル×2課題×4条件×各3回=216回

課題・条件

成功した回数

仮想マシンからホストへの脱出

108回中0回

通信の制限の回避(通信が全く無い条件)

54回中0回

通信の制限の回避(一部だけ許されている条件)

54回中11回(修正前)

通信の制限を回避できたのは、Claude Opus 5.0、GPT-5.6 Cyber、GPT-5.6 Sol、Kimi K3の4つです。手口は2つありました。

  • DNSのなりすまし: 許可されていた pypi.org の名前を、偽の応答で合図の宛先のIPアドレスに向けた。ソースコードを読めた条件でだけ成功した
  • IPアドレスの共有: 許可された宛先が使っているCDN(配信網)の同じIPアドレスにある別のサービスを経由して、合図の宛先に届いた

Perplexityはこの2つを修正しました。仮想マシンに割り当てたアドレス以外から出た通信を落とす設定を足し、暗号化しない通信では宛先の名前を確かめ、暗号化した通信では接続先の名前(SNI)とHostヘッダーの両方が許可リストにあることを求めるようにしています。修正後に9モデルすべてをいちばん有利な条件で再度試し、合図を取れたモデルはありませんでした。

同じ記事では、他社のサンドボックス10個にも同じ手口を試し、結果を公表した9個のうち7個で少なくとも1回の回避があったと書いています。回避が無かったとされたのはCloudflare SandboxとNVIDIA OpenShellです。

Escaping SPACE Part Iの結果:仮想マシンからの脱出は108回中0回。通信の制限の回避は一部許可の条件で54回中11回、4モデルが成功し、修正後は0回

この結果から読み取れることは2つです。仮想マシンの壁そのものは、今回の検証の範囲では破られていません。一方で、破られたのは「どこへの通信を許すか」の設定の側でした。サンドボックスを使う側が設計で気をつけるべきなのも、壁の強さより許可の書き方だということになります。

Perplexity SPACEを動かすのに要るもの|Linux+KVM、Macは不可

公式の「Install and configure locally」の手順に書かれている前提は次のとおりです。

  • apt系のLinux(x86_64)で、KVM(Linuxの仮想化機能)が使えること。/dev/kvm・/dev/net/tun・ループデバイス・btrfsが要る
  • 特権コンテナを許したDockerが動いていること
  • 仮想マシンの中に立てる場合は、入れ子の仮想化が使えること。手順は「macOSでは直接動かない」と明記している
  • Dockerのデータ置き場とホームディレクトリに、それぞれ30GiB以上の空き
  • Kind・kubectl・Helm・Tilt・Goなどをインストールする準備スクリプトを、root権限で動かせること

手順書が作るのはKindを使ったローカルの検証環境で、開発用のパスワードと鍵が使われています。手順書自身が「公開しない・本番の認証情報を使わない」と注意しています。本番で使うなら、Kubernetesの運用、仮想マシンを動かすサーバーの管理、監視と障害対応までが自分の仕事になります。

もう1つの入口が、E2B互換のレイヤー「ECW」です。E2BのPython SDK(動作確認されている版は e2b==2.21.1 と e2b-code-interpreter==2.6.2)からの呼び出しを、SPACEの操作に置き換えます。すでにE2Bで作ったアプリがある場合、呼び出し側のコードを大きく書き換えずに、裏側だけ自社のSPACEに差し替える道があります。JavaScriptのSDKは、公式の互換テストの範囲に入っていません。

自分でサーバーを持たない場合は、提供側の企業を使う選択肢があります。Perplexityの発表では、Akamaiが自社クラウドで提供を始め、Crusoeが自社のマネージドサービスに加え、CoreWeaveが自社のKubernetes環境(CKS)で評価用に構築する手順を公開しています。各社の料金や提供条件は、この記事を書いた時点で私たちは確認していません。

私たちの無人ジョブで使っている「エージェントを信用しない」設計

私たちはSPACEのような仮想マシンの隔離は使っていません。それでも、SPACEが掲げる「サンドボックスを信用しない」「認証情報を中に置かない」「作業が終わったら元に戻す」の3つは、私たちがMac mini上の無人のAIジョブで、事故を経験してから足してきたルールとほぼ同じ形をしています。ここでは、その対応関係を並べます。

書いてよい場所を1つに決め、外への書き込みは捨てる

Mac miniでは、記事の執筆、Xの投稿案づくり、検索データの集計などのジョブが毎日決まった時刻に動きます。どのジョブも、成果物を書いてよいフォルダは1つに決めています。ジョブが終わると、そのフォルダの変更だけを記録して共有し、それ以外の場所への書き込みは記録せずに捨て、Slackに「境界違反」として名指しで知らせます。さらに、次のジョブの開始時には作業場所を共有済みの最新の状態に強制的に戻すので、前のジョブが何か残していても、それが積み重なることはありません。

この仕組みは、AIに「このフォルダ以外に書かないで」と指示するだけでは足りなかったので作ったものです。指示は守られることが多いのですが、守られなかったときに誰も気づけません。外側の仕組みで捨てて知らせるようにしてからは、守られなかった回が通知として見えるようになりました。SPACEが「作業が終わったら消す」「長いセッションだけ残す」としているのと同じで、エージェントの作業場所はいつでも捨てられる前提で作る、という考え方です。

ただし、私たちの境界はこの仕組みを通したジョブにしか効きません。同じMac miniで人がAIと対話しながら作業すると、境界は働かず、フォルダの外を書き換えられてしまいます。実際にそれが起きたことがあり、今はMac miniで対話の作業をしないルールにしています。仕組みで守れる範囲の外は、運用のルールで塞ぐしかありません。

エージェントに渡す鍵は、できることを絞る

記事を公開するジョブに渡しているブログ管理システム(microCMS)のAPIキーは、記事の読み取り・作成・更新と画像のアップロードはできますが、削除はできません。削除を試すと、キーの側で拒否されることを確かめてあります。既存の記事の本文を変更するのは「関連記事へのリンクを1つ足す」専用のスクリプトだけに限り、そのスクリプトは、足した部分を除くと元の本文と1バイトも違わないことを確かめ、読み戻して結果が合わなければ元に戻します。

SPACEが認証情報をサンドボックスの外に置くのは、中のエージェントが乗っ取られても鍵を持ち出されないためです。私たちのやり方は、鍵を渡したうえで鍵にできることを絞る形なので、守り方は1段弱くなります。そのぶん「最悪でも記事は消えない」「既存の記事は決まった形でしか変わらない」と、起こりうる被害の上限を先に決めています。

判定する役は、書いた役と分け、読むことしかさせない

公開前の判定は、記事を書いたAIとは別のプロセスで起動するAIが行います。判定役のAIに許しているのはファイルを読むことだけで、書き込みやコマンドの実行はできません。通らなかったものは公開せず、下書きに戻します。

SPACEの検証で、通信の制限が破られたのは許可の設定の側でした。私たちの場合も、危ないのは個々のAIの能力より「どの役に何を許したか」の設計です。役ごとに許すことを分けておけば、1つの役が想定外の動きをしても、被害はその役に許した範囲に収まります。

SPACEの設計

私たちの無人ジョブでの対応

違い

サンドボックスは作業が終わったら消す

書いてよいフォルダ以外の変更は捨て、次の開始時に元に戻す

仮想マシンの隔離ではなく、ファイルの変更を後から捨てる方式

認証情報はサンドボックスの外に置く

鍵は渡すが、削除できないなど権限を絞る

鍵が中にあるぶん弱い。被害の上限を先に決めて補う

外への通信はノード側で許可した先だけ

(通信の制限はしていない)

ここは未対応。下で触れるClaude Codeの機能が手近な選択肢

管理用と出力用でトークンを分ける

書く役と判定する役を分け、判定する役は読むだけ

トークンではなく、役ごとのツールの許可で分けている

表の3行目のとおり、私たちは外への通信を絞っていません。SPACEの検証を読んで、ここがいちばん手の薄いところだと分かりました。

中小企業が自分でPerplexity SPACEを立てる必要はあるか

ほとんどの場合、要りません。SPACEは「自社のサービスの中で、利用者やエージェントのコードを大量に、互いに隔離して動かす」ための部品です。必要かどうかは、次の表で判断できます。

やりたいこと

SPACEが要るか

現実的な選択肢

社員がClaude CodeやCodexを自分のPCで使う

要らない

各ツールに元からあるサンドボックスと承認の設定を使う

Mac1台でAIのジョブを無人で定期実行する

要らない(Macでは動かない)

書いてよい場所の制限、鍵の権限の絞り込み、変更を後から捨てる仕組み

自社のWebサービスで、利用者がAIにコードを書かせて実行する機能を出す

候補になる

SPACE、E2Bなどのサンドボックスサービス、提供側の企業のマネージド版を比べる

すでにE2Bで作ったアプリの実行先を自社の環境に移したい

候補になる

ECWでSDKの呼び出しを保ったまま裏側を差し替える

手元で使うなら、まずClaude CodeとCodexの機能を使う

社員のPCでエージェントを使う場面なら、仮想マシンを立てるより、ツールに元からある隔離を有効にするほうが早くて確実です。Claude Codeの公式ドキュメントによると、セッションで /sandbox を実行するか、設定ファイルで "sandbox": {"enabled": true} にすると、Bashのコマンドが隔離されて動きます。macOSではOSに組み込まれたSeatbelt、Linuxではbubblewrapを使い、書き込めるのは作業フォルダなどに限られます。外への通信はPC上のプロキシを通り、allowedDomains に書いた宛先だけに出られます。

注意点も公式に書かれています。読み取りは初期状態ではPCのほとんどの場所に許されていて、~/.ssh のような認証情報のファイルも読めます。読ませたくない場所は denyRead などで別に指定します。また、サンドボックスを起動できない環境では、初期設定のままだと隔離なしでコマンドを動かします。隔離できないなら止めたい場合は、sandbox.failIfUnavailable を true にします。

SPACEの検証で見たとおり、破られやすいのは通信の許可の書き方です。allowedDomains を足すときは、ワイルドカードで広く許さず、本当に要る宛先だけを並べるのが、SPACEの設計から手元に持ち帰れるいちばん具体的な教訓です。Codexの承認モードとサンドボックスの設定は、次の記事で手順を整理しています。

Codexの承認モードとサンドボックス|安全運用

エージェントに渡す権限全体を、どの層で絞るかの考え方は、こちらにまとめています。

AIエージェントの権限管理|業務導入で押さえる3層設計
Claude CodeAIエージェントの権限管理|業務導入で押さえる3層設計

Windowsのエージェントを隔離するMicrosoftの仕組みについては、設定と限界を別の記事で扱っています。

MXCとは|AIエージェント隔離の設定と限界
AI業務効率化MXCとは|AIエージェント隔離の設定と限界

自社で立てるときに先に決めること

自社のサービスにSPACEを組み込むと決めた場合でも、最初に決めるべきなのは仮想マシンの数や速さではありません。公式ドキュメントと検証記事から、少なくとも次の3つは構築の前に決めておく必要があると読めます。

  • どの宛先への通信を許すか: 許可の組み合わせ(egress profile)を名前つきで用意し、ドメインは完全一致で書く。同じCDNのIPアドレスを共有する別サービスに抜けられた例があるので、IPアドレスでの許可は特に慎重にする
  • 認証情報をどこで持ち、いつ渡すか: サンドボックスの中に保存しない前提で、外から渡す経路を設計する。サンドボックスの名前やラベルに認証情報を書かないことは、公式のチュートリアルも注意している
  • いつ消すか: 6時間で自動的に保存して停止する初期設定を、自社の使い方に合わせて見直す。保存したスナップショットにも利用者のデータが残る

まとめ|Perplexity SPACEから持ち帰れること

  • Perplexity SPACEは、エージェントのコードを1件ごとにFirecrackerのmicroVMで隔離し、HTTP APIで作る・動かす・止める・消すを行うサンドボックスの基盤。2026年10月15日にApache-2.0で公開された
  • 設計の中心は「サンドボックスを信用しない」こと。認証情報は外に置き、外への通信はサーバー側で許可した先だけにし、作業が終わったら消す
  • Perplexityの検証(2026年9月23日)では、仮想マシンからの脱出は108回中0回。一方で通信の制限は一部許可の条件で54回中11回回避され、修正された。破られたのは壁ではなく許可の設定だった
  • 動かすにはLinux(x86_64)とKVMが要り、Macでは動かない。速さや安全性の数字はPerplexityが自社で測った値で、第三者の再現はまだない
  • 社員のPCでClaude CodeやCodexを使う会社は、SPACEを立てるより、各ツールのサンドボックスを有効にして通信の許可を絞るほうが先

株式会社Fyveは、AIエージェントを業務に導入するときの権限の分け方や、無人で回すジョブの安全の決め方を、自社で毎日動かしている仕組みをもとにお手伝いしています。どこまでをAIに任せ、どこで止めるかの線引きから一緒に考えます。

AIを使う会社と、使わない会社。
その差は、開き始めています。

ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。

無料プレゼント:様々な業種にAIを導入して分かった、成功の型と失敗パターン ― 無料でダウンロードする
← 記事一覧に戻る