Perplexityが公開したSPACE、AIの実行環境を隔てる意味
ニュースの概要
Perplexityが、AIエージェントにコードを実行させるための基盤「SPACE」をApache 2.0ライセンスで公開した。中核はFirecrackerという軽量な仮想マシン技術である。エージェントの作業ごとに専用の仮想マシンを立ち上げ、それぞれが独自のカーネル（＝OSの中心部分）を持つ。さらにパスワードやAPIキーなどの認証情報は仮想マシンの外で管理し、中のコードには直接渡さない。外へ出る通信もホスト側で制御する設計だという。AIが書いたコードをそのまま動かす場面が増えるなか、実行環境の隔離を企業が自前で作らなくても済む選択肢が、公開された形になる。
引用元: PerplexityのAIエージェント向けサンドボックス「SPACE」が公開（Twarx）
分析・見解
コンテナでは足りない、という判断が示された
これまでAIエージェントの実行環境には、Dockerなどのコンテナが広く使われてきた。軽くて速いからである。ただしコンテナは、ホストのカーネルを共有する。つまり、中で動くコードがカーネルの弱点を突けば、外の世界に出られる可能性が残る。
SPACEはここを避け、作業ごとに独立したカーネルを持つ仮想マシンを使う。Firecrackerは、AWS LambdaやFargateの裏側で使われてきた技術だ。起動が速く、メモリの消費も小さい。隔離の強さと速さを両立できる点が、採用の理由と読める。
本当に守りたいのは、鍵と通信の出口
今回の設計で最も重要なのは、認証情報をVMの外に置く点だと考える。エージェントは、外部から読み込んだ文章に悪意ある指示が紛れていても、気づけないことがある。これをプロンプトインジェクション（＝AIへの命令のすり替え）と呼ぶ。
このとき、VMの中に鍵があれば、そのまま盗まれる。鍵が外にあれば、中のコードは「使う権限」だけを借りる形になる。外向きの通信をホスト側で見張れば、盗もうとしても出口で止められる。壁を厚くするより、盗まれて困るものを最初から中に置かない。発想の転換である。
先行するサンドボックス基盤との違い
似た領域には、E2BやModal、Daytonaなどの商用サービスがある。多くはクラウドとして提供され、利用料がかかる。一方でSPACEは、Apache 2.0で自社運用できる。ソースを読み、自分の環境に合わせて直せる点が大きな違いだ。
もっとも、公開されたのは基盤であり、運用の手間まで消えるわけではない。VMイメージの更新、ログの保管、リソース枠の設計は利用者側の仕事になる。ここを軽く見ると、安全な箱を手に入れたつもりで穴だらけ、という事態になりかねない。
隔離が標準部品になる流れは止まらない
今後は、エージェントを動かす際の隔離が「あると安心」ではなく「なければ監査を通らない」要件に変わっていくだろう。大手が実装を公開した意味は、そこにある。
筆者は、各社の設計が似通っていく可能性が高いと見ている。独立カーネル、鍵の外部管理、通信の出口制御。この三点がそろえば、あとは使い勝手の競争になる。ローカルで軽く動かす方向では、当サイトで扱うsmolvmのような小さな仮想化も、選択肢として並ぶはずだ。
ビジネスへの影響
自社でエージェントを動かすなら、最初に確認すること
まず確認したいのは、いま動かしているエージェントが、どこでコードを実行しているかだ。開発者のパソコン上で直接動いていたり、鍵が環境変数に入ったままだったりする例は珍しくない。
最初の一歩としては、次の三点を点検するとよい。実行場所が本番の仕組みから切り離されているか。鍵がコードから見える場所にないか。外への通信先が制限されているか。SPACEを導入しなくても、この三点だけで事故の確率は大きく下がる。
導入するか、買うか、見送るかの判断軸
社内に基盤を運用できる人材がいるなら、SPACEのようなオープンソースは有力だ。顧客データを外に出せない業種では、特に相性がよい。ライセンス料がかからない分、人件費と運用の責任は自社に残る。
人手が足りないなら、商用のサンドボックスを使うほうが現実的である。月数万円の利用料は、障害対応一回の工数より安く済むことが多い。迷う場合は、まず小さな社内ツール一つで試し、運用の負担を測ってから広げるのが堅実だろう。
どちらを選ぶにしても、取引先や監査から「AIにコードを実行させる環境の隔離はどうなっているか」と問われる日は近い。答えを用意しておくこと自体が、信頼につながる。