起動60ms CubeSandboxでエージェント高密度実行

LLMが生成したコードを安全に動かすには、隔離環境の起動速度と密度がボトルネックになりやすい。Tencent CloudがApache 2.0で公開したCubeSandboxは、起動60ms未満・1インスタンス5MB未満のオーバーヘッドで、1台のサーバーに数千のエージェントを載せられる設計です。

この記事では、CubeSandboxの技術構成とE2B SDK互換による移行方法、Dockerや従来VMとの違いを整理します。

この記事でわかること

• CubeSandboxが解決するAIエージェント実行の課題
• RustVMMとKVMによるハードウェアレベル隔離の仕組み
• E2B SDK互換でURL差し替えだけで移行できる理由
• E2BやDockerコンテナとの性能・運用面の違い

AIエージェント実行で起きる隔離と密度の矛盾

AIエージェントは、コード実行・ファイル操作・外部API呼び出しを自律的に行います。LLMが出力したコードは信頼できないため、ホスト環境から切り離した実行領域が必要です。

Dockerコンテナは起動が比較的速い一方、ホストカーネルを共有するため、カーネル共有型の隔離にとどまります。従来の仮想マシン（VM）はカーネルごと分離できますが、起動に数秒かかり、1台あたりの密度も低くなります。E2BのようなサンドボックスSaaSはFirecrackerベースのマイクロVMで実用速度を実現していますが、利用量に応じた課金やデータ持ち出しの制約が運用コストになります。

CubeSandboxは、この「隔離の強さ」「起動速度」「1台あたりの密度」「自前ホストでの運用」を同時に狙うOSSです。2026年4月20日にv0.1.0で初のオープンソース公開が行われ、2026年7月3日時点の最新版はv0.5.0です（参考）。

CubeSandboxとは

https://github.com/TencentCloud/CubeSandbox

CubeSandboxは、Tencent Cloudが開発したAIエージェント向けのサンドボックス基盤です。RustVMMとKVM（Kernel-based Virtual Machine）上にMicroVMを立て、各サンドボックスに専用のゲストOSカーネルを割り当てます。Dockerの共有カーネルではなく、VM相当の隔離をミリ秒単位の起動で実現するのが特徴です。

公式READMEのベンチマークでは、DockerコンテナのフルOS起動が200ms、従来VMが数秒に対し、CubeSandboxは60ms未満と記載されています。1インスタンスあたりのメモリオーバーヘッドは5MB未満で、1ノードに数千のエージェントを載せられる密度をうたっています（参考）。

ベアメタル環境での計測値は、単一同時実行で60ms、50同時作成時でも平均67ms・P95 90ms・P99 137msと、150ms未満を維持しています。メモリオーバーヘッドはサンドボックス仕様32GB以下の条件で計測されており、インスタンスサイズが大きくなっても増加は限定的です。

ライセンスはApache 2.0。CNCF LandscapeのAI Native Infrastructureにも掲載されています。

主な機能とアーキテクチャ

CubeSandboxは複数コンポーネントで構成されます。CubeAPIがE2B互換のREST APIゲートウェイを提供し、CubeMasterがクラスタ全体のスケジューリングを担います。CubeProxyがE2Bプロトコルに沿ってリクエストを各サンドボックスへルーティングし、Cubeletがノード上のMicroVMライフサイクルを管理します。

ネットワーク面では、eBPF（extended Berkeley Packet Filter）ベースのCubeVSがサンドボックス間の通信をカーネルレベルで分離します。CubeEgressはL7ドメインフィルタや認証情報の注入を担い、v0.4.0以降はCredential VaultによりAPIキーがサンドボックス内部に入らない設計になっています。

v0.3.0で導入されたCubeCoW（Copy-on-Write）エンジンは、実行中サンドボックスのスナップショット取得・クローン・ロールバックを100ミリ秒粒度で行えます。v0.5.0ではAutoPause/AutoResumeが追加され、アイドル状態のサンドボックスを自動停止し、次のリクエストで復帰させるライフサイクル管理が可能になりました。

