AIエージェント用OSS「CubeSandbox」の仕組みと特徴

AIエージェントに任意のコードを実行させる用途では、Docker コンテナだけでは分離が甘く、通常の仮想マシンでは起動時間・メモリオーバーヘッドが大きすぎるという設計上のジレンマが以前から知られています。マネージドサービスの E2B がこの領域の事実上の標準になった一方で、「オンプレで動かしたい」「大量のサンドボックスを高密度で並列稼働させたい」という要件に応える OSS 選択肢はしばらく限定的でした。

こうした背景の中、TencentCloud が 2026 年 4 月に公開したのが「CubeSandbox」です。RustVMM と KVM を土台にした、AIエージェント向けの高性能サンドボックスサービスで、E2B の SDK と互換の API を持ち、単一ノードからマルチノードクラスタまでスケールできるとされています。

本記事では、CubeSandbox の GitHub リポジトリ・公式ドキュメント・README の内容をもとに、この OSS が解決する課題・主要機能・アーキテクチャ・類似リポジトリとの違い・導入時の前提・メンテナンス状況を整理します。動作検証やインストールは行わず、公式資料の内容のみをベースとした解説です。

読み終えたときに、AIエージェント基盤を検討しているエンジニアが「CubeSandbox は自プロジェクトの候補になるか」「E2B や Firecracker と比べて何が違うか」を一次判断できることを目指します。

CubeSandboxとは

CubeSandbox は、TencentCloud IaaS Frontier Technology Team が開発・公開している OSS で、公式説明は「Instant, Concurrent, Secure & Lightweight Sandbox for AI Agents」です（公式リポジトリ）。AIエージェントが生成した任意のコードを、ハードウェアレベルで分離された環境で高速に実行することを目的としています。

初回の OSS 公開は 2026 年 4 月で、Tencent Cloud News でも「AIエージェント向けの高性能サンドボックス」として発表されています（Tencent Cloud News）。CNCF Landscape にも掲載されており、AI ネイティブインフラのワークロードランタイム領域に位置づけられています（CNCF Landscape）。

リポジトリの基本情報

gh api /repos/TencentCloud/CubeSandbox で取得した本記事執筆時点（2026 年 7 月）の主要属性は以下の通りです。

archived=false かつ fork=false のため、本家として現在も継続開発されているプロジェクトです。ライセンスは README で Apache 2.0 と明記されており、商用利用・改変・再配布が可能な条件になっています。

開発元と OSS 化の経緯

CubeSandbox の開発元は Tencent Cloud のインフラ先端技術チームで、内部的に AIエージェント向けサンドボックス技術として運用されていたものが 2026 年 4 月にオープンソース化されました。README では、AIエージェントが生成する任意コードを「安全に・高速に・並列で」実行するインフラ需要が急拡大していることが OSS 化の背景として説明されています（公式リポジトリ）。

CubeSandboxが解決する課題

CubeSandbox が対象にしているのは、AIエージェントに任意のコードを実行させる際の「分離」と「起動オーバーヘッド」のトレードオフです。README のベンチマークセクションでは、Docker コンテナ・Traditional VM・CubeSandbox の 3 者を対比しながら、各アプローチの限界と CubeSandbox のポジションが整理されています。

Docker コンテナはホストとカーネルを共有するため、コールドスタート時間は 200ms 前後と高速な一方、悪意あるコードやサンドボックスエスケープ耐性という観点では「共有カーネル」の制約が残ります。逆に伝統的な仮想マシンは分離レベルは高いものの、起動が秒級・メモリオーバーヘッドが大きく、AIエージェントが数百から数千のサンドボックスを短寿命で回すユースケースには不向きとされています。

CubeSandbox はこの中間地点として設計されており、公式ベンチマークでは以下の数値が示されています（公式リポジトリ）。

• 単一同時接続でのコールドスタート 60ms 未満
• 50 並列でも平均 67ms、P95 90ms、P99 137ms（一貫して 150ms 未満）
• 1 サンドボックスあたりのベースメモリオーバーヘッド 5MB 未満（≤32GB スペック時）

つまり「専用カーネル + ハードウェアレベルの分離」を保ったまま、コンテナに近い起動速度と密度を実現することを狙った OSS といえます。

なお、これらの数値は公式ドキュメントで公表されている値であり、本記事は実機での再測定を行っていません。実運用での確認は各読者のワークロードで行う必要があります。

CubeSandboxの主要機能と特徴

公式ドキュメントの Home では、CubeSandbox の主要機能ハイライトが列挙されています（公式ドキュメント Home）。ここでは、採用判断に直結する 7 つの中核機能を取り上げて整理します。

