Codex PluginsとSkillsの違い｜MCP・コネクタ・Hooksを安全に使い分ける

先に結論：PluginはSkillを含み得る、より大きな再利用単位

OpenAI DocsのPluginsページでは、Pluginsは再利用可能なworkflowやcapabilityをまとめる単位として説明されています。PluginにはSkills、Connectors、MCP servers、browser extensions、Hooks、scheduled task templatesなどが含まれ得ます。したがって、PluginとSkillを同じものとして扱うより、Skillは手順、Pluginは複数の機能を束ねた配布単位、と考える方が導入前の確認項目を分けやすくなります。

PluginsとSkillsを一言で分ける

この表のAGENTS.mdとPromptの位置づけは、サイト内での運用整理です。OpenAI DocsのPluginsページが定義しているのはPluginの構成と利用面なので、プロジェクト固有のルールはAGENTS.md、繰り返す手順はSkill、外部へつながる機能はConnectorやMCPとして別々にレビューします。

Pluginに含まれ得る6つの部品

「含まれ得る」は、すべてのPluginに全要素が入るという意味ではありません。Pluginごとに構成が違う可能性があるため、名前や紹介文だけで判断せず、インストール前に含まれる部品を確認することが重要です。

どの画面で使えるのか：対応面を先に固定する

ここでいう対応面は、OpenAI DocsのPluginsページに記載された現行の案内です。プラン、workspace設定、段階的提供、アプリの版によって表示が変わる可能性があるため、記事の表だけで利用可否を確定せず、自分の画面と公式Docsを突き合わせます。

現行Docsでは、インストール済みPluginのSkills、Connectors、MCP toolsは新しいchatやCLI sessionで利用する流れです。Connectorはsetup中または初回利用時に外部サービスへの接続を求めることがあり、MCPも追加設定や認証が必要な場合があります。Pluginを入れたこと、接続が済んだこと、Codex hostのsandbox・approval policyの範囲でtoolを実行できることは、別々に確認します。

Codex CLIでは、/pluginsから導入面を確認する

/plugins

• Codex CLIで/pluginsを開き、設定されているMarketplaceと見えるPluginを確認する
• Pluginの説明だけでなく、Skills、Connectors、MCP servers、Hooksなど含まれる部品を読む
• 外部接続がある場合は、認証方式、送信先、読み書き権限、scopeを確認する
• 導入後すぐに重要repoへ適用せず、新しいsessionで小さな読み取り作業から挙動を見る
• 差分、ログ、外部サービス側の記録を確認し、期待しない接続や変更があれば停止する

Codex CLIのpluginコマンド：TUIと自動化を分ける

現行のCodex CLI Developer commandsでは、`/plugins`のbrowserに加えて、`codex plugin add`・`list`・`remove`と、`codex plugin marketplace add`・`list`・`remove`・`upgrade`が案内されています。`--json`を付けると自動化向けの出力になり、Pluginのinstalled・available、version、enabled、source、installPolicy、authPolicyなどを機械的に記録できます。TUIで見つける操作と、CIや管理スクリプトで状態を読む操作を同じものとして扱わないようにします。

codex plugin list --json
codex plugin list --available --json
codex plugin marketplace list --json
codex plugin add YOUR_PLUGIN@YOUR_MARKETPLACE --json
codex plugin remove YOUR_PLUGIN@YOUR_MARKETPLACE --json

MarketplaceとPlugin directoryは、発見と信頼を分けて使う

Plugin directoryやMarketplaceは、候補を見つけるための入口です。掲載されていること、導入できること、現在の作業に安全に使えることは別の判断です。特にConnector、MCP server、Browser extension、Hooksが含まれる場合は、外部へ出る情報と変更できる範囲を読んでから適用します。

Universal plugin directoryは、利用面と導入状態を分けて見る

現行のPluginsページでは、ChatGPTとCodexが同じpublic plugin catalogを使います。ただし、見える場所と使える面は同じではありません。WebのChatGPT Work、ChatGPT desktop appのChatGPT Work/Codex、Codex CLIのplugin browserを別々に確認し、Installed rowやworkspace・personalの区分で導入済み状態を確認します。

DirectoryのタブやInstalled rowは、発見・所属・導入状態を整理する表示です。Pluginをインストールできたことは、Connectorの認証やtoolの承認が済んだことを意味しません。Webではインストール時、初回利用時、別の接続画面で認証を求められる場合があるため、画面の要求を順番に確認します。

SkillとMCP・Connectorは、同じ『便利機能』でも境界が違う

