私たちが セキュア MCP トンネルを開発したのは、チームにとって最も重要な MCP サーバーほど、インターネットには公開したくないことが多いためです。
プライベートサーバーを非公開に保ちつつ、ChatGPT、Codex、その他の OpenAI 製品に通常の MCP リクエスト経路を提供する。この制約にどう取り組んだのかを紹介します。
Model Context Protocol によって、AI システムを外部のツールやデータに接続しやすくなりました。しかし、特に価値の高い MCP サーバーの多くは、企業ネットワーク、プライベートなサービスメッシュ、開発者のノート PC など、パブリックネットワークからのインバウンド通信を拒否するように設計された環境で稼働しています。これらのサーバーをホスト型 AI 製品に接続するには、公開エンドポイントの作成、追加のプロキシ基盤の導入、あるいは機密性の高い通信経路への新たなネットワーク運用事業者の介在が必要になることがよくありました。
セキュア MCP トンネルは、よりシンプルな方法を提供します。 お客様はプライベート環境内で小さなクライアントを実行し、そこから OpenAI へのアウトバウンド HTTPS 接続を確立します。クライアントは次の役割を担います。
- MCP リクエストを受信
- 承認済みのローカルサーバーにリクエストを転送
- 同じ接続を通じてレスポンスと通知を返送
OpenAI 製品は標準の MCP リクエストとレスポンスのモデルを利用でき、背後にあるサーバーはお客様の既存のネットワーク制御で保護されたままです。
これを安全かつ確実に機能させるには、複数の技術的な課題を同時に解決する必要がありました。サーバーのプライベートネットワーク境界を維持すること、MCP のストリーミングと認証フローをサポートすること、そしてチームが自ら検証して運用できるクライアントを提供することです。この記事では、こうした設計上の判断を解説します。
トンネルの設計では、いくつかの原則を軸にしました。接続の開始をアウトバウンドに限定すること、接続先を明示的に設定すること、MCP のストリーミングと通知に対応すること、そしてお客様側で実行するクライアントをチーム自身が検証し、運用できることです。
これらを組み合わせることで、プライベート MCP サーバーを公開サービスにすることなく、プライベートなツールやデータを OpenAI 製品に簡単に接続できます。
定番の接続方法が抱える問題
現在、プライベートサービスにアクセスできるようにするには、通常、次の 3 つの方法のいずれかを使います。エンドポイントの公開、サードパーティー製トンネルの運用、または VPN やピアリング接続によるネットワークの拡張です。
- 公開エンドポイントは、境界の保護を弱めることでアクセスを容易にします。
- サードパーティーのトンネルプロバイダーを使えば、プライベートサーバーをすぐにアクセス可能にできます。しかし同時に、接続経路には、審査、契約、運用管理、そして信頼が必要なベンダーがもう 1 社加わります。企業のチームにとって、これは小さな問題ではありません。プライベートなツールを非公開に保つためのシステムで、トンネルプロバイダーもセキュリティレビュー、調達プロセス、運用手順書の対象となり、メタデータの取り扱いを考慮すべき範囲に加わるためです。
- VPN やネットワークピアリングは、広範なネットワーク接続を作ることでアクセスの問題を解決します。しかし、限定的な MCP 連携には大がかりすぎることがよくあります。
セキュア MCP トンネルは、より用途を絞った方法を採用しています。MCP サーバーの移動、ネットワーク境界の拡張、接続を担う別のベンダーの導入をお客様に求めるのではなく、プライベートサーバーの近くに、コードを検証できる小さなオープンソースクライアントを配置します。このクライアントが OpenAI への接続を開始し、制御します。
セキュア MCP トンネルは、接続の考え方を逆転させます。最初に接続を開始するのはプライベート側です。OpenAI 製品は、OpenAI がホストするトンネルエンドポイントに MCP リクエストを送信します。トンネルサービスは特定のトンネルに向けた処理をキューに入れ、プライベート MCP サーバーの近くですでに稼働しているお客様側のクライアントが、アウトバウンド HTTPS 接続を通じてそれを取得します。クライアントはリクエストをローカルに転送し、同じ経路でレスポンスを返します。
これにより、プライベートサーバーでパブリックネットワークからのインバウンド通信を受け入れたり、より広範なネットワーク接続を作ったりせずに、OpenAI 製品に通常の MCP リクエスト経路を提供できます。
図 1。セキュア MCP トンネルのリクエストライフサイクル。
最初にロングポーリングを選んだ理由
私たちはあえて、運用面では目新しさのない通信方式から始めました。アウトバウンド HTTPS は、企業のファイアウォールやプロキシ環境ですでに広く使われ、プラットフォームチームにもなじみがあります。ロングポーリングでは、トンネルクライアントが処理できる量だけを要求できます。そのため、際限なくバッファリングするのではなく、クライアント側のキューで自然にバックプレッシャーをかけられます。
この選択により、実際に提供する仕組みも次のように理解しやすくなりました。
- 製品が OpenAI のホストするエンドポイントに MCP JSON-RPC を送信します。
- お客様側で実行するクライアントが最終レスポンスを返すまで、トンネルサービスがリクエストを保持するか、ストリーミングします。
- 結果のストリーミングが要求された場合、トンネルは途中のサーバー送信イベントを転送できます。
その結果、MCP サーバーとそのアドレスを非公開に保ちながら、製品には通常の MCP リクエスト／レスポンス経路を提供できます。リクエスト、レスポンス、途中のイベントは、OpenAI がホストするトンネルエンドポイントを通じて中継されます。
明確なセキュリティ境界の維持
トンネルはネットワーク境界をなくす手段ではなく、その境界を明確にする手段です。お客様側で実行するトンネルクライアントはトンネルのコントロールプレーンに対して認証を行い、製品側は OpenAI がホストするトンネルエンドポイントを使用します。プライベート MCP アドレスは、お客様の環境内からのみ使用されます。トンネルへのアクセスは、お客様の既存の OpenAI 組織とワークスペースのコンテキスト、および設定済みのトンネル ID に紐づきます。独自のアクセスモデルを持つ別個のネットワーク経路が作られるわけではありません。
この設計では、接続の向きを正しく選ぶだけでは十分ではありません。トンネルクライアントはお客様の環境内で動くため、その動作を検証でき、かつ動作範囲を意図的に絞る必要があります。どのコードが動いているのか、どのアウトバウンド経路を開くのか、どのプライベートサービスへのアクセスが許可されているのかを、お客様が把握できる必要があります。
図 2。MCP サーバーはお客様のネットワーク境界の内側に留まります。
ローカルと同じ感覚で進められる MCP 開発
トンネルクライアントは、ネットワーク構築プロジェクトではなく、開発ツールとして手軽に使えるものを目指しました。開発者がノート PC で MCP サーバーを動かし、その近くでトンネルクライアントを起動すれば、公開エンドポイントの作成や、VPN、ファイアウォールルール、ピアリングの変更を待たずに、ChatGPT や Codex に接続できるようにしたいと考えました。
サーバーをノート PC から Kubernetes、VM、その他のお客様が管理する環境に移す際にも、同じ流れを引き継げることを目指しています。大切なのは、考え方が変わらないことです。プライベート MCP サーバーの近くでクライアントを実行し、クライアントからサーバーにアクセスできることを確認し、クライアントから OpenAI への接続を開始します。ヘルスチェック、レディネス、ログ、ローカル管理 UI は、うまく動かないときにこの一連の流れを確認するためのものです。トンネルの運用を大がかりなプロジェクトにするためのものではありません。
開発者体験への配慮は、Codex 自体にも組み込まれています。トンネルクライアントには Codex プラグインが付属しており、案内に沿ってセットアップを進められます。開発者が最初から tunnel-client のすべてのフラグ、プロファイル、コントロールプレーンの詳細を学ぶ必要はありません。目指しているのは、ローカルで一度だけ使える簡便な手段ではありません。サーバーをノート PC から Kubernetes、VM、その他の本番環境に移したときにも、チームがそのまま引き継げる形式の構成をプラグインで生成することです。
tunnel-client に同梱されたアシスタントのワークフローにも、同じ考え方が反映されています。アシスタントは tunnel-client が提供するローカルトンネルのコンテキストを読み取れるため、一般的な手順ではなく、実際のセットアップに基づいて開発者の状況判断を支援できます。有効なプロファイル、生成された構成、ローカル MCP サーバーにアクセスできるかどうか、トンネルクライアントの起動がどの段階まで進んでいるかを把握できます。 これにより、トラブルシューティングは別途エスカレーションする作業ではなく、開発の流れの一部になります。
図 3。ノート PC から本番環境まで、同じ tunnel-client の流れを使えます。
トンネルクライアントをオープンソースにする意義
トンネルクライアントは、お客様のネットワーク境界の内側、プライベート MCP サーバーの近くで、お客様自身が実行するオープンソースソフトウェアです。そのため、お客様やセキュリティレビュー担当者は、環境内で動くコードを検証できます。クライアントが何をするのか、どのアウトバウンド接続を開くのか、MCP リクエストをローカルにどう転送するのか、どの構成がアクセス範囲を制御するのかを確認できます。
この透明性により、信頼モデルとアーキテクチャの整合性を保てます。トンネルサービスは OpenAI がホストしますが、お客様の環境内で動くコードは小規模で、レビューが可能であり、お客様の管理下にあります。
広範なネットワークアクセスを必要としないエンタープライズ認証
プライベート MCP サーバーが、認証不要の単純な内部 HTTP エンドポイントであることはほとんどありません。OAuth、プライベート認証局、アウトバウンドプロキシ、あるいは MCP サーバーへの接続で使うクライアント証明書に依存していることもあります。こうしたサーバーに対応するには、企業ネットワークの前提を、お客様が個別に対処すべき例外ではなく、トンネル設計の一部として扱う必要がありました。
中心となる制約は、MCP サーバーを非公開に保つことです。MCP サーバーの OAuth ディスカバリはトンネル経路を通るため、MCP サーバーがパブリックインターネットで接続を待ち受けなくても、ホスト型製品は認証方法を取得できます。お客様側では、カスタム CA バンドル、プロキシ設定、MCP 側の mTLS など、ローカル環境に合わせてトンネルクライアントを設定できます。
境界も明確に保っています。トンネルによって、関連する企業内のすべてのエンドポイントに OpenAI から自動的にアクセスできるようになるわけではありません。認可サーバーが非公開の場合でも、OAuth フローを実行するコンポーネントからはアクセスできる必要があります。この境界は意図的なものです。セキュア MCP トンネルは、設定済みのプライベートなツールへの限定的な経路を提供するものであり、汎用的なネットワークブリッジではありません。
MCP 以外への展開
MCP はモデル用ツールの主要な形式ですが、お客様との初期アルファテストでは、密接に関連する別の課題も見えてきました。お客様のプライベートなワークフローがすべて、すでに MCP サーバーとして提供されているわけではありません。重要なワークフローの中には、同じファイアウォール境界の内側にある既存の REST API として実装されているものもあります。セキュア MCP トンネルが MCP へのアクセスだけを解決するなら、チームはこれらの関連するプライベート API のために、引き続き別途、公開エンドポイント、トンネルプロバイダー、VPN 経路、またはピアリングの構築プロジェクトを必要とします。
Harpoon は、この接続範囲を限定するモデルを、承認済みの REST 接続先にも拡張します。お客様は任意の URL を公開する代わりに、ラベルを付けた接続先をトンネルクライアントに登録します。OpenAI 側の呼び出し元は、セキュア MCP トンネル経由でそのラベルを指定して呼び出します。実際の HTTP リクエストは引き続き、お客様の環境内にあるプライベートサービスの近くから送信されます。
重要な制約は、ラベルが汎用的なネットワークブリッジにはならないことです。呼び出しは、お客様が管理する接続先の登録、許可されたメソッド、レスポンスサイズの上限、タイムアウト、リダイレクトの動作、トンネルのアクセス制御によって制限されます。これにより、お客様にインバウンドのネットワークアクセスを開放してもらったり、OpenAI に VPN 利用時のようなネットワーク上の ID を付与してもらったりすることなく、承認済みの OpenAI ワークフローに、お客様のプライベート API へのアクセスを制御できる経路を提供できます。