サンドボックス化とは、AI コーディングエージェントを隔離された環境 — コンテナ、仮想マシン、別ブランチ、使い捨てのワークスペース — で実行し、実際の本番システムに影響を与えることなく、ファイルの読み取り、コードの記述、コマンドの実行を行えるようにするプラクティスである。エージェントがディレクトリの削除、設定ファイルの破損、不適切な依存関係のインストールといったミスを犯しても、その被害はサンドボックス内に封じ込められ、実際のコードベースは手つかずのまま残る。
用法
サンドボックス化の具体的な形態には次のものがある。Git ワークツリー（エージェントが作業するためのリポジトリの隔離されたコピーで、結果が良ければマージし、そうでなければ削除する）、コンテナ（ネットワークアクセスを制限し、ファイルシステムを隔離した Docker の中でエージェントを実行する）、GitHub Codespaces や Gitpod のように一時的な開発環境を提供するクラウドサンドボックスサービス、エージェントが別ブランチで作業し、人間のレビューの前に CI が変更を検証するブランチベースの隔離、エージェントが外部 API を呼び出したり本番サービスにアクセスしたりすることを防ぐネットワーク制限、そして完全なサンドボックス化を行わない場合でもより軽量な隔離の形態となるパーミッションのスコープ設定（大半のディレクトリには読み取り専用のアクセス、特定のパスにのみ書き込みアクセス）である。
エージェント的ループの設計 は、エージェントをローカルで隔離することと、単にリスクを受け入れることの中間にある選択肢を示している。それは 他人のコンピュータ で実行することであり、暴走したエージェントの影響範囲は、それが自分のマシンではないという点で限定される。この記事の著者はこれを自身のお気に入りとして挙げ、その実例として GitHub Codespaces を挙げたうえで、最悪の場合を、環境にチェックアウトされたコードが持ち出されること、あるいは接続されたリポジトリに不適切なコードがプッシュされることに限定している — 消費される CPU は他人のものである。また、ホスト型のコードインタープリターモードも同じ役割で驚くほど遠くまで行けると報告しており、著者自身が OpenAI の Codex Cloud をそのように使って大きな成果を上げてきたことも伝えている。
2026年のAI Coding Agent活用 ── スピードと安全性を両立させる は、これらの形態のうち 3 つを、4 つの軸 — セットアップの手間、安定性、開発者がエディタの選択を保てるかどうか、外部ツールとの統合のしやすさ — で比較している。開発コンテナは、中程度の手間で安定性とエディタの選択の点で良い結果を示す。同記事によれば、エージェントベンダー自身のリポジトリには、iptables ベースのネットワーク制限を備えたサンプルのコンテナ構成が同梱されており、また別の CLI とサードパーティ製ツールがどちらも同じ構成を外部から扱えることから、コンテナ開発は 1 つのエディタに縛られない。その代償はホスト上で作業する際の利便性であり、パスワードマネージャーからのシークレットの取得、フックによる通知、ユーザーレベルのエージェント設定の共有がいずれも難しくなる。
エージェント自身の組み込みサンドボックスは、3 つの中で最もセットアップが少なく済み、クラウド IDE と同程度で、コンテナよりも少ない。コンテナ定義を書くのではなく、エージェントの設定ファイルから有効にするからである。Linux では bubblewrap、macOS では Seatbelt で実装されている。同記事はこれを 3 つの中で最も成熟度が低く、そのぶん内部で何かが失敗したときの診断が難しいと報告している。サンドボックス化されていないコマンドを依然として許可する設定をオフにすることを推奨しつつ、そうするとサンドボックス自体が引き起こしたエラーを回避する余地が小さくなることも認めている。3 つ目の選択肢はクラウド IDE で、手間が少なく隔離されているが、使うエディタが決まってしまう。
同じ記事は、サンドボックスと承認設定を二者択一として扱うのではなく、サンドボックスを より 寛容な承認設定と組み合わせる論拠も示している。シェルコマンドがサンドボックス化されている からこそ それらを自動許可する設定を推奨しており、その根拠は、安全性を保ったまま体験が向上するというものである。そして、パーミッションプロンプトが大幅に減ったという結果を、自ら計測するのではなく、ベンダー自身のエンジニアリング記事から伝えている。プロンプトが少ないこと自体が単なる利便性ではなく安全性に関わる性質であるという点は、同記事の別の節 — パーミッション設定に関する節 — で論じられており、本 Wiki では 承認疲れ（Approval Fatigue） で取り上げている。
ドキュメントに記載されたベンダーの組み込みサンドボックス
Claude Code のサンドボックス化された Bash ツールに関する Anthropic のドキュメントは、1 つの組み込みサンドボックスを詳しく説明している。コマンドを 1 つずつ承認する代わりに、ユーザーはコマンドが触れてよいファイルとネットワークドメインを定義し、オペレーティングシステムがすべての Bash、PowerShell、Monitor コマンドとその子プロセスに対してその境界を強制する — macOS では Seatbelt、Linux と WSL2 では bubblewrap を用い、socat がネットワークトラフィックをサンドボックスのプロキシへ中継する。ネイティブの Windows と WSL1 はサポートされていない。このドキュメントはサンドボックスを 2 つの独立したレイヤーに分けている。ファイルシステムの隔離は、デフォルトでは作業ディレクトリ、ユーザーが追加したディレクトリ、セッション用の一時ディレクトリへの書き込みのみを許可し、読み取りは特定の拒否されたディレクトリを除いてコンピュータ全体にわたって許可する — このデフォルトでは、保護対象として列挙しない限り ~/.aws/credentials や ~/.ssh/ のような認証情報ファイルが依然として読み取り可能であることを、ドキュメントは明示的に注記している。ネットワークの隔離はサンドボックスの外側にあるプロキシを経由して行われ、このプロキシはどのドメインも事前には許可せず、コマンドが新しいドメインを初めて必要としたときに確認を求める。
その説明の中の 2 つの設計上の選択は、一般的なプラクティスに関わるものである。第一に、サンドボックスはパーミッションルールの一種ではなく、それとは別のレイヤーとして提示されている。パーミッションルールはツールの実行前にコマンド文字列に基づいて評価されるのに対し、サンドボックスは実行中のプロセスに対してオペレーティングシステムが強制するものであるため、モデルが何を実行することを選んだかに関係なく、また許可されたコマンドがその名前から想像される以上のことを行った場合でも成り立つ、とドキュメントは述べている。第二に、サンドボックス化されたコマンドをプロンプトなしで実行するオプションの自動許可モードと、エスケープハッチ — サンドボックス内で失敗したコマンドを通常のパーミッションフローを通じてサンドボックスの外で再試行できる — を組み合わせており、このエスケープハッチはオフにしてすべてのコマンドをサンドボックス内で実行させることもできる。認証情報については、ファイルのブロックや変数の設定解除に加えて、サンドボックス化されたコマンドにはプレースホルダーが見え、プロキシがユーザーの許可したホストへの送信リクエストに限って実際の値に置き換えるというマスキングモードも用意されている。
同じドキュメントは、これが完全な隔離境界ではないことも明言している。デフォルトでは、プロキシは TLS を終端・検査することなく、クライアントが提示したホスト名から判断するため、github.com のような広いドメインを許可すると、ドメインフロンティングのような手法も含めて、データ持ち出しの経路を開きうる。Docker ソケットのような Unix ソケットを許可すると、サンドボックス化されたプロセスにホストへのアクセスを与えうる。また、非特権コンテナ内で実行するためのより弱いモードは、セキュリティを大幅に弱めるものと説明されている。その結論は、効果的なサンドボックス化には両方のレイヤーが必要だというものである。ネットワークの隔離がなければ、侵害されたエージェントは SSH 鍵のような機密ファイルを持ち出せてしまい、ファイルシステムの隔離がなければ、システムリソースにバックドアを仕込んでネットワークアクセスを得られてしまう。
適用される場面
サンドボックス化は、エージェントに与える自律性が大きくなるほど重要になる。エージェントは指示を誤解したり、解決策をハルシネーションしたり、意図しない副作用を伴うコマンドを実行したりしうるため、隔離がなければすべてのアクションが現実のリスクを伴い、各コマンドは実行前にレビューと承認を必要とする。サンドボックス化が施されていれば、エージェントは自由に試行錯誤でき、レビューが必要なのは最終結果だけになり、これはワークフローを劇的に高速化すると説明されている。これは特定の当事者による固有の提案ではなく、自律型エージェント全般のベストプラクティスとして提示されており、エージェントの出力を信頼できないプルリクエストのように扱う — 隔離された環境で作業させ、結果をレビューし、検証後にのみマージする — と要約されている。
上記の説明がネットワーク制限をいくつかある隔離手法の 1 つとして扱っているのに対し、Claude Code for web：Anthropic の新しい非同期コーディングエージェント はそれを難しい部分であり、かつセキュリティ上の議論を担う部分として特に取り上げている。Anthropic のサンドボックス化の取り組みを報告する中で、ファイルシステムの隔離は比較的容易であり、ネットワークの隔離こそが難しい問題だと述べ、Anthropic のアプローチを引用している。すなわち、インターネットアクセスはサンドボックスの外で動作するプロキシサーバーに接続された Unix ドメインソケットを通じてのみ許可され、そのプロキシがプロセスの到達できるドメインを強制し、新たに要求されたドメインについてはユーザーの確認を処理する。これが重要である理由として同記事が挙げるのは 致命的な三要素 である — そうした攻撃に対する最善の防御は 3 つの要素のうちの 1 つを断つことであり、送信方向のネットワークアクセスを制限することが持ち出しという要素を取り除く方法となる。また、部分的な遮断の限界にも触れている。依存関係のインストール用ドメインが数十にも及ぶ許可リストでは、その内側に持ち出し経路が残っているのではないかと著者は不安を覚えたが、ネットワークなしのモードであれば、その軸については何も心配する必要がない。
同記事は、各アクションを単に承認するのではなく、なぜサンドボックス化に労力を費やす価値があるのかという論拠も示している。Anthropic の投資を、段階ごとのパーミッションプロンプトなしで動作するエージェントのほうが、それを必要とするエージェントよりもはるかに生産的であることを認めたものと読み解いており、そうであれば解決すべき問題は、承認を厳しくすることではなく、安全な実行を手軽にすることになる。著者はこのアプローチを、自分にとって信頼に足ると感じられる唯一のものだと述べている。
こうしたことが実際にどれほど確実に達成されるかについては、エージェント的ループの設計 がより懐疑的に扱っている。同記事によれば、コーディングエージェントはそれぞれ独自のレベルのサンドボックス化を実装しているが、著者は信頼できるほど説得力のあるドキュメントを見たことがない — これは検証された知見ではなく著者自身の評価である。そして、Docker や Apple のコンテナツールを、コンテナエスケープが存在することに触れつつも、大半の人にとって受け入れてよいリスクとして扱っている。より率直な観察は手法ではなく普及に関するものである。サンドボックス、他人のマシン、単にリスクを取ることの 3 つを提示されると、大半の人は 3 つ目を選ぶという。同記事はまた、--dangerously-skip-permissions をインターネットアクセスのないコンテナ内で使うよう推奨する Anthropic の Claude Code ドキュメントを引用し、非公開のソースコードの持ち出しを防ぐ方法として、エージェントを信頼できるホストのリストに制限することを支持している。
関連用語
ガードレール、ヒューマン・イン・ザ・ループ、DefinedTerm/tool-use、エージェント型エンジニアリング、致命的な三要素、Claude Code for web、YOLO モード、パーミッションモード