Codex プラグインを束ねるOSS「OpenAI Plugins」の仕組みと中身

「Codex に Slack や Figma、社内の Notion を連携させたい」「公式のプラグイン配布フォーマットを把握して、自社用プラグインを整備したい」——AI コーディングツールの導入を進める開発チームで、こうした検討が増えています。その入り口で多くの技術リードが行き当たるのが、OpenAI 公式リポジトリ「OpenAI Plugins（openai/plugins）」です。

ところが、いざリポジトリを開いても「これは何を配布する仕組みなのか」「プラグインの中身はどう構成されるのか」「anthropics/skills や MCP サーバ集、awesome 系リストと何が違うのか」が一目では分かりにくいのが実情です。マーケットプレイスの画面でプラグインを追加する手順は説明されていても、配布の単位や内部構造まで踏み込んだ日本語の整理はまだ多くありません。

本記事では、openai/plugins の README・公式ドキュメント・リポジトリツリーの実測を一次情報として、(1) このリポジトリが何を配布する仕組みなのか、(2) plugin.json マニフェストの構成、(3) プラグインを構成する 5 つの要素（skills・apps・MCP・commands・hooks）、(4) 3 層マーケットプレイスの配布機構、(5) 類似リポジトリとの違い、(6) 採用前に確認したいライセンス・メンテナンス状況を整理します。Codex プラグインを採用すべきか、自作の雛形にすべきかを判断する材料を提供することがねらいです。

なお本記事は、リポジトリの実行・インストール・環境構築は行わず、README・公式ドキュメント・GitHub API で取得したリポジトリツリーの実測のみに基づいて記述しています。本文中の数値はいずれも調査時点（2026 年 6 月）のものです。

OpenAI Plugins とは｜Codex プラグインの公式キュレーション集

OpenAI Plugins（openai/plugins）は、Codex 向けプラグインの「キュレーション済みサンプル集（curated collection of Codex plugin examples）」として OpenAI が公式に管理するモノレポです。Codex で使えるプラグインのリファレンス実装とカタログを、一箇所にまとめて公開しています。

調査時点でのリポジトリの基本情報は次のとおりです。

このリポジトリはアーカイブ済み（archived）でもフォーク（fork）でもなく、OpenAI 公式が直接運用している現行のリポジトリです。一方で、リポジトリルートには OSI 準拠のライセンスが設定されていません（license フィールドは未設定）。この点は採用判断に直結するため、のちほど「採用時に確認したいこと」で改めて触れます。

「ChatGPT プラグイン」とは別物である点に注意

注意したいのは、ここでいう「プラグイン」は 2023 年に提供されていたChatGPT プラグイン（すでに提供終了）とは別物である点です。OpenAI Plugins が対象とするのは、エージェント型のコーディングツールである Codex 向けのプラグインです。検索の過程で旧 ChatGPT プラグインの情報と混同しやすいため、最初に切り分けておきます。

つまり OpenAI Plugins は、「Codex に対して、スキルや外部サービス連携・MCP サーバなどを束ねたプラグインを公式に配布・例示するためのモノレポ」だと捉えると理解しやすくなります。次に、その「プラグイン」が実際にどう構成されるのかを見ていきます。

Codex プラグインの仕組み｜plugin.json マニフェストの構成

Codex プラグインは、リポジトリ内の plugins/<name>/ というディレクトリ単位で配置されます。各プラグインの中核にあるのが、必須のマニフェストファイル .codex-plugin/plugin.json です。このマニフェストは、(1) プラグインを識別し、(2) バンドルされた各要素へのポインタを示し、(3) インストール画面に表示するメタデータを提供する、という 3 つの役割を担います。

必須フィールドと任意フィールド

公式のビルドガイドによると、plugin.json のフィールドは次のように整理できます。

interface オブジェクトは、マーケットプレイスのインストール画面での見え方を制御する部分です。displayName / shortDescription / longDescription / category / capabilities のほか、websiteURL / privacyPolicyURL / termsOfServiceURL といった URL 群、defaultPrompt（既定の呼び出し例）、logo / screenshots などのアセットを指定できます（出典: 公式ビルドガイド）。

