AIエージェントのためのCubeSandboxとは？

先週、数晩かけてCubeSandboxのリポジトリを読んだ。本番環境で動かしたわけではない――このプロジェクトが公開されたのは4月21日のことで、ツールに対して私が通常与える判断には、もっと実稼働時間が必要だ。しかしアーキテクチャ上の意思決定は、ニュースサイクルがフレーミングを掌握する前に、エージェントインフラについて何を示唆しているか書き留めておく価値がある程度には興味深い。

信頼できないコードを実行するエージェント――コードインタープリテーション、ブラウザオートメーション、RLトレーニング、あるいはモデルが何を実行するかを決定する「思考→実行→フィードバック」ループのいずれかに触れるもの――を構築しているなら、サンドボックスインフラは副次的な懸念事項ではない。負荷がかかったときに最初に壊れるものだ。CubeSandboxはその答えのひとつだ。この記事は、それが何であるか、なぜ設計上の選択が重要なのか、そしてどのチームが評価すべきかについてのものだ。切り替えるべきかどうかについてではない。

CubeSandboxとは何か、そしてTencentがオープンソース化したもの

コアアーキテクチャとポジショニング

CubeSandboxは、Tencent Cloudが2026年4月21日にApache 2.0ライセンスの下でリリースした、AIエージェント向けのオープンソースサンドボックスサービスだ。GitHub上のリポジトリはフルスタックを提供している：APIゲートウェイ、オーケストレーター、ノードごとのエージェント、ネットワーキングレイヤー、ハイパーバイザー。SDKでもなく、ホスト型サービスのラッパーでもない。自分でデプロイするものだ。

READMEから直接引用した技術的な主張：

完全に使用可能なサンドボックスのコールドスタートが60ms未満。
インスタンスあたりのメモリオーバーヘッドが5MB未満。
96コアサーバーで約2,000の同時サンドボックス。
RustVMM + KVMによるハードウェアレベルの分離で、各サンドボックスが独自のゲストカーネルを持つ。
E2B SDKプロトコル互換性――環境変数を1つ変更するだけで移行できる。

コードベースはおおよそ半分がRustで、サポートレイヤーにGoとCが使われている。アーキテクチャ概要ドキュメントは、CubeAPI（E2B互換RESTゲートウェイ）、CubeMaster（クラスターオーケストレーター）、CubeProxy（リクエストルーター）、Cubelet（ノードごとのライフサイクルマネージャー）、CubeVS（eBPFベースのネットワーク分離）、CubeHypervisor + CubeShim（仮想化レイヤー；CubeShimはcontainerdのShim v2を実装）に分けて説明している。READMEはCloud Hypervisor、Kata Containers、virtiofsd、containerd-shim-rsのアップストリームをクレジットしている――この分野の人なら誰も驚かないだろう。

実際のところ：これはFirecrackerと同じアーキテクチャファミリーのマイクロVMサンドボックスだが、別のVMM実装だ。実装品質がTencentのベアメタルテストベッド以外でも通用するかどうかは未解決の問いだ。READMEからは判断できない。

E2B互換性が重要な理由

CubeSandboxで最も興味深い設計上の選択は、60msのコールドスタートではない。意図的なE2B SDK互換性だ。

E2Bはエージェントのコード実行においてほぼデフォルトになっている。Manusはそれを使っている。モデルが生成したコードを実行する必要があるLLMアプリの長いテールは、まずそれに手を伸ばす。そのSDKプロトコル――from e2b_code_interpreter import Sandbox、URLを指定してコードを実行する――は、このカテゴリーが持つものの中でデファクトのインターフェースに最も近いものだ。

そのプロトコルを踏襲することで、CubeSandboxはほとんどの「代替品」が抱える問題を回避している：開発者に新しいSDKを学ばせること。移行パスは環境変数1つだ。既存のエージェントコードは変更しない。すでにE2Bに対してビルドしているなら、CubeSandboxをテストする摩擦は四半期ではなく、午後1つ分だ。

リポジトリを読んでいて、ここで立ち止まった。この互換性は、CubeSandboxが「より優れている」ことを証明するためのものではない。実験を安価にするためのものだ。それが賢い賭けだ。

エージェントインフラにおいてサンドボックスが重要な理由

分離、起動時間、同時実行性

