AIREITER

ChatGPT MCPサーバーのデプロイ完全ガイド：構築から本番公開まで

最終更新日: 2026-10-01 19:12:45

ChatGPT MCPサーバーのデプロイは、/mcpが応答した時点で完了するわけではありません。ChatGPTから接続でき、適切なツールを発見でき、ユーザーを認証でき、必要な場面で正しいツールを選べて、初めて実用になります。多くのチームにとってはマネージドホスティングが現実的なデフォルトで、プライベートなインフラを使うならSecure MCP Tunnelの背後に置く構成が適しています。

コードを書く前に、デプロイ先の境界を決める

どこにデプロイするかで、トランスポート、認証の実装量、運用負担、公開可否が決まります。ChatGPTはリモートMCPクライアントです。一部のデスクトップクライアントのように、ローカルのstdioプロセスを直接起動することはありません（OpenAI Help Center）。

デプロイ方式ChatGPTとの接続適したケース主なコスト
マネージドなパブリックホスティング安定したHTTPSのStreamable HTTPエンドポイントチーム向け・顧客向けアプリの大半プラットフォームの制約とベンダー依存
セルフ管理のパブリックエンドポイントコンテナ、VM、クラスタ上の安定したHTTPSエンドポイントコンプライアンスやネットワーク要件を持つ既存のプラットフォームチームTLS、スケーリング、パッチ適用、ロールバック、監視を自分たちで担う必要がある
Secure MCP TunnelOpenAIのホストするエンドポイントから、プライベートなstdioまたはHTTPサーバーへ中継オンプレミス環境、プライベートネットワーク、開発用途正常なtunnel-clientが可用性の一部になる

基本はマネージドホスティングでよいのは、MCPサーバーがステートレスで、トラフィックが断続的で、チーム内に信頼できるパブリックアプリ基盤の運用経験がない場合です。VercelのルートハンドラーパターンやCloudflareのステートレスなWorkerパターンなら、ChatGPTが必要とする安定したHTTPSエンドポイントを用意できます。ただし、選定前に各プラットフォームのリクエスト時間、ストリーミング、状態管理に関する制約を確認してください（Vercel、Cloudflare）。

パブリックエンドポイントをセルフ管理するのは、既存データベースの近くにサーバーを置く必要がある場合、社内の認証基盤を使う場合、データレジデンシーの要件を満たす必要がある場合、あるいはサーバーレスの実行時間モデルに収まらない処理を動かす場合です。ただし、シークレット管理、デプロイのロールバック、アラート、オンコール担当者をすでに用意できるチームに限って選ぶべきです。

Secure MCP Tunnelを使うのは、パブリックな入口を設けること自体が適切でない場合です。OpenAIのトンネルクライアントはapi.openai.com:443へアウトバウンドのHTTPS接続を張り、プライベートなHTTPまたはstdioサーバーへリクエストを転送します。インターネットから受け付けるインバウンドリスナーは必要ありません。なお、OpenAIのデプロイメントドキュメントでは、Secure MCP Tunnelは、安定して外部から到達できるHTTPSエンドポイントを求める一般公開申請の要件を満たさないと説明されています（OpenAI tunnel documentation、OpenAI build guidance）。

プライベートサーバーへの接続モデルを示すOpenAI Secure MCP Tunnelのドキュメント

ローカルツールを本番運用のChatGPT MCPサーバーへ移行する

信頼できるChatGPT MCPサーバーのデプロイでは、ツールの動作、プロトコル、実環境からの到達性、モデルによるルーティングを別々のゲートで確認します。1つのゲートを通過したからといって、次のゲートも通るとは限りません。

1. ツールの役割を絞り、安定した契約を定義する

まずは、ユーザーが認識できる1つの操作につき1つのツールを用意します。OpenAIのビルドガイドでは、関係のないモードを1つのツールに詰め込むのではなく、list_projects、get_project、update_projectを分けています（OpenAI developer documentation）。各ツールには、操作内容が伝わる名前、具体的な説明、明示的な入力スキーマ、役に立つ出力、正確な安全性アノテーションが必要です。

