Codexまたはコーディングエージェントをセキュアなサンドボックスで実行する

コーディングエージェントをサンドボックスで実行するには、制限されたリポジトリワークスペース、制御された端末実行パス、明示的なファイル権限、ネットワークとパッケージインストールのポリシー、分離されたシークレット、コマンドログ、アーティファクト、そしてマージやデプロイ前の高リスク変更に対する明確な承認パスを設定します。このパターンは、エージェントがCodexスタイル、IDE連携、CIトリガー、または独自の開発者プラットフォームに組み込まれている場合でも機能します。モデルは計画と編集ができますが、サンドボックスが、何に触れられるか、何を実行できるか、何を取得できるか、そしてレビュー担当者が受け取る証拠を決定します。

コーディングエージェントサンドボックスとは？

コーディングエージェントサンドボックスは、AIシステムがコードの検査、ファイルの編集、端末コマンドの実行、ポリシーが許可する場合の依存関係のインストール、テストの実行、プレビューサーバーの起動、レビュー可能な差分の返却を行える、分離されたランタイムです。これにより、開発者のマシンや本番環境への広範なアクセスは必要ありません。

重要なのは、サンドボックスは単なるモデルのチャットラッパーではないということです。それは作業のための運用境界です。モデルがアクションを提案し、サンドボックスがワークスペース、ツール、権限、証拠のトレイルを強制します。

シンプルなコードアシスタントの場合、ローカルチェックアウトと手動のコピーペーストで十分かもしれません。コマンドを実行したり、多くのステップを継続できるエージェントの場合、より強力な境界が必要です：

• 各タスクまたはセッション専用のワークスペース。
• 既知のリポジトリ状態とブランチ。
• 危険な操作に承認が必要なコマンド実行インターフェース。
• npm、pip、cargo、aptなどのパッケージインストールポリシー。
• レジストリ、ドキュメント、API、プレビューアクセスに関するネットワーク出力ルール。
• タスクにスコープされ、可能な限りログから隠されたシークレット。
• キャプチャされたstdout、stderr、終了コード、ファイル変更、生成されたアーティファクト、プレビューURL。
• マージ、デプロイ、外部リリース前のレビューゲート。

これが、「Codexをサンドボックスで実行する」を単一のCLIフラグや一つのベンダー統合ではなく、インフラストラクチャパターンとして理解すべき理由です。Codex CLI自体は、コンピュータ上でローカルに実行されるコーディングエージェントとして文書化されており、OpenAIのCodexドキュメントでは端末指向のワークフローが説明されています。チーム、CIシステム、製品ワークフローのためにその種のエージェントを運用する場合、周囲の実行環境が制御プレーンになります。

コーディングエージェントサンドボックスのアーキテクチャ

最もクリーンなアーキテクチャは、モデルループを実行境界から分離します：

レイヤー	責任	考慮すべき質問
エージェントインターフェース	ユーザーの意図を計画、ファイル編集、ツール呼び出し、レビューサマリーに変換します。	どのモデルまたはコーディングエージェントが使用されるか？プロンプト、コンテキスト、ツールスキーマはどのように管理されるか？
ワークスペースマネージャー	サンドボックスを作成し、リポジトリをチェックアウトし、ブランチを設定し、許可されたファイルをマウントします。	各タスクは分離されているか？ベースコミットは既知か？ワークスペースはリセットできるか？
端末ランナー	承認されたコマンドを実行し、結果をエージェントにストリームします。	どのコマンドが自動的に許可され、承認が必要、またはブロックされるか？
ポリシーレイヤー	ファイルシステムの範囲、シークレット、ネットワーク出力、パッケージインストール、ランタイム制限、クリーンアップを制御します。	エージェントはパッケージを取得できるか？公開インターネットにアクセスできるか？認証情報を読み取れるか？
証拠レイヤー	ログ、差分、テスト結果、プレビュー、アーティファクトを保存します。	レビュー担当者は、モデルのサマリーを信頼せずに何が起こったかを再構築できるか？
レビューゲート	マージ、公開、デプロイの前に人間または信頼された自動化ステップを要求します。	リスクのある変更は誰が承認するか？最初にどのチェックを通過する必要があるか？

