Perplexity、Agent APIにSandbox実行環境を追加 単体serviceとしても提供

March 11, 2026、PerplexityはXで、Sandbox APIをAgent API内のtoolとして提供すると同時に、developer向けstandalone serviceとしても公開すると述べた。会社はこれを自社が内部利用しているexecution runtimeと同じ環境だと説明し、必要に応じてorchestration runtimeがdeterministic code executionを委譲できるとした。

現在のAgent API quickstartは、Perplexityをmulti-provider LLM application interfaceとして位置づけている。Perplexityによれば、developerは一つのAPIから複数providerのmodelにアクセスしつつ、reasoning、token budget、toolを一貫したsyntaxで設定できる。別のTools documentationでは、toolは各requestで明示的に有効化する必要があり、built-in toolとして現在はweb_searchとfetch_url、さらに外部systemとつなぐcustom functionが説明されている。

Sandbox updateで変わること

• deterministic code executionがagent runtimeのfirst-class toolに近づく。
• Perplexity内部のexecution environmentがstandalone developer surfaceとして公開される。
• retrievalとcode executionを一つのorchestration flowで組み合わせやすくなる。

この変化が重要なのは、実運用のagent workloadがretrievalだけでは完結しないからだ。research-style agentは、web searchの後にfileを解析し、dataを変換し、計算を検証し、小さなprogramを実行する必要がある。これまでPerplexityの公開docsはretrieval寄りのtoolとcustom function callを中心に説明してきた。March 11のX postは、会社がcode executionを外付け機能ではなく、orchestration modelの中核に近い位置へ引き寄せようとしていることを示している。

発表時点で公開docsはなおweb_search、fetch_url、custom functionを中心としたtool frameworkを説明していたため、今回のX postはdeterministic executionがそのモデルにどう組み込まれるかを示す初期シグナルとして読むのが自然だ。今後、Perplexityがlimit、security control、pricingを明確に出せば、Sandboxはresearch agentとdeterministic actionを必要とするworkflowをつなぐ実用的な橋になる可能性がある。

つまり、これは単なるtool toggleではない。agent platformの競争が、model access、retrieval、controlled executionをどれだけ少ない構成要素で一つのdeveloper surfaceに束ねられるかへ移りつつあることを示す動きだ。