AIエージェントの実行サンドボックス：アーキテクチャ、リスク、および実世界のパターン

ホーム » Python » AIエージェントの実行サンドボックス：アーキテクチャ、リスク、および実世界のパターン

AIエージェントにコードを実行させたり、ファイルを操作させたり、ブラウザを開かせたり、APIにアクセスさせたりすることで、AIエージェントは単なる高度なオートコンプリート機能から、マシン上でroot権限を持つジュニアエンジニアに近い存在へと進化する。 その特別な力こそが、エージェントが魔法のように感じられる理由であり、同時に危険な理由でもある。設定ミスやバグのあるエージェントは、データベースを消去したり、APIキーをインターネットに漏洩させたり、何が問題だったのかを「理解」しないまま、不具合のあるビルドを本番環境にデプロイしたりする可能性がある。

本当の問題はもはや「モデルの精度はどれくらいか？」ではなく、「モデルが間違っていたり、騙されたり、過信したりした場合に、どこまで到達できるのか？」ということだ。 エージェント向けの実行サンドボックスは、エンジニアリング上の解決策です。エージェントがコードの読み書き、シェルの実行、サーバーの起動、ブラウザの起動などを実行できる、厳密にスコープが限定された環境を提供します。ファイルシステム、ネットワーク、認証情報、ライフサイクルは厳密に制御できます。モデルを信頼するのではなく、影響範囲を制限するのです。

コーディングエージェントに専用の実行サンドボックスが必要な理由

Claude Code、LangChain Deep Agents、Dockerのコーディングサンドボックスなどの最新のコーディングエージェントや類似ツールは、もはやファイルアクセス機能を備えた単純なチャットボットのようには動作しません。 それらはリポジトリ全体を読み込み、ファイルを編集し、シェルコマンドを実行し、Gitを操作し、Dockerビルドを開始し、外部APIと通信し、さらにはブラウザを介してデスクトップのような環境全体を操作します。ベンダーのドキュメントには、この点について非常に明確に記載されています。Claude Codeは、コードベースを検査し、編集を行い、コマンドを実行できるアジャイル開発アシスタントとして紹介されています。LangChain Deep Agentsは、サンドボックスバックエンドを、シェルコマンドを実行し、ファイルシステムを管理し、分離のためにサブエージェントに作業を委任する場所として扱います。

この能力セットこそが、これらのエージェントを有用な存在にすると同時に、運用上のリスクも高める要因となっている。 モデルが実行可能になったら pytestnpm パッケージのインストール、ブランチのオープン、ビルドの失敗のデバッグなどを行う際、デプロイ スクリプトの変更、破損したイメージのプッシュ、CI 設定の調整、HTTP リクエストによるトークンの漏洩まで、ツールを数回呼び出すだけで済みます。OpenAI のエージェントの安全性に関するガイダンスと NIST のエージェント ハイジャックに関する取り組みは、いずれもプロンプトの挿入を強調しています。ファイル、Web ページ、ログに隠された悪意のある指示によって、意図していなかったアクションにエージェントが静かに誘導される可能性があります。

多くのチームは、あらゆるコマンドに対して「承認を求める」という単純なフローから始めますが、すぐにそれが拡張性に欠けることに気づきます。 Anthropicは、ユーザーがClaude Codeの権限プロンプトの93%を承認したことを公表しました。DockerのClaudeサンドボックスは、Claude Codeを起動する際に、 --skip-permissions デフォルトでは、大量のダイアログを表示するのではなく、実行時分離に頼る。特に複数のエージェントを並行して実行し、多くのプロンプト間でコンテキストを切り替える場合、ユーザーは承認疲れを感じる。そうなると、確認ダイアログは信頼できる制御手段ではなく、単なる儀式になってしまう。

実行サンドボックスは、セキュリティモデルを「ユーザーがすべてのプロンプトを読み込むことを信頼する」から「一部のコマンドが誤っていたり、悪意のあるものであったりすると想定し、それらが引き起こす損害を制限する」へと移行させる。 サンドボックスは、エージェントがプロンプトインジェクションによって操作されている場合や、単にミスを犯している場合であっても、エージェントがアクセスできるファイル、プロセス、ネットワーク、および機密情報の範囲を厳密に区切る境界となる。