状態を変更できない場合に限り、readOnlyHint: trueを付けます。取り消せない、または元に戻すのが難しい作用にはdestructiveHint: trueを使い、自由度の高い外部エンティティにアクセスするツールにはopenWorldHint: trueを設定します。OpenAIは、これらのアノテーションをツールの振る舞いや安全性の扱いに使うモデル向けメタデータと説明しています。一方、保護された各リクエストの認可は、サーバー側で必ず実施しなければなりません（OpenAI developer documentation）。

後続の呼び出しで同じレコードを更新する可能性があるなら、安定したレコード識別子をstructuredContentに返します。トークン、シークレット、不要な個人データをcontent、structuredContent、_metaに含めないでください。OpenAIも、_metaはモデルから隠されるものの、安全なストレージではないと明記しています。

2. ローカルでStreamable HTTPを公開する

ChatGPTが通常使うリモート接続はStreamable HTTPで、エンドポイントは一般に/mcpです。このパスは慣例であって必須ではありませんが、ChatGPTにはデプロイ後の完全なURLを入力する必要があります（OpenAI connection guide）。

サーバーをローカルで起動し、MCP Inspectorを立ち上げます。

npx @modelcontextprotocol/inspector@latest

Inspectorからhttp://localhost:3000/mcpのようなURLへ接続します。初期化とツール一覧を確認したら、すべてのツールを、正しいリクエスト、無効なスキーマ、識別子の欠落、結果が空になるケースで呼び出します。保護されたツールについては、認証情報がない場合や権限が不足している場合に確実に拒否されることも確認してください。

3. 外部公開前に本番用のアクセス制御を追加する

ヘルスチェックが外部から見えるからといって、ツール全体を公開してよい理由にはなりません。意図的に公開した読み取り専用データだけを扱うなら、認証なしのエンドポイントでも許容できる場合があります。しかし、プライベートデータ、ユーザー固有のデータ、状態を変更する操作には、すべてのリクエストで認証と認可が必要です（OpenAI build guidance）。

OAuthで保護されたMCPでは、サーバーがリソースサーバーとして動作します。認証されていないリクエストには401を返し、通常は/.well-known/oauth-protected-resourceにある保護対象リソースのメタデータをクライアントへ案内します。認可フローではPKCE、必要最小限のスコープ、発行者とオーディエンスの厳格な検証を使い、永続的な接続で必要になる場合はリフレッシュトークンにも対応します（OpenAI Help Center）。

MCPのアクセストークンを、そのサービスもBearerトークンを受け付けるという理由だけで上流サービスへ渡してはいけません。トークンは受信側のリソース向けに発行されたものでなければなりません。下流への呼び出しには、サービス資格情報または適切なトークン交換の設計を使います（MCP deployment security guide）。

4. 変更不能な候補ビルドをデプロイする

Inspectorを通過したものと同じビルドをプレビューまたはステージングのエンドポイントへデプロイし、そのアーティファクトを本番へ昇格させます。本番エンドポイントではHTTPSを使い、MCPの完全なパスを維持し、依存サービスへ到達できるようにします。シークレットはホスティングプラットフォームのシークレットストアで管理してください。

Vercelを使った簡潔な構成では、mcp-handler、@modelcontextprotocol/server、zodをインストールし、返されたWebハンドラーをapp/api/mcp/route.tsにマウントします。そのうえでGETとPOST向けにエクスポートし、次のコマンドでデプロイします。

npx vercel deploy --prod

この場合、ChatGPTの接続URLはhttps://your-project.vercel.app/api/mcpの形式になります。Vercelは、Fluid compute使用時のデフォルト関数実行時間を300秒とし、対象となる有料構成ではさらに長い上限を用意しています。そのため、1回のリクエストを超える処理は、アイドル状態のストリームを保持するのではなく、再開可能なジョブへ切り出します（Vercel deployment guide）。選択したランタイムに意図的な共有状態の設計がない限り、ルートはステートレスに保ってください。

