CodexのSkills・MCP・プラグインの違い

「CodexからBlenderを操作したい」と考えたとき、Skillを作るのか、MCPをつなぐのか、それともプラグインを入れるのか。ここで迷うのは、3つが同じ種類の機能に見えるからです。

Blender連携を実際に検証すると、MCPをつないでシーンを読む入口は増えましたが、「読み取りから始める」「本番ファイルを保存しない」といった進め方までは接続だけで決まりませんでした。Skillは手順、MCPは接続、プラグインは配布の仕組みと分けると、この違いを整理できます。

連携の例にはBlender LabのMCPを使います。Codexの機能と各アプリで使える範囲は、2026年11月14日にOpenAIの公式資料と照合しました。

先に結論：3つは競合する機能ではない
Skills・MCP・プラグインを5項目で比較
この作業にはどれを選ぶか
Blender操作に当てはめると分かりやすい
デスクトップ・CLI・IDE拡張では何が違うか
接続前に決める権限と安全性
混同しやすい3点
迷ったときの決め方
参照元

先に結論：3つは競合する機能ではない

関係を簡略化すると、次の形です。

Skill、MCP、プラグインを手順・接続・配布の役割で分けた図 — プラグインにはSkillだけ、MCPだけ、またはその両方を含められます。

図の矢印は「配布するときにまとめられる」という意味です。プラグインはSkillだけを含むことも、MCPサーバーだけを含むことも、両方を含むこともあります。「SkillとMCPの上に必ずプラグインが必要」という意味ではなく、自分の環境だけで使うなら単体で設定できます。

足りないのが作業手順ならSkill、外部ツールへの入口ならMCP、他の人にも導入してもらう単位が必要ならプラグインです。

Skills・MCP・プラグインを5項目で比較

比較項目	Skill	MCP	プラグイン
何を持つか	必須の`SKILL.md`に手順とメタデータ。必要に応じてスクリプト、参考資料、テンプレート、素材	モデルから呼べるツール、入出力、コンテキスト、認証。サーバー側の共通指示も持てる	Skill、コネクタ、MCPサーバー設定などをまとめるマニフェスト付きパッケージ
どこで動くか	CodexやChatGPTが内容を読み、必要な手順を実行する。補助スクリプトは実行環境で動く	STDIOならローカルプロセス、Streamable HTTPなら接続先サーバーで動く	プラグイン自体は配布・導入の単位。中のSkillはホスト、MCP処理は接続先で動く
向く用途	レビューやテストなど、繰り返す作業の手順をそろえる	Blenderや社内システムなど、外部の操作や情報へ接続する	複数の手順や接続をまとめて導入・共有する
権限・安全性	暗黙起動の範囲と同梱スクリプトを確認する。実際のローカル操作にはホストの権限設定が関わる	認証、公開ツール、読み書き、承認モードを絞る。サーバーは入力検証も必要	同梱するコネクタ、MCP、hooksの権限をまとめて確認する。外部サービスは別途認証が必要
設定・共有範囲	リポジトリ、ユーザー、管理者、システムの各スコープ。広く配るならプラグイン化	ユーザー単位または信頼済みプロジェクト単位。デスクトップ、CLI、IDE拡張は同じCodexホストの設定を共有	公開ディレクトリ、ワークスペース、リポジトリ、個人向けマーケットプレイスなど

表の「MCP」はModel Context Protocolの略です。接続で使える操作は、MCPサーバーが公開したツールと、Codex側で許可したツールの組み合わせで決まります。たとえばシーン名を読むツールだけを許可すれば、そのMCP接続を通じたファイルの保存はできません。

使える画面も同じではありません。特に、単体SkillとMCPを使えるIDE拡張がプラグインには対応していない点は、後半で整理します。

この作業にはどれを選ぶか

判断は、足りないものを上から判定していくと迷いません。

1. いま使えるツールだけで作業は完了するか

完了するが、毎回の確認順や出力形式がばらつくなら、最初の候補はSkillです。たとえば「変更前に対象ファイルを読む」「編集後にテストする」「最後に差分を確認する」という手順を、毎回長いプロンプトで渡す必要がなくなります。

Skillには説明だけでなく、参考資料やテンプレート、必要なら補助スクリプトも含められます。ただし、Skillを書いただけでCodexに存在しない操作能力が増えるわけではありません。

リポジトリ全体で毎回使うテストコマンドなどは、ルートの AGENTS.md にも書けます。読み込むフォルダや指示が分からないときは、CodexでAGENTS.mdが反映されないときに確認する3か所を参照してください。

2. 外部アプリや外部データへ届かないことが問題か

既存のツールでは対象の状態を読めず、対応するMCPサーバーがあるなら、MCPが候補です。サーバーが公開するツールを確認してから、欲しい操作だけをCodexで使えるようにします。

この段階ではプラグインを先に作る必要はありません。まずMCPサーバー単体で、必要な情報を正しく読めるか、書き込み操作を狭く制御できるかを確かめます。

3. 自分だけで使うのか、同じ構成を配るのか

一つのリポジトリや自分の環境だけなら、SkillとMCPをそれぞれのスコープで設定できます。チームに同じワークフローと接続を導入してもらうなら、プラグインとしてまとめる理由が生まれます。

プラグインにまとめる目的は、必要なSkillと接続を、発見・インストール・更新しやすくすることです。

4. 手順と接続の両方が必要か

