Perplexityが配る『檻』、暴走は防げても誤発注は防げない

PCやブラウザを自律的に操作するAIエージェントの利用が広がるにつれ、「プロンプト無視による不正アクセス」や「誤ったコマンド実行によるデータ破壊」といった安全面のリスクが表面化しています。これまでの安全策は「悪質な命令に従うな」とプロンプトで指示するか、規約で縛る「言葉による約束」が中心でした。しかし、AI検索エンジンやエージェント開発を手がける米Perplexity（パープレキシティ）は、このアプローチの限界を宣告しました。

2026年10月15日、Perplexityは自律型エージェントの実行基盤である「SPACE（Sandboxed Platform for Agentic Code Execution）」をApache 2.0ライセンスでGitHub上にオープンソース公開しました。AIの善意や命令への忠実さに期待するのをやめ、仮想マシンという物理的な「檻」の中に閉じ込めて処理させるインフラ型の制御へ舵を切ったのです。

60ミリ秒の「使い捨ての檻」と118回耐えた防御力

SPACEの核となる仕組みは、計算処理ごとに使い捨てる隔離部屋（サンドボックス）を即座に作っては壊す技術です。AWSが開発した超軽量仮想マシン「Firecracker microVM」を採用し、起動時間の中央値は約60ミリ秒を達成しました。処理が終われば環境ごと消去されるため、仮に内部で悪質なコードが実行されても、基幹システムや他データへ被害が広がる心配がありません。

さらに、データベースの認証情報や外部通信の制御を仮想マシンの外側に配置することで、AIエージェント自身にはAPIキーやパスワードを見せない設計を徹底しています。2026年7月の稼働開始以降、1日あたり数百万件のサンドボックス生成を処理しながら、118回に及ぶ外部からの脱走攻撃テストで被害0件を維持している実績は、技術的な安全網の強固さを証明しています。

エージェントの統制は、プロンプトや利用規約による言葉の約束ではなく、エンジニアリングによる物理隔離の問題だ。

公開の狙いと中小企業が陥る「誤認の罠」

PerplexityのCEOである Aravind Srinivas（アラヴィンド・スリニヴァス） は、この技術を無償公開した理由を「業界全体の安全基準を引き上げるため」と説明します。しかし、その背景には自社インフラを業界標準に仕立て上げ、エージェント開発基盤の主導権を握る明確な計算が存在します。技術を他社へ配り普及させることで、自社基盤の地位を固める狙いです。

ここで地方・中小企業の経営者が最も警戒すべきは、このニュースを「AIエージェントの事故リスクがゼロになった」と誤読することです。SPACEが防いでくれるのは、悪意あるプログラムによる「OSの破壊」「データの丸ごと漏洩」「他サーバーへの不正攻撃」といったシステム上の壊滅的被害に過ぎません。

一方で、AIが与えられた正当な権限の範囲内で引き起こす「業務上のミス」は、物理隔離では一切遮断できません。例えば、発注エージェントに「部材を補充しておいて」と頼んだ際、桁を1つ間違えて100個ではなく1000個発注してしまう事故や、顧客管理画面で必要なデータを誤って上書き削除してしまう事故です。これらはすべて「正しい権限での正常な操作」として実行されるため、どれほど強固な使い捨て環境を用意しても防げないのです。

システム隔離に頼る前に、現場が組むべき防波堤

AIエージェントを業務に導入する際、中小企業が取るべき姿勢は明確です。システム破壊を防ぐ「インフラの安全」は既存ツールやクラウド側の隔離機能に任せつつ、現場で発生する「運用のミス」を止める仕組化を自前で構築することです。過剰な技術投資をする必要はありません。

具体的には、AIにすべての権限を一任するのではなく、「読み取りや下書き作成まではAI自律」「金銭が発生する処理やデータ更新は人間が確定ボタンを押す」という役割分担を徹底します。10人規模の卸売業者や建設業者であれば、見積書の作成や発注書の生成をAIに行わせ、最後の送信前に人がチェックする「半自動化」のラインを維持することが、最も費用対効果の高い安全対策になります。

Srinivasが主張するように、AIの安全対策は「言葉の約束」から「物理的な仕組み」へと移行しました。だからこそ、現場の運用においても「AIに気をつけて作業してね」と注意喚起するのではなく、「誤発注ができない承認フローを作る」という仕組みで事故を防ぐ必要があります。壊れない環境はテクノロジーに任せ、間違えない運用は現場の知恵で固めること。これこそが、熱狂を人が担い、退屈な作業をAIへ渡すための実践的な境界線です。

30分で課題を整理する→