OpenAI が公開した Secure MCP Tunnel とは。社内 MCP を安全に ChatGPT へ繋ぐ仕組み anchor left anchor right

May 28 2026 AIニュース

OpenAI が公開した Secure MCP Tunnel とは。社内 MCP を安全に ChatGPT へ繋ぐ仕組み

anchor left anchor right

📖 この記事で分かること

  • Secure MCP Tunnel が解決する課題の正体
  • アーキテクチャと通信の流れ
  • 必要なものと最小構成のセットアップ手順
  • Anthropic 系 MCP との位置づけの違い

💡 知っておきたい用語

  • MCP:AI モデルに外部ツールやデータを安全に接続するための共通プロトコル
  • アウトバウンド接続:社内から外側に向かう通信のこと。ファイアウォールを開けずに使える
  • tunnel-client:Secure MCP Tunnel の実体となる、社内側で常駐するエージェントプログラム

最終更新日: 2026年5月28日

▶ 公式ページ

Secure MCP Tunnel の正体

この記事のポイント

  • OpenAI が Secure MCP Tunnel(2026年5月時点)を公開し、社内に置いた MCP サーバを公開せずに ChatGPT・Codex・Responses API から呼べるようになりました。
  • 通信は社内側からの外向き HTTPS のみで、インバウンドのポート開放やパブリック IP の付与は不要です。
  • 必要なものは tunnel_id・ランタイム API キー・tunnel-client バイナリの 3 点で、stdio と HTTP の両方の MCP サーバに対応します。

OpenAI が 2026 年 5 月時点で公開している Secure MCP Tunnel は、企業や個人開発者が社内・オンプレ・ローカル環境に置いた MCP サーバを、インターネットに公開することなく、ChatGPT や Codex、Responses API から利用できるようにする仕組みです。

仕組みの肝は通信方向の逆転にあります。従来、外部の AI から社内のサーバを呼ばせるには、社内サーバ側に公開エンドポイントを用意するか、VPN を構成する必要がありました。Secure MCP Tunnel では、社内側で tunnel-client というエージェントを動かし、そこから OpenAI の指定エンドポイントに向けてアウトバウンドの HTTPS 接続を張ります。OpenAI 製品からのリクエストはその接続経由で受け取り、社内 MCP サーバに転送して、レスポンスを同じ経路で返します。

なぜこの仕組みが必要だったのか

MCP は AI モデルに外部のツールやデータソースを接続するための共通プロトコルとして、2024 年末から急速に広がりました。ChatGPT や Claude といった主要な AI クライアントが MCP に対応したことで、業務システムと AI を直接つなぐ動きが現実的になっています。

ただし MCP を実運用しようとすると、ほぼ必ず突き当たる壁があります。社内システムやオンプレのデータベース、開発機上のローカルツールなど、外に公開できないリソースをどう AI に渡すか、という問題です。MCP サーバ自体をクラウドの公開エンドポイントに置き直すのはコストもリスクも大きく、VPN や踏み台サーバを噛ませる方式は構成と運用が重くなります。

Secure MCP Tunnel はこの課題に対して、社内側から外向きに 1 本だけアウトバウンド接続を張る構成を提示しました。社内ネットワークのファイアウォール設定を変更せず、MCP サーバには公開 IP を付与せず、それでも ChatGPT 側からは通常の MCP リクエスト経路として扱えるという設計です。

アーキテクチャと通信の流れ

通信フローは次のようになります。

第 1 段階として、利用者が OpenAI の Platform tunnel settings 画面でトンネルを作成し、tunnel_id を発行します。次に、社内ネットワーク内部の任意のホストで tunnel-client を起動します。tunnel-client は OpenAI のコントロールプレーン(既定では api.openai.com:443、mTLS 構成時は mtls.api.openai.com:443)に対してアウトバウンドの HTTPS 接続を張り、自身に割り当てられた tunnel_id でロングポーリングを始めます。

ChatGPT などの OpenAI 製品からのリクエストは、OpenAI 側に用意されたトンネルエンドポイントに届きます。tunnel-client はこの受信したジョブをロングポーリング経由で引き取り、設定された MCP サーバ(stdio コマンドまたは HTTP URL)に対して JSON-RPC リクエストとして転送します。MCP サーバが返したレスポンスは、再び同じトンネル経路で OpenAI 側に戻り、最終的に呼び出し元の ChatGPT 等に到達します。

ストリーミング応答にも対応しており、コネクタが Server-Sent Events で逐次結果を求めた場合は、その中間イベントもトンネル経由でそのまま転送されます。

セットアップに必要なもの

最小構成で必要となるのは次の 3 つです。

第一に、Platform tunnel settings で発行する tunnel_id です。第二に、tunnel-client の認証に使うランタイム API キーで、対象のトンネルに対する Tunnels の Read と Use 権限を持つ必要があります。トンネルの作成・編集を行う管理者には別途 Manage 権限が必要です。第三に、tunnel-client バイナリ本体で、openai/tunnel-client の GitHub Releases から取得します。

加えて、tunnel-client を動かすホストから、OpenAI のコントロールプレーンと社内 MCP サーバの双方に到達できる必要があります。MCP サーバとの接続は stdio(ローカルプロセス起動)と HTTP(社内ネットワーク内の URL)のどちらでも構いません。

最小構成のコマンド例は以下のとおりです(2026年5月時点の公式ドキュメントより)。

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

HTTP の MCP サーバに繋ぐ場合は、--mcp-command の代わりに --mcp-server-url https://mcp.internal.example.com/mcp を指定します。tunnel-client run を起動したまま、ChatGPT のコネクタ設定画面で「Tunnel」を選択し、対象のトンネルを指定すれば接続が完了します。

どこで動かすか