実際のマニフェストがどうなっているかは、リポジトリ内の実装例で確認できます。たとえば figma プラグインの plugin.json は version が 2.0.9、license が LicenseRef-Figma-Developer-Terms、skills に "./skills/"、apps に "./.app.json" を指定し、interface の category は「Creativity」、capabilities は ["Interactive", "Read", "Write"] という構成です（出典: openai/plugins figma プラグイン）。一方 notion プラグインは version 0.1.3、license は MIT で、skills と apps を持ちます。このように、必須の 3 フィールドに加えて、プラグインが提供する機能に応じてポインタとメタデータが付与されていきます。

ディレクトリレイアウト

公式ビルドガイドが示すプラグインの標準的なディレクトリレイアウトは次のとおりです。

my-plugin/
├── .codex-plugin/
│   └── plugin.json (required)
├── skills/
├── hooks/
│   └── hooks.json (optional)
├── .app.json (optional)
├── .mcp.json (optional)
└── assets/

出典: 公式ビルドガイド

この雛形に対して、実際のプラグインはもっと豊富な構成を持ちます。たとえば figma プラグインのツリーには .codex-plugin/plugin.json に加えて agents/・commands/・skills/<name>/SKILL.md（参照資料の references/ を含む）・hooks.json・scripts/・assets/・plugin.lock.json が含まれます。notion プラグインでは skills 配下に evaluations/（評価用 JSON）や examples/（例示の Markdown）まで同梱されており、評価・例示を含む充実した構成になっています。

自社用プラグインを作る場合、この plugin.json に何を書き、どのディレクトリに何を置くかが最初の設計ポイントになります。採用するプラグインの構造を読むときも、まず plugin.json のポインタを追えば、そのプラグインが何を束ねているかを把握できます。

プラグインを構成する5つの要素｜skills・apps・MCP・commands・hooks

plugin.json が指し示すバンドル要素は、大きく「連携系」と「自動化系」に分けて捉えると整理しやすくなります。各要素の役割は公式 Codex Plugins ドキュメントに基づいて説明します。

Skills / Apps / MCP（連携系の3要素）

• Skills（スキル）: 特定の種類の作業に向けた、再利用可能な指示のセットです。Codex が文脈に応じて読み込み、適切な手順や参照資料を提供します。「このプラグインを入れると、こういう作業の進め方を Codex が知る」という部分にあたります。
• Apps（アプリ／コネクタ）: GitHub や Slack といった外部ツールとの接続を担います。Codex がそれらのツールから情報を読み取り、アクションを実行できるようにする要素です。マニフェストでは .app.json として参照されます。
• MCP Servers: Model Context Protocol（MCP）に対応したサーバで、ローカルプロジェクトの外にあるシステムのツールや共有情報へのアクセスを Codex に与えます。マニフェストでは .mcp.json として参照されます。

この 3 要素が、「自社の SaaS やツールを Codex に連携させたい」というニーズに対応する中心的な仕組みです。実際、openai/plugins に含まれるプラグインは airtable・github・gmail・hubspot・linear・slack・stripe・supabase・vercel・zoom など SaaS 連携系が中心で、Apps と MCP を組み合わせて外部サービスとつなぐ構成が目立ちます。

Commands・Agents・Hooks（自動化系）

• Commands / Agents: スラッシュコマンドやサブエージェントの定義です。figma プラグインのように commands/ や agents/ を持つプラグインは、特定の操作をコマンド化したり、補助的なエージェントを定義したりできます。
• Hooks（フック）: プラグインのライフサイクルに沿って実行されるフックです。フックコマンドには 2 つの環境変数が渡されます。PLUGIN_ROOT はインストールされたプラグインのルートディレクトリを指し、PLUGIN_DATA はプラグインが書き込み可能なデータディレクトリを指します（出典: 公式ビルドガイド）。フックを使うと、プラグインの導入時や実行前後にスクリプトを差し込めます。

全要素を持つプラグインの代表例が figma です。figma は agents・commands・skills・hooks・scripts を一通り備えた「全部入り」構成で、デザインツールとの双方向連携を実現しています。一方 notion は skills を主軸に、評価（evaluations）や例示（examples）まで含めてスキルの品質を担保する構成です。このように、プラグインによって使う要素の組み合わせは異なり、plugin.json のポインタを見ればどの要素を使っているかを読み取れます。

マーケットプレイスの仕組み｜3層の配布チャネルとカテゴリ

OpenAI Plugins を理解するうえでもう一つ重要なのが、プラグインをどう配布するかという「マーケットプレイス」の機構です。リポジトリのルート直下には .agents/（マーケットプレイス定義）と plugins/（個別プラグイン）の 2 ディレクトリがあり、配布の中核となるのが .agents/plugins/marketplace.json です。これがリポジトリ標準の plugins/ ディレクトリを指すデフォルトのマーケットプレイス定義になります。API キーでログインするユーザー向けには、別途 .agents/plugins/api_marketplace.json も用意されています。

3 層の配布チャネルと読み込み順

公式ドキュメントによると、プラグインの配布チャネルは大きく 3 つに整理できます。

Codex はこれらのカタログを 公式ディレクトリ → リポジトリスコープ → ユーザースコープ の優先順位で読み込みます。プラグインディレクトリの画面上では、公式キュレーション・ユーザー共有（ChatGPT ワークスペースのメンバーが共有）・ユーザー作成という形でグループ表示されます（出典: 公式 Codex Plugins ドキュメント）。この階層構造があるため、「社内専用のプラグインをリポジトリ内やユーザー環境に置きつつ、公式ディレクトリのプラグインと共存させる」といった運用が可能です。

マーケットプレイスエントリの構造とカテゴリ分布

marketplace.json の各エントリは、name / source（ローカルパス）/ policy（インストール方針・認証タイミング）/ category を持ちます。調査時点で plugins/ 配下には 173 個のプラグインディレクトリがあり、marketplace.json には約 174 件のエントリが登録されていました。

カテゴリ分布（marketplace.json 集計）は次のとおりで、業務系の連携が多いことが分かります。

なお、自作プラグインの土台づくりには組み込みの @plugin-creator スキルが用意されており、.codex-plugin/plugin.json の生成やローカルマーケットプレイスエントリの作成を支援します。ゼロからマニフェストを書くよりも、このスキルでスキャフォールドしてから既存プラグインを参考に肉付けする流れが現実的です。

類似リポジトリとの違い｜anthropics/skills・MCP サーバ集・awesome リスト

採用判断で最も悩ましいのが、「自分の用途には openai/plugins が適切なのか、それとも別のエコシステムの方が合うのか」という点です。ここでは性質の近い 4 つのリポジトリと比較し、配布の単位と対象エコシステムの違いを整理します（スター数は調査時点）。

ここから見えてくる openai/plugins の独自性は、「Codex 専用に、マニフェスト駆動でスキル／コネクタ／MCP／コマンド／フックをバンドルしたプラグインを、公式キュレーション・リポジトリスコープ・ユーザースコープの 3 層マーケットプレイスで配布する公式モノレポ」である点です。

選定の目安を言い換えると、次のようになります。

• スキル（指示セット）だけを Claude エコシステムで使いたい → anthropics/skills
• MCP サーバ単体を探している（ツール・エコシステム非依存で再利用したい）→ modelcontextprotocol/servers
• まず情報を俯瞰したい・リンクから探したい → awesome 系リスト
• Codex でスキル・外部連携・MCP・コマンド・フックを「プラグイン」という 1 パッケージとして配布／採用したい → openai/plugins

「スキル集」「MCP 集」「awesome リスト」のどれでもなく、複数要素をプラグイン単位で束ねて Codex に配布する、という配布単位の違いが選定の決め手になります。

採用時に確認したいこと｜ライセンス・メンテナンス状況・想定ユースケース

最後に、openai/plugins を採用・参照する前に確認しておきたい点を、ライセンス・メンテナンス・ユースケースの 3 つの観点で整理します。

