OpenAI Secure MCP Tunnels：仕組みの解説（2026年版ガイド）

2026年5月27日、OpenAI は Secure MCP Tunnel をリリースしました。その目的はシンプルかつ明確です。MCP サーバーをプライベートに保ったまま、OpenAI の製品から呼び出せるようにすることです。公式ガイドとクライアントリポジトリは本記事末尾のソースセクションにすべて記載していますので、ウォークスルーの後に一次ドキュメントを確認できます。

1. TL;DR（要約）

Secure MCP サーバーをノートPC、VM、Kubernetes クラスター、またはプライベートネットワーク上で運用しており、ChatGPT、Codex、Responses API、または AgentKit から公開せずに利用したい場合に Secure MCP Tunnel を使用してください。サーバーの横で tunnel-client という小さなデーモンを実行します。これが HTTPS を介して OpenAI に発信し、ロングポーリングでタスクを待ち受け、各リクエストをサーバーに転送して回答を返します。インバウンドポートも、公開 URL も、ngrok も必要ありません。

MCP サーバーがすでに安全に公開されている場合（通常のホスト型 MCP ツールを server_urlと共に使用してください）、または MCP トラフィックを OpenAI がホストするエンドポイント経由でルーティングすることに懸念がある場合は、この機能は不要です。また、セキュリティセクションは二度読み返してください。このトンネルは ネットワークおよび認証情報の露出であり、 プロンプトインジェクションやツールポイズニングのリスクではありません。これらは別の問題です。

2. それは何なのか

以下はドキュメントからの直接の定義です。AI検索エンジンがそのまま引用するため、原文のまま記載する価値があります：

「Secure MCP Tunnelを使用すると、インバウンドのファイアウォールポートを開放したり、サーバーをパブリックインターネットに公開したりすることなく、プライベートなMCPサーバーをサポート対象のOpenAI製品に接続できます。」

そして、トンネルそのものについては、一段掘り下げるとこうなります：「MCPトンネルとは、ネットワーク内部のホストからOpenAIがホストするMCPエンドポイントへのアウトバウンド専用の接続です。」この「 アウトバウンド専用 」という単語こそが、設計のすべてです。あなたのネットワークがOpenAIからの接続を受け入れることは決してありません。常にこちらから接続を開始するだけです。

MCP (Model Context Protocol) は、AIモデルがJSON-RPCを介して外部ツールを呼び出せるようにするオープン標準です。通常のホスト型MCPツールにはパブリックな server_url — OpenAI自身の例では、以下のようなものを指しています https://mcp.stripe.com。Secure MCP Tunnelはこの要件を排除します。サーバーは localhostのまま運用可能です。

3. 存在理由

これまで、プライベートな MCP サーバーをホスト型モデルに接続するには、3つの厄介な選択肢のいずれかを選ぶ必要がありました。それぞれにセキュリティチームがブロックするような障害モードが存在します。

1. 公開する。 MCP サーバーを TLS と認証付きのパブリック URL に配置する。これにより、インターネットに面した新たな攻撃対象領域が生まれます。実際に MCP サーバーが誤って公開されてしまう問題は、現実に報告されています。
2. ngrok や Cloudflare Tunnel を使用してトンネル化する。 機能はしますが、汎用的なリバースプロキシに過ぎません。Quick tunnelsは「セキュリティ境界として設計されていない」ため、CORSはデフォルトでオープン、パスフィルタリング機能はなく、MCPも認識しません。
3. インバウンドファイアウォールルールを開放する。 セキュリティチームが最も承認しにくく、開発者用マシンではそもそも提供できない選択肢です。

Secure MCP Tunnelの回答は、接続を反転させることです。ドキュメントには「個別のパブリックな入口パスを導入するのではなく、既存の組織およびワークスペースのコンテキストに従う」と明記されています。つまり、新しい正面玄関を設置するのではなく、自身が制御するデーモンを、すでに存在するドアから外へ向かわせる仕組みです。

4. メンタルモデル：構成要素の名称

この機能は5つの要素で成り立っています。これらの名称を覚えれば、ドキュメントは一読で理解できます。

