Perplexity SPACE Sandboxがオープンソース化、本番規模での実力が試金石に

Perplexityは、信頼性の高いエージェントインフラには依然として困難な本番運用が不可欠だと主張しながらも、SPACE sandboxをオープンソース化した。Perplexity SPACE sandboxは、周辺システムを露出させずにPerplexity Computerがコードを実行できる、隔離されたコンピュータ環境を提供する。このため、今回の公開は通常のソースコード公開以上の意味を持つ。

CEOのAravind Srinivasは2026年10月19日に公開を発表し、sandbox自体はコモディティだと表現した。しかし、彼の発表投稿では、sandboxを作ることと、その数百万個を運用することの間に明確な線を引いている。Perplexityによれば、SPACEはComputerで使用されるsandbox機能を支えているが、この規模に関する主張は独立して検証されていない。

したがって争点は、オープンソースかクローズドソースかではない。自己ホスト型インフラと、運用経験に支えられたマネージド実行環境の対決である。E2Bなどのsandboxプロバイダーは信頼できるオープンな代替手段に直面する一方、Perplexityはコード公開によって実用的な本番運用の知見まで移転できることを示さなければならない。

Perplexity SPACE Sandboxが実行レイヤーを公開

Perplexityが公開したのは、エージェントに隔離された作業場所を与える仕組みであり、Perplexity Computer製品全体ではない。

SPACEはSandboxed Platform for Agentic Code Executionの略称である。公開されたSPACE repositoryでは、隔離されたFirecracker microVM内でエージェントまたはユーザーのコードを実行するためのプラットフォームと説明されている。

microVMは、従来のサーバーVMより少ないオーバーヘッドで起動するよう設計された小型の仮想マシンだ。各ワークロードに独自のカーネル境界を与えるため、一般に共有カーネル型コンテナより強力な隔離を実現できる。

アプリケーションはHTTP APIを介してSPACEと通信する。Linux環境の作成、コマンドの開始、出力の受信、環境の保持、一時停止、再開、削除が可能だ。

このライフサイクルは重要である。エージェントは通常、1つのコマンドを実行して消えるわけではない。調査やコーディングのワークフローでは、パッケージのインストール、ファイル作成、プログラム実行、エラーの確認、再試行が行われる場合がある。

SPACEは、こうした関連する操作を単一の書き込み可能な環境内に維持する。アプリケーションがエージェントの試行内容を制御し、プラットフォームがマシン、プロセス、出力接続を管理する。

プロジェクトの主な実装言語はRustだが、クライアント側でRustライブラリを組み込む必要はない。HTTPで操作し、標準的な一方向ストリーミング機構であるserver-sent eventsを通じてライブのコマンド出力を受け取る。

PerplexityはApache License 2.0の下でrepositoryを公開した。このライセンス条件に従う限り、商用利用、改変、再配布が認められる。

このrepositoryは単なるデモ用ラッパーより充実している。サービスコンポーネント、API定義、Firecrackerテンプレート、smoke tests、ローカルKubernetes設定、AWS参照デプロイメントが含まれる。

公開ドキュメントでは、warm pools、snapshots、ライフサイクル復旧、可観測性、アウトバウンドネットワークポリシー、互換性に関する挙動も扱っている。これらは、チームが基本的なコードランナーの段階を越えた後に現れる運用上の課題だ。

確認時点で、このプロジェクトはGitHubで約1,600件のstarsと132件のforksを集めていた。これらの数値は開発者からの初期の関心を示すが、本番導入やセキュリティ品質を立証するものではない。

Perplexity Computerは別の、より上位の製品である。同社はComputerを、調査、分析、作成、コーディング、ツールをまたぐ長期的なワークフローの調整を行えるオーケストレーターとして説明している。

公式のComputer overviewによれば、この製品は20種類を超えるモデルにタスクを振り分ける。SPACEが扱うのは、ワークフローの一部の下層にある実行環境であり、計画、モデルルーティング、connectors、ユーザーインターフェースではない。

この違いにより、ありがちな誤解を避けられる。SPACEをインストールしてもPerplexity Computerが再現されるわけではない。開発者が独自のコード実行エージェントやワークスペースを構築するためのインフラレイヤーが得られるだけだ。