実際には、単一のプラットフォームがこれらのレイヤーのいくつかを組み合わせることがあります。それでもアーキテクチャは重要です。なぜなら、製品の選択を正直に保つからです。ツールがエージェントに端末を提供しても、コマンドログ、ファイル差分、出力ポリシーを表示できない場合、プロトタイピングには便利でも、本番レビューには不十分です。

コーディングエージェントサンドボックスでの端末アクセスはどのように機能すべきか？

端末は、コーディングエージェントが運用上便利であり、同時に運用上危険になるところです。テストを実行し、アセットをビルドし、生成されたファイルを検査し、ローカルサーバーを起動し、障害を診断できます。また、ファイルを削除し、環境変数を漏洩させ、予期しないインストールスクリプトを実行し、大きな計算リソースを消費することもできます。

優れた端末モデルには3つの部分があります。

第一に、コマンドクラスを定義します。ls、sed、rg、git diff、テストステータスコマンドなどの安全な読み取り専用コマンドは、多くの場合自動的に実行できます。npm test、pytest、cargo test、npm run buildなどのビルドおよびテストコマンドはタイムアウト付きで許可される場合があります。rm -rf、git push、gh pr merge、デプロイメントCLI、パッケージ公開、データベースマイグレーション、クラウドリソースの変更などの破壊的または外部影響のあるコマンドは、明示的な承認が必要か、完全にブロックされるべきです。

第二に、結果を構造化してストリームします。エージェントとレビュー担当者は、コマンド、作業ディレクトリ、開始時間、終了コード、stdout、stderr、タイムアウト状態、出力の切り捨てポリシーを確認できる必要があります。端末のスクリーンショットだけでは不十分です。システムは機械読み取り可能なログを保存する必要があります。

第三に、長時間実行セッションを意図的に処理します。コーディングエージェントは、バックグラウンドの開発サーバー、ウォッチャー、ブラウザ自動化プロセス、統合テストスタックを必要とすることがよくあります。長時間実行プロセスは、ハンドルを持つリソースとして扱います：開始し、ログをストリームし、必要なプレビューポートのみを公開し、クリーンアップ中に停止します。バックグラウンドプロセスをチャットセッションの追跡されない副作用にしてはいけません。

エージェント変更のためのリポジトリ分離とブランチ制御

リポジトリの状態は、レビュー可能なコーディングエージェントワークフローのバックボーンです。エージェントは、ユーザーが明示的にそのモードを選択しない限り、不明なローカル編集がある曖昧なフォルダで作業すべきではありません。

チームワークフローでは、既知のリポジトリURL、ベースブランチ、コミットSHAから各タスクを開始します。タスクブランチまたはデタッチされたワークスペースを作成します。ユーザーの変更をエージェントの変更から分離し、レビューの前に正確な差分をキャプチャします。サンドボックスが永続セッションをサポートする場合、ワークスペースを意図的に永続化します。偶発的なプロセス状態に依存してはいけません。

デフォルトのパターンは次のようになります：

1. task-123用に分離されたワークスペースを作成する。
2. main@<base_sha> でリポジトリをチェックアウトする。
3. ブランチ agent/task-123 を作成する。
4. ポリシーに従って依存関係のインストールを実行する。
5. エージェントが検査、編集、テスト、反復できるようにする。
6. git diff、テスト出力、生成されたアーティファクト、プレビューURLをキャプチャする。
7. プルリクエストを作成するか、パッチを人間のレビュー担当者に渡す。
8. 保持ポリシーに従ってワークスペースを破棄またはアーカイブする。

重要な詳細はステップ6です。有用なコーディングエージェントは「修正しました」と言うだけではありません。変更されたファイル、各変更の理由、実行された検証、失敗したこと、未検証のままのものを返します。

