2026-05-19 に Claude プラットフォームへ MCP tunnels が Research Preview として入りました。これは、社内ネットワークの中で動いている MCP サーバーに Claude を接続させるための仕組みです。肝は、トラフィックがアウトバウンド専用で流れること。つまり、
- インバウンドのファイアウォールポートを開けない
- サービスをインターネットに公開しない
- Anthropic の IP レンジを自社の origin で許可リストに入れない
これらをすべて避けたまま、Claude(Managed Agents / Messages API)から社内 MCP サーバーのツールを使えます。「MCP サーバーは社内にあるが、外に出したくない」という、エンタープライズで頻出する制約に対する答えです。
MCP tunnels は beta(Research Preview)です。アクセス申請が必要で、無保証(as-is)です。トランスポートは第三者プロバイダ(Cloudflare)に依存します。
仕組み
トンネルのデプロイは、社内ネットワークで動く 2 つのコンポーネントから成ります。
- cloudflared: トンネルエージェント。Anthropic 側のトンネルエッジへアウトバウンド専用接続を張り、暗号化トラフィックを運ぶ
- Proxy: Anthropic のルーティング部品。内側 TLS を終端し、upstream の IP が許可範囲内かを検証し、ホスト名で適切な upstream MCP サーバーへ振り分ける
公開する MCP サーバーごとに、トンネルドメイン配下のホスト名(例: docs.<your-tunnel-domain>)が割り当てられます。これを Managed Agent セッションに紐付けるか、Messages API の MCP connector に渡します。
Claude ─▶ Anthropic tunnel edge ◀── (outbound only) ── cloudflared ─▶ Proxy ─▶ 社内 MCP サーバー
前提条件
デプロイ前に必要なものは次のとおりです。
- デプロイ先: Kubernetes クラスタ、または Docker と Docker Compose が動く VM
- Console で作成したトンネル(Claude Console から)
- Tunnels API への認証手段(下記のいずれか)
- プログラム的アクセス(推奨): トンネル作成時に Workload Identity Federation を設定。短命トークンを IdP から発行し、トンネルトークン取得・CA 証明書の生成と登録まで自動化。
org:manage_tunnelsスコープの federation rule が要る - 手動: Console から取得したトンネルトークンと、登録した CA で署名したサーバー証明書を自前で用意
- プログラム的アクセス(推奨): トンネル作成時に Workload Identity Federation を設定。短命トークンを IdP から発行し、トンネルトークン取得・CA 証明書の生成と登録まで自動化。
- 社内ネットワークで動く 1 つ以上の MCP サーバー
ネットワーク要件(アウトバウンド)
| コンポーネント | 宛先 | ポート / プロトコル | いつ |
|---|---|---|---|
| セットアップ | api.anthropic.com | 443 TCP | プロビジョニング・トークン更新時 |
| cloudflared | トンネルエッジ(198.41.192.0/19, 2606:4700:a0::/44) | 7844 TCP / UDP | 常時 |
| Proxy | 自社の upstream MCP サーバー | 設定どおり | 常時 |
いずれもアウトバウンドである点に注目してください。社内からエッジへ繋ぎにいくだけなので、境界ファイアウォールにインバウンド穴を開ける必要がありません。
セキュリティモデル — 3 層
すべてのリクエストは、独立した 3 層で保護されます。これは「社外のトランスポートを通すなら、中身を誰にも読まれない設計か」を判断するうえで重要なポイントです。
| 層 | 何から守るか |
|---|---|
| Anthropic とトランスポートプロバイダ間の外側 mTLS + IP 検証 | 不正なクライアントがトンネルに到達すること |
| Anthropic のバックエンドから自社 Proxy への内側 TLS | トランスポートプロバイダや中間者によるペイロード覗き見 |
| 各 MCP サーバーの OAuth | 認証済みトンネルトラフィックによるツールの不正利用 |
トランスポートは Cloudflare のネットワーク上を通りますが、内側 TLS の証明書は自社しか持たないため、Cloudflare はリクエスト / レスポンスのペイロードを読めません。Anthropic は CA 証明書が登録されるまでトンネルに接続しないので、「ペイロードが平文で Cloudflare を通る」構成は存在しません。Cloudflare が受け取るのは接続メタデータ(cloudflared ホストの egress IP、接続のタイミングとバイト量、割り当てサブドメイン等)に限られます。
注意: トンネルトークンと TLS 秘密鍵の両方が攻撃者に渡ると、Proxy を偽装して MCP リクエストのペイロードを読まれ得ます。どちらも高価値シークレットとして扱ってください。
Messages API からの使い方
トンネルがアクティブ(有効な CA 証明書があり、スタックが接続済み)になれば、ルーティングされた MCP サーバーは Claude から到達可能になります。Messages API では、ルーティング先 URL を mcp_servers 配列に、他のリモート MCP サーバーと同じ形で渡すだけです。トンネル固有なのは url だけで、リクエストボディと anthropic-beta ヘッダは標準の MCP connector 形式に従います。
curl https://api.anthropic.com/v1/messages \
-H "Content-Type: application/json" \
-H "X-API-Key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-client-2025-11-20" \
-d '{
"model": "claude-opus-4-7",
"max_tokens": 1000,
"messages": [{"role": "user", "content": "Use the hello tool to greet tunnel."}],
"mcp_servers": [
{
"type": "url",
"url": "https://echo.YOUR_TUNNEL_DOMAIN_HERE/mcp",
"name": "echo"
}
],
"tools": [{"type": "mcp_toolset", "mcp_server_name": "echo"}]
}'
ホストは <subdomain>.<your-tunnel-domain>、パスは upstream の MCP サーバーが提供するもの(FastMCP の streamable-http なら既定で /mcp、サーバーによっては /)。トンネルは暗号化トラフィックを運ぶだけで、MCP サーバー自体への認証はしません。upstream が OAuth や bearer token を要求するなら、通常のリモート MCP サーバーと同じように別途渡します。
何に使えるか
- 社内データベースや内部 API に繋がる MCP サーバーを、公開せずに Claude から使わせたいエンタープライズ
- コンプライアンス上、サービスを外部公開できないが、エージェントには社内ツールを使わせたいケース
- ネットワークチームに「インバウンド穴を開けてくれ」と交渉せずに MCP を本番投入したい場合
デプロイは、まず Docker Compose のクイックスタートでローカルに 1 本通してから、本番は Helm(Kubernetes)か Docker Compose(単一ホスト)へ、という順序が無難です。
まとめ
MCP tunnels は、「MCP サーバーは社内にあるが、外に出したくない」という制約を、アウトバウンド専用接続と 3 層のセキュリティで解く Research Preview です。インバウンドポートを開けず、サービスを公開せず、Anthropic の IP を許可リストに入れずに、社内 MCP を Claude から使えます。
実行を社内に閉じたいなら、次回取り上げる Managed Agents の self-hosted sandboxes と組み合わせると、ツール実行も MCP アクセスも自社境界の中に収められます。Research Preview なので無保証ですが、エンタープライズ案件で「社内 MCP をどう繋ぐか」に悩んでいたなら、検討する価値のある選択肢です。
release notes タグで Anthropic / Claude のリリース情報を継続フォローしています。