AIエージェントが動的にコードを生成して実行する場面が増えるにつれ、そのコードをどこで・どう動かすかという問題が浮上している。CubeSandboxはTencent Cloudがオープンソースで公開したサンドボックス基盤で、コールドスタートを60ms以下に抑えながらハードウェアレベルの隔離を実現する。インフラ設計の観点から見ると、これは単なる「コンテナの代替」ではなく、AIワークロード特有のリスクと性能要件に応えるための新しいレイヤーとなる。
なぜDockerだけでは足りないのか
Dockerコンテナはプロセス単位の隔離（cgroup・namespaceを使ったLinuxカーネルの機能）を提供する。しかし、ホストOSと同じカーネルを共有するため、カーネルの脆弱性を突いた「コンテナエスケープ」攻撃のリスクが残る。AIエージェントが生成したコードは事前に内容を精査できないため、このリスクが特に顕在化しやすい。
たとえば、コーディングエージェントがユーザー入力を受けてPythonスクリプトをその場で生成・実行するケースを考える。スクリプトの中に意図しない`os.system`の呼び出しや、ホストのファイルシステムへのアクセスが含まれていた場合、Dockerの隔離だけでは防ぎきれない攻撃経路が存在する。
CubeSandboxはこの問題をKVM（Kernel-based Virtual Machine）とRustVMMを組み合わせて解決する。KVMはLinuxカーネルに組み込まれたハイパーバイザ機能で、各サンドボックスに専用のゲストOSカーネルを割り当てる。ホストカーネルと完全に分離されるため、エスケープの経路を物理レベルで断てる。
60ms・5MBという数字の意味
KVMを使った従来のVMは起動に数秒かかる。AIエージェントがコードを「書いてすぐ実行する」フローにこの遅延が入ると、ユーザー体験はもちろん、SLO（サービスレベル目標、サービスの品質を数値で定めた指標）の設計にも影響が出る。CubeSandboxのコールドスタートは60ms以下に抑えられており、これはFirecracker（AWSのマイクロVM、Lambdaの実行基盤として使われている）と同等の水準を目指した設計だと見て取れる。
メモリ消費量が1インスタンスあたり5MB以下という点も、インフラ設計上の自由度を広げる。一般的なコンテナランタイムでも起動時に数十MBを消費するケースがある中で、この数値は1台のサーバー上に数千インスタンスを同時に立ち上げられることを意味する。バースト的にエージェントのタスクが集中するワークロードでも、ノード数を増やさずにスケールアウトできる可能性がある。
インフラ設計と運用への組み込み方
CubeSandboxのリポジトリにはTerraformスクリプトが含まれており、クラウドサーバー上へのクラスタ展開を自動化できる。IaC（Infrastructure as Code、インフラ構成をコードで管理する手法）で展開できることは、本番環境への導入ハードルを下げると同時に、構成のバージョン管理・レビューを可能にする。
# CubeSandboxのTerraformによるクラスタ展開イメージ
terraform init
terraform apply -var="node_count=5" -var="region=ap-northeast-1"オブザーバビリティ（システムの内部状態を外部から観測できる性質）の設計では、各サンドボックスのライフサイクルをどう計測するかが課題になる。コールドスタートのレイテンシ、サンドボックス生成レート、メモリ使用量の推移をPrometheus等でスクレイピングできる構成にしておくと、SLOの達成状況を定量的に把握しやすくなる。障害発生時に「どのサンドボックスが異常終了したか」「ホストへの影響はなかったか」を追跡できるログ設計も、運用フェーズでは欠かせない。
コスト最適化の観点では、E2B（クラウド型サンドボックスSDK、AIコーディングツール向けに広く使われている）との互換性が注目に値する。CubeSandboxはE2BのAPIと互換性を持つため、環境変数を1つ変えるだけでオンプレミスやセルフホストのクラウドに移行できる。従量課金のSaaS型サンドボックスから自社管理基盤に移すことで、コストを大幅に削減できるケースも考えられる。
導入前に確認すべき前提条件
KVMを使うためには、ホストサーバーのCPUがハードウェア仮想化（Intel VT-xまたはAMD-V）をサポートしている必要がある。クラウド環境では「ネストされた仮想化（Nested Virtualization）」が有効になっているインスタンスタイプを選ぶ必要があり、AWS EC2ならベアメタルインスタンスやNested Virt対応のインスタンスが対象になる。
Rustで実装されている点は、メモリ安全性（所有権システムによりバッファオーバーフローなどのメモリ破壊バグをコンパイル時に排除する仕組み）の面でも意味がある。サンドボックス基盤自体の脆弱性リスクを下げる設計思想と見られる。
整理すると、CubeSandboxをインフラとして採用する際に確認すべき点は次のとおりです。
- ホストサーバーでKVM・ネスト仮想化が使えるか（CPU・ハイパーバイザ・クラウドプランの確認）
- サンドボックスごとのコールドスタートレイテンシをSLOのどの指標に組み込むか
- Prometheusなどでサンドボックスのライフサイクルをスクレイピングできる設計になっているか
- E2B等の既存サービスと比較したセルフホストのコスト試算
AIエージェント基盤のセキュリティ設計は、コードレビューやWAFだけでは対処しきれない領域に踏み込んでいる。実行時の隔離をインフラのレイヤーで保証するアプローチが、今後のSRE・プラットフォーム設計の標準的な要件になっていく方向は明確だ。