tunnel-client は MCP サーバに到達可能な信頼境界の内側であれば、どこに置いても構いません。公式ドキュメントが想定する典型構成は以下の 3 パターンです。

Kubernetes 上で MCP サーバと同じ Pod 内のサイドカーとして動かす構成、MCP サーバが既にプライベート Service として公開されている場合に専用の Deployment として動かす構成、そして仮想マシンや物理サーバ上で systemd サービスとして常駐させる構成です。

ローカル開発機での運用も想定されており、自宅やオフィスのワークステーションで動かしている stdio 型の MCP サーバを ChatGPT から呼ばせる、といった使い方もそのまま成立します。

セキュリティと運用面の特徴

通信は全て社内側からの発信のため、MCP サーバのアドレスや内部ネットワーク構成が外部に露出することはありません。認証は OpenAI の組織・ワークスペース権限体系にそのまま乗る形になっており、別系統の公開エンドポイントを追加で管理する必要はありません。

エンタープライズ環境向けの要件として、アウトバウンドプロキシ経由の通信、カスタム CA バンドル、コントロールプレーンとの mTLS、MCP サーバ側との mTLS にも対応しています。tunnel-client 自体には /healthz/readyz/metrics エンドポイントと、ローカル管理 UI(デフォルトはループバックのみ)が用意されており、運用監視のフックも整備されています。

生 HTTP のロギングはデフォルト無効で、サポート用のエクスポートも秘匿情報が伏せられた状態で出力されます。

編集部の見方

位置づけ:Secure MCP Tunnel は、MCP の本格的な業務活用フェーズで必ず出てくる「社内システムをどう繋ぐか」問題に対する、OpenAI 側からの公式回答です。ngrok や Cloudflare Tunnel のような汎用トンネルではなく、MCP のリクエスト経路に特化した設計になっている点が肝心です。汎用トンネルを使って MCP サーバを公開する構成と比べ、認証や権限管理が OpenAI 側の権限体系と統合される分、運用がシンプルになります。

Anthropic 系 MCP との対比:Anthropic が打ち出している MCP のローカル接続(stdio・HTTP・Streamable HTTP)は、Claude Desktop など利用者の手元のクライアントから直接 MCP サーバへ話す前提でした。Secure MCP Tunnel は逆に、クラウド側にある ChatGPT から社内 MCP を呼ばせるための仕組みです。両者は競合するものではなく、利用シナリオが異なります。社内のメンバー個人が手元の AI クライアントから業務システムを使う用途と、組織全体で ChatGPT を入り口に業務システムを統合していく用途で、それぞれ別の解になります。

Anthropic が MCP を基盤にエコシステムをどう拡張しているかについては、以下の記事で詳しく解説しています:

Harpoon という拡張:tunnel-client には Harpoon という組み込み MCP サーバが含まれており、設定済みの社内 HTTP エンドポイントだけをラベル経由で AI に呼ばせる構成が取れます。新規に MCP サーバを書き起こさなくても、既存の社内 REST API のうち AI に開放したいエンドポイントだけをホワイトリスト形式で接続できるため、実装コストが下げられます。これは MCP サーバを 1 から実装する余裕がない現場にとって現実的な選択肢になります。

注意したい運用上の落とし穴:OAuth フローを必要とする MCP サーバの場合、認可サーバ(Authorization Server)自体はトンネル経由で自動公開されない仕様です。MCP サーバはプライベートのままでも、認可サーバが「公開ネットからも tunnel-client ホストからも到達不能」な状態だと OAuth フローが失敗します。社内 IdP を使う構成では事前の経路確認が必要です。

まとめ


よくある質問

Q: 既存の ngrok や Cloudflare Tunnel で代替できますか?

A: 技術的には可能ですが、Secure MCP Tunnel は MCP の JSON-RPC 経路と OpenAI 側の権限体系に統合された設計になっており、認証・観測性・運用面で専用ツールならではの利点があります。汎用トンネルでは別途、エンドポイント側の認証・認可を自前で組む必要があります。

Q: tunnel-client は常駐させる必要がありますか?

A: はい。tunnel-client が停止している間は、ChatGPT 側でコネクタ探索や MCP ツール呼び出しが失敗します。本番運用では Kubernetes の Deployment、systemd サービスなど、再起動と監視が効く形での常駐構成が前提です。

Q: 料金はかかりますか?

A: 2026 年 5 月時点で、Secure MCP Tunnel 自体の追加料金体系は公式ドキュメントに明記されていません。利用には OpenAI Platform のアカウントと API キーが必要で、API キーの利用に伴う通常の従量料金は発生します。


まとめ

Secure MCP Tunnel は、社内に閉じた MCP サーバを ChatGPT・Codex・Responses API から呼べるようにする、OpenAI 公式の接続経路です。アウトバウンドの HTTPS 接続だけで成立する設計のため、ファイアウォール構成や VPN 構築を伴わずに導入できます。MCP の業務利用が本格化していく中で、社内システムを AI ワークフローに組み込む際の標準的な選択肢の 1 つになる可能性があります。


【用語解説】

  • MCP: Model Context Protocol の略。AI モデルに外部ツールやデータを接続するための共通仕様。2024 年に Anthropic が公開し、その後 OpenAI など他社にも採用が広がった
  • JSON-RPC: JSON 形式でリモートプロシージャ呼び出しを行うプロトコル。MCP はこの上に構築されている
  • mTLS: 通信の両端が互いに証明書を提示して認証する方式。エンタープライズ用途で内部通信の信頼性を担保するために使われる

引用元:


この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。

anchor left anchor right
KOJI TANEMURA

15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。

人気の記事

anchor left anchor left

おすすめの記事

anchor left anchor left

categories

anchor left anchor left

tags

anchor left anchor left