一般企業に勤めるSE向けに、AI関連の最新情報を「実務での判断」に翻訳して届ける。

調達

社内のMCPサーバを、外に出さずにつなぐ

OpenAI が2026年5月27日に Secure MCP Tunnel を出している。社内やローカルの MCP サーバを、インターネットに公開せずに ChatGPT・Codex・Responses API・AgentKit へつなぐための仕組みである。

通信の向き

要点は外向きだけで完結することにある。

  1. 社内に tunnel-client というデーモンを置く
  2. デーモンが api.openai.com の 443番ポートへ外向きに長時間ポーリングする
  3. MCP のリクエストを引き取り、社内の MCP サーバへ JSON-RPC で転送する
  4. 応答を返す

受信ポートを開けない。 社内サーバをグローバルに露出させずに済む。

クライアントは 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行になる。 反対しにくい構成だが、運用が増えることは隠さないほうが後で揉めない。

出典

  1. https://developers.openai.com/api/docs/guides/secure-mcp-tunnels.md
  2. https://github.com/openai/tunnel-client