MCPトンネルで社内システムをファイアウォールを開けずにAIエージェントへ接続する手順

情シス部門でAIエージェントの導入を検討していると、必ずと言っていいほど社内システムとの接続方法でつまずきます。社内DBやAPIをクラウド側のAIに触らせるには、ファイアウォールに穴を開けるか、システム自体を外部公開する必要がある——そう思われがちです。しかしAnthropicが提供する「MCPトンネル(MCP tunnels)」という仕組みを使うと、その前提自体を避けられるとされています。結論を先に言うと、MCPトンネルは社内ネットワーク側から外向きの暗号化接続を張るだけで済み、インバウンドのポート開放も公開エンドポイントの用意も不要になる設計だとClaude Platform Docsの公式ページは説明しています。

ただし2026年8月時点でこの機能はリサーチプレビュー段階にあり、誰でも無条件に使えるわけではありません。この記事では、MCPトンネルの仕組みと前提条件、実際のセットアップ手順、そして「導入すれば何でも安全になる」わけではない限界を、公式ドキュメントに基づいて整理します。

MCPトンネルとは

MCPトンネルとは、社内ネットワークの中で動くMCP（Model Context Protocol）サーバーに、Claudeからアウトバウンド接続のみで到達できるようにする仕組みです。公式ドキュメントによれば、トンネルは「cloudflared」と「プロキシ」という2つのコンポーネントで構成されています。社内側で動くcloudflared（Cloudflareのオープンソーストンネルコネクタ）が外向きの接続を開始し、Anthropic側のプロキシがその内側TLSを終端したうえで、ホスト名ごとに適切な社内MCPサーバーへリクエストを振り分けるとされています。

公開される各MCPサーバーは、トンネルドメインの下にサブドメインを持ちます。たとえばdocs.<tunnel-domain>のような形です。このホスト名をManaged Agentsのセッションや、Messages APIのMCPコネクタに渡すことで、Claudeがそのサーバーのツールを呼び出せるようになるという流れです。なお、ZDR（ゼロデータ保持）やHIPAA BAAの適用範囲については別ページでの確認が必要とされており、単純にオンにすれば全て網羅されるわけではなさそうです。

前提条件・対象プラン

公式ドキュメントの記載を整理すると、導入前に揃えておくべき条件は次のとおりです。

この一覧を見て分かるとおり、MCPトンネルは単体で完結する機能ではありません。社内側にMCPサーバーがすでに存在すること、そしてDockerやKubernetesを扱える運用体制があることが前提になっています。ゼロから全部作る、というより既存の運用基盤に乗せる機能だと捉えたほうが実態に近いでしょう。

限界・注意点

「ファイアウォールを開けずに社内システムをAIにつなげる」と聞くと、それだけで安全性が完結するように感じるかもしれません。ですが公式ドキュメントを読む限り、そう単純ではない部分がいくつかあります。

特に見落とされやすいのが、トンネル区間の暗号化と、MCPサーバー自体の認可は別レイヤーだという点です。公式ドキュメントはセキュリティモデルを3層に分けて説明しており、外側のmTLS（トンネル入口の不正クライアント排除）、内側TLS（Cloudflareを含む中間者によるペイロード盗み見の防止）、そして各MCPサーバー上のOAuth（認証済みトンネル経由であっても不正なツール利用を防ぐ）が独立して機能する設計だとされています。トンネルを張ること自体は「配線」を安全にする作業であって、「誰が何を呼び出せるか」という認可の設計は依然として利用者側の責任です。この切り分けを誤解したまま導入すると、経路は暗号化されているのに、社内MCPサーバーのツールが実質的に無認証で叩ける、という事態にもなりかねません。

実務での使い方

1. 社内API・DBは先にMCPサーバー化してから晒す

MCPトンネルはあくまで「既存のMCPサーバーへの経路」を提供するものです。社内のデータベースやAPI、チケット管理システムをそのままトンネルに接続できるわけではなく、まずMCPサーバーとしてラップしておく必要があります。リモートMCPサーバーの実装例を参考に、社内システムごとにどのツールを公開するかを先に設計しておくと、トンネル設定自体はシンプルに進められます。

2. 認証方式は自組織のID基盤に合わせて選ぶ

認証方式には、Workload Identity Federationを使ったプログラマティックアクセスと、トークン・証明書を手動で管理する方式の2択があるとされています。OIDCの発行元をすでに持つ組織であれば前者のほうがトークンのローテーションを自動化でき、運用負荷は下がりそうです。逆に、まず動くものを見たいだけの検証段階では、手動credentialのほうが構成要素が少なく理解しやすいでしょう。

