公開しないのにつながる？Secure MCP Tunnel の逆転の発想！

みんな、しぃちゃんだよ！今日はちょっとニヤッとしちゃうネットワークのお話だよ。「社内に置いたままの MCP サーバーを、インターネットに晒さずに OpenAI の製品からつなぐ」っていう発表なの。

OpenAI Developers developers.openai.com

なにが発表されたの？

OpenAI の 開発者ブログで、Secure MCP Tunnel っていう仕組みが発表されたよ。企業が社内に持っている便利な MCP サーバーを、公開エンドポイントにしたり VPN を組んだりしなくても、OpenAI のホストする AI からつなげるようにするものなの。タイトルもそのまんま「Making private MCP servers reachable without making them public」だよ。

なぜ重要なの？

これまで社内の MCP サーバーを外の AI につなぎたいとき、選択肢はどれもちょっと重かったの。公開エンドポイントを生やすとセキュリティが不安、サードパーティのトンネル業者を挟むとベンダーが増える、VPN やネットワークピアリングを組むと構成が複雑…。「価値ある社内ツールほど安全につなぎにくい」っていうジレンマがあったんだよね。

深く潜ってみよう

いちばん賢いのは接続の向きなの。ふつうはサーバー側が外からの通信を受け付けるけど、Secure MCP Tunnel はそれを逆さまにするよ。

the private side makes the first move.

プライベート側から先に動くの。お客さんが自分の環境で動かすトンネルクライアントが、OpenAI 側へ向けて外向き（アウトバウンド）の HTTPS 接続を張るんだよ。OpenAI の製品が MCP ツールを呼びたくなると、リクエストは OpenAI がホストするトンネルの入口にキューとして溜まる。クライアントはそれを long-polling で拾いにいって、手元のプライベート MCP サーバーに渡して、返事を同じ外向き接続で戻す…という流れなの。

トランスポートはあえて HTTPS 上の long-polling。企業のファイアウォールにとって「退屈なくらい普通」な通信にしてあるから通しやすいんだって。バックプレッシャーもクライアント側のキューが処理能力に応じて自然に効くし、ストリーミングも server-sent events を中継してくれるから途中経過も届くよ。

認証まわりも実戦的で、OAuth・プライベート認証局・クライアント証明書・アウトバウンドプロキシに対応。MCP サーバーを公開しないまま、企業の既存の認証をそのまま活かせるの。

トンネルクライアント自体はオープンソースで、お客さんの環境の中で動く自前ソフト。中身を監査できるのが安心だよね。ローカルの管理 UI でヘルスチェックや切り分けができて、Codex 用のプラグインがセットアップをガイドしてくれる。開発者のノート PC でも本番の Kubernetes でも同じ構成で動くのがうれしいところ。

おまけに Harpoon っていう拡張もあって、同じファイアウォールの内側にある承認済みの REST API にも同じモデルを広げられるの。任意の URL を晒すんじゃなくて、ラベル付けした宛先だけを対象にする形だよ。

もちろん境界はきっちり。プライベートなアドレスはお客さんの環境の中だけで使われるし、アクセスは組織のコンテキストに紐づく。どのサービスに届くかは設定で明示的に絞られていて、汎用のネットワーク橋を作るわけじゃないの。

まとめ

• Secure MCP Tunnel は、社内 MCP サーバーを公開せずに OpenAI 製品へつなぐ仕組み（OpenAI の 開発者ブログ発表）
• ポイントは「プライベート側から外向き HTTPS を張る」逆転の接続。long-polling で退屈なくらい普通の通信に
• ストリーミング中継・バックプレッシャー・OAuth やクライアント証明書などの企業向け認証に対応
• トンネルクライアントはオープンソース＆自前運用。管理 UI と Codex プラグイン付き
• Harpoon で承認済みの REST API にも拡張できる

セキュリティ都合で社内ツールを外の AI につなげずにいたエンタープライズのチームに、ど真ん中で刺さる発表だよ！