サンドボックスはエージェントシステムに対して同時に3つのことを行い、そのひとつをトレードオフすることなく他を損なうことはできない。

分離。 モデルがコードを生成するとき、実行してみるまでそれが何をするかわからない。ホストカーネルを共有するコンテナでは不十分だ。ゲストカーネルの権限昇格バグひとつ、またはDockerエスケープひとつで、エージェントはホストのファイルシステム、ホストの認証情報、ホストのネットワークに到達してしまう。マイクロVMは各サンドボックスに独自のゲストカーネルを与えることでこれを解決する――名前空間の境界ではなく、ハードウェア仮想化された境界だ。これはLambda向けにFirecrackerをオープンソース化した際にAWSが主張したのと同じ議論だ：コンテナはマルチテナントのコード実行には壁として薄すぎる。

起動時間。 「この出力を確認するためにこのPythonスクリプトを実行しよう」と決定するエージェントは、その決定をウォールクロック予算のミリ秒単位で行っている。サンドボックスの起動に2秒かかるなら、フィードバックループはすでに壊れている。モデルが速くても製品は遅く見える。Firecrackerは約125msの起動時間を達成し、マイクロVMをサーバーレスで実用的にした。E2Bのホスト型サービスは事前ウォームアップされたプールで約150〜200msを報告している。CubeSandboxは事前プロビジョニングされたリソースプールとスナップショットクローニングにより60ms未満を主張している。その数値が維持されれば、どの種類のエージェントループが実用的かが変わる。自分のハードウェアで確認してから引用するようにしたい。

同時実行性。 ユーザーあたり1つのサンドボックスは簡単なケースだ。エージェントステップあたり、ユーザーあたり1つのサンドボックスで、何千ものエージェントが同時進行しているのが難しいケースだ。制約は「1つがどれだけ速く起動するか」から「1台のマシンでいくつ実行できるか」にシフトする。96コアマシンで2,000以上と組み合わせた5MBあたりのインスタンス数値が、密度の主張だ。実際のワークロード――Pythonインタープリター、ブラウザ、依存関係を実際にロードするサンドボックス――でこれが生き残るかどうかが、また未解決の問いだ。

これらの3つは互いに引っ張り合っている。より強い分離は通常、より重いVM、より遅い起動、より低い密度を意味する。興味深いマイクロVMシステムはそのトレードオフを拒否する。

スケール時にこれが製品のボトルネックになる理由

シングルユーザーのプロトタイプでは、これらは何も問題にならない。エージェントの後ろにDockerコンテナを置き、セキュリティの負債を受け入れ、出荷する。コストは見えないままだ――そうでなくなるまでは。

3つのポイントで見えるようになる。これらはすべて実際に展開されるのを見てきた：

ステップあたりのレイテンシ。 単一の推論トレースでサンドボックスを20回呼び出すエージェントは、コールドスタートを20回継承する。それぞれ200msで、ユーザーの知覚する応答時間に4秒の純粋なインフラレイテンシが加わる。モデルは遅くなっていない。インフラが遅くなった。

マルチテナント同時実行性。 有料ユーザーが同時にエージェントを実行すると、「ユーザーあたり1つのVM」は線形にスケールしなくなる。ホスティング費用が収益より速く増える。カーネルを共有して分離リスクを受け入れるか、より悪いマージンを受け入れるかのどちらかだ。基礎となるプリミティブを変えること以外に第三の選択肢はない。

実験から本番へのギャップ。 1つのサンドボックスで局所的にはすべてうまくいく。本番では、スナップショットウォームアッププールに有限のサイズがあること、負荷がかかるとコールドスタートが戻ってくること、サンドボックスが互いに通信したり通信すべきでない場合に注意を払わなかったeBPFネットワークポリシーが重要になり始めることが明らかになる。これが立ち上げの投稿で過小評価される地味な部分だ。

CubeSandboxは、ハードウェア分離、低メモリオーバーヘッド、60ms未満の起動が同時に達成可能であり、本番チームがその3つの壁にぶつかれば気にかけるだろうと賭けている。それが報われるかどうかは、実行と採用の問題だ。どちらもまだ未解決だ。

CubeSandboxを評価すべきチームとそうでないチーム

本格的に検討する価値があるもの：