今回の公開が記事の中心的な緊張を生むのは、インフラコードが運用プラットフォームの一部にすぎないためである。デプロイメントの規律、容量計画、インシデント対応、セキュリティレビュー、サポートは、Git cloneの外側に残る。

Perplexityが今SPACEを公開する理由

この公開は、エージェントプラットフォームがインフラを選定している最中に、Perplexityの内部実行アーキテクチャを公開の標準策定活動へと転換するものだ。

AIエージェントには、テキストを返す以上の能力が求められるようになっている。プログラムの生成、ファイル変換、ソフトウェアテスト、データセット分析、実際の動作環境を必要とする成果物の作成を行う。

この作業をアプリケーションサーバー上で実行すると、明らかな危険が生じる。モデルが生成したコマンドは、ファイルの削除、リソースの消費、secretsの調査、意図しないネットワークリクエストの送信を行い得る。

使い捨て可能なsandboxは、エージェントの実行環境を周囲のサービスから分離する。タスクが失敗しても、運用者はメインアプリケーションを再構築することなく環境を破棄できる。

この基本的な考え方自体は新しくない。変化したのは、エージェントによる操作の頻度と多様性だ。本番サービスでは、多数の隔離環境の作成、出力のストリーミング、障害からの復旧、制限の適用、容量の継続的な回収が必要になる場合がある。

Srinivasはこの違いを直接的に示した。彼の発表ではsandboxをコモディティと呼ぶ一方、本番トラフィックで提供するには多くの細部にわたる慎重な作業が必要だと主張した。

この主張はSPACEを同時に二つの方向へ位置付ける。Perplexityはインフラ所有への障壁を下げながら、その運用履歴を設計を信頼する理由として提示している。

オープンソース化により、Perplexityは開発者がエージェントをコンピューティング資源へ接続する方法にも影響を及ぼせる。広く採用されたAPIは、多くの利用者が自己ホストではなくマネージドホスティングを選ぶ場合でも重要になり得る。

SPACEにはE2B互換コンポーネントが含まれており、これは特に示唆的だ。互換性により、既存のsandboxインターフェースを前提に書かれたアプリケーションの移行摩擦を減らせる。

このアプローチは専門プロバイダーに圧力をかける。開発者は、SPACEを自ら運用する、プライベートインフラ向けに改変する、あるいはそのインターフェースを代替バックエンドとして使うことを検討できる。

圧力はE2Bに限定されない。Modal、Cloudflare、Daytona、一般的なクラウドプラットフォームも、それぞれ異なる抽象化を通じてリモート実行の問題の一部を扱っている。

マネージドな開発者体験を重視するものもある。他方で、汎用serverless compute、地理的分散、永続的なワークスペース、デプロイメントの柔軟性を重視するものもある。

Perplexityは異なる実績をもってこの分野に参入する。同社は、SPACEが単独のインフラサービスとして存在するのではなく、コンシューマーおよびエンタープライズ向けエージェント製品の実行ニーズを支えているとしている。

この本番利用との結び付きは、SPACEに即時の注目をもたらす。しかし同時に、開発者が公開プロジェクトをPerplexityの内部運用に関する主張と比較するため、立証の基準も引き上げる。

今回の公開は、エージェントシステムを評価する企業の買い手にも利点をもたらす。アーキテクチャの検査、データ経路のレビュー、アウトバウンドネットワーク制限のテスト、自社環境内でのデプロイメント検討が可能になる。

検査してもリスクがなくなるわけではない。ただし、セキュリティチームは製品説明だけに全面的に依存するのではなく、評価すべき具体的な実装を手にできる。

Perplexityにとって、外部のcontributorsは欠陥の特定、デプロイメントパターンの追加、互換性の拡大を担える。公開開発は、SPACEを独自依存ではなく共有インフラとしてより信頼できるものにもできる。

戦略上の賭けは明白だ。Perplexityは実行レイヤーをオープンで置き換え可能なものにしつつ、オーケストレーション、モデル、インターフェース、データアクセス、運用能力で製品差別化を維持したいと考えている。