また、基本的な開発者エクスペリエンスの観点から言えば、エージェントには実際に作業するための十分なスペースが必要だという点もある。 粗雑な制限で過度にサンドボックス化すると、ビルドやテストといった単純なコマンドでさえ、分かりにくい権限エラーで頻繁に失敗します。CursorがmacOS/Linux/Windows上で展開しているシステムや、Cloudflare、Heroku、Google Cloudがホスト型ワークロード向けに提供しているシステムなど、優れたシステムは、エージェントに厳密な境界内で「本物のコンピュータ」のような感覚を与えることを目指しています。

エージェントの実行サンドボックスが本当に隔離するもの

適切なエージェントサンドボックスとは、単に「コードを実行する別の場所」ではなく、爆発範囲を定義する明確な境界の集合体である。 Docker Sandboxes、Cloudflare Sandboxes、GKE Agent Sandbox、Freestyle VMs、E2B、Daytonaといった主要なプラットフォームで繰り返し見られる主な制限事項を5つ挙げることができます。

まず、ファイルシステムの境界について：エージェントは、ユーザーが意図的に共有したワークスペースのみを認識できる必要があります。 LangChainのドキュメントでは、サンドボックスはエージェントがホストファイルにアクセスできないようにする障壁として説明されています。Dockerのサンドボックスモデルでは、マイクロVMは明示的にマウントされたプロジェクトディレクトリしか認識できないことが明確に示されています。そのツリー外にあるものはすべて非表示または読み取り専用であるため、エージェントは気軽にファイルを読み取ることができません。 ~/.ssh またはシステム設定を書き換える。

第二に、プロセスとカーネルの境界：エージェントのワークロードは、ホストの生のカーネルやプロセス テーブルを共有すべきではありません。 Dockerのサンドボックスアーキテクチャは、各環境を独自の空間に隔離します。 microVMとLinuxカーネルFirecracker（複数のプロバイダが内部で使用）は、そのVM境界を最初の分離レイヤーとして扱い、その上にseccomp、名前空間、cgroups、jailのような制限を追加します。GoogleのGKE Agent Sandboxは、gVisorを使用してKubernetes内で同様の効果を実現します。「監視」レイヤーがシステムコールを傍受し、基盤となるノードへのアクセスを仲介します。

第三に、ネットワーク境界：ネットワークポリシーがなければ、サンドボックス化されたエージェントは依然としてデータ漏洩装置である。 現在、ほとんどの本格的なプラットフォームは、デフォルトで「すべての送信を拒否」する機能を備えています。例えば、Docker Sandboxは、明示的に許可されるまでHTTP/HTTPSをブロックし、生のTCP/UDP/ICMPを遮断し、例外を設定しない限りプライベートIPアドレス範囲やlocalhostへのトラフィックを許可しません。CloudflareやGoogleなどは、送信呼び出しがプログラム可能なプロキシを経由するようにサンドボックスを設計しており、そこで認証を挿入したり、宛先をフィルタリングしたり、使用状況を監査したりできます。

第四に、認証情報の境界：サンドボックス内で生の機密情報を公開することは、最終手段として扱うべきであり、デフォルトとして扱うべきではない。 Dockerの設計では、HTTP呼び出しをホスト側のプロキシ経由でルーティングし、トークンやAPIキーをリクエストに添付することで、それらの生の値をVM内に配置することなく処理します。Cloudflare Sandboxesも同様に、環境変数ではなくネットワーク層で認証情報を注入します。そのため、プロンプトの注入によってエージェントが「すべての環境変数を表示する」ように誘導されたとしても、盗むべき重要な情報は何も得られません。

5つ目はライフサイクル境界です。エージェントワークスペースは単一のコマンドのためだけに存在することはほとんどなく、開始、一時停止、スナップショット、フォーク、およびティアダウンのための明示的なセマンティクスが必要です。 E2Bは、単一のサンドボックスのライフサイクルを超えて存続できる、分離されたファイルシステム、バックグラウンドコマンド、およびボリュームを公開します。Freestyleは、スナップショットとインメモリ状態の分岐による、非常に高速なVMの起動、サスペンド、および再開に重点を置いています。Daytonaは、スナップショットベースのサンドボックスに加え、自動停止、自動アーカイブ、および自動削除ポリシーを追加することで、一部の環境を長期間維持し、他の環境を使い捨てとして扱うことができます。