60ms級のコールドスタートと高密度稼働

前述の通り、CubeSandbox はコールドスタートを 60ms 未満に抑える設計になっています。README には「96 コアサーバで 2,000+ サンドボックス同時稼働」というスケール事例も紹介されており、AIエージェントが短命なサンドボックスを大量に生成・破棄するワークロードでの利用が想定されています。

ハードウェアレベルの分離

各サンドボックスに専用の Guest OS カーネルが割り当てられます。ホストと Guest でカーネル空間が独立するため、コンテナランタイム系（共有カーネル）とは異なるレベルの分離が得られる、と公式ドキュメントは説明しています。

E2B SDK 互換によるドロップイン移行

CubeSandbox は E2B の SDK 互換を明示的に掲げており、E2B マネージドサービスを利用中のコードから CubeSandbox セルフホストへ移行する際に、URL の環境変数を差し替えるだけで動作する設計になっているとされています。SDK 全体の完全互換はロードマップにも「E2B API 完全互換」として掲載されており、段階的に拡張されている状況です。

CubeCoW によるスナップショット・クローン・ロールバック

v0.3.0 で導入された CubeCoW エンジンは、FICLONE ioctl を使ったコピーオンライトによる O(1) スナップショット・クローン・ロールバックを提供します。AIエージェントの試行反復（同一の初期状態から複数の分岐を走らせて結果を比較する）に適しています。

AutoPause / AutoResume

v0.5.0 で追加された機能で、アイドル状態のサンドボックスを自動でサスペンドし、リクエストが来たタイミングで自動復帰させます。「大量に生成したものの実際に稼働しているのは一部だけ」という状況で、メモリと CPU の消費を抑える設計です。

Credential Vault と Egress 制御

v0.4.0 で導入された Credential Vault は、API キーなどのシークレットをサンドボックス側から見えない場所に隔離し、モデルコンテキスト・実行ログにも露出させないようにする仕組みです。あわせて、CubeEgress による L7 レベルのドメイン許可リスト・監査ログ機能により、AIエージェントが意図しない外部通信を行うリスクを低減する設計になっています。

Web コンソールと Template Store

セットアップ後、:12088 ポートで Web コンソールにアクセスでき、テンプレート状態の確認・サンドボックス管理・ダッシュボード確認が可能とされています。OCI イメージをテンプレートとして登録する Template System と、公式プリセットが配布されている Template Store により、初期セットアップから利用開始までの動線が短縮されているとの説明です。

CubeSandboxのアーキテクチャ構成

CubeSandbox のアーキテクチャは、Control Plane（クラスタ制御層）と Data Plane（各ノード上の実行層）の 2 層で構成されます（アーキテクチャ設計書）。

全体構成: Control Plane と Data Plane

Control Plane は、E2B 互換の REST API ゲートウェイである CubeAPI と、クラスタオーケストレータの CubeMaster、そしてクラスタ全体のメタデータ SSOT として使われる Redis で構成されます。CubeMaster がノードへのスケジューリング・ライフサイクル管理を担い、状態はすべて Redis 経由でやりとりされる設計です。

Data Plane は、各ノード上で以下のコンポーネントを組み合わせて動作します。

• Cubelet: ノードローカルのサンドボックス・ライフサイクル管理
• CubeShim: containerd Shim v2 API 実装
• CubeHypervisor: RustVMM + KVM ベースの MicroVM 管理
• CubeVS: eBPF を使ったカーネル空間のネットワーク分離とセキュリティポリシー
• CubeCoW: FICLONE ioctl による O(1) スナップショット・クローン
• CubeEgress: L7 egress ゲートウェイ（ドメイン許可・クレデンシャル注入・監査）
• CubeProxy: E2B プロトコル互換のリバースプロキシ

主要コンポーネントの役割一覧

各コンポーネントの役割と実装言語を整理すると以下の通りです（詳細は公式アーキテクチャ設計書を参照）。

採用技術と設計判断

コンポーネント一覧から読み取れる設計判断として、以下の点が挙げられます。

• Rust と Go の使い分け: 低レベルなハイパーバイザ・シム・COW エンジンは Rust、クラスタ制御や上位ライフサイクル管理は Go という言い分け。RustVMM や containerd-shim-rs といった既存 OSS を活用しつつ、書きやすさと安全性を両立している
• eBPF によるネットワーク分離: CubeVS でカーネル空間のパケットフィルタ・ポリシーを実装。iptables ベースの管理に比べて動的な変更と高いスループットが期待できる
• OpenResty を採用したプロキシ層: E2B プロトコル互換のプロキシ・L7 egress ゲートウェイに OpenResty（Nginx + Lua）を採用。既存のリバースプロキシ運用ノウハウを活用しやすい
• containerd Shim v2 API 準拠: CubeShim が containerd の Shim v2 API に準拠しているため、既存の containerd エコシステムから呼び出せる余地がある