サンドボックス化されたコーディングエージェントのためのコマンド、パッケージ、ネットワークポリシー

パッケージインストールは、コーディングエージェントサンドボックスの最も難しい部分の1つです。多くの実際のタスクは依存関係を必要とします。また、多くのサプライチェーンインシデントも依存関係の取得、インストール後のスクリプト、不透明なバイナリから始まります。

実用的なポリシーは「パッケージを決してインストールしない」ではありません。「既知のパスを通じて、ログとスコープを使用してのみパッケージをインストールする」です。

制御	実用的な実装
パッケージマネージャー	言語とリポジトリタイプに基づいて、どのパッケージマネージャーが利用可能かを決定します。
レジストリアクセス	承認されたレジストリを許可し、タスクに必要ない場合は任意のパッケージソースをブロックします。
ロックファイル	既存のロックファイルと再現可能なインストールコマンドを優先します。
インストール後スクリプト	ライフサイクルスクリプトが自動的に実行できるか、承認が必要かを決定します。
システムパッケージ	apt、brew、OSパッケージインストールは、プロジェクト依存関係インストールよりも高リスクとして扱います。
キャッシュ	速度と再現性が必要な場合は、制御されたパッケージキャッシュを使用します。
ロギング	パッケージ名、バージョン、レジストリURL、可能な場合はチェックサム、インストール出力を保存します。

ネットワークポリシーも同様に明示的であるべきです。コーディングエージェントは、公開ドキュメントの読み取り、ステージングAPIの呼び出し、パッケージのダウンロード、ローカルプレビューの公開を必要とする場合があります。これらは無制限のインターネットアクセスとは異なります。パッケージの取得、ウェブブラウジング、API呼び出し、ウェブフック配信、プレビューイングレスを分離します。製品が機密コードやデータを扱う場合、DNS、プロキシログ、レジストリミラーがHTTPトラフィックと同じポリシーでカバーされているかどうかを確認します。

エージェントワークスペースのシークレット、ログ、監査証跡

シークレットは、最小限の有用な表面にスコープされるべきです。コーディングエージェントは通常、本番環境の認証情報を必要としません。読み取り専用のGitトークン、パッケージレジストリトークン、ステージングAPIキー、プレビューデプロイメントトークンが必要になる場合があります。それぞれタスクにスコープされ、可能な限り時間制限があり、それを必要としないコマンドでは利用できないようにします。

タスクが本当に必要としない限り、エージェントが読み取れるファイルにシークレットを配置しないようにします。ブローカーアクセスを優先します：サンドボックスは操作を実行できますが、モデルは生の認証情報を見ません。環境変数が必要な場合、ログは既知のシークレットパターンを難読化し、レビューアーティファクトには完全な環境ダンプを含めないようにします。

監査証跡については、最終パッチ以上のものを保存します：

• ユーザーリクエストとタスクメタデータ。
• リポジトリURL、ベースコミット、ブランチ、最終コミットまたは差分。
• リクエストされた、承認された、ブロックされた、実行されたコマンド。
• コマンドの出力、終了コード、タイムアウト。
• プラットフォームがキャプチャできる場合のファイル読み取りと書き込み。
• ポリシーがサポートするレベルのネットワークおよびパッケージ取得記録。
• プレビューURLと生成されたアーティファクトのパス。
• 人間の承認とマージの決定。

これは官僚主義ではありません。レビュー担当者が実際の修正ともっともらしいストーリーを区別する方法です。

マージ前の差分、プレビュー、レビューゲート

コーディングエージェントからの最も有用な出力は、レビュー可能な変更セットです。つまり、サンドボックスは、慎重なエンジニアがプルリクエストから期待するのと同じアーティファクトを生成する必要があります：

• 焦点を絞った差分。
• 実行されたテストまたはビルドコマンド。
• 残っている障害。
• UIや生成されたアセットが変更された場合のスクリーンショット、プレビューURL、ダウンロード可能なファイル。
• 意図された動作変更の短い説明。

