MCPとプラグインは何が違う？

MCPとプラグインは、同じ「外部サービスとの連携」に見えても、比べている層が違います。MCPはAIアプリと外部の機能・dataを接続するprotocolです。一方、プラグインは特定のproductが決める拡張機能や利用体験を指すことが多く、共通の技術仕様を意味しません。プラグインがMCPを内部で使うことも、使わないこともあります。

先に短く答える

特定のAI product内で、提供者が用意した連携をすぐ使いたいなら、そのproductの公式plugin / connectorが適しています。複数の対応AI Hostから同じ外部機能を使いたい、または自分で接続serverを実装したいなら、MCPを候補にします。

これは機能の優劣ではありません。Pluginは「利用者が製品上で導入・操作する単位」、MCPは「接続するsoftware間で合意するprotocol」という整理です。実際の仕様はplatform、plugin、Host、MCP Serverごとに確認します。

表は横にスクロールできます

見る点	Plugin / connector	MCP
何を指すか	特定productの拡張・integration体験	AI HostとServer間のprotocol
提供・管理	productやplugin提供者のルールに従う	HostとServerの実装・設定に分かれる
利用者の導入	catalog、workspace設定、管理者承認等	HostへServerを登録し接続・認証
他環境への再利用	同じproductや互換環境に依存	対応する複数Hostで利用できる可能性
確認すること	対応plan、scope、data利用、管理方法	Server実行元、公開機能、transport、auth、権限

同じ「plugin」という呼び名が、どのproductでも同じ技術形式を表すわけではありません。あるproductではstoreから追加する拡張、別のproductでは組織が有効化するconnector、また別の場所では開発者向けpackageを指すことがあります。

連携を3つの層で見る

外部の顧客管理serviceをAIから使う例で考えます。

1. 外部serviceの接点： 顧客データを検索・更新するAPIやdatabaseがある。

2. 接続方式： AI Hostから直接APIを呼ぶ、MCP Server経由で使う、product内の独自connectorを使う等を選ぶ。

3. 利用者向けの導入・操作： workspace管理画面、plugin catalog、設定画面から有効化し、どの利用者に許可するか決める。

Pluginは3層目のproduct体験を指すことがあり、MCPは2層目のprotocolとして使われます。Pluginの画面からMCP Serverが呼び出される場合でも、利用者が見る商品機能はplugin、接続部分の仕組みはMCPです。逆に、MCPを直接Hostへ設定しても、それが各productのcatalog上のpluginとして配布されるとは限りません。

構成イメージ：

利用者の操作・製品内連携（plugin / connector）

↓

AI Host ─ MCP Client ─ MCP Server ─ 外部API / data

図は一つの例です。特定platformの内部実装を示すものではありません。実際の接続構造は提供者の説明と設定で確認してください。

どういうときに公式pluginが向くか

社内で使うAI productが一つに決まり、公式integrationが必要なserviceへ接続できるなら、まずその方法の導入負担を調べます。利用者が管理画面から接続しやすい、workspace administratorが配布を管理できる、product内で利用状況を確認できるなど、運用がまとまっている場合があります。ただし、それらが必ず備わるわけではなく、planや契約、地域、管理者設定に依存します。

導入前に、対象plan、利用できる操作、閲覧・書込scope、接続credentialの所有者、dataがどこで処理・保存されるか、組織の監査方法を確認します。名称が公式でも、業務の権限ルールに合うとは限りません。特に顧客情報や社内文書へ接続する場合は、最小権限でテストし、外部送信や更新の承認条件を明確にします。

MCPを選ぶ意味がある場面

複数のAI Hostから同じ機能を利用したい、独自の社内toolを共通形式で公開したい、AIアプリとbackendの間のinterfaceを切り分けたいときは、MCP Serverを検討できます。ServerはTools、Resources、Prompts等を提供し、Host側は対応する機能を利用します。MCPの存在だけでどのHostでも同じ動作になるわけではなく、対応するprotocol version、transport、capability、認証方式を照合します。

