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

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

Managed Agentsのcloud環境で使える言語・データベース・ユーティリティを公式リファレンスから一覧します。DBが既定で起動していない点やPlaywrightの制約など、実装前に踏みがちな落とし穴も扱います。

読了目安 約7分

Managed AgentsのCloud sandboxは、Ubuntu 24.04のLinuxコンテナとしてAnthropic側のインフラで動きます。主要な言語・パッケージマネージャー・データベース・ユーティリティがあらかじめ入っており、エージェントは追加インストールなしにこれらを呼び出せます。公式リファレンスに載っている一覧には、初手でつまずきやすいポイントが何箇所かあります。

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つの言語ランタイムが常設されています。

言語バージョンパッケージマネージャー
Pythonバージョン3.10 / 3.11 / 3.12 / 3.13パッケージマネージャーpip、uv、poetry
Node.jsバージョン20 / 21 / 22(既定)パッケージマネージャーnpm、yarn、pnpm、bun
Goバージョン1.24(既定)/ 1.25パッケージマネージャーgoモジュール
Rustバージョンrustupの安定版ツールチェーンパッケージマネージャーcargo
JavaバージョンOpenJDK 21パッケージマネージャーmaven、gradle
Rubyバージョン3.1 / 3.2 / 3.3(既定)パッケージマネージャーbundler、gem
PHPバージョン8.3パッケージマネージャーcomposer
C / C++バージョンGCC 13、Clangパッケージマネージャーmake、cmake、ninja

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

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

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

データベース説明
PostgreSQL 16説明サーバーとpsqlクライアントがインストール済み。サーバーは既定で起動していない
Redis 7説明サーバーとredis-cliがインストール済み。サーバーは既定で起動していない
SQLite説明Pythonのsqlite3モジュールなど、言語バインディング経由で利用可能

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

タスクの性質向くDB理由
軽い動作検証・使い捨てのデータ操作向くDBSQLite理由サーバー起動が不要ですぐ使える
本番同等のスキーマ・トランザクションを試す向くDBPostgreSQL理由型・制約・拡張機能が本番に近い
キャッシュやキュー処理のプロトタイプ向くDBRedis理由インメモリで高速、TTLやPub/Subも試せる

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

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

  • システムツール: 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のような処理時間が読みにくいコマンドをエージェントに任せるときは合わせて確認してください。

システムツールの中ではtmuxの存在が地味に重要です。長時間かかる処理をバックグラウンドで走らせつつエージェントが別の作業を進める、という並行実行のパターンを組むとき、素のBashだけでは実行中のプロセスとの対話が難しくなります。tmuxのセッションを介せば、実行中のコマンドに後から接続してログを確認したり、途中で入力を送ったりできるので、ビルドやテストのように完了までの時間が読めないコマンドほどtmux経由で実行する価値が出てきます。

Dockerの利用可能範囲は限定的

開発ツールの一覧にdockerが含まれていますが、公式リファレンスは「利用可能範囲は限定的」とだけ記し、具体的にどのサブコマンドが使えないかまでは明記していません。サンドボックス自体がコンテナである以上、コンテナの中でさらにコンテナを起動する構成(Docker-in-Docker)には制約が付きやすい領域です。エージェントに「Dockerでビルドして」と指示する前に、まずは小さなコマンド(docker versionなど)で疎通を確認し、想定した操作が通るかを個別に見極める姿勢が安全です。ビルドやデプロイの検証にDockerを前提としたワークフローを丸ごと持ち込む場合は、self-hosted sandbox側でDocker環境を明示的に用意する方が確実です。

ブラウザー自動化は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はインストールされていないため、クロスブラウザーテストが必要な処理は自前でブラウザーを持ち込むか、self-hosted sandbox側で用意する必要があります。

サンドボックスのスペックとネットワーク既定値

コンテナ自体のスペックは次の通りです。

項目値
OS値Ubuntu 24.04 LTS
アーキテクチャー値x86_64(amd64)
メモリー値最大8GB
ディスク容量値最大10GB
ネットワーク値APIで作成した環境は既定でunrestricted(無制限)。Claude Studio経由で作成した環境は既定でlimited(制限あり)

ネットワークの既定値が作成経路によって変わる点は見落としやすい仕様です。APIから直接環境を作ると無制限ネットワークが既定になるため、外部への通信を絞りたい場合は明示的にlimitedへ変更する必要があります。逆にStudio経由だと既定で制限がかかっているため、エージェントが外部APIを叩けずに詰まったときは、まずネットワーク設定を疑うのが早道です。ネットワーク設定の詳細な変更方法は環境設定のドキュメントに譲りますが、既定値の違いだけは実装前に押さえておく価値があります。

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

Cloud sandboxの仕様は固定です。8GBメモリー・10GBディスクという上限は、大規模なビルドや巨大なデータセットの処理には窮屈に働くことがあります。自社のコンプライアンス要件でデータを外部に出せない場合や、GPUなど特殊なハードウェアが必要な場合は、self-hosted sandboxで自社インフラ上に環境を用意する選択肢が残されています。逆に言えば、ここまで挙げた8言語・3データベース・5系統のユーティリティという構成は、あくまでAnthropicが「多くのタスクで困らない標準セット」として選んだ既定値であり、自社独自のランタイムや社内専用ツールを常設したい場合は、cloud sandboxの範囲では実現できません。

この使い分けは、Managed Agentsの設計思想にあるハーネス・サンドボックス分離の恩恵がそのまま効く場面です。サンドボックスはexecuteという最小契約さえ満たせば入れ替え可能なので、開発中はcloud sandboxで素早く検証し、本番でデータ主権やスペック上の理由が出てきたらself-hosted sandboxに切り替える、という段階的な移行が設計上想定されています。認証情報をサンドボックス内に残さない設計はClaude Codeセキュリティ・権限ガイドで扱った考え方とも重なるので、self-hosted環境を検討する際はあわせて確認すると設計の抜けを減らせます。

まとめ

  • Cloud sandboxは8言語のランタイムとPostgreSQL・Redis・SQLiteをプリインストール済みだが、PostgreSQLとRedisのサーバーは既定で起動していない
  • ブラウザー自動化はPlaywright + Chromiumのみで、別バージョンのPlaywrightを追加インストールすると動かなくなる
  • メモリー最大8GB・ディスク最大10GBが上限で、ネットワークの既定値はAPI作成かStudio作成かでunrestricted/limitedに分かれる
  • スペック上限やデータ主権の要件に当たったら、self-hosted sandboxへの切り替えが選択肢になる
この記事を共有:XはてブLinkedIn

関連する記事

Anthropic をもっと見る →