Claude Managed Agents の self-hosted sandboxes(2026-05-19)— ツール実行を自社インフラに閉じる

Claude Managed Agents は既定で、ツールやコードを Anthropic 管理のクラウドコンテナで実行します。2026-05-19 に追加された self-hosted sandboxes は、オーケストレーション(エージェントの思考の進行管理)は Anthropic 側に残したまま、ツール実行だけを自社インフラに移す選択肢です。これにより、エージェントのコード・ファイルシステム・ネットワーク egress が自社環境から出ません。

同じ 5/19 のリリースには、関連する強化も入りました。agent_toolset や MCP ツールの出力が 100K トークンを超えると、自動でサンドボックス内のファイルに退避され、モデルには切り詰めたプレビューとファイルパスが渡る、という変更です。大きな出力でコンテキストを溢れさせない実務的な改善です。

この記事は Managed Agents 入門の続きとして、「実行を自社境界に閉じたい」要件への答えを整理します。

クラウド実行とどう違うか

	クラウド環境	self-hosted sandbox
ツールが動く場所	Anthropic 管理コンテナ	自社インフラ
ネットワーク到達範囲	Anthropic の egress 制御	自社のネットワークポリシー
ファイル / GitHub リポジトリのマウント	Anthropic 管理	自社管理
ライフサイクル	Anthropic 管理	自社管理

self-hosting が向くのは、ネットワーク境界の外に出せないデータを扱う、公開ルーティングされていない内部サービスに到達したい、自社のコンプライアンス・監査統制の下で動かしたい——といったケースです。

MCP tunnels と混同しないように。self-hosting は「エージェントのコードがどこで実行されるか」を、MCP tunnels は「Anthropic が社内 MCP サーバーにどう到達するか」を制御します。両者は独立で、組み合わせると実行も MCP アクセスも自社境界に収まります。

environment worker の仕組み

中核は environment worker です。これは自社インフラで動かすプロセスで、Anthropic からツール実行リクエストを受け取ってローカルで実行します。self_hosted 環境は、Anthropic のオーケストレーションと自社 worker を繋ぐワークキューとして機能します。

セッションが環境に割り当てられると、Anthropic がそれをワークアイテムとしてキューに積む
自社 worker がキューからアイテムをclaimし、セッションごとの実行コンテキストを生成
エージェントの skills をダウンロードし、ツール呼び出しをローカル実行し、結果を返す

claim の方式は 2 つ。常時起動 worker(継続的にポーリング)か、webhook 起動ハンドラ(session.status_run_started で起き、ポーリングを始める)です。CLI / SDK の双方に組み込みの worker があり、ant CLI は常時起動のみ、SDK は両方をサポートします。

環境を作る

Console(Workspace > Environments > New > Self-hosted)か、API で作成します。beta header は managed-agents-2026-04-01 です。

curl -sS --fail-with-body 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": "self-hosted", "config": {"type": "self_hosted"}}'

Console で環境を開き Generate environment key を押すと、worker 用の鍵が得られます。worker ホストでは環境 ID と鍵を export します。

export ANTHROPIC_ENVIRONMENT_KEY="sk-ant-oat01-..."
export ANTHROPIC_ENVIRONMENT_ID="env_..."

worker を動かす(ant CLI)

最も簡単なのは ant CLI の常時起動 worker です。ant beta:worker poll が、環境に割り当てられたセッションを claim → skills ダウンロード → 作業ディレクトリでツール実行 → 結果返送、を回します。

ant beta:worker poll --workdir "/workspace"

worker は SIGTERM / SIGINT で in-flight のツール呼び出しをドレインしてから終了します。セッションごとに新しいコンテナで隔離したい(クリーンな FS・リソース制限・ネットワーク制御)場合は、--on-work にスクリプトを渡して、claim ごとにコンテナを spawn します。

ant beta:worker poll --on-work ./spawn.sh

spawn.sh には ANTHROPIC_SESSION_ID / ANTHROPIC_WORK_ID 等がセッション詳細として環境変数で渡るので、それを使って docker run で 1 セッション 1 コンテナを起動できます。