この分担が成り立つなら、SPACEの公開はComputerの優位性を弱めない。むしろ、Perplexityがすでに利用するアーキテクチャの周辺で開発を行う開発者の数を増やす。

成り立たなければ、競合他社は開発コストを負担せずにPerplexityのstackの有意義な一部へアクセスできる。したがって、運用上の知見がどれだけ移転されるかが、今回の公開がレバレッジを生むのか、流出を招くのかを決める。

Perplexity SPACEがComputerの下層で動作する仕組み

SPACEは制御上の意思決定とコマンド実行を分離し、すべてのコマンドを新しいマシンとして扱うことなく、エージェントに永続的な環境を提供する。

SPACE deploymentはtemplatesから始まる。templateは、sandbox instanceを作成する際の初期環境を定義する。

各sandboxには独自の仮想マシンと書き込み可能なfilesystemが与えられる。複数のコマンドを同じ環境内で実行でき、ステップ間でファイルやインストール済みdependenciesを維持できる。

この永続性は現実的なエージェントの挙動を支える。エージェントはプロジェクトを生成し、dependenciesをインストールし、testsを実行し、失敗を調べ、ファイルを修正して、再度testsを実行できる。

アプリケーションはまずcontrol APIにsandboxをリクエストする。ライフサイクルの変更は非同期であるため、APIはoperation identifierを返し、クライアントは操作完了までこれを確認する。

このパターンにより、長時間かかるインフラ処理が単一のリクエストをブロックすることを防げる。また、クライアントは未完了の操作を再試行または確認しやすくなる。

コマンド実行にはsession modelを使用する。アプリケーションはcommand sessionを作成して接続し、processを開始し、出力と最終的な終了結果を受け取る。

出力は、session-specific attachment tokenを使う別のdata-plane connection経由で送られる。この分離により、process-output clientが利用可能なcredentialsを限定できる。

SPACEは単純な作成と削除を超える複数のstateを公開している。必要な準備性とリソース使用量のトレードオフに応じ、sandboxはactiveのままにする、pause、suspend、resume、terminateできる。

価格が議論されていない場合でも、こうしたstateは経済性に影響する。すべての環境を完全にactiveな状態で維持すればレイテンシーは低下するが、アイドル期間にも多くの容量を消費する。

すべてを停止すればリソースを節約できるが、ユーザーは復元を待たなければならない。本番プラットフォームには、多数のworkloadsでこれらの結果を選択するためのpoliciesが必要だ。

Warm poolsはこの問題の一部に対処する。起動済みの環境を待機させ、新しいリクエストが完全なcold startを回避できるようにする。

warm poolは応答性を改善するが、容量に関する問題を持ち込む。運用者は、確保する環境数、不健全なinstancesの置換方法、無駄の回避方法を決めなければならない。

SPACEはbase snapshotsについても文書化している。snapshotでは、タスクごとに再構築する代わりに、準備済みのfilesystem stateを復元できる。

snapshotsは、エージェントが同じlanguages、libraries、project setupを繰り返し必要とする場合に有用だ。一方で、慎重に扱うべきversioningとstorage-managementの責任も生じる。

隔離レイヤーでは、SPACEはデフォルトでFirecrackerを使用する。Amazon Web Servicesは、serverless functionsやcontainersを含む軽量な仮想化workloads向けにFirecrackerを開発した。

公開されたFirecracker architectureは、Linuxのkernel-based virtual machine技術を利用してハードウェア支援による隔離を提供する。簡素化されたdevice modelは、起動オーバーヘッドと利用可能なattack surfaceを抑えることを目的としている。

Firecracker を使用しても、サービス全体が自動的に安全になるわけではありません。認証、ホスト構成、イメージの来歴、ネットワークポリシー、カーネル更新、リソース制限、テナント分離は、依然として正しく実装する必要があります。

SPACE は、egress プロファイルによるアウトバウンドネットワーク制御にも対応しています。egress とは、パッケージをダウンロードするコマンドや外部 API への接続など、サンドボックスから外部へ出ていくトラフィックを指します。

これはエージェントにとって重要なポリシー領域です。アウトバウンドアクセスが無制限のサンドボックスは、仮想マシンから直接脱出できなくても、機密情報を送信できてしまいます。