Skillは、作業の進め方や確認手順を再利用するためのInstructionsとして扱います。一方、ConnectorやMCP serverは外部のサービスやtoolへつながる可能性があります。前者では適用範囲と出力を、後者では認証、送信データ、読み書き、toolの許可範囲を中心にレビューします。Pluginに両方が入る場合、Skillを読んだだけで外部接続まで安全になるわけではありません。

HooksとScheduled task templatesは、時間と自動実行を確認する

PluginにHooksやscheduled task templatesが含まれるなら、通常の手動実行よりも開始条件と停止条件の確認が重要になります。いつ動くのか、何を対象にするのか、通知や外部送信があるのか、失敗時にどう止めるのかを、導入前に文章で説明できる状態にします。自動で動くことは、内容が検証済みであることを意味しません。

• Hookの実行条件、対象ファイル、変更可能な範囲を確認する
• scheduled taskの頻度、timezone、通知先、実行アカウントを確認する
• 外部へ送るデータ、認証情報、ログの保存先を確認する
• 一時停止・削除・再実行の方法を先に試し、戻せない変更を最初のテストにしない

HooksはPluginの表示ではなく、実行経路としてtrustする

• Hookのevent、matcher、command、timeout、statusMessage、additionalContextLimitを先に読む。Windows固有commandは`command_windows` / `commandWindows`の有無を確認する。
• `/hooks`で新規・変更Hookをreviewし、hashが変わったHookは再びtrustが必要だと考える。
• `--dangerously-bypass-hook-trust`は、Hook sourceをCodex外で検証済みの一回限りのautomationに限定し、普段の導入手順には使わない。
• Hooksを無効化する場合は`[features].hooks = false`とdeprecated aliasの`codex_hooks`を混同せず、managed policyで強制されていないか確認する。
• Hookのログ・analytics・memory・validationは副作用を持ち得るため、外部送信、secret、個人情報、transcript pathを最小化する。

Codexの作業ルール、Skill、Pluginを置く場所を分ける

これは製品の設定ファイルを置く場所を一律に決める話ではなく、レビュー単位を分けるための実務整理です。repo全体に効くルールと、任意の作業手順、外部接続を一つの長いPromptに混ぜない方が、変更時の影響を追いやすくなります。

導入前の安全チェックリスト

• 自分が使う面が、現行のPluginsページにある対応面か確認した
• Pluginに含まれるSkills、Connectors、MCP servers、Browser extensions、Hooks、scheduled task templatesを確認した
• Marketplaceやdirectoryの表示を、信頼性の証明ではなく候補発見の入口として扱った
• 外部接続のURL、認証、scope、読み書き、送信データ、ログを確認した
• Hooksやscheduled taskの開始条件、停止方法、通知先を確認した
• Codex CLIでは/pluginsを確認し、導入後に新しいsessionで小さく試す計画を立てた
• 重要repo、本番環境、秘密情報を最初の試行対象から外し、差分とログを残すようにした

認証・承認・アンインストールを同じ操作だと考えない

Pluginの導入、Connectorへのサインイン、hostのsandbox・approval policy、Pluginの削除は別の状態です。API keyでCodexへサインインしている場合も、OAuthが必要な一部のPluginは利用できない可能性があります。接続を外したいときは、Plugin bundleを削除しただけでConnectorまで切れたと判断せず、ChatGPT側の接続管理も確認します。

Claude Code Skillsと混同しない

このサイトにはClaude CodeのSkillsとCLAUDE.md・AGENTS.mdを扱う別記事があります。今回の記事は、OpenAI DocsのCodex PluginsページにあるPluginの構成と利用面を対象にしています。名前にSkillが含まれていても、Claude Code向けのSkillがそのままCodex Pluginとして動く、または逆方向に互換であるとは判断しません。利用する製品、配布形式、対応面、必要な設定を個別に確認してください。

まとめ：Pluginを入れる前に、含まれる機能を分解する

Codex Pluginsは、Skillだけを追加する仕組みではなく、Skills、Connectors、MCP servers、Hooksなどを束ねる再利用単位として確認します。使える面、Marketplaceやdirectoryの範囲、外部接続、認証、scope、停止方法を分けてレビューし、Codex CLIでは/pluginsと新しいsessionを入口に小さく試します。便利そうだから一括で許可するのではなく、手順と外部権限を分解できる状態を作ることが、個人開発での安全な導入につながります。

Standalone SkillとPlugin-bundled Skillを分ける

Progressive disclosureは実行許可ではない

