MCP tunnelsをConsoleで作成・管理する手順
Claude ConsoleでMCP tunnelsを作成し、CA証明書の登録からManaged Agentセッションへの接続、アーカイブまでの手順を、組織あたり10トンネル・証明書2枚という上限とあわせてまとめます。
MCP tunnelsとは何をConsoleで作る機能か
MCP tunnelsは、社内ネットワークで動くMCPサーバーへ、インバウンドのポートを一切開けずにClaudeから到達できるようにする機能です。実体はcloudflaredとプロキシの2コンテナで、あなたのネットワーク側からトンネルエッジへアウトバウンド接続を張るだけで経路が成立します。ファイアウォールに見えるのはエグレスだけで、外から開ける穴はありません。
Console側で行うのは、トンネルという入れ物の作成と、その入れ物にMCPサーバーを接続するための証明書・トークンの管理です。トンネルスタック自体をネットワーク内で実際に動かす作業とは分かれています。MCP tunnelsはリサーチプレビュー(research preview)として提供されている機能で、稼働率やサポート継続の保証は無く、利用にはアクセス申請が要ります。第三者ネットワークプロバイダ(Cloudflare)にも依存するため、Anthropicは機能をいつでも変更・終了できるとしています。
接続したMCPサーバーは、ClaudeのManaged AgentセッションかMessages APIのmcp_serversから呼び出せます。Consoleで作ったトンネルはclaude.aiのコネクタ一覧には出てきません。個人利用のclaude.aiと混同しないための最初の注意点です。
事前に必要なもの
- 社内ネットワークで稼働するMCPサーバーが1つ以上。トンネルはあくまで経路であって、サーバー自体をホストする機能ではありません
- Manage tunnels権限を持つConsoleロール。組織のadmin・ownerにはデフォルトで付与されており、カスタムロールや個別アカウントへの権限付与でも持たせられます。権限が無いロールは、MCP tunnelsページとトンネル詳細を閲覧できるだけの読み取り専用になります
- Tunnels APIへの認証手段。次の節で比較する2種類のどちらかを選びます
プログラム的アクセスと手動、どちらを選ぶか
トンネル作成時に選ぶ認証方式は、あとからネットワーク内のデプロイ手順にもそのまま影響します。デプロイ手順の側では、前者を「With programmatic access」、後者を「Without programmatic access」のタブで書き分けています。
トンネルの認証方式
プログラム的アクセス
Workload Identity Federationで短命なAPIトークンを発行し、トンネルトークンの取得とCA証明書の生成・登録もスタック側が自動で行います。Kubernetesクラスタ・クラウドIAM・GitHub ActionsなどOIDCの発行元を持つ本番環境向けです。
必要なのは、対象のIDプロバイダに対応するOIDC発行者の登録、workspace:manage_tunnelsスコープを持つfederation rule、そのruleのサービスアカウントを対象ワークスペースのメンバーに加えること、の3点です。
手動
Consoleでトンネルトークンをコピーし、CA証明書は自分で生成してConsoleに登録します。トークンとサーバー証明書はシークレットとしてスタックに渡します。ローカル検証や、IDプロバイダを新たに用意したくない環境向けです。
トンネル作成時にトグルをオフにするだけで選べます。
プログラム的アクセスでも、秘密鍵はあなたの環境から出ません。スタックが生成するのはCAとサーバー証明書で、Anthropicに登録されるのはCAの公開証明書だけです。秘密鍵の保護と、サーバー証明書の期限前の更新は利用者側の仕事として残ります。
トンネルを作成する
Consoleでの作成の流れ
- 1
MCP tunnelsページを開く
サイドバーでManage > MCP tunnelsを開きます。トンネルはワークスペース単位で作られるので、目的のワークスペースに切り替えてから進めます。
- 2
名前を付ける
New tunnelをクリックし、一覧・詳細ページ・エージェントのMCPサーバーピッカーで識別名になる名前を入力します。
abcd1234.tunnel.anthropic.com形式のドメインが自動で割り当てられます。 - 3
プログラム的アクセスを選ぶ
federation ruleを管理できるロールならSet up programmatic accessのトグルが表示されます(既定はオフ)。権限が無いロールではトグルの代わりに案内が出て、手動フローになります。前節の3条件を満たしているならオンにします。
- 4
作成する
Create tunnelをクリックすると、Consoleがトンネルを作成して詳細ページを開きます。
詳細ページからトンネルID(tnl_...)とトンネルドメインを控えます。ドメインは、プロキシ設定のtunnel_domainとサーバー証明書のSANに使う値です。これ以外に何を控えるかは、認証方式で変わります。
| 控えるもの | プログラム的アクセス | 手動 |
|---|---|---|
| 認証まわり | プログラム的アクセスfederation rule ID(fdrl_...)。Settings > Workload identity > Rulesにある | 手動トンネルトークン |
| もう1つ | プログラム的アクセス組織ID(UUID)。Settings > Organizationにある | 手動自分で生成してConsoleに登録したCA証明書 |
federation ruleは組織単位の設定で、トンネル自体には保存されません。1組織で作成できるアクティブなトンネルは最大10個です。トンネルを作成しただけでは通信は始まりません。
接続情報を取得する
詳細ページのConnectionセクションに、ドメインとトークンが並びます。トークンは目のアイコン(Show token)を押さないと表示されず、コピーアイコンでシークレットストアに渡します。Rotate tokenを押すと現在のトークンが無効になり、新しいトークンが発行されます。
ローテーションは確立済みのcloudflared接続を切断しません。新しい値で先にデプロイを更新してから、古い接続が自然に切れるのを待つ運用ができます。トークンの表示とローテーションは、いずれも組織のCompliance APIのアクティビティログに記録されます。コピーしたドメインとトークンは、デプロイ手順にそのまま渡せるようシェル変数へ入れておくと後工程がなめらかです。
export TUNNEL_DOMAIN=abcd1234.tunnel.anthropic.com
export TUNNEL_TOKEN='eyJ...'CA証明書を登録する
トンネルの経路を担うCloudflareは、MCPリクエストとレスポンスの中身を読めません。内側のTLSはAnthropicのバックエンドからあなたのプロキシまで張られ、その秘密鍵を持つのは利用者だけだからです。この秘密鍵は、プロキシが提示するサーバー証明書の鍵です。Anthropicはその証明書を、利用者がConsoleに登録したCA証明書で検証します。
証明書が1枚も無いトンネルは接続を受け付けません。Anthropicのバックエンドも、CA証明書が登録されるまでトンネルには接続しません。
- 詳細ページのCertificatesセクションでAdd certificateを押す
.pem・.crt・.cerのいずれかのファイルを選ぶか、PEMブロックを直接貼り付ける。秘密鍵を含むファイルや-----BEGIN CERTIFICATE-----で始まらない内容は拒否され、ファイルサイズの上限は8kBです- Add certificateを押すと、フィンガープリントと有効期限が一覧に加わる
1つのトンネルには最大2枚まで証明書を有効化できます。新しい証明書を旧証明書と並行登録し、新しい鍵ペアでプロキシを再デプロイしてトラフィックを確認したうえで、旧証明書の行でRevokeを押す、というダウンタイムの無いローテーションが組めます。失効した証明書は一覧にRevokedバッジ付きのまま残ります。
自前のPKIで発行する場合の条件
プログラム的アクセスなら、スタックが条件を満たす証明書を自動で作ります。具体的には、5年有効のECDSA P-256のCAと、ワイルドカードSAN付き・90日有効のRSA 4096ビットのサーバー証明書です。手動フローで自分のPKIから発行するときは、次の条件を満たす必要があります。
| 対象 | 条件 |
|---|---|
| CA証明書 | 条件PEMの単一証明書で8kB以下。BasicConstraintsがCA:TRUEでcritical、SubjectKeyIdentifierあり、KeyUsageにkeyCertSignを含む。有効期間内 |
| サーバー証明書 | 条件登録済みのCAが直接署名する(中間CAなし)。AuthorityKeyIdentifierがCAのSKIと一致する。SANに<route>.<tunnel-domain>に合うDNS名を含む |
| 鍵と署名(共通) | 条件RSA 2048ビット以上、またはECDSA P-256以上。署名はSHA-256以上 |
SANのワイルドカード*.<tunnel-domain>を使うと、すべてのルートを1枚でカバーできます。ExtendedKeyUsageを付けるならserverAuthが必要です。
トンネルスタックを動かす
ここまではConsole側の設定で、まだ通信は始まっていません。単一ホストで動かすならDocker Composeで、Kubernetesクラスタで動かすならHelmチャートでのデプロイ手順で、cloudflaredとプロキシの2コンテナを実際にネットワーク内で起動し、控えておいたトークンで接続する作業が別途要ります。Composeの流れはDocker Composeでのデプロイ手順にあります。どちらの方式でも、プログラム的アクセス・手動の両方の認証フローに対応しています。
ファイアウォール側に必要なのは次の経路です。
| 通信元 | 宛先 | ポート |
|---|---|---|
| setupコンポーネント(プログラム的アクセスのみ) | 宛先api.anthropic.com | ポート443 TCP |
| cloudflared | 宛先トンネルエッジ(198.41.192.0/19、2606:4700:a0::/44) | ポート7844 TCPとUDP |
| プロキシ | 宛先社内のMCPサーバー | ポート設定どおり |
Managed Agentセッションでトンネルを使う
トンネルスタックが動き、MCPサーバーが1つ以上設定できたら、Managed Agentセッションへ接続します。
セッションにトンネルを足す
- 1
New sessionを開く
Managed Agents > SessionsでNew sessionを開きます。
- 2
インラインのエージェントを作る
エージェントピッカーでCreate new agentを選び、MCPサーバー一覧を編集できる状態にします。
- 3
MCPサーバーを追加する
+ MCP Serverを押してドロップダウンを開きます。現在のワークスペースで作ったトンネルは、公開されているコネクタカタログより上に並びます。接続したいトンネルを選びます。
- 4
ルーティングを入力する
必要に応じてSubdomain(トンネルドメインの前に付く)とPath(後ろに付く)を入力します。Resolves toの行に、エージェントが実際に接続する完全なURLが表示されます。
トンネルは経路であって、MCPサーバー自体を認証するものではありません。OAuthやbearer認証は、通常の他のMCPサーバーと同じ方法でサーバー側に設定します。仕組みはリモートMCPのOAuth認証にまとめています。MCP自体の基本的な仕組みはMCPとはで解説しています。
このトンネルの接続先は、Managed AgentsのAPIやセッション設計とも関わります。セッション・ハーネス・サンドボックスを切り離す設計思想はAgent SDKのManaged Agentsの設計思想で扱っています。
トンネルをアーカイブする
MCP tunnelsの一覧でトンネルの行メニューを開きArchiveを選ぶと、そのトンネルは接続の受け付けを即座に停止します。アーカイブ済みのトンネルは、一覧をArchivedまたはAllで絞り込んだときだけ表示されます。トンネルトークンが漏れた疑いがあるときも、スタックを止めてエージェントから切り離したうえでアーカイブすると、トークンが無効になりドメインも切り離されます。
症状から原因をたどる
リクエストが通らないときは、トンネルエッジへのアウトバウンド接続、プロキシまでの内側のTLS、プロキシから社内MCPサーバーへのルーティングとIP検証の順に層を分けて見ます。症状ごとの原因と直し方は次のとおりです。
| 症状 | 原因 | 直し方 |
|---|---|---|
| エージェントのピッカーにトンネルが出ない | 原因アクティブな証明書が無いか、セッションと別のワークスペースを見ている | 直し方CA証明書を登録する。一覧にNeeds certificateと出ている間は未登録 |
呼び出し側にHTTP 500。cloudflaredのログにNo ingress rules were defined | 原因cloudflaredにローカルの宛先が無い | 直し方cloudflaredのサービスに--url http://localhost:8080とnetwork_mode: "service:mcp-proxy"を足す |
プロキシのログにno route for host | 原因tunnel_domainが割り当てドメインと違うか、config.yamlを直してから再起動していない | 直し方詳細ページのドメインをそのままtunnel_domainに入れ、プロキシを再起動する |
プロキシがcannot unmarshal !!seq into map[string]stringで終了 | 原因routesをYAMLのリストで書いている | 直し方routes: { name: http://host:port }のマップ形式にする |
プロキシがopen /data/tls.key: permission deniedで終了 | 原因鍵が0600で、プロキシのコンテナが非rootで動く | 直し方chmod 644 data/tls.key |
プロキシへのcurl https://<proxy>:8080がwrong version number | 原因正常な挙動。待ち受けはTLSでなくプレーンなWebSocketで、TLSはその中で張られる | 直し方ManagedエージェントかMessages APIから通して確かめる |
表に収まらない分は、層ごとに補足します。
トークンやTLSの問題。cloudflaredが接続できないときは、まずそのログを見ます。TUNNEL_TOKENの欠落や誤コピー、ポート7844へのアウトバウンド遮断が典型です。プロキシのログにtls handshake failedが出るなら、サーバー証明書の期限切れ、SANが*.<tunnel-domain>に合っていない、署名したCAがこのトンネルに登録されていない、の3点を順に見ます。
プログラム的アクセスの認証エラー。Tunnels APIが、交換に成功した後で403を返すなら、ruleのスコープにworkspace:manage_tunnelsが無いか、ruleのサービスアカウントがトンネルのワークスペースのメンバーではありません。Helmチャートの既定のaudienceはapi.anthropic.com(スキーム無し)なので、ruleのaudienceがhttps://api.anthropic.comならapi.wif.audienceを合わせます。Helmのsetup Jobは失敗するとそのまま残るため、再試行の前に削除します。
helm uninstall mcp-tunnel -n mcp-tunnel
kubectl -n mcp-tunnel delete job mcp-tunnel-setup社内MCPサーバーに届かない。SSRF対策として、プロキシは既定でRFC1918のプライベート範囲(10.0.0.0/8・172.16.0.0/12・192.168.0.0/16)のIPv4にしか接続しません。ログにIP validation failed: <ip> is not a private addressが出たら、接続先がその外に解決されています。一部のマネージドKubernetesはServiceのCIDRをRFC1918の外に割り当てており、kubectl get svc kubernetes -n default -o jsonpath='{.spec.clusterIP}'の結果が範囲外なら該当します。
許可するIPは、必要な最小のCIDRをupstream.allowed_ipsに足して通します。この設定は既定値を置き換えるので、ほかのMCPサーバーが使うプライベート範囲も書き直す必要があります。
upstream:
allowed_ips:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/160.0.0.0/0を指定するとSSRF対策が丸ごと無効になるため、ローカルでの検証以外では使えません。
OAuthがIP許可リストで失敗する。認可サーバーが送信元IPを制限していると、Anthropicのバックエンドが/token・/register・ディスカバリのエンドポイントに届かず、OAuthが失敗します。Anthropicのエグレス範囲を許可リストに入れたくないなら、これらのバックエンド同士の呼び出しだけをトンネル経由にし、ブラウザが開く/authorizeは既存の公開ホスト名のままにする構成があります。プロキシのroutesに認可サーバーを足し、ディスカバリのメタデータでauthorization_endpointだけを公開ホスト名に向けます。
公開コネクタとの違いも押さえておく点です。外部向けに審査付きでMCPサーバーを公開するAnthropic Connectors Directoryとは別の仕組みで、Consoleのトンネルは自分のワークスペースの中だけで使われます。
まとめ
Console側の作業は、認証方式の選択と証明書の登録で、動くかどうかがほぼ決まります。この2つを済ませてからスタックを起動し、通らなければ症状の表で層を切り分けるのが近道です。リサーチプレビュー段階でclaude.aiのコネクタとは別枠という点は、社内で展開する前に関係者へ共有しておく価値があります。