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

コーディングエージェントをサンドボックスで実行するには、スコープ付きのリポジトリワークスペース、制御されたターミナル実行パス、明示的なファイル権限、ネットワークとパッケージインストールポリシー、分離されたシークレット、コマンドログ、アーティファクト、そしてマージまたはデプロイ前の高リスク変更に対する明確な承認パスをエージェントに与えます。このパターンは、エージェントが 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. タスク-123 用の分離されたワークスペースを作成。
2. main@<base_sha> でリポジトリをチェックアウト。
3. ブランチ agent/task-123 を作成。
4. ポリシーに従って依存関係インストールを実行。
5. エージェントが検査、編集、テスト、反復を行えるようにする。
6. git diff、テスト出力、生成アーティファクト、プレビュー 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 AI モデル API を使用しているチームにとって、サンドボックス層はモデル推論とアクション実行の間のギャップを減らすことができます。モデルは推論し、ツールを呼び出し、コード変更を計画できます。サンドボックスは、それらのアクションが実行され、記録され、プレビューされ、レビューされる隔離されたワークスペースを提供できます。

ワークフローを設計する際は、控えめな製品境界を使用します。

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

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

おすすめ記事

• AI 生成コード向けサンドボックス要件（プロダクションアプリ向け）
• 隔離サンドボックス内の MCP サーバー：ファイルシステム、シークレット、ネットワークのトレードオフ
• Firecracker を AI エージェントサンドボックスに使用する：利点、制限、評価の質問
• サンドボックス化された Python と制御されたパッケージアクセスで AI データアナリストを構築する