Managed Agentsのクラウドサンドボックス仕様 — 使える言語とツールの一覧

Managed AgentsのCloud sandboxは、Ubuntu 24.04のLinuxコンテナとしてAnthropic側のインフラで動きます。主要な言語・パッケージマネージャー・データベース・ユーティリティがあらかじめ入っており、エージェントは追加インストールなしにこれらを呼び出せます。初手でつまずきやすいのは、DBが起動していないこと、Playwrightを入れ直すと壊れること、ネットワークの既定値が作成経路で違うことの3点です。

Cloud sandboxとは何か

Cloud sandboxは、Managed AgentsのAPIでエージェントにコード実行環境を与える仕組みです。分離されたコンテナが1セッションに1つ割り当たり、エージェントはBashツールやファイル操作ツールを通じてその中身を操作します。設計の背景はManaged Agentsの3要素分離アーキテクチャで扱った「hand(手)」の実装そのもので、execute(name, input) → stringという最小契約の裏側にある具体的な環境の中身がここで見る仕様です。

対象はcloud環境です。自社インフラ上で動かすself-hosted sandboxは、ワーカーが用意した環境がそのまま使われます。下記の言語・DB・ツールの一覧はcloud環境の話です。API呼び出しにはmanaged-agents-2026-04-01のbetaヘッダーが必要で、SDKを使えば自動で付与されます。

使える言語とパッケージマネージャー

Cloud sandboxには8つの言語ランタイムが常設されています。

Node.jsのパッケージマネージャーが4種類そろっている点は地味に効きます。エージェントが生成したプロジェクトのlockファイル形式に合わせてそのまま実行できます。Pythonはpython3インタープリタ向けにNumPy・pandas・Matplotlib・openpyxl・python-docx・python-pptx・pypdfが標準で入っています。データ分析やドキュメント生成のタスクなら、追加インストールの待ち時間なしに本題へ入れます。

データベースは3種 — 既定で起動していない点に注意

Cloud sandboxにはPostgreSQL・Redis・SQLiteの3種が用意されています。落とし穴は、サーバー自体は既定で起動していないことです。

エージェントに「DBを使って」と指示しても、PostgreSQLやRedisはプロセスとして立ち上がっていません。最初にサーバー起動のコマンドを実行させる必要があります。SQLiteは言語バインディングを呼ぶだけでファイルベースのDBとして動くので、軽い検証タスクなら起動待ちを省けます。

用途別のユーティリティ一覧

システムツール・開発ツール・テキスト処理・ドキュメント/メディア処理の4系統に加え、ブラウザー自動化もそろっています。

• システムツール: git(バージョン管理)、curl / wget(HTTPクライアント)、jq / yq(JSON・YAML処理)、tar / zip / unzip(アーカイブ)、tmux(ターミナルマルチプレクサー)
• 開発ツール: make / cmake(ビルドシステム)、docker(コンテナ管理、利用可能範囲は限定的)、ripgrep(rg、高速ファイル検索)
• テキスト処理: sed / awk / grep(ストリームエディター)、vim / nano(テキストエディター)、diff / patch(ファイル比較)
• ドキュメント・メディア処理: ffmpeg(音声・動画処理)、ImageMagick(convert / identify、画像操作)、pandoc(文書変換)、LibreOffice(ヘッドレスモードでのOffice文書変換)、Poppler(pdftotext / pdftoppm)とqpdf(PDF処理)、tesseract(英語OCR)、TeX Live(pdflatex / xelatex / latexmk、組版)

長時間タスクでBashコマンドがハングした場合の検知・タイムアウト処理は、サンドボックス側の仕様ではなくハーネス側の実装で担います。センチネル行を使ったタイムアウト実装はBashツールをAPIで実装するセンチネル行とタイムアウト処理で扱っています。ffmpegやLibreOfficeのように処理時間が読みにくいコマンドを任せるときは、合わせて確認してください。

Dockerは「限定的」とだけ書かれている

開発ツールの一覧でdockerには「limited availability(利用可能範囲は限定的)」の注記が付いています。リファレンスにあるのはこの一言だけで、使えるサブコマンドや使えない操作の一覧はありません。

エージェントに「Dockerでビルドして」と頼む前に、docker versionのような小さなコマンドで疎通を見ておくと、通る操作と通らない操作を切り分けられます。