ファイルシステム、プロセス、ネットワーク、認証情報、ライフサイクルという5つの軸を理解すれば、サンドボックス製品ページはすべて、一連のトレードオフとして読み解くことができる。 ホストマウントは大きいものの、厳格なエグレスルールを持つ共有カーネルコンテナは、ホストマウントはなくネットワークがより寛容なマイクロVMとは大きく異なります。依存関係のインストール、ブラウザの実行、Dockerイメージのビルドなどを行うコーディングエージェントにとっては、VMスタイルのより強力な境界の方が安全なデフォルト設定となる傾向があります。

macOS、Linux、Windows 上でのローカルコーディングエージェントのサンドボックス化

開発者用ノートパソコンでは、常に高負荷なマイクロVMサンドボックスを起動できるとは限らないため、チームはOSネイティブな分離に関して工夫を凝らす必要があった。 Cursorが最近取り組んだローカルサンドボックスに関する取り組みは、macOS、Linux、Windowsそれぞれの特性に合わせてカスタマイズしつつ、エージェント層には統一されたAPIを維持するという点で、優れた事例と言えるでしょう。

macOSでは、アプリサンドボックス、汎用コンテナ、完全な仮想マシン、そして長らく使われてきたものの「非推奨」となったSeatbeltという技術など、いくつかの選択肢が検討された。 App Sandboxでは、エージェントが実行する可能性のあるすべてのバイナリに署名する必要があり、複雑さが劇的に増大し、生成されたバイナリに推移的な信頼を与える必要さえありました。LinuxコンテナではmacOSユーザーはLinux専用のバイナリしか使用できなくなり、本格的な仮想マシンでは起動時の遅延やメモリオーバーヘッドが許容範囲を超え、対話型のコーディング作業には不向きでした。

シートベルトは、 sandbox-exec古さにもかかわらず、結果的に実用的な選択肢となった。 これにより、きめ細かなポリシー言語でプロセスツリー全体を制限したサンドボックスプロファイルの下でコマンドを実行できます。特定のシステムコールをホワイトリストに追加したりブロックしたり、対象のファイルやディレクトリへの読み取り/書き込み権限を制限したりできます。Cursor は、ワークスペースと管理者設定、およびユーザーの設定に基づいて、実行時にこれらのポリシーを動的に生成します。 .cursorignoreそのため、無視された経路はサンドボックス内で立ち入り禁止となる。

Linuxでは、カーネルはシステムコールフィルタリングのためのseccompやファイルシステム制限のためのLandlockといった適切なプリミティブを公開するが、その構成はユーザー空間に委ねられている。 リポジトリ固有の無視をサポートしていない既存のOSSラッパーに依存するのではなく、 .cursorignoreCursorは、Landlockとseccompを直接連携させることを選択しました。seccompは危険なシステムコールを禁止し、Landlockはパスベースの読み書きルールを適用します。さらに、ユーザーワークスペースにルールを上書きすることで、無視されたファイルには完全にアクセスできなくなったり、サンドボックス化されたプロセスが読み取ったり変更したりできない保護されたコピーに置き換えられたりします。

Linuxにおける微妙な点のひとつはパフォーマンスです。無視されたすべてのファイルを再マウントまたは書き換える処理は、サンドボックスの設定において最も時間がかかる部分です。 macOS スタイルの遅延フィルタリングで、システムコール時に正確なファイルパスを確認できればこの問題は簡単に解決できるが、Linux の seccomp-bpf ではパス検査が容易ではないため、厳密な分離と起動速度の間には、実際には技術的なトレードオフが存在する。

Windowsでは、真に同等のネイティブサンドボックスを構築することは依然として困難です。なぜなら、ほとんどの分離プリミティブはブラウザ向けに最適化されており、汎用的な開発ツール向けには最適化されていないからです。 Cursorは現在、Windowsユーザー向けにWSL2内でLinuxサンドボックスを実行しており、より高度な基本機能が利用可能になるまでは、Linuxの隔離機能を利用しています。同社はMicrosoftと協力して適切な機能を公開することで、将来的にはWindowsエージェントがWSLに頼ることなく、一流のネイティブサンドボックス機能を利用できるようになることを目指しています。

これらのOS固有のアプローチに共通しているのは、その上に統一されたサンドボックスAPIが構築されている点である。 エージェントの視点から見ると、明確な機能とルールを備えた「シェルツール」が存在するだけです。しかし、その内部では、Seatbelt、Landlock/seccomp、またはWSL2ベースの隔離機能が、プラットフォームごとに異なる方法でこれらのルールを適用しています。