ChatGPTを接続する前に、次の4つの運用対策を追加します。

  1. 負荷の高いツールにリクエストタイムアウトとレート制限を設定する。
  2. トークンや機密性の高い結果を記録せず、初期化失敗とツール失敗をログに残す。
  3. 各呼び出しにリリース識別子を記録し、インシデントとデプロイ済みコードを紐付けられるようにする。
  4. ツールスキーマや認可の回帰に備え、テスト済みのロールバック手順を維持する。

Inspectorはlocalhostだけでなく、本番URLに対しても実行します。ツールの発見、スキーマ、アノテーション、認証、正常系の呼び出し、エラーをすべて再確認してください。アプリケーションがローカルで動いていても、ロードバランサー、プロキシ、CORS設定、認証プロバイダーのリダイレクトで失敗することがあります。

アクセス制御は3つの層に分けて設計する

ChatGPTのMCPアクセス制御には、独立した3つの強制ポイントがあります。OAuthを有効にするだけでは、アイデンティティ層に対応したにすぎません。

層強制する場所決めるべきこと
ワークスペースアクセスChatGPTの管理者設定誰がアプリを作成、公開、有効化、利用できるのか
ユーザーのアイデンティティOAuth認可サーバーとMCPリソースサーバーどのアカウントからの呼び出しか、トークンはこのサーバー向けに有効か
リソース・操作の認可MCPツールハンドラーとバックエンドこのユーザーが、このテナント、レコード、環境に対して操作を実行できるか

ChatGPT Businessでは、管理者またはオーナーがデベロッパーモードと公開を管理します。EnterpriseとEduのワークスペースでは、開発者アクセス、アプリへのアクセス、アクションに対するRBACも利用できます（OpenAI Help Center）。ただし、これらはChatGPTがアプリを使えるかを制御する仕組みであり、バックエンド上で呼び出し元が顧客Aのレコードを編集できることを証明するものではありません。

MCPハンドラーは、検証済みの認証情報からアイデンティティを取得し、すべての呼び出しでテナントとオブジェクト単位の認可を適用する必要があります。モデルが生成した引数に含まれるユーザーID、組織ID、ロールを、本人確認の根拠として受け入れてはいけません。すべてのツール引数を信頼できない入力として扱ってください。

読み取り用スコープと書き込み用スコープは分離します。たとえばprojects:readは広く許可し、projects:writeは編集者に限定し、破壊的な操作の前にはサーバー側で最新の権限を再確認する、といったポリシーです。ChatGPTが重要な操作の前に確認を求めることはありますが、確認はユーザー体験上の安全策であって、認可制御ではありません。

プロンプトインジェクションもアクセス制御の問題です。ツールの出力や取得したドキュメントに悪意のある指示が含まれる可能性があるため、書き込みツールは可能な限り狭い操作だけを公開し、許可するフィールドをサーバー側で検証します。何でも実行できるexecute_actionのようなツールは、ルーティングの曖昧さと被害範囲の両方を広げます。

ChatGPTでアプリを接続・テスト・公開する

エンドポイントを接続すると、下書きアプリとメタデータのスナップショットが作成されます。公開すると、レビュー済みの設定をワークスペースで利用できるようになります。サーバーコードのデプロイとは別の操作です。

  1. 利用中のChatGPTワークスペースポリシーに従って、デベロッパーモードを有効にする。
  2. アプリ作成フローを開き、必要ならマウントしているルートの/mcpまで含めた完全なHTTPS MCP URLを入力する。
  3. 認証方式を選択し、必要に応じてOAuthを完了する。
  4. Scan Toolsを実行し、検出されたすべての名前、スキーマ、アノテーション、アクションを確認してから下書きを作成する。
  5. ワークスペースに公開する前に、新しいチャットで下書きをテストする。

プライベートサーバーの場合は、接続方式としてTunnelを選び、関連付けられたトンネルを選択するか、tunnel_idを入力します。オペレーターにはOpenAI PlatformのTunnels Read + Use権限が必要です。一方、ChatGPTのデベロッパーモードは別のワークスペース権限です（OpenAI tunnel documentation）。

