先に結論
いちばん重要なのは、Codex Plugins が出たからといって、MCP・Composio・skills が全部同じものになったわけではないことです。
役割を先に切ると、こうです。
- Codex Plugins: skills / app integrations / MCP configs を ひとつの installable bundle として配る
- MCPサーバー: agent に 外部ツールやデータへ触る能力を渡す
- Composio: 認証・接続・observability を含む managed integration plane を使う
- skills-only: 単一repo / 単一runtime で 軽く再利用する
なので選び方はかなりシンプルです。
- 同じ workflow をチームや複数repoへ配りたい → Codex Plugins
- ツール接続を標準化したい → MCPサーバー
- auth / token / 監査を自前で持ちたくない → Composio
- まだ1人 or 1repo で回っている → skills-only
つまり、比較の主語は「どれが一番賢いか」ではなく、workflow をどの粒度で、どこまで責任込みで配るかです。
より抽象的に agent portability を整理したいなら GitAgent vs OpenClaw Skills vs MCPサーバー が先です。MCP と Composio の運用差を業務ツール連携で見たいなら Google Workspace CLI vs Composio vs MCP server vs 直接Google API がつながります。plugin と MCP の責務差を別角度で見たいなら Vercel plugin vs MCPサーバー vs 素のcoding agent も近いです。
なぜ今この比較が重要か
2026-03-26 に OpenAI は Codex Plugins を docs / changelog で前面化し、plugins are installable bundles for reusable Codex workflows と明示しました。公式 docs では、plugin は skills、optional app integrations、MCP server configurations を1か所にまとめ、share the same setup across projects or teams するための仕組みとして説明されています。
ここで重要なのは、Codex Plugins が単なる「新しい connector 形式」ではないことです。
従来の現場では、こう分裂しやすかったです。
- instructions や skills は repo ローカルに置く
- MCP server は別途設定する
- SaaS 認証や token 管理は Composio 側で持つ
- チーム展開は README と口頭で頑張る
この状態だと、接続面はあるのに配布単位がない か、逆に 配布はしているが auth / governance が弱い になりやすいです。
Codex Plugins が埋めに来たのは、この「再利用できる workflow を、installable な形で配る」隙間です。
だから今の論点は、
- plugins で bundle するべきか
- MCP をそのまま見せるべきか
- Composio の managed plane に寄せるべきか
- skills-only のまま軽く回すべきか
を、個人利用 / チーム標準化 / enterprise 統制 の文脈で切り分けることです。
比較表
| 比較軸 | Codex Plugins | MCPサーバー | Composio | skills-only |
|---|---|---|---|---|
| 主な役割 | workflow の配布単位 | 外部能力の接続面 | managed integration plane | repo / runtime 内の軽量再利用 |
| 何を持てるか | skills、apps、MCP configs、manifest、marketplace metadata | tools、resources、prompts | auth、connector、logs、governance | instructions、rules、手順 |
| 配布性 | 高い | 中 | 中 | 低〜中 |
| 接続性 | 単体では接続面ではない | 高い | 高い | 低い |
| 可搬性 | Codex エコシステム内で高い | client 次第 | platform 依存あり | runtime 依存が強い |
| reviewability | manifest / folder ごと review しやすい | server 実装次第 | SaaS 設定が混ざる | 非常に高い |
| 導入難易度 | 中 | 中 | 低〜中 | 最低 |
| 向いている場面 | team 標準化、再利用 bundle 化 | 外部システム接続の標準化 | auth / 監査込みで早く出したい | 1repo / 1workflow の試行 |
4つの違いを先に整理する
Codex Plugins は「配布単位」を作る
OpenAI の plugin docs では、Codex Plugins は installable bundles for reusable Codex workflows とされています。さらに plugin は次の3要素を1つのパッケージに含められます。
- Skills: workflow を記述する prompt / instructions
- Apps: app integrations や connector mappings
- MCP servers: remote tools や shared context の設定
つまり Codex Plugins の本質は、MCP や skills の代替ではありません。skills・apps・MCP config をまとめて、プロジェクト横断・チーム横断で再利用できる配布単位にすることです。
ここが刺さるのは次のようなケースです。
- 同じ workflow を複数repoで使いたい
- チームの onboarding で、同じ setup を installable にしたい
- local skill から一段上げて versioned package にしたい
- MCP config や app integration を README ではなく bundle として渡したい
公式 docs でも、1 repo / 1 workflow の試行段階では local skills、共有したくなったら plugin という整理が明示されています。これはかなり実務的です。
MCPサーバーは「接続面」を作る
MCPサーバーがやるのは、agent に 何へ触れられるか を増やすことです。
- GitHub を読む
- Slack を触る
- DB を参照する
- 社内 API を叩く
- design system や docs を shared context として渡す
ここでの役割は、あくまで connection layer です。
重要なのは、MCPサーバー単体では その設定をどう team に再配布するか までは解決しないことです。もちろん repo に config を置けば共有はできますが、Codex Plugins のように marketplace や install surface まで含んだ「配布プロダクト」には自動でなりません。
なので、MCP は強いが、それ自体は workflow package ではない と見るのが正確です。
Composio は「managed integration」を買う
Composio は、MCP のような標準接続そのものより、認証・token lifecycle・connector 管理・observability を外出しする 価値が大きいです。
つまり Composio の主語は、
- どの SaaS にどう接続するか
- 認証や接続状態をどう運用するか
- 実行ログや governance をどう確保するか
です。
この意味で Composio は、Codex Plugins と競合しきりません。むしろ、Composio で接続面を安定化し、それを plugin や repo 標準の一部として配る という組み合わせも成立します。
逆に、Composio だけでは skills や app-aware workflow の bundle 配布まで綺麗に揃うとは限りません。Composio は「接続運用を楽にする」側で、Codex Plugins は「workflow を installable に配る」側です。
skills-only は「最小構成」で試す
skills-only が向くのは、まだ workflow が固まっていないときです。
- 1つの repo だけで使う
- 1人 or 少人数だけが使う
- まだ connector や MCP config を bundle にするほどではない
- 実験の回転数を優先したい
この段階で最初から plugins や managed integration まで持ち込むと、何が効いたか見えにくくなります。
OpenAI の docs が Start local, then package the workflow as a plugin when you are ready to share it と書いているのは、かなり筋がいいです。最初は skills-only、共有の必要が出たら plugins、接続運用が重くなったら MCP / Composio を足す、という順番がいちばん失敗しにくいです。
個人利用 / チーム / enterprise での選び方
個人利用
個人開発や検証なら、まず skills-only で十分なことが多いです。
理由は単純で、配布先が自分だけなら install surface を整えるより、workflow そのものを磨く方が価値が高いからです。
ただし次の状態になったら plugin 化を考える価値があります。
- 複数repoへ同じ setup を入れ始めた
- MCP config や app integration を毎回手で持ち込んでいる
- 将来 team に渡す前提で versioned package にしたい
チーム標準化
チームに入ると Codex Plugins が一気に強くなります。
なぜなら、単なる「サンプル設定」ではなく、installable / versioned / reviewable な配布単位 が欲しくなるからです。
- onboarding を短くしたい
- repo ごとの差分を減らしたい
- skills と MCP config を別々に説明したくない
- 誰が何を install しているかを揃えたい
この段階では、plugins が最も自然です。MCP server は必要でも、MCP 単体では team 配布の UX が弱いことが多いです。
enterprise 統制
enterprise では Composio + plugin か MCP + plugin の組み合わせが現実的です。
見るべき論点は、
- auth を誰が持つか
- token rotation を誰が面倒みるか
- 実行ログと監査をどこで見るか
- self-hosted をどこまで許容するか
です。
認証や監査を platform 側へ寄せたいなら Composio が強く、社内規制や独自接続を優先するなら self-hosted MCP が残ります。その上で、利用者へどう配るか は plugin 側で整理する、という二層構造がわかりやすいです。
lock-in / 可搬性 / reviewability でどう見るか
ここは感覚ではなく、かなり明確に分けた方がいいです。
lock-in
- skills-only は runtime lock-in が強い
- Codex Plugins は Codex エコシステム前提なので surface lock-in がある
- MCP は接続規格として比較的中立
- Composio は platform lock-in を受け入れて運用負荷を下げる発想
可搬性
可搬性を一番高くしたいなら、MCP や repo rules 側に寄せたくなります。ただし、それだけだと installable workflow にはなりません。
逆に Codex Plugins は可搬性よりも Codex 内での共有再現性 を強くします。ここは portability の種類が違います。
reviewability
レビューしやすさでは、skills-only と plugins が強いです。どちらもファイルとして差分を見やすいからです。MCP は server 実装と config が分かれやすく、Composio は UI / SaaS 設定が混ざるぶん、Git diff だけでは追い切れないことがあります。
じゃあ実務ではどう選ぶか
迷ったらこの順番で十分です。
- 1repo / 1workflow なら skills-only で始める
- 再利用したくなったら Codex Plugins に昇格する
- 外部能力が必要なら MCP を足す
- auth / 監査 / 運用が重くなったら Composio を検討する
この順番の良さは、最初から複雑にしすぎないことです。
特に今回の Codex Plugins で変わったのは、MCP や skills をバラで配る必要がなくなりつつあることです。接続面・workflow・app integration を bundle にして「これを入れれば同じ setup になる」と言えるようになったのは大きいです。
どの読者にどれが向くか
- 個人で Codex workflow を試している → skills-only
- 同じ workflow を複数repo / 複数人へ配りたい → Codex Plugins
- ツール接続の標準化を最優先したい → MCPサーバー
- 認証・監査・運用の手間を先に減らしたい → Composio
関連記事として、runtime 自体の比較は open-swe vs Claude Code vs Codex vs GitHub Copilot coding agent、Codex 周辺の意思決定は Composer 2 vs Claude Code vs Codex vs GitHub Copilot、MCP と portability の切り分けは GitAgent vs OpenClaw Skills vs MCPサーバー がつながります。
参考にした一次情報
- OpenAI Codex Plugins docs（plugins are installable bundles for reusable Codex workflows、skills / apps / MCP servers を package できる点）
- OpenAI Codex changelog 2026-03-26（plugins are now a first-class workflow）
- OpenAI まわりの公開報道（Codex app / CLI / IDE 拡張まで跨いで plugin が使える点、curated directory と marketplace の説明）
まとめ
Codex Plugins が出たことで、やっと workflow を installable に配る単位 がはっきりしました。
ただし、それで MCP や Composio や skills が不要になるわけではありません。
- Codex Plugins は配布単位
- MCPサーバー は接続面
- Composio は managed integration
- skills-only は最小構成
この切り分けで見ると、何を bundle 化し、何を接続面に残し、何を運用サービスへ逃がすべきかがかなり見えやすくなります。
最初の一歩としては、1repo なら skills-only、共有したくなったら plugin、接続が必要なら MCP、運用が重ければ Composio。これがいちばん実務的です。