OpenAIのSecure MCP Tunnelは、社内やオンプレミスに置いたMCP serverを公開インターネットへさらさずに、ChatGPTやCodex、Responses APIから使えるようにする仕組みです。ポイントは、外から社内へ穴を開けるのではなく、社内側で動かす tunnel-client が outbound HTTPS で OpenAI に接続し、キューされたMCPリクエストを取りに行く構成にあります。
Secure MCP Tunnelとは何か
公式ガイドでは、Secure MCP Tunnelを「inbound firewall port を開けず、private MCP server を public internet に exposed しないまま接続する方法」と説明しています。tunnel-client は OpenAI hosted endpoint を long-poll し、社内で到達できる stdio または HTTP のMCP serverへ JSON-RPC を転送し、その応答を同じ経路で返します。つまり、OpenAI製品から見れば通常のMCP呼び出しですが、実際のサーバーアドレスは社内境界の内側に残ったままです。
なぜ企業導入で注目されるのか
これまで private MCP server を hosted AI 製品につなぐには、public endpoint 化、外部トンネル事業者の導入、VPN や peering の追加といった回り道が必要でした。OpenAIの開発者向けブログは、こうした方法は境界を弱めたり、余分なベンダー審査や運用負荷を増やしたりしやすいと整理しています。Secure MCP Tunnelはここを絞り込み、OpenAIとの通信を outbound HTTPS だけに限定しつつ、OpenAI側では通常のMCP request pathを維持するため、セキュリティレビューと運用の両方を軽くしやすい設計です。
特に効くのは、MCP server が developer laptop、VM、Kubernetes、private service mesh の内側にあるケースです。既存の network control を保ったまま接続できるため、「まずローカルで検証し、後で本番の private environment に持ち込む」という段階的な導入がしやすくなります。公式資料でも laptop から production まで同じ mental model を維持できることが強調されています。
導入前に確認したい3つの判断軸
1つ目は通信要件です。必要なのは tunnel-client を置くホストから api.openai.com:443 への outbound HTTPS と、必要に応じて mtls.api.openai.com:443 への接続、そして社内MCP server へのローカル到達性です。一般的な inbound rule の追加が不要な一方、社内proxy、custom CA bundle、MCP-side mTLS など既存企業ネットワーク前提との整合は事前確認が必要です。
2つ目は権限設計です。トンネル作成・編集には Tunnels Read + Manage、実行や利用には Tunnels Read + Use が必要で、さらに ChatGPT 側の developer mode 権限は別管理です。Platform organization の権限と ChatGPT workspace 側の権限が分かれているため、情シス・Platform管理者・業務部門のだれが何を持つかを先に決めないと、接続自体はできても運用が止まりやすくなります。
3つ目は認証と監査です。OpenAIは OAuth discovery を tunnel path 経由で扱えるようにしていますが、authorization server 自体まで自動的にトンネルされるわけではありません。つまりMCP serverは private のままでも、OAuth に必要な別系統の到達性が不足すると認証フローは失敗します。また、tunnel transport 自体は ChatGPT Compliance Platform の app event と別で、tunnel.created などの metadata change は Platform audit logs に出る、というログ境界も把握しておくべきです。
実装・運用で外しにくいチェックリスト
まず Platform tunnel settings で tunnel_id を作成し、runtime API key を分けて発行します。そのうえで tunnel-client を private MCP server と同じ trust boundary に置き、doctor --explain で疎通確認してから run します。Kubernetes sidecar、専用Deployment、VM/systemd のどれでもよいですが、/healthz、/readyz、/metrics、loopback-only の /ui を見て healthy と ready を確認してから ChatGPT connector や Codex 側の接続テストに進むのが安全です。
社内MCP serverの公開可否、RBAC、OAuth、監査ログ、導入順序まで含めて設計したい場合は、PoC前に運用ルールを先に固めるのがおすすめです。HelloCraftAIでも、要件整理から検証計画の整理まで ご相談ください 。
FAQ
Q. Secure MCP Tunnelを使えば社内MCP serverは完全に公開不要ですか？ A. 少なくともMCP server自体に inbound public listener を持たせる必要はありません。ただし OAuth の認可サーバーや関連エンドポイントの到達性は別途確認が必要です。
Q. ChatGPTとCodexのどちらでも使えますか？ A. 公式ガイドとGitHub READMEでは、ChatGPT、Codex、Responses API、AgentKit など対応OpenAI surface から利用できると案内されています。どの組織・workspaceに紐づけるかは tunnel association の設定次第です。
Q. private REST APIにも使えますか？ A. 公式資料では、embedded MCP server の Harpoon を使って label 指定の private REST target へ狭く到達させる方法も紹介されています。任意URLへ出られる一般プロキシではなく、method や response size を制限した bounded callout として使う設計です。
