結論：2026年5月19日にAnthropicが追加した「自社サンドボックス（public beta）」と「MCPトンネル（research preview）」は、AIエージェントを社内データにつなぐときの最大の不安——「コードはどこで動くのか」「データはどこを通るのか」——を企業の境界の内側に閉じ込めて解決する機能です。エージェントの頭脳はAnthropic基盤に残したまま、ツール実行と社内システムへの到達だけを自社の管理下に移せます。
この記事の要点
- 自社サンドボックス：ツール実行を自社インフラ、またはCloudflare・Daytona・Modal・Vercelのマネージドプロバイダに移せる。エージェントのループ自体はAnthropic基盤に残る（public beta）
- MCPトンネル：社内ネットワーク内のMCPサーバーに、公開インターネットへ晒さずアウトバウンド1接続だけで到達できる（research preview・申請制）
- 情シスの見るべき3点：①どこでコードが実行されるか ②データはどのネットワークを通るか ③監査ログとデータ所在をどこまで自社で握れるか
対象読者：情報システム部門・セキュリティ担当・AI導入の意思決定者。読了後にできること：自社でAIエージェントを社内データにつなぐ際の「実行場所・通信経路・監査」のチェックリストを、社内説明に使える形で持ち帰れます。
「AIエージェントに社内の顧客データベースを触らせて、自動でレポートまで作らせたい。でも、それって結局うちのデータが外に出るってことですよね？」
これは、企業向けのAI研修やClaude導入支援をしていて、情シスやセキュリティ担当の方からほぼ毎回聞かれる質問です。経営層は「早く使え」と言う。現場は「便利そう」と乗り気。でも止めるのはたいてい情シスで、その理由はだいたい同じ——「データがどこを通って、コードがどこで動いているのか、説明できないから稟議が通せない」。正直、これはまったく正しい慎重さなんです。
2026年5月19日、Anthropicがこの「説明できない」を真正面から潰しにくる機能を、Claude Managed Agentsに2つ追加しました。自社サンドボックス（self-hosted sandboxes）とMCPトンネル（MCP tunnels）です。ざっくり言うと「エージェントの頭脳はAnthropicに置いたまま、手足が触る場所と、つなぎ先の社内システムだけを自社の壁の内側に閉じ込められる」という話。情シスが一番気にする「実行場所」と「通信経路」を、初めてまとめてコントロールできるようになった、というのが今回のキモです。
この記事では、この2機能が技術的に何をしているのかを情シス・セキュリティ担当の目線で噛み砕き、betaなのか正式版なのか、どのプロバイダに対応しているのか、中小企業でも現実的に使えるのかまで、出典付きで整理します。なお本記事は発表直後（2026年5月時点）の公式情報・報道に基づく解説であり、弊社が本番運用で性能を測定した数字ではない点は最初にお断りしておきます。AIエージェント導入そのものの全体像はAI導入戦略の完全ガイドで体系的にまとめているので、あわせて読むと位置づけが分かりやすいはずです。
そもそも何が「不安」だったのか — 情シスが止めていた理由
新機能の解説に入る前に、なぜこの2機能が「ありがたい」のかを整理しておきます。ここを飛ばすと、機能のすごさが伝わらないんです。
生成AIの導入は、2024〜2025年あたりまでは「チャットでQ&Aする」「文章を要約する」といった、社内データに直接触れない使い方が中心でした。この段階なら情シスもそこまで身構えません。せいぜい「機密情報を貼り付けるな」というルール周知で済む。
ところが、AIエージェントの時代になると話が変わります。エージェントは自律的に動き、社内のデータベースを参照し、APIを叩き、ファイルを生成します。「人間が貼り付けた情報だけを見る」のではなく「自分で社内システムに取りにいく」。ここで情シスの警報が一斉に鳴るわけです。具体的には次のような不安です。
| 情シスの不安 | 従来の状態 |
|---|---|
| 実行環境の所在 | エージェントがコードを実行する場所がベンダー側にあり、説明しづらい |
| 社内システムの露出 | クラウドのエージェントに届かせるには、社内サーバーを公開する必要があった |
| クレデンシャルの持ち出し | 接続情報やトークンをエージェント側に渡すと、境界の外に出てしまう |
| 監査・ログ | 「誰が・何に・いつアクセスしたか」を自社の監査基準で取れるか不透明 |
顧問先のある中堅企業（製造業）で、まさにこの議論で導入が3か月止まったことがあります。現場は「在庫データをAIに見せて発注の下書きを作らせたい」と乗り気。でも情シスが「在庫DBをインターネットに晒すのは無理」と。結局そのときは社内の閉域に小さな仕組みを別途作って凌いだのですが、今回のMCPトンネルがあれば、この手の膠着はかなり減るはずなんです。
何が発表されたのか — 2機能の全体像
まず事実関係を時系列と一覧で押さえます。ここは断定できる範囲だけを書きます。
| 項目 | 内容 |
|---|---|
| 発表日 | 2026年5月19日 |
| 対象 | Claude Managed Agents（およびMessages API） |
| 機能1 | 自社サンドボックス（self-hosted sandboxes）— public beta |
| 機能2 | MCPトンネル（MCP tunnels）— research preview（申請制／access request required） |
| 設定場所 | Claude Console の組織設定（organization settings） |
ここで早速、情シス的に重要な注意点が1つあります。2つの機能で提供ステータスが違うことです。一部の海外報道では両方をまとめて「ベータ」と書いているものもありますが、公式ブログとInfoQの報道を突き合わせると、自社サンドボックスはpublic beta、MCPトンネルはresearch preview（申請して使う段階）です。本番の基幹システムに組み込む前提で考えるなら、この成熟度の差は稟議の前提条件として正確に押さえておくべきところです。
Claude Managed Agentsそのもの（Anthropicが運用基盤を提供し、企業がAIエージェントを動かす仕組み）については、AIエージェント導入の完全ガイドで基礎から解説しています。今回の発表は「その基盤に、企業のセキュリティ境界を尊重するためのオプションが2つ増えた」と捉えると分かりやすいです。
自社サンドボックスとは — 「手足の置き場所」を自社に移す
AIエージェントは、ただ文章を返すだけでなく、コードを実行したり、ファイルを読み書きしたり、APIを叩いたりします。この「実際に何かを実行する隔離環境」がサンドボックスです。従来はこの実行環境もAnthropic側にありました。つまり、エージェントが触るファイルやパッケージ、サービスがAnthropicの基盤の上に乗っていたわけです。
今回の自社サンドボックスは、このツール実行（tool execution）の場所を自社インフラ、またはマネージドプロバイダ側に移せる機能です。重要なのは「全部が自社に来るわけではない」という分担です。
| レイヤー | 役割 | どこで動くか |
|---|---|---|
| エージェントループ | オーケストレーション・コンテキスト管理・エラー回復 | Anthropic基盤に残る |
| ツール実行 | コード実行・ファイル読み書き・サービス呼び出し | 自社が指定した環境へ移せる |
公式ブログの表現を借りると「機微なファイル・パッケージ・サービスを自社のインフラ、またはマネージドのサンドボックスプロバイダに置ける。オーケストレーション・コンテキスト管理・エラー回復を担うエージェントループはAnthropicの基盤に残り、ツール実行だけが自社の構成した環境に移る」という設計です。
情シスの観点で噛み砕くと、こうです。「AIが考える脳みそはAnthropicのクラウドにある。でも、実際に手を動かして社内の機微なファイルを開けたりコードを走らせたりする”作業台”は、うちの敷地内に置ける」。データの実体と実行が境界の内側に留まるなら、データ所在（data residency）やネットワークポリシー、監査ログを自社の基準で握れる。これが稟議を通す決定打になります。
対応するマネージドサンドボックスプロバイダ
「自社インフラに置く」と聞くと、自前でKubernetesクラスタを立てて……と身構えるかもしれませんが、マネージドプロバイダを使えば計算リソースと隔離の面倒を任せられます。発表時点で名前が挙がっているのは次の4社です。
| プロバイダ | 特徴（報道ベース） |
|---|---|
| Cloudflare | マイクロVM、ゼロトラストネットワーク、アウトバウンド通信の制御 |
| Daytona | 長時間稼働・ステートフルな環境、SSHやプレビューURLでアクセス可能 |
| Modal | AIワークロード向け、CPU/GPUをスケーラブルに割り当て |
| Vercel | サンドボックス隔離＋VPCピアリング＋クレデンシャル注入 |
正直、この4社のラインナップは「すでにモダンなクラウド開発をしている会社なら、どれか1つは触ったことがある」という顔ぶれです。逆に言うと、オンプレ中心でこれらをまったく使っていない企業にとっては、新規にプロバイダ契約と運用設計が必要になる、という現実も同時に意味します。ここは後半の「中小企業でも使えるのか」で正直に書きます。
プロバイダ選びの観点を実務目線で1つだけ補足しておくと、「すでに自社のクラウド環境がどのベンダーに寄っているか」を起点に選ぶのが鉄則です。たとえば、すでにVercelでフロントをホストしているチームなら、VPCピアリングやクレデンシャル注入の運用に慣れているのでVercelのサンドボックスに乗せやすい。Cloudflareでゼロトラスト網を組んでいる会社なら、アウトバウンド制御の延長で考えられる。「機能比較表で一番強そうなものを選ぶ」のではなく、「既存の運用と地続きなものを選ぶ」ほうが、結局のところ事故が少ないです。新しいベンダーを1社増やすたびに、契約・監査・障害対応の経路が1つ増えることを忘れないでください。
MCPトンネルとは — 「社内サーバーに穴を開けずにつなぐ」
もう1つの目玉がMCPトンネルです。MCP（Model Context Protocol）は、AIエージェントに社内のデータベース・API・ナレッジベース・チケットシステムなどをツールとして接続するための標準プロトコルで、すでに企業導入の事実上の標準になりつつあります。MCPそのものの仕組みはClaude周辺の用語解説でも触れていますが、ここで問題になるのが「その社内MCPサーバーに、クラウド上のエージェントがどうやって届くのか」です。
従来、外部から社内サーバーに届かせようとすると、だいたい次のどちらかでした。どちらも情シスとしては気が重い選択です。
- ❌ 社内MCPサーバーをインターネットに公開する（インバウンドのファイアウォール穴あけ、公開エンドポイント）
- ❌ VPNやリバースプロキシを別途構築して経路を作り込む
MCPトンネルは、この発想を逆転させます。自社に軽量なゲートウェイを1つ立て、そこからAnthropic基盤に向かってアウトバウンドの暗号化接続を1本だけ張る。インバウンドのファイアウォールルールも、公開エンドポイントも不要。通信はエンドツーエンドで暗号化される、という設計です。
| 観点 | 従来の公開方式 | MCPトンネル |
|---|---|---|
| ファイアウォール | インバウンドの穴あけが必要 | インバウンド不要（アウトバウンドのみ） |
| 公開エンドポイント | 必要（攻撃対象になる） | 不要 |
| 通信の暗号化 | 構成次第 | エンドツーエンドで暗号化 |
| 社内サーバーの露出 | インターネットに晒される | 晒さない |
セキュリティ担当として一番ありがたいのは「インバウンドの穴を開けなくていい」という一点に尽きます。社内システムを外部に届かせる案件で、稟議が止まる最大の理由が「公開エンドポイントを作りたくない」だからです。アウトバウンド1本に閉じられるなら、攻撃対象領域（アタックサーフェス）が劇的に小さくなる。ここは構造として正しい方向だと思います。
VentureBeatはこの機能を「クレデンシャルを漏らさずに企業APIへつなげるようになった」という切り口で報じています。社内システムへの接続情報やトークンを、エージェント側にベタ書きして外に持ち出すのではなく、境界の内側に留めたままつなげる、という発想です。
この「クレデンシャルを境界の外に出さない」という点は、実は情シスにとって地味だけど決定的に重要です。AIエージェント関連のインシデントで、技術的に高度なものより圧倒的に多いのが「APIキーやトークンがどこかに残って漏れた」という、ある意味”古典的”な事故なんです。エージェントの設定ファイル、ログ、プロンプト履歴——トークンが紛れ込む場所は無数にあります。社内システムへの到達経路そのものを境界内のゲートウェイに閉じてしまえば、そもそもクレデンシャルを外に渡す機会が減る。攻撃面を減らすだけでなく、「うっかり漏らす」事故の母数を減らせる、というのが実務的なメリットです。AIエージェント全般のセキュリティ論点は、過去記事のAIエージェント導入ガイドでも整理しているので、社内のリスク評価の下敷きに使ってください。
MCPトンネルの構成イメージ（ざっくり）
細かい実装は公式ドキュメントに譲りますが、情シスが頭に描いておくべき構成はシンプルです。
- 社内ネットワークに、軽量なゲートウェイ（小さなプロセス）を1つ立てる
- そのゲートウェイが、Anthropic基盤に向かってアウトバウンド方向に1本だけ暗号化接続を張る
- エージェントが社内MCPサーバーを呼ぶときは、この既存のアウトバウンド接続の上を通る
- 社内MCPサーバーは外部に公開されず、ファイアウォールのインバウンドは一切開けない
ポイントは「接続を張るのは社内側から外へ」という方向です。社内から外へのアウトバウンド通信は、たいていの企業でもともと許可されています。だから新規にファイアウォールの穴あけ申請をしなくて済む——これが運用上、想像以上に効きます。インバウンドの穴あけは、社内の情報セキュリティ委員会の審査やペネトレーションテストの対象になりがちで、ここを回避できるだけで導入のリードタイムが数週間単位で縮むことも珍しくありません。
情シスが本当に確認すべき3つの問い
機能の説明はここまでにして、ここからが本題です。100社以上のAI導入を見てきた経験から言うと、この手の発表で情シスが押さえるべき問いは結局3つに集約されます。発表のキャッチコピーに流されず、この3つで自社の状況を点検してください。
問い1：コードはどこで実行されるのか？
自社サンドボックスを使えば、ツール実行は自社が指定した環境（自社インフラ or 4プロバイダ）に移ります。ただしエージェントループ（プロンプトやコンテキストの処理）はAnthropic基盤に残るのはこれまで通りです。「実行環境を自社に移した＝すべてのデータ処理が自社内で完結する」ではない点は、社内説明で誤解を生みやすいので正確に伝える必要があります。
問い2：データはどのネットワークを通るのか？
MCPトンネルを使えば、社内MCPサーバーへの到達は「自社ゲートウェイ→Anthropic」のアウトバウンド暗号化接続経由になります。社内サーバー自体は公開されません。一方で、エージェントが処理する文脈（プロンプトに含まれる情報など）はAnthropic基盤を経由します。「データの実体が社内に留まる経路」と「文脈として一時的に処理される経路」を分けて整理すると、データ保護方針との突き合わせがしやすくなります。
問い3：監査・ログ・データ所在をどこまで自社で握れるか？
報道では、自社サンドボックスによってネットワークポリシー・監査ログ・ランタイム構成・データ所在（data residency）を企業側でより強くコントロールできる、とされています。ただし「具体的にどのログがどの粒度で取れるか」はプロバイダ構成と契約によって変わるため、ここは導入前に必ず実機とドキュメントで確認すべきポイントです。発表文の「コントロールできる」を額面通り信じず、自社の監査要件にマッピングして検証してください。
賛否両論 — 楽観と慎重、両方の声
新機能はつい「これで全部解決」と書きたくなりますが、それは記事として不誠実です。実務目線で楽観論と慎重論を並べます。
楽観論：稟議が通るようになる
- AIエージェントを社内データにつなぐ際の「実行場所」「通信経路」という、情シスが止めていた2大論点に正面から答えている
- インバウンドのファイアウォール穴あけが不要になり、アタックサーフェスが小さくなる
- Cloudflare・Vercelなど既存のモダンクラウド資産を持つ企業なら、追加投資が比較的小さい
- データ所在や監査ログを自社基準で握れる方向性は、規制業種（金融・医療など）の導入の障壁を下げる
慎重論：まだ過信は禁物
- MCPトンネルはresearch preview（申請制）。基幹システムへの本番組み込みを今すぐ前提にするのは早い
- エージェントループはAnthropic基盤に残るため「完全に自社内で完結」ではない。社内説明で誇張すると後で齟齬が出る
- 監査ログの粒度・データ所在の保証範囲は構成依存。発表文の「コントロールできる」を鵜呑みにしない
- InfoQの記事では、Anthropic純正コネクタ（Anthropic基盤を経由する連携）とトンネルの組み合わせに関する疑問も開発者から出ている。連携の相性は要検証
- オンプレ中心でプロバイダを使っていない企業は、新規のプロバイダ契約・運用設計コストが発生する
研修現場でよく言うのですが、新機能は「使える/使えない」の二択ではなく「どの成熟度なら自社のどの業務に当てられるか」で考えるべきです。今回で言えば、自社サンドボックス（public beta）は検証〜限定本番、MCPトンネル（research preview）はPoC・検証フェーズ、という温度感で扱うのが、現時点では現実的だと思います。
日本企業・中小企業への影響 — 現実的に使えるのか
ここが一番聞かれるところです。結論から言うと、「使えるが、企業の現在地によって難易度がまったく違う」というのが正直な評価です。
使いやすい企業
| 条件 | 理由 |
|---|---|
| すでにCloudflare/Vercel等を使っている | 対応プロバイダの運用ノウハウが既にあり、追加投資が小さい |
| 社内に開発・インフラ運用の人材がいる | ゲートウェイの設置・サンドボックス構成・監査設計を内製できる |
| 規制で外部処理に制約がある業種 | データ所在をコントロールできる方向性が、そもそもの導入可否を変える |
ハードルが高い企業
| 条件 | 課題 |
|---|---|
| 情シスが1〜数名・兼任体制 | ゲートウェイ運用・監査ログ確認の継続的なリソースが確保しづらい |
| オンプレ中心でクラウド資産が薄い | 対応プロバイダの新規契約・設計から始める必要がある |
| そもそもMCPサーバーをまだ持っていない | つなぐ先（社内MCPサーバー）の構築が先に必要 |
身も蓋もない話をすると、中小企業の場合「この機能を使いこなす前に、つなぐ先の社内MCPサーバーがそもそも無い」というケースが多いです。順番としては、まず社内データをMCP経由でAIに見せられる状態を作り、その上で「外に晒したくない部分だけトンネルで閉じる」という流れになります。いきなりトンネルから入るものではない、という点は押さえておきたいところです。
企業がとるべきアクション — 今日から着手できる5つ
発表を「すごいね」で終わらせず、自社の状況に落とすための具体的なアクションを5つ挙げます。情シス・セキュリティ担当がそのまま社内の検討材料に使える粒度にしています。
アクション1：自社のAIエージェント利用で「実行場所」を棚卸しする
現在、社内で使っているAI機能がコードやツールを実行する場合、それがどこで動いているのかを一覧化します。「実行場所が説明できない機能」を洗い出すのが第一歩です。
アクション2：つなぎたい社内システムを「公開可否」で分類する
顧客DB・基幹API・チケットシステムなど、AIにつなぎたい候補を「絶対に外に出せないもの」「条件付きで可」に分類します。前者がMCPトンネルの主対象になります。
アクション3：対応プロバイダの保有状況を確認する
Cloudflare・Daytona・Modal・Vercelのいずれかを既に使っているか、運用できる人材がいるかを確認します。ここが「使いやすさ」を大きく左右します。
アクション4：成熟度に応じてフェーズを切る
自社サンドボックス（public beta）は限定検証から、MCPトンネル（research preview・申請制）はPoCから。基幹システムへの本番投入は、ステータスがGA（正式版）に進んでから、と段階を切ります。
アクション5：監査要件と突き合わせて検証項目を作る
自社のセキュリティ監査・ログ保全要件を書き出し、「この機能でその要件が満たせるか」を実機・ドキュメントで検証する項目リストを作ります。発表文ではなく自社要件を起点にするのがコツです。
【要注意】導入検討でやりがちな失敗パターン
失敗1：「自社実行だから全部社内で完結」と社内説明してしまう
❌ 「実行環境を自社に移したので、データは一切外に出ません」
⭕ 「ツール実行は自社内に移るが、エージェントの思考処理（コンテキスト）はAnthropic基盤を経由する。データの実体と実行は境界内に留められる」
なぜ重要か：エージェントループがAnthropic基盤に残る事実を伏せると、後で監査やインシデント時に「話が違う」となり信頼を失います。
失敗2：research previewの機能を本番前提で稟議に書く
❌ MCPトンネルを基幹システム接続の本番構成として稟議申請
⭕ MCPトンネルはPoC・検証フェーズと明記し、本番化はGA後の再評価を条件にする
なぜ重要か：preview段階の機能は仕様変更や提供条件の変更があり得ます。本番依存設計にすると後戻りコストが大きくなります。
失敗3：つなぐ先を用意せずに機能だけ追いかける
❌ 社内MCPサーバーが無いのにトンネルの検証から始める
⭕ まず社内データをMCPで安全に見せられる状態を作り、その上で公開したくない部分をトンネルで閉じる
なぜ重要か：手段（トンネル）が目的化すると、肝心の「AIに何をさせたいか」が置き去りになります。
失敗4：監査ログの取得範囲を確認せず導入を決める
❌ 「監査ログをコントロールできる」という発表文だけで導入決定
⭕ どのログがどの粒度で取れるかをプロバイダ構成・契約単位で実機確認してから決定
なぜ重要か：監査要件を満たせないと、せっかく導入しても規制対応で使えない、という事態になります。
社内説明にそのまま使える「3層モデル」
稟議や社内勉強会で説明するとき、技術用語をそのまま並べると伝わりません。研修現場では、今回の仕組みを次の「3層」で説明すると一発で腹落ちしてもらえます。経営層・現場・情シスの三者で共通言語にできるので、ぜひ流用してください。
| 層 | たとえ | どこにある | 誰の管理 |
|---|---|---|---|
| 頭脳（エージェントループ） | 考える人 | Anthropic基盤 | Anthropic |
| 作業台（サンドボックス） | 手を動かす机 | 自社 or プロバイダ | 自社（自社サンドボックス利用時） |
| 金庫への通路（MCPトンネル） | 社内倉庫への専用通路 | 自社ネットワーク | 自社（トンネル利用時） |
このたとえのポイントは「頭脳はベンダーに借りているが、手を動かす机と倉庫への通路は自社の敷地内に置ける」と言い切れることです。「全部自社」ではない。でも「機密に触る部分は自社」。この線引きが正確に伝わると、情シスの納得感がまるで違います。
逆に言うと、この3層を曖昧にしたまま「セキュアになりました」とだけ説明するのが一番危険です。頭脳がベンダー側に残ることを隠すと、インシデント対応の責任分界点でもめます。正直に3層を見せたほうが、結果的に早く稟議が通ります。
よくある質問（FAQ）
Q1. 自社サンドボックスとMCPトンネルは、どちらか片方だけでも使えますか？
はい、それぞれ独立した機能です。ツール実行の場所を移したいだけなら自社サンドボックス、社内サーバーへの到達経路を閉じたいだけならMCPトンネル、という使い分けができます。両方を組み合わせれば「実行も到達も境界の内側」という構成になります。ただしMCPトンネルはresearch preview（申請制）なので、まずは自社サンドボックスから検証する企業が多くなりそうです。
Q2. これを使えば、社内データが一切Anthropicに渡らなくなりますか？
いいえ、そこは誤解しやすい点です。ツール実行とデータの実体は自社境界に留められますが、エージェントループ（オーケストレーション・コンテキスト管理・エラー回復）はAnthropic基盤に残ります。つまり、エージェントが思考のために扱う文脈はAnthropic側を経由します。「データの実体は社内」「思考処理はベンダー」と分けて理解するのが正確です。
Q3. MCPトンネルは正式版（GA）ですか？本番で使って大丈夫ですか？
2026年5月19日の発表時点ではresearch preview（申請制）です。自社サンドボックスはpublic beta。どちらもまだ正式版（GA）ではないため、基幹システムへの本番組み込みを今すぐ前提にするのは早いと考えます。PoC・限定検証から始め、GAに進んだ段階で本番化を再評価するのが現実的です。
Q4. 対応プロバイダ（Cloudflare/Daytona/Modal/Vercel）以外は使えませんか？
発表ではこの4社がマネージドプロバイダとして挙がっていますが、自社インフラ上での実行も可能とされています。ただし自社インフラで動かす場合は、隔離環境・ネットワークポリシー・監査ログの構成を自前で設計・運用する必要があり、相応の体制が前提になります。手軽さを取るならマネージドプロバイダ、統制を最大化したいなら自社インフラ、というトレードオフです。
Q5. 中小企業でも導入できますか？情シスが少人数なのですが。
技術的には可能ですが、ゲートウェイの設置・サンドボックス構成・監査ログの継続確認には一定の運用リソースが要ります。少人数・兼任体制の場合は、まず「つなぐ先の社内MCPサーバーがあるか」「対応プロバイダを既に使っているか」を確認し、無ければそこから順に整える必要があります。いきなりトンネルから始めるより、社内データをMCPで安全に見せる土台づくりが先です。
Q6. 既存のClaude Managed Agents利用者は、追加料金なしで使えますか？
料金体系の詳細は提供ステータス（beta / research preview）や構成によって変わり得るため、本記事執筆時点で断定はできません。マネージドプロバイダを使う場合は、そのプロバイダ側の計算リソース費用が別途発生する点に注意が必要です。正確な費用は、Claude Consoleの組織設定と各プロバイダの料金を実際に確認してください。Managed Agents全体の料金感は別記事でも整理しています。
まとめ：今日から始める3つのアクション
- 今日やること：自社で使っているAI機能の「実行場所」を1つでいいので確認し、説明できるか試す
- 今週中：AIにつなぎたい社内システムを「外に出せる/出せない」で分類し、トンネル候補を洗い出す
- 今月中：対応プロバイダの保有状況と監査要件を突き合わせ、検証項目リストを作って関係部署に共有する
あわせて読みたい：
- Claude Code法人導入ガイド｜SSO・料金・部門別21例 — 全社展開時のセキュリティ・権限設計の実務
- Anthropic全製品比較｜Claude / Code / Design — Managed Agentsが製品群のどこに位置するか
次回予告：次の記事では、社内MCPサーバーを「最初の1台」から立ち上げる実装フローを、情シス向けのチェックリスト付きで解説します。
参考・出典
- New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels — Anthropic（Claude公式ブログ）（参照日: 2026-05-29）
- Anthropic enhances Claude Managed Agents with two new privacy and security features — 9to5Mac（参照日: 2026-05-29）
- Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems — InfoQ（参照日: 2026-05-29）
- Anthropic adds self-hosted sandboxes and MCP tunnels to Claude Managed Agents — THE DECODER（参照日: 2026-05-29）
- Anthropic launches secure sandboxes and private MCPs — TestingCatalog（参照日: 2026-05-29）
- Securing AI agent credentials with MCP tunnels — VentureBeat（参照日: 2026-05-29）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