メタデータの変更には、明確なライフサイクルが必要です。デベロッパーモードの接続では、サーバーをデプロイまたは再起動し、接続を開いてRefreshを選び、変更後のメタデータを確認してから、新しい会話を始めます。OpenAIの現在のBusiness向けガイダンスでは、公開済みアプリのツールやメタデータを変更するには、アプリを再作成して再公開する必要があります。Enterprise/Eduでは、管理者がアクションを更新し、差分を確認し、新しいアクションを有効にできます。新しいアクションはデフォルトで無効です（OpenAI Help Center）。

それでも、サーバー側の方針としては後方互換性のある進化が最も安全です。オプションのフィールドや新しいツールを追加し、既存ツールの意味を黙って変えないようにします。承認済みのスナップショットとクライアントがすべて移行するまで、古いスキーマを利用可能な状態に保ってください。

ChatGPTユーザーが実際に体験する動作をテストする

プロトコルテストで確認できるのは、サーバーが応答できることです。ChatGPTのテストでは、モデルが意図したツールを選び、適切な引数を渡し、境界を守り、関係のない場面ではツールを使わないことまで検証します。

Redditユーザーのu/EmailNo8428は、この2層の問題を次のように説明しています。

「実際には、2つのことを同時にテストしています。ツールのロジックと、特定のクライアントがそのツールをどう呼び出すかです。」（r/mcp）

次のケースを含む、小規模でバージョン管理された評価セットを作成します。

ケース期待する結果
直接的な依頼指定された機能を、正しい引数で選択する
間接的な依頼ユーザーの目的から適切なツールを推測する
フォローアップ先の呼び出しで返された安定した識別子を再利用する
否定的な依頼MCPツールを一切呼び出さない
権限不足データを漏らさず、役に立つ認可エラーを返す
書き込み依頼狭い範囲の書き込みツールを選び、必要な確認を発生させる
曖昧な依頼引数を勝手に作らず、必要な情報を質問する
結果が空トランスポートエラーやスキーマエラーではなく、正しい空状態を返す

選択されたツール、引数、返された結果、エラー、確認動作を記録します。ツール名、説明、スキーマ、アノテーション、認証ルール、結果の形式を変更したら、影響を受けるケースを再実行してください。OpenAIも接続ガイドで、同じ更新・再テストのサイクルを推奨しています。

Inspectorには通るのにChatGPTでのルーティングがうまくいかないサーバーは、ツールの境界、説明、スキーマを見直す必要があることが多いでしょう。正しくルーティングされるのに401が返る、タイムアウトする、状態が失われるという場合は、インフラまたは認可に問題があります。原因を切り分けて考えることで、修正までの時間を短縮できます。

FAQ

ChatGPTはlocalhostやstdioのMCPサーバーへ直接接続できますか？

できません。ChatGPTは通常、リモートMCPエンドポイントへ接続します。OpenAI Secure MCP Tunnelを使えば、パブリックな入口を公開せずに、プライベートなstdioまたはHTTPサーバーへ中継できます。開発中は一時的なHTTPSトンネルも使えますが、一般公開用プラグインの申請には利用できません。

ChatGPT MCPサーバーにはパブリックなHTTPSエンドポイントが必要ですか？

通常のリモート接続と一般公開用プラグインの申請には、安定したHTTPSエンドポイントが必要です。プライベートなデベロッパーモードのサーバーでは、Secure MCP Tunnelを使ってサーバーを顧客の管理環境内に置けます。

searchとfetchは必須ですか？

いいえ。OpenAIによると、接続サーバーでこれらは必須ではなくなりました。社内ナレッジやディープリサーチの検索画面に参加させる必要がある場合は、標準のsearchとfetchの契約を実装します（OpenAI Help Center）。

デプロイ後もChatGPTに古いツールが表示されるのはなぜですか？

ChatGPTは、コードをデプロイするたびに承認済みのツール変更として扱うのではなく、発見したメタデータを保存します。デベロッパーモードの接続では更新してから新しい会話を始めてください。ワークスペースに公開したアプリでは、プランごとに決められたレビューと再公開の手順が必要です。