組織がその特定のリポジトリとリスクレベルに対して別途の信頼できる自動化ポリシーを構築していない限り、最終的なマージまたはデプロイは人間の制御ゲートの背後に置きます。変更が認証、課金、データアクセス、ネットワークコール、インフラストラクチャ、依存関係バージョン、生成されたマイグレーション、ユーザーに表示されるコンテンツに影響する場合、人間のレビューは特に重要です。

プレビューの取り扱いには独自のルールがあります：レビューに必要なサービスとポートのみを公開します。ウェブアプリを起動するサンドボックスは、レビュー担当者にスコープされたプレビューURLを提供し、ワークスペースへの広範なネットワークアクセスを許可してはいけません。

長時間実行エージェントセッションのクリーンアップとリセット戦略

すべてのサンドボックスにはライフサイクルが必要です。それがないと、長時間実行コーディングエージェントインフラストラクチャは、古いワークスペース、漏洩したログ、まだ実行中のプロセスの山になります。

短いタスクには、エフェメラルモデルが適しています：サンドボックスを作成し、ジョブを実行し、アーティファクトを抽出し、破棄します。大規模なタスクには、永続性が価値がある場合があります：エージェントは一時停止し、レビューを待ち、同じブランチから再開するか、レビューセッション中に開発サーバーを実行し続ける必要があるかもしれません。永続性は、有効期限、所有者、保持ルールを持つ明示的な製品機能であるべきです。

クリーンアップを定義します：

• バックグラウンドプロセスと開いているポート。
• 一時ファイルとビルド出力。
• パッケージキャッシュとダウンロードされたアーカイブ。
• タスクスコープのシークレット。
• ログとアーティファクト。
• 置き換えられたブランチまたはワークツリー。

リセットも同様に重要です。レビュー担当者は、ベースコミットまたは最終ブランチからエージェントの検証を再実行できる必要があります。結果が長時間実行セッション内の目に見えない状態にのみ依存している場合、そのワークフローは信頼しにくいです。

Novita Agent Sandboxがこのワークフローに適合する場所

Novita Agent Sandbox は、コード実行、ブラウザ自動化、コンピュータユーススタイルのワークフロー、データ分析、評価、長時間実行エージェントワークフローが分離されたランタイムを必要とするエージェントインフラストラクチャ向けに設計されています。Novita Agent Sandboxのドキュメント では、製品をエージェントワークロードを実行するためのステートフル環境として説明しており、サンドボックスのライフサイクル、ファイル、コマンド、ブラウザセッション、関連するワークフロープリミティブを操作するためのSDKおよびCLIパスを提供しています。

既にNovita AIモデルAPIを使用しているチームにとって、サンドボックスレイヤーはモデル推論とアクション実行の間のギャップを減らすことができます。モデルは推論し、ツールを呼び出し、コード変更を計画できます。サンドボックスは、それらのアクションが実行、ログ記録、プレビュー、レビューされる分離されたワークスペースを提供できます。

ワークフローを設計する際には、保守的な製品境界を使用します：

• Novita Agent Sandboxを実行環境として扱い、包括的なセキュリティ保証としては扱わない。
• シークレット、パッケージインストール、出力、公開アクションを独自のポリシーの背後に保つ。
• 現在のSDK、CLI、価格、アカウント制限の詳細は、Novitaのドキュメントから確認してから、本番自動化にハードコードする。
• 本番でサンドボックスに依存する前に、分離境界、サードパーティエージェントの互換性、コンプライアンス要件を独自のポリシーに対して評価する。

この分離により、エージェントレイヤーが変更されても実装ガイダンスが有用になります。Codexスタイルのエージェント、内部コーディングエージェント、ブラウザエージェント、評価ワーカーを使用しながら、同じサンドボックス制御の質問を維持できます。

コーディングエージェントサンドボックス実装チェックリスト

コーディングエージェントサンドボックスをプロトタイプを超えて移行する前に、このチェックリストを使用します。

