AIエージェントがコードを書けるなら、質の悪いコードも書けます。ツールを呼び出せるなら、間違った引数で間違ったツールを呼び出すこともあります。その解決策は、より賢いプロンプトではありません。モデルの出力とそれを実行するマシンの間に、分離境界を設けることです。CubeSandboxは、まさにその境界のために構築されたシステムの一つであり、それが何をするのか、他のアプローチと比較してどうか、エージェントが実際のAPIやデータに触れ始める際にどこに位置づけられるのかを理解する価値があります。
要約
CubeSandboxは、AIエージェントのコードを実行するための、Tencent Cloudが提供するオープンソースのハードウェア隔離型サンドボックスサービスです。各サンドボックスはKVMを介して独自のゲストOSカーネルを取得し、約60msで起動し、メモリオーバーヘッドは5MB未満です。Apache 2.0ライセンスで提供され、E2B SDKとドロップイン互換性があります。
はじめに
エージェントシステムは現在、本番環境でコードを書き、実行しています。コーディングエージェントはPythonスクリプトを生成して実行します。リサーチエージェントはページをスクレイピングし、解析し、その結果を次のステップにパイプします。データエージェントはCSVをロードし、モデルが実行時に決定した変換を実行します。これらのコードは、実行前に人間によってレビューされることはありませんでした。これこそが、エージェントのサンドボックス化が解決する核心的な問題です。信頼できない、モデルが生成した命令を、ホスト、ファイルシステム、認証情報、ネットワークを明け渡すことなく実行する必要があります。
エージェントが自律性を高めるにつれて、この問題はさらに重要になります。SQLクエリを間違えるモデルは煩わしいだけです。`rm -rf`を間違えたり、スクレイピングされたウェブページ内のインジェクトされた命令に従ったりするモデルは、セキュリティインシデントです。サンドボックス化は明確な線引きをします。エージェントは、使い捨ての隔離された環境内で好きなように行動でき、その行動が外部に漏れることはありません。
2つ目の、より静かな問題があります。エージェントはコードを実行するだけでなく、APIやツールも呼び出します。サンドボックス内からエージェントが支払いAPIや内部サービスにアクセスすることを信頼する前に、それらのAPIが正しく動作すること、そしてエージェントが期待通りにそれらを呼び出すことを知る必要があります。そこで、ランタイム隔離と並んでAPIツールがその地位を確立します。Apidogのようなプラットフォームを使用すると、エージェントが呼び出すエンドポイントをモックおよびテストできるため、自律システムがサンドボックス化された実行でそれらを駆動し始める前に、契約を検証できます。エージェントアーキテクチャについてすでに検討している場合は、当社のエージェントAIアーキテクチャに関するガイドが、これらの実行層とツール層がどのように連携するかを説明しています。
この記事の残りの部分では、CubeSandboxとは何か、なぜAIエージェントにサンドボックスが必要なのか、隔離モデルの違い、そしてこれがエージェントが依存するAPIのテストにどのように関連するかを説明します。
CubeSandboxとは？
CubeSandboxは、Tencent Cloudが2026年4月にApache 2.0ライセンスでオープンソース化した、AIエージェントコードを実行するためのセキュリティサンドボックスシステムです。GitHubのタグラインは「AIエージェントのための即時、並行、安全かつ軽量なサンドボックス」と明快に説明しています。これは単なるSDKではなく、ほとんどがRustで書かれた、自分でデプロイできるサンドボックス・アズ・ア・サービススタック全体です。
このアーキテクチャは、多くのクラウドハイパーバイザーで使われているものと同じLinuxカーネル仮想化層であるRustVMMとKVM上に構築されています。プロジェクトのドキュメントと公式発表によると、システムはいくつかのコンポーネントに分割されています。
- CubeAPI：E2BサンドボックスインターフェースをミラーリングするRESTゲートウェイ。
- CubeMaster：ノード間でサンドボックスをスケジューリングするクラスターオーケストレーター。
- CubeHypervisorとCubeShim：各マイクロVMを起動および管理するKVM仮想化層。
- CubeletとCubeProxy：サンドボックスを実行し、ルーティングするノードレベルのエージェント。
- CubeVS：eBPFを活用したネットワーク層で、カーネルレベルでサンドボックス間のネットワーク隔離を強制します。
特筆すべき特徴は、各サンドボックスが専用のゲストOSカーネルを持つことです。これは、ホストカーネルを共有するコンテナとは異なる、より強力な隔離モデルです。Tencentが発表した数値によると、単一同時実行では約60msのコールドスタート（50同時作成下でP95は約90msで平均67ms）、インスタンスあたり5MB未満のメモリオーバーヘッド、そして1つの大規模ホスト上で数千のサンドボックスを実行する能力が報告されています。プレスリリースでは、96vCPUサーバーが2,000以上の同時サンドボックスをサポートしていると述べています。Tencentは、CubeSandboxが自社のインフラストラクチャ内で大規模に稼働しており、MiniMaxが異種環境での大規模なエージェント型強化学習トレーニングにそれを使用していると述べています。
チェックポイント作成やサンドボックス状態の復元のためのイベントレベルのスナップショットロールバックなど、いくつかの高度な機能はまだ開発中であると説明されています。将来の項目はロードマップとして扱い、出荷保証とはせず、現在の状況についてはリポジトリを確認してください。ベンダー自身の数値以外の公開ベンチマーク方法は限られているため、ご自身のワークロードに対してパフォーマンスの主張を検証してください。
公式の詳細については、CubeSandbox GitHubリポジトリと公式ドキュメントサイトが信頼できる情報源です。
なぜAIエージェントにサンドボックスが必要なのか
「セキュリティ」は設計するには漠然としすぎているため、脅威について具体的にすることが役立ちます。チームをサンドボックス化に導く3つの失敗モードがあります。
危険な生成コード。モデルは正しいと信じるコードを生成します。しかし、時にはそうではありません。間違ったディレクトリを削除したり、タイトなループでメモリを使い果たしたり、不適切な場所にファイルを書き込んだりします。これらは悪意のあるものではありません。単に間違っているだけであり、ホストへのアクセス権を持つ間違ったコードは危険です。エージェントには、爆発半径を与えない限り、その概念がありません。
信頼できないツール呼び出し。エージェントは、モデルが実行時に決定した内容に基づいてツールやAPIを呼び出します。ドキュメント、ウェブページ、またはツール応答に埋め込まれたプロンプトインジェクションによってモデルが操作された場合、破壊的なツールを呼び出したり、攻撃者が制御する引数を渡したり、意図しない方法で呼び出しを連鎖させたりする可能性があります。ここでモデルは信頼できるアクターではありません。コンテキストウィンドウに到達するあらゆるテキストの通訳者にすぎません。自律的な呼び出し元では従来のAPIの信頼仮定が崩れる理由について、新しいAPIコンシューマーとしてのAIエージェントに関する記事でさらに詳しく掘り下げています。
データ持ち出し。これは人々が過小評価している問題です。ネットワークアクセスとシークレットへのアクセス権を持つエージェントは、持ち出しチャネルに変換される可能性があります。汚染された命令は、エージェントにAPIキーを保持する環境変数を読み取り、外部エンドポイントにPOSTするように指示します。エグレスフィルタリングと認証情報隔離がなければ、サンドボックスの境界は無意味になります。データは正面玄関から出て行ってしまうからです。これが、CubeSandboxがカーネルレベルの隔離とCubeVSを介したeBPFベースのエグレスフィルタリングを組み合わせる理由です。ネットワークが広く開いている場合、プロセスの隔離だけでは不十分です。
共通するスレッド：エージェントが取り込んだ信頼できないデータによってエージェントの動作が部分的に制御されるため、エージェントが適切に振る舞うと仮定することはできません。サンドボックスを使用すると、モデルが信頼できるかどうかについて推論するのをやめ、状況に関わらず保持される境界について推論を開始できます。これらの動作が本番環境に到達する前に調べる実践的な視点については、APIを呼び出すAIエージェントのテスト方法を参照してください。
エージェントサンドボックスの仕組み：隔離モデル
すべてのサンドボックスが同じ方法で隔離するわけではなく、その違いはセキュリティとパフォーマンスの両方に影響します。エージェントエコシステムで見られる主要な4つのアプローチがあります。
プロセスレベルの隔離。 seccompフィルター、ドロップされた機能、名前空間、cgroupを使用して、制限されたOSプロセスとしてコードを実行します。これは最も軽量で最も弱いオプションです。ホストカーネルを共有するため、カーネルエクスプロイトはホスト侵害を意味します。ほとんど信頼できるコードには問題ありませんが、任意のモデル出力には脆弱です。
コンテナ。 Dockerスタイルのコンテナは名前空間とリソース制限を追加し、運用上も馴染み深いものです。しかし、コンテナは設計上、ホストカーネルを共有します。コンテナ脱出の脆弱性は現実的で繰り返されるバグのクラスであり、「共有カーネルコンテナ内の信頼できないコード」は既知の弱点です。多くのチームは簡単なのでここから始めますが、隔離の限界に達します。
マイクロVM。 マイクロVMは、ハードウェア仮想化（KVM）内で最小限のゲストカーネルを起動します。エージェントのコードは自身のカーネルに対して実行されるため、カーネルレベルのエクスプロイトは使い捨てのVM内に封じ込められ、ホストには及びません。Firecrackerはサーバーレスワークロード向けにこのモデルを普及させ、CubeSandboxはこのカテゴリに属し、RustVMMとKVMを各サンドボックスのゲストカーネルと共に使用しています。歴史的なトレードオフは起動時間でした。マイクロVMはコンテナよりも起動が遅かったのです。現代の実装では、スナップショットとリソースの事前プロビジョニングによってこれを克服しており、CubeSandboxが100ms未満の起動を報告しているのはこのためです。
アプリケーションカーネル。 gVisorは異なる経路をたどります。システムコールをユーザー空間で傍受し、Linuxのようなインターフェース自体を実装するため、ワークロードはホストカーネルと直接通信することはありません。これは完全なVMなしで強力な隔離層を提供しますが、syscall互換性とパフォーマンスにはいくつかのトレードオフがあります。
エージェントにとって重要な側面で、これらのアプローチを比較すると次のようになります。
| アプローチ | 隔離強度 | コールドスタート | オーバーヘッド | カーネル共有 | 例 |
|---|---|---|---|---|---|
| プロセス + seccomp | 低 | 瞬時 | 最小限 | 共有ホストカーネル | 制限されたサブプロセス、nsjail |
| コンテナ | 中 | 約数十ミリ秒 | 低 | 共有ホストカーネル | Docker、containerd |
| マイクロVM | 高 | 約50～150ミリ秒 | 低～中 | 専用ゲストカーネル | CubeSandbox、Firecracker |
| アプリケーションカーネル | 高 | 約数十ミリ秒 | 低～中 | ユーザー空間で傍受 | gVisor |
| ホスト型サンドボックスAPI | 高（マネージド） | 変動 | お客様に代わって管理 | お客様に代わって管理 | E2B、ホスト型サービス |
どれか一つが常に勝者となるわけではありません。適切な選択は、コードをどれだけ信頼するか、コールドスタートをどれだけ速くする必要があるか、KVMを実行できるか、そしてインフラストラクチャを自分で運用したいか、サービスとして利用したいかによって決まります。
CubeSandboxの現状
CubeSandboxの位置付けは具体的です。ハードウェアレベルの隔離により、コンテナのような感覚で高速なコールドスタートを実現し、サービスを借りるのではなく自分で運用する形でデプロイされます。これにより、3つの参照点と直接比較することができます。
コンテナとの比較。コンテナはホストカーネルを共有しますが、CubeSandboxは各サンドボックスに独自のカーネルを提供します。任意のAIエージェント生成コードの場合、これはセキュリティ上の利点となります。コストとしては、KVMを有効にしたx86_64 Linuxホスト（ベアメタルサーバー、ネストされた仮想化をサポートするクラウドVM、またはローカル作業用のWSL 2）が必要です。プラットフォームがKVMを公開できない場合、マイクロVMベースの隔離は利用できず、gVisorのようなユーザー空間アプローチまたはホスト型APIの方が適しているかもしれません。
Firecrackerとの比較。 Firecrackerは、サーバーレス向けのよく知られたマイクロVMであり、それ自体はエージェントサンドボックス製品ではなく、構成要素です。CubeSandboxもKVM/RustVMMベースですが、より上位のスタックで提供されます。オーケストレーター、E2B互換APIゲートウェイ、eBPFネットワーク隔離などを含み、単に組み立てるのではなく、エージェントサンドボックスサービスとしてデプロイします。プリミティブが必要ならFirecracker、エージェント向けのAPIを備えたサンドボックスサービスが必要ならCubeSandboxがその役割を担います。
E2Bおよびホスト型サンドボックスとの比較。 E2Bはマネージドサービスとして隔離されたサンドボックスを提供します。APIを呼び出せば、インフラストラクチャの課題は他社のものになります。CubeSandboxの注目すべき設計上の選択肢は、E2B SDK互換性です。ドキュメントでは、ドロップイン置換として説明されており、`E2B_API_URL`を自己ホスト型Cubeインスタンスに向ければ、既存のコードが引き続き機能します。これにより、実際の決定は「どのサンドボックスを使うか」ではなく、「マネージドサービスか自己ホスト型インフラか」という問いになり、データレジデンシー、規模でのコスト、運用上の所有権が決定要因となります。Tencentの発表によると、OpenAI Python SDKもネイティブでサポートしています。
正直なまとめ：CubeSandboxは、強力な隔離、高速な起動、自己ホスト型、E2B互換性という明確な論文を持つ、エージェントサンドボックス分野の信頼できる新参者です。また、新しく、ほとんどがベンダーによって文書化されているため、独立したベンチマークは少ないです。コミットする前に、自身のワークロードに対してプロトタイプを作成し、コールドスタート、密度、隔離動作を測定してください。
これがエージェントが呼び出すAPIとツールのテストにどうつながるか
ランタイム隔離は「コードが不良だったらどうなるか」という問いに答えます。しかし、「エージェントが呼び出すAPIが不良だったら、あるいはエージェントがそれを誤って呼び出したらどうなるか」という問いには答えません。これらは異なる問題であり、両方をカバーする必要があります。
サンドボックス化された旅行予約エージェントを想像してみてください。コードはCubeSandbox内で安全に実行されます。しかし、エージェントは依然としてフライトAPI、支払いAPI、および内部の旅行日程サービスを呼び出します。これらのいずれかが不正な応答を返した場合、エージェントはループしたり、回復を幻覚したり、下流に誤ったデータを渡したりする可能性があります。間違った冪等性キーで支払いAPIを呼び出した場合、隔離ではあなたを救うことはできません。お金は依然として移動します。サンドボックスはホストをエージェントから保護します。しかし、混乱したエージェントが実際のサービスに実際の呼び出しを行うことから、あなたのシステムを保護するわけではありません。
したがって、実際に機能するワークフローは、2つのレイヤーが連携して動作します。
- モデルが生成したコードやツール呼び出しがホストを傷つけたり、データを持ち出したりしないように、実行を隔離します。これがCubeSandboxのレイヤーです。
- サンドボックス化された実行の前と最中に、エージェントがアクセスできるすべてのAPIとツールの契約を検証します。これがAPIツールレイヤーです。
2番目の層については、動作をテストしている間、エージェントが制御された代役と通信するように依存関係をモックし、その後、実際のEndpointsに対してスキーマ準拠、エラー処理、認証、およびエッジケースをテストします。Apidogを使用すると、確定的なスキーマに準拠した応答を返すモックサーバーを構築し、サンドボックス化されたエージェントをそれに向け、本番環境に触れることなく、エージェントが成功パスと失敗パスの両方にどのように反応するかを観察できます。準備ができたら、同じシナリオをライブAPIに対して実行して、契約が保持されることを確認します。サンドボックステストに関する当社の詳細な説明は、隔離された制御された環境に対してテストする一般的な実践をカバーしており、これはここに直接適用されます。
エージェントは契約のずれを増幅させるため、このペアリングは重要です。APIの応答がおかしい場合、人間はそれに気づきます。エージェントは多くの場合そうではありません。応答を取り込んでそれに基づいて行動します。厳密なAPI契約をモックとテストで実行することで、自律的な呼び出し元が1つの悪い応答を連鎖反応に悪化させるのを防ぎます。エージェントがモデルコンテキストプロトコルを話す場合、Apidogを使用したMCPサーバーのテストは、同じ規律をツール層に拡張します。そして、エージェントコンシューマー向けにAPIを設計している場合、AIエージェント向けAPIの設計は、自律的な呼び出しを予測可能にする契約パターンをカバーしています。
実際のユースケース
隔離と契約のアプローチがその価値を発揮するいくつかのパターン:
コーディングエージェントとコードインタプリタ。モデルは質問に答えたり、データを変換したり、グラフを生成したりするためにコードを書き、実行します。これは典型的なサンドボックスのユースケースであり、E2B互換APIが直接対象とするものです。CubeSandboxのサンドボックスごとのカーネルは、コードが完全に任意であり、実行ごとに変化するため、ここで重要になります。
マルチテナントエージェントプラットフォーム。多くの顧客のエージェントが共有インフラストラクチャでコードを実行する場合、テナント間のコンテナレベルの隔離は危険です。サンドボックスごとのハードウェア隔離は、たとえあるテナントのエージェントが敵対的であっても機能するテナンシー境界を提供します。報告されている密度（ホストあたり数千のサンドボックス）が、1テナントあたり1VMではなく、これを実現可能にしています。
エージェント型強化学習とトレーニングループ。強化学習でエージェントをトレーニングすることは、大量の短命で信頼できないロールアウトを実行することを意味します。Tencentは、MiniMaxが異種環境でまさにこの目的のためにCubeSandboxを使用していることを挙げています。高速なコールドスタートとインスタンスあたりの低いオーバーヘッドは、トレーニング実行が実現可能かどうかの違いです。
ツールを使用するリサーチエージェントとデータエージェント。エージェントは外部コンテンツを取得し、解析し、下流のAPIを呼び出します。取得されたコンテンツは信頼できない（プロンプトインジェクションのリスク）ため、解析と生成されたコードはサンドボックス内に属し、下流のAPIはまずモックに対して実行されるべきです。これは、隔離とAPI契約テストの組み合わせが最も効果を発揮する場面です。
信頼できないプラグインまたは拡張機能の実行。ユーザーがエージェントが実行するツールやコードを提供できる場合、定義上、サードパーティの信頼できないコードを実行することになります。各実行ごとにマイクロVMの境界を設けることは適切な姿勢であり、サーバーレスプラットフォームがFirecrackerを採用したのと同じ理由です。
結論
エージェントが人間のレビューなしにコードを実行し、ツールを呼び出し始めた瞬間から、エージェントのサンドボックス化は選択肢ではなくなりました。CubeSandboxは、この問題の隔離の半分に対する具体的でオープンな答えです。
重要なポイント:
- CubeSandboxは具体的かつ実用的です: Tencent CloudのApache 2.0オープンソースAIエージェント用サンドボックスで、RustVMMとKVM上に構築され、サンドボックスごとにゲストカーネルを備えています。
- 隔離モデルが重要です: サンドボックスごとの専用カーネルは、任意のモデル生成コードに対するコンテナ隔離よりも強力で、報告されているコールドスタート時間は100ミリ秒未満、オーバーヘッドは5MB未満です。
- E2B互換性により移行コストが削減されます: E2Bを使用している場合、ドキュメントに記載されているドロップインパスは、選択を書き換えではなく、マネージドか自己ホスト型かという問題として再定義します。
- ベンダーの数値を出発点として扱ってください: パフォーマンスと密度の主張は主にTencentからのものです。コミットする前に、自身のワークロードに対してベンチマークを行い、どの機能が出荷済みで開発中であるかについてリポジトリを確認してください。
- 隔離は必要不可欠ですが、それだけでは十分ではありません: サンドボックスはホストをエージェントから保護しますが、混乱したエージェントがAPIを呼び出すことからあなたのAPIを保護するわけではありません。
- ランタイム隔離をAPI契約テストと組み合わせる: エージェントが到達できるすべてのエンドポイントをモックしてテストし、単一の悪い応答が連鎖しないようにします。
あなたのエージェントがあなたが所有または依存するAPIを呼び出す場合、隔離層とともに契約層を設定してください。Apidogをダウンロードして、サンドボックス化されたエージェントがアクセスするサービスをモックし、自律システムが本番環境でそれらを駆動する前に、スキーマ、認証、およびエラー動作についてテストしてください。
ボタン