Anthropic Sandbox Runtime (srt)と次世代のAIエージェントのアーキテクチャ
Anthropic Sandbox Runtime (srt) は、Claude Code on the web などクラウド環境向けに Anthropic が開発した軽量サンドボックスの PoC(概念実証)です。

少なくない Claude Code ユーザーは --dangerously-skip-permissions オプションでbypassPermissions モードを有効にし、承認フローなしで運用しています。 開発体験は向上しますが、破壊的な操作やデータ漏洩のリスクを受け入れることになります。 個人開発者やバイブコーダーはこれでもいいのかもしれませんが、エンタープライズ環境では、この手のリスクを許容できず導入が進まないケースもあります(なお組織ポリシーは managed-settings.json で disableBypassPermissionsMode を設定し、このバイパスを無効化できます)。
Dev Containers でコンテナとして隔離する方法もありますが、現時点では少数派です。また、そもそもコンテナ内であってもエージェントがプロンプトインジェクションやブラウザツール悪用などによって、ファイルを改竄したり外部に送信するリスクは残ります[1]。
[1]: https://www.promptarmor.com/resources/google-antigravity-exfiltrates-data
このように従来のアプローチでは、権限を与えるほど危険度が上がり、「自律性を高めたいのに権限が与えられない」というジレンマがありました。
Anthropic は最近エージェント実行をクラウドに寄せる方向で開発を進めており、srt で示されているのはその基盤技術となります。 ユーザーの自己責任だけではなく、エージェントレイヤーで安全機構を設け、ユーザーにはその設計の自由を与えようというのが Anthropic ブログの意図です。
Claude Code のCLI 自体に srt は含まれていませんが、CLI には macOS 向けに Seatbelt(macOS 10.5から導入されたOS標準のサンドボックス機構)を利用した軽量サンドボックスが実装されています。
LinuxやClaude Code on the Web環境では Linux の bubblewrap(Flatpakなどで使われる低レベルサンドボックスツール)が使われます。bubblewrap はLinuxカーネルのNamespace機能でファイルシステムやネットワークを隔離し、seccompでシステムコールを制限します。 Windows は対象外ですが、WSL 経由で利用可能と思われます。
srt の実行方法は2つあります。CLI でコマンドをラップする方法と、コードからライブラリとして呼び出す方法です。
CLI では srt コマンドで任意のプロセスをサンドボックス内で実行します:
npm install -g @anthropic-ai/sandbox-runtime
curl https://example.com
<!doctype html><html lang="en"><head><title>Example Domain</title><
srt --debug curl https://example.com
curl: (6) Could not resolve host: example.com
srt "echo 1 > a.txt"
/bin/bash: a.txt: Operation not permitted
Node.js からは @anthropic-ai/sandbox-runtime パッケージを使います:
import { SandboxManager } from '@anthropic-ai/sandbox-runtime'
import { spawn } from 'child_process'
const config = {
network: { allowedDomains: ['example.com'], deniedDomains: [] },
filesystem: { denyRead: ['~/.ssh'], allowWrite: ['.', '/tmp'], denyWrite: ['.env'] },
}
await SandboxManager.initialize(config)
// 許可されたドメイン → 成功
const allowed = await SandboxManager.wrapWithSandbox('curl https://example.com')
spawn(allowed, { shell: true, stdio: 'inherit' })
// <!doctype html><html lang="en">...
// 許可されていないドメイン → ブロック
const blocked = await SandboxManager.wrapWithSandbox('curl https://google.com')
spawn(blocked, { shell: true, stdio: 'inherit' })
// curl: (6) Could not resolve host: google.com
node srt.mjs
<!doctype html><html lang="en"><head><title>Example Domain</title>
curl: (56) CONNECT tunnel failed, response 403
srt は OS レベルでネットワークとファイルシステムへのアクセスを個別に細かく制限できます。 この2段階の制限により、エージェントの振る舞いの中で「読めない・書けない・送れない」という状態が保証されます。
- ネットワーク: すべての通信はプロキシ経由に強制され、許可ドメイン以外は遮断
- ファイルシステム: 読み込みは禁止リスト、書き込みは許可リスト+禁止リストで制御
現在の Claude Code は シェルに渡す引数内のコマンド名でマッチングして許可を取ります(rm を許可、git push を許可など)。 一方 srt は「どのドメインに通信できるか」「どのパスに書き込めるか」とリソース単位で制御します。 コマンド名のマッチングでは想定外のコマンドに対応できませんが、リソース単位の境界なら未知のコマンドでも安全に実行できます。
srt のようなサンドボックスレイヤーは、先のジレンマを一部解消します。 OS が強制する安全境界により「安全だから権限を与えられる」に変わります。 どんなに暴走しても Home ディレクトリを消されないし、機密ファイルは読めないし、外部にデータを送れないなら、ある程度自由に動かせるわけです。
srt 公開の意味は、現在までに普及した「LLMによるツールの自律的な実行」から「LLMが生成した未知のコードを実行する」フェーズへの土台作りです。 Claude Skills のように、その場で生成したスクリプトを実行する技術が当たり前になると、このサンドボックスが効いてきます。AnthropicとしてはMCPアーキテクチャの普及のようにこのデザインごと業界内へ広げたいのでしょう。
なお、繰り返しますがsrt 自体は PoC であり、自前のサンドボックス実装の参考にするものでそのまま使うものではないと思います。