エージェントにサンドボックスを理解し尊重するように教える

サンドボックスは、エージェントがサンドボックス内で何が有効かを予測でき、権限昇格が必要な場合やサンドボックスから出る必要がある場合を予測できる場合にのみ役立ちます。 それは当たり前のことのように聞こえるが、実際には、コーディングエージェントを出荷するベンダーにとって、驚くほど綿密なプロンプトとツール設計の反復作業が必要だった。

多くのチームが最初にとったステップは、ツールの説明、特にシェル実行に関する説明を改善することだった。 一般的な「run_shell_command」ツールではなく、説明ではアクセス可能なリソースを明示的に示しています。コマンドがファイルシステムアクセス、Gitアクセス、ネットワークアクセス、またはユーザー設定に応じた完全オフライン環境のいずれに対応しているかが明記されています。また、必要に応じてエージェントが昇格された権限（例えば、パブリックインターネットへのアクセス）を要求する方法も記載されています。この迅速なエンジニアリング作業は非常に経験的なアプローチで行われます。チームは一般的なデプロイメントフローを実行し、モデルが機能を誤って予測している箇所を観察し、ツールの説明を調整して、このプロセスを繰り返します。

次に、「Cursor Bench」などの内部ベンチマークや同様の評価スイートを使用して、サンドボックスを使用した場合と使用しない場合のエージェントのパフォーマンスを比較します。 初期の障害モードの一つに、非常に一貫性のあるものがありました。エージェントは、サンドボックスの制限に引っかかっていることに気づかず、同じ失敗した端末コマンドを何度も繰り返し実行してしまうのです。コマンドが失敗した理由が明確に示されないため、モデルはパターンを学習できませんでした。

解決策は、サンドボックスのエラーをツールの出力に明示的に表示し、多くの場合、次に何をすべきかについてのヒントを添えることだった。 ファイルシステムやネットワークのルールによってコマンドがブロックされた場合、シェルツールは「サンドボックスによってブロックされました：このセッションではアウトバウンドネットワークアクセスが無効になっています」といった短い説明文を表示するようになり、場合によってはエージェントが管理者権限を要求する可能性があることを示唆するヒントも表示されるようになりました。この変更後、エージェントの動作は大幅に改善され、実行不可能なコマンドでループすることがなくなり、実行計画を調整するか、必要な権限を要求するようになりました。

オフラインでの評価は役立つが、全体像の一部しか示していない。 サンドボックス化がユーザーエクスペリエンスを低下させるかどうかを真に把握するため、各チームはサンドボックスのサポートを本番環境に段階的に展開し、エラー率、完了時間、フィードバックチャネルを監視してきました。実際、ベンダー各社は、互換性のあるプラットフォーム上のクエリのかなりの割合がサンドボックス内で完全に実行されるようになったと報告しています。NVIDIAのようなエンタープライズ顧客も早期導入企業の一つです。また、サンドボックス化されたエージェントは、実際のワークフローにおいて承認待ちの頻度が約40%減少し、手動レビューにかかる時間を大幅に削減すると同時にリスクも軽減しています。

今後を見据えると、「ネイティブサンドボックスエージェント」、つまり環境の制約条件に基づいて直接学習されたモデルへの関心が高まっている。 シェル、ブラウザ、ファイルシステムを抽象的なツールとして扱うのではなく、これらのエージェントは、厳密にスコープが限定されたランタイム環境で動作し、長期間実行されるスクリプトやプログラムを作成でき、「外部ネットワークへの接続禁止」や「ワークスペースは読み取り専用」といった境界条件を遵守しなければならないことを理解するだろう。このような訓練によって、エージェントは目に見えない壁にぶつかることなく、安全かつ効率的な一連の動作を計画する能力を大幅に向上させることができる。

クラウドサンドボックス：Cloudflare、Google Cloud、Herokuなど

開発者のノートパソコンの外では、多くのインフラプロバイダーが、AIエージェント向けに特化して調整されたホスト型サンドボックスの提供を競い合っている。 彼らの目標は同じだ――分離、制御、そしてパフォーマンス――だが、クラウド規模になると、そのトレードオフは少し異なって見える。