サンドボックスの FS 約束

/workspace: ツール実行と skill ダウンロードの既定作業ディレクトリ。skills は /workspace/skills/<name>/ に落ちる。--workdir を変えたらエージェントの system プロンプトも更新する
/mnt/session/outputs: エージェントが最終出力ファイルを書く場所。コンテナ実行ならここにホストディレクトリをマウントして回収する

worker を動かす(SDK)

SDK には EnvironmentWorker があり、ポーリング・セットアップ・実行を端から端まで面倒見てくれます。.run() は無期限に動いてセッションを拾い続け、SIGTERM できれいに終了します。

import asyncio, os
from anthropic import AsyncAnthropic
from anthropic.lib.environments import EnvironmentWorker

async def main() -> None:
    key = os.environ["ANTHROPIC_ENVIRONMENT_KEY"]
    env_id = os.environ["ANTHROPIC_ENVIRONMENT_ID"]
    async with AsyncAnthropic(auth_token=key) as client:
        await EnvironmentWorker(
            client, environment_id=env_id, environment_key=key, workdir="/workspace",
        ).run()

asyncio.run(main())

webhook 起動にしたい場合は、session.status_run_started を受けて EnvironmentWorker を起動するハンドラを書きます。1 セッションだけ処理して終了する .handle_item() や、自前のコンテナ起動に差し込むための work.poller() も用意されています。

セッションを起動する

worker が動いていれば、その環境を指定してセッションを作るだけです。Anthropic がキューに積み、worker が claim して実行します。ファイルや GitHub リソースのマウントは自社コンテナ側の責任なので、セッション作成時に metadata を渡し、オーケストレーション層がそれを読んでファイルをマウントする、という流れになります。

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    metadata={"input_file": "s3://my-bucket/data.csv"},
)

監視 — work queue の深さを見る

worker フリートを運用するなら、work.stats でキュー状態を見ます。これは worker ホストではなく運用ツール側から、組織 API キーで呼びます(環境鍵ではない点に注意。worker ホストに組織 API キーを置くと、エージェントのツール呼び出しに組織スコープの資格情報を晒すことになります)。

stats = client.beta.environments.work.stats(os.environ["ANTHROPIC_ENVIRONMENT_ID"])
print(f"depth={stats.depth} pending={stats.pending}")

depth: claim 待ちのアイテム数。これを基に worker をスケールさせる / バックログをアラートする
pending: claim 済みで処理中のアイテム数
oldest_queued_at: キュー最古アイテムの時刻(空なら null)
workers_polling: 直近 30 秒にポーリングした worker 数。死活監視に使う

セッションを丁寧に止めたいときは work.stop を使います(force: true で即時中断)。

何に使えるか

データを境界外に出せない規制業界で、エージェントにツールを使わせたい
公開されていない内部サービス(社内 DB・内部 API)にエージェントから到達したい
既存のサンドボックス基盤(Cloudflare / Daytona / Modal / Vercel 等。公式に個別ガイドあり)にツール実行を載せたい

注意点として、self-hosted sandboxes ではまだ agent memory は未対応です。メモリ前提のエージェントを組んでいる場合は、現時点ではクラウド環境との使い分けが要ります。

まとめ

self-hosted sandboxes は、Managed Agents の「賢いオーケストレーションは Anthropic に任せたいが、ツール実行は自社の中に閉じたい」という要件を満たす機能です。environment worker がワークキューを介して Anthropic と繋がり、ツール実行・FS・egress を自社が握ります。ant CLI なら 1 コマンド、SDK なら EnvironmentWorker で動かせます。

実行を社内に閉じたうえで社内 MCP サーバーにも繋ぎたいなら、MCP tunnels と併用するのが筋の良い構成です。Managed Agents の全体像は入門記事を参照してください。

release notes タグで Anthropic / Claude のリリース情報を継続フォローしています。

参考

Self-hosted sandboxes — 公式ドキュメント
Claude Platform リリースノート(API)
当ブログ: Claude Managed Agents(beta)実践入門
当ブログ: Claude の MCP tunnels で社内 MCP サーバーへ繋ぐ