Codex を触っていると、plugin と skill が同時に出てきて混乱しやすいです。どちらも「Codex を強くする機能」に見えますが、役割は同じではありません。ここを曖昧にすると、外部接続したいだけなのに skill を増やしたり、逆に社内手順を固定したいのに plugin を先に作って運用が重くなります。
この記事は、Codex で plugin と skill をどう切り分けるかを実務目線で整理したい人向けです。skill 自体の設計を深掘りしたいなら Codex Skills 設計入門、定期実行まで含めて考えたいなら Codex Automations 実践ガイド、並列 worktree 運用まで広げたいなら Codex 複数エージェント運用ガイド を先に読むとつながります。
先に結論: plugin は「外部接続と配布単位」、skill は「再利用する仕事の型」
2026年5月12日時点で一番分かりやすい整理はこれです。
- plugin: Codex を別のツールやデータソースにつなぐ。加えて、skills や MCP 設定や app 連携を束ねて配布できる
- skill: Codex に「この仕事はこの順番でやる」と教える再利用ワークフロー
OpenAI Academy の説明もかなり明快で、別ツールの情報が必要なら plugin、あなたやチームの進め方を守らせたいなら skill、両方必要なら併用という整理です。
私なら、最初の判断を次の3問で切ります。
- 外部サービスや別アプリの情報が必要か
- 毎回同じ手順や出力形式を守らせたいか
- 個人用メモではなく、チームで再利用・配布したいか
1だけが yes なら plugin 寄り、2だけが yes なら skill 寄り、1と2が両方 yes なら plugin と skill の組み合わせです。3 が強いなら、skill 単体より plugin という配布単位まで考えた方がよいです。
plugin は「道具そのもの」ではなく「接続面と配布面のパッケージ」
plugin を単なる外部連携ボタンだと思うと、少し理解がずれます。OpenAI の openai/plugins リポジトリでは、plugin は必須の manifest を持ちつつ、必要に応じて skills/、.mcp.json、.app.json、agents/、commands/、hooks.json、assets/ まで同梱できる前提で整理されています。
つまり plugin は、「Codex を何につなぐか」だけでなく、その接続をどう配るか の単位でもあります。
たとえば plugin が向くのは次のような場面です。
- Google Drive や Notion や GitHub など、別ツールの情報を直接読ませたい
- MCP サーバー設定や app 連携をチームへまとめて配りたい
- 特定の workflow で必要な skills や commands も一緒に配布したい
- repo をまたいで同じ拡張セットを再利用したい
ここで重要なのは、plugin 自体が「手順」を主役にしているわけではないことです。plugin の主役は接続と配布です。手順や判断基準まで強く固定したいなら、中に skill を持たせるか、別 skill と組み合わせる必要があります。
skill は「こう進める」を固定する再利用ワークフロー
一方で skill は、OpenAI Academy と Help Center の説明どおり、再利用できる作業手順です。instructions、例、必要ならコードや supporting resources を持てますが、中心にあるのは「この仕事をどう進めるか」です。
このブログでも繰り返し書いているとおり、skill の価値は万能化ではありません。私が skill にする基準はかなり単純です。
- 同じ種類の依頼が繰り返し来る
- 毎回同じ順番で確認したい
- 出力形式をある程度固定したい
AGENTS.mdに常駐させるには重い
たとえば次は skill 向きです。
- 新規記事テーマの重複チェック
- PR レビュー時の確認観点の固定
- 週次レポートの書式統一
- 社内ガイドラインに沿った文書レビュー
逆に、別ツールの情報取得なしに skill だけで十分な仕事も多いです。たとえば repo 内の frontmatter 点検や、特定形式のレビューは、plugin を作らず skill だけで始めた方が軽いです。ここは Codex Skills 設計入門 で書いた「まず instruction-only で始める」という原則と同じです。
一番多い誤解: plugin と skill は競合ではなく、重ねて使う
plugin と skill を二択で考えると失敗します。公式の整理でも、connected tool の情報を使いながら、自分たちのやり方も守らせたいなら両方を使う 前提です。
実務だと、次のような組み合わせが自然です。
- plugin: Google Drive から最新資料を読む
- skill: その資料をチーム標準の週次レポート形式へまとめる
あるいは、
- plugin: GitHub / issue tracker / docs を参照する
- skill: 障害報告を「影響範囲 / 原因仮説 / 次アクション」の3段で要約する
要するに、plugin は「どこから情報を取るか」、skill は「どう料理するか」です。
実務では AGENTS.md、skill、plugin の3層で切ると安定する
Codex を運用していると、AGENTS.md、skill、plugin の役割が混ざりやすいです。私なら次のように固定します。
| 置き場 | 役割 |
|---|---|
AGENTS.md | 常に守る前提、禁止事項、検証コマンド、ブランチ運用 |
| skill | 特定タスクだけで使う再利用手順 |
| plugin | 外部接続、MCP/app/skills を束ねた配布単位 |
たとえば「記事追加後は pnpm seo:update-llms と pnpm run build を流す」は AGENTS.md です。
「新規記事テーマは keyword-plan と既存記事を照合してから決める」は skill にしやすいです。
「Google Drive や Notion の資料も使って同じ流れを回したい」は plugin を足す判断になります。
この切り分けを先に決めないと、plugin にまで運用ルールを書き込みすぎたり、逆に skill に外部接続の責務まで背負わせたりして破綻します。
plugin を先に作るべきケース
私なら、次のどれかに当てはまったら plugin を先に検討します。
- 外部データがないと仕事が成立しない
- skills だけでなく MCP や app 設定もまとめて配りたい
- 複数 repo / 複数チームで同じ拡張を使いたい
- 個人の試作ではなく、配布単位を最初から意識したい
具体例を挙げると、社内で「ドキュメント参照」「チケット確認」「会議メモ回収」を毎回同じように使うなら、plugin 側で接続面をまとめておく価値があります。その上で、実際の報告書作成や triage 手順は skill に閉じ込めた方が、変更責務が分かれます。
skill を先に作るべきケース
逆に、次のような仕事は skill から始める方が現実的です。
- 入力のほとんどが repo 内か thread 内で完結する
- まずは自分や小チームで運用を固めたい
- 手順は反復するが、外部接続はまだ不要
- 配布より先に description と出力形式を固めたい
ここでいきなり plugin 化すると、まだ揺れている workflow を配布単位で固定してしまいます。これは Codex Skills 記事でも触れた論点ですが、再利用が見える前に配布単位を作ると、改善コストが上がる ことが多いです。
plugin と MCP の関係も分けて考える
MCP が出てくると、さらに混乱しやすくなります。ですが役割は分けられます。
- MCP: 外部ツールやデータへ到達するための接続プロトコル / サーバー
- plugin: その接続や関連 skill や app 面を配布する束
- skill: 接続後にどう仕事を進めるか
たとえば Docs MCP のような read-only 接続を Codex へ追加し、その上で「OpenAI 製品の質問では先に公式 docs を引く」という skill を重ねる、という形はかなり自然です。MCP だけでは仕事の進め方は固定されませんし、skill だけでは外部情報へ届きません。
この視点で見ると、plugin は「MCP の代替」ではなく、MCP を含めた配布面の整理です。
チーム運用で先に決めるべき判断基準
plugin と skill の違いを理解しても、運用に落ちないと意味がありません。私なら、導入時に次の5点を先に決めます。
- どの外部ツール接続が本当に必要か
- どの手順を再利用したいか
- 個人スコープで試すのか、チームへ配るのか
- skill の description をどこまで狭くするか
- plugin に何を同梱し、何を同梱しないか
特に 4 が重要です。skill は description が広すぎると誤発火しやすくなります。逆に plugin は同梱範囲が広すぎると、接続・commands・hooks・skills が全部入りになって、何を入れた plugin なのか分からなくなります。
私ならこう切る: 最初の設計順
新しい workflow を作るとき、私は次の順で考えます。
- まず
AGENTS.mdに置くべき常時ルールを分離する - skill 単体で回せるか確認する
- 外部ツール接続が必要なら plugin で束ねる
- skills / MCP / app / commands を同梱する理由があるか確認する
- 配布範囲が複数 repo / チームに広がってから plugin を育てる
この順番なら、最初から重い構成にしなくて済みます。
まとめ
Codex の plugin と skill は似て見えますが、役割ははっきり分けられます。
- plugin は外部接続と配布単位
- skill は再利用する仕事の型
- 両方必要な場面は普通にある
一番避けたいのは、接続したいだけなのに skill を増やすことと、手順を固定したいだけなのに plugin を先に作ることです。まずは「外部情報が必要か」「手順を固定したいか」「配布したいか」の3点で切れば、大きくは外しません。
次に読む順番としては、skill の中身を詰めたいなら Codex Skills 設計入門、定期実行に広げたいなら Codex Automations 実践ガイド、複数スレッドや worktree まで運用設計を広げたいなら Codex 複数エージェント運用ガイド が自然につながります。