データフローはポーリングループであり、OpenAIがネットワークに対して永続的なソケットを開き続けるものではありません。上から順に読んでください：

        OpenAI cloud                         Your network (trust boundary)
 ┌─────────────────────────┐          ┌──────────────────────────────────────┐
 │ ChatGPT / Codex /        │          │                                        │
 │ Responses API / AgentKit │          │   tunnel-client (daemon)               │
 │           │              │          │        │            │                  │
 │           v              │          │        │            v                  │
 │  OpenAI-hosted tunnel    │  <====== │  (1) outbound HTTPS long-poll          │
 │  endpoint  (queues work) │          │      GET /v1/tunnel/{id}/poll          │
 │           │              │  ======> │  (2) queued JSON-RPC request           │
 │           ^              │          │        │                               │
 │           │              │          │        v                               │
 │  (4) response returns    │  <====== │  (3) forward to private MCP server     │
 │      to the product      │          │      (stdio command or HTTP URL)       │
 └─────────────────────────┘          │        │                               │
                                       │        v                               │
                                       │   Private MCP server (localhost / VPC) │
                                       └──────────────────────────────────────┘
   The MCP server never has a public listener. Every arrow your network draws
   is OUTBOUND. OpenAI never initiates a connection into your boundary.

結論：ポーリング設計であることに意味があります。常に外向きにのみ通信するデーモンであれば、ファイアウォールやセキュリティ担当者が論理的に判断可能です。永続的なインバウンドソケットではそうはいきません。

5. 最小限のエンドツーエンドの例

これはドキュメントにある標準的なクイックスタートをそのまま引用したものです。Platformのトンネル設定でトンネルを作成済みであり、その tunnel_idを持っていることを前提としています。これはトンネルをローカルの stdio に向けます。 MCP server — コマンドで起動するPythonスクリプト。

export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-command "python /path/to/server.py"

tunnel-client doctor --profile local-stdio --explain
tunnel-client run --profile local-stdio

3つのコマンドで動作します。 init サンプルから名前付きプロファイルを作成します。 doctor --explain プロファイルをチェックし、依存関係に問題がある場合はその理由を通知します。 run デーモンのポーリングループを開始します。 run コネクタの作成とテストを行っている間は、プロセスを維持してください。ドキュメントには「コネクタの検出とMCPツール呼び出しは、実行中のクライアントに依存する」と明記されています。

MCP serverがstdioではなくHTTPを使用する場合は、フラグを1つ切り替えてください。 --mcp-server-url の代わりに --mcp-commandを使用します：

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-http \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-server-url https://mcp.internal.example.com/mcp

その後、ChatGPTに触れる前に、デーモンが正常に動作していることを確認してください。 tunnel-client は、まさにこの目的のためにオペレーターエンドポイントとループバック管理UIを公開しています：

curl -fsS http://127.0.0.1:8080/healthz   # process is up
curl -fsS http://127.0.0.1:8080/readyz    # connected and polling
open    http://127.0.0.1:8080/ui          # local admin UI (loopback-only)

6. 各要素の詳細解説

6.1 リクエストのライフサイクル

ドキュメントでは、ループを5つのステップで説明しています。プロダクトがMCPリクエストをOpenAIホストのエンドポイントに送信し、エンドポイントがそれをキューに入れます。 tunnel-client はキューに入れられた作業をロングポーリングし、各JSON-RPCリクエストをプライベートなMCP serverに転送し、レスポンスを同じトンネル経由で送り返します。コネクタがストリーミング結果を要求した場合、パスは中間的なサーバー送信イベントを転送できるため、ストリーミングツールもそのまま機能します。ネットワークの開始点は常に境界内に留まります。

個人的な見解：「ロングポーリングを行い、処理できる分だけを転送する」ことで、自然なバックプレッシャーが得られます。OpenAIからの「サンダリング・ハード（大量の同時アクセス）」がサーバーに直接かかることはなく、クライアントが自身のペースで作業を取得します。

6.2 tunnel-client とプロファイル

tunnel-client はGoバイナリであり、オープンソースとして公開されています。 openai/tunnel-client. The docs are firm about distribution: get it from the Platform download link or the latest public release, and “keep your runbook pointed at the latest-release URL instead of hard-coding a specific release URL.” It is not on npm or PyPI. A プロファイル は名前付き設定（上記の local-stdio ）であり、1つのホストで異なる設定のトンネルを複数実行できます。また、環境変数やフラグですべてを制御することも可能で、その優先順位は flags > env vars > YAML > defaultsです。

