RLエージェントのサンドボックスは、状態を分離し、リソースを制御し、アクションと出力を記録し、試行間で環境をリセットすることで、実験を再現可能にする必要があります。これは、強化学習、評価ループ、コーディングエージェント、ブラウザエージェント、そしてエージェントがコマンドを実行したり、ファイルを変更したり、ツールを呼び出したり、学習元の環境を変更したりするような試行錯誤システムにとって重要です。
なぜRLエージェントにサンドボックスが必要なのか
強化学習はインタラクションに基づいて構築されています。エージェントは環境を観察し、アクションを選択し、フィードバックを受け取り、ポリシーや決定プロセスを更新します。おもちゃのシミュレーターでは、このループはグリッド上のトークンを動かすだけかもしれません。しかし、現代のエージェントシステムでは、アクションがPythonの実行、パッケージのインストール、リポジトリの編集、Webアプリのクリック操作、ツールの呼び出し、または評価者が評価するファイルの生成を行う可能性があります。
これにより、ランタイムは実験の一部となります。2つの試行がファイルシステム、キャッシュ、ブラウザセッション、バックグラウンドプロセス、または部分的に変更されたリポジトリを共有する場合、2回目の試行は1回目と同じ状態から開始されません。報酬が向上するのは、エージェントが学習したからかもしれませんし、環境が誤って依存関係、認証情報、コンパイル済みバイナリ、ブラウザCookie、または生成されたヘルパーファイルを保持していたからかもしれません。封じ込めとリセット動作がなければ、その違いを見分けるのは困難です。
サンドボックスは、各試行に明確な実行境界を与えます。それ自体は完全な安全戦略ではなく、報酬設計、ポリシーレビュー、アクセス制御、人間による承認の必要性を排除するものではありません。これは、ビルダーに、エージェントのアクションを実行し、副作用を観察し、アーティファクトをキャプチャし、次の試行の前に環境をリセットするための制御された場所を提供します。
RLスタイルのエージェント作業では、有用な質問は単に「このサンドボックスは安全か？」ではありません。より良い質問は「このランタイムは、1回の試行が静かに次の試行を汚染することなく、再現可能な実験をサポートできるか？」です。
RLエージェントの試行におけるリセット可能性の意味
リセット可能性とは、新しいエピソード、評価、またはトレーニングバッチの前に、環境を既知のベースラインに戻す能力のことです。実際には、このベースラインにはクリーンなディレクトリ以上のものが含まれます。
RLエージェントのサンドボックスは、以下のものをリセットする必要があるかもしれません：
- 試行中に作成、編集、削除、またはダウンロードされたファイル。
- インストールされたパッケージ、ビルドキャッシュ、コンパイル済みアーティファクト、一時ファイル。
- 実行中のプロセス、ポート、ソケット、ブラウザセッション、バックグラウンドジョブ。
- 環境変数とスコープ化された認証情報。
- データベースフィクスチャ、ローカルサービス、キュー、モックAPI。
- ネットワークポリシー、パッケージレジストリ設定、ツールの権限。
- 評価状態、報酬ログ、評価者入力。
リセットメカニズムはワークロードによって異なります。コーディングベンチマークでは、リポジトリのチェックアウトとテストフィクスチャを復元する必要があるかもしれません。ブラウザタスクでは、Cookie、ローカルストレージ、ダウンロード、ブラウザプロファイルをクリアする必要があるかもしれません。データ分析エージェントでは、承認された出力アーティファクトのみを保持しながら、入力データセットをリセットする必要があるかもしれません。マルチステップエージェント評価では、一時停止、検査、そしてサンドボックスを再開または破棄する必要があるかもしれません。
よくある間違いは、リセットを最後に実行するクリーンアップスクリプトとして扱うことです。クリーンアップスクリプトは失敗します。エージェントはそれらを強制終了したり、実行前にハングさせたり、ディスクを満杯にしたり、バックグラウンドプロセスを残したり、スクリプトが知らないパスを作成したりする可能性があります。より堅牢な設計は、各試行を既知のテンプレートまたはスナップショットから開始し、変更内容を記録し、ランタイム境界全体を破棄またはリセットすることです。
再現可能な環境と状態スナップショット
再現可能なRL試行には、明確なベースラインが必要です。このベースラインは、オペレーティングシステムイメージ、言語ランタイム、パッケージ、データセットバージョン、環境変数、ファイル、ネットワークポリシー、リソース制限、エントリポイントコマンドを定義する必要があります。
一般的なベースラインパターンは3つあります：
| パターン | 最適な用途 | 注意点 |
|---|---|---|
| テンプレートからの新しいサンドボックス | 独立したエピソード、バッチ評価、コーディングタスク、ブラウザタスク | 起動時間とパッケージインストール時間が短い試行を支配する可能性がある |
| スナップショットと復元 | 各試行前に準備された環境が必要なマルチステップタスク | スナップショットがバージョン管理されていない場合、スナップショットのドリフトが変更を隠す可能性がある |
| 制御されたチェックポイントによる長期実行サンドボックス | インタラクティブデバッグ、カリキュラムタスク、ヒューマンインザループ修正 | チェックポイントが明示的でない限り、試行間で状態が漏洩する可能性がある |
テンプレートは、ほとんどの試行が同じ既知のイメージから開始する場合に便利です。スナップショットは、依存関係のインストール、公開フィクスチャのダウンロード、プロジェクトのコンパイル、ブラウザ対応ワークスペースのオープンなど、高価なセットアップの後に役立ちます。長期実行セッションは、本当にメモリと状態を必要とするエージェントワークフローに役立ちますが、状態モデルが実験の一部でない限り、評価のデフォルトにすべきではありません。
実用的なルール：試行が始まる前に、何を永続化することが許可されているかを定義します。答えが「承認されたアーティファクト以外は何もない」場合は、新しいサンドボックスまたはスナップショット復元を使用します。答えが「エージェントは以前の試行に基づいて構築すべき」である場合は、その永続性を実験の一部として扱い、そのようにログに記録します。
決定論的実行と非決定論的実行
すべてのエージェント試行を完全に決定論的にできるわけではありません。言語モデルのサンプリング、外部API、ブラウザのタイミング、パッケージレジストリの可用性、並列プロセス、ネットワークレイテンシはすべて変動する可能性があります。それでも、サンドボックスは回避可能な変動の原因を減らすことができます。
より再現性の高い実行のために、制御可能な部分を制御します：
- パッケージバージョン、コンテナイメージ、データセット、プロンプト、評価者コード、モデル設定を固定します。
- モデル、環境、または評価者がサポートする場合は、乱数シードを記録します。
- ベンチマークフィクスチャと期待される出力を固定します。
- パッケージインストールを承認されたレジストリまたはキャッシュ経由でルーティングします。
- タスクが明示的にライブ統合に関するものでない限り、報酬ソースとして本番システムを避けます。
- 実行中に使用された正確なコマンド、ツール呼び出し、ファイル、ネットワーク宛先をキャプチャします。
次に、決定論的障害と確率的動作を分離します。試行7がエージェントが異なる計画を選択したために失敗した場合、それは有用な情報です。試行7が前の試行が同じポートにプロセスを残したために失敗した場合、それは環境汚染です。試行7がパッケージレジストリが異なるバージョンを返したために失敗した場合、それは依存関係のドリフトです。
サンドボックスはこれらの違いを可視化する必要があります。すべてのRLエージェント実行が決定論的であるふりをするのが目標ではありません。目標は、隠れた状態を除去し、実行がなぜ変わったかを説明するのに十分な証拠を保持することです。
試行ループのリソース制限と時間制限
RLと評価ループは多くの試行を実行する可能性があります。単一のエージェントのバグは急速に増幅する可能性があります：無限ループ、暴走するパッケージインストール、フォークされたプロセス、大規模なダウンロード、無制限のログ、繰り返されるブラウザセッション。リソース制御は、悪い試行が評価予算全体を消費するのを防ぎます。
エージェントプロンプト内だけでなく、サンドボックスレベルで制限を設定します：
| 制限 | RLエージェントにとって重要な理由 |
|---|---|
| ウォールクロックタイムアウト | ハングしたエピソードがバッチをブロックするのを防ぐ |
| CPUおよびメモリクォータ | 1つの試行が隣接する試行を枯渇させるのを防ぐ |
| ディスククォータ | ログ、キャッシュ、パッケージインストール、生成されたアーティファクトを制御する |
| プロセス制限 | 暴走するサブプロセスおよびバックグラウンドジョブの失敗を減らす |
| ネットワークポリシー | 予期しない呼び出し、ダウンロード、内部アクセスを防ぐ |
| 出力サイズ制限 | モデルコンテキストとテレメトリパイプラインを使いやすく保つ |
| 同時サンドボックスキャップ | スイープ中の予算と共有インフラストラクチャを保護する |
タイムアウトにはニュアンスが必要です。短いベンチマークエピソードにはハードタイムアウトが適切です。長時間実行タスクでは、進行状況を人間が検査して続行するかどうかを決定できるように、一時停止、再開、またはチェックポイントが必要になる場合があります。重要なのは、ランタイムポリシーが明示的であることです。報酬ループが終了しなかったからといって、エージェントに無制限の計算リソースを与えるべきではありません。
報酬、評価、デバッグのためのテレメトリ
報酬シグナルは、それを説明できて初めて有用です。エージェントシステムでは、スコアは多くの要素を組み合わせることがよくあります：タスクの成功、テスト結果、コマンドの終了コード、ファイルの差分、ブラウザの状態、レイテンシ、トークン使用量、人間のラベル、評価者の出力。サンドボックスは、不必要な秘密や個人データを保存することなく、スコアを理解するために必要な証拠をキャプチャする必要があります。
有用なテレメトリには以下が含まれます：
- サンドボックスID、試行ID、タスクID、テンプレートまたはスナップショットバージョン、開始時刻。
- 実行に使用されたモデルおよびエージェント設定。
- ツール呼び出し、シェルコマンド、終了コード、ランタイム期間。
- 読み取り、書き込み、作成、削除、またはエクスポートされたファイル。
- 連絡されたネットワークドメインとインストールされたパッケージ名。
- 関連する場合のブラウザアクション、スクリーンショット、ダウンロード、最終ページ状態。
- 評価者の入力、報酬出力、テスト結果、評価者のエラー。
- レビューのためにサンドボックスからコピーされたアーティファクト。
生のログはスコープを制限してください。完全なコマンド出力、生のプロンプト、ブラウザのスクリーンショット、生成されたファイルには機密情報が含まれている可能性があります。多くのシステムでは、構造化されたテレメトリと選択的に保持されたアーティファクトの方が優れたデフォルトです。実行の再現とデバッグに十分な量を保存し、ログを認証情報、顧客データ、未レビューのモデル出力でいっぱいのセカンドデータレイクにしないでください。
報酬設計はサンドボックスの制限も考慮する必要があります。エージェントがパブリックインターネットにアクセスすることを許可されていない場合、ライブWebサイトが利用できなかったことで失敗としてスコア付けしないでください。サンドボックスに小さなディスククォータがある場合、エージェントがストレージを力技で確保できたかどうかではなく、その制約をどのように処理したかを測定します。環境ポリシーと報酬関数は一致している必要があります。
ファイル、ネットワーク、安全でないアクションの境界
サンドボックスは、エージェントが触れることができる範囲を狭めるときに最も役立ちます。RLスタイルの試行では、エージェントが驚くべきアクションを発見する可能性があると想定して開始します。プロンプトで言及されていないコマンドを実行したり、隠しファイルを検査したり、ブロックされたネットワークパスを再試行したり、パッケージをインストールしたり、後のステップで動作を変更するスクリプトを生成したりする可能性があります。
タスクに一致するファイルシステム境界を使用します：
- エージェントが検査するだけでよい場合は、入力を読み取り専用でマウントします。
- 生成された出力は別の書き込み可能ディレクトリに配置します。
- 認証情報、ホスト設定、ブラウザプロファイル、デプロイキーをワークスペースの外に保管します。
- 試行間で書き込み可能ディレクトリをリセットします。
- デフォルトでワークスペース全体ではなく、承認されたアーティファクトのみをコピーアウトします。
ネットワークポリシーも同じ精度が必要です。コーディングベンチマークはインターネットアクセスを必要としない場合があります。パッケージインストールタスクはレジストリの許可リストを必要とする場合があります。ブラウザエージェント評価は特定の公開Webサイトとブロックされた内部メタデータエンドポイントを必要とする場合があります。データエージェントワークフローは、広範なプライベートネットワーク到達可能性の代わりに、狭いAPIを必要とする場合があります。
安全でないアクションは、実験に明示的に含まれており、レビューパスが明確でない限り、自動ループの外側に留める必要があります。例としては、本番環境へのデプロイ、顧客向けメッセージ、課金変更、アクセス制御編集、大規模エクスポート、破壊的なデータベース書き込み、インフラストラクチャ変更などがあります。サンドボックスはランタイムの副作用を含めることができますが、どのビジネスアクションが承認に値するかを決定することはできません。
アーティファクトのキャプチャと人間によるレビュー
RLエージェントの試行の終了時には、レビュー可能な記録を生成する必要があります。これはすべてを保存することを意味するのではありません。試行をスコアリング、監査、学習するために必要なアーティファクトを保存することを意味します。
コーディングエージェントの場合、それはパッチ、テストログ、生成されたレポート、最終的なワークスペースの差分かもしれません。ブラウザエージェントの場合、それはスクリーンショットシーケンス、ダウンロードされたファイル、最終URL、DOMサマリーかもしれません。データ分析エージェントの場合、それはノートブック、グラフ、変換されたデータセット、評価者スコアかもしれません。安全性が重要なワークフローの場合、拒否されたアクションと承認リクエストが含まれる場合があります。
人間によるレビューは、サンドボックス化された実験が外部システムに影響を与える境界に属します。良いレビューポイントは次のとおりです：
- サンドボックスから本番ワークスペースにファイルをエクスポートする前。
- メッセージを送信したり、チケットをオープンしたり、ページを公開したり、コードをデプロイしたりする前。
- 新しいネットワーク、ファイルシステム、シークレットの権限を付与する前。
- 学習されたポリシーをライブユーザーや顧客データに使用する前。
- 報酬ハッキング、プロンプトインジェクション、環境の悪用を示唆する繰り返しの失敗の後。
レビューはループに設計されるべきであり、エージェントが広範なアクセス権を得た後に後付けで追加されるべきではありません。サンドボックスは、提案されたアクション、サポートアーティファクト、試行履歴を検査しやすくする必要があります。
Novita Agent Sandboxの位置づけ
Novita Agent Sandbox は、コード実行、ファイルシステム操作、ブラウザスタイルのワークフロー、長時間実行タスクのために分離された環境を必要とするAIエージェント向けのクラウドサンドボックスランタイムです。現在のNovitaドキュメントは、コマンド実行、ファイル操作、テンプレート、スナップショット、一時停止と再開、バックグラウンド実行、SDK/CLIライフサイクル管理などのサンドボックス機能について説明しています。
RLスタイルのエージェント作業では、これらのプリミティブはコアとなる環境要件に対応します：
| RLエージェント要件 | 探すべきサンドボックスプリミティブ |
|---|---|
| 各試行を既知のベースラインから開始する | テンプレートまたはスナップショットベースのサンドボックス作成 |
| ホストアクセスなしでエージェントアクションを実行する | 分離されたコマンド実行とスコープ化されたファイルシステム |
| 選択された出力のみを保存する | ファイル操作とアーティファクトエクスポートポリシー |
| 長時間実行評価をサポートする | バックグラウンド実行、一時停止/再開、タイムアウトポリシー |
| 失敗したまたは驚くべき試行をデバッグする | ログ、コマンド結果、ファイル差分、キャプチャされたアーティファクト |
| 評価をアプリロジックから分離する | 各実行を中心としたSDK/CLIライフサイクル制御 |
製品の境界を明確に保ちます。Novita Agent Sandboxは、評価とRLエージェントインフラストラクチャをサポートできるランタイムプリミティブを提供しますが、ビルダーは依然として報酬関数、環境テンプレート、ツールポリシー、ネットワークルール、テレメリスキーマ、シークレット処理、人間による承認ワークフローを定義します。サンドボックスプロバイダーを自律エージェントの完全な安全性レイヤーとして扱わないでください。
RLエージェントサンドボックスチェックリスト
反復的なRLスタイルの試行または大規模な評価バッチを実行する前に、このチェックリストを使用してください：
| エリア | 回答すべき質問 |
|---|---|
| ベースライン | 各試行はどのテンプレート、スナップショット、データセット、依存関係セット、評価者バージョンから開始されますか？ |
| リセット | 試行間でどの状態がワイプされ、どの状態が意図的に保持されますか？ |
| 決定論 | どのシード、パッケージバージョン、モデル設定、フィクスチャが固定されていますか？ |
| ファイルシステム | どのパスが読み取り専用、書き込み可能、隠し、またはエクスポートされますか？ |
| ネットワーク | 出力はブロック、許可リスト、プロキシ、ログ記録、またはタスク固有ですか？ |
| リソース | CPU、メモリ、ディスク、プロセス、タイムアウト、同時実行数の制限は何ですか？ |
| ツール | エージェントはどのコマンド、パッケージマネージャー、ブラウザ、APIを呼び出すことができますか？ |
| 報酬 | 報酬を支える証拠は何ですか？スコアはキャプチャされたアーティファクトから説明できますか？ |
| テレメトリ | コマンド、ファイル変更、ネットワーク呼び出し、出力、評価者結果は、シークレットを保存せずにログ記録されていますか？ |
| アーティファクト | どの出力がコピーアウト、保持、編集、または破棄されますか？ |
| 人間によるレビュー | どのアクションが、サンドボックスを出るか外部システムに触れる前に承認を必要としますか？ |
1つの行が不明確な場合は、ループをスケーリングする前にそれを修正してください。小さなあいまいさは、数百または数千の試行にわたって倍増すると高価になります。
FAQ
RLエージェントサンドボックスとは何ですか？
RLエージェントサンドボックスは、エージェントがアクションを実行し、フィードバックを受け取り、試行間で既知の環境状態にリセットできる分離されたランタイムです。実験を再現可能に保ち、副作用を封じ込め、スコアリングとデバッグのための証拠をキャプチャするために使用されます。
なぜリセット可能性が強化学習エージェントにとって重要なのですか？
リセット可能性は、ある試行のファイル、プロセス、キャッシュ、ブラウザセッション、インストールされたパッケージが次の試行に影響を与えるのを防ぎます。信頼性の高いリセットがなければ、報酬の変化は、より良いエージェントの動作ではなく、隠れた環境ドリフトを反映している可能性があります。
RLエージェントサンドボックスは自律エージェントを安全にしますか？
いいえ。サンドボックスはランタイムの爆発半径を減らし、副作用を観察しやすくすることができますが、完全な安全性の保証ではありません。ビルダーは依然として、スコープ化された権限、ネットワークポリシー、シークレット処理、報酬設計、監視、および機密性の高い外部アクションに対する人間によるレビューを必要とします。
すべてのRL試行は新しいサンドボックスから開始すべきですか？
常にそうとは限りません。新しいサンドボックスは独立した評価に最適です。スナップショットの復元は、高価なセットアップ後により効率的です。長時間実行サンドボックスは、インタラクティブまたはカリキュラムスタイルの作業に適合できますが、永続的な状態は明示的であり、ログに記録されるべきです。
RLエージェントサンドボックスは何をログに記録すべきですか？
試行ID、サンドボックスベースライン、コマンド、ツール呼び出し、終了コード、ファイル変更、ネットワーク宛先、リソース使用量、評価者入力、報酬出力、承認されたアーティファクトをログに記録します。デフォルトでは、生のシークレット、不要な顧客データ、または未レビューの完全なファイル内容をログに記録しないでください。
