ChatGPTのプラグインとアプリにおけるMCP — 2026年の変化

ChatGPTの拡張性を最後に見たのが1年前なら、語彙は2度変わり、中身は1度変わって います。「プラグイン」という言葉が戻ってきましたが、その意味は2023年のものでは ありません。OpenAIの開発者ドキュメントは現在、プラグインを3つのものをまとめた パッケージと定義しています。スキル、MCPサーバー、そして任意のUIです。スキルは ツールのまわりに繰り返し使える手順を加え、MCPサーバーはツールと外部システムへの アクセスを提供し、UIは一部のツールがChatGPT内での表示のために返すリソースの 集まりです。

実務上の帰結は見落とされがちです。プラグインはMCPサーバーを包む配布用の器で あって、その代わりになるものでも、使うための前提でもありません。つまり、自分の ファイルやメモ、会議の文字起こしをChatGPTに読ませることが目的なら、プラグインを 作るのはたいてい問題の反対側から手をつけることになります。ディレクトリと プロトコルは別の層であり、あなたの邪魔をしているのは片方だけです。

以下では、2026年8月15日時点のOpenAI自身のドキュメントとAgent Pluginsの仕様に 沿って、その層を切り分けます。

プラグインに実際に入っているもの

OpenAIのプラグインアーキテクチャのページによれば、プラグインはスキル、MCP サーバー、あるいはその両方を含むことができます。どちらも常に必須というわけでは ありません。「指示とモデルがすでに使えるツールだけでタスクを完了できる」場合は スキルだけで足りますし、MCPサーバーが登場するのは、プラグインがサービスへ到達し、 ユーザーを認証し、誰かが運用するインフラ上で処理を動かす必要があるときです。

この2つの役割分担は身につけておく価値があります。プラグインであるかどうかに かかわらず、あらゆるアシスタントの構成に同じ分担が当てはまるからです。

部分 何のためのものか
MCPサーバー 生きたデータ、認証、認可、制御された操作
スキル ツールの手順、判断のポイント、出力の要件、例、テンプレート
UI 一部のツールが返し、ChatGPT内で表示されるリソース

これはChatGPT固有の考え方ではありません。 ツールの説明だけでは足りない理由と 同じ話です。サーバーはモデルに何ができるかを伝え、スキルはこのチームでは どう進めてほしいかを伝えます。両者を一緒に梱包するというのは、単に2つが1つの 単位として運ばれるということです。

ディレクトリは層の1つであって、唯一の層ではない

ChatGPTとCodexは1つのプラグインディレクトリを共有しており、公開された掲載は 双方から見つかります。そこに入るのは、公開のための要件を伴う公開プロセスです。 OpenAIのビルドガイドはホスティングについて明快です。公開プラグインとして申請 するなら、MCPサーバーは安定して公開到達可能なHTTPSエンドポイントにデプロイし、 MCPのstreamable HTTPトランスポートに対応し、通常は/mcpで終わるURLで応答します。 エンドポイントはプラグインの審査とドメイン確認の間、到達可能なままである必要が あり、ドキュメントは公開申請に一時的なトンネルやローカルのエンドポイントを使う ことを明示的に排除しています。

これはMCPについてではなく掲載についての記述として読むべきです。公開HTTPS、 安定したURL、審査、ドメイン確認、そのすべては見知らぬ人がそれをインストールする から存在します。アシスタントがツールサーバーを使うために必要なものは1つも ありません。これはアプリストアの税であり、他人に配るときに払うものです。

ではなぜ形式はローカルサーバーを許しているのか

形式はディレクトリではないからです。2026年8月6日、梱包そのものがオープンな標準に なりました。Agent Plugins 1.0.0で、技術運営委員会にはAmazon、Cursor、Microsoft、 OpenAI、Vercelの中心的なメンテナーが加わり、ChatGPTとCodex、Cursor、GitHub Copilot、Kiro、VS Codeが立ち上げ時点で対応しています。掲げられた目標は小さな 相互運用の土台です。作者はクライアントごとに部品を並べ替えるのではなく、一度 梱包すれば済みます。

構造は意図的に退屈です。プラグインはルートにplugin.json(必須は$schemanameだけ)を置いたディレクトリで、Agent Skillsはskills/の下にそれぞれ SKILL.mdを持つサブディレクトリとして並び、MCPサーバーの設定はmcp.jsonに あります。そしてmcp.jsonは3つのトランスポートを記述します。コマンドで起動 されるローカルのサブプロセスのためのstdio、リモートのエンドポイントのための streamable-http、そして2024-11-05の旧トランスポートのためのsseです。適合の 規則は明示的で、Agent PluginsのMCPサーバーに対応するクライアントはstdiostreamable-httpの少なくとも一方に対応しなければならず、両方に対応することが 望ましいとされています。

つまり、MCPサーバーが完全に自分のノートパソコンで動くプラグインも、正当な プラグインです。ただOpenAIの公開ディレクトリでは掲載できないというだけで、 それは「許されていない」とは別の主張です。たとえばVS Codeはマーケットプレイス から、あるいはGitリポジトリのURLから直接Agent Pluginsをインストールでき、 プラグインのMCPサーバーはワークスペース単位やユーザー単位のサーバーと並んで 現れます。Cursorは自社形式と並べてこの標準に対応し、どちらもCustomizeページ から管理します。

