Claude Media
MCP tunnelsをConsoleで作成・管理する手順
MCPAgent SDKチュートリアル

MCP tunnelsをConsoleで作成・管理する手順

Claude ConsoleでMCP tunnelsを作成し、CA証明書の登録からManaged Agentセッションへの接続、アーカイブまでの手順を、組織あたり10トンネル・証明書2枚という上限とあわせてまとめます。

読了目安 約8分

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種類のどちらかを選びます

プログラム的アクセスと手動、どちらを選ぶか

トンネル作成時に選ぶ認証方式は、あとからネットワーク内のデプロイ手順にもそのまま影響します。

モード認証の仕組み向いているケース
プログラム的アクセス(推奨)認証の仕組みWorkload Identity Federationで短命なAPIトークンを発行し、CA証明書も自動で生成・登録する向いているケースKubernetesクラスタ・クラウドIAM・GitHub ActionsなどOIDCの発行元を持つ本番環境
手動認証の仕組みConsoleでトンネルトークンをコピーし、CA証明書は自分で生成してConsoleに登録する向いているケースローカル検証や、IDプロバイダを新たに用意したくない環境

プログラム的アクセスには、①対象のIDプロバイダに対応するOIDC発行者の登録②workspace:manage_tunnelsスコープを持つfederation ruleの用意③そのruleのサービスアカウントを対象ワークスペースのメンバーに加えること、の3点が要ります。この設定を省いても手動フローで運用できるので、後から切り替えても構いません。

トンネルを作成する

Consoleでの作成は次の流れです。

  1. サイドバーでManage > MCP tunnelsを開く。トンネルはワークスペース単位で作られるので、目的のワークスペースに切り替えてから進めます
  2. New tunnelをクリックし、一覧・詳細ページ・エージェントのMCPサーバーピッカーで識別名になる名前を入力する。abcd1234.tunnel.anthropic.com形式のドメインが自動で割り当てられます
  3. federation ruleを管理できるロールならSet up programmatic accessのトグルが表示されるので、前節の3条件を満たしているならオンにする
  4. Create tunnelをクリックすると、Consoleがトンネルを作成し詳細ページを開く
  5. 詳細ページからトンネルID(tnl_...)とトンネルドメインを控える。手動フローではこれに加えてトンネルトークンとCA証明書も要ります

1組織で作成できるアクティブなトンネルは最大10個です。トンネルを作成しただけでは通信は始まりません。ネットワーク内でトンネルスタックが実際に動き、トークンで接続してCA証明書が登録されて初めてトラフィックが流れます。

接続情報を取得する

詳細ページのConnectionセクションに、ドメインとトークンが並びます。トークンは目のアイコン(Show token)を押さないと表示されず、コピーアイコンでシークレットストアに渡します。Rotate tokenを押すと現在のトークンは即座に無効化され、新しいトークンが発行されます。ローテーションは確立済みのcloudflared接続を切断しないため、新しい値で先にデプロイを更新してから、古い接続が自然に切れるのを待つ運用ができます。

トークンの表示とローテーションは、いずれも組織のCompliance APIのアクティビティログに記録されます。コピーしたドメインとトークンは、デプロイ手順にそのまま渡せるようシェル変数へ入れておくと後工程がなめらかです。

export TUNNEL_DOMAIN=abcd1234.tunnel.anthropic.com
export TUNNEL_TOKEN='eyJ...'

CA証明書を登録する

トンネルの経路を担うCloudflareは、MCPリクエストとレスポンスの中身を読めません。内側のTLSはAnthropicのバックエンドからあなたのプロキシまで張られ、その秘密鍵を持つのは利用者だけだからです。この秘密鍵と対になるのが、プロキシが提示するサーバー証明書を検証するCA証明書で、利用者側がConsoleに登録する仕組みになっています。証明書が1枚も無いトンネルは接続を受け付けず、Managed AgentのMCPサーバーピッカーにも表示されません。

  1. 詳細ページのCertificatesセクションでAdd certificateを押す
  2. .pem・.crt・.cerのいずれかのファイルを選ぶか、PEMブロックを直接貼り付ける。秘密鍵を含むファイルや-----BEGIN CERTIFICATE-----で始まらない内容は拒否され、ファイルサイズの上限は8kBです
  3. Add certificateを押すと、フィンガープリントと有効期限が一覧に加わる