ブラウザー自動化はPlaywright限定

ブラウザー自動化はPlaywright(Python・Node.js両対応)とChromiumのみです。Chromiumは/opt/pw-browsers/chromiumに置かれ、PATHには含まれません。サンドボックスはPLAYWRIGHT_BROWSERS_PATHを/opt/pw-browsersに設定済みなので、プリインストール済みのPlaywrightパッケージは設定なしでChromiumを見つけます。

実装でつまずきやすいのは次の点です。別バージョンのPlaywrightを追加インストールすると、そのバージョンが探すブラウザービルドが環境に無いため、動かなくなります。requirements.txtやpackage.jsonにPlaywrightを再度指定しないのが基本です。FirefoxとWebKitはインストールされていません。

環境を作るときに決めるパッケージとネットワーク

プリインストールで足りない分は、環境(environment)のpackagesで足せます。環境は一度作ってIDを使い回す単位で、同じ環境を参照する複数のセッションも、それぞれ別のサンドボックスを持ちます。ファイルシステムの状態は共有されません。

3つ目の400エラーを避けた最小の作成リクエストは次のとおりです。

curl -fsS https://api.anthropic.com/v1/environments \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d '{
    "name": "data-analysis",
    "config": {
      "type": "cloud",
      "packages": {"pip": ["pandas", "scikit-learn"]},
      "networking": {"type": "limited", "allow_package_managers": true}
    }
  }'

環境は更新しても版が残りません。頻繁に変えるなら、どのセッションがどの設定だったかを手元で記録しておく必要があります。環境はアーカイブか削除をするまで残り続けます。環境の作り方の流れはManaged Agentsの環境設定チュートリアルにもあります。

サンドボックスのスペック

ネットワークの既定値は作成経路で変わる

リファレンスの記載は、APIで作成した環境は既定でunrestricted、Claude Studio経由で作成した環境は既定でlimited、というものです。環境設定のページでは、networkingを省いたAPIリクエストがunrestrictedになること、Claude Consoleの作成フォームはLimitedが選ばれて何も許可されていない状態から始まることが書かれています。呼び名はページで違いますが、フォーム経由は制限あり、API経由で省略すると無制限、という点は共通です。

エージェントが外部APIを叩けずに詰まったときは、フォーム経由で作った環境のネットワーク設定をまず見るのが早道です。逆に外部への通信を絞りたいなら、APIではnetworkingを明示します。

allow_package_managersがtrueのとき追加で開くのは、GitHub・npm・PyPI・crates.io・Go proxy・Maven・RubyGems・Packagist・Ubuntuのaptミラー・Docker関連のレジストリなどです。許可は操作単位でなくホスト単位なので、許可したホストにはgit pushやパッケージ公開のような書き込みも送れます。リポジトリのファイルや取得したWebページのように信頼できない入力を処理するエージェントでは、プロンプトインジェクションでファイルが外に出る経路になりえます。bashツールの権限ポリシーをalways_askやautoにする方法が、公式のリスク低減策に挙がっています。

なおnetworkingが制限するのはサンドボックスの外向き通信です。web_searchとweb_fetchはAnthropic側のサーバーで動くので影響を受けず、到達先を絞るにはツール設定のallowed_domainsかblocked_domainsを使います。

Cloud sandboxとself-hosted sandboxの使い分け

メモリーとディスクの上限は上のスペック表のとおりです。プリインストールの構成に加えられるのは、packagesで指定する6種のパッケージマネージャー経由のパッケージです。自社独自のランタイムや社内専用ツールを常設したいときは、ワーカーが用意した環境を使うself-hosted sandboxが受け皿になります。

cloud sandboxとself-hosted sandboxを切り替えられるのは、サンドボックスがexecuteという最小契約で呼ばれる設計だからです。これはManaged Agentsの設計思想にあるハーネスとサンドボックスの分離にあたります。認証情報をサンドボックス内に残さない考え方はClaude Codeセキュリティ・権限ガイドとも重なります。

まとめ

最初に決めるのは、DBをSQLiteで済ませるか、サーバー起動を前提にPostgreSQL・Redisを使うかです。次に、ネットワークはlimitedから始め、エージェントが詰まったホストだけをallowed_hostsに足していく順序だと、広く開けたまま走らせずに済みます。