OpenAIは、プライベートネットワーク内のMCPサーバーを公開インバウンドなしでOpenAI製品へ接続するSecure MCP Tunnelを提供した。

トンネルクライアントは社内側からアウトバウンドHTTPS接続を確立し、OpenAIからのMCP要求を取得して内部サーバーへ中継する。ChatGPT、Codex、Responses APIから同じ接続基盤を利用できる。

何が変わったか

従来、OpenAI側から社内MCPへ到達させるには、公開エンドポイント、リバースプロキシ、VPN、Private Link相当の接続、または独自の中継APIを用意する必要があった。

Secure MCP Tunnelでは、社内ネットワークから外向きに接続する。ファイアウォールへ新しい受信ポートを開けず、MCPサーバーを公開DNSへ載せる必要もない。

変更前後の差

項目公開MCP方式Secure MCP Tunnel
通信開始OpenAI側からインバウンド社内クライアントからアウトバウンド
公開URL必要になりやすい不要
WAF・DDoS対策公開面で必要公開面は縮小
認証公開エンドポイントで実装OpenAI RBACとMCP認証を併用
可用性公開LBやGatewayへ依存トンネルクライアント群へ依存
監査Gatewayログ中心OpenAI監査、トンネル、MCPログを連結

公開面がなくなることは、認可が不要になることを意味しない。トンネルが到達可能なMCPサーバーと、MCPが実行可能なToolが新しい境界になる。

誰に影響するか

次のユースケースで検討価値が高い。

  • 社内CRMやチケットシステムをChatGPTへ接続する
  • Codexから内部開発ツールを呼ぶ
  • Responses APIのエージェントがオンプレミスDBを検索する
  • セキュリティ方針で公開インバウンドを禁止している
  • 公開MCPの証明書、WAF、IP制限の運用負荷が高い
  • 既存のMCPサーバーを大きく変更せず接続したい

ただし、MCPが書き込み、送信、削除、権限変更を行う場合は、ネットワークの非公開化だけで本番許可してはいけない。

必要な対応

アーキテクチャを四つの層に分ける。

  1. OpenAI側の利用者・Workspace・Project権限
  2. Tunnel IDとトンネルクライアント
  3. 内部MCPサーバーの認証・認可
  4. 各Toolが接続する下流システムの権限

一つの共有トンネルへ全社MCPを集約すると、障害・侵害・誤設定の影響範囲が大きくなる。環境、データ分類、業務領域で分離する。

実装・移行手順

1. MCPとToolを分類する

各MCPについて、所有者、接続先、扱うデータ、Tool一覧、読み書き区分、人間承認の要否を記録する。

read-only
write-internal
external-send
delete
permission-change
secret-access

2. 専用実行基盤を用意する

トンネルクライアントをMCPサーバーと同じ信頼境界または専用中継セグメントへ配置する。個人端末や共有開発サーバーで常時稼働させない。

3. Egressを限定する

アウトバウンドHTTPSを許可するが、送信先を必要なOpenAIエンドポイントへ限定する。DNS、Proxy、TLS検査を使う場合は、長時間接続や証明書検証を含めて動作確認する。

4. OpenAI側のRBACを設定する

誰がTunnelを作成、閲覧、接続、利用できるかを分ける。管理者権限とTool利用権限を同じロールへ集約しない。

5. MCP認証を残す

Tunnelがあることを認証済みとみなさず、MCPまたは下流システムでも呼出主体を確認する。利用者委任が必要な場合はOAuthを設計し、サービス共通資格情報の乱用を避ける。

6. 読み取り専用で開始する

最初は検索、参照、下書き作成だけを許可する。更新や外部送信は、人間承認と差分表示を実装してから追加する。

7. ログを相関できるようにする

最低限、OpenAI Request ID、Tunnel ID、MCP Request ID、Tool名、利用者、対象リソース、結果、承認IDを保存する。秘密値や全文データを無条件に記録しない。

失敗しやすい点

トンネルをVPNと誤解する

Secure MCP Tunnelは、ネットワーク全体をOpenAIへ接続する仕組みではない。許可されたMCP通信を中継する。内部サービスへの任意アクセスを前提にしない。

共有クライアントの過剰権限

一つのトンネルクライアントが多数のMCPと管理APIへ到達できると、侵害時の横展開が容易になる。

OAuthの責任境界が曖昧

利用者単位の認可が必要なToolを共通サービスアカウントで実行すると、誰の権限で操作したか説明できない。

完全なログがOpenAI側にあると仮定する

OpenAI側の監査だけでは、内部MCPが実行したSQL、下流APIの結果、ローカル拒否理由までは説明できない。複数層のログを関連付ける。

ヘルスチェックだけで正常判定する

トンネル接続がHealthyでも、MCP認証、Tool schema、下流API、DNS、OAuthが壊れている場合がある。業務シナリオで監視する。

評価方法

  • トンネル接続稼働率
  • 再接続回数と平均復旧時間
  • MCP要求成功率
  • P50・P95・P99レイテンシ
  • Tool別エラー率
  • 未承認Toolの拒否率
  • 書き込み操作の人間承認率
  • OpenAI Request IDから内部操作まで追跡できる割合
  • トンネル停止後に要求が遮断されるまでの時間
  • クライアント侵害を想定した到達可能範囲

性能試験では、同時接続、長時間処理、大きな応答、タイムアウト、再試行、重複実行を含める。

ロールバック

トンネル導入前の公開MCPを残す場合、同時に二つの経路を常時有効にしない。切替期間は、公開経路を読み取り専用またはIP制限下に置く。

障害時は次の順で戻す。

  1. 高リスクToolを停止する
  2. Tunnel経由の新規要求を止める
  3. 実行中要求と重複実行を確認する
  4. 承認済みの旧経路だけを一時有効化する
  5. 復旧後に旧経路を再び閉じる
  6. 切替期間のログを照合する

公開エンドポイントへ戻す場合は、証明書、WAF、認証、レート制限が現在も有効か確認する。古い経路が放置されている可能性がある。

編集部分析

Secure MCP Tunnelの本質は、公開面を消すことではなく、接続経路をOpenAI管理の論理チャネルへ限定することにある。これにより、インターネット露出、証明書運用、公開Gatewayの負担は減る。

しかし、MCPの危険性はネットワーク到達性だけではない。Tool schemaが広い、入力検証が弱い、下流資格情報が強い、人間承認がない場合、非公開ネットワーク内で大きな操作が実行される。公開されていないため、通常の外部攻撃面監視で見つけにくくなる面もある。

導入判断は「公開ポートを閉じられるか」ではなく、「利用者からTool実行、下流変更まで一貫して認可・監査できるか」で行うべきである。

実務チェックリスト

  • [ ] MCPとToolをデータ分類・操作リスクで棚卸しした
  • [ ] 環境・業務領域ごとにTunnelを分離した
  • [ ] トンネルクライアントを専用基盤で実行した
  • [ ] アウトバウンド宛先を限定した
  • [ ] OpenAI RBACとMCP認可を別々に設計した
  • [ ] 共通管理者資格情報をToolへ渡していない
  • [ ] 書き込み・送信・削除へ人間承認を設定した
  • [ ] OpenAIと内部ログをRequest IDで相関できる
  • [ ] クライアント停止・再接続・重複実行を試験した
  • [ ] 旧公開経路の停止条件を決めた

一次情報