1つのトンネルには最大2枚まで証明書を有効化できます。新しい証明書を旧証明書と並行登録し、新しい鍵ペアでプロキシを再デプロイしてトラフィックを確認したうえで、旧証明書の行でRevokeを押す、というダウンタイムの無いローテーションが組めます。失効した証明書は一覧にRevokedバッジ付きのまま残ります。

トンネルスタックを動かす

ここまではConsole側の設定で、まだ通信は始まっていません。単一ホストで動かすならDocker Composeで、Kubernetesクラスタで動かすならHelmチャートでのデプロイ手順で、cloudflaredとプロキシの2コンテナを実際にネットワーク内で起動し、控えておいたトークンで接続する作業が別途要ります。どちらの方式でも、プログラム的アクセス・手動の両方の認証フローに対応しています。

Managed Agentセッションでトンネルを使う

トンネルスタックが動き、MCPサーバーが1つ以上設定できたら、Managed Agentセッションへ接続します。

  1. Managed Agents > SessionsでNew sessionを開く
  2. エージェントピッカーでCreate new agentを選び、MCPサーバー一覧を編集できる状態にする
  3. + MCP Serverを押しドロップダウンを開く。現在のワークスペースで作ったトンネルは、公開されているコネクタカタログより上に並びます
  4. 接続したいトンネルを選び、必要に応じてSubdomain(トンネルドメインの前に付く)とPath(後ろに付く)を入力する。Resolves toの行に、エージェントが実際に接続する完全なURLが表示されます

ピッカーに出てくるのは、アクティブな証明書を1枚以上持つトンネルだけです。ワークスペースをまたいだトンネルは表示されません。MCP自体の基本的な仕組みはMCPとはで解説しています。トンネルはあくまで経路で、MCPサーバー自体を認証するものではありません。OAuthやbearer認証は、通常の他のMCPサーバーと同じ方法でサーバー側に設定します。仕組みはリモートMCPのOAuth認証にまとめています。

このトンネルの接続先は、Managed AgentsのAPIやセッション設計とも関わります。セッション・ハーネス・サンドボックスを切り離す設計思想はAgent SDKのManaged Agentsの設計思想で扱っています。

トンネルをアーカイブする

MCP tunnelsの一覧でトンネルの行メニューを開きArchiveを選ぶと、そのトンネルは接続の受け付けを即座に停止します。アーカイブ済みのトンネルは、一覧をArchivedまたはAllで絞り込んだときだけ表示されます。

よくあるつまずき

  • 証明書の登録を忘れる。トンネルを作成しただけではManaged Agentのピッカーに出てきません。一覧にNeeds certificateと表示されている間は、CA証明書を最低1枚登録します
  • ワークスペースを取り違える。トンネルもピッカーもワークスペーススコープで動きます。別のワークスペースを見ていると、存在するはずのトンネルが見当たりません
  • federation ruleのスコープ不足。プログラム的アクセスにはworkspace:manage_tunnelsスコープが要ります。組織全体を対象にした古いruleでは通りません
  • トークンをローテーションしたのにスタックを再デプロイし忘れる。旧トークンは即座に無効化されるため、再デプロイが遅れたホストだけ再接続できなくなります
  • 公開コネクタと混同する。Consoleで作ったトンネルはclaude.aiのコネクタ一覧には出ません。外部向けに審査付きでMCPサーバーを公開するAnthropic Connectors Directoryとは別の仕組みです

まとめ

Console側でMCP tunnelsを扱う作業は、トンネルの作成、認証方式の選択、証明書の登録、Managed Agentセッションへの接続、そして不要になったトンネルのアーカイブに集約されます。実際のトラフィックはネットワーク内のトンネルスタックが動いて初めて流れるので、Console側の設定が終わった時点ではまだ半分です。リサーチプレビュー段階の機能である点と、claude.aiのコネクタとは別枠である点は、社内で展開する前に関係者へ共有しておく価値があります。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →