CubeSandboxとは何か：AIエージェント実行環境の課題を解く
2026年4月、Tencent CloudはAIエージェント向けサンドボックス実行環境「CubeSandbox」をApache License 2.0のオープンソースプロジェクトとして公開した。RustVMM/KVMベースのMicroVMで構築されたこのサンドボックスは、単一起動時60ms以下の高速コールドスタートと、1インスタンスあたり5MB以下のメモリ使用量を実現する。Tencent Cloudの本番環境で実証済みのアーキテクチャが、同社OSSとして外部公開された形だ。
AIエージェントが実際のコードを生成・実行するユースケースでは、実行環境の安全性と速度のトレードオフが常に課題になる。従来の解決策には主に3つのパターンがあった。
DockerコンテナはLinuxの名前空間（namespace）で隔離するため、起動は速いが共有カーネルの脆弱性が全コンテナに波及するリスクを持つ。コンテナエスケープ攻撃に対して根本的な耐性がない。
フルVM（KVM/QEMU等）はゲストカーネルを完全に分離でき、セキュリティ面では強固だ。しかし起動に数秒〜十数秒かかり、1インスタンスあたりのメモリオーバーヘッドも数百MBに達するため、高密度な並行実行には不向きだ。
E2BなどのクラウドサンドボックスサービスはSaaSとして手軽に使えるが、自己ホストが難しく利用料が積み上がる。データをサードパーティに預ける構成のため、エンタープライズ用途ではデータガバナンス上の制約も出やすい。
CubeSandboxはこの3者の問題を同時に解決しようとするプロジェクトだ。MicroVM技術でDockerより強固なカーネル分離を実現しながら、RustベースのランタイムチューニングとCopy-on-Write（CoW）メモリ共有でフルVMの起動遅延とメモリ肥大を解消する。さらにE2B SDK互換のREST APIを実装し、既存のAIエージェントコードをURLの変更だけでCubeSandboxに移行できる設計になっている。
GitHubリポジトリは公開から短期間で1,000以上のスターを獲得し、AIエージェントフレームワーク比較2026でも取り上げられ始めている。AIエージェントインフラにおけるセルフホスト型サンドボックスの有力な選択肢として注目が集まっている。
主な機能と技術的特徴
1. MicroVM分離：カーネルレベルのセキュリティ保証
CubeSandboxは各サンドボックスインスタンスに独立したゲストOSカーネルを割り当てる。これによりDockerのような共有カーネルの脆弱性が全サンドボックスに波及するリスクを根本から排除する。RustVMMとKVMを組み合わせたMicroVMは「ハードウェアレベルの仮想化」を提供しつつ、ゲストイメージの最小化とCoWメモリ共有でオーバーヘッドを極限まで圧縮している。
2. 60ms以下の高速コールドスタート
公式ベンチマークデータによると、単一起動時のコールドスタートは60ms。50並列起動時でも平均67ms、P95で90ms、P99で137msを記録している。これはFirecracker（E2Bが採用するMicroVM技術）の公称起動時間（〜150ms）を大幅に下回る数値だ。AIエージェントのリアルタイム応答が求められる用途でも、ユーザー体験を損なわない速度を実現する。
3. 高密度並行実行：数千インスタンス/サーバー
1インスタンスあたりのメモリオーバーヘッドが5MB以下のため、1台のサーバーで数千のサンドボックスを同時実行できる。CoWによるカーネルとメモリページの共有がこの異常な密度を実現するキー技術だ。AI SaaSや教育プラットフォームのような高並列ワークロードで、インフラコストを大幅に削減できる。
4. CubeVS：eBPFネットワーク隔離
CubeVS（Cube Virtual Switch）はeBPF（extended Berkeley Packet Filter）を使ってカーネル内でネットワークを制御するコンポーネントだ。サンドボックス間通信を完全遮断しながら、外部エグレストラフィックに対してはドメイン・IPレンジ単位のきめ細かいフィルタリングポリシーを適用できる。eBPFはカーネルソースを変更せずにカーネル空間で動作するため、パフォーマンスオーバーヘッドがほぼゼロだ。
5. E2B互換REST API
CubeSandboxはE2BのSDKと完全互換のREST APIを実装している。エンドポイントURL一つを変更するだけで既存のE2Bコードがそのまま動作する。PythonとTypeScriptの両SDKに対応しており、E2Bを使っているチームが最小の変更でオンプレミスに移行できる。
6. containerdシム統合（CubeShim）
CubeShimはcontainerd Shim v2 APIを実装しており、CubeSandboxのMicroVMをコンテナランタイムのエコシステムに直接統合する。KubernetesやDockerで管理されているクラスタにCubeSandboxを組み込める設計で、既存のコンテナオーケストレーション基盤を活かした本番運用が可能だ。
7. クラスタオーケストレーション
複数ノードにまたがるCubeSandboxクラスタを管理するオーケストレーターを内蔵しており、シングルノードからマルチノードへのスケールアウトに対応している。リソーススケジューリングとサンドボックスライフサイクル管理をAPIから統一的に制御できる。
クイックスタート：インストールから最初のサンドボックスまで
システム要件の確認
CubeSandboxはKVM（Kernel-based Virtual Machine）を使用するため、KVM対応のx86_64 Linux環境が必要だ。WSL 2（Windows Subsystem for Linux 2）でも動作する。
まずKVMが利用可能かどうかを確認する：
# KVMデバイスの存在確認
ls /dev/kvm && echo "KVM OK" || echo "KVM not available"
# 仮想化サポートのCPUフラグ確認（1以上なら対応）
egrep -c '(vmx|svm)' /proc/cpuinfo
# カーネルモジュールのロード確認
lsmod | grep kvm
クラウド環境ではネスト仮想化（nested virtualization）のサポートが必要になる場合がある。AWS EC2ではbareメタルインスタンス（.metal系）またはネスト仮想化対応インスタンスタイプを使うことを推奨する。
Windows 11 + WSL 2環境では
/dev/kvmが自動的に利用可能になっている場合が多い。ls /dev/kvmが成功すればCubeSandboxをWSL 2上で動かせる。開発環境やデモ用途ではWSL 2が手軽な選択肢だ。
Docker Composeを使ったシングルノード起動
公式リポジトリのQuick Startに従って、シングルノード構成を立ち上げる：
# リポジトリのクローン
git clone https://github.com/TencentCloud/CubeSandbox
cd CubeSandbox
# シングルノード構成でサービス起動
docker compose up -d
# APIサーバーの起動確認
curl http://localhost:5000/health
# => {"status":"ok"}
サービスが正常に起動すると、E2B互換のREST APIがポート5000で待ち受け状態になる。この時点でE2B SDKを使ったコード実行が可能になる。
Pythonから最初のサンドボックスを作る
E2B Python SDKがインストール済みであれば、接続先URLを変えるだけでCubeSandboxに向けることができる：
import os
from e2b_code_interpreter import Sandbox
# E2BのクラウドエンドポイントをCubeSandboxのローカルインスタンスに変更
os.environ["E2B_API_KEY"] = "local-dev-key"
os.environ["E2B_DOMAIN"] = "localhost:5000"
# サンドボックスを作成してPythonコードを実行
with Sandbox() as sbx:
# 基本的なコード実行
execution = sbx.run_code("print('Hello from CubeSandbox MicroVM!')")
print(execution.text)
# => Hello from CubeSandbox MicroVM!
# ゲストOSの情報確認（独立したカーネルが動作していることを確認）
result = sbx.run_code("""
import subprocess
r = subprocess.run(['uname', '-a'], capture_output=True, text=True)
print(r.stdout.strip())
""")
print(result.text)
# => Linux sandbox-xxx 5.x.x ... (ゲストOSのカーネル情報)
# ファイル操作のデモ
sbx.files.write("/workspace/data.txt", "CubeSandboxのファイルシステムテスト")
content = sbx.files.read("/workspace/data.txt")
print(content)
# => CubeSandboxのファイルシステムテスト
E2B SDKのインストールは pip install e2b-code-interpreter、TypeScriptは npm install @e2b/code-interpreter で行う。
Node.js/TypeScriptからの利用例
import { Sandbox } from "@e2b/code-interpreter";
// 環境変数で接続先をCubeSandboxに切り替える
process.env.E2B_DOMAIN = "localhost:5000";
process.env.E2B_API_KEY = "local-dev-key";
async function runCodeInSandbox(code: string): Promise<string> {
const sbx = await Sandbox.create();
try {
const execution = await sbx.runCode(code);
if (execution.error) {
return `Error: ${execution.error.value}`;
}
return execution.text ?? "";
} finally {
// サンドボックスは必ずクリーンアップする
await sbx.kill();
}
}
// AIエージェントが生成したコードを安全実行
const result = await runCodeInSandbox(`
import json
primes = [n for n in range(2, 100) if all(n % i != 0 for i in range(2, n))]
print(json.dumps({"primes": primes, "count": len(primes)}))
`);
console.log(result);
// => {"primes": [2, 3, 5, 7, ...], "count": 25}
デフォルトのQuick Start構成ではAPI認証が無効になっている場合がある。外部からアクセス可能な環境にデプロイする際は、公式ドキュメントの認証設定セクションを必ず確認すること。APIキー認証またはネットワークレベルのアクセス制御を設定する。
MicroVMアーキテクチャと4コンポーネントの設計
CubeSandboxは4つのコアコンポーネントで構成されており、それぞれが明確な役割分担を持つ。
（AIエージェント / E2B SDK）"] -->|"REST API"| GW["REST APIゲートウェイ
（Rust製）"] GW --> Orch["クラスタオーケストレーター"] Orch --> Cubelet1["Cubelet
（ノード1）"] Orch --> Cubelet2["Cubelet
（ノード2）"] Cubelet1 --> Hyp1["CubeHypervisor
KVM MicroVM管理"] Cubelet1 --> VS1["CubeVS
eBPF仮想スイッチ"] Hyp1 --> SB1["Sandbox A
独立カーネル"] Hyp1 --> SB2["Sandbox B
独立カーネル"] SB1 <-->|"CoWメモリ共有"| SB2 VS1 -->|"ネットワーク隔離"| SB1 VS1 -->|"ネットワーク隔離"| SB2 VS1 <-->|"エグレスフィルタ"| Internet["インターネット"] style Client fill:#f5a623,stroke:#e67e22,color:#000 style GW fill:#2980b9,stroke:#1a5276,color:#fff style Orch fill:#16a085,stroke:#0e6655,color:#fff style Hyp1 fill:#8e44ad,stroke:#6c3483,color:#fff style VS1 fill:#27ae60,stroke:#1e8449,color:#fff style SB1 fill:#e74c3c,stroke:#c0392b,color:#fff style SB2 fill:#e74c3c,stroke:#c0392b,color:#fff
CubeHypervisor — KVM MicroVMの管理層
CubeHypervisorはRustVMMとKVMを使ってMicroVMのライフサイクルを管理するコアコンポーネントだ。各サンドボックスは独立したゲストOSカーネルを持つMicroVM上で動作するため、Dockerのような名前空間エスケープのリスクが根本的に存在しない。
MicroVMはフルVMと比較して起動オーバーヘッドを極限まで削減した軽量仮想マシンで、FirecrackerやCloud Hypervisorが代表的な実装だ。CubeSandboxはRustVMMコミュニティの成果物を基盤に、コールドスタート最適化を独自に実施している。
CoW技術によるカーネルとメモリページ共有は密度向上の核心だ。各MicroVMが独自のカーネルを「持つ」といっても、実際には読み取り専用ページをホストと共有しており、書き込みが発生したページのみコピーされる。これにより複数インスタンスのメモリオーバーヘッドが5MB以下に収まる仕組みだ。
CubeShim — containerd統合レイヤー
CubeShimはcontainerd Shim v2 APIを実装し、CubeSandboxのMicroVMをコンテナランタイムとして見せるアダプターだ。KubernetesはCRIランタイムとしてcontainerdを使うため、CubeShimを通じてKubernetes上でMicroVMサンドボックスをPodとして管理できる。既存のKubernetesオーケストレーション基盤をそのまま活かせる点が運用面での強みだ。
REST APIゲートウェイ — Rust製高並行サーバー
外部に公開するREST APIはRustで実装されており、高並行性と低レイテンシを確保する。E2B互換のエンドポイント設計により、既存のツールチェーンがそのまま使える。サンドボックスの作成・実行・停止・ファイル操作などのライフサイクル管理をすべてこのAPIから行う。
CubeSandboxのコアコンポーネントはすべてRustで実装されている。Rustはメモリ安全性をコンパイル時に保証しながら、GCのポーズなしにC/C++に近いパフォーマンスを実現する。サンドボックス管理のような「大量の並行処理＋ゼロダウンタイム要件」のユースケースと親和性が高く、Tencent Cloudの本番環境スケールでの実績がある。
クラスタオーケストレーター — マルチノード管理
クラスタオーケストレーターはAPIゲートウェイからリクエストを受け取り、適切なCubelet（各ノードのエージェント）にディスパッチする。リソーススケジューリング、ノード状態管理、ロードバランシングを担当する。シングルノード構成でも動作するが、スケールアウト時にこのコンポーネントが真価を発揮する。
CubeVS：eBPFで実現するサンドボックス間ネットワーク隔離
AIエージェントがサンドボックス内でコードを実行する場合、最大のセキュリティリスクの一つがネットワーク通信だ。YoloFSが290件のファイル破壊インシデントを分析して示した安全性課題と同様に、ネットワークアクセス制御もAIエージェントのセキュリティには欠かせない要素だ。CubeSandboxはeBPFを使ってこの問題にカーネルレベルで対処する。
eBPFとは何か
eBPF（extended Berkeley Packet Filter）はLinuxカーネル内でユーザー定義のプログラムを安全に実行するためのフレームワークだ。ネットワークパケットの処理、システムコールの監視、パフォーマンストレースなど多様な用途で活用されている。
従来のネットワーク制御（iptables等）はカーネルのnetfilterを経由するためコンテキストスイッチのオーバーヘッドが発生する。eBPFはXDP（eXpress Data Path）やTC（Traffic Control）フックを使ってNICドライバに近い位置でパケットを処理するため、オーバーヘッドがほぼゼロだ。
CubeVSの3つの制御機能
CubeVS（Cube Virtual Switch）はeBPFを活用した仮想スイッチの実装で、次の制御を担当する。
サンドボックス間通信の遮断：あるサンドボックスから別のサンドボックスへのネットワークパケットをeBPFプログラムがドロップする。マルチテナント環境でデータ漏洩・横断攻撃のリスクを排除する。
エグレスフィルタリング：各サンドボックスが外部インターネットにアクセスできるドメインやIPレンジをポリシーで制御できる。「このサンドボックスはGitHubとpypi.orgにのみアクセス許可」といった設定が可能だ。
ゼロオーバーヘッド監視：eBPFのperfイベントやBPF Mapsを使ってネットワークトラフィックを観測できる。不審な通信パターンの検出にも活用できる。
ネットワークポリシーの設定例
CubeSandboxのネットワークポリシーはYAML形式で定義できる（公式ドキュメントの設定例をもとにした模式）：
# cubesandbox-network-policy.yaml
apiVersion: cubesandbox.io/v1
kind: NetworkPolicy
metadata:
name: ai-agent-strict-policy
spec:
# サンドボックス間通信は全面禁止
sandboxIsolation: true
# エグレスポリシー（外向き通信の許可リスト）
egress:
allow:
domains:
- github.com
- api.github.com
- pypi.org
- files.pythonhosted.org
- registry.npmjs.org
deny: "*" # 許可リスト以外はすべて拒否
iptablesのようなnetfilterベースの実装と比較して、eBPFはカーネルの再コンパイルや再起動なしにネットワークポリシーを動的に更新できる。AIエージェントのワークロードは実行タスクによって必要なネットワーク権限が変わるため、この柔軟性が特に有用だ。またeBPFプログラムはVerifierによって安全性が検証されてからカーネルにロードされるため、カーネルクラッシュのリスクも低い。
競合ツールとの比較
CubeSandboxと主要な競合サンドボックスソリューションを、性能・安全性・運用の観点から比較する。
| 項目 | CubeSandbox | E2B | Cloudflare Sandboxes | Docker |
|---|---|---|---|---|
| 隔離レベル | MicroVM（カーネル分離） | MicroVM（Firecracker） | コンテナ + Workers | 名前空間のみ |
| コールドスタート | 60ms | 〜150ms | 〜数百ms | 〜500ms以下 |
| メモリ/インスタンス | <5MB | より高い | N/A | 数MB〜 |
| 並行密度 | 数千/サーバー | 高い | Workers制限内 | 中程度 |
| E2B互換API | ✓ 完全互換 | — | ✗ | ✗ |
| 自己ホスト | ✓ | ✓（有料プラン） | ✗ | ✓ |
| ライセンス | Apache 2.0 | 独自ライセンス | 独自ライセンス | Apache 2.0 |
| eBPFネット隔離 | ✓ CubeVS | ✗ | ✗ | ✗（別途設定） |
| K8s統合 | ✓ CubeShim | 限定的 | ✗ | ✓ |
| 本番実績 | Tencent Cloud | 多数 | Cloudflare | 広範 |
| アーキテクチャ | OSS | SaaS/自己ホスト | SaaS | OSS |
最大の差別化点は「E2B互換 + 自己ホスト可能 + MicroVM分離 + eBPFネット隔離」の4条件を同時に満たしていることだ。E2Bはクラウド前提のためオンプレミス移行にはコストがかかり、Cloudflare Sandboxesの一般提供（GA）はE2B互換性がなくCloudflareインフラへの依存が前提になる。
選択の指針
CubeSandboxが最適な場合：
- E2Bを使っているが自己ホスト・オンプレミスに移行したい
- エンタープライズ環境でデータをサードパーティに預けられない
- 高密度並行実行でインフラコストを最小化したい
- Kubernetes環境にMicroVMサンドボックスを統合したい
E2Bクラウドが最適な場合：
- マネージドサービスで手間をかけたくない
- SLAや公式サポートが必要
- すぐに本番投入したい
Cloudflare Sandboxesが最適な場合：
- Cloudflare Workers/AI Gatewayと組み合わせたい
- グローバルエッジでの低レイテンシ実行が必要
Docker/AIO Sandboxが最適な場合：
- シンプルなコンテナ実行で十分で、完全なカーネル分離が不要
- AIO Sandboxのように単一Dockerコンテナに全機能をまとめたい
実践的な活用シナリオ3選
シナリオ1：Claude APIと組み合わせたAIコーディングエージェント
LLMが生成したコードをCubeSandboxで隔離実行するパターンは、AIエージェント開発の基本構成だ。「コードの生成（LLM）と実行（CubeSandbox）を分離」することで、LLMが予期しないコードを生成しても被害がサンドボックス内に留まる：
import os
import anthropic
from e2b_code_interpreter import Sandbox
os.environ["E2B_DOMAIN"] = "http://your-cubesandbox-host:5000"
os.environ["E2B_API_KEY"] = "your-api-key"
client = anthropic.Anthropic()
def execute_ai_generated_code(user_request: str) -> dict:
"""Claude APIでコードを生成し、CubeSandboxで安全実行する"""
# Claude にPythonコードを生成させる
message = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{
"role": "user",
"content": (
f"以下のタスクを実行するPythonコードのみを書いてください。"
f"説明不要、コードだけ。\nタスク: {user_request}"
)
}]
)
generated_code = message.content[0].text.strip()
# コードブロックのマークダウン記法を除去
if generated_code.startswith("```"):
lines = generated_code.split("\n")
generated_code = "\n".join(lines[1:-1])
# CubeSandboxで安全実行（60ms以下で起動）
with Sandbox() as sbx:
execution = sbx.run_code(generated_code)
return {
"code": generated_code,
"output": execution.text,
"error": execution.error.value if execution.error else None,
}
# 使用例
result = execute_ai_generated_code("1から100の素数を列挙し、合計を計算する")
print(f"出力: {result['output']}")
# => 出力: 素数: [2, 3, 5, ...97] 合計: 1060
シナリオ2：高密度データ処理パイプラインの並列実行
CubeSandboxの低メモリオーバーヘッドを活かして、多数のデータ処理ジョブを並列実行できる。1台のサーバーで数百〜数千のジョブを同時に走らせることが可能だ：
import asyncio
import os
from e2b_code_interpreter import AsyncSandbox
os.environ["E2B_DOMAIN"] = "http://your-cubesandbox-host:5000"
async def process_chunk(chunk_id: int, data: list) -> dict:
"""1チャンクをCubeSandboxで独立処理する"""
async with await AsyncSandbox.create() as sbx:
code = f"""
import json, statistics
data = {data}
result = {{
"chunk_id": {chunk_id},
"count": len(data),
"mean": round(statistics.mean(data), 2),
"stdev": round(statistics.stdev(data), 2) if len(data) > 1 else 0,
}}
print(json.dumps(result))
"""
execution = await sbx.run_code(code)
return {"chunk_id": chunk_id, "result": execution.text}
async def parallel_pipeline(dataset: list, chunk_size: int = 100):
"""データセットをチャンクに分割して並列処理"""
chunks = [
dataset[i:i + chunk_size]
for i in range(0, len(dataset), chunk_size)
]
# 全チャンクを並列実行（60ms起動 × N チャンク）
tasks = [
process_chunk(idx, chunk)
for idx, chunk in enumerate(chunks)
]
results = await asyncio.gather(*tasks)
print(f"処理完了: {len(results)} チャンク")
for r in results[:3]: # 最初の3件を表示
print(r)
import random
sample_data = [random.gauss(50, 10) for _ in range(1000)]
asyncio.run(parallel_pipeline(sample_data, chunk_size=200))
このパターンは機械学習のデータ前処理、並列テスト実行、大規模ログ解析などに応用できる。各ジョブが独立したMicroVMで動作するため、あるジョブがクラッシュしても他のジョブに影響しない。
シナリオ3：セキュアなオンラインコーディング採点システム
プログラミング教育プラットフォームや採用コーディングテストでは、受験者が提出したコードを安全に実行して採点する必要がある。CubeSandboxのMicroVM分離と高密度並行実行はこのユースケースに最適だ：
#!/bin/bash
# 提出コードをCubeSandboxで採点するスクリプト
SANDBOX_HOST="http://cubesandbox-judge:5000"
SUBMISSION_FILE="$1"
TEST_CASES_FILE="$2"
python3 << EOF
import os, json
from e2b_code_interpreter import Sandbox
os.environ["E2B_DOMAIN"] = "${SANDBOX_HOST}"
os.environ["E2B_API_KEY"] = "judge-system-key"
submission_code = open("${SUBMISSION_FILE}").read()
test_cases = json.load(open("${TEST_CASES_FILE}"))
passed = 0
total = len(test_cases)
with Sandbox() as sbx:
# 提出コードをサンドボックスにデプロイ
sbx.files.write("/workspace/solution.py", submission_code)
for i, tc in enumerate(test_cases):
# 各テストケースを実行
runner = f"""
import sys
sys.stdin = open('/dev/stdin', 'r')
exec(open('/workspace/solution.py').read())
"""
result = sbx.run_code(
f"echo '{tc['input']}' | python /workspace/solution.py",
language="bash"
)
output = result.text.strip()
expected = tc["expected"].strip()
if output == expected:
passed += 1
print(f"テスト{i+1}: PASS")
else:
print(f"テスト{i+1}: FAIL (期待値: {expected}, 実際: {output})")
print(f"\n結果: {passed}/{total} テストケース通過")
print(f"スコア: {int(passed/total*100)}点")
EOF
採点用サンドボックスではCubeVSのエグレスフィルタリングを使い、外部ネットワークへのアクセスを完全に遮断することを推奨する。不正なネットワーク通信によるカンニングや、悪意あるコードによる外部サーバーへのデータ送信を防げる。
まとめ
CubeSandboxはTencent CloudがApache 2.0ライセンスでOSSとして公開したMicroVMベースのAIエージェント実行環境で、60ms以下の起動速度・5MB以下のメモリ使用量・E2B互換API・eBPFネットワーク隔離を同時に実現している。
向いているユースケース：
- E2Bクラウドからオンプレミス・プライベートクラウドへの移行（環境変数1つで切り替え可能）
- AIコーディングエージェントの安全なコード実行バックエンド（LLM生成コードの隔離実行）
- 高密度マルチテナントサンドボックス基盤（AI SaaS・教育プラットフォーム等）
- KubernetesクラスタへのMicroVM統合（CubeShim経由で既存K8sに組み込み）
現時点での制約と注意点：
- x86_64 Linux/KVM環境が必須（ARM対応は現時点では未確認）
- クラウドVM環境ではネスト仮想化の有効化が必要（プロバイダーによって制限あり）
- v0.1.0公開直後のため、本番運用は公式ドキュメントとGitHub issuesの最新情報を追いながら行うことを推奨する
- E2B互換性については主要APIに対応しているが、E2B固有のクラウド機能は別途検討が必要
AIエージェントの自律実行が増えるにつれ「コードを実行できるが安全に隔離された環境」の需要は急増している。Cloudflare SandboxesのGAに続き、CubeSandboxはその選択肢をさらに広げるプロジェクトだ。Tencent Cloudの本番実績に裏打ちされたアーキテクチャが、オープンソースとして利用できるようになった意義は大きい。
