Self-hosted SandboxとMCP Tunnelの違いは何ですか？

Self-hosted Sandboxは「エージェントのコードが実行される場所」を自社インフラに移す機能で、MCP Tunnelは「Anthropic側から社内の私設MCPサーバーに到達するための通信経路」を提供する機能です。前者は実行ロケーションの制御、後者はネットワーク到達性の制御に関するもので、独立した機能として組み合わせて使えます。

完全にオンプレミスでClaudeエージェントを動かせますか？

2026年5月時点では完全なオンプレ運用はできません。Self-hosted Sandboxを使ってもエージェントのオーケストレーション（コンテキスト管理・エラー回復・エージェントループ自体）はAnthropic側のインフラに残るため、ツール実行のみが自社インフラ側で動く構成になります。AWS Bedrock経由の「Claude Platform on AWS」ではSelf-hosted Sandboxは未対応です。

対応プロバイダはどこですか？自前で実装することもできますか？

Cloudflare、Daytona、Modal、Vercelの4社がマネージドプロバイダとして公式ガイドを提供しています。これらを使わずに自社のKubernetesクラスタやDockerホスト上に環境ワーカーを直接デプロイすることも可能で、Anthropicは`ant`CLIとSDK（Python、TypeScript、Go）でワーカーの実装ヘルパーを提供しています。

MCP Tunnelの通信は誰が見られるのですか？

Anthropicは内部TLS終端後にペイロードを処理しますが、トランスポートを担うCloudflareはペイロードの中身を読めません。Cloudflareが観測できるのは、cloudflaredが動くホストのegress IP、ホストのフィンガープリント、接続タイミング、バイト量、テナントに割り当てられた`*.tunnel.anthropic.com`サブドメインの4種類のメタデータのみです。Cloudflareはこのリサーチプレビューにおいてサブプロセッサとして扱われます。

いつから利用できますか？料金は？

Self-hosted Sandboxは2026年5月19日からパブリックベータで提供開始されており、Claude Managed Agentsの利用契約があれば追加申請なしで使えます。MCP Tunnelはリサーチプレビュー段階で、`claude.com/form/claude-managed-agents`からのアクセス申請と承認が必要です。両機能ともAnthropic側の料金は通常のAPI課金に含まれますが、プロバイダ側のインフラ費用（Cloudflare WorkersやModalのコンテナ実行費用など）は別途発生します。

AI News 2026年5月21日 26分で読める

Claude Managed Agentsを自社インフラで動かす｜Self-hosted Sandbox & MCP Tunnel

#Claude #Anthropic #Managed Agents #MCP #セキュリティ #エンタープライズ #Cloudflare

「コンプライアンスチームこそが本番エージェントの真のボトルネックだ。モデルではない」。InfoQの技術解説記事が業界の声として引用したこの一行は、企業でAIエージェントを動かそうとした経験のあるPMやエンジニアなら共感する人が多いだろう。

セキュリティチームが2か月かけて承認したサンドボックスに、エージェントが入っていく。SOC2やHIPAAの監査対象になっている社内データには絶対に触らせない。AWSのプライベートサブネットに置いた検索APIには、Anthropic側からは直接届かない。そういう壁の前で、PoCが本番に進まない案件は実在する。

2026年5月19日、Anthropicがロンドンで開催したCode with Claudeイベントで、この壁を低くするための2機能が発表された。Self-hosted Sandbox（パブリックベータ）とMCP Tunnels（リサーチプレビュー）だ。前者はツール実行を自社インフラに移し、後者は社内の私設MCPサーバーに到達するための通信経路を作る。

この記事はこんな人におすすめ

Claude Managed AgentsやMessages APIを業務用エージェントに使っているPM・エンジニア
機密データやコンプライアンス要件のあるエージェントを社内本番に出したいシステム設計者
自社インフラ上でAIエージェントのツール実行を完結させたい情シス担当者

2機能が解決する問題は別物だ

両機能はよく一括して紹介されるが、解決する問題は別だ。整理する。

機能	制御するもの	ステータス	主なユースケース
Self-hosted Sandbox	エージェントのコードがどこで実行されるか	パブリックベータ	データレジデンシー要件、独自ランタイム、長時間のビルド・画像生成
MCP Tunnels	Anthropicが社内の私設MCPに到達する経路	リサーチプレビュー（申請必須）	社内DB・社内API・チケッティング・ナレッジベースをエージェントに接続

両者は独立しており、Anthropicのクラウドコンテナで動くセッションがMCP Tunnel経由で社内サーバーを呼ぶこともできるし、Self-hosted Sandboxセッションが公開MCPサーバーを使うこともできる。「実行場所」と「ツール到達経路」の2つの制御点があると考えるとわかりやすい。

