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

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

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

コーディングエージェントサンドボックスは、AIシステムがコードを検査し、ファイルを編集し、ターミナルコマンドを実行し、ポリシーが許可する場合に依存関係をインストールし、テストを実行し、プレビューサーバーを起動し、レビュー可能な差分を返すことができる、隔離されたランタイムです。重要なのは、サンドボックスが単なるモデルのチャットラッパーではないということです。サンドボックスは作業の運用境界です。モデルがアクションを提案し、サンドボックスがワークスペース、ツール、権限、証跡を強制します。

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

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

これが、「サンドボックスでCodexを実行する」という概念が、単なるローカルCLIの習慣ではなく、インフラストラクチャパターンとして理解されるべき理由です。Codex CLI自体は、ターミナルワークフローを通じて実行されるコーディングエージェントとして文書化されており、チーム、CIシステム、または製品ワークフローで運用する場合、周囲の実行環境が制御プレーンとなります。NovitaのファーストパーティCodexエージェントテンプレートは、このパターンを概念的な可能性として残すのではなく、Novita Sandbox内で具体的なものにしています。

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

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

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

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

コーディングエージェントサンドボックスでのターミナルアクセスはどうあるべきか？

ターミナルは、コーディングエージェントが運用上有用であり、かつ運用上リスクがある場所です。テストの実行、アセットのビルド、生成されたファイルの検査、ローカルサーバーの起動、障害の診断が可能です。また、ファイルの削除、環境変数の漏洩、予期しないインストールスクリプトの実行、大量のコンピューティングリソースの消費も可能です。

優れたターミナルモデルには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差分、テスト出力、生成されたアーティファクト、プレビューURLをキャプチャします。
7. プルリクエストを開くか、パッチを人間のレビュー担当者に渡します。
8. 保持ポリシーに従ってワークスペースを破棄またはアーカイブします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プレビュー処理には独自のルールが必要です。レビューに必要なサービスとポートのみを公開します。Webアプリを起動するサンドボックスは、ワークスペースへの広範なネットワークアクセスではなく、スコープ付きのプレビューURLをレビュー担当者に提供する必要があります。

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

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

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

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

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

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

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

Novita Agent Sandboxは、コード実行、ブラウザ自動化、コンピュータ使用スタイルのワークフロー、データ分析、評価、長時間実行エージェントワークフローが分離されたランタイムを必要とするエージェントインフラストラクチャ向けに設計されています。Novita Agent Sandboxのドキュメントでは、この製品を、SDKおよびCLIパスを備えたエージェントワークロードを実行するためのステートフル環境として説明しており、サンドボックスのライフサイクル、ファイル、コマンド、ブラウザセッション、および関連するワークフロープリミティブを操作できます。Novitaはまた、ファーストパーティのCodexエージェントテンプレートを文書化しており、これは「サンドボックスでCodexを実行する」というアイデアを具体的なセットアップ詳細とともにリリースされたワークフローに変えるため重要です。

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

ファーストパーティのCodexテンプレートが実際に何を変えるか

新しいCodexテンプレートはポリシーの必要性を取り除くわけではありませんが、プロダクション志向のCodexワークフローがこの記事で前述した制御にどのようにマッピングされるかを明確にします。

• codex exec は、純粋に対話型のターミナルセッションよりも、キューイングされたジョブ、エージェントオーケストレーター、レビュー可能なタスク実行に適した非インタラクティブ実行モードを提供します。
• --full-auto は、サンドボックス自体が信頼できる承認境界である場合にのみ意味があります。言い換えれば、ファイルアクセス、ネットワーク出力、リポジトリスコープ、クリーンアップがCodexの周りのランタイムによってすでに制約されている場合、自動承認を正当化するのが容易になります。
• --skip-git-repo-check はブートストラップタスクに便利ですが、実際のエンジニアリング作業のためのより強力なパターンは、特定のリポジトリをサンドボックスにクローンし、その制御されたチェックアウトからCodexを実行することです。
• サンドボックス内に ~/.codex/auth.json と ~/.codex/config.toml を書き込むことで、プロバイダーとモデルのカスタマイズを、開発者のラップトップから借用したものではなく、分離された環境の一部にします。
• sandbox.git.clone は、リポジトリの分離とブランチ制御に自然に適合します。タスクに必要なリポジトリのみをプルし、そのスコープ付きディレクトリでエージェントを実行し、ホストマシンをループから外します。
• --json、キャプチャされた thread_id、codex exec resume <thread_id> によるセッション再開は、永続性と監査可能性が同じものであると偽らずに長時間実行作業を処理する実用的な方法です。再開されたセッションには、明示的な保持、ログキャプチャ、所有者ルールが依然として必要です。

これが、ドキュメントとブログガイダンスの間の有用な分割です。ドキュメントは運用順序を示します。ワークフロー決定は、それらのメカニズムをより安全なパターンの証拠として扱うことです。Codexを境界のあるワークスペース内で実行し、自動承認を信頼されたサンドボックスに制限し、リポジトリ状態を意図的に保持し、再開されたセッションを不透明なエージェントメモリではなくレビュー担当者に可視化します。

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

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

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

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

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

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

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

よくある質問

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

はい。Novitaは現在、Novita Sandbox向けのファーストパーティCodexエージェントテンプレートを文書化しており、分離された環境で codex exec を実行し、リポジトリをサンドボックスにクローンし、~/.codex/ 内でCodexプロバイダー設定をカスタマイズし、キャプチャされた thread_id で以前のセッションを再開するためのリリースされたフローを提供しています。ただし、アカウントとセットアップレベルでは注意が必要です。すべてのローカルCodexワークフローが変更されずに転送されると想定するのではなく、独自の環境の正確な認証パス、リポジトリ資格情報、ランタイム制限、ポリシー制御を検証してください。

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

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

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

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

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

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

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

Novita Agent Sandboxは、コード実行、ブラウザ自動化、コンピュータ使用スタイルのタスク、データ分析、評価、長時間実行ワークフローなどのワークロード向けに分離されたエージェントランタイムを提供します。ファーストパーティのCodexテンプレートにより、このランタイムは非インタラクティブ実行、リポジトリスコープのチェックアウト、カスタムプロバイダー設定、セッション再開などのCodex固有のフローもホストできます。これらのメカニズムを、明示的なリポジトリ、コマンド、パッケージ、ネットワーク、シークレット、レビューポリシーと組み合わせて、サンドボックスが通常のエンジニアリング制御を回避するための監視されていないショートカットではなく、実行境界であり続けるようにします。

おすすめ記事

• AI生成コードのサンドボックス要件：プロダクションアプリ向け
• Claude Codeまたはマネージドエージェントを隔離されたサンドボックスで実行する
• 隔離されたサンドボックス内のMCPサーバー：ファイルシステム、シークレット、ネットワークのトレードオフ