Cloudflare Containersを基盤として構築され、現在一般提供されているCloudflare Sandboxesは、エージェント向けの本格的な開発環境と遜色ない外観と操作感を目指しています。 各サンドボックスは、名前で指定する永続的で隔離されたワークスペースです。スリープ状態の場合は、必要に応じて起動します。アイドル状態の場合は、コンピューティングリソースを節約するために自動的に一時停止し、次のリクエストで再開します。開発者（またはエージェント）は、次のような型付きメソッドを介してサンドボックスとやり取りできます。 exec, gitCheckout, writeFileさらに、JavaScript/TypeScript SDK を使用することで、より多くのことが可能になります。

クラウドにおける最も厄介な問題の一つは、エージェントサンドボックス内部からの安全な認証である。 エージェントはプライベートサービスにアクセスする必要があることが多いですが、環境変数に生の認証情報が放置されているのは好ましくありません。Cloudflareはネットワークプロキシ層で認証情報を挿入し、ホストごとの送信リクエストを、セキュアストレージからトークンを添付するカスタムロジックにマッピングします。サンドボックスプロセスは実際のシークレットを見ることはありませんが、呼び出しは認証されます。この設計は、動的でID認識型の認証情報挿入をサポートし、Workersバインディングともうまく連携します。

ターミナルを多用するワークフロー向けに、CloudflareはWebSocketとxterm.jsを介して接続された、完全なPTY（擬似ターミナル）機能を追加しました。 エージェントと人間は、ライブシェルセッションを開き、プロセスを中断し、後で再接続して過去の出力を再生できます。各PTYは独自の作業ディレクトリと環境を持ち、出力はサーバー上でバッファリングされるため、再接続したクライアントは見逃したログに追いつくことができます。

Cloudflareは、生のシェルアクセスに加えて、Python、JavaScript、TypeScriptなどの言語向けに永続的な「コード実行コンテキスト」も提供しています。 多くのスニペットランナーが各フラグメントを個別に実行するのとは異なり、これらのコンテキストはJupyterノートブックのように、呼び出し間で変数、インポート、状態を保持します。エージェントは、1回の呼び出しでデータを読み込み、別の呼び出しでデータを変換し、すべてのデータを繰り返し解析および再インポートすることなく、グラフやHTMLテーブルをレンダリングできます。

Cloudflareのサンドボックスは、Web開発タスクにおいて、バックグラウンドプロセス、ヘルスチェック、およびライブプレビューURLをサポートしています。 エージェントは開始できます npm run dev バックグラウンドジョブとして、サーバーの準備が整うまでログを監視し、その後、公開プレビュー URL の背後にポートを公開します。 waitForPort() or waitForLog() エージェントが単純な準備状況ではなく実際の準備状況シグナルに基づいて行動を順序付ける sleep(2s) 推測します。

イベント駆動型ワークフローは、Linuxのinotifyメカニズムに支えられたファイル監視プリミティブによって強化される。 エージェントは以下の変更を購読できます /workspace/src TypeScript ファイルが変更されると、テストやビルドを自動的に再実行します。これは、人間の開発者が頼りにしているフィードバック ループと同じですが、次のような API を介してエージェント ネイティブになっています。 sandbox.watch() およびサーバー送信イベントストリーム。

ライフサイクルのループを完結させるため、Cloudflareは真のスナップショット、つまりR2ストレージから数秒で復元可能なVMレベルの状態キャプチャを展開しています。 スナップショットは、ファイルシステムの状態、OS構成、インストール済みの依存関係、およびデータファイルを永続的に保持します。将来のバージョンでは、ライブメモリの状態も復元され、即座に再開できるようになります。エージェント（またはオーケストレーター）は、チェックポイントやファンアウトシナリオのためにプログラムでスナップショットをトリガーし、同じスナップショットから複数のサンドボックスをフォークして、並列の仮説を個別に検証できます。

価格設定に関して、Cloudflareは「アクティブCPUのみ」モデルに移行しました。つまり、エージェントがLLM（ローカルリソース管理）を待機している間のアイドル時間ではなく、実際に使用されたCPUサイクルに対して課金されます。 「ライト」インスタンスと大規模インスタンスの両方で同時実行数の上限が大幅に引き上げられているため、スリープ状態のコンテナに費用をかけることなく、多数のエージェントを運用することが可能になります。

