MCP トンネルで社内の MCP サーバーに接続する

MCP トンネルは、社内ネットワークの中で動いている MCP サーバーへ Claude から接続するための仕組みです。受信ポートを開けず、サービスをインターネットに公開せず、Anthropic の IP レンジを許可リストに入れる必要もありません。この記事では、公式ドキュメントに基づいて、仕組み・セキュリティ・Docker Compose での試し方を順に説明します。

MCP トンネルはリサーチプレビューです。公式ドキュメントは「無保証で提供され、稼働率・サポート・継続性のいずれについても約束しない」「Anthropic はいつでも変更・終了しうる」と明記しています。本番の重要な経路に組み込む前に、この前提を確認してください。

MCP トンネルとは何か

MCP トンネルを使うと、プライベートネットワークの中で動く MCP（Model Context Protocol）サーバーに Claude を接続できます。通信は外向き（アウトバウンド）専用の接続の上を流れます。そのため次の3つが不要になります。

ファイアウォールの受信ポートを開けること
サービスをインターネットに公開すること
自社のオリジンで Anthropic の IP レンジを許可リストに入れること

公開したい MCP サーバーごとに、トンネルのドメイン配下にホスト名が割り当てられます。たとえば docs.<your-tunnel-domain> のような形です。このホスト名を Claude Console の Managed Agent セッションに紐づけるか、MCP コネクタ経由で Messages API に渡して使います。

従来、社内の MCP サーバーを Claude から使おうとすると、リバースプロキシを公開してそこに認証を付けるか、VPN の中に閉じたままにするかの二択になりがちでした。MCP トンネルは、公開せずに届かせるための経路を用意するものだと考えると分かりやすいです。

構成要素と通信の向き

自分のネットワークの中で動かすのは、次の2つのコンテナです。公式はこれをトンネルスタックと呼んでいます。

cloudflared: Cloudflare のオープンソースのトンネルコネクタです。トンネルエッジへ外向きの接続だけを張り、Anthropic からの暗号化された通信をプロキシまで運びます。
プロキシ（proxy）: Anthropic のルーティング部品です。内側の TLS を終端し、上流の IP が許可された範囲に入っているかを検証したうえで、ホスト名に応じて各 MCP サーバーへ振り分けます。

ここでいちばん誤解しやすいのが「向き」です。公式ドキュメントは、2つの向きが逆を指していると明示しています。

接続の向き: cloudflared が自社ネットワークからトンネルエッジへ外向きにダイヤルします。ファイアウォールから見えるのはポート 7844 への送信だけで、受信ポートは1つも開きません。
リクエストの向き: いったん接続が張られると、MCP のリクエストはAnthropic 側から自社ネットワークへ向かって、その接続の上を流れます。cloudflared を通ってプロキシへ、さらに上流の MCP サーバーへ届きます。

つまり「アウトバウンド専用」という言葉は接続について言っているのであって、その上を運ばれるリクエストのことではありません。この点を取り違えると、設計の議論がかみ合わなくなります。

通信に必要な外向きの到達性は次のとおりです。

部品	宛先	ポート / プロトコル	使う場面
セットアップ部品	`api.anthropic.com`	443 TCP	プロビジョニングとトークンのローテーション
cloudflared	トンネルエッジ（`198.41.192.0/19`、`2606:4700:a0::/44`）	7844 TCP および UDP	実行時
プロキシ	自社の上流 MCP サーバー	設定による	実行時

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

公式は、すべてのリクエストが3つの独立した層で守られると説明しています。

層	何を防ぐか
Anthropic とトランスポート提供者のあいだの外側 mTLS（IP 検証つき）	認可されていないクライアントがトンネルに到達すること
Anthropic のバックエンドから自社プロキシまでの内側 TLS	トランスポート提供者やネットワーク中継者によるペイロードの覗き見
各 MCP サーバーの OAuth	認証済みのトンネル通信による MCP ツールの不正利用

内側 TLS が要点です。トンネルの輸送路は Cloudflare のネットワーク上を通りますが、プロキシは自分だけが秘密鍵を持つ証明書で内側 TLS を終端します。したがって Cloudflare はリクエストとレスポンスの中身を読めません。Anthropic はCA 証明書が登録されるまでトンネルに接続しないので、Cloudflare のネットワークを通るときには必ず暗号化されている、という設計です。

ただし Cloudflare は接続のメタデータは受け取ります。公式が挙げているのは、cloudflared を動かしているホストの送信元 IP アドレス、cloudflared のホストのフィンガープリント、接続のタイミングと転送バイト量、割り当てられた *.tunnel.anthropic.com のサブドメインです。中身は読めないがメタデータは残る、という区別を押さえてください。

警告として公式が明記していること。攻撃者がトンネルトークンと TLS 秘密鍵の両方を手に入れた場合、プロキシになりすまして MCP リクエストのペイロードを読めます。どちらも高価値の秘密情報として扱ってください。

責任分界も明文化されています。Anthropic 側はトンネルのアクセス制御、接続前の CA 証明書の検証、Claude が自組織のトンネルにだけリクエストを送ることの保証を担います。利用者側は、トンネルを通る内容と通信のすべて、トンネルトークンと TLS 秘密鍵の保護、サーバー証明書の管理と期限前の更新、各 MCP サーバーでの OAuth 設定、プロキシと MCP サーバーのネットワークアクセス制限、そして侵害が疑われるときの Anthropic への通知を担います。

Docker Compose で試す

公式のクイックスタートは、Docker Compose と手動のクレデンシャル供給で最短の経路をたどります。必要なものは、外向きのインターネット接続がある Docker / Docker Compose の環境、Claude Console で MCP トンネルを管理できるロール、そして OpenSSL 1.1.1 以降です。

トンネルを作る。Claude Console のサイドバーから Manage > MCP tunnels を開き、New tunnel をクリックして名前を付けます。クイックスタートでは Set up programmatic access はオフのままにします。作成後、Connection の節からドメイン（abcd1234.tunnel.anthropic.com のような形）とトークンの2つを控えます。

作業ディレクトリを用意する。

mkdir -p mcp-tunnel/{config,data}
cd mcp-tunnel
export TUNNEL_DOMAIN=YOUR_TUNNEL_DOMAIN_HERE
export TUNNEL_TOKEN='eyJ...'

CA とサーバー証明書を作る。プロキシは、自分が管理する CA で署名した証明書を使って内側 TLS を終端します。まず CA を作ります。
```
openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout data/ca.key -out data/ca.crt \
  -days 3650 -subj "/CN=mcp-tunnel-ca" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
```
続けてサーバー証明書を作り、CA を Console に登録します。
スタックを起動する。プロキシ、cloudflared、サンプルの MCP サーバーを Docker Compose で立ち上げます。
Claude から呼ぶ。公開ポートで待ち受けているものが何も無いにもかかわらず、サンプルサーバーが https://echo.<your-tunnel-domain>/mcp として Claude から到達できる状態になります。

手順の全文とサーバー証明書の作成コマンドは、公式の MCP tunnels quickstart を参照してください。Windows では PowerShell 用の書き方が併記されており、openssl を別途インストールして PATH に通す必要があります。

使う前に確認しておくこと

クレデンシャルの供給方法は2通りあります。どちらを選ぶかで運用の手間が変わります。

プログラム的アクセス（推奨）: トンネル作成時に Workload Identity Federation を設定します。スタック側が自社の ID プロバイダから短命の API トークンを発行し、トンネルトークンを取得して、CA 証明書の生成と登録まで自動で行います。長期の秘密情報を手でコピーする作業が無くなります。フェデレーションルールの管理権限、登録済みの OIDC 発行者、そして workspace:manage_tunnels スコープを持つフェデレーションルールが必要です。
手動: トンネルトークンを Console からコピーし、CA とサーバー証明書を自分で作って CA を Console に登録し、トークンと証明書をシークレットとしてスタックへ渡します。OIDC の ID プロバイダが無い場合や、まず試すだけの場合はこちらです。

デプロイ先の選択は Kubernetes かどうかで決まります。Kubernetes には Anthropic の Helm チャート、単一ホストやローカルの検証には Docker Compose を使います。Helm チャートのセットアップフックは、インストール中にトンネル自体を作ることもできます。

証明書の期限切れに注意してください。サーバー証明書の管理と期限前の更新は利用者側の責任として明記されています。セットアップ部品は renew-cert を提供しているので、更新を仕組みに組み込んでおくのが安全です。

Zero Data Retention と HIPAA BAA の対象になるかどうかは、公式の「API and data retention」の機能別の適格性の節に記載があります。規制のある環境で使う場合は、実装より先にそちらを確認してください。

参考にした公式ドキュメント

この記事は次の公式ドキュメントに基づいています（2026年9月6日に確認）。

MCP tunnels（概要・前提条件・ネットワーク要件・セキュリティモデル・責任分界）
Architecture and components（構成要素の呼び方・クレデンシャル供給の2方式・接続モデル）
MCP tunnels quickstart（Docker Compose での構築手順）