AI生成コードを実行するプロダクションアプリケーションには、プロセスレベルの分離を強制し、並行セッションをサポートし、プログラム可能なライフサイクルAPIを提供し、可観測性のあるログとリソースメトリクスを提供し、パッケージとネットワークポリシーを強制し、アプリケーションバックエンドとクリーンに統合するサンドボックスが必要です。これらの各側面を体系的に評価せずにサンドボックスを選択することは、チームがローンチ後に問題に直面する最も一般的な方法です。ステージングでは安全に見えたワークロードが、実際のトラフィックの下で失敗したり、テナント間で状態を漏洩したり、アプリが許可するつもりのなかったコードを静かに実行したりします。
このガイドは要件チェックリストです。各分離レベルで何を検証すべきか、プロダクションライフサイクルAPIが何を公開する必要があるか、可観測性とリソース制御がどのようにあるべきか、そしてバックエンド統合パターンが設計の成否を分けるポイントをカバーしています。マネージドサンドボックスを評価している場合でも、独自に構築している場合でも、これらは出荷前に答える価値のある質問です。
サンドボックスの分離：プロセス、コンテナ、MicroVM
分離はスペクトルであり、各レベルはパフォーマンス、移植性、そして生成コードに対してどの程度の信頼を拡張するかについて異なるトレードオフをもたらします。
プロセスレベルの分離 は、OSプリミティブ（名前空間、cgroup、seccomp、AppArmorまたはSELinuxプロファイル）を使用して、プロセスがアクセスできるものを制限します。高速で、別個のVMカーネルを必要としませんが、すべてのプロセスはホストカーネルを共有します。カーネルの脆弱性や、seccompフィルタをすり抜ける特権システムコールは、同じホスト上の他のワークロードに影響を与える可能性があります。プロセス分離は、低リスク、短命、信頼されたコードパスには合理的な出発点ですが、システムコール、サブプロセスの生成、パッケージインストールを試みる可能性のある信頼できないAI生成コードにとっては薄い境界です。
このレベルで確認すべきこと：
- どのシステムコールがブロックされているか、未知のシステムコールが試行された場合のデフォルトポリシーは何か？
- 名前空間はタスクごと、テナントごと、またはジョブ間で共有されているか？
- cgroup制限はタスクレベルで強制されているか、ホストレベルでのみか？
- サンドボックスは終了時にすべてのプロセス、一時ファイル、ソケット、共有メモリをクリーンアップするか？
コンテナレベルの分離 は、ファイルシステムとネットワーク名前空間の境界を追加し、イメージ管理を反復可能にします。コンテナはフルVMよりも起動が速く、構成が容易で、オーケストレーションレイヤーで広くサポートされています。トレードオフは、コンテナが依然としてホストカーネルを共有すること、そしてコンテナの境界は基礎となるランタイム設定と同じくらいの強度しかないことです。特権コンテナ、広範なケーパビリティセット、マウントされたホストソケット、ホストネットワークモードはすべて、実効的な境界をほぼ無効にします。
このレベルで確認すべきこと：
- コンテナイメージは最小限で、ワークロードが実際に必要とするランタイムとツールのみを含んでいるか？
- 機能は必要な最小限のセットに削減されているか？
- コンテナはルートレスか、それともrootが必要か、その場合の制御はどうなっているか？
- ホストPID名前空間、ホストネットワーク、Dockerソケットは明示的に除外されているか？
- マウントされたボリュームは明示的に定義されたパスに限定されており、ルートファイルシステムは可能な限り読み取り専用になっているか？
MicroVM分離 は、各ワークロードを軽量仮想マシン内に配置します。独自のゲストカーネル、仮想デバイス、ゲストとホストの間にKVMバックアップの境界を持ちます。Firecrackerなどのテクノロジーは、攻撃対象領域を減らすために最小限のデバイスモデルを使用しつつ、インタラクティブな使用に十分な起動速度を維持します。MicroVMの境界は、ゲスト内のカーネルエクスプロイトが自動的にホストや他のゲストに影響を与えないことを意味します。
このレベルで確認すべきこと：
- 各エージェント実行、各テナント、または各並行セッションは個別のMicroVMを取得するか？
- API呼び出しから実行準備完了までの起動レイテンシはどのくらいか、またそれはウォームプール、スナップショット、コールドブートのいずれから測定されるか？
- ゲストイメージはバージョン管理され、含まれるランタイムとツールが監査され、定期的なスケジュールで更新されているか？
- ゲストカーネルがパニックを起こしたり応答しなくなった場合、ホストレベルでは何が起こるか？
実際の判断は脅威モデルに依存します。MicroVM分離は、信頼できないAI生成コードに対して一般的に利用可能な最も強力な境界ですが、ファイルシステムポリシー、エグレス制御、パッケージガバナンス、またはシークレット処理を置き換えるものではありません。これらの制御は、選択した分離レイヤーの上に配置する必要があります。
並行サンドボックスセッションの管理
同時に複数のユーザーに対してコードを生成するプロダクションアプリケーションには、並行性を後付けではなく第一級の関心事として扱うサンドボックスが必要です。
重要な質問は次のとおりです。
セッションごとの分離：50のセッションが同時に実行されている場合、各セッションは独自の分離されたファイルシステム、プロセスツリー、ネットワーク名前空間、および資格情報スコープを持っていますか？セッション間の状態漏洩は、マルチテナントサンドボックスアプリケーションにおいて最も有害な障害モードの1つであり、セッションが順次実行されるテストでは見えないことがよくあります。
セッション制限とバックプレッシャー：サンドボックスは、並行性制限を明確なAPI契約として表面化しますか？500のリクエストが到着し、プラットフォームが100の並行セッションをサポートしている場合、APIは構造化されたエラーを返しますか、リクエストをキューに入れますか、それとも静かに劣化しますか？プロダクションアプリケーションは、バックプレッシャー、キュー管理、ユーザー向けフィードバックを実装するためにそのシグナルを必要とします。
負荷時のリソース公平性：1つのセッションが異常に高いCPUまたはメモリを消費した場合、他のセッションはセッションごとのリソース制限によって保護されますか、それとも1つのノイズの多いワークロードがプール全体を劣化させる可能性がありますか？
ウォームプールとセッション起動レイテンシ：インタラクティブなコーディング機能には、サブ秒のセッション開始時間が必要です。これには通常、オンデマンドで起動するのではなく、すぐに要求できる事前初期化された環境のプールが必要です。プラットフォームがウォームプールの可用性と、さまざまな並行性レベルで期待される起動レイテンシを文書化しているかどうかを確認してください。
セッション再利用と新しい環境：一部のアプリケーションは、複数のエージェントターンにわたって長期実行セッションを再利用することでメリットを得ますが、他のアプリケーションはリクエストごとにクリーンな環境を必要とします。両方のパターンがサポートされていること、およびセッションの再利用が以前の会話からの古い状態を持ち越さないことを確認してください。
ライフサイクルAPI：作成、実行、終了
ライフサイクルAPIは、アプリケーションとサンドボックスランタイムの間のインターフェースです。プロダクショングレードのAPIは、最低限以下のものを公開する必要があります。
作成：新しいサンドボックスセッションを初期化します。オプションでテンプレートまたはスナップショットから、指定されたリソース制限、環境変数、マウントされたボリュームを使用します。応答には、セッションIDと準備完了シグナルが含まれている必要があります。単なる確認応答ではありません。
実行：実行するコードまたはコマンドを送信します。これは、実行IDを返す非同期呼び出しである必要があります。APIは、ワーキングディレクトリ、呼び出しの環境オーバーライド、タイムアウトを指定することをサポートする必要があります。
出力のストリーミング：実行完了後の最終結果としてだけでなく、ストリームとして標準出力と標準エラー出力を取得します。ストリーミングは、長時間実行ジョブ、多くの秒数を要するエージェントステップ、およびユーザーに段階的な進捗を示すUXにとって重要です。
終了：実行中の実行を完了前に終了します。サンドボックスは、親プロセスだけでなく、プロセスツリー全体がクリーンアップされることを保証する必要があります。
クリーンアップ：セッションを破棄し、すべての関連リソース（ファイルシステム、メモリ、プロセススロット、ネットワーク状態、保持されている資格情報）を解放します。この呼び出しは冪等である必要があります。これにより、ネットワークエラー後の再試行がエラーを引き起こさないようにします。
ファイルのアップロードとダウンロード：実行前にサンドボックスに入力ファイルを転送し、実行後に出力アーティファクトを取得します。ファイル転送はサイズ制限に制限され、書き込み可能なパスについてポリシーで制御される必要があります。
プロダクションでの使用のために確認する価値のある追加機能：
- 一時停止と再開：長時間実行セッションを一時停止し、後で状態を失わずに再開できますか？これは、レート制限、コスト制御、およびエージェントターン間のセッションハンドオフに役立ちます。
- スナップショット：現在のセッション状態をキャプチャし、将来のセッションの開始点として使用できますか？これは、ウォームプールと再利用可能な環境のための主要なメカニズムです。
- タイムアウトの強制：実行コードがウォールクロックタイムアウトを超えた場合、プラットフォームはそれをクリーンに終了し、正しい終了ステータスを報告しますか？
可観測性：ログ、メトリクス、トレース
デバッグや監査は、見えないものに対しては行えません。プロダクションサンドボックスには、後付けではなく組み込みの可観測性が必要です。
標準出力と標準エラー出力のキャプチャ：すべての実行は、セッションIDと実行IDに関連付けられたキャプチャされた出力レコードを生成する必要があります。これは、実行完了後にAPIを介してアクセス可能である必要があり、リアルタイムストリームとしてのみ利用可能であるべきではありません。
実行ログ：プラットフォームは、どのコードが実行されたか、いつ開始されたか、いつ終了したか、終了コードは何か、どのユーザーまたはテナントがセッションを所有していたか、どのテンプレートまたはスナップショットが使用されたかを記録する必要があります。これらのレコードは、問題が発生したときに何が起こったかを再構築するために必要な最小限の情報です。
リソースメトリクス：プロダクションアプリケーションには、CPU使用率、メモリピーク、ウォールクロック時間、ファイルシステム書き込みに関するセッションごとのメトリクスが必要です。これにより、キャパシティプランニング、異常検出、およびセッションごとのコスト属性が可能になります。
エラートレース：サンドボックスが起動、実行、またはクリーンアップに失敗した場合、エラーサーフェスは構造化されている必要があります。エラーコード、メッセージ、セッションID、およびユーザーエラー（不良コード、欠落パッケージ）とプラットフォームエラー（クォータ超過、内部障害）を区別するのに十分なコンテキスト。
監査証跡：マルチテナントアプリケーションの場合、監査証跡はエージェントの動作を再構築可能にする必要があります。セッションID、テナント、実行シーケンス、パッケージインストール、連絡先の外部ドメイン、書き込まれたファイル、クリーンアップ結果。生の顧客コードと完全なコマンド出力は、デフォルトでは監査ログに含めるべきではありません。実際にサポートできる保持およびアクセスポリシーに合わせて設計してください。
避けるべきこと：構造化されたエラー、セッションレベルのログがなく、タイムアウトとOOMとプロセスエスケープ試行を区別する方法がない「実行に失敗しました」のみを表示するサンドボックス。これにより、アプリケーションレイヤーですべてを計装する必要が生じ、作業が重複し、サンドボックスが直接観測できるイベントを見逃します。
CPU、メモリ、タイムアウト制限
無制限のリソース消費は、サンドボックスワークロードがプロダクションで問題を引き起こす最も簡単な方法の1つです。他のセッションを劣化させたり、予期しないインフラストラクチャコストを発生させたりします。
プロダクションサンドボックスは、ホストレベルだけでなく、セッションレベルで制限を強制する必要があります。
CPU：単一のセッションが消費できるCPU時間を制限します。無限ループを生成するセッションは、同じホスト上の他のセッションを劣化させるべきではありません。制限がハードキャップ（プロセスがスロットルまたは強制終了される）か、ソフト制限（使用可能なCPUを他のプロセスと競合する）かを確認してください。
メモリ：セッションがホストメモリを使い果たすことを許可するのではなく、クリーンアップまたは終了をトリガーするメモリ上限を設定します。制限に達したときに何が起こるかを確認してください。OOMキル、構造化エラー応答、またはサイレントハング。
ウォールクロックタイムアウト：すべての実行呼び出しには最大期間が必要です。タイムアウトはクライアントレベルだけでなく、プラットフォームレベルで強制可能である必要があります。クライアントが接続を切断した場合でも、サンドボックスは構成された制限で実行を終了する必要があります。
ディスク使用量：生成されたコードは、大きな出力ファイルを作成したり、大きなパッケージをインストールしたり、ワーキングディレクトリを埋めたりする可能性があります。セッションワーキングディレクトリのディスククォータは、暴走書き込みを防ぎます。
プロセス数：AI生成コードは、サブプロセス、バックグラウンドワーカー、またはさらに多くのプロセスを生成するシェルコマンドを生成する可能性があります。セッションの名前空間内のプロセス総数の制限は、フォーク爆弾や暴走サブプロセスツリーを防ぎます。
サンドボックスプラットフォームを評価するときは、これらの制限がセッションごとに構成可能かどうか（異なるユーザーティアやタスクタイプが異なる制限を持つことができるように）、サンドボックスレベルで強制されるかどうか、制限に達した場合に構造化されたAPIエラーを生成するか、サイレント障害になるかを確認してください。
パッケージインストールポリシー
AI生成コードは頻繁にパッケージインストールを要求します。pip install、npm install、apt-get、Gitクローン、直接URLフェッチなど。これらの各操作は、実行時に外部コードをサンドボックスに取り込みます。これはサンドボックスが管理する必要がある最もリスクの高い操作の1つです。
プロダクションパッケージポリシーは以下をカバーする必要があります。
レジストリアロウリスト：どのパッケージレジストリが許可されていますか？PyPIとnpmがデフォルトですが、多くのチームは内部ミラー、キュレーションされたレジストリ、または明示的に承認されたソースに制限するオプションを望んでいます。
インストールキャッシュ：多くのセッションが同じ人気パッケージをインストールする場合、レイヤーキャッシュまたはプルスループロキシにより、冗長なダウンロードを回避し、起動レイテンシを削減し、何がフェッチされているかを検査するポイントを提供します。
オフラインモード：一部のワークロードは、パッケージインストールをまったく行わずに実行する必要があります。環境はイメージまたはテンプレートに事前に組み込まれており、インストールの試行は明確なエラーで失敗する必要があります。これは、再現性が柔軟性よりも重要な評価実行に適したモードです。
ハッシュ検証とロックファイル：パッケージが許可されている場合、固定バージョンとハッシュ検証により、レジストリの侵害がサンドボックス内で実行されるコードを変更するリスクを軽減します。
サイズ制限：パッケージとその推移的依存関係は大きくなる可能性があります。セッションごとのダウンロードされたフットプリントの総サイズ上限は、偶発的または意図的なストレージの枯渇を防ぎます。
パッケージログ：すべてのインストール試行は、実行監査ログに記録される必要があります。パッケージ名、要求されたバージョン、レジストリソース、成功または失敗。これは、インシデント中にサンドボックスに入ったものを再構築するために必要なデータです。
サンドボックスベンダーに問うべき質問は、「ユーザーはパッケージをインストールできますか？」ではなく、「各インストールはどのように監査され、デフォルトでどのレジストリが許可され、機密性の高いワークロードに対してより厳格なポリシーを構成できますか？」です。
ネットワークとエグレス制御
ネットワークアクセスは、サンドボックスが予期しない宛先に到達するための2番目の主要なベクトルです。デフォルトでオープンなエグレスは開発では便利ですが、AI生成コードを実行するプロダクションアプリケーションにとっては不適切なデフォルトです。
デフォルト拒否エグレス：最も強力なプロダクション姿勢は、デフォルトですべてのアウトバウンド接続をブロックし、セッションが正当に必要とする宛先を明示的に許可リストに追加することです。これにはより多くの構成が必要ですが、アクセスモデルを監査可能にします。
許可リストの宛先：コーディングエージェントの場合、典型的な許可された宛先には、パッケージレジストリ、エージェントが呼び出すように構築された特定の公開APIのセット、およびそれ以外は何も含まれない場合があります。データ分析エージェントの場合、リストには特定のデータソースが含まれる場合があります。プラットフォームがセッションごとまたはテナントごとの宛先許可リストをサポートしていることを確認してください。
DNSポリシー：DNSはエグレスポリシーと一貫して処理される必要があります。任意のHTTP宛先に到達できないセッションは、任意のDNS名を解決し、それを使用してネットワークトポロジを推測したり、DNSベースのチャネルを介して制御をバイパスしたりすることもできないようにする必要があります。
内部サービスアクセス：AI生成コードは、クラウドメタデータエンドポイント（例：AWSインスタンスメタデータサービス）、内部API、プライベートデータベース、管理パネルにアクセスできるべきではありません。ただし、明示的に構成されている場合を除きます。サンドボックスのデフォルトのネットワークポリシーが、既知の内部アドレス範囲をブロックしていることを確認してください。
パッケージダウンロードエグレス：パッケージインストールはネットワーク操作です。エグレスが制限されている場合、パッケージレジストリの許可リストがエグレスポリシーと一致していることを確認するか、信頼されたネットワーク内のプルスループロキシを使用してください。
アウトバウンド接続のログ記録：エグレスが許可されている場合でも、セッションがどのドメインとIPに接続したかをログに記録することは、インシデント調査に役立ちます。すべてのサンドボックスプラットフォームがこれをネイティブに提供するわけではありません。何が得られるかを確認してください。
シークレットと認証情報の注入
AIエージェントは頻繁に認証情報を必要とします。APIキー、データベース接続、OAuthトークン、短期間のクラウド認証情報など。サンドボックスがシークレットをどのように扱うかは、セキュリティと運用信頼性の両方に影響します。
狭いスコープ：各セッションは、実行している特定のタスクに必要なシークレットのみを受け取る必要があります。すべてのセッションにすべての認証情報を含む広範な環境ファイルをマウントすることは、運用上は便利ですが、いずれかのセッションで侵害されたり誤動作したりしたコードがそれらの認証情報のすべてに到達できることを意味します。
短期間の認証情報：バックエンドがサポートする場合、セッションの存続期間にスコープされたTTLを持つ短期間のトークンを優先します。これにより、漏洩した認証情報が有用な期間が制限されます。
注入メカニズム：シークレットが環境変数として注入されるか、マウントされたファイルとして注入されるか、シークレットAPIを介して注入されるかを確認します。環境変数はデフォルトでセッション内のすべてのプロセスにアクセス可能です。マウントされたファイルはパスと権限セットにスコープできます。最も機密性の高い認証情報については、明示的に承認されたプロセスにのみ値を提供するシークレットAPIを検討してください。
編集：サンドボックスは、シークレットを標準出力、標準エラー出力、実行ログ、エラーメッセージ、またはモデル可視ツール応答を介してエコーバックしないようにする必要があります。編集はアプリケーションレイヤーの責任ですが、構成可能なログスクラビングをサポートするサンドボックスは、偶発的な露出の影響範囲を減らします。
クリーンアップ：セッション終了後、環境変数、マウントされたシークレットファイル、およびキャッシュされた認証情報データが、次のセッションに引き継がれるのではなく、セッションのティアダウンの一部としてクリーンアップされることを確認してください。
エフェメラルと永続ファイルストレージ
さまざまなワークロードには異なる永続性のニーズがあり、プロダクションサンドボックスは両方のパターンを明確にサポートする必要があります。
エフェメラルセッション：短命なコード実行のデフォルトは、クリーンなワーキングディレクトリを作成し、コードを実行し、出力を生成し、破棄されるセッションです。エフェメラルセッションは推論が容易です。各実行は既知のベースラインから開始され、状態が蓄積されず、クリーンアップは簡単です。これらは、評価ジョブ、ワンショットコード補完、および再現性が継続性よりも重要なタスクに適した選択肢です。
永続ワークスペース：長時間実行コーディングエージェント、反復的な開発ワークフロー、およびマルチターンエージェントセッションは、複数の実行呼び出しにわたって存続するワークスペースを必要とすることがよくあります。あるターンでインストールされたファイル、キャッシュされた依存関係、記述されたコード、蓄積された履歴は、次のターンで利用可能である必要があります。永続ワークスペースは運用がより複雑です。状態が蓄積され、テンプレートからドリフトする可能性があり、明示的なライフサイクルが必要です。いつワークスペースがクリーンアップされるか、誰が所有するか、セッション間でどのようなアクセス制御が保護するか。
スナップショットとテンプレート：テンプレートを使用すると、既知の良好なベースライン環境（ランタイム、ツール、依存関係）を定義し、そこから一貫してセッションを起動できます。スナップショットは、実行中のセッションの現在の状態をキャプチャし、将来のセッションの開始点として使用します。どちらも、再現可能な環境と低い起動レイテンシを必要とするチームに役立ちます。テンプレートがバージョン管理されていること、誰が作成および更新できるかが制御されていること、スナップショットがテナントによって分離されていることを確認してください。
出力アーティファクトのエクスポート：実行後、何をサンドボックスから持ち出すことができますか？プロダクションポリシーは、どのファイルパスがエクスポート可能か、どのサイズ制限が適用されるか、アーティファクトがアプリケーションに受け取られる前にレビューまたはフィルタリングされるかを定義する必要があります。
セッション間の状態：アプリケーションの設計がセッション間で状態を共有することを意図しているかどうかを明確にしてください。共有パッケージキャッシュ、共有ボリューム、または誤ったルーティングのワークスペースを介した偶発的な共有は、一般的なマルチテナント分離障害です。
バックエンド統合：REST、WebSocket、SDK
サンドボックスは、アプリケーションバックエンドにクリーンに統合できる場合にのみ有用です。3つの主要な統合パターンは、REST、WebSocket、SDKです。
REST：REST APIは、個別の実行リクエストを送信し、結果をポーリングするアプリケーションにとって、最も摩擦の少ない統合方法です。短命なタスクに適しており、標準のHTTPツールでデバッグが容易で、既存のサービスアーキテクチャに自然に適合します。トレードオフは、結果のポーリングがプッシュ通知と比較してレイテンシを追加し、長時間実行出力のストリーミングにはSSEまたはログエンドポイントのポーリングのいずれかが必要になることです。
WebSocket：WebSocket接続は、アプリケーションとサンドボックス間の双方向の低レイテンシ通信をサポートします。これは、インタラクティブなユースケースに適した選択肢です。コードの実行時に出力をストリーミングするコーディングアシスタント、コマンドを送信してリアルタイムで応答を受信する必要があるブラウザエージェント、または実行を継続的に監視する評価ハーネス。トレードオフは運用の複雑さです。WebSocket接続は永続的な状態、再接続処理、およびクライアントとサーバーの両方でより複雑なインフラストラクチャを必要とします。
SDK：言語ネイティブSDKは、トランスポートの詳細を隠蔽し、認証を処理し、セッション管理と実行のための型付きインターフェースを提供し、多くの場合、出力のストリーミング、ファイルのアップロード、テンプレートの管理のためのヘルパーを含みます。SDKは、ほとんどのアプリケーション開発者にとって統合への最速のパスです。SDKが積極的にメンテナンスされ、完全なAPIサーフェスをカバーし、アプリケーションが対応できる構造化された方法でエラーを処理することを確認してください。
アプリケーションが所有する必要がある統合ポイント：トランスポートに関係なく、アプリケーションは、認可（どのユーザーがどのリソース制限でセッションを作成できるか）、承認ゲート（実行前にどのツール呼び出しまたはコード実行に人間のレビューが必要か）、結果処理（サンドボックス出力がエージェントによってどのように表面化または処理されるか）、およびクリーンアップ（ユーザーフローが完了したとき、またはエージェントターンが終了したときにセッションのティアダウンをトリガーする）を担当します。
適切に設計されたサンドボックスAPIは、アプリケーションのビジネスロジックを所有しようとはしません。プリミティブ（作成、実行、ストリーム、終了、クリーンアップ）を公開し、アプリケーションレイヤーがその上に適切な製品動作を構築できるようにします。
障害復旧とクリーンアップ
プロダクションシステムは失敗します。障害を適切に処理するサンドボックスは、リソースリーク、古い状態、デバッグが困難なインシデントを防ぎます。
実行タイムアウト処理：実行中の実行がタイムアウトを超えた場合、プラットフォームはプロセスツリーをクリーンに終了し、構造化されたエラー応答を返す必要があります。リソースを消費するゾンビセッションを残してはいけません。タイムアウト後にセッションがどうなるかを確認してください。自動的にクリーンアップされますか、それとも明示的なクリーンアップ呼び出しが必要ですか？
セッションクラッシュ復旧：サンドボックスホストがクラッシュした場合、またはセッションVMが予期せず終了した場合、プラットフォームは障害を検出し、セッションを終了としてマークし、アプリケーションが反応できるようにAPIを介してその状態を表面化する必要があります。セッションは、APIシグナルなしに静かに消えるべきではありません。
クリーンアップの保証：cleanup または terminate API呼び出しは、すべてのリソース（CPUおよびメモリ割り当て、ファイルシステムクォータ、プロセススロット、ネットワーク状態、認証情報）を確実に解放する必要があります。クリーンアップは冪等である必要があります。同じセッションIDで複数回呼び出してもエラーを返してはいけません。これは実際に重要です。ネットワークエラー後にクリーンアップを再試行するアプリケーションコードは、壊れてはいけません。
部分的な実行失敗：コードが実行の途中で失敗した場合（未処理の例外、強制終了されたプロセス、欠落パッケージ）、サンドボックスは部分的な成功（失敗の前にいくつかの出力が生成された）と完全な失敗を区別する構造化された結果を返す必要があります。部分的な結果に基づいて構築されたアプリケーションは、不完全または誤解を招く出力をユーザーに提示しないためにこれが必要です。
暴走プロセス処理：生成されたコードがメイン実行を生き延びるバックグラウンドプロセスを作成した場合、サンドボックスはそれをセッションクリーンアップの一部として終了し、無期限に実行させないようにする必要があります。プラットフォームのクリーンアップが、実行呼び出しの直接の子だけでなく、プロセスツリー全体をカバーしているかどうかを確認してください。
容量とクォータエラー：プラットフォームがセッション容量に達した場合、またはテナントがクォータに達した場合、APIは、アプリケーションが明示的に処理できる特定のエラーコードを返す必要があります。一般的な500やサイレントハングではなく。これにより、アプリケーションはキューに入れたり、バックオフしたり、ユーザーに役立つメッセージを表示したりできます。
Novita Agent Sandbox
Novita Agent Sandbox は、エージェントワークロード向けに構築されたマネージドサンドボックスプラットフォームです。コーディングエージェント、データ分析エージェント、ブラウザ指向のワークフロー、および生成されたコードがアプリケーションサーバーや共有インフラストラクチャに置かれることなく、分離された観測可能な環境で実行する必要がある長時間実行エージェントセッションを対象としています。
すでにNovita AIモデルAPIを使用しているチームにとって、Agent Sandboxはより広範なエージェントアーキテクチャの一部となります。モデルがコードを計画および生成し、サンドボックスがプログラム可能なライフサイクルで分離された実行を提供し、アプリケーションレイヤーが認可、承認ゲート、結果処理を担当します。
Novitaは、MicroVM分離、並行セッションサポート、作成、実行、ストリーム、終了、クリーンアップをカバーするライフサイクルAPI、セッション状態管理のための一時停止と自動再開、高速で再現可能な環境起動のためのテンプレートとスナップショット、およびNovitaモデルAPIとの統合などの機能を説明しています。アーキテクチャ上の決定を行う前に、Novita Agent Sandboxのドキュメント および製品ページで、現在の機能の利用可能性、リソース構成オプション、価格を確認してください。特定の分離境界、並行性制限、起動レイテンシ、ネットワークポリシーに関する主張は、現在の製品ドキュメントと照らし合わせて確認する必要があります。
Novita Agent Sandboxをこのガイドの要件と比較して評価する場合は、他のベンダーと同じチェックリストを適用してください。セッションごとの分離境界、ライフサイクルAPIの完全性、可観測性サーフェス、構成可能なリソース制限、パッケージポリシーオプション、エグレス制御、シークレット処理、永続性モデル、バックエンド統合サポート。
FAQ
AI生成コードにはどの分離モデルを選択すべきですか？
MicroVM分離は、信頼できないAI生成コードに対して最も強力な境界を提供しますが、運用の複雑さが増します。コンテナ分離は、コンテナが適切に強化されている場合（特権モードなし、最小限のケーパビリティ、可能な限り読み取り専用のルートファイルシステム、ホストソケットマウントなし）、低リスクのワークロードには十分です。プロセス分離だけでは、システムコール、サブプロセスの生成、パッケージインストールを試みる可能性のある信頼できないコードに対しては薄すぎる境界です。実際の脅威モデルに分離レベルを一致させてください。
プロダクションサンドボックスでパッケージインストールを処理するにはどうすればよいですか？
デフォルトでオープンなアクセスではなく、レジストリアロウリストを使用します。プルスルーキャッシュを追加して、冗長なダウンロードを削減し、検査ポイントを提供します。パッケージ名、バージョン、ソース、結果を含むすべてのインストール試行をログに記録します。再現性が柔軟性よりも重要なワークロード（評価実行、自動化パイプライン）の場合、環境が事前に組み込まれ、インストールが完全に禁止されるオフラインモードを検討してください。
ライフサイクルAPIは最低限何を公開する必要がありますか？
作成、ストリーミング出力付き実行、終了、クリーンアップ。ストリーム出力は、最小限の実装で最も欠落しがちな機能であり、インタラクティブなエージェントUIにとって最も重要なものです。クリーンアップは冪等であり、エントリポイントプロセスだけでなく、プロセスツリー全体をカバーする必要があります。
シークレットがサンドボックスを介して漏洩するのを防ぐにはどうすればよいですか？
認証情報をタスクに狭くスコープします。広範な環境ファイルではありません。短期間のトークンを優先します。シークレットが表示される可能性がある場合は、デフォルトで完全な標準出力をログに記録しないでください。サンドボックスがセッションのティアダウン時に環境変数とマウントされたシークレットファイルをクリーンアップすることを確認してください。編集はサンドボックスの保証ではなく、アプリケーションの責任として扱ってください。
