まとめ
- ChatGPTからローカルMCPを操作するには、公開URLではなくSecure MCP Tunnel（gtunnel）を使える
tunnel-clientはローカルからOpenAIへ外向きのHTTPS接続を作り、MCPサーバーをインターネットへ公開しない- 通常のMCPサーバーはそのまま接続できる
- Codex MCP Serverのように
server/discoverへ対応していない場合だけ、互換proxyを挟む
Secure MCP Tunnelは2026年6月にOpenAIから紹介された仕組みで、ローカル側から外向きに接続するのが特徴になる。
構成
ChatGPT
│ Secure MCP Tunnel
▼
tunnel-client ── MCP server
Secure MCP Tunnelは、ローカルで起動したtunnel-clientがOpenAIへ外向きに接続する。ChatGPTからのMCPリクエストはトンネル経由でローカルへ届き、ローカルMCPの応答も同じ経路で返る。MCPサーバー側で公開ポートを開く必要はない。
tunnel-clientを用意する
PlatformのTunnel設定からtunnel_idを作成し、runtime API keyを用意する。tunnel-clientは同じ画面のダウンロードリンク、または公式リリースからインストールする。
必要な権限は用途ごとに異なる。
- Tunnelを作成・編集する: Tunnels Read + Manage
tunnel-clientを起動する、ChatGPT側でTunnelを選ぶ: Tunnels Read + Use- Platform組織とChatGPTワークスペースの関連付けを変更する: 組織の管理権限
tunnel-clientが使うのはruntime API keyで、Admin API keyではない。キーを発行したら、値は環境変数にだけ設定する。設定ファイルや記事、リポジトリには保存しない。
stdio MCPサーバー用のプロファイルを作る。
export CONTROL_PLANE_API_KEY="<runtime-api-key>"
tunnel-client init \
--sample sample_mcp_stdio_local \
--profile local-mcp \
--tunnel-id "<tunnel-id>" \
--mcp-command "/path/to/mcp/server"
tunnel-client doctor --profile local-mcp --explain
tunnel-client run --profile local-mcp
doctorが成功したら、tunnel-client runは起動したままにする。/readyzやローカル管理画面で状態を確認できる。
ChatGPTからローカルMCPへ接続する
ChatGPTのPluginsから開発者モードのアプリを作り、接続方式にTunnelを選ぶ。利用可能なTunnelから先ほどのTunnelを選択し、認証方式は「認証なし」を選ぶ。必要な確認に同意して作成する。
この構成では、MCPサーバー側のOAuth認証は使わない。Tunnelへの接続はtunnel-clientのruntime API keyで行う。
ChatGPTは接続時にserver/discoverを送り、利用可能なMCPの能力を確認する。
Codex MCP Serverを使う場合
codex mcp-serverはstdioでMCPサーバーを起動できる。ただし、ChatGPTが最初に送るserver/discoverには対応していないため、通常のMCPサーバーと同じように直接指定すると接続時に失敗する。
server/discover用にinitializeを先に送ると、Codexの「initializeは一度だけ」という制約と衝突する。そこで、tmcproxyではserver/discoverだけを処理し、tools/listで能力を確認する。initialize、tools/list、tools/callなどの他のJSON-RPCはそのままCodexへ転送する。
Codexを下流にする場合の設定は次のようになる。
command: "node /path/to/tmcproxy/src/tmcproxy.ts -- codex mcp-server"
注意点
MCPサーバーを公開せずに接続できる一方、ChatGPTからローカルのファイル操作やコマンド実行が可能になる。接続するMCPサーバー、公開するツール、ChatGPT側のアクション権限を確認してから使う。
ChatGPT 経由で tools/call を実行する場合、OpenAI 側の command response deadline（通常 3 分）で打ち切られる。MCP_CONNECTION_MAX_TTL（tunnel-client 側、デフォルト 10 分）は接続の寿命だが、1 回のツール呼び出し自体はコントロールプレーンから送られる response_timeout（3 分）で制限される。tmcproxy ではこの 3 分を伸ばせない。codex や subagent のように 3 分を超える可能性があるツールを呼ぶと、tunnel-client が接続を閉じ、tmcproxy は EPIPE でシャットダウンする。長時間エージェントを実行したい場合は、ChatGPT から直接ではなくローカルで codex を使うか、実行時間を 3 分以内に収めた小さいタスクに分ける。
Tunnelはチャットごとに作られるのではなく、起動中のtunnel-clientと下流MCPプロセスを複数のチャットで共有する。Codexの場合はproxyとcodex mcp-serverも共有される。チャットごとに完全に分離したい場合は、それぞれに別のTunnelとMCPプロセスを用意する必要がある。複数チャットから同時に使う場合は、下流MCPの状態やinitializeの扱いが競合しないか確認する。