DEV Communityで紹介された使い分けの指針は明確だ。「私設MCPサーバーがある → Tunnel」「データレジデンシー要件がある → Self-hosted Sandbox」「両方ある → 両方を組み合わせる」（The Gateway Guy）。

Self-hosted Sandboxの仕組み：オーケストレーションは残し、実行だけ動かす

Self-hosted Sandboxは、Anthropic公式ドキュメントが「Anthropicがオーケストレーションを残したまま、ツール実行のみ顧客制御のインフラに移動させる」と表現する設計だ（platform.claude.com）。

具体的には、Anthropic側に残るのは次の要素だ。

エージェントループ（思考と次のアクションを決める処理）
コンテキスト管理（メモリ・履歴の保持）
エラーリカバリ
セッションの状態遷移管理

逆に顧客側に移るのは下記。

ツール実行（bash、read、write、edit、glob、grepなどのツール呼び出し）
ファイルシステム（/workspace配下の作業ディレクトリ）
ネットワーク到達（社内サービスへの到達はすべて顧客の責任）
スキル（Skills）のダウンロードと配置

InfoQの解説では、これを「実行（execution）と協調（coordination）の分離」と位置付け、「データレジデンシー要件は内部にリポジトリとサービスを置き続けることで満たされる」と整理している（InfoQ）。

環境ワーカーの基本構造

実装はシンプルだ。**環境ワーカー（Environment Worker）**と呼ばれるプロセスを自社インフラで動かし、Anthropic側のワークキューをポーリングする。セッションがアサインされると、ワーカーが該当のスキルをダウンロードし、ツール呼び出しをローカルで実行して結果をAnthropic側に返す。

antCLIを使う場合の最小構成は以下のようになる（公式ドキュメントから引用）。

# 1. 環境キーを設定
export ANTHROPIC_ENVIRONMENT_KEY="sk-ant-oat01-..."
export ANTHROPIC_ENVIRONMENT_ID="env_..."

# 2. ワーカーを起動（インプロセス実行）
ant beta:worker poll --workdir "/workspace"

セッション単位の強固な分離が必要な場合は、--on-work spawn.shオプションでスクリプトを呼び出し、各セッションを新しいコンテナで実行する構成が推奨されている。コンテナ内でClaudeのスキルを実行することで、ファイルシステム・リソース上限・ネットワーク制御をセッションごとに分けられる。

SDKを使う場合は、EnvironmentWorkerという抽象が提供されている。Pythonの最小例は次のようになる。

from anthropic import AsyncAnthropic
from anthropic.lib.environments import EnvironmentWorker

async with AsyncAnthropic(auth_token=environment_key) as client:
    await EnvironmentWorker(
        client,
        environment_id=environment_id,
        environment_key=environment_key,
        workdir="/workspace",
    ).run()

4つのマネージドプロバイダの違い

自前のKubernetesクラスタで動かしてもよいが、現実的にはマネージドサンドボックスプロバイダを使うことになる。InfoQの技術解説と各社の公式ドキュメントをまとめると下表のような違いがある。

プロバイダ	強み	想定ワークロード
Cloudflare	MicroVM、ゼロトラスト、エグレスプロキシ制御。Workers VPCでプライベートサービス到達	大量並列・短時間ジョブ、ブラウザ自動化
Daytona	フル状態保持のLinux環境、SSH・プレビューURLアクセス可	長時間セッション、IDEライクな対話的開発
Modal	サブ秒のコンテナ起動、GPU対応	AI推論、画像生成、機械学習タスク
Vercel	ミリ秒起動のVM、VPCピアリング、認証情報注入	既存のVercelスタックと統合した運用

Cloudflare公式ブログは「最もシンプルで最もセキュア、そして最もプログラマブルなエージェントクラウド」と自社を位置付け、Workersベースの制御プレーンと数万件の並列エージェントへのスケーリングを訴求している（Cloudflare Blog）。

制約事項

公開ドキュメントから読み取れる現時点（2026年5月時点）の制約は以下のとおりだ。

Memory機能は未対応：エージェントのメモリ機能はSelf-hosted Sandbox環境では使えない
Claude Platform on AWSでは未提供：Anthropic公式が認める制約
/bin/bashの固定パス依存：SDKヘルパーは/bin/bashの存在を前提とする。TypeScript SDKは追加でunzip、tar、Node.js 22以降が必要
オーガニゼーションAPIキーをワーカーホストに置かない：環境キーで認証する設計のため、ワーカー側に組織スコープのAPIキーを置くとエージェントのツール呼び出しから組織権限が漏れる危険がある（公式ドキュメントに明記された警告）

MCP Tunnels：エージェントが社内VPNなしで私設DBに届く