推奨事項：フラグを羅列するのではなく、プロファイルを使用してください。 profiles/ ディレクトリをリポジトリに含め、シークレットを env:VARNAME や file:/path で参照するようにすることが、再現可能なデプロイと、再構築不可能な使い捨て環境との違いを生みます。

6.3 実行場所

MCPサーバーにアクセス可能な信頼境界内で tunnel-client を実行してください。ドキュメントでは以下の3つのパターンが挙げられています：

• Kubernetesサイドカー — MCPサーバーと同じPod内で実行し、 localhost経由で接続します。
• 専用のKubernetesデプロイメント — サーバーがプライベートなService経由ですでに到達可能な場合に、個別に実行します。
• VMまたはsystemdサービス — プライベートネットワーク経由でサーバーに到達できるホスト上で実行します。

推奨事項：サイドカーが最もクリーンなデフォルト構成です。同じPod内で、 localhost hopは1つのライフサイクルを持ちます。専用のデプロイメントを利用するのは、複数のワークロードで1つのMCPサービスを共有する場合のみにしてください。

6.4 権限とID

トンネルアクセスには、既存の組織およびワークスペースのコンテキストが使用されます。3つの権限アトムがアクセスを制御しており、これらは実際のロールに対応しています：

ランタイムAPIキーが tunnel-client 実行時に必要とするのは Read + Useです。管理用のIDには Read + Manage が必要で、トンネルメタデータの作成や編集を行います。これらは分離しておいてください。デーモンに作成や削除の権限を持たせるべきではありません。

推奨事項：最小権限の原則が組み込まれているため、これを活用してください。常駐するデーモンにはUseを、人間やCIジョブにはManageを割り当て、両者でキーを共有しないようにします。

6.5 Harpoon: 許可リストによるHTTPコールアウト

MCP以外では、 tunnel-client は、以下と呼ばれる組み込みの MCP server を同梱しています。 Harpoon これは、ラベルごとに限定された少数のプライベートな REST endpoint を公開するもので、リクエストとレスポンスのサイズに制限があります。これは、内部サービスを公開することなく、少数のサービスにアクセスするためのものです。ドキュメントには明確な境界線が引かれています。「Harpoon は汎用プロキシではありません。呼び出し側は任意のホストを選択できず、リクエストは顧客が設定したターゲットとメソッドに限定されます。」

個人的な見解：Harpoon はメスであり、VPN ではありません。「内部のあらゆるもの」にアクセスしたいのであれば、それは用途を超えています。その場合は、適切な MCP server を公開すべきです。

6.6 トンネル経由の OAuth

MCP server で OAuth を使用する場合、見落とすと午後を丸々無駄にしてしまう注意点が一つあります。OAuth discovery はトンネルを経由できますし、トンネルはブラウザ向けのフローにおいてアップストリームの authorization-server メタデータを保持します。しかし、ドキュメントにある通り、「authorization server 自体は自動的にトンネリングされません。もしそれがパブリックインターネットや tunnel-client host

から到達できない場合、MCP server に到達可能であっても OAuth フローは失敗する可能性があります。」

個人的な見解：MCP server をトンネリングする際は、OAuth authorization server がブラウザやクライアントの実行環境から到達可能であることを確認してください。MCP server に到達できても auth server に到達できない場合、原因不明のサイレントな失敗を引き起こします。

7. 私たちが誤解していたこと

最初の実行時に、4つの前提が裏目に出ました。それらはまさに、マーケティングのキャッチコピーが信じ込ませようとする内容そのものです。 私たちは「プライベート」とはデータが OpenAI に一切触れないことだと想定していました。 しかし、そうではありません。サーバーの address や credentials

はローカルに留まりますが、MCP のリクエストとレスポンスのペイロードは、他のホスト型 tool call と同様に、OpenAI がホストする endpoint を経由します。トンネルはサーバーの場所を隠すだけであり、ツールトラフィックを OpenAI のプラットフォームから排除するものではありません。ホスト型モデルに送信するには機密性が高すぎるペイロードであれば、トンネルを使ってもその状況は変わりません。 私たちはそれを「OpenAI 版の ngrok」だと想定していました。

私たちが探していたのは npm install。 存在しません。 tunnel-client は、ダウンロード可能なバイナリ、または openai/tunnel-client。他のOpenAI SDKにはすべてパッケージが存在していたため、今回も同様だろうと思い込み、10分を無駄にしました。

