OpenAIのSecure MCP Tunnel、社内ツールを公開せずChatGPTとCodexへつなぐ
OpenAIのSecure MCP Tunnelは、社内やオンプレミスのMCPサーバーを公開インターネットへ出さず、ChatGPT、Codex、Responses API、AgentKitから呼べるようにする仕組みです。ポイントは、AIに社内ツールを使わせるためにサーバーを外へ開くのではなく、社内側で動くtunnel-clientがOpenAIへアウトバウンド接続し、MCPリクエストを中継することです。AIエージェント連携は、公開MCPやSaaSコネクタの話から、企業ネットワークの境界を保った私有ツール接続へ進み始めました。
社内MCPを公開せず、OpenAI側から呼べる道を作る
OpenAIの説明では、Secure MCP Tunnelは、プライベートネットワーク、オンプレミス、ファイアウォール内にあるMCPサーバーを、公開インターネットへ出さずに対応製品へつなぐための機能です。社内側でtunnel-clientを動かし、OpenAIへのアウトバウンドHTTPS接続でキューを取りに行き、MCPのJSON-RPCリクエストをローカルへ転送して、同じトンネル経由で応答を返します。
この形だと、MCPサーバーに公開リスナーを立てる必要がありません。OpenAI側には通常のMCPエンドポイントのように見えますが、通信の開始点は社内ネットワーク内のクライアントに残ります。企業がAIエージェントに社内ツールを渡すとき、最初の壁になる「外から叩けるURLを作るか」という問題を避けられるのが大きいところです。
ChatGPTとCodexで同じ私有ツールを使う前提になる
対象として挙がっているのはChatGPT、Codex、Responses API、AgentKitなどです。つまりこれはAPI開発者だけの仕組みではなく、ChatGPTのカスタムコネクタやCodexの作業環境から、同じ社内MCPへ到達するための接続面として設計されています。OpenAIはMCP and Connectorsガイドでも、公開リモートMCP、SaaSコネクタ、そしてプライベートMCPを同じ道具立ての中へ並べています。
Interface Wire的に重要なのは、AIのUIがチャット欄だけで完結しなくなることです。ユーザーがChatGPTで尋ねる、Codexに修正を任せる、AgentKitのフローで処理する。その背後で、同じ社内ツールやデータ取得口が使われるなら、AIプロダクトの差はモデル性能だけでなく、どの作業面から安全に社内システムへ触れるかに移ります。
便利さより先に、承認とログの境界を設計する機能でもある
OpenAIはMCPガイドで、コネクタやリモートMCPが外部サービスへデータを渡したり、操作を実行したりできる点をはっきりリスクとして扱っています。デフォルトでMCPツール呼び出しに承認を求める設計、allowed_toolsで読み込むツールを絞る設計、機密操作では承認を残す設計は、Tunnelでも同じ文脈で見る必要があります。
Secure MCP Tunnelのガイドは、トンネル輸送のログとアプリ側のコンプライアンスログも分けています。トンネルはあくまで輸送路であり、ChatGPT側のカスタムアプリ利用ログや認証ライフサイクルログは通常どおり残る、という整理です。社内ツールをAIへ開くとき、どこまでがネットワーク接続で、どこからがアプリ操作なのかを分けて設計する。Secure MCP Tunnelは、その境界をOpenAI製品側へ持ち込む機能です。
Secure MCP Tunnelは派手なモデル発表ではありません。ただ、ChatGPTやCodexが企業の私有ツールを使うための入口を、公開URLではなくアウトバウンドトンネルに変える点で、エージェント製品の実用範囲を広げます。AIが「何を知っているか」より「どの閉じた道具を、どの承認で使えるか」が重要になる流れです。