再利用できることには運用負担も伴います。Server更新、権限設計、認証credential、監査、障害対応、互換性の確認を誰が担当するのか決めます。一つのproductだけで一つの固定操作をする場合は、共通Serverを作る費用に見合わないこともあります。

使い分けを決める質問

表は横にスクロールできます

質問	Plugin / connector側を確認	MCP側を確認
どのAI productを使うか	そのproductが公式に対応するか	Hostが対象protocol / transportに対応するか
誰が接続を管理するか	userかworkspace adminか	Server ownerとHost administratorの責任
何を外へ出せるか	pluginのscope、data処理、permission	Serverが公開するTool / Resourceの範囲
他のHostでも使うか	対応するproductを限定できるか	各Hostの互換性と認証差
誰が更新・停止するか	catalogやadmin設定で無効化できるか	Server、token、Host設定の停止手順

回答が不明なままなら、連携を有効化せず、提供者の仕様・契約を確認します。機能の名称や説明文から、実際のread/write範囲を推定しないでください。

安全性は接続名と分けて評価する

Pluginという名前だから安全、MCPだから危険という比較はできません。どちらも、接続先、認証方法、scope、実行できる操作、結果の扱いが重要です。読み取りだけに見える機能が検索queryやdocument内容を外部へ送ることもあります。送信data、保持期間、利用者別の権限を確認します。

書き込み・削除・送信操作は読取と分け、必要なら実行前に人の確認を求めます。pluginを管理者が有効にする場合はworkspace全体に配布される範囲を、MCP Serverを登録する場合はserver process / remote endpointの所有者と実行権限を確認します。OAuth同意画面で要求scopeを読み、不要な権限があれば接続を中止します。

導入を小さく検証する手順

1. 業務目的を一文で決める。 例「社内FAQの検索候補を返す」。外部送信や更新まで必要か分ける。

2. 既存の公式連携を調べる。 対応plan、機能、scope、管理者設定、保存・学習条件を提供元の現行資料で確認。

3. 再利用範囲を決める。 一つのproductに閉じるか、複数Hostで共通利用するかを決める。

4. read-onlyでテストする。 テストデータと限定folderを使い、意図しないrecordへ届かないことを確認。

5. 実行操作を別に検証する。 書込・削除・送信が必要なら専用の承認と監査を追加。

6. 停止と引継ぎを試す。 接続解除、credential revoke、利用者変更、server更新の担当を確認。

7. 結果を記録する。 対象user、scope、data、test、残る制限を記録し、利用開始を承認。

それぞれの製品には別の管理機能があります。これらをすべてpluginやMCP自体が提供すると想定せず、契約と実装で確認します。

公式情報の読み方

OpenAIの現行Plugin開発情報では、pluginにSkills、MCP Servers、optional interfaces等を組み合わせる説明があります。ここではpluginがMCPと同じ言葉ではなく、product側の仕組みがMCP Serverを含み得る例として参照できます。ただし、読者が使う各ChatGPT機能の提供条件や管理方法は、製品の現行help / plan説明で別途確かめてください。

MCP公式ArchitectureとSpecificationは、Host / Client / Serverの関係やprotocol上のやりとりを説明します。仕様はversionが進むため、技術的な接続方法を決めるときは対象Host・Serverのversionと合わせて参照してください。一般的な「plugin」の定義をMCP仕様から決められるわけではありません。

AIものさしの判断

MCPは接続protocol、pluginは多くの場合productが提供する拡張・導入体験です。すぐ使える連携を一つのAI productで運用するなら公式plugin / connectorの条件を確認し、同じAI向け機能を複数Hostへ公開する必要があるならMCPを評価します。最後は名称ではなく、必要な機能、scope、data処理、管理者の制御、停止方法で決めてください。