運用者には、必要なネットワーク活動と危険なアクセスを区別するルールが必要です。コーディングエージェントにはパッケージレジストリへのアクセスが必要かもしれませんが、社内の管理サービスに接続する理由はありません。

公開リポジトリには、ローカルコンテナを通じて Kubernetes クラスターを実行する Kind を使ったローカルデプロイ手順が含まれています。また、Amazon のマネージド Kubernetes サービス向けのリファレンスインフラも収録されています。

ドキュメントによれば、SPACE は Kubernetes なしでも実行できます。この柔軟性は潜在的な利用者層を広げますが、同時に、どの保証が SPACE によるもので、どの保証が周辺のスケジューラーによるものかを、運用者が理解しなければならないことも意味します。

したがって、Perplexity SPACE sandbox は、連携したインフラ判断の集合体です。microVM は構成要素の一つにすぎません。

API 契約、ライフサイクル状態機械、ウォームキャパシティ、スナップショット、認証、コマンドストリーミング、リカバリー動作が、実際のワークロード下でシステムを利用可能な状態に保てるかを左右します。

この仕組みは、Srinivas がこのプリミティブをコモディティと呼びつつ、運用上の取り組みを擁護できる理由を説明します。単一の隔離 VM を作成することは、繰り返される障害や変動する需要に対して予測可能な動作を維持することに比べれば簡単です。

Perplexity SPACE vs E2B の本質はセルフホスティングとマネージド運用の対比

主な競争は、どちらのプロジェクトが microVM を起動できるかではなく、エージェントが使い始めた後の運用負担を誰が担うかにあります。

E2B は、エージェントにリモート環境を提供するためのよく知られたインターフェースになっています。開発者はその SDK を使い、サンドボックスの作成、コマンド実行、ファイル操作、ツール呼び出しをまたいだ状態維持を行っています。

SPACE は、文書化された E2B compatibility layer を通じて、この導入基盤を認識しています。このラッパーにより、対応する E2B クライアントの挙動を SPACE のデプロイ環境に向けられます。

これは実用的な競争戦略です。チームは、エージェントアプリケーション内のすべての呼び出しをすぐに書き換えずとも、SPACE を評価できます。

互換性は、挙動が同一であることを意味しません。各プロバイダーは、ライフサイクルの意味論、制限、ネットワーク、永続性、エラー処理、可観測性、対応 SDK 機能において異なる可能性があります。

開発者は、自身のエージェントが利用する正確な操作をテストする必要があります。基本的なコマンド例では、キャンセル、ネットワーク中断、同時セッション、ホスト障害時の動作は明らかになりません。

Perplexity SPACE と E2B の選択は、まず責任の所在から始まります。マネージドプラットフォームでは、プロバイダーがキャパシティ、更新、可用性、そしてセキュリティ境界の大部分を運用します。

SPACE をセルフホストすれば、導入、変更、データ配置、ネットワーク統合をより細かく制御できます。一方で、より多くの運用責任も採用者に移ります。

小規模な開発チームにとって、マネージドインフラはエージェント公開までに必要な作業を減らせます。チームは API を統合し、アプリケーションに注力できます。

規制対象の企業は、承認済みのクラウドアカウント内にインフラを置くことを望むかもしれません。サンドボックスサービスの周囲に、既存のアイデンティティ、ロギング、ネットワーク、コンプライアンス制御を適用できます。

どちらの選択肢も、常に優れているわけではありません。適切な道筋は、ワークロードの機密性、規模、人員、レイテンシー要件、外部サービス依存への許容度によって決まります。

オープンソースは、実際に導入しないチームにとっても交渉力を変えます。購入者は代替アーキテクチャを評価でき、一つの独自実行サービスを前提に設計するリスクを下げられます。

Apache ライセンスは、ベンダーが SPACE を基盤とした商用サービスを構築することも認めます。これにより、マネージドデプロイ、エンタープライズサポート、特化ディストリビューションが生まれる可能性があります。