MCP TunnelsはClaudeエージェントを社内ネットワークの私設MCPサーバーにインバウンドポートを開けずに接続させる仕組みだ。インバウンドファイアウォール変更や公開エンドポイントの追加が不要で、社内DB、社内API、ナレッジベース、ticketingシステムなどをツール化できる。

3層のセキュリティモデル

公式ドキュメントが定義する保護層は3つに分かれる（platform.claude.com）。

外側のmTLS（AnthropicとCloudflare間）：未承認のクライアントがトンネルに到達することを防ぐ
内側のTLS（AnthropicバックエンドからユーザーのProxyまで）：トランスポートプロバイダや経路上の中間者がペイロードを覗くことを防ぐ
MCPサーバー側のOAuth：認証済みのトンネルトラフィックでもMCPツールを未承認で呼ばれないようにする

ペイロードはユーザー側のProxyでのみ復号される。Anthropicの認証済みCA証明書がない限りトンネル接続自体が確立しないため、「Cloudflareが平文を読める設定」は構造的に存在しない。

ただし、Cloudflareがメタデータとして観測できる情報はある。cloudflaredが動くホストのegress IP、cloudflaredホストのフィンガープリント、接続のタイミングとバイト量、テナント固有の*.tunnel.anthropic.comサブドメインの4種類だ。AnthropicとCloudflareの契約でこのテレメトリの用途は制限されており、Cloudflareは本リサーチプレビューにおいてサブプロセッサとして扱われる、と公式に明記されている。

デプロイ構成

トンネルは2コンポーネントのスタックで動く。

cloudflared：トンネルエージェント。Anthropic運営のトンネルエッジに対してアウトバウンドのみの接続を張る
Proxy：Anthropicが提供するルーティングコンポーネント。内側のTLSを終端し、上流IPの妥当性検証と、ホスト名ベースで上流MCPサーバーへ振り分ける

社内に公開するMCPサーバーごとに、テナントのトンネルドメイン配下にホスト名が割り当てられる（例：docs.<tunnel-domain>）。Managed Agentsのコンソール画面でセッションにこのホスト名を紐付けるか、Messages APIのmcp_servers配列で渡せば、エージェントから呼べる状態になる。

Messages APIから呼び出すサンプル（公式ドキュメントから引用）は下記のようになる。

curl https://api.anthropic.com/v1/messages \
  -H "anthropic-beta: mcp-client-2025-11-20" \
  -d '{
    "model": "claude-opus-4-7",
    "mcp_servers": [{
      "type": "url",
      "url": "https://echo.YOUR_TUNNEL_DOMAIN_HERE/mcp",
      "name": "echo"
    }],
    "tools": [{"type": "mcp_toolset", "mcp_server_name": "echo"}]
  }'

URLがhttps://echo.<your-tunnel-domain>/mcpのように見える点を除けば、通常のリモートMCPサーバーを使う場合と同じインターフェースだ。

認証・運用上の注意点

トンネルトークンとTLS秘密鍵を両方流出させない：Anthropic公式が「攻撃者がこの2つを揃えてしまうと、Proxyを偽装してMCPリクエストペイロードを読める」と明示している
Workload Identity Federation推奨：Kubernetesクラスタ、クラウドIAM、SPIFFEなどのOIDC IdPがあるならプログラマティックアクセス経由でトンネルトークンを短期で発行・回転させる構成が公式推奨
可用性コミットメントなし：「as-is」で提供され、稼働率SLAはない。Cloudflareの可用性にも依存する
claude.aiのコネクタには現状非対応：コンソールで作ったトンネルはclaude.ai側のコネクタには出てこない（API・Managed Agents経由のみ）

光と影：何が解決され、何が残るか

解決される問題

これまで「PoCはClaudeで作ったが、本番では社内データに触れないので使えない」というケースが多かった。MCP Tunnelsで社内システムへの到達経路ができ、Self-hosted Sandboxで実行ロケーションが社内側に移ることで、データレジデンシー要件のある組織でもエージェントを動かせるようになる。

Cloudflareなどのプロバイダを使えば、microVMによるテナント分離、エグレスプロキシ制御、ゼロトラスト認証情報注入といったセキュリティ機能を顧客側で重ねられる。コンプライアンス監査に対する説明がしやすくなる。

残る限界

一方で、「完全オンプレミス」を求める組織には不十分な解決だ。