すでにE2Bを使用していてコストや同時実行性の制限に達しており、いずれにせよセルフホスティングを検討しているチーム。移行は実際に1行の変更だ。
コンプライアンスやデータ居住要件のためにサードパーティのクラウドを排除する必要がある内部エージェントプラットフォームを構築しているインフラチーム。Apache 2.0 + セルフホストが前提条件だ。
サンドボックス作成レートが高いRLトレーニングループを実行しており、コールドスタートコストが内部のトレーニングループに存在するチーム。何百万ものエピソードに乗算された100msの改善は実際のお金だ。
現在の設定が「ハードニングフラグ付きのDockerコンテナ」であり、脅威モデルがこっそりそれを超えてしまったチーム。切り替えの正直な瞬間は、インシデントの後ではなく前だ。

今のところおそらくスキップ：

プロトタイプとシングルユーザーのデモ。マイクロVMクラスターの立ち上げコストは、低い呼び出し量では正当化されない。
ベアメタルアクセスまたはKVM対応VMがないチーム。ハードウェア要件は本物だ――KVM付きのx86_64 Linux。ネステッド仮想化なしの標準クラウドVMはそのままでは該当しないが、PVMパスがこれを拡大する。
移行コストがランタイムの節約を上回る非E2B SDKに深く組み込まれたスタックを持つ誰か。互換性は助けになる；切り替えコストを完全にはなくさない。

コードとドキュメントを読んで確認できるのはそれだけだ。残りは本番での実稼働時間が必要で、まだそこには置いていない。

FAQ

CubeSandboxはどんな問題を解決するのか？

ホストカーネルを共有せず、低レイテンシで、高い同時実行性を持ちながら、AIが生成したコードを分離して実行するためのランタイムだ。ターゲットとする問題は、すべてのエージェントプラットフォームが最終的に直面するものだ：コンテナは信頼できないコードにとって漏れやすすぎる、従来のVMは遅すぎて重すぎる、既存のマイクロVMオプションはプロプライエタリか運用が複雑だ。

コンテナのみのアプローチとどう違うのか？

コンテナのみのアプローチはホストカーネルを共有する。ゲストカーネルのエクスプロイトがホストに到達する。CubeSandboxはKVMベースのハードウェア仮想化を介して各サンドボックスに独自のゲストカーネルを与える――LLMが何かがおかしくなったとき、またはユーザーがそうさせようとしているときに発するコードの種類に対するより強固な境界だ。報告されているメモリオーバーヘッド（インスタンスあたり5MB未満）も、歴史的にVMをコンテナと比較して経済的でなくさせていた密度のギャップを埋める。

E2B互換性はなぜ重要なのか？

新しいサンドボックスを試すコストは通常、試用そのものではなく移行プロジェクトだからだ。E2BのSDKは十分な採用があるため、互換性によりチームは環境変数を1つ変更するだけでCubeSandboxをテストできる。それが「来四半期に評価しよう」と「今夜立ち上げてみよう」の違いだ。プロトコルの選択が採用の重労働をこなしている。

どのチームが最初にテストすべきか？

すでにE2Bを非自明な量で使用しているチーム、セルフホスティングを必要とするコンプライアンス制約があるチーム、コールドスタートレイテンシがユーザー向けの応答時間に現れる密なエージェントループを実行しているチーム。小規模なユーザーは待てる――早期採用は節約できる以上のコストがかかる。

まとめ

エージェントの下にあるインフラは本物のカテゴリーになりつつある。2024年の大部分から2025年にかけて、サンドボックス化は副次的な懸念事項だった――便利なもので対処されていた。今、実際のユーザーの前にエージェントを置いているチームは、サンドボックスの選択がリクエストあたりのレイテンシからユーザーあたりのマージンまですべてを形作ることを発見しつつある。

CubeSandboxは根本的な物理を変えない。マイクロVMはすでに正しいアーキテクチャ上の答えだった；未解決の問いは常に実装品質と採用の摩擦だった。このリポジトリは最初の点で競争力のある数値を主張し、E2Bのプロトコルをネイティブに話すことで2番目の点に対処している。Tencentのテストベッド以外の本番の手でその数値が維持されるかどうかが、次の数ヶ月が明らかにするものだ。

テストクラスターにデプロイして、コールドスタートの主張を自分のワークロードに対して確認する予定だ。要検証。データが得られたら戻ってくる。

過去の投稿：