ChatGPTとCodexは最初にSkillのnameとdescriptionを一覧へ読み込み、taskに合うと判断したときにfull SKILL.mdを読む設計です。Codexの初期一覧にはSkillのfile pathも含まれ、一覧はcontextの最大2%または8,000 charactersを目安に短縮されます。Skillが多いと一部が初期一覧から省略されwarningが出る可能性があるため、一覧に見えないことを無効化や安全の証明と扱いません。

• Skillのdescriptionに、対象task、入力、出力、触ってよい範囲、触らない範囲を短く書く。
• SKILL.mdだけでなくscripts、references、assets、agents/openai.yaml、MCP tool dependencyの宣言を読む。
• descriptionの名前一致だけで暗黙に選ばれることを避けたいSkillは、`agents/openai.yaml`の`allow_implicit_invocation: false`を検討する。
• 選択されたSkillの全文を読み、外部取得、shell command、秘密情報、MCP、browser、生成物への副作用を確認してから実行する。

Skillの呼び出し方とlocal discovery

同じ`name`のSkillが複数scopeにあっても、Codexは一つへmergeせず両方をselectorへ出せます。symlinked Skill folderも追跡されるため、ファイルが見えているdirectoryだけを確認せず、symlink先、親repo、user・admin scopeまで含めて実際に選ばれる候補を確認します。

Skillを止める・配布する・更新する

• local Skillを無効にする場合は`~/.codex/config.toml`の`[[skills.config]]`で対象SKILL.mdのpathと`enabled = false`を指定し、Codexを再起動する。
• curated Skillの追加は`$skill-installer`をlocal setupの入口として扱い、別repoから取得するSkillは出所、commit、scripts、licenseを確認する。
• 自作Skillは`$skill-creator`やRecord & Replayで雛形を作れても、description、全文、外部tool、生成物、更新差分は人間がreviewする。
• 単独repoで使うSkillは`.agents/skills`のscopeを検討し、複数Skillやconnectorを配布する場合はPlugin bundleの構成と依存を分けて確認する。
• Skill更新後に表示されない場合はCodex再起動が必要なことがあるため、古いSkillが動いていると決めつけずversionとpathを確認する。

workspace Skill・local Skill・Pluginの管理境界を分ける

同じSkillをworkspaceから共有する場合とrepoへ置く場合では、管理者、配布経路、更新責任、停止方法が変わります。Skillを別の面へコピー・移動しても、workspaceの所有権や共有role、Pluginのインストール状態、Connectorの認証が引き継がれるとは限りません。どのpath、workspace、Plugin packageから読まれているかを記録してから利用します。

Pluginの導入許可だけで外部操作を許可しない

• Plugin availability / installation：workspaceやCLIのPlugin導入経路でbundleが利用可能かを確認する。
• Bundled Skill：インストールされたPluginがどのinstructionsやworkflowを追加するか、packageとSkill controlsで確認する。
• Connector access：外部サービスへの接続をworkspace roleやapps設定で許可するかを確認する。
• Connector actions / permissions：read-onlyかwriteを含むか、実行前確認をいつ要求するかを確認する。
• Source-system authorization：接続先サービスと認証済みidentityが実際に読める・変更できる範囲を確認する。
• Runtime permissions：sandbox、approval、MCP、filesystem、networkなど、実行面のruntime policyを別に確認する。

管理者がPluginをavailableにしたことは、外部システムのread・writeを安全に許可したことを意味しません。まずread actionsを中心に、Plugin owner、requested scopes、外部データ、write actionの影響、復旧方法をレビューし、必要なroleだけへ割り当てます。接続先の権限が強ければ、Plugin側の表示やworkspace設定だけでは影響範囲を狭められません。

Record & ReplayをWindowsの機能と取り違えない

Windowsでskills・replayを再開する確認順

• 最初にOS、region、account、desktop appのsurface、Computer Useのavailability・enabled状態、organization policyを確認する。WindowsでmacOS限定機能の入口を再現しようとしない。
• recordingするworkflowは既知で安定し、success criteriaが明確な短いものに限定する。録画前に変動するinput、命名規則、decision point、停止条件、検証手順を決める。
• realistic inputを使ってもsecret、API key、Cookie、個人情報、機密file、signed-in画面をrecordingへ含めない。画面content、window、plugin、Browser、外部送信の範囲をreviewする。
• 生成skillは新しいchatでreplayする前に、入力、許可、対象path、外部service、成功条件、検証方法を読み、現在hostのtool・permission・MCP・sandboxと一致するか確認する。
• team配布やMCP・connector・install metadataが必要になったら、skillのreplayとplugin化を分けて設計する。実行後は結果だけでなくdiff、test・build、外部変更、ログ、secret露出、停止方法を確認する。