
社内のMCPサーバを、外に出さずにつなぐ
OpenAI が2026年5月27日に Secure MCP Tunnel を出している。社内やローカルの MCP サーバを、インターネットに公開せずに ChatGPT・Codex・Responses API・AgentKit へつなぐための仕組みである。
通信の向き
要点は外向きだけで完結することにある。
- 社内に
tunnel-clientというデーモンを置く - デーモンが
api.openai.comの 443番ポートへ外向きに長時間ポーリングする - MCP のリクエストを引き取り、社内の MCP サーバへ JSON-RPC で転送する
- 応答を返す
受信ポートを開けない。 社内サーバをグローバルに露出させずに済む。
クライアントは openai/tunnel-client として公開されており、Apache-2.0 である。
権限は用途で分かれている。トンネルの作成・編集には Tunnels Read + Manage、tunnel-client の実行やアプリ作成時の選択には Tunnels Read + Use が要る。
で、SEの実務ではどう使うか
「社内システムをAIにつなぎたい」という要望に対して、これまでの答えは重かった。
社内のAPIを外から叩けるようにするには、DMZ を用意するか、逆プロキシを立てるか、VPN を通すかになる。どれもネットワーク側の設計変更を伴い、セキュリティレビューが長くなる。 そこで止まった話は多い。
外向きポーリングの構成は、その論点を1つ減らす。「受信ポートを開けますか」という質問が発生しない。
ただし別の論点が発生する。
社内サーバへ何が転送されるのかを説明できるか。 経路が外向きでも、転送されるリクエストの中身と権限は別問題である。MCPサーバ側の認可設計は自分で持つ必要がある。
デーモンをどこで動かすか。 社内で動く常駐プロセスなので、運用対象が1つ増える。落ちたら止まる。監視とログの置き場所を決めておく必要がある。
クライアントがオープンソースであることは、レビューを楽にする。 Apache-2.0 で読めるので、「何を送っているのか」を実装で確認できる。ブラックボックスの常駐プロセスを社内に置くのとは、審査の重さが違う。
稟議に書くなら「受信ポートを開けない。常駐プロセスが1つ増える。クライアントはオープンソース」の3行になる。 反対しにくい構成だが、運用が増えることは隠さないほうが後で揉めない。