3. まずQuickstartで検証してから本番構成に進める

いきなりKubernetesやDocker Composeの本番構成を組むのではなく、公式のQuickstartが用意するローカルDocker Compose構成で一度エンドツーエンドの疎通を確認するのが安全です。サンプルのMCPサーバーに対してClaudeからツール呼び出しが成功することを見届けてから、Helmやプロダクション向けCompose構成に切り替える、という順序が公式の推奨する進め方になっています。

導入手順

公式Quickstartで示されている検証用の手順は次のとおりです。事前にDocker・Docker Compose、トンネルを管理できるConsoleロール、OpenSSL 1.1.1以降が必要とされています。

1. Claude Consoleの「Manage > MCP tunnels」から新しいトンネルを作成し、表示される「Domain」と「Token」を控える
2. 作業ディレクトリを用意し、控えた値を環境変数（TUNNEL_DOMAIN・TUNNEL_TOKEN）として設定する
3. OpenSSLで自己署名のCA証明書と、そのCAで署名したサーバー証明書を生成する
4. 生成したCA証明書をConsoleのトンネル詳細画面にアップロードする（アップロードが完了するとトンネルのステータスが「Active」に変わるとされる）
5. 検証用のサンプルMCPサーバー（FastMCPベースのシンプルなツール）を用意する
6. プロキシの設定ファイルと、mcp-proxy・cloudflared・サンプルMCPサーバーの3コンテナを定義したdocker-compose.yamlを作成する
7. docker compose up -dで起動し、ログに「route configured」「Registered tunnel connection」が出力されることを確認する
8. Managed Agentsのセッションを作成し、対象のトンネルとサブドメイン・パスを指定してMCPサーバーを追加したうえで、Claudeにツール呼び出しを依頼して疎通確認する

本番導入の際は、この検証構成をそのまま使うのではなく、KubernetesクラスタへのHelmデプロイ、またはVM向けのDocker Compose本番構成に切り替えることが公式ドキュメントでは推奨されています。ステップ数や画面文言は今後のアップデートで変わる可能性があるため、実施直前に公式ページの最新版を確認することをおすすめします。

つまずきポイント・注意点

• CA証明書のアップロード漏れ: CA証明書をConsoleに登録するまでトンネルは「Active」にならず、Anthropic側からの接続も始まらないとされています。疎通しない場合はまずここを疑うとよさそうです。
• トークンと秘密鍵の同時漏えい: 公式ドキュメントは、攻撃者がトンネルトークンとTLS秘密鍵の両方を入手した場合、プロキシになりすましてMCPリクエストのペイロードを読み取れる可能性があると警告しています。どちらも高価値な機密情報として扱う必要があります。
• 研究プレビューという前提を忘れない: 稼働率やサポートの保証がない状態で提供されているため、可用性要件の厳しい基幹システムをいきなり本番接続するのは時期尚早かもしれません。
• MCPサーバー側の認証設定忘れ: トンネルが経路を暗号化しても、MCPサーバー自体にOAuthなどの認証を設定し忘れると、認証済みのトンネル経由であれば誰でもツールを呼び出せる状態になりえます。

まとめ

MCPトンネルは、cloudflaredとAnthropicのプロキシという2つのコンポーネントを組み合わせ、社内ネットワークから外向きの接続だけで社内MCPサーバーをClaudeに到達可能にする仕組みです。インバウンドのポート開放や公開エンドポイントの用意が不要になる点は、情シスにとって確かに魅力的な変化だと言えます。

ただし、それは「経路の安全性」を解決する機能であって、「誰が何にアクセスできるか」という認可の設計まで肩代わりしてくれるわけではありません。3層のセキュリティモデルのうち、MCPサーバー上のOAuth設定は組織側の責任として明確に残っており、そこを省略すると、暗号化された経路の先に無防備なツールが待っている、という状態になりかねません。研究プレビューという提供形態そのものも、本番導入の判断材料として無視できない要素です。

次の一手としては、まずアクセス申請を行い、Quickstartのローカル構成で疎通を確認したうえで、社内のどのシステムをMCPサーバー化する価値があるかを棚卸しするのが現実的な進め方でしょう。そのうえで、認証方式の選定とMCPサーバー側の認可設計を、トンネル設定と同じ優先度で検討することをおすすめします。

出典

• MCP tunnels overview | Claude Platform Docs
• MCP tunnels quickstart | Claude Platform Docs