プロダクションエージェント向けCubeSandbox対E2B比較

私はDoraです。最近、本番環境でツールコールを行うエージェントを動かしていました。オーケストレーターは問題なし。LLMも問題なし。ボトルネックはサンドボックス層でした――エージェントが生成されたコードのスニペットを実行するたびに、コールドスタートで200msを消費し、時にはそれ以上、時にはキューが混雑することもありました。セッションあたり約40回のツールコールで、壁時計時間のかなりの部分が積み上がります。

そこで代替手段を調べ始めました。今みんなが比較しているのはCubeSandbox vs E2Bです。この記事は、両プロジェクトを2週間かけて調べ、一方をデプロイし、もう一方はデプロイできなかった（後述します）後に分かったことをまとめたものです。

最初に簡単な免責事項：どちらのプロジェクトとも商業的な関係はありません。両方オープンソースです。以下の比較はホスティングvs自己ホスティングのトレードオフであり、「良い側／悪い側」という話ではありません。

CubeSandbox vs E2B 概要

両プロジェクトはほぼ同じ方法で同じ問題を解決します：マイクロVMを起動し、信頼できないコードを実行し、終了させる。両方とも同程度のパフォーマンス数値を公表しています。実際の違いはプロダクトの形式です。

CubeSandboxは、Tencent Cloudが2026年4月にApache 2.0ライセンスでリリースしたオープンソースのサンドボックス・アズ・ア・サービス・スタックです。RustVMMとKVM上に構築されています。リポジトリに記載されている主な数値：60ms未満のコールドスタート、サンドボックルあたり約5MBのメモリ、ネイティブE2B SDK互換性（URL環境変数を一つ変えるだけ）。完全な自己ホスト可能なスタックとして配布されており、単なるライブラリではありません。

E2Bもオープンソース（同じくApache 2.0）で、Firecrackerマイクロ仮想マシン上に構築されています。2023年設立。事前ウォームアップされたスナップショットプールによるサンドボックスの初期化時間は約150〜200ms。Terraformスクリプトによるセルフホスティングもありますはいますが、主な配布形態はマネージドクラウドです――Hobbyプラン（無料、$100クレジット）、Proプラン（$150/月+使用量）、Enterprise（BYOC、オンプレ）。セルフホストユーザーはユーザーベースの少数派であり、ホスティングがデフォルトのストーリーです。

つまり、本当の軸は「どのサンドボックスが優れているか」ではありません。それは：

機能	CubeSandbox	E2B
ライセンス	Apache 2.0	Apache 2.0
主な形式	自己ホスト	ホスティングSaaS（自己ホスト可）
基盤VMM	RustVMM + KVM	Firecracker（KVM）
公表コールドスタート	`<60ms`	~150–200ms
サンドボックスあたりメモリ	~5MB	~5MB
SDK互換性	E2B SDKのドロップイン	ネイティブE2B SDK
GPUサポート	KVM有効なx86_64 Linuxが必要；アップストリームにネイティブパススルーなし	同じFirecracker GPU制約
運用負担	クラスターを自分で運用	E2BがクラスターをRunします（マネージド）

上記の数値は各プロジェクトの独自リポジトリおよびリリースノートから引用したものであり、私が実行したベンチマークではありません。ベンダー公表値として扱ってください――方向性の参考にはなりますが、自身のテストの代わりにはなりません。

ホスティングvs自己ホスティングのトレードオフ

これが実際の判断であり、ほとんど技術的な問題ではありません。

E2Bのホスティングを選ぶということは、マイクロVMカーネル、スナップショットプール、KVMホスト、オーケストレーターのフェイルオーバーについて考えることをやめることを意味します。コスト最適化についても考えなくなります。料金は決まっているからです。私が所属していたチームは2週間E2B Proを試しました――統合には実際に約1時間かかり、SDKはクリーンで、節約されたエンジニアリング時間は本物です。

CubeSandboxで自己ホスティングするということは、自分でサーバーを所有することを意味します。コストは「使用量コーブがどうなるか」ではなく「基盤となるサーバーのコストはいくらか」になります。データがセキュリティ境界を越えないため、コンプライアンスも容易になります。しかし、オンコールローテーション、カーネルアップデート、eBPFポリシーのチューニングも自分の責任です。CubeSandboxはシングルノードとクラスターのセットアップ用にワンクリックデプロイを提供していますが、「ワンクリックデプロイ」と「プロダクション対応クラスター」は同じ意味ではありません。