互換サービスがそのインターフェースを維持するなら、こうしたエコシステムは Perplexity の立場を強めるでしょう。実装が分断されたり、セキュリティ修正への追随が遅れたりすれば、プロジェクトは弱体化します。

専門ベンダーには、いくつかの防御策が残ります。ホステッドサービスは、信頼性、地理的なキャパシティ、サポート、導入支援、監視、新しいランタイム機能への迅速なアクセスで競争できます。

マネージドプロバイダーは、オープンソースによって可視化される運用の複雑さも隠せます。コンポーネントで満たされたリポジトリはインフラチームにとって価値がありますが、アプリケーションチームには威圧的に映る場合があります。

Perplexity の優位性は、内部での重要性を示す証拠にあります。同社は、このプラットフォームが Computer を支えるサンドボックス機能をサポートしているとしており、この設計には要求の厳しい参照ワークロードがあります。

ただし、リポジトリだけでは外部の人間がその主張を再現・検証することはできません。Perplexity のフリート規模、サービスレベルの実績、リージョン構成、インシデント履歴、インフラ支出は開示されていません。

「数百万のサンドボックス」という表現も、慎重な解釈が必要です。累計作成数、ピーク時の同時実行数、稼働中の環境数、あるいは別の社内指標を指している可能性があります。

これらの指標には実質的な違いがあります。時間の経過とともに数百万の短命なサンドボックスが作成されたことは、数百万台の仮想マシンが同時に稼働していることを意味しません。

この検証上の隔たりは、プロジェクトの有効性を否定するものではありません。発表から読者がどこまで結論づけるべきかを制限するものです。

開発者は、公開 API、コード、デプロイ手順、テストを検証できます。しかし、それらの成果物だけで社内の本番利用規模を検証することはできません。

したがって、最も信頼できる比較は独立したデプロイから生まれるでしょう。チームは、作成レイテンシー、障害からの復旧、コマンドストリーミング、ホスト利用率、敵対的なワークロード下での挙動を測定する必要があります。

プラットフォーム運用に伴う人件費も追跡すべきです。技術的に高性能なシステムでも、専門インフラチームによる継続的な介入が必要なら、経済的には成立しない可能性があります。

このオープンリリースは、検査可能な選択肢を新たに生み出したため、すでに競争環境を変えています。しかし、SPACE がマネージドサービスより優れた運用成果をもたらすかどうかは、まだ決着していません。

公開コードは本番環境での安全性を証明しない

SPACE は意味のある実装詳細を提供していますが、公開された証拠だけでは、Perplexity の最も広範なスケールおよびセキュリティ上の主張をまだ裏付けられません。

エージェントのサンドボックスは、特にリスクの高いワークロードを処理します。その中核的な目的は、モデルが生成した、ユーザーが提供した、あるいは外部コンテンツから組み立てられたコマンドを実行することです。

つまり、運用者は一部のコマンドが不正な形式であることを想定しなければなりません。また、攻撃者が隔離境界を意図的に試すことも想定する必要があります。

microVM は、信頼できないコマンドを共有アプリケーションホスト上で直接実行する場合と比べ、露出を減らします。しかし、多層防御の必要性をなくすものではありません。

ホストカーネル、仮想化コンポーネント、ストレージパス、ネットワーク、制御 API、イメージパイプラインには、いずれも脆弱性が存在し得ます。設定ミスは、他の点で堅牢なアーキテクチャを弱める可能性があります。

リポジトリには非公開の脆弱性報告プロセスが含まれており、セキュリティ修正の対象は最新のマイナーリリースのみであるとしています。公開されている security policy には、レビュー時点で公表済みのアドバイザリーは記載されていません。

アドバイザリーがないことは、脆弱性が存在しない証拠ではありません。新しいプロジェクトでは、弱点が表面化するまでに時間、導入、敵対的テストが必要になることがよくあります。

最新マイナー版のみを対象とするポリシーは、採用者にも作業を求めます。SPACE をセルフホストするチームは、サポート対象のセキュリティ期間内にとどまるため、リリースを追跡し、迅速に更新しなければなりません。

本番環境への適合性は、VM 脱出の防止だけで決まりません。運用者には、テナント認証、認可、クォータ、シークレット処理、監査記録、信頼できるクリーンアップが必要です。