OCIイメージからテンプレートを1ステップで作成する機能や、ブラウザ上でサンドボックスを管理するWebUI（ポート12088）も備えています。SWE-bench向けの強化学習、OpenClaw連携、OpenAI Agents SDK連携などのサンプルも公式リポジトリに公開されています。

E2B SDK互換でURL差し替えだけで移行できる

CubeSandboxの実用性を押し上げているのが、E2B SDKとのネイティブ互換です。E2BはLLM生成コードの実行基盤として広く使われており、Python SDKのe2b_code_interpreterなど既存コード資産が多く存在します。

CubeSandboxでは、環境変数E2B_API_URLを自前ホストのCubeAPIエンドポイント（例: http://127.0.0.1:3000）に向けるだけで、SDK側のコード変更なしに接続先を切り替えられます。公式クイックスタートでも、from e2b_code_interpreter import SandboxのままSandbox.create()を呼ぶ手順が示されています（参考）。

必要な環境変数は次のとおりです。

テンプレートはcubemastercli tpl create-from-imageでOCIイメージから作成します。インストール後はワンクリックスクリプトでCubeMaster、Cubelet、CubeProxy、MySQL、Redisがセットアップされ、E2B互換REST APIがポート3000で待ち受けます。

料金と運用コスト

CubeSandbox本体はApache 2.0のオープンソースで、ライセンス料はかかりません。コストは自前サーバーやクラウドVMのインフラ費用に集約されます。

対照的にE2Bのマネージドプランは、Hobby（無料枠＋$100クレジット）、Pro（$150/月＋従量課金）、Enterprise（BYOC・オンプレ）といった料金体系です。E2BもApache 2.0でOSS化されていますが、多くのチームはホスト型クラウドをデフォルトで使います。

CubeSandboxを自前運用すれば、利用量増加に伴う従量課金の急増を抑えられ、データが自社ネットワーク外に出ない構成も組みやすくなります。一方、カーネル更新、eBPFポリシー調整、障害対応は自チームの責任になります。v0.5.0ではTencent Cloud向けTerraformデプロイヤーも追加され、VPC・TKE・MySQL・Redisを含むクラスタ構築を自動化できます。

E2BやDockerとの違い

隔離方式の違いが最も大きいポイントです。Dockerは共有カーネル上の名前空間分離、CubeSandboxとE2Bは専用カーネルを持つMicroVM型です。CubeSandboxはeBPFを加えた「Dedicated Kernel + eBPF」と位置づけています。

起動速度では、Dockerが200ms、E2Bがスナップショットプール利用時に150〜200ms程度、CubeSandboxが60ms未満と公式に整理されています。密度面では、CubeSandboxが5MB未満のオーバーヘッドで数千インスタンス/ノードをうたう点が際立ちます。

運用面では、E2Bマネージドはインフラ担当なしで素早く始められる利点があります。CubeSandboxはKVM対応のx86_64 Linux（またはARM64ベアメタル）が前提で、MacやWindowsネイティブ環境には向きません。PVM（Pagetable-based Virtual Machine）を使えばKVM非対応のクラウドVM上でもネスト仮想化を可能にしますが、PVMはx86_64専用です。

E2B互換を維持しつつ自前ホストで高密度実行したいチーム、RL訓練やエージェント群の大量評価など同時実行数が課題になる用途、データレジデンシー要件がある環境にCubeSandboxは向いています。

導入の第一歩

最小構成では、KVM対応のLinuxサーバーにワンクリックインストーラを実行し、テンプレート作成、Python SDKでの接続確認まで4ステップで完了します。/data/cubeletにはXFSファイルシステムで50GB以上の空き容量が必要です。

既にE2B SDKでエージェントを組んでいる場合は、E2B_API_URLの差し替えだけ先に試すのが最短です。v0.5.0時点でGo/Python SDKはE2BのファイルシステムAPIやPTY APIにも対応が進んでおり、移行ギャップは縮小方向にあります。

AIエージェントの本番運用では、隔離の強さと起動コストのバランスがサービス品質を左右します。CubeSandboxはその両立を狙った中国発のOSSとして、E2Bエコシステムにそのまま載せ替えられる実装まで用意している点が注目に値します。