先に結論
OpenAI の Secure MCP Tunnel は、private MCP server を public 公開せずに ChatGPT や Codex から使えるようにした更新 です。
効くのは、社内 wiki、社内 DB、監視、チケット、独自ツールを MCP 化したいのに、public endpoint を増やしたくない組織です。
ただし今回変わったのは、agent をどこで走らせるか ではありません。変わったのは private tool にどう届かせるか です。
- private MCP 接続が欲しい → Secure MCP Tunnel を見る
- agent 実行環境ごと自社インフラへ寄せたい → 別の self-hosted 実行手段も見る
この切り分けを最初にしておくと迷いにくいです。Codex 導入の全体像から見たいなら OpenAI Codex enterprise rollout guide、private network 全体の比較から入りたいなら Self-hosted / private network 前提のAI coding agent比較 を先に見てもつながります。
何が変わったか
2026-05-19 の OpenAI API changelog で、OpenAI は Secure MCP Tunnel を enterprise customers 向けに公開しました。
今回の要点は3つです。
1. private MCP server を public internet に出さなくてよくなった
Secure MCP Tunnel を使うと、MCP server は社内ネットワークやオンプレのまま置けます。OpenAI 側には OpenAI-hosted の tunnel endpoint があり、ChatGPT、Codex、Responses API、AgentKit はその入口に向かって通常の MCP request を送ります。
つまり、MCP server 自体に public listener を立てる必要はありません。
2. 社内側では tunnel-client を動かし、outbound HTTPS だけでつなぐ
OpenAI の docs では、tunnel-client を private MCP server に届く場所で動かします。client は OpenAI へ long-poll し、MCP request を受け取って社内の server に転送し、返答を同じ経路で戻します。
必要なのは基本的に outbound HTTPS です。OpenAI は api.openai.com:443、control-plane mTLS を組む場合は mtls.api.openai.com:443 を案内しています。
要するに、inbound port 開放より outbound 接続で済ませたい組織向けの設計 です。
3. initial GA は account-led で、self-serve ではない
ここはかなり大事です。
Secure MCP Tunnel は docs が公開されていますが、この確認時点の changelog では initial GA is account-led rather than self-serve と明記されています。
つまり、今すぐ全員が管理画面から好きに有効化できる前提ではありません。PoC を急ぐ前に、契約、workspace、提供条件を OpenAI 側と確認したほうが安全です。
どういう仕組みか
仕組みはそこまで複雑ではありません。
- OpenAI 側で tunnel endpoint を用意する
- 社内ネットワーク側で tunnel-client を起動する
- tunnel-client が OpenAI へ outbound HTTPS で接続する
- ChatGPT や Codex が OpenAI-hosted endpoint に MCP request を送る
- tunnel-client がその request を社内の MCP server へ転送する
- 結果を同じ tunnel 経路で返す
ここで重要なのは、接続の起点が社内側にある ことです。OpenAI docs でも、private MCP server のアドレスは tunnel-client がいる trust boundary の内側でだけ使われると説明されています。
stdio の MCP server でも HTTP の MCP server でも扱える点も実務向きです。ローカル command を叩く構成と、社内 URL の MCP server 構成を分けて選べます。
誰に関係あるか
この更新が強く刺さるのは、MCP は使いたいが public endpoint を増やしたくない組織 です。
たとえば次のチームは相性がいいです。
ChatGPT や Codex から社内ツールを使いたいチーム
OpenAI の surface で agent 体験を寄せつつ、社内 docs、運用 API、内部 DB、独自システムを MCP 化したいなら候補になります。
特に Codex や Responses API をすでに見ている組織は、tool 接続の最後の1ピースとして刺さりやすいです。
inbound port を開けたくない Security、Infra 担当
public ingress を新設したくない組織では、そこで導入が止まりがちです。
Secure MCP Tunnel は、社内側から outbound HTTPS でつなぐ形を前提にしているので、説明の軸を作りやすいです。
ChatGPT Apps や MCP の位置づけが曖昧なチーム
ChatGPT 側の接続方法を広く見たいなら、ChatGPT Apps vs Zapier vs Make vs MCP と一緒に見ると整理しやすいです。今回の Secure MCP Tunnel は、その中でも private MCP をどう扱うか に話を絞った更新です。
先に確認したい前提条件
導入前に見るべきポイントは、機能の有無より運用条件です。
1. tunnel-client を置く場所から OpenAI と private MCP server の両方へ届くか
OpenAI docs では、tunnel-client を private MCP server に届く場所で動かす前提です。Kubernetes sidecar、専用 deployment、VM や systemd service などが例として挙がっています。
なので、まず確認したいのは次です。
- tunnel-client をどこに置くか
- そのホストから
api.openai.com:443に outbound HTTPS を許可できるか - そのホストから private MCP server の stdio command か HTTP endpoint に届くか
2. 権限を誰に持たせるか
docs では、runtime API key に Tunnels Read + Use が必要です。tunnel metadata を作成、編集するなら Tunnels Read + Manage も必要です。
ChatGPT connector 側でも、workspace 紐付けや operator 権限が不足すると tunnel が見えないことがあります。
技術検証の前に、誰が作るのか、誰が使うのか、誰が管理するのか を分けておくと後が楽です。
3. self-hosted 実行と混同しないか
ここは見落としやすいです。
Secure MCP Tunnel が解決するのは、private MCP server への接続です。agent のコード実行、filesystem、sandbox まで自社側へ移す話ではありません。
この違いを OpenAI 側で見たいなら Codex 周辺の enterprise 論点が参考になりますし、Anthropic 側の切り分けを見るなら Claude Managed Agents の self-hosted sandboxes 公開 が分かりやすいです。
今すぐどう動くべきか
一番現実的なのは、小さく切ることです。
まず private MCP 接続の要件を言語化する
最初に決めたいのは、何をつなぎたいかです。
- 社内 wiki や docs なのか
- DB や analytics なのか
- ticketing や incident response なのか
- 単純な read だけか、write も含むのか
ここが曖昧なまま tunnel を作っても、後で approval や権限設計がぶれます。
次に、どの surface から使いたいかを切る
OpenAI は ChatGPT web、Codex、Responses API、AgentKit を挙げています。
同じ MCP server でも、ChatGPT connector と API workflow では運用の置き方が変わります。PoC を早く回したいなら、最初から全部つなぐより 1 surface に絞る ほうが速いです。
最後に、account-led 前提で相談ラインを引く
self-serve ではない以上、社内稟議より先に OpenAI 側へ確認したほうが早いケースがあります。
特に enterprise 契約、workspace 権限、connector 運用者、mTLS の有無が絡むなら、PoC の条件整理を先に済ませたほうが手戻りを減らせます。
まとめ
OpenAI Secure MCP Tunnel の価値は、private MCP server を public に出さずに OpenAI の各 surface から使える道ができたこと です。
押さえるべきポイントは3つです。
- private MCP 接続が主語で、self-hosted 実行の話ではない
- 社内側の tunnel-client が outbound HTTPS で OpenAI とつながる
- initial GA は account-led で、今すぐ完全 self-serve ではない
なので、いま見るべきなのは『とにかく使えるか』ではありません。自分たちの private tool 接続要件に、この方式がきれいにはまるか です。
そこがはまるなら、OpenAI を使った enterprise agent 導入の現実味はかなり上がります。