オーケストレーションはAnthropic側：エージェントループ・コンテキスト管理・状態遷移は依然としてAnthropicのインフラで動く。完全なエアギャップ環境では使えない
AWS Bedrockルートでは未対応：Bedrock経由の「Claude Platform on AWS」ではSelf-hosted Sandboxは現時点で提供されていない
MCP Tunnelはリサーチプレビュー：稼働率コミットがなく、本番クリティカルなワークフローには慎重さが要る
第三者依存：トンネルのトランスポートにCloudflareを使うため、Cloudflareの障害がそのまま伝搬する
複雑性の増加：cloudflared、Proxy、CA証明書管理、Workload Identity Federationなど、運用要素が一段増える

The Gateway Guy氏は「これらはどれもClaudeを賢くするための機能ではない。実際のエンタープライズセキュリティ境界の中で安全に動かすための機能だ」と整理しており、この見立てが本質を捉えていると思う。

自分（電脳狐影）ならこう判断する

PMの立場でこの2機能を見ると、判断基準は「セキュリティ要件」と「PoC〜本番のステージ」の2軸になる。

Self-hosted Sandboxは「使える」場面が広い。パブリックベータでアクセス申請も不要、しかも既存のCloudflareやVercelに乗っているなら追加のインフラ判断がほぼいらない。「とりあえずワーカーをデプロイして試す」のハードルは低いから、コンプライアンスチームと話す前段のPoCで使い始める価値がある。

MCP Tunnelsはまだ慎重に。リサーチプレビューで稼働率SLAがなく、Cloudflare依存がある時点で「本番で動かす」決断は早い。代わりに、トンネル経由でアクセスする予定の社内API側を「もしトンネルが正式版になったらこう繋ぐ」設計レビューに使うのが現実的だ。実際の繋ぎ込みは正式版を待つ。

両機能を組み合わせた完全なエンタープライズ向け配置（実行も社内、MCPも社内）は、規制業界（金融・医療・公共）でPoCの突破口になる。営業視点では「Anthropicは完全オンプレではないが、データレジデンシー要件は満たせる」というメッセージで話を進められる。

既存の選択肢との比較

完全オンプレを求めるなら、現時点ではAWS Bedrock + Claude on AWS（ただしSelf-hosted Sandbox未対応）か、Llama・DeepSeekなどのオープンウェイトモデルを自社で動かす道がある。前者はAnthropic公式のモデル品質を維持できるが、Self-hosted Sandboxほどの実行制御はできない。後者は完全な実行制御を得られるが、モデル品質と運用負荷のトレードオフがある。Anthropicの今回の発表は、この2極の中間を狙う層に向けた解決策だ。

アクセス方法とドキュメント

Self-hosted Sandbox（パブリックベータ）

申請不要。Managed Agentsの利用契約があればコンソールから直接環境を作成可能
公式ドキュメント：platform.claude.com/docs/en/managed-agents/self-hosted-sandboxes
ベータヘッダー：managed-agents-2026-04-01
プロバイダ別ガイド：Cloudflare、Daytona、Modal、Vercel各社の公式ドキュメントにClaude Managed Agents向けのチュートリアルが用意されている

MCP Tunnels（リサーチプレビュー）

アクセス申請が必要：claude.com/form/claude-managed-agents
公式ドキュメント：platform.claude.com/docs/en/agents-and-tools/mcp-tunnels/overview
ベータヘッダー：mcp-client-2025-11-20
必要なインフラ：KubernetesクラスタまたはDocker/Docker Composeが動くVM
「as-is」提供で稼働率コミットメントなし

まとめ

Self-hosted SandboxとMCP Tunnelsは、Claudeエージェントを「コンプライアンスチームが本番にGoサインを出せる」状態に近づけるための機能だ。前者は実行ロケーションを動かし、後者はネットワーク到達経路を作る。組み合わせるとデータレジデンシー要件のあるエンタープライズでも本番運用に踏み込める。

ただし完全なオンプレ運用にはまだ届かない。オーケストレーションはAnthropic側に残るし、MCP Tunnelはリサーチプレビュー段階だ。Anthropicが今後のCode with Claudeイベントや製品アップデートで、どこまで「Claude Platformから出ない」設計に踏み込むかが焦点になる。

「セキュリティチームが2か月かけて承認するサンドボックス」を待っていたPoCがあるなら、Self-hosted Sandboxは今週からでも触れる。MCP Tunnelは申請を出しておいて、正式版を待つ準備をするのが筋がいい。

Claude Managed Agentsの最新情報は claude.com/blog で随時更新されている。Self-hosted SandboxとMCP Tunnelsの発表記事は claude.com/blog/claude-managed-agents-updates で読める。

詳しく見る

関連記事

本記事の情報は2026年5月21日時点のものです。Self-hosted SandboxはパブリックベータでMCP Tunnelsはリサーチプレビュー段階であり、機能仕様・価格・提供条件は予告なく変更されることがあります。最新情報は公式ドキュメント（platform.claude.com）を参照してください。