Secure MCP Tunnel は「private MCP を公開せずに使う」責任境界を具体化した

要点

要点まとめ

社内やローカルに置いた MCP サーバーを、インターネットへ丸出しにせず agent から使いたい人向けの公式ガイドである。
要は『内側のサーバーの近くから外へだけ接続し、外から直接入ってこない形』に整理する仕組みだ。
その役を担うのが `tunnel-client` で、MCP サーバーに届く境界の内側で動き、OpenAI 側との中継点になる。
重要なのは接続のしやすさより、どこまでを OpenAI に任せ、どこから先を自社の認証、監査、権限管理で持つかを説明しやすくした点にある。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 仕事で安全に使いたい

権限、秘密情報、監査、失敗時の扱いを確認したい人向け。

同じテーマで読む AIエージェント

ツール利用、MCP、Agent SDK、長時間タスク、実行責任の設計。

次の記事 OWASP Prompt Injection は「騙される危険」を実装チェック項目へ落とす

外から入ってきた文章を AI が命令だと勘違いすると、その誤解が送信、削除、決済のような実行操作に変わることがある。

読解

何が変わったのか

これまで private MCP を agent から使いたい場面では、公開 endpoint を立てるか、VPN や踏み台を組むか、自前で境界設計するかが実装の重荷になりやすかった。このガイドは、MCP server 自体は customer-controlled environment の内側に残したまま、その近くで `tunnel-client` を走らせ、OpenAI 側の tunnel endpoint と outbound-only でつなぐ形をはっきり示しています。

日本の文脈

なぜ重要か

日本の企業内導入では、MCP が便利でも『社内サーバーをインターネットへ公開するのか』で止まりやすい。このガイドは、その前提自体を崩します。ただし楽になるのは公開設定だけで、権限管理や監査責任が消えるわけではありません。`tunnel-client` をどこに置くか、OpenAI に出る通信は何か、MCP server 側の認可はどこで切るかを説明できないと、結局は社内審査を通しにくいままです。

技術ポイント

技術的ポイント

Secure MCP Tunnel は inbound firewall port を開けずに、内側のホストから OpenAI-hosted endpoint へ outbound-only 接続を張る前提になっている。
`tunnel-client` は private MCP server と同じ trust boundary に置くのが基本で、sidecar、private service に届く別 deployment、VM/systemd service などの配置例が示されている。
ネットワーク要件は『OpenAI への outbound HTTPS』と『private MCP server への local/private reachability』に絞られている。control-plane mTLS や custom CA bundle を使う余地はあるが、MCP server 側の認証と認可は引き続き自分で考える必要がある。
運用面では `tunnel-client` の健全性が connector discovery と tool call の前提になる。runbook やログがないと接続不能時の切り分けが難しい。

用語

英日キーワード

英語	日本語	補足
Secure MCP Tunnel	Secure MCP Tunnel / 安全なMCPトンネル	private MCP server を公開せずに OpenAI 製品と接続する仕組み。接続容易化より trust boundary 配置の問題として読むべき。
tunnel-client	トンネルクライアント	社内境界内で動き、OpenAI と private MCP server の間を中継する実行体。置き場所がそのまま信頼境界になる。
private MCP server	非公開MCPサーバー	public internet に晒さない前提の MCP server。公開の代わりに outbound-only 接続で扱う設計が争点になる。
outbound HTTPS	外向きHTTPS通信	内側から外へだけ張る通信。MCP tunnel では inbound port 開放を避けるための前提になる。
control-plane mTLS	制御プレーンmTLS	OpenAI 側 control plane との相互認証。接続できることより、どの主体を信用するかの整理に関わる。
trust boundary	信頼境界	どこから先を未信頼入力として扱うかの境目。ローカル設定や起動時フックも trust 前なら未信頼として扱う。

試す

試すなら

まず自分の MCP server がどこにあり、誰が触れ、どの host なら private reachability を持てるかを書き出す。
`tunnel-client` を sidecar、専用 deployment、VM のどこに置くかを決め、OpenAI への outbound HTTPS 以外に何を許可するか最小化する。
runtime API key の権限を棚卸しし、トンネル用 principal を通常 API 利用と分離する。
接続後は discovery 成功だけで終わらせず、tool call 失敗時に `tunnel-client`、OpenAI 側、MCP server 側のどこで詰まったかを追えるログを残す。

注意

注意点

このガイドは接続経路を簡潔にするが、MCP server の中身の認可設計までは代行しない。読み取り専用と書き込み操作を同じ server に混在させるなら別途設計が必要。
`tunnel-client` の可用性が落ちると connector discovery や tool call が止まる。冗長化、再起動方針、監視粒度はこのページだけでは十分に詰まらない。
帯域、レイテンシ、長時間接続の制約はこのガイドからは読み切れない。高頻度 tool use や重い payload を扱う前には別検証が必要。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。