一方、Google CloudのGKE Agent Sandboxは、KubernetesおよびgVisorと深く統合されている。 このアイデアは、エージェントワークロードを独自のクラスター内の分離されたポッドで実行できるようにすることです。GKEクラスターを作成し（AutopilotではgVisorが自動的に有効になりますが、Standardクラスターでは明示的なランタイムクラスとgVisorが有効化されたノードプールが必要です）、バージョン管理されたマニフェストを使用してエージェントサンドボックスコントローラーをデプロイします。

このモデルを支える2つの主要なカスタムリソースは以下のとおりです。 SandboxTemplate and SandboxWarmPool. SandboxTemplate 再利用可能な設計図として機能し、ポッド テンプレート (イメージ、ポート、リソース、 runtimeClassName: gvisorPython環境などのサンドボックス化されたランタイム向けに、など）を提供します。 SandboxWarmPool 設定済みの数のプレウォーム済みポッドをほぼ瞬時に使用できるように準備しておくことで、エージェントが1秒以内に新しい環境を必要とする場合に発生するコールドスタートを回避します。

A Sandbox Router このサービスは、クライアントとこれらの隔離されたポッド間のトラフィックのゲートウェイとして機能します。 開発では、トラフィックをトンネル化することができます kubectl port-forward パブリックIPアドレスを公開することなく、この処理を実行できます。本番環境では、通常、ルーターの前に適切なイングレスとmTLSを配置します。クライアント側では、GoogleがPythonライブラリ「Agentic Sandbox」を提供しており、テンプレートからサンドボックスクレームを作成し、準備が整うまで待機し、シェルコマンドを実行し、完了したらクリーンアップするという、ライフサイクル全体をラップします。

これらはすべて、内部的には依然として「単なるKubernetes」ですが、エージェントランタイム向けに一貫性のあるストーリーとしてパッケージ化されています。 gVisorはプロセスとシステムコールの分離を提供し、SandboxTemplateは設定を標準化し、WarmPoolは起動時の遅延を解消し、ルーターとPythonクライアントによりLLM中心のアプリケーションにとって便利なものとなっています。

一方、Herokuは非常に成熟した構成要素である、単発のdynoに依拠している。 Herokuユーザーは長年にわたり、移行、メンテナンススクリプト、管理タスクなどの臨時のジョブを、必要に応じて起動し、完了すると停止する一時的なdynoで実行してきました。Herokuはこのインフラストラクチャをコード実行サンドボックスとして再利用し、マネージド推論およびエージェントサービスと同時にリリースしました。エージェントはPython、Ruby、Node、またはGoのコードスニペットを作成し、Herokuはそれを短命のdyno内で実行して結果をストリームで返すため、影響範囲は一時的なコンテナ内に限定されます。

これらのサンドボックスには、HerokuのエージェントAPIに組み込まれているツールを使用するか、オープンソースのモデルコンテキストプロトコル（MCP）サーバーをデプロイすることでアクセスできます。 MCPサーバーは標準化されたツールエンドポイントを公開するため、Agentforce、Claude Desktop、CursorなどのクライアントはHerokuのサンドボックスを汎用的なリモートコード実行バックエンドとして扱うことができます。各サーバーはランタイム固有の制限（例： max_calls エージェントがタイトでコストのかかるループに陥らないように、エージェントループごとに）

LangChainのDeep Agentsは、Runloop、Daytona、Modalといったサードパーティのサンドボックスプロバイダーと統合することで、新たな次元を切り開きます。 仕組みはシンプルです。Deep Agentは、ローカル環境でもクラウド環境でも、必要な場所で実行され続けますが、コマンドの実行、ファイルの作成、コードの実行が必要になった場合は、それらの操作はリモートのサンドボックスに転送されます。セットアップスクリプトは、環境変数の事前読み込み、リポジトリのクローン作成、ツールのインストールなどを行うことができ、各エージェントはクリーンで制御された環境を利用できます。コンテキストマネージャが作成とクリーンアップを処理しますが、ドキュメントでは、プロバイダーのダッシュボードを監視して、実行中のサンドボックスが残っていないか確認することを強く推奨しています。

パフォーマンス、状態、分岐：エージェントにとってスピードが重要な理由

動作は遅いが極めて安全なサンドボックスは、実際には迂回されるだろう。開発者ツールの成否は、レイテンシにかかっている。 コーディングエージェントは、夜間のバッチ処理のように動作するわけではありません。対話型のループを実行します。コードを読み込み、編集案を提示し、テストを実行し、ログを分析し、ツールを呼び出し、人間の応答を待ち、そしてこれを繰り返します。実際のセッションでは、問題の複数の分岐を探索し、一部の経路を放棄して後で他の経路に戻ることもあります。

これが、Freestyleのようなプラットフォームが、1秒未満のVMライフサイクル時間と豊富な状態セマンティクスにこだわる理由です。 彼らのVMは、rootアクセス、systemdサービス、ネストされた仮想化サポート、および完全なネットワークを備えた完全なLinuxマシンです。ドキュメントによると、API呼び出しからVMの実行まで800ms未満でプロビジョニングされ、100ms未満でサスペンド/レジュームが可能で、パフォーマンスへの影響を最小限に抑えながら実行中にVMのスナップショットを作成したりフォークしたりできます。彼らはブラウザの状態を特に恩恵を受けるものとして挙げています。エージェントがブラウザを興味深い状態に誘導した場合、その状態を最初から再作成するのではなく、同じスナップショットからそのVMを20回フォークできます。

GoogleのGKE向けSandboxWarmPoolは、Kubernetesの用語で同じ考え方を表現しています。つまり、事前にウォームアップされたPodのプールを保持することで、エージェントが新しい実行のたびに完全なコールドスタートペナルティを支払わなくて済むようにするのです。 Daytonaのスナップショットベースのワークスペースと、自動停止/アーカイブ/削除ポリシーにより、アクティブな開発環境、一時的な実験、長期にわたるベースラインなど、さまざまな種類のセッションに合わせてライフサイクルを調整できます。

E2Bがバックグラウンドジョブ、監視可能なディレクトリ、分離されたファイルシステム、再利用可能なボリュームを重視している点は、同じコインの裏表と言えるでしょう。 これらの機能により、エージェントはコードの変更を検証しながら開発サーバーやテストハーネスを実行し続けたり、複数の一時的なサンドボックス間で永続ボリュームを長期にわたって共有したりすることが可能になります。これらの機能がないと、エージェントは単発のコマンドを実行するだけでコンテキストを失い、生産性が低下してしまいます。

エージェントの作業を行うためのサンドボックスを評価する有効な方法は、いくつか率直な質問をしてみることです。 新しい環境を1秒未満で起動できますか？部分的なビルドやブラウザセッションを含め、状態をクリーンに保存および復元できますか？並列探索のために状態をフォークできますか？「後で再開する」フローのために、長期間存続するリソース効率の良いワークスペースを保持できますか？これらの質問に対する「はい」の答えが多ければ多いほど、エージェントはステートレスなスクリプトランナーではなく、真のエンジニアのように振る舞うことができます。

秘密情報、ネットワークポリシー、ワークスペースの信頼が真の制御プレーンとなる

ホスト分離が完全に行われていても、機密情報、ネットワークポリシー、ワークスペースの信頼性を無視すれば、簡単に安全性の低いシステムを構築してしまう可能性があります。 Dockerのサンドボックスに関するドキュメントは、この点に関して非常に率直です。マイクロVMとそのプライベートDockerデーモンが、ホストとの主要な信頼境界を形成します。ただし、そのVM内では、エージェントは完全なルートレベルの制御権を持ち、共有ワークスペースは読み書き可能な状態でマウントされます。デフォルトでは、ファイルの編集はホストに即座に反映されます。ネットワークからの送信はデフォルトでは拒否され、明示的なルールによってのみ許可されます。また、HTTPリクエストはホスト側のプロキシを使用し、VMに生の機密情報を公開することなく認証情報を挿入できます。

つまり、ホストを隔離するのは第一歩に過ぎず、エージェントがワークスペースや外部世界に対してどのような影響を与える可能性があるのか​​についても考慮する必要があるということです。 Docker のドキュメントでは、エージェントが後で人間が実行するスクリプト (Git フック、CI 設定、IDE タスク定義など) を編集した場合、 Makefile ターゲット、 package.json スクリプト – これらのスクリプトが実行されると、ダメージがホストまたは CI システムに「跳ね返る」可能性があります。Git フックが .git/ 現れない git diffこれにより、悪意のあるロジックを静かに永続させることが容易になる。

認証情報プロキシは強力だが、扱いが難しい。 Docker のアウトバウンドプロキシは、シークレットが VM の外に留まるようにしますが、エージェントは許可されたホストに対してそれらの ID を使用して動作することができます。カスタム環境変数をファイルに書き込むなどのフローでは、 /etc/sandbox-persistent.sh – 意図的にVM内に秘密情報を保存することでこの境界を破ることもできますが、これはエージェントとサンドボックスを本当に信頼している場合にのみ安全です。

設定スコープは、シークレットと同じくらい重要です。 Docker の FAQ には、次のようなユーザーレベルの設定が記載されています。 ~/.claude or ~/.codex ホスト上の設定はサンドボックスにはコピーされません。共有ワークスペース内のプロジェクトスコープの設定のみが表示されます。Anthropic の設定ドキュメントでは、プロジェクトレベルの設定（ツール、権限、MCP サーバー、フックなど）がユーザーレベルの設定を上書きし、チーム間で共有されることが強調されています。つまり、リポジトリに添付したポリシー、手順、プラグインが、エージェントが認識する主要なインターフェースとなります。

OpenAIのスキルガイダンスは、やや異なる用語を用いながらも、同様の点を強調している。 スキル（ツールバンドル）は、プロンプトインジェクションによるデータ漏洩のリスクをもたらす可能性があります。ドキュメントでは、悪意のあるSKILL.mdファイルがポリシーを上書きしたり、破壊的なアクションを引き起こしたり、プライベートデータを漏洩させたりする可能性があるため、キュレーションされていない公開スキルマーケットプレイスをエンドユーザーに直接公開しないよう警告しています。開発者スキルの精査、特定のワークフローへの適用範囲の限定、影響の大きいアクションの追加承認とポリシーチェックによる隠蔽、そしてスキルを脅威モデルの一部として扱うことを推奨しています。

これらの要素を組み合わせると、エージェントサンドボックスの「真の」制御プレーンは4つの層にまたがることになります。 ホスト分離は、マシンとクラスタノードを保護します。ワークスペースの信頼は、サンドボックス内で生成されたファイルを実行する将来のユーザーまたはCIを保護します。ネットワークポリシーは、外部システムとプライベートデータソースを保護します。認証情報管理は、エージェントが動作するためのIDを保護します。堅牢な設計は、最初の4つだけでなく、これら4つすべてに対応できるものです。

さらに、即座の注入やエージェントの乗っ取りに対しては、健全な懐疑心を持つ必要がある。 NIST、OWASP、OpenAIはいずれも、同じパターンのバリエーションについて説明しています。信頼できない入力（README、Webページ、ログファイルなど）に悪意のある指示が埋め込まれており、エージェントの動作をリダイレクトします。検索機能を強化した生成や微調整によって、この問題が魔法のように解決されるわけではありません。適切に計測されたサンドボックスと適切なポリシーがあっても、モデルが騙されるのを完全に防ぐことはできませんが、騙された場合の被害を大幅に軽減できます。

クラウドプラットフォームとエージェントランタイムは、これらの教訓を組み込み始めている。 シークレットプロキシ、許可リストに登録されたアウトバウンドドメイン、リポジトリスコープの設定、より限定された機能を持つサブエージェント、フックベースの承認フロー、再現可能なサンドボックスはすべて同じパズルのピースです。つまり、モデルには誤りがあることを受け入れ、その誤りによるコストが限定されるように環境を設計するということです。

ローカル環境とクラウド環境の両方において、エージェントの実行サンドボックスは、慎重に引かれた境界線と考えるのが最適です。それはモデルをより賢くするのではなく、モデルのミスによる影響を軽減し、より観測しやすくするものです。 ファイルシステム、プロセス、ネットワーク、シークレット、ライフサイクル制御を適切に組み合わせ、さらにエージェントにその環境についてスマートに学習させることで、AIシステムにリポジトリのクローン作成、テストの実行、ブラウザの起動、さらには本番環境に近いシステムへのアクセスさえも許可できます。しかも、あなたが重要視するすべての情報へのアクセス権をAIシステムに渡す必要はありません。

つまり、ホストを隔離するのは第一歩に過ぎず、エージェントがワークスペースや外部世界に対して何ができるか、リスクなどについても考慮する必要があります。 リモートコード実行. Docker のドキュメントでは、エージェントが後で人間が実行するスクリプト (Git フック、CI 設定、IDE タスク定義など) を編集した場合、 Makefile ターゲット、 package.json スクリプト - これらのスクリプトが実行されると、その損害がホストシステムやCIシステムに「跳ね返る」可能性があります。