数日間ここで立ち止まりました。答えは本当にチームの形に依存するからです。来四半期にエージェントをリリースする4人のスタートアップは、おそらく独自のマイクロVMフリートを運用すべきではありません。インフラエンジニアとコンプライアンス制約を持つチームはおそらく運用すべきです。

互換性と移行の問題

CubeSandboxのE2B互換性の話は、CubeSandboxリリースで最も興味深い技術的主張です。彼らのドキュメントによると、既存のE2Bベースのエージェントは単一の環境変数を変更するだけで、コードを変更せずに自己ホスト型CubeSandboxクラスターにトラフィックをルーティングできます。私は個人的に本番E2Bのワークロードを移行したわけではないので、今のところこの主張を信頼するしかありませんが、各側が受け入れるSDKコールを読めば検証可能です。サーフェスエリアは小さいです。両方とも同じSandboxライフサイクルを話します：作成、コマンド実行、コード実行、終了。

ここで有用になるのは：CubeSandboxは本質的にE2B SDKのブリング・ユア・オウン・インフラストラクチャバックエンドだということです。E2Bのホスティングクラウドで開発し、使用量が正当化されたら独自クラスターに再指定できます。ロックイン引数は両側で弱くなります――これはカテゴリーにとって健全だと思います。

CubeSandboxが勝る点

コントロール、コスト構造、インフラストラクチャの所有権

マネージドサンドボックスの料金が月額請求書に出始めるほどのボリュームを持つエージェントチームにとって、CubeSandboxはより正直な選択肢です。すでに理解しているハードウェアにお金を払っています。eBPF（CubeVS）によるエグレスフィルタリングはカーネルレベルで設定可能です。データ居住ルールが「これはVPCを出てはならない」と言っている場合、自己ホストサンドボックスとは30秒の会話で済み、マネージドサンドボックスとははるかに長い会話になります。

あまり言われていないこと：自己ホスト型エージェントランタイムは無料ランチではありません。実行あたりの限界コストは下がりますが、固定費は上がります。損益分岐点は各チームの使用量曲線に固有です。決める前に計算してください。「月に$300節約できるが、週2時間の運用作業が増える」という答えが出るなら、それは勝ちではありません。

チームがテストすべきパフォーマンスと密度の主張

CubeSandboxは60ms未満のコールドスタートを公表しており、HPCwireを通じたTencent Cloudのリリースノートでは”業界平均（150ms）の3分の1”と説明されています。彼らはまた、単一の物理マシンで2,000以上のサンドボックスを主張しています。これらの数値は合成ベンチマークではなく、Tencent Cloud内の本番ワークロードから来ています――合成より良いですが、それでも彼らのワークロードであって、あなたのものではありません。

見出しを信じる前にテストすること：

実際のスナップショットサイズでのコールドスタート（5GBのテンプレートは200MBのものとは異なる動作をします）
平均だけでなくp99での同時実行動作――CubeSandboxは50同時接続で67msの平均応答時間を公表していますが、これは励みになりますが、p99とは異なります
特定の依存関係がRustVMMの削減されたカーネルで問題なく動作するかどうか

ここで私のデータは終わります。KVM対応の単一VMにCubeSandboxをデプロイし、午後半分でサンドボックスを提供できる状態にしました。リリースの密度数値でのストレステストはしていません。プロジェクトが公開されてから3週間で行ったと言う人は、おそらく誇張しています。

E2Bがまだ勝る点

CubeSandbox vs E2Bの図のもう半分：インフラについて考えたくないなら、E2Bが勝ちます。その文は軽視しているように聞こえますが、実際の結論です。

具体的には：

ホスティングE2B SDKはより成熟しています。クックブックの例が多く、LangChain/LlamaIndexとの統合が多く、実績があります。
Manus、Perplexityのコード分析、Hugging FaceのOpen R1――スケールでの本番リファレンスが存在します。CubeSandboxにはTencent Cloud内の本番リファレンスがあり、それは本物ですが、外部のケーススタディはまだ書かれている最中です。
E2BのドキュメントはDockerfileからのテンプレート、デスクトップサンドボックス、ファイル永続化、24時間セッションライフタイムをすぐに使える形でカバーしています。CubeSandboxはよりスパルタ的です――READMEと例はコアライフサイクルをカバーしていますが、ロングテールはカバーしていません。
Firecracker自体は既知の存在です。AWS LambdaはFirecracker上で動いています。Firecrackerプロジェクトは2018年から本番環境で稼働しています。CubeSandboxのRustVMMベースのスタックは、Tencent内でしばらく動作していたとしても、公眼ではより新しいものです。