クリーンアップの失敗は、高コストまたは危険な問題になり得ます。放棄されたサンドボックスは、リソースを消費し続けたり、機密ファイルを保持したり、意図したより長くネットワーク認証情報を残したりする可能性があります。

アウトバウンドアクセスも同等に注意を要します。隔離されたワークロードでも、外部システムを探索したり、悪意あるコードをダウンロードしたり、攻撃者にデータを送信したりすることで被害を与えられます。

SPACE はポリシー機構を提供しますが、設定するのは採用者です。egress プロファイルが存在しても、すべてのデプロイで制限的なデフォルトが適用されることは保証されません。

テンプレートとスナップショットは、別のサプライチェーン上の攻撃面を生みます。侵害されたベースイメージは、それを基に作成されるすべてのサンドボックスに影響を及ぼす可能性があります。

運用者には、再現可能なビルド、依存関係レビュー、イメージ署名、脆弱性スキャン、管理された昇格プロセスが必要です。こうした慣行は、オープンライセンスによって自動的に提供されるものではありません。

可観測性は、競合するリスクを露呈させることがあります。ログとトレースは障害の診断に役立ちますが、不注意なテレメトリーはコマンド内容、ファイルパス、トークン、ユーザーデータを取得するおそれがあります。

チームは、何を記録し、どれだけ長く保持するかを決めなければなりません。エンタープライズ導入では、誰がエージェント活動を閲覧できるかを管理する制御も必要になります。

信頼性は別の不確実性として残ります。サンドボックスは、起動中、実行中、一時停止中、復元中、出力ストリーミング中に障害を起こす可能性があります。

アプリケーションは、遅延した操作と失敗した操作を区別しなければなりません。また、レスポンスが失われた際に重複リソースの作成を避ける、べき等な再試行も必要です。

Perplexity のドキュメントは、リカバリーと隔離の挙動を扱っており、このプロジェクトがこれらの障害類型に対処していることを示唆します。公開ベンチマークがあれば、こうした機能をより評価しやすくなるでしょう。

現行リリースは、独立監査済みのスループットや可用性の数値を提供していません。また、公開設定が Perplexity の社内本番環境とどの程度一致しているかも示していません。

企業は、オープンソースの中核の周囲で追加システムを動かすことがよくあります。社内スケジューラー、キャパシティ予測、セキュリティサービス、デプロイ自動化、インシデント対応ツールが、運用成果の大部分を占める可能性があります。

したがって、Perplexity の主張は限定的に読むべきです。同社はサンドボックスアーキテクチャに関連する相当量のコードを公開しました。

しかし、Perplexity Computer の背後にあるサービスを再現するために必要なすべてのプロセスを移転したわけではありません。また、外部の人間が主張された本番規模を検証できるほどのデータも公開していません。

これが、このリリースにおける中心的なトレードオフです。公開コードは検査可能性と制御性を高める一方、セルフホスティングでは採用者により大きな責任が課されます。

SPACE を評価するチームは、機能チェックリストではなく、脅威モデルから始めるべきです。信頼できない入力、保護対象の資産、許可する宛先、許容可能な復旧時間を特定する必要があります。

次にチームは、通常のデモでは避けられる障害ケースをテストすべきです。これには、起動の停止、出力ストリームの中断、ホストキャパシティの枯渇、無効なスナップショット、取り消された認証情報、強制終了が含まれます。

独立したセキュリティレビューを通じて、脱出耐性もテストすべきです。敵対的なコードを実行するよう設計されたプラットフォームには、一般的な社内サービスよりも厳しい精査が求められます。

SPACE は、その作業を正当化するだけの真剣さを備えているように見えます。利用可能な証拠は、それを省略することを正当化しません。

SPACE が共有インフラになるかを示す三つの兆候

次の段階を決めるのは、リポジトリへの注目だけではなく、外部での運用、セキュリティ対応、実際の互換性です。

第一の兆候は、独立した本番デプロイです。開発者は、Perplexity 自身の環境の外で Perplexity SPACE sandbox を運用する組織に注目すべきです。