この場合は一つに決めません。MCPで操作手段を用意し、Skillで「どの順に、何を確認しながら使うか」を定めます。配布が必要になった段階で、両方をプラグインへ入れます。

Blender操作に当てはめると分かりやすい

Blenderで製品モデルを作り、途中経過をレンダリングして確認する作業を例にします。

Skillが担当するのはモデリングの進め方

Skillには、作業前に資料をそろえる順番、単位系の確認、シルエットを先に固めること、破壊的な編集前に複製すること、確認用レンダーの角度、完了条件などを書けます。

これは「Blender作業の手の内」を再利用する仕組みです。モデルに何を作らせるかだけでなく、どこで立ち止まり、何を見て合否を判断するかまで残せます。

一方、Codex側にBlenderへ命令を渡す手段がなければ、Skillは操作の入口にはなりません。操作手順を正しく説明できても、シーンを取得したりオブジェクトを変更したりする能力は別途必要です。

MCPが担当するのはBlenderへの入口

Blenderと連携するMCPサーバーが、シーン情報の取得、オブジェクト操作、レンダリングなどのツールを公開しているとします。その場合、CodexはMCPを通じて定義済みの操作を呼び出せます。

ここで重要なのは、MCPにつないだ事実と、何ができるかは別という点です。実際に使えるツール名、読み取りと書き込みの範囲、Blenderの対応版、保存や取り消しの挙動は、MCPサーバーの実装によって変わります。

OpenAIの公式資料で確認できるのは、CodexがSTDIOまたはStreamable HTTPのMCPサーバーへ接続できること、ツールの許可・拒否や承認方法を設定できることです。特定のBlender向けMCPサーバーの品質や互換性までは保証していません。

プラグインが担当するのは一式の導入

Blender用の作業SkillとMCP接続を自分だけで試す段階なら、プラグイン化は必須ではありません。同じ構成をチームへ配りたい、関連する複数のSkillを一つの名前で管理したいという段階で、プラグインが役立ちます。

プラグインにまとめても、MCPの操作精度が上がるわけではありません。誰が導入しても同じ構成を見つけやすくすることが主な役割です。

デスクトップ・CLI・IDE拡張では何が違うか

現在のCodexはCLIだけではありません。OpenAI公式資料では、次のように役割が分かれています。

ChatGPTデスクトップアプリ: プロジェクトや長時間作業を並行して管理し、ファイル、ブラウザ、デスクトップアプリ、プラグインを扱う作業拠点
Codex CLI: ローカルリポジトリをターミナルから調査・編集・実行し、対話操作やcodex execによる自動化を行うクライアント
Codex IDE拡張: 開いているファイルや選択範囲を文脈として渡し、エディタ内で変更を確認するクライアント

単体のSkillとMCPサーバーは3つで利用できます。同じCodexホスト上ではMCP設定も共有されるため、デスクトップで追加した接続をCLIやIDE拡張へ切り替えるたびに設定し直す必要はありません。

ただし、IDE拡張はプラグインをサポートしていません。 プラグインを探してインストールする場合は、ChatGPTデスクトップアプリまたはCodex CLIを使います。ChatGPT WebもローカルのCodex設定ファイルは読まず、プラグインが提供するリモートMCPツールを使います。

この違いがあるため、「デスクトップで使えたプラグインがIDEの一覧にない」ことを、MCP接続の失敗と判断しない方がよいでしょう。

接続前に決める権限と安全性

Blender連携では、シーンのオブジェクト名を読むだけの操作から始めると、接続の成否を安全に見分けられます。実際に設定する場合は、WindowsでBlender公式MCPにつなぐ手順で、読み取りツール一つだけの構成を紹介しています。

MCP設定ではサーバーごとに利用ツールを絞り、ツール単位の承認方法も設定できます。保存済みファイルの上書き、削除、外部送信に関わる操作は、人が内容を確認してから実行する境界を残します。

外部サービスへ接続する場合は、認証・認可の要件もMCPサーバー側で定義します。トークンをSkill本文やプラグインの説明へ直接書かず、必要最小限の権限にします。OpenAIのプラグイン向けセキュリティ資料も、最小権限、明示的な同意、サーバー側の入力検証、取り消せない操作への人の確認を求めています。

プラグインにはhooksなど、所定のタイミングでコマンドを実行する部品を含められます。インストール元だけで判断せず、マニフェスト、同梱Skill、MCP接続先、hooksの内容を確認します。プラグイン経由でCodexホスト上の操作を行う場合も、ホストのサンドボックスと承認ポリシーが適用されます。

混同しやすい3点

Skillは単なる長文プロンプトではありません。 手順に加えて、参考資料、テンプレート、素材、任意のスクリプトを一つのディレクトリで管理できます。

MCP接続は万能な遠隔操作ではありません。 サーバーが公開したツールだけが入口です。接続済みでも、必要なツールがなければ目的の操作はできません。

プラグインはMCPの別名ではありません。 Skillだけのプラグインも、MCPだけのプラグインも作れます。違いは中身ではなく、導入と共有の単位であることです。

迷ったときの決め方

Blenderの作業品質をそろえたいだけなら、Skillから始めます。CodexにBlenderの状態取得や操作まで任せたいなら、要件に合うMCPサーバーが必要です。その組み合わせを他の人にも同じ形で使ってもらう段階で、プラグインにまとめます。

見る順番は「何を配りたいか」ではなく、いま足りないのは手順か、接続かです。そこを決めてから共有範囲を考えると、不要な仕組みを増やさずに済みます。