RustVMM や Kata Containers、virtiofsd、containerd-shim-rs、ttrpc-rust への謝辞が README にあり、これらの上位技術を活用したフルスタックとして構成されていることが読み取れます。

類似リポジトリとの比較で見えるCubeSandboxのポジション

CubeSandbox は「AIエージェント向けサンドボックス」というカテゴリでは唯一の存在ではなく、複数の類似 OSS が存在します。選定判断のために、代表的な 4 つのプロジェクトと CubeSandbox の位置づけを整理します。

E2B との比較

E2B（12.9k stars）は、AIエージェント向けサンドボックスの事実上の標準 SDK として広く使われており、Firecracker ベースのマネージドサービスと SDK を提供しています。E2B のドキュメントではコールドスタート 500ms 未満と紹介されており、開発者は SDK 経由で数行のコードでサンドボックスを利用できます。

CubeSandbox は、この E2B の SDK 互換をセルフホストで実現する E2B 代替 という立ち位置です。E2B のマネージドを使い続ける場合と比べて、以下のような要件を満たしたい場合に E2B 代替の選択肢として候補になります。

• コスト・データ主権・オンプレ要件から自ホストで運用したい
• 単一マネージド環境ではなく、大規模並列（96 コアで 2,000+ 同時）を自クラスタで確保したい
• コールドスタートを一段速く（60ms 級に）したい

Firecracker との比較

Firecracker は AWS Lambda や AWS Fargate を支える低レベル microVM プリミティブで、起動時間は 125ms 未満と公表されています。ただし Firecracker はあくまで「microVM ランタイム」という部品であり、オーケストレーション・API ゲートウェイ・ネットワーク分離・スナップショット・Web コンソール等はユーザ側で実装する必要があります。

CubeSandbox はその 1 レイヤ上に、E2B 互換 API・クラスタオーケストレータ・eBPF ベースのネットワーク・CubeCoW スナップショット・Web コンソールまでをフルスタックでまとめた形になります。「Firecracker を自前で組み立てる工数を省きたい」ニーズにマッチする構成です。起動時間の公称値も 60ms 未満と Firecracker より短くなっています。

Kata Containers / Microsandbox との比較

Kata Containers は「secure container runtime」として、Kubernetes ワークロード全般を対象とする汎用の VM ベース分離ランタイムです。CubeSandbox の CubeShim は containerd Shim v2 API に準拠しており、内部的にも Kata Containers への謝辞があります。

一方 CubeSandbox は「AIエージェント特化」の設計で、E2B SDK 互換・CubeCoW スナップショット・大量並列生成といった、エージェント特有のワークロードに最適化されている点が Kata Containers との違いです。「特定の用途に特化した機能セットと性能を優先したい」場合に選択候補になります。

Microsandbox は libkrun ベースの microVM サンドボックスで、単一バイナリ・デーモンレス運用を志向しています。個人開発者や小規模利用には向いていますが、マルチノードクラスタ・Terraform を使ったクラスタデプロイ・Web コンソール・eBPF ネットワークといった プラットフォーム提供者向けの機能 は Microsandbox の主軸ではありません。CubeSandbox はこのプラットフォーム提供者側のニーズに寄せた設計といえます。

比較表: 5 つの主軸で見る違い

分離モデル・起動速度・SDK 互換・セルフホスト可否・スケール志向の 5 軸で整理すると以下のようになります（各値は各リポジトリの公式ドキュメント・README の公称値を基にしています）。

CubeSandbox が選択候補になるのは、「E2B SDK 互換をセルフホストで実現し、かつクラスタ規模で高密度に運用したい」というニーズが中心である、と整理できます。

CubeSandbox導入時の前提とデプロイ構成

導入判断の際に把握しておきたいのが、システム要件と提供されているデプロイパスです。ここでは、Quick Start ガイドと README に記載された内容を整理します（Quick Start ガイド）。

システム要件

必須要件として、公式ドキュメントには以下の項目が挙げられています。

• x86_64 Linux（v0.5.0 で ARM64 ネイティブフルサポートが追加）
• KVM サポート（/dev/kvm が利用可能なホスト、または KVM をパススルーした仮想化環境）

KVM 必須であるため、ネストされた仮想化が有効化されていないクラウド VM や、KVM 非対応のパブリッククラウド環境では動作しません。オンプレのベアメタル、KVM パススルーを許可するクラウド、あるいは Tencent Cloud の PVM のような専用インスタンスが必要になります。

