エンジニアが毎回ゼロから同じプロンプトを書いている。チームで構築したワークフローを他のメンバーに共有するのが手間だ。そんな悩みを抱えていませんか？
OpenAI Codexが2026年に入って展開したプラグイン（Plugins）機能は、そのモヤモヤを一気に解消する仕組みです。スキル（AIへの指示書）、MCP設定（外部ツール連携）、アプリ統合を1つのパッケージにまとめて、チーム全体にインストールできるようになりました。
この記事では、Codexプラグインとは何なのか、どう使えばいいのか、具体的にどんな開発現場で役立つのかを徹底的に解説します。読み終わった頃には「早速チームに展開してみよう」と思えるはずです。
- そもそもCodexプラグインって何？スキルとの違いから整理する
- プラグインの構造を理解する—中身は思ったよりシンプル
- プラグインのインストール方法—3つの入口
- 実際の開発現場での活用シナリオ
- 競合ツールとの比較—Codexプラグインはどこが違うのか
- プラグインを使う上での注意点と現実的な制約
- 最初のプラグインを作ってみる—実践的な手順
- まとめ—プラグインはチームの「開発文化をコード化」する手段
そもそもCodexプラグインって何？スキルとの違いから整理する
Codex自体をおさらい
まず前提として、Codexについて簡単に。
OpenAI Codexは、コード生成・修正・レビューを自律的にこなすAIエージェントです。「この関数にテストを追加して」「このリファクタリングお願い」と自然言語で指示するだけで、GPT-5.4-Codexなどのモデルが実際のコードを読み書きします。
ChatGPTのPlusプラン（月額約3,000円）以上で使えて、VS Code拡張機能、CLIツール、ブラウザのWebインターフェイス、スマートフォンからもアクセス可能です。単なる「コード補完」ではなく、複雑なリファクタリングやテスト生成、PRレビューまでこなす開発チームの一員として機能します。
スキル（Skills）という概念
Codexにはすでにスキルという概念があります。これは「AIへの作業手順書」みたいなもので、SKILL.mdというMarkdownファイルに書かれた指示書です。
たとえば「Datasettプラグインの書き方」「コードレビューの観点」「プロジェクト固有のドキュメント生成ルール」を1つのスキルファイルにまとめておくと、Codexがそのスキルを自動で発見して使ってくれます。スキルのサポートは2025年12月15日に実験的機能として開始されました。
CLIでは $.スキル名 で明示的に呼び出せますし、タスク内容を見てCodexが自動的に適切なスキルを選んでくれます。
プラグインはスキルの「パッケージ版」
ここからが本題です。
スキルは便利ですが、「自分のプロジェクト専用」の色が強い。チーム全員に展開しようとすると、ファイルを手動でコピーしてもらったり、セットアップ手順を共有したりと手間がかかります。
プラグインは、それを解決する仕組みです。
プラグインはCodexの再利用可能なワークフローをインストール可能なバンドルとしてまとめたもので、プロジェクトやチームをまたいで同じセットアップを共有しやすくします。スキル、オプションのアプリ統合、MCPサーバー設定を1つにまとめて配布できます。
つまり「よく使うスキル + よく使うMCPサーバー設定 + アプリ連携」をワンパッケージにして、チームメンバーが1コマンドでインストールできる形にしたものです。
スキル単体 vs プラグインの使い分け
公式ドキュメントがわかりやすく整理してくれています。
| 使うべき場面 | スキル（単体） | プラグイン |
|---|---|---|
| 一つのリポジトリ・ワークフロー | ✅ | |
| 個人的・実験的な用途 | ✅ | |
| チーム全体で同じ設定を共有 | ✅ | |
| スキル＋MCP設定をセットで配布 | ✅ | |
| バージョン管理された安定パッケージ | ✅ |
まずローカルで試してから、共有できる段階になったらプラグインとしてパッケージ化する、という流れが推奨されています。
プラグインの構造を理解する—中身は思ったよりシンプル
プラグインの中身
プラグインの実体は、特定のディレクトリ構造を持つフォルダです。
my-plugin/ ├── .codex-plugin/ │ └── plugin.json ← 必須：プラグインのマニフェスト ├── skills/ │ └── my-skill/ │ └── SKILL.md ← スキルの指示書 ├── .app.json ← アプリ連携（任意） ├── .mcp.json ← MCPサーバー設定（任意） └── assets/ ← アイコン・スクリーンショット（任意）
.codex-plugin/plugin.json のみが必須です。skills/、assets/、.mcp.json、.app.json はプラグインのルートに置きます。
マニフェストファイルの書き方
plugin.json が、プラグインの「名刺」です。最小限の構成はこれだけ：
{ "name": "my-first-plugin", "version": "1.0.0", "description": "社内標準のコードレビューワークフロー", "skills": "./skills/" }
チーム公開や配布を想定するなら、より詳細なマニフェストを使います。
{ "name": "team-review-plugin", "version": "0.1.0", "description": "コードレビュー・テスト生成・ドキュメント作成の標準スキルセット", "author": { "name": "開発チーム", "email": "dev@company.com" }, "skills": "./skills/", "mcpServers": "./.mcp.json", "apps": "./.app.json", "interface": { "displayName": "チーム標準プラグイン", "shortDescription": "社内開発標準のスキルとツール統合", "category": "Productivity", "capabilities": ["Read", "Write"], "defaultPrompt": [ "このPRをチームの基準でレビューして", "このモジュールのテストコードを生成して" ] } }
defaultPrompt に書いておくと、Codexがプラグインを使う際の「入口のプロンプト例」として提示してくれます。チームメンバーが「どう使えばいいの？」と迷わずに済む工夫です。
MCP設定をプラグインに含める
MCPサーバー（Model Context Protocol）とは、Codexが外部ツールにアクセスするための仕組みです。たとえばGitHub、Jira、Slackのデータをリアルタイムで参照しながらコーディング作業できます。
.mcp.json にサーバー設定を書いておくと、プラグインをインストールするだけでそのMCP設定も一緒に反映されます。毎回手動でMCPサーバーを設定する手間が省けます。
プラグインのインストール方法—3つの入口
Codexアプリのディレクトリから
最も簡単な方法です。OpenAIがキュレートしたプラグインがCodexディレクトリに表示されます。すぐに使えるワークフローやアプリ統合が欲しい場合はここが出発点になります。
Codexアプリを開くと、プラグインディレクトリが表示されます。気になるプラグインを選んでインストールするだけです。ChatGPTのGPTsストアに似た感覚で使えます。
CLIからインストール
ターミナルで作業するエンジニアには、CLIが手っ取り早いです。
codex /plugins
この2コマンドで、プラグインの管理画面が開きます。プラグインは個別に有効・無効を切り替えられ、オン/オフの状態は ~/.codex/config.toml に保存されます。
ローカルで自作プラグインを使う
自社用のプラグインを作って使いたい場合は、ローカルマーケットプレイスに登録する方法があります。
リポジトリ単位で共有するなら、.agents/plugins/marketplace.json を作ってプロジェクトに置きます。
{ "name": "company-repo", "plugins": [ { "name": "team-plugin", "source": { "source": "local", "path": "./plugins/team-plugin" }, "policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" }, "category": "Productivity" } ] }
この設定ファイルをリポジトリにコミットしておけば、チームメンバー全員がCodexを起動した際に同じプラグインが見えるようになります。
個人専用のプラグインなら ~/.agents/plugins/marketplace.json に書くと、どのプロジェクトからでも使えます。
また、組み込みの @plugin-creator スキルを使うと、ローカルプラグインのスキャフォールドを素早く作成できます。 「ゼロから自分でフォルダ構成を作るのは面倒」という場合は、これを使うのが現実的です。
実際の開発現場での活用シナリオ
シナリオ1：チーム標準のコードレビューを自動化
コードレビューの観点がメンバーごとにバラバラ、という問題はどの現場でも起きています。「このレビュアーはセキュリティに厳しいが、あの人はパフォーマンスしか見ない」という状況です。
プラグインを使えば、こんな構成が作れます。
review-plugin/
├── .codex-plugin/
│ └── plugin.json
└── skills/
└── code-review/
└── SKILL.md ← チームの標準レビュー観点を記述
SKILL.md の中には「セキュリティ：SQLインジェクション、XSSの確認」「パフォーマンス：N+1クエリのチェック」「命名規則：チーム標準に準拠しているか」などを書いておきます。
チームメンバーがこのプラグインをインストールすれば、「このPRをチーム基準でレビューして」と一言送るだけで、統一されたレビューが返ってきます。
シナリオ2：マイクロサービス環境でのMCP連携を標準化
複数サービスを扱うチームでは、Codexが参照すべきMCPサーバーの設定もチームで共有したいはずです。GitHubの特定リポジトリ、Jiraの特定プロジェクト、Confluenceのドキュメントスペース——それらへのアクセス設定をプラグインに含めておけば、新しいメンバーが参加したときのオンボーディングが格段に楽になります。
従来は「このURLにMCPサーバーを設定して」「認証はこうやって」と説明する必要がありました。プラグインなら /plugins を開いてインストールするだけです。
シナリオ3：OSS貢献用の特化スキルをプラグイン化
Codexはリファクタリングや移行などの大規模なコード変更をエンドツーエンドで処理できます。 これを特定のOSSプロジェクトに最適化した形でプラグイン化すると、コントリビューターがすぐに生産的に動けます。
たとえばDjangoやRailsのOSSプロジェクトなら、「このプロジェクト固有のコーディング規約」「テストの書き方」「PRのテンプレート」をスキルとして含めたプラグインを用意しておくことで、初めてコントリビュートする人でもCodexを活用しやすくなります。
シナリオ4：Figmaとの連携をプラグインに含める
フロントエンドチームでは、デザインからコードを生成するワークフローが定番化しつつあります。2025年、Codexはスキルとアプリ統合のエコシステムを整備し、モデルと開発者がすでに使っているツールを組み合わせたコーディングプラットフォームとして機能するようになりました。
Figmaとの連携設定をプラグインに含めておけば、「このデザインカンプをReactコンポーネントに変換して」というワークフローをチーム全体で使い回せます。
競合ツールとの比較—Codexプラグインはどこが違うのか
AIコーディングエージェントの比較
| 機能 | Codex（プラグイン込み） | GitHub Copilot | Cursor | Claude Code |
|---|---|---|---|---|
| スキル/指示書のパッケージ配布 | ✅（プラグイン） | ❌ | △（ルールファイル） | △（スキルのみ） |
| MCP設定のバンドル配布 | ✅ | ❌ | ❌ | △（個別設定） |
| チームマーケットプレイス | ✅（ローカル） | ❌ | ❌ | ❌ |
| CLI対応 | ✅ | ✅ | ✅ | ✅ |
| IDE拡張機能 | ✅（VSCode等） | ✅ | ✅（Cursor自体がIDE） | ✅ |
| 非同期バックグラウンド実行 | ✅（Codex Cloud） | ❌ | ❌ | ❌ |
| GitHubネイティブ連携 | ✅ | ✅ | ❌ | ❌ |
スキル仕様のポータビリティ
興味深いのは、スキルのSKILL.mdという仕様は非常に軽量で、どのLLMツールでもファイルシステムの読み書きができれば実装できる点です。Claude CodeとCodexの両方でほぼ同じスキルファイルを使い回せる、というエコシステムが形成されつつあります。
これは将来的に「特定のAIツールへの依存」を減らせる可能性を持っています。プラグインに含まれるスキルファイルは、ツールを乗り換えても再利用できるかもしれません。
従来手法（AGENTS.md）との違い
Codexには以前からAGENTS.mdというファイルで指示を与える仕組みがありました。スキルとプラグインとの違いはどこか、整理すると：
| 仕組み | 主な用途 | スコープ | 配布のしやすさ |
|---|---|---|---|
| AGENTS.md | リポジトリの基本設定・ルール | リポジトリ単位 | コミットするだけ |
| スキル（Skills） | 特定ワークフローの手順書 | プロジェクト・ユーザー | ファイルをコピー |
| プラグイン（Plugins） | スキル＋MCP＋アプリの統合 | チーム・組織 | マーケットプレイス経由 |
AGENTS.mdは「リポジトリ固有のルール」、スキルは「やり方の手順書」、プラグインは「チームの標準装備パッケージ」と考えると整理しやすいです。
プラグインを使う上での注意点と現実的な制約
まだ開発中の機能が多い
公式プラグインディレクトリへの追加や、セルフサービスのプラグイン公開・管理機能はまもなく提供予定とされています。 現時点では、ローカルマーケットプレイス経由での社内共有が現実的な使い方です。
つまり「OSSのプラグインを検索してインストール」という体験はまだ限定的で、社内で作ったプラグインを同じチームで使い回す、というユースケースが今のメインです。
セキュリティの考慮
プラグインには.mcp.jsonで外部サーバーへの接続設定を含められます。これは強力な機能ですが、見知らぬ誰かが作ったプラグインをそのままインストールするのはリスクがあります。
- プラグインに含まれるMCPサーバーが正規のものか確認する
- スキルの指示書の内容を読んでから有効化する
- 社内配布プラグインは信頼できるメンバーがレビューする体制を整える
ユーザーは引用、ターミナルログ、テスト結果を通じてCodexの作業を確認できます。統合や実行の前に、エージェントが生成したコードを手動で確認・検証することは依然として重要です。
Windows環境でのサポート状況
Codex VS Code拡張機能はmacOSとLinuxで動作します。Windowsサポートは実験的段階です。最良のWindows体験にはWSL（Windows Subsystem for Linux）ワークスペースを推奨します。
Windowsユーザーがチームにいる場合は、WSLの事前セットアップが必要になる点は覚えておいてください。
プラグインのバージョン管理
プラグインを社内で配布する場合、plugin.json の version フィールドを適切に管理することが大切です。バージョンが変わったとき、インストール済みのプラグインをどう更新するか、チームの運用ルールを事前に決めておくと後々楽になります。
最初のプラグインを作ってみる—実践的な手順
ステップ1：フォルダ構造を作る
mkdir -p my-team-plugin/.codex-plugin mkdir -p my-team-plugin/skills/code-review
ステップ2：マニフェストを書く
my-team-plugin/.codex-plugin/plugin.json:
{ "name": "my-team-plugin", "version": "1.0.0", "description": "チーム標準の開発ワークフロー", "skills": "./skills/" }
ステップ3：スキルを書く
my-team-plugin/skills/code-review/SKILL.md:
--- name: code-review description: チームのコーディング規約に基づいてコードレビューを行う --- 以下の観点でコードレビューを実施してください： 1. セキュリティ：入力値のバリデーション、SQLインジェクション、XSSの有無 2. パフォーマンス：N+1クエリ、不要なループ処理 3. 命名規則：チームのコーディングガイドに準拠しているか 4. テストカバレッジ：主要なケースが網羅されているか 5. エラーハンドリング：例外処理の適切さ
ステップ4：ローカルマーケットプレイスに登録する
リポジトリのルートに .agents/plugins/marketplace.json を作成：
{ "name": "team-marketplace", "plugins": [ { "name": "my-team-plugin", "source": { "source": "local", "path": "./my-team-plugin" }, "policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" }, "category": "Productivity" } ] }
ステップ5：Codexを再起動して確認
Codexを再起動してプラグインディレクトリを開くと、作成したプラグインが表示されます。インストールしてから $.code-review と入力すればスキルが使えます。
@plugin-creator スキルを使えばこの手順の大部分を自動化できます。まずCodexを起動して「@plugin-creator 新しいプラグインを作って」と指示してみてください。
まとめ—プラグインはチームの「開発文化をコード化」する手段
Codexのプラグイン機能を一言で言うなら、「チームの開発ノウハウをインストール可能な形にする仕組み」です。
スキルを書けば、ベテランの暗黙知をAIへの指示書として形式化できます。それをプラグインにパッケージ化すれば、新入りメンバーでも即日から同じクオリティで動けます。MCPサーバー設定を含めれば、GitHubやJiraとの連携設定も一緒に配布できます。
まだ公式のプラグインディレクトリは整備中ですが、社内での活用は今日から始められます。まず小さなスキルを1つ書いてプラグイン化してみるところから、チームの標準化が始まります。
個人的には、スキルファイルが他のAIツールでも使い回せるオープンな仕様になっている点が好きです。特定のツールに縛られずに、チームのノウハウを蓄積していける方向性は、長期的に見ても理にかなっていると思います。