私たちは、トンネルを使えばセットアップ全体が「安全」になると想定していました。 トンネルはネットワーク経路を保護するだけで、悪意のある、あるいは操作されたツール呼び出しに対しては何の対策にもなりません。プロンプトインジェクションを受けたエージェントは、サーバーが正常に実行してしまうような、完全に有効なリクエストを送信できてしまいます。トンネルはネットワーク制御であり、認可やコンテンツの制御ではないのです。

8. アンチパターンと推奨パターン

9. よくある間違い（ドキュメントより抜粋）

これらは公式のトラブルシューティングおよび設定ノートから直接引用したもので、症状と根本原因を併記しています。

• ChatGPTでTunnelが表示されません。 原因: Tunnelが対象のワークスペースに関連付けられていないか、コネクタオペレーターにTunnels Use権限がありません。ワークスペースのスコープと権限を確認してください。
• コネクタの検出またはツール呼び出しが失敗します。 原因: tunnel-client run 停止しています。検出と呼び出しは実行中のクライアントに依存します。再起動してから再度実行してください。 doctor --explain。
• Tunnelの表示はできますが、編集ができません。 原因: オペレーターにTunnels Read権限はありますが、Manage権限がありません。メタデータを編集するIDにManage権限を付与してください。
• MCPサーバーには到達可能ですが、OAuthが失敗します。 原因: 認証サーバーがトンネル化されておらず、パブリックインターネットおよびクライアントホストから到達できません。認証サーバーに到達できるようにしてください。
• Tunnel経由のリクエストが断続的に失敗します。 原因: クライアントが接続されていません。 tunnel-client が再接続中の場合、復旧するまでリクエストは失敗します。 /readyz および /metricsを監視してください。

10. パフォーマンス、スケーリング、およびコストに関する注意点

まずは正直な数字から：OpenAIはトンネル固有のレイテンシやスループットの数値を公開しておらず、トンネルの価格に関するドキュメントも存在しません。ドキュメントとリポジトリが 提供しているのは、 動作を調整するための設定項目です。

• ロングポーリングのタイミング。 クライアントはロングポーリングでタスクを取得します。ポーリング間隔とインフライトリクエストの上限は設定可能です。これらを調整することで、アイドル接続数とタスク取得レイテンシのトレードオフを最適化できます。
• 接続のTTL。 MCPの接続ウィンドウには制限があります（リポジトリのデフォルトは数分程度です）。このウィンドウよりも長く実行されるツールは、進捗をストリーミングするか、制限時間内に完了させる必要があり、さもなければ切断されます。
• バックプレッシャーは自動的に機能します。 クライアントがプッシュを受け取るのではなくタスクをプルする仕組みのため、MCPサーバーの処理が遅い場合、負荷でダウンするのではなく、自身の取り込み速度が低下するだけです。スケーリングを行う際は、大量のトラフィックを受け止めるのではなく、クライアントの数を増やすか、より強力なサーバーを使用します。
• コスト。 ホスト型MCPツール全般について、OpenAIはツール定義のインポートやツール呼び出しに使用したトークンに対してのみ課金され、呼び出しごとの追加料金はないとしています。トンネル固有の料金については ドキュメントに明記されていません — 大規模利用で無料だと判断する前に、Platformの設定で確認してください。

11. 対象ユーザー（および対象外のユーザー）

12. コミュニティの反応

この発表はOpenAIのデベロッパーアカウントから行われ、Greg Brockman氏が「bring-your-own MCP servers（独自のMCPサーバーを持ち込もう）」と表現したことで拡散されました。

このアーキテクチャはOpenAI独自のものではありません。 Anthropicは数週間前に機能的に類似したMCP-tunnelパターンをリリースしており、コミュニティで最も鋭い議論が交わされているr/mcpのスレッドでは、両者を比較して「Anthropicの新しいmcp tunnelアーキテクチャ：エージェントが認証情報を保持しない」と評価されています。そこでのコンセンサスは、 セキュリティモデル （認証情報を境界に移動させることで、プロンプトインジェクションを受けたエージェントが盗むべきトークンを持たないようにする）については肯定的ですが、ロックインについては懐疑的です。

反対意見も引用する価値があります。 そのスレッドで最も支持されている批判は、トレードオフを明確に突いています：

「ループを所有するのではなく、境界を所有するのです。そのトレードオフが自分にとってプラスに働くかどうかは、[ベンダー]がそのループを運用することをどれだけ信頼できるか、そしてベンダーロックインをどれだけ許容できるかにかかっています。」
— r/mcp、トンネルアーキテクチャパターンについて