来四半期にv1エージェントプロダクトをリリースしていてインフラ担当者がいない場合、E2Bのホスティングプランは摩擦が少ないパスです。サンドボックスクラスターと格闘しない時間は、エージェント自体に費やす時間です。多くのチームにとって、それは月$150の価値があります。

エージェントチームのための意思決定フレームワーク

2週間これを調べた後、私が実際に使うフレームワークです。これは私が見つけた最も有用なAIエージェントサンドボックス比較のショートカットの一つです：

月あたり約50k サンドボックスホール未満、コンプライアンス制約なし、インフラチームなし → E2Bホスティング。読むのをやめてください。
それ以上のボリューム、または厳格なデータ居住要件、またはKubernetes/マイクロVMをすでに運用している → CubeSandbox自己ホスト。経済学が逆転し、運用する筋力があります。
その中間 → E2Bホスティングから始めてください。SDKで構築してください。料金が痛くなり始めるかコンプライアンスが質問し始めたら、SDK互換性により移行はURL一つの変更で済みます。その選択肢性がこの比較全体で最も過小評価されている特性です。
サンドボックス内のエージェント推論のためにGPUパススルーが必要な場合 → どちらも良くありません。アップストリームのFirecrackerはネイティブにGPUパススルーをサポートしておらず、CubeSandboxも同様の制約を持っています。そのワークロードにはgVisorまたはDaytonaを検討してください。

私が抵抗するフレーミング：「CubeSandboxの方が優れた技術だから勝つ」。マイクロVMサンドボックスの選択はプロダクト形式の選択です。技術は公表スペックでほぼ同等です。日常のコストは運用面にあります。

よくある質問

これらはCubeSandbox vs E2B評価を実施中にチームメートから繰り返し受けた質問です。

CubeSandboxはE2Bのドロップイン置換ですか？

E2B SDKのサーフェスについては、はい――設計上そうです。プロジェクトは環境変数を変えるだけのE2B互換ランタイムとして自らを売り込んでいます。コアサンドボックスライフサイクルを超えた機能（Dockerfileからのテンプレート、デスクトップサンドボックス、ホスティング観測可能性）については、答えは「まだ」です。

自己ホスティングは実際にどれだけの作業を追加しますか？

KVM対応ホスト（またはフリート）、カーネル/イメージ管理、モニタリング、スナップショットプールのチューニング、ネットワークエグレスポリシー、オンコール。Tencent Cloudのリリースではシングルノードとクラスターのセットアップ向けに「ワンクリックデプロイ」と説明していますが、それをプロダクショングレードのクラスターと同等と見なすのは楽観的です。1〜2週間のセットアップと、誰かの注意の定期的な小さな割合を計画してください。

どのワークロードがマイクロVMサンドボックスから最も恩恵を受けますか？

スケールで信頼できない入力に対してモデル生成コードを実行するもの全て。プレーンDockerの共有カーネルリスクは、コンテナに対する標準的な反論です――全ての主要エージェントプラットフォームがその理由で共有カーネル分離から離れています。エージェントが信頼された固定スクリプトの許可リストからのサンドボックスコードのみを実行する場合、マイクロVMは必要ないかもしれません。

チームが最初にベンチマークすべきものは何ですか？

この順序で3つ：実際のテンプレートサイズでのp99コールドスタート；ハードウェアのドル当たりサンドボックス密度（自己ホスト向け）または請求書のドル当たり（ホスティング向け）；バースト負荷での障害モード。見出し数値――60ms未満 vs 約150ms――は本物ですが、ベンダーに有利な条件下での平均値を記述しています。あなたのワークロードはどちらのベンダーとも一致しないでしょう。それがそもそもベンチマークを行う唯一の理由です。

まとめ

CubeSandbox vs E2Bの議論は本物ですが、少し誤ったフレームです。「どのサンドボックスが技術的に優れているか」ではありません。どちらもハードウェアレベルの分離を使用し、どちらも信頼できるパフォーマンス数値を公表し、どちらもApache 2.0で、どちらも同じSDKを話します。判断は：インフラを誰かに運用してもらいたいか、自分で運用したいか、です。

それはエンジニアリングの問題ではなく、プロダクトの問題です。そして、ほとんどのチームへの正直な答えは「ホスティングから始め、移行を安くしておく」です。両プロジェクト間のSDK互換性がこのリリース全体で最も有用なものです――エージェントインフラにおける全員のロックイン税がより小さくなったことを意味するからです。

CubeSandboxを実際の負荷下で実行したら、続報をお知らせします。両プロジェクトとも更新が速いです――この比較は基盤となる技術ほど長持ちしないでしょう。

前の記事：