ChatGPTに自分のデータを見せたいだけなら

プラグインは飛ばして、サーバーをつなぎます。

このサーフェスの違いは見た目の問題ではありません。ローカルのstdioサーバーは、 クライアントが起動し標準入力と標準出力でやり取りするプログラムです。ポートは 開かず、トークンも発行されず、アシスタントへ届くまでの途中で第三者に何かが渡る こともありません。ホスト型のエンドポイントは運用者と資格情報とネットワーク経路を 意味します。本当にクラウドにあるサービスなら妥当な取引ですが、自分のメモに対して は奇妙な取引です。

承認は依然としてクライアントのもの

梱包の変更が変えなかったものが1つあります。アシスタントが行動してよいかを決める のはプラグインではなくクライアントだという点です。Codexには4つの承認モード、 autopromptwritesapproveがあり、writesはread-onlyと記されていない ツールについて確認します。設定はdefault_tools_approval_modeで全体に、あるいは ツール単位で行えます。対照的にVS Codeは、プラグインをインストールした時点でその MCPサーバーを暗黙に信頼されたものとして扱い、ワークスペースのサーバーと違って 起動時に別途の信頼確認を出しません。見慣れないマーケットプレイスからプラグインを 入れる前に知っておく価値があります。

「読み取り専用」がディレクトリの強制する約束ではなく、サーバーが宣言する性質で あるのもこのためです。Speak-Yのサーバーは、データを変更するコマンド、つまり 録音へのタグ付け、話者名の変更、チームチャンネルへの共有を、変更するものとして 公開します。だからクライアントは実行前に確認します。読み取りはローカルで完結し、 ほかに動かしておくものはありません。サーバーのargsに--read-onlyを加えれば クライアントを読み取りだけに固定でき、そのあとは変更系のコマンドがそもそも 提示されません。

結局どうなるか

他人のために統合を作っているなら、いまはプラグインが正しい形です。1つの パッケージ、1つのマニフェスト、複数のクライアント、そしてChatGPTとCodexに同時に 届くディレクトリ。自分のアシスタントに自分のコンテキストを渡そうとしているなら、 その仕掛けはどれも当てはまらず、そこへ手を伸ばすのは、設定ファイルの1行がすでに 解いている問題のために、ホスティングの請求書と審査の待ち行列を買うことになります。

Speak-Yは意図的に後者の道を取っています。そのMCPサーバーはローカルのプロセスで、 Freeを含むすべてのプランで無料、設定 → 連携からワンクリックで導入できます。 アシスタントが何を読み、何を変えられるのかはMCPの概要にあります。どの アシスタントを向けるかまだ決めていない場合は、 クライアント比較が ローカルサーバーを起動できる側とできない側を扱っています。

FAQ

2026年のChatGPTプラグインとは何ですか

プロトコルではなくパッケージです。OpenAIの開発者ドキュメントは、スキル、MCPサーバー、任意のUIとして定義しています。スキルは繰り返し使える手順を加え、MCPサーバーはツールと外部システムへのアクセスを提供し、UIは選ばれたツールが返すリソースの集まりです。MCPサーバーは必須ではなく、指示とリソースだけでできたプラグインはスキルだけで構成することもできます。

自分のデータをChatGPTにつなぐには、プラグインを作る必要がありますか

いいえ。プラグインを公開するのは、ChatGPTとCodexが共有するディレクトリを通じて統合を他の人へ配るための方法です。自分のマシン上のデータにアシスタントからアクセスさせたいなら、クライアントをMCPサーバーへ直接向けます。CodexとChatGPTデスクトップアプリはconfig.tomlでローカルのstdioサーバーを受け付け、CursorとVS Codeはmcp.jsonで受け付けます。掲載も審査もホスティングも要りません。

プラグインのMCPサーバーを自分のコンピューターで動かせますか

形式としては可能です。Agent Plugins 1.0.0の仕様はmcp.jsonにstdio、streamable-http、sseの各トランスポートを定義しており、準拠するクライアントは少なくともstdioかstreamable-httpのどちらかに対応しなければなりません。OpenAIの公開ディレクトリでは不可です。公開プラグインとして申請する場合、サーバーは安定して公開到達可能なHTTPSエンドポイントに置く必要があり、ドキュメントはローカルのエンドポイントや一時的なトンネルを明示的に除外しています。2026年8月15日時点の情報です。

Agent Pluginsとは何で、MCPとどう違いますか

MCPは、アシスタントがツールサーバーと話すためのプロトコルです。2026年8月6日に公開されたAgent Pluginsは、プラグインの各部分がどこに置かれるかを定める梱包の形式です。ルートにplugin.json、スキルはskills/、MCPサーバーの設定はmcp.jsonです。技術運営委員会にはAmazon、Cursor、Microsoft、OpenAI、Vercelのメンテナーが参加しており、立ち上げ時点の対応クライアントはChatGPTとCodex、Cursor、GitHub Copilot、Kiro、VS Codeです。

Speak-YのMCPサーバーはChatGPTのプラグインですか

いいえ、その必要もありません。Speak-Yが提供するのはローカルのMCPサーバーで、あなたのクライアントがあなたのマシン上で起動します。そのため録音や文字起こしは、誰かが運用するエンドポイントへ送られるのではなく、ディスク上のライブラリから読まれます。設定 → 連携からワンクリックで導入でき、Freeを含むすべてのプランで無料です。