同スレッドの他の参加者からは、「ローカル証明書が漏洩・盗難されるのをどう防ぐのか？」という当然の疑問が投げかけられました。また、リスクの所在をトークンからベンダーの稼働状況へと移しただけで、根本的な解決にはなっていないという指摘もありました。これらはもっともな意見です。トンネルはトレードオフであり、ネットワーク露出を減らす代わりに、OpenAIがホストするコントロールプレーンへの依存度が高まるという側面があります。

13. 結論：使う価値はあるか？

14. 全体像

Secure MCP Tunnelは、より大きな変化の一端に過ぎません。主要なモデルベンダーは、以下を実現するために競い合っています。 あなたのプライベートツール 利用可能： ホストされたエージェント 何も公開することなく利用可能です。Anthropicがこれを実現し、OpenAIも同様です。アウトバウンド専用、境界での認証情報管理、ベンダー主導のループという共通のパターンは、エージェント接続におけるエンタープライズの標準的な形態になりつつあります。Googleや他社も、名称こそ違えど同様のプリミティブを提供してくるでしょう。

具体的な次のステップとして、 MCP Servers Setup Guide では、サーバーをIDEに接続する方法を解説しています。 Build Your Own MCP Server チュートリアルでは、トンネルの背後に配置するサーバーの作成方法を説明しており、 OpenAI Agents Python SDK guide では、これらのツールを利用するより広範なエージェントランタイムについて解説しています。

15. よくある質問 (FAQ)

16. 用語集

• MCP: Model Context Protocol。モデルがJSON-RPC経由で外部ツールを呼び出すためのオープン標準。
• MCP server: ツール、リソース、プロンプトをMCPクライアントに公開するプロセス。
• Secure MCP Tunnel: パブリックなリスナーを介さずに、プライベートなMCPサーバーをOpenAIの製品に接続するための機能。
• tunnel-client: OpenAIをポーリングし、リクエストをMCPサーバーに転送する、顧客側で実行されるデーモン。
• OpenAIホスト型トンネルエンドポイント: OpenAI製品が呼び出すパブリックエッジ。トンネル用のタスクをキューイングします。
• tunnel_id: トンネルの識別子。フォーマットは tunnel_ に32桁の16進数を加えたもの。
• ランタイムAPIキー: 認証情報 tunnel-client が使用するもの。Tunnels Read + Use権限が必要です。
• アウトバウンド専用: トラフィックは常にネットワーク内部から開始されます。OpenAI側から接続を開始することはありません。
• ロングポーリング: クライアントがHTTPリクエストを開いたまま待機し、キューイングされたタスクを取得する方式（プッシュ型ではありません）。
• stdioトランスポート: コマンドによって起動され、標準入出力（stdio）を介して通信するMCPサーバー。
• Harpoon: tunnel-client に組み込まれたMCPサーバー。厳密に許可リスト化されたプライベートなHTTPコールアウト用。
• mTLS: 相互TLS。クライアントとサーバーの両方が証明書を提示します。コントロールプレーンおよびMCP側ではオプションです。
• コネクタ: トンネルを含む、ツールソースを指し示すChatGPT側のオブジェクト。
• Responses APIでホストされたMCPツール: mcp tool type that lets the API call an MCP server, normally via a public server_url。

17. すべてのソースとリンク

一次情報源

• OpenAI: Secure MCP Tunnelガイド
• GitHub上のopenai/tunnel-client
• OpenAI: MCPとコネクタ（ホスト型MCPツール）
• MCP認可仕様（OAuth 2.1）

コミュニティ

• @OpenAIDevs: Secure MCP Tunnel発表ツイート
• r/mcp: トンネルアーキテクチャとロックインに関する批判
• r/OpenAI: ChatGPTのMCPサポートに対する反応

Webおよびセキュリティコンテキスト

• Invariant Labs: MCPツールポイズニング攻撃
• Cloudflare: リモートMCPサーバー（先行技術としてのトンネリング）
• Solo.io: MCPサーバーにおけるセキュリティ上の欠陥

内部リンク

• MCPサーバーのセットアップガイド
• MCPサーバーの構築方法
• 主要なMCPサーバーディレクトリ
• OpenAI Agents Python SDKガイド