領域	最低限の本番質問
ワークスペース	各タスクにスコープされたファイルシステムと既知のリポジトリベースコミットが与えられていますか？
ブランチング	エージェントの変更は、レビュー担当者が検査できるブランチまたはパッチに分離されていますか？
端末	コマンドは作業ディレクトリ、出力、終了コード、タイムアウトとともに記録されていますか？
承認	どのコマンドが自動的に実行され、承認が必要で、ブロックされますか？
パッケージ	依存関係のインストールは再現可能でログに記録されていますか？
ネットワーク	出力は、パッケージ取得、ドキュメントブラウジング、API呼び出し、プレビューアクセスによって分離されていますか？
シークレット	認証情報はタスクにスコープされ、ログから難読化されていますか？
プレビュー	プレビューポートは明示的で、簡単にシャットダウンできますか？
アーティファクト	生成されたファイル、スクリーンショット、レポート、ログはレビューに添付されていますか？
永続性	セッションの一時停止/再開は意図的で、所有者と有効期限がありますか？
クリーンアップ	プロセス、ポート、一時ファイル、シークレット、古いワークスペースは削除されていますか？
レビュー	リスクのある変更に対して、人間がマージ、公開、デプロイを承認しますか？

現在のセットアップがこれらの質問のいくつかに答えられない場合は、ワークフローをプロトタイプレーンに保ちます。エージェントは依然として有用かもしれませんが、広範なリポジトリ、ネットワーク、認証情報へのアクセスを許可すべきではありません。

FAQ

Codex自体をクラウドサンドボックス内で実行できますか？

概念的には可能です。端末コーディングエージェントは、環境がエージェントに必要なオペレーティングシステム、認証パス、端末I/O、ファイルシステムアクセス、ネットワークアクセスをサポートしている場合、分離されたワークスペース内で実行できます。サンドボックスプロバイダーとエージェントプロバイダーがあなたの正確なセットアップに対してそれを文書化していない限り、公式な統合や完全な互換性を想定しないでください。

Dockerはコーディングエージェントサンドボックスに十分ですか？

Dockerはローカル開発、CIジョブ、再現可能な環境に有用ですが、「十分かどうか」は脅威モデルに依存します。カーネルを共有しているもの、存在するファイルマウント、ネットワーク出力がどのように制御されているか、シークレットがコンテナに露出されているか、エスケープや依存関係の侵害がどのように処理されるかを尋ねます。機密性の高いワークロードの場合、セキュリティチームはより強力な分離境界とより厳格な出力制御を評価することがよくあります。

コーディングエージェントはインターネットアクセスを持つべきですか？

タスクに必要な場合にのみ、そして説明可能なポリシーを通じてのみです。ドキュメント検索、パッケージレジストリアクセス、ステージングAPI呼び出し、任意のブラウジングは異なる権限です。エージェントが取得したものをログに記録し、パッケージインストールを再現可能に保ち、汎用コーディングセッションに本番ネットワークアクセスを与えないようにします。

エージェント生成コードをマージする前に、レビュー担当者は何を見るべきですか？

差分、実行されたコマンド、テスト/ビルド出力、依存関係の変更、生成されたアーティファクト、プレビューの動作、スキップされた検証をレビューします。認証、権限、データ処理、ネットワークコール、マイグレーション、インストールスクリプト、シークレットに特に注意を払います。

Novitaはコーディングエージェントサンドボックスにどのように役立ちますか？

Novita Agent Sandboxは、コード実行、ブラウザ自動化、コンピュータユーススタイルのタスク、データ分析、評価、長時間実行ワークフローなどのワークロード向けの分離されたエージェントランタイムを提供します。コーディングエージェントワークフローを構築する際には、明示的なリポジトリ、コマンド、パッケージ、ネットワーク、シークレット、レビューポリシーと組み合わせて使用します。

推奨記事

• NovitaのAgent Sandboxでコーディングエージェントを構築する
• エージェントサンドボックスが安全でスケーラブルなAIイノベーションを支える方法
• CodexをNovita AIモデルで使用する方法