AI生成コードを実行する本番アプリケーションには、プロセスレベルの分離を強制し、同時セッションをサポートし、プログラム可能なライフサイクルAPIを公開し、観測可能なログとリソースメトリクスを提供し、パッケージとネットワークポリシーを適用し、アプリバックエンドとクリーンに統合できるサンドボックスが必要です。これらの各側面を体系的に評価せずにサンドボックスを選択することは、チームが本番環境で問題に遭遇する最も一般的な方法です。ステージングでは安全に見えたワークロードが、実際のトラフィックの下で失敗したり、テナント間で状態が漏洩したり、アプリが決して許可するつもりのなかったコードを静かに実行したりします。
このガイドは要件チェックリストです。各分離レベルで確認すべきこと、本番ライフサイクルAPIが公開すべきこと、観測可能性とリソース制御の姿、そしてバックエンド統合パターンが設計を成功させるか失敗させるかをカバーします。マネージドサンドボックスを評価する場合でも、独自のものを構築する場合でも、リリース前に答える価値のある質問です。
サンドボックス分離：プロセス、コンテナ、マイクロVM
分離はスペクトラムであり、各レベルはパフォーマンス、移植性、そして生成コードに対してどれだけの信頼を置くかに関して異なるトレードオフをもたらします。
プロセスレベルの分離 は、OSプリミティブ（名前空間、cgroup、seccomp、AppArmorまたはSELinuxプロファイル）を使用して、プロセスがアクセスできるものを制限します。高速で、個別のVMカーネルを必要としませんが、すべてのプロセスはホストカーネルを共有します。カーネルの脆弱性や、seccompフィルターをすり抜ける特権システムコールは、同じホスト上の他のワークロードに影響を与える可能性があります。プロセス分離は、低リスク、短命、信頼できるコードパスにとって妥当な出発点ですが、信頼できないAI生成コード（システムコール、サブプロセスの生成、パッケージインストールを試みる可能性がある）にとっては薄い境界です。
このレベルで確認すべきこと：
- どのシステムコールがブロックされているか、未知のシステムコールが試行された場合のデフォルトポリシーは何か？
- 名前空間はタスクごと、テナントごとにスコープされているか、それともジョブ間で共有されているか？
- cgroup制限はタスクレベルで強制されているか、それともホストレベルだけか？
- サンドボックスは終了時にすべてのプロセス、一時ファイル、ソケット、共有メモリをクリーンアップするか？
コンテナレベルの分離 は、ファイルシステムとネットワーク名前空間の境界を追加し、イメージ管理を反復可能にします。コンテナは完全なVMよりも起動が速く、構成が容易で、オーケストレーションレイヤーで広くサポートされています。トレードオフは、コンテナが依然としてホストカーネルを共有し、コンテナの境界は基盤となるランタイム設定と同じ程度の強度しかないことです。特権コンテナ、広範なケーパビリティセット、マウントされたホストソケット、ホストネットワークモードはすべて、効果的な境界をほぼ無にします。
このレベルで確認すべきこと：
- コンテナイメージは最小限で、ワークロードが実際に必要とするランタイムとツールのみを含んでいるか？
- ケーパビリティは必要な最小セットに削減されているか？
- コンテナはルートレスか、それともルートを必要とし、その周りにどのような制御があるか？
- ホストPID名前空間、ホストネットワーク、Dockerソケットは明示的に除外されているか？
- マウントされたボリュームは明示的に定義されたパスに制限され、可能な場合はルートファイルシステムは読み取り専用か？
マイクロVM分離 は、各ワークロードを軽量な仮想マシン（独自のゲストカーネル、仮想デバイス、ゲストとホスト間のKVMバックアップ境界を持つ）の内部に配置します。Firecrackerのような技術は、攻撃対象領域を減らすために最小限のデバイスモデルを使用しながら、インタラクティブな使用に十分な高速起動を維持します。マイクロVM境界は、ゲスト内のカーネルエクスプロイトが自動的にホストや他のゲストに影響を与えないことを意味します。
このレベルで確認すべきこと：
- 各エージェント実行、各テナント、または各同時セッションは個別のマイクロVMを取得するか？
- API呼び出しから実行準備完了までの起動レイテンシはどの程度で、それはウォームプール、スナップショット、コールドブートのどれから測定されるか？
- ゲストイメージはバージョン管理され、含まれるランタイムとツールについて監査され、定期的に更新されているか？
- ゲストカーネルがパニックしたり応答しなくなったりした場合、ホストレベルでは何が起こるか？
実際の決定は、あなたの脅威モデルに関するものです。マイクロVM分離は、信頼できないAI生成コードに対して一般的に利用可能な最強の境界ですが、ファイルシステムポリシー、エグレス制御、パッケージガバナンス、またはシークレット処理に取って代わるものではありません。これらの制御は、選択した分離レイヤーの上に配置する必要があります。
同時サンドボックスセッションの管理
複数のユーザー向けに同時にコードを生成する本番アプリケーションには、同時実行性を後付けではなく第一級の関心事として扱うサンドボックスが必要です。
重要な質問は次のとおりです：
セッションごとの分離：50のセッションが同時に実行されている場合、各セッションは独自の分離されたファイルシステム、プロセスツリー、ネットワーク名前空間、およびクレデンシャルスコープを持っていますか？セッション間の状態漏洩は、マルチテナントのサンドボックスアプリケーションにおける最も有害な障害モードの1つであり、セッションが順次実行されるテストではしばしば見えません。
セッション制限とバックプレッシャー：サンドボックスは、同時実行制限を明確なAPI契約として表面化しますか？500のリクエストが到着し、プラットフォームが100の同時セッションをサポートしている場合、APIは構造化エラーを返すか、リクエストをキューに入れるか、静かに劣化しますか？本番アプリケーションは、バックプレッシャー、キュー管理、ユーザー向けフィードバックを実装するためにそのシグナルを必要とします。
負荷時のリソース公平性：1つのセッションが異常に高いCPUまたはメモリを消費した場合、他のセッションはセッションごとのリソース制限によって保護されていますか、それとも1つのノイズの多いワークロードがプール全体を劣化させる可能性がありますか？
ウォームプールとセッション起動レイテンシ：インタラクティブなコーディング機能には、サブ秒のセッション開始時間が必要です。通常、これにはオンデマンドで起動するのではなく、即座に要求できる事前初期化された環境のプールが必要です。プラットフォームがウォームプールの可用性を文書化しているか、異なる同時実行レベルでどのような起動レイテンシを期待すべきかを確認します。
セッション再利用と新しい環境：一部のアプリは、複数のエージェントターンにわたって長期実行セッションを再利用することでメリットを得ますが、他のアプリはリクエストごとにクリーンな環境を必要とします。両方のパターンがサポートされていること、そしてセッション再利用が以前の会話からの古い状態を持ち越さないことを確認します。
ライフサイクルAPI：作成、実行、終了
ライフサイクルAPIは、アプリケーションとサンドボックスランタイムの間のインターフェースです。本番グレードのAPIは、少なくとも以下を公開する必要があります：
作成：新しいサンドボックスセッションを初期化します。オプションでテンプレートまたはスナップショットから、指定されたリソース制限、環境変数、マウントされたボリュームを使用します。レスポンスには、セッションIDと準備完了シグナルが含まれている必要があり、単なる確認応答ではありません。
実行：実行するコードまたはコマンドを送信します。これは非同期呼び出しであり、実行IDを返す必要があります。APIは、ワーキングディレクトリの指定、呼び出しの環境オーバーライド、タイムアウトをサポートする必要があります。
出力のストリーム：stdoutとstderrを、実行完了後の最終結果としてだけでなく、ストリームとして取得します。ストリーミングは、長時間実行ジョブ、多くの秒を要するエージェントステップ、およびユーザーに段階的な進行状況を表示するUXにとって重要です。
終了：実行が完了する前に実行中の実行を終了します。サンドボックスは、プロセスツリーが確実にクリーンアップされることを保証する必要があり、親プロセスだけではありません。
クリーンアップ：セッションを破棄し、関連するすべてのリソース（ファイルシステム、メモリ、プロセススロット、ネットワーク状態、保持されているクレデンシャル）を解放します。この呼び出しは冪等である必要があり、ネットワークエラー後の再試行がエラーを引き起こさないようにします。
ファイルのアップロードとダウンロード：実行前にサンドボックスに入力ファイルを転送し、実行後に出力アーティファクトを取得します。ファイル転送はサイズ制限で制限され、書き込み可能なパスがポリシーで制御されている必要があります。
本番環境で確認する価値のある追加機能：
- 一時停止と再開：長期実行セッションを一時停止し、後で状態を失うことなく再開できますか？これは、レート制限、コスト管理、エージェントターン間のセッションハンドオフに役立ちます。
- スナップショット：現在のセッション状態をキャプチャし、将来のセッションの開始点として使用できますか？これは、ウォームプールと再利用可能な環境のための重要なメカニズムです。
- タイムアウトの強制：実行中のコードがウォールクロックタイムアウトを超えた場合、プラットフォームはそれをクリーンに終了し、正しい終了ステータスを報告しますか？
観測可能性：ログ、メトリクス、トレース
見えないものはデバッグも監査もできません。本番サンドボックスには、後付けではなく組み込まれた観測可能性が必要です。
stdoutとstderrのキャプチャ：すべての実行は、セッション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を検討します。
編集：サンドボックスは、stdout、stderr、実行ログ、エラーメッセージ、またはモデル可視ツール応答を介してシークレットをエコーバックしてはいけません。編集はアプリケーション層の責任ですが、構成可能なログスクラビングをサポートするサンドボックスは、偶発的な露出の爆発半径を減らします。
クリーンアップ：セッション終了後、環境変数、マウントされたシークレットファイル、およびキャッシュされたクレデンシャルデータが、次のセッションに継承されるのではなく、セッションティアダウンの一部としてクリーンアップされることを確認します。
エフェメラル vs 永続ファイルストレージ
異なるワークロードには異なる永続性のニーズがあり、本番サンドボックスは両方のパターンを明確にサポートする必要があります。
エフェメラルセッション：短命なコード実行のデフォルトは、クリーンなワーキングディレクトリを作成し、コードを実行し、出力を生成し、破棄されるセッションです。エフェメラルセッションは推論が容易です。各実行は既知のベースラインから開始され、状態は蓄積されず、クリーンアップは簡単です。これらは、評価ジョブ、ワンショットコード補完、および継続性よりも再現性が重要なタスクに適切な選択です。
永続ワークスペース：長時間実行コーディングエージェント、反復的な開発ワークフロー、およびマルチターンエージェントセッションは、複数の実行呼び出しにわたって存続するワークスペースを必要とすることがよくあります。あるターンでインストールされたファイル、キャッシュされた依存関係、書かれたコード、蓄積された履歴は、次のターンで利用可能である必要があります。永続ワークスペースは運用がより複雑です。状態を蓄積し、テンプレートからドリフトする可能性があり、明示的なライフサイクルが必要です（ワークスペースはいつクリーンアップされるか、誰が所有するか、セッション間でどのようなアクセス制御が保護するか？）。
スナップショットとテンプレート：テンプレートを使用すると、既知の良好なベースライン環境（ランタイム、ツール、依存関係）を定義し、そこから一貫してセッションを起動できます。スナップショットは実行中のセッションの現在の状態をキャプチャし、将来のセッションの開始点として使用します。どちらも、反復可能な環境と低起動レイテンシを必要とするチームにとって有用です。テンプレートがバージョン管理され、誰が作成および更新できるかが制御され、スナップショットがテナントごとに分離されていることを確認します。
出力アーティファクトのエクスポート：実行後、何がサンドボックスから出ることができますか？本番ポリシーは、どのファイルパスがエクスポート可能か、どのサイズ制限が適用されるか、アーティファクトがアプリケーションに受信される前にレビューまたはフィルタリングされるかを定義する必要があります。
セッション間の状態：アプリ設計がセッション間で状態を共有することを意図しているかどうかを明確にします。共有パッケージキャッシュ、共有ボリューム、または誤ったルーティングのワークスペースによる偶発的な共有は、一般的なマルチテナント分離障害です。
バックエンド統合：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は、マイクロVM分離、同時セッションサポート、作成、実行、ストリーム、終了、クリーンアップをカバーするライフサイクルAPI、セッション状態管理のための一時停止と自動再開、迅速で反復可能な環境起動のためのテンプレートとスナップショット、およびNovitaモデルAPIとの統合を含む機能を説明しています。アーキテクチャ上の決定を行う前に、現在の機能の可用性、リソース構成オプション、および価格をNovita Agent Sandboxドキュメントおよび製品ページで確認してください。特定の分離境界、同時実行制限、起動レイテンシ、ネットワークポリシーに関する主張は、現在の製品ドキュメントに対して確認する必要があります。
Novita Agent Sandboxをこのガイドの要件に対して評価する場合、他のベンダーと同じチェックリストを適用します。セッションごとの分離境界、ライフサイクルAPIの完全性、観測可能性サーフェス、構成可能なリソース制限、パッケージポリシーオプション、エグレス制御、シークレット処理、永続性モデル、およびバックエンド統合サポート。
よくある質問
AI生成コードにはどの分離モデルを選択すべきですか？
マイクロVM分離は、信頼できないAI生成コードに対して最強の境界を提供しますが、運用の複雑さが増します。コンテナ分離は、コンテナが適切に強化されている場合（特権モードなし、最小限のケーパビリティ、可能な場合は読み取り専用のルートファイルシステム、ホストソケットマウントなし）、低リスクのワークロードに適切です。プロセス分離だけでは、システムコール、サブプロセス生成、パッケージインストールを試みる可能性のある信頼できないコードには薄すぎる境界です。実際の脅威モデルに分離レベルを一致させます。
本番サンドボックスでのパッケージインストールはどう処理すればよいですか？
デフォルトオープンアクセスではなく、レジストリ許可リストを使用します。プルスルーキャッシュを追加して、冗長なダウンロードを減らし、検査ポイントを提供します。すべてのインストール試行をパッケージ名、バージョン、ソース、結果とともに記録します。柔軟性よりも再現性が重要なワークロード（評価実行、自動化パイプライン）の場合は、環境が事前に組み込まれ、インストールが完全に禁止されるオフラインモードを検討します。
ライフサイクルAPIは最低限何を公開すべきですか？
作成、出力のストリーミングによる実行、終了、クリーンアップ。ストリーム出力は、最小限の実装で最も欠落している機能であり、インタラクティブなエージェントUIにとって最も重要なものです。クリーンアップは冪等であり、エントリポイントプロセスだけでなく、完全なプロセスツリーをカバーする必要があります。
サンドボックスを介したシークレットの漏洩を防ぐにはどうすればよいですか？
クレデンシャルを広範な環境ファイルではなく、タスクに狭くスコープします。短期間のトークンを優先します。シークレットが表示される可能性がある場合、デフォルトで完全なstdoutをログに記録しないでください。サンドボックスがセッションティアダウン時に環境変数とマウントされたシークレットファイルをクリーンアップすることを確認します。編集はサンドボックスの保証ではなく、アプリケーションの責任として扱います。
