Anthropicが公開した「sandbox-runtime（srt）」は、Claude Codeのサンドボックス化されたbashツールの土台となっているOSレベルの隔離機構だ。だが用途はClaude Codeに限らない。自作のエージェント、ローカルのMCPサーバー、さらには通常のコマンドラインプログラムまで、このサンドボックスの中で動かせる。プロセスが触れられるファイルと接続できるホストを制限しつつ、コンテナを起動する必要がない点が最大の特徴である。
導入は簡単で、npm install -g @anthropic-ai/sandbox-runtimeでインストールし、コマンドの前にsrtを付けるだけでよい。CLIとしてもTypeScriptライブラリとしても利用できる。npmパッケージはv0.0.81、展開後約11.4MB、ライセンスはApache-2.0で、Node.js 22.12以上を要求する。対応環境はmacOSまたはLinuxの開発マシンやCI環境だ。
仕組みの面では、各OSが備える隔離プリミティブを再利用し、制限はスクリプトや子プロセスを含むプロセスツリー全体に及ぶ。macOSではsandbox-execと動的生成されるSeatbeltプロファイルを使い、必要なのはripgrepのみ。Linuxではネットワーク名前空間を外したbubblewrapを用い、socatとripgrepも必要とする。Windowsはアルファ段階で、専用のsrt-sandboxアカウント、Windows Filtering Platformによる外向き通信の制限、明示的なファイルACLを組み合わせる。
ネットワーク通信は、ホスト上で動くHTTPプロキシとSOCKS5プロキシを経由しなければ外に出られない。LinuxではこれらのプロキシがサンドボックスにバインドマウントされたUnixソケットの背後に置かれ、macOSではSeatbeltプロファイルがlocalhostの1ポートのみを許可する。プロキシ側でドメインの許可リストと拒否リストを適用する仕組みだ。
Anthropicはファイルシステムとネットワークの両方の隔離が必要だと強調する。ネットワーク隔離がなければ、プロンプトインジェクションを受けたエージェントがSSH鍵を持ち出しかねない。逆にファイルシステム隔離がなければ、サンドボックスを抜け出してネットワークに到達できてしまう。そこでsrtの既定値は、拒否されない限り読み取りはどこでも許可、許可されない限り書き込みはどこでも拒否、ドメインが許可リストになければネットワークは拒否、という設計になっている。
MCPサーバーをサンドボックス化するには、.mcp.json内のコマンドをnpxからsrtに置き換え、元のコマンドを引数として渡す。ルールは~/.srt-settings.jsonに記述し、networkのallowedDomainsとdeniedDomains、filesystemのdenyRead・allowWrite・denyWriteを指定できる。例えばapi.github.comや*.npmjs.orgを許可し、~/.sshの読み取りを拒否し、カレントディレクトリへの書き込みを許可しつつ.envへの書き込みを拒否する、といった設定が可能だ。自作エージェント向けにはSandboxManagerが用意されており、initialize(config)でプロキシを起動し、wrapWithSandbox()でspawn可能なラップ済みコマンド文字列を取得できる。
Anthropicは社内のClaude Code利用において、サンドボックス導入で権限確認プロンプトが84%減少したと報告している。ただしこれは自己申告の数値であり、外部のベンチマークではない。狙いは「承認疲れ」の解消にある。一日中「承認」をクリックし続ける開発者は、やがてその内容を読まなくなる。固定された境界を設ければ、エージェントは境界内で自由に作業し、境界に触れたときだけ確認を求められる。
実際の課題は、厳格な許可リストとエージェントの実務需要のバランスにある。コーディングエージェントはファイル編集だけでなく、依存関係のインストール、ドキュメントの取得、API呼び出しも行う。許可リストが厳しすぎればnpm installが失敗し、緩すぎればサンドボックスはほとんど意味をなさない。srtはこの中間を取るための調整手段を複数用意している。*.npmjs.orgやapi.example.com:443のようなワイルドカードとポート指定、ルールでカバーされないホストを判断しモデルが読む理由を返せる「askコールバック」、1回の呼び出しだけレジストリを開放するコマンド単位の許可リスト、--control-fdによる実行中のネットワークリストの動的更新、許可された名前がループバックやクラウドのメタデータIPに解決される場合を遮断する解決アドレス検査、拒否ドメインに対してHTTPSのgitリモートなど代替手段をエージェントに伝える仕組みなどだ。
他のエージェント向けサンドボックスとの違いも明確だ。OpenAI Codex CLIのサンドボックスもOSプリミティブを用いてローカルで動作するが、Codexに組み込まれている。Docker SandboxesとE2BはmicroVMに依存し、E2BはクラウドまたはBYOC（AWS、GCP）上で動く。ネットワークの既定ポリシーは、srtが全拒否＋プロキシ許可リストなのに対し、Codexはworkspace-writeモードで既定オフ（設定で切替可能）、Docker Sandboxesは初回起動時にポリシーを選択、E2Bは既定オンで無効化も可能となっている。ライセンスはsrtとCodexがApache-2.0、E2BのSDKもApache-2.0、Docker Sandboxesは非公開。成熟度ではsrtがベータのリサーチプレビューでWindowsはアルファ、CodexのサンドボックスはCLIに同梱済み、Docker SandboxesとE2Bは正式提供製品だ。
総じて、srtの利点はコンテナなしでプロセスツリー全体にファイルとネットワークの制限を課せ、権限確認を大幅に減らせることにある。一方でベータのリサーチプレビューであり、Windows対応が未成熟という弱点がある。何より注意すべきは、許可リストの広さこそが実質的なセキュリティの調整弁であり、広すぎるドメイン指定はデータ持ち出しの経路になり得るという点だ。