ChatGPT MCP Server Hosting、デプロイをSitesへ移行するも、境界を決めるのは依然アクセス権
ChatGPTは現在、別途ホスティングプロバイダーを必要とせず、Sitesを通じてツールの構築、ホスティング、デプロイを行えるChatGPT MCP serverワークフローをサポートしている。この変化は、AIクライアントが共通インターフェースを介して外部ツールを呼び出せるようにするModel Context Protocol（MCP）をめぐる、実務上の大きな障壁の一つを取り除くものだ。
Tibo Thibaultによる公開投稿は、2026年10月1日にこの機能を取り上げた。OpenAIの最新ドキュメントも、基盤となるワークフローを確認している。ユーザーはChatGPTまたはCodexに対し、SiteへのMCP server追加、公開、生成されたプラグインのインストールを依頼できる。
このため、この発表は単なるウェブサイトビルダーのアップデート以上の意味を持つ。これまで一般的なChatGPT MCP serverには、コード、インターネットからアクセス可能なエンドポイント、デプロイ基盤、そして別途の接続プロセスが必要だった。Sitesはこれらのステップのいくつかを、一つの対話的環境へ取り込む。
したがって重要な競争は、ChatGPTと別のモデルとの対決ではない。管理されたプロンプト主導のデプロイと、従来のセルフホスト型MCPルートの競争である。OpenAIはアイデアからインストール済みツールに至る道のりを短縮したが、そのツールが有用かどうかは依然として権限、テスト、配布によって決まる。
ChatGPT MCP Server Hostingで何が変わったのか
ChatGPT Sitesは現在、アプリケーションの表層であると同時に、プラグインを介して利用するMCPツールのホストとしても機能する。
ChatGPT Sitesは、インタラクティブなウェブサイトと軽量アプリケーションを構築・公開するためのOpenAIの環境だ。ユーザーは望むものを説明し、生成されたプレビューを確認し、修正を依頼して、結果をSite URLへデプロイする。
新たな要素は、そのSiteにサーバーサイドツールを追加できることだ。OpenAIのSites guideによれば、ユーザーはChatGPTまたはCodexに、新規または既存のSiteへMCP serverを追加するよう依頼できる。ツールが読み取れる情報と、実行可能な変更を説明する必要がある。
MCPは、互換性のあるAIクライアントにツールとデータを公開するためのプロトコルだ。サーバーは利用可能な操作、その入力、出力を記述する。ユーザーが関連する要求を行った際、ChatGPTはそれらの操作を呼び出せる。
たとえばSiteの所有者はプロジェクトダッシュボードを作成し、マイルストーンの読み取りやステータス更新のためのツールを追加できる。Siteを公開すると、サポート対象のChatGPTおよびCodexの会話内でそれらのツールを公開する関連プラグインが作成される。
この一連の流れは、これまで別々だった複数の作業を圧縮する。
ユーザーが会話の中で望むワークフローを定義する。
ChatGPTまたはCodexがSiteとそのMCPツールを構築する。
所有者がSiteを確認し、その挙動をテストする。
公開により、ライブSiteと関連プラグインが生成される。
ユーザーがそのプラグインをインストールし、接続する。
ChatGPTは後続の会話でそのツールを呼び出せる。
Siteは静的なインターフェースにとどまらない。情報を保持し、インタラクティブなビューを表示し、MCP経由で公開される操作を提供できる。OpenAIの例では、内容の検索とアクセスのためのツールを備えたチームハンドブックが説明されている。
このパターンは、プロジェクトトラッカー、社内ディレクトリ、ローンチカレンダー、文書検索ツール、運用ダッシュボードにも適している。チームは、データと権限を慎重に設計することを前提に、このアプローチを検索可能なナレッジベースと組み合わせることもできる。
関連プラグインが表示される前に、所有者はSiteを公開しなければならない。ツールの追加または変更にも、それらの変更を利用可能にする前に再度の公開が必要となる。保存済みの下書きがライブプラグインを密かに変更することはない。
OpenAIはSitesをパブリックベータとして説明している。ChatGPTワークスペース、Plusアカウント、Proアカウントで利用できるが、ロールアウトがすべてのアカウントに同時に届くとは限らない。ワークスペース管理者は、作成および公開の権限を管理できる。
デプロイURLは本番URLだ。OpenAIは作成者に対し、デプロイ前にバージョンを保存し、変更を確認するよう助言している。対話的な編集は非公式に感じられる場合があるため、この区別は重要だ。最終的なソフトウェアには実際のユーザーが存在する可能性がある。
結果として、デプロイまでの経路は大幅に短くなる。ソフトウェア運用を不要にするわけではないが、その多くを管理された製品と対話的ワークフローへ移す。
プロンプト主導デプロイがセルフホスト型ルートに与える圧力
Sitesは、多くの小規模なワークフローにおいて、MCPデプロイをインフラプロジェクトから製品設定タスクへと変える。
従来のリモートMCPデプロイには、ChatGPTがパブリックインターネット経由で到達できる、稼働中のサーバーが依然として必要だ。開発者はツールを実装し、HTTPSエンドポイントを公開し、認証を構成し、サービスの可用性を維持しなければならない。
OpenAIのMCP quickstartは、そのルートを示している。開発者はMCP software development kitをインストールし、serverを作成し、/mcpエンドポイントを公開して、ChatGPTの開発者向けコントロールからパブリックURLを接続する。
チームがカスタムインフラ、複雑な統合、独立したスケーリング、あるいはランタイムの制御を必要とする場合、この方法は引き続き適切だ。また開発者は、デプロイスケジュール、ログ、ネットワーキング、データストレージを直接管理できる。
しかし、多くの社内ツールはそうした要件から始まるわけではない。ハンドブックの検索、マイルストーンの更新、プロジェクトレコードの取得といった限定的な要望から始まる。インフラ作業が、最初のバージョンの機能範囲を上回ることもある。
ChatGPT Sitesはこの隔たりを対象とする。ユーザーはSite、そのデータ、ChatGPTに実行させる操作を説明できる。Codexは必要なツール層を生成し、インストール可能なプラグインへ接続できる。
これはエンジニアリング知識を不要にするものではない。必要になる場面を変えるものだ。
最初のバージョンは、手作業で組み上げたデプロイスタックではなく、ガイド付きの構築によって生み出せる。エンジニアリング上の注意は、ツールの境界、認可、エラー処理、データ品質へ移せる。
これが中心的な逆転だ。MCPは接続を標準化するよう設計されたが、serverの運用は、焦点を絞ったワークフローだけを求める人々にとって依然として摩擦を生んでいた。OpenAIは現在、その運用負荷を減らすために管理されたホストを用いている。
圧力がまず及ぶのは、軽量なホスティングパターンと社内プロトタイプだ。3つのツールから成るワークフローが実際の問題を解決するかを試すだけなら、開発者は別のクラウドプロジェクトを必要としなくなるかもしれない。
この圧力は、ノーコードおよびローコードのAIビルダーにも及ぶ。ChatGPTは、対話的な仕様策定、アプリケーション生成、ホスティング、プラグインのインストールを、一つのアカウント環境内で接続する。これにより、プロトタイプと利用可能なChatGPTツールとの距離は縮まる。
それでも、セルフホスティングには重要な利点が残る。管理されたSiteが、すべての本番システムで必要とされるデプロイの柔軟性、可観測性、ポータビリティ、または容量を自動的に提供するわけではない。
OpenAIはパブリックベータ期間中、プランごとの利用制限も適用している。この制限はアカウント内のSites全体を対象とし、Siteの作成、ストレージ追加、アクセスの多いSiteの公開維持に影響する可能性がある。
ドキュメントでは、ユーザーにアカウント内で表示される制限を確認するよう求めている。すべてに普遍的に適用される固定容量は示していない。
この不確実性により、Sitesが従来のMCPホスティングを置き換えるという単純な結論は導けない。代わりに、小規模または初期段階のデプロイに向けた管理型の標準選択肢を生み出している。
開発者は、この二つのルートを異なる運用上のコミットメントとして捉えるべきだ。
Site-hosted toolsは、速度、統合されたデプロイ、ガイド付きワークフローを優先する。
Self-hosted toolsは、インフラ制御、カスタムアーキテクチャ、独立した運用を優先する。
Site-hosted pluginsは、OpenAIのアカウントおよびワークスペースのコントロールを継承する。
Self-hosted serversも、ChatGPTの接続、認可、レビュー要件を引き続き継承する。
多くのチームにとって、選択はコード生成よりもガバナンスに左右されるだろう。MCPツールの構築は容易になりつつある。誰がそれを呼び出せるかを決めることは、依然としてより難しい製品上の判断だ。
Siteがインストール可能なプラグインになる仕組み
ワークフローは公開済みSiteをプラグインに結び付けるが、インストールと認可は別個のステップとして残る。
OpenAIのhosting guideは、具体的な手順を説明している。作成者は所有するSiteから始め、ChatGPTまたはCodexにMCPツールの追加を依頼し、それらを確認してSiteを公開する。
MCPのセットアップが完了すると、ChatGPTはそのSiteに関連付けられたプラグインカードを提示する。作成者はカードを確認し、Installを選択して、接続フローを完了できる。
インストール済みプラグインは、サポート対象のChatGPTまたはCodexの会話で言及できる。そのプラグインがユーザーの要求に適合する場合、ChatGPTがインストール済みプラグインを選択することもある。
このパッケージ化のステップは重要だ。生のMCPエンドポイントと、配布可能なChatGPT体験は同一ではない。プラグインは、ユーザーがインストール、検索、選択、管理できる認識可能な単位を提供する。
プラグインには、スキル、接続済みアプリケーション、MCPを基盤とするツール、インタラクティブな拡張機能を含められる。Site-hosted MCP applicationは、このより広範なパッケージ化システム内の一つのコンポーネントになる。
現在のプラグインディレクトリは、ChatGPT web、desktop、mobileに表示される。ただしOpenAIは、個々の機能が利用する環境、アカウント、地域、プラン、ロール、ワークスペース構成によって異なる可能性を警告している。
この留保は重要だ。プラグインがディレクトリに表示されても、含まれるすべてのツールやビューがあらゆる場所で同じように動作することを保証するものではない。
ローカルMCP applicationsはその違いを示している。OpenAIによれば、ローカルapplicationはChatGPT Desktop上のプラグインを通じて動作できる。そのプラグインをアカウントに保存しても、ローカルツールがwebやmobileで利用可能になるわけではない。
Site hostingは、リモートランタイムを提供することで、この制約に対処する。それでも、プラグインの正確な環境サポートは、含まれる機能と現在の製品提供状況に依存する。
関連するSiteにも独自のアクセスモデルがある。受信者には、Siteを表示する権限、プラグインを使用する権限、接続先サービスに対する認可が必要になる場合がある。
プラグインをインストールしても、これらの層を迂回することはない。Siteだけを共有してもプラグインは共有されず、プラグインを共有しても無関係なデータへのアクセス権は与えられない。
この分離は、見落としやすいが危険な想定を防ぐ。ツールがインストール可能であることは、それを作成した人が読み取れるすべての情報を読み取れることを意味しない。
各ユーザーは、対象となるアカウントを接続する必要がある場合がある。Siteが接続済みアプリケーションへアクセスする際、訪問者は自身の接続と既存の権限を使用する。
課題トラッカーに接続されたプロジェクトダッシュボードを考えてみよう。Siteは割り当て済みの課題を表示し、更新アクションを公開できる。受信者に表示されるべきなのは、その人の課題トラッカーアカウントで許可されたレコードだけだ。
同じ原則は、文書リポジトリ、顧客レコード、社内ハンドブックにも適用される。Siteはインターフェースとホストされたツールを提供するが、基盤となるサービスは依然として認可の境界である。
このモデルは、個人用およびワークスペース用ツールへのより実用的な経路を生み出す。同時に、アクセスに失敗した際には多層的なトラブルシューティングの問題も持ち込む。
ツール呼び出しの失敗は、Site、プラグイン接続、ワークスペースのロール、基盤となるアプリケーション、あるいはユーザーのプロバイダーアカウントに起因する可能性があります。作成者は各レイヤーを個別にテストする必要があります。
したがって、インストール体験は実際の製品進化を示すものですが、普遍的な可搬性を保証するものではありません。OpenAIは、異なるセキュリティドメインを維持しながら、構築とパッケージ化のフローを統合しました。
権限こそが製品の境界線
新しいワークフローの最大の強みは、同時に最大のリスクでもあります。会話を通じて生成されたツールが、実際の操作を実行できるためです。
作成者は、各ツールが情報を読み取るだけなのか、それとも変更も可能なのかを判断しなければなりません。検索操作と更新操作は並んで表示されるかもしれませんが、運用上の影響は異なります。
OpenAIは、アクセスを共有する前にSiteの内容とツールの挙動を確認するよう作成者に指示しています。特に、ユーザーがデータを読むだけにすべきか、書き込み操作も可能にすべきかを検討するよう求めています。
書き込みアクセスには、マイルストーンの変更、レコードの作成、情報の送信、保存済みコンテンツの更新などが含まれます。これらの操作には、生成されたインターフェースから受ける印象以上の慎重な検討が必要です。
洗練されたSiteのプレビューは、アクセスルールが正しいことを証明するものではありません。また、すべての入力が意図したサーバー操作につながることも保証しません。
作成者は、代表的なレコード、権限レベル、欠損データ、不正な入力、拒否される操作をテストすべきです。ツールが変更を実行した後にSiteを開き、結果を検証する必要もあります。
Enterprise向けの管理機能は、さらに別のレイヤーを加えます。OpenAIによると、プラグインの使用、アップロード、MCPを利用した作成、共有、ワークスペースディレクトリへの公開など、複数のプラグイン権限を独立して管理できます。
一部の権限はEnterprise環境ではデフォルトで無効になっています。作成者がSiteを公開したり、そのプラグインを共有したりするには、管理者が該当ロールを有効化する必要がある場合があります。
この設計は意図しない配布を抑えますが、アカウントごとに機能の一貫性がないように見える原因にもなり得ます。あるユーザーはすぐにツールを構築してインストールできる一方、別のユーザーには必要なコントロールが表示されないかもしれません。
公開アクセスには、さらに慎重な扱いが必要です。当初のソーシャル投稿では、作成者がツールを選ばれた人に限定したり、世界中と共有したりできると示唆されていました。公式ドキュメントは、制御されたワークスペース共有と、別途設けられた公開申請ルートを支持しています。
ただし、個人用プラグインの共有が普遍的に開放されているとは説明していません。現在、Proおよび個人アカウントのユーザーは、共有リンクを通じて他のChatGPTユーザーをSiteホスト型プラグインに直接招待することはできません。
BusinessおよびEnterpriseのメンバーは、ワークスペースの権限に従って同僚と共有できます。受信者はプラグインとそのSiteの両方にアクセスできる必要があり、その後、自身でインストールと接続を行わなければなりません。
公開ディレクトリでの配布は別のプロセスに従います。開発者はプラグインを審査に提出し、本人確認と権限に関する要件を満たした上で、承認後にのみ公開します。
OpenAIの審査要件では、リモート申請に対して実在し、一般公開されているMCPエンドポイントが求められます。審査では、ツールスキーマ、セキュリティ方式、アノテーション、ユーザーデータの取り扱い、想定される挙動が確認される場合があります。
審査ガイダンスは、読み取り専用、破壊的操作、オープンワールド操作も区別しています。こうした分類は、審査者がツールの挙動とリスクを理解する方法に影響します。
ツールは、説明文で無害と呼ばれているだけで読み取り専用にはなりません。宣言されたアノテーションと実際の挙動が一致している必要があります。
この基準は、手作業でコード化されたサーバーと同様に、Site生成ツールにも重要です。自然言語による作成は実装工数を減らせますが、正確なセキュリティモデルの代わりにはなりません。
最大の未解決課題は、一般的な作成者が安全でないツール境界をどれほど確実に認識できるかです。開発者は、一見小さな更新機能であっても、下流システムを起動したり、機密フィールドを公開したりし得ることを知っています。
技術的な知識が少ないユーザーは、ワークフローが動作するかどうかに注目しがちです。過剰なレスポンスフィールド、間接的な副作用、一貫しない認可ルールを確認しない可能性があります。
OpenAIの管理されたワークフローはガードレールを提供できますが、ドキュメントは依然としてテスト責任を作成者に委ねています。所有者に対し、共有前にツールを確認し、サンプルデータをテストし、結果をチェックするよう求めています。
つまり、ガバナンスが実際の導入制約になります。有用なツールには、明確な機能と、正当化可能な権限境界の両方が必要です。
ChatGPT MCP Serverのユースケースは小さく始める
初期段階で最適なのは、データの範囲が明確で、操作を元に戻せ、ユーザーが結果を確認できる、限定的なワークフローです。
チームハンドブックは、OpenAIが示す最も明確な例です。Siteでハンドブックを提示しながら、MCPツールによってChatGPTが会話中にその内容を検索し、関連セクションを取得できるようにします。
このユースケースには、定義されたコーパスと比較的シンプルな出力があります。作成者はChatGPTの回答を元のSiteと比較し、欠落や誤った情報を特定できます。
プロジェクトダッシュボードは2つ目のパターンです。読み取りツールは、マイルストーン、担当者、障害要因、期限を取得できます。制御された書き込みツールは、ユーザーの確認後にマイルストーンのステータスを更新できます。
このワークフローでは、目に見える検証が可能です。ユーザーはダッシュボードを再度開き、要求したレコードが正しく変更されたことを確認できます。
ドキュメント検索ツールも、実用的な出発点になります。Siteは、承認済みフォルダを検索し、一致するタイトルを返し、現在のユーザーがアクセスできるレコードを開くツールを提供できます。
こうしたツールは、優れた情報整理と組み合わせることで価値を高めます。個人またはチームのナレッジワークフローは、依然として正確なソース資料、安定した権限、明確な検索境界に依存しています。
社内ディレクトリ、ローンチカレンダー、ステータスレポートもこのモデルに適しています。いずれも、範囲が限定された入力と理解しやすい出力を持つ小規模なツールセットを利用できます。
リスクの高いワークフローには、より慎重な対応が必要です。メッセージを送信する、レコードを削除する、コンテンツを公開する、権限を変更する、外部ジョブを開始するツールは、Siteの外部で影響を生じさせる可能性があります。
そのような操作では明確なパラメーターを提示し、適切な確認を求めるべきです。初期プロトタイプでは、広範なデータアクセスと広範な書き込み権限を組み合わせることを避けるべきです。
また、Siteはユーザーが結果を検証できるだけの状態を表示すべきです。会話上の確認だけでは、外部操作が正しく完了したことの十分な証拠にはなりません。
ここに、ChatGPT MCP serverのホスティングが従来のウェブサイトジェネレーターと異なる点があります。出力は単なるコンテンツやインターフェースコードではありません。将来の会話の中で、運用上の参加者になり得ます。
これにより、複合的な効果が生まれます。一度インストールされると、そのプラグインはChatGPTが関連性があると判断した際、またはユーザーが直接言及した際に選択できるようになります。
そのため、メタデータが重要です。ツール名と説明は、意図する範囲を明確にする必要があります。曖昧な説明は誤ったツールの選択につながったり、不適切な要求を促したりする可能性があります。
管理環境は反復作業も変えます。作成者はChatGPTまたはCodexに、新しいツールの追加、既存操作の改訂、Siteのインターフェース変更を依頼できます。
これらの変更は自動的には公開されません。所有者はSiteを再度公開し、その後プラグインが想定したツールバージョンを公開していることを確認しなければなりません。
この公開要件は有用なチェックポイントになります。チームは、変更された機能がユーザーに届く前にレビューできます。
ただし、バージョンに関する混乱を生む可能性もあります。Siteのドラフト、公開済みSite、インストール済みプラグインが、常に同じ想定挙動を反映しているとは限りません。
チームは、シンプルなリリースノート、名前付きテストケース、各ツールの所有者を維持すべきです。小規模な社内プラグインであっても、ユーザーが現在どのバージョンを呼び出しているかを把握するメリットがあります。
したがって、最初に取り組むべきプロジェクトは、想像し得る中で最も包括的なアシスタントではありません。所有者が次の4つの質問に明確に答えられる、焦点を絞ったワークフローです。
ツールはどの情報を読み取れるのか？
ツールは何を変更できるのか？
誰がこれを呼び出せるのか？
ユーザーは結果をどのように検証できるのか？
これらの答えが曖昧なままであれば、迅速なデプロイは不確実性をより早く本番環境へ持ち込むだけです。
SitesがMCP導入を変えるかどうかを示す3つのシグナル
次の試金石は、生成されるSiteの数ではなく、ホストされたツールのうちどれだけが信頼され、再現可能なワークフローになるかです。
最初のシグナルは、サーフェス間の信頼性です。OpenAIによれば、プラグインディレクトリはウェブ、デスクトップ、モバイルで利用できますが、個々の機能はこれらのサーフェス間で異なる場合があります。
Siteホスト型ツールが、サポートされる各クライアントで一貫して動作するかを注視すべきです。一貫したインストール、認可、ツール選択、出力が実現すれば、Sitesが汎用的なMCPデプロイメントレイヤーであるという主張を強めます。
サーフェス間の差異が残れば、その主張は弱まります。作成者は依然として、デスクトップ、ウェブ、モバイルのユーザー向けに異なる期待値を設計する必要があります。
2つ目のシグナルは、ワークスペースでの導入です。BusinessおよびEnterprise環境では制御された共有が可能ですが、必要な権限は管理者が統制します。
組織が、広範な従業員グループに対してSite作成、MCPプラグイン作成、ワークスペース共有を有効化するかを注視すべきです。開発チームを超えた導入は、会話型デプロイメントが真の運用ニーズに応えていることを示します。
制限的なデフォルトポリシーは逆の結果をもたらします。セキュリティチームが生成された操作と接続データを自信を持って監査できなければ、Sitesはプロトタイプ用ツールにとどまるかもしれません。
3つ目のシグナルは、公開プラグインの品質です。非公開配布と公開は異なる経路であり、ディレクトリへの提出には正式な審査が含まれます。
個人的な実験から、承認済みの公開製品へと成長するSiteベースのプラグインに注目すべきです。その信頼性、プライバシー開示、サポート慣行、ユーザー満足度は、実際の需要の下で管理モデルを検証することになります。
承認済みツールが安定して生まれれば、Sitesは社内デモ以上を支えられるというOpenAIの主張を強めます。繰り返される権限の失敗や不明確なツール挙動は、プロンプト主導のデプロイメントの限界を露呈させるでしょう。
残る不確実性は、したがって概念的なものではなく実務的なものです。OpenAIは、構築、ホスト、公開、インストール、共有のワークフローを文書化しています。仕組みは現実のものです。
まだ確立されていないのは、多数の作成者にまたがり、持続的なトラフィック、複雑な認可、運用上のデバッグ、長期保守をどれほど適切に扱えるかです。
開発者にとって、当面の行動は、1つの範囲が限定されたワークフローを従来のセルフホスト型ルートと比較してテストすることです。セットアップ時間、権限の明確さ、エラー診断、更新管理、クライアント対応範囲を比較してください。
エンタープライズの購入者にとって、優先事項はガバナンスです。誰がツールを作成できるのか、誰が書き込み操作を承認するのか、接続アカウントがどのように動作するのか、変更後にユーザーがどのような証拠を受け取るのかを確認してください。
ナレッジワーカーにとって、機会は直接的です。有用な社内ダッシュボードや参照コレクションは、もはや単独のインフラプロジェクトとして始めることなく、会話型ツールになり得ます。
ChatGPT MCP serverの変化が重要なのは、デプロイメントがリクエストそのものに近づいているためです。決定的な問いは、チームがアクセス、テスト、所有権も同じ程度に近く保てるかどうかです。まず1つの限定的なワークフローを選び、構築前にその境界を定義し、異なる権限を持つユーザーとテストしてください。その証拠が、Sitesが単に高速なホスティングなのか、それともAIツールを作るための持続的な新しい経路なのかを明らかにします。