意味のあるケーススタディでは、ワークロードの性質、同時実行数、作成レイテンシー、障害率、人員体制が説明されるはずです。ロゴや導入発表から得られる情報は、はるかに少ないでしょう。

独立運用が可能であれば、コードが実用的な本番知識を移転できるというPerplexityの主張は強まる。一方、デプロイの複雑さに関する報告が繰り返されれば、その主張は弱まる。

この最初のシグナルでは、コミュニティからの貢献も重要だ。スケジューリング、ランタイム、デプロイ先、診断機能に対する実質的な変更は、外部の開発者がアーキテクチャを理解し、拡張できていることを示す。

2つ目のシグナルは、プロジェクトのセキュリティとリリースの実績である。プラットフォームは設計上、信頼できないコードを受け入れるため、研究者はSPACEを検証することになる。

このレイヤーにおいて、プロンプト処理は中心的な問題ではない。本質的な問いは、悪意あるプロセスが分離境界を越えられるか、認証情報を不正利用できるか、あるいは禁止されたネットワークへ到達できるかだ。

透明性の高いアドバイザリー対応、迅速なパッチ、明確なアップグレード指針は信頼を築く。告知されない修正や、互換性を損なうセキュリティ更新は、エンタープライズでの導入を難しくする。

ユーザーは、Perplexityが公開リポジトリをどれほど一貫して維持するかにも注目すべきだ。社内開発が先行する一方で公開リリースが遅れれば、オープンソース・プラットフォームの価値は失われる。

3つ目のシグナルは、実際のエージェント・ワークロードにおける互換性である。E2Bラッパーは、アプリケーションが振る舞いを変えずにインフラを変更できるかを直接検証する手段となる。

開発者は、長時間実行されるコマンド、ファイル転送、キャンセル、再接続、永続性、同時セッションを検証すべきだ。こうしたエッジケースは、単に「hello world」コマンドが成功すること以上に多くを明らかにする。

信頼できる互換性が実現すれば、マネージド・サンドボックス・プロバイダーへの圧力は高まる。チームは実行バックエンドを交換可能なコンポーネントとして扱えるようになる。

互換性が不完全であれば、乗り換えコストは維持される。プロバイダーは、アプリケーションが密かに依存している振る舞いを通じて、引き続き差別化できる。

Perplexity Computerも、もう一つの観測点を提供する。Computerがより複雑な成果物を扱うようになるにつれ、ユーザーは実行環境の実用上の限界に直面する。

パッケージのインストール、長時間タスク、保持される状態、生成ファイルに関する失敗は、サンドボックス・インフラがなお製品を制約している箇所を明らかにし得る。改善は、基盤プラットフォームがどれほど速く進化しているかを示す可能性がある。

知識集約型エージェントを構築する開発者は、実行環境がコンテキストとどう接続されるかも考慮すべきだ。サンドボックスはコードを実行できるが、エージェントにアクセスを与える前に、慎重に選択されたファイルと指示が必要になる。

そのため、情報検索と権限設計は、コンピュート分離と同じくらい重要になる。検索可能なAIナレッジベースは、エージェントにアクセスを与える前に、ソース資料を整理できる。

PerplexityによるSPACEサンドボックスのリリースは、現時点で一つの結論を妥当なものにする。エージェント実行は、独自のインターフェース、互換性の課題、デプロイの選択肢を備えた、独立したインフラレイヤーになりつつある。

ただし、セルフホスティングがすべてのチームにとって最善の答えだとまでは示していない。インフラ制御よりも信頼性が重要な場合、マネージド運用には依然として価値がある。

したがって実務上の問いは具体的だ。組織は実行境界を自ら所有する必要があるのか。そして、その境界を安全に運用できるのか。

答えが「はい」であれば、敵対的なワークロードと現実的な障害条件でSPACEをテストすべきだ。答えが「いいえ」であれば、その公開設計を活用し、マネージド・プロバイダーにより鋭い問いを投げかけるべきだ。

今後3か月間は、独立したデプロイ、セキュリティ開示、互換性の結果を注視してほしい。これらのシグナルが、SPACEが共有エージェント・インフラになるのか、それとも主にPerplexityが公開したリファレンス実装にとどまるのかを示すだろう。