4 つのデプロイパス

Quick Start ガイドでは、4 つのデプロイパスが提示されています。

本番採用を検討する場合は「PVM · Cloud VM」または「Bare Metal」が推奨されており、開発・PoC 用途では Dev-Env が用意されている構成です。Terraform デプロイは v0.5.0 で新規追加された機能で、Tencent Cloud を利用しているユーザ向けに導入コストを下げる目的があります。

Web コンソールと Template Store

セットアップが完了すると、Web コンソールが :12088 ポートで公開されます。README では「テンプレートの状態確認・サンドボックス管理・ダッシュボード確認」がここから可能とされています。あわせて、OCI イメージをテンプレートとして登録する Template System と、公式プリセットが配布されている Template Store が提供されており、初期セットアップから利用開始までの動線が短縮されているとの説明です。

CubeSandboxのメンテナンス状況とロードマップ

OSS を本番採用する際に多くのエンジニアが確認するのが、リリース頻度・直近のコミット状況・ロードマップの明確さです。CubeSandbox はこの点でも判断材料が公開されています。

リリース履歴（2026 年 4 月〜 7 月）

README の News セクションから、初回 OSS 化以降のリリースを抜粋すると以下の通りです。

2026 年 4 月に OSS 化されて以降、約 1〜2 か月ペースでマイナーバージョンが公開されており、直近の push も 2026-07-10 と 1 週間以内にコミットが入っている状況です。少なくとも本記事執筆時点では、明確にアクティブなプロジェクトといえます。

公式ロードマップの主要項目

Roadmap には、次のような大きなマイルストーンが掲載されています（Roadmap）。

• Kubernetes-Native デプロイ（CRD / operator / ネイティブスケジューリング）
• Volume Support（E2B の volume プロトコル互換）
• Cross-Node Pause & Resume（メモリ・ファイルシステム状態を保持したまま別ノードへ移動）
• E2B API 完全互換（現時点で部分互換の SDK レベル互換をさらに拡張）
• Control Plane / Data Plane 分離（現状の設計をさらに厳密に分離）
• Sandbox Fault Recovery（サンドボックス障害からの復旧強化）
• Scheduling & Operations 強化（マルチテナント運用に必要な仕組みの拡充）

「Kubernetes-Native デプロイ」「E2B API 完全互換」「Cross-Node Pause & Resume」は、既存の VM 系サンドボックス OSS と差別化する重要なマイルストーンであり、これらの進捗状況が採用判断の継続的な観察ポイントになります。

コミュニティ活動

コミュニティ動線として、GitHub Issues / Discussions、Discord（招待コード kkapzDXShb）、X（旧 Twitter）アカウント @CubeSandbox_AI が提供されています。CONTRIBUTING.md も整備されており、「End User Program」（Issue #158）で早期採用者との対話が行われている点も、開発元がコミュニティ形成に取り組んでいる兆候といえます。

まとめ: CubeSandboxがフィットするケース・しないケース

ここまでの内容を整理すると、CubeSandbox は「AIエージェント特化の高性能サンドボックスをセルフホストで組みたい」チームに向いた OSS だと位置づけられます。特に、以下のようなユースケースにフィットします。

• AIエージェント基盤を自社で持ちたい: マネージド E2B を離れて、コスト・データ主権・カスタマイズ性を確保したいケース
• E2B からセルフホストへ段階移行したい: SDK 互換によりコード変更を抑えつつ移行できる
• 大量のサンドボックスを高密度で運用したい: 96 コアサーバで 2,000+ 同時稼働という公称値が示す通り、高密度並列を志向

一方、以下のようなケースでは他の選択肢の方が向いている可能性があります。

• とにかくマネージドで済ませたい: 運用工数を最小化したい場合は E2B マネージドや類似 SaaS の方が適合します
• ARM64 環境が主軸: v0.5.0 で ARM64 対応が入りましたが、まだ x86_64 中心の設計です
• 超小規模・単一開発者利用: 単一バイナリ・デーモンレス志向であれば Microsandbox の方が導入コストが低い可能性があります
• 汎用の K8s ワークロードでの VM ベース分離が主要用途: エージェント特化ではない汎用用途では Kata Containers が適合します

CubeSandbox は初回 OSS 化から間もない段階ですが、リリースペース・ロードマップ・コミュニティ動線から判断する限り、少なくとも 2026 年 7 月時点ではアクティブなプロジェクトです。本記事はドキュメントベースの整理であり、実運用性能や本番投入時の運用課題は各読者の環境で確認する必要があります。詳細な仕様・最新情報は 公式リポジトリ および 公式ドキュメント を参照してください。