ライセンスは「プラグインごと」に確認する

前述のとおり、openai/plugins のリポジトリルートには OSI 準拠のライセンスが設定されていません（license は未設定）。ただし、これは「全プラグインがライセンス不明」という意味ではありません。個別のプラグイン配下に LICENSE.txt を持つものや、plugin.json の license フィールドでライセンスを宣言しているものがあります。実際、figma プラグインは LicenseRef-Figma-Developer-Terms、notion プラグインは MIT というように、プラグインごとにライセンスが個別設定されています。

したがって、特定のプラグインを採用する際は、リポジトリ全体ではなくそのプラグインの LICENSE.txt および plugin.json の license フィールドを個別に確認する必要があります。社内利用・商用利用の可否は、束ねられた各要素（特に外部サービスのコネクタ）の利用規約にも影響を受けるため、Apps が参照する外部サービス側の規約もあわせて確認しておくと安全です。

メンテナンス状況は健全か

メンテナンスの健全性については、次の点が確認できます。

• OpenAI 公式が直接運用するリポジトリであり、アーカイブ済み・フォークのいずれにも該当しない
• 2026 年 6 月時点で push があり、活発に更新されている
• スター数 3,131・Fork 数 372 と、相応のコミュニティ関心がある

リファレンスとして参照する分には、現行で更新が続いている公式リポジトリという点は安心材料になります。一方、特定プラグインを本番運用に組み込む場合は、そのプラグインが扱う外部サービスの API 変更に追従できているか（個別プラグインの更新履歴）も併せて見ておくとよいでしょう。

想定されるユースケース

openai/plugins の使い方は、おおむね次の 3 パターンに整理できます。

1. 公式プラグインをそのまま採用する: Slack・Figma・Notion など、既に整備されたプラグインをマーケットプレイス経由で導入する。
2. 自作プラグインの雛形にする: figma や notion の構成を参照し、@plugin-creator でスキャフォールドして自社用プラグインを作る。
3. 社内マーケットプレイスを構築する: リポジトリスコープ／ユーザースコープの marketplace.json を使い、社内専用プラグインを公式ディレクトリと共存させて配布する。

なお本記事の記述は、リポジトリの実行や動作確認を行わず、README・公式ドキュメント・GitHub API で取得したリポジトリツリーの実測に基づいています。実際に導入する際は、対象プラグインのマニフェストとライセンス、外部サービス連携の認証要件を自社環境で個別に検証してください。

まとめ

OpenAI Plugins（openai/plugins）は、Codex 向けプラグインを公式にキュレーションして配布・例示するモノレポです。本記事の要点を振り返ります。

• 何のリポジトリか: Codex（エージェント型コーディングツール）向けプラグインの公式サンプル集。2023 年の旧 ChatGPT プラグインとは別物。
• 仕組み: プラグインは plugins/<name>/ 単位で配置され、必須の .codex-plugin/plugin.json がプラグインを識別し、バンドル要素を指し示し、インストール画面のメタデータを提供する。
• 構成要素: skills（再利用可能な指示）/ apps（外部コネクタ）/ MCP（外部ツール・情報アクセス）/ commands・agents（コマンド・サブエージェント）/ hooks（PLUGIN_ROOT・PLUGIN_DATA を受け取るライフサイクルフック）の 5 要素。
• 配布: 公式ディレクトリ → リポジトリスコープ → ユーザースコープの 3 層マーケットプレイスで配布され、Codex はこの順で読み込む。
• 独自性: スキル単体集・MCP 単体集・awesome リストのいずれでもなく、複数要素をプラグイン単位で束ねて Codex に配布する点が、anthropics/skills や modelcontextprotocol/servers との違い。
• 採用前の確認: ライセンスはプラグインごとに確認（ルートは未設定）。公式管理・活発に更新中だが、本番運用では個別プラグインの追従状況も確認する。

Codex プラグインを採用するか自作するかを検討する際は、まず openai/plugins を公式リファレンスとして開き、近い構成のプラグインの plugin.json を読み解くところから始めると、判断の解像度が一気に上がります。