AIコーディングエージェント 2026.05.31 更新: 2026.06.01

CodexのSkills・Plugins・Subagents・MCPをチームで使う前に：手順・配布・分担・外部接続の分け方

3行まとめ

VisualCodex拡張の4つの責務手順、配布、分担、外部接続を分けます。

Skills

作業手順を読む。

Plugins

まとめて配る。

Subagents

調査を分担。

MCP

外部toolへ接続。

最初に責務を分けると、権限とレビューを決めやすくなります。

CodexのSkills、Plugins、Subagents、MCPは、まとめて「便利な拡張」として扱わず、手順、配布、分担、外部接続に分けます。
繰り返す作業手順はSkills、複数のSkillsやApp連携やMCP serverをまとめて配るならPlugins、広い調査や別観点の確認はSubagents、外部toolや共有情報への接続はMCPとして見ます。
チーム導入では、機能を増やす前に、permissions profile、approval policy、skill approval、MCP elicitation、network allowlist、secretの扱いを決めます。

本文の事実確認には、OpenAI DevelopersのSkills、Plugins、Subagents、MCP、Agent approvals & security、Permissionsを使っています。Xで見かけるCodex拡張やチーム運用への関心は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Visual導入前に決める項目チームで迷いやすい判断です。

Where

どこに手順を置くか。

Package

何をpluginに含めるか。

Delegate

何をsubagentへ渡すか。

Permission

外部接続をどう制限するか。

便利な部品を増やす前に、運用上の置き場所を決めます。

CodexのSkills、Plugins、Subagents、MCPをどう分けて使うか
Skillに書くべき手順と、AGENTS.mdに残すべきルールの違い
Pluginを入れる前に、Skills、Apps、MCP serversを分解して見る理由
Subagentsを調査やレビュー補助に使い、責任分散にしない考え方
MCPを外部tool権限として扱い、read-onlyから始める手順
permissions profileとapproval policyをチーム導入時にどう固定するか

Codexは、単体でもコード調査、編集、テスト、レビュー補助を進められます。そこへSkills、Plugins、Subagents、MCPを足すと、繰り返し作業を型にしたり、外部ツールへ接続したり、調査を分担したりできます。

ただし、全部を一度に入れると、どこに手順があるのか、どこから外部権限なのか、誰が結果をレビューするのかが見えにくくなります。チームで使うなら、機能名ではなく責務で分ける方が安全です。

前提知識

Visual公式docsで見る対象この記事で扱うCodex機能です。

項目	内容	見方
Skills		SKILL.mdと補助file。
Plugins		skills、apps、MCPをbundle。
Subagents		別観点の作業分担。
MCP		外部toolと情報源。

Codexの拡張は、作業手順と外部権限を分けて理解します。

OpenAI DevelopersのSkills docsでは、Skillは名前、説明、file pathから始まり、必要になった時にCodexがSKILL.mdを読む仕組みとして説明されています。Skill directoryには、必須のSKILL.mdに加えて、scripts、references、assets、agentsを置けます。

Plugins docsでは、PluginはSkills、Apps、MCP serversをbundleし、Codexで再利用できるworkflowにするものと説明されています。たとえば、GitHub、Slack、Google Driveのような外部serviceへつなぐAppや、追加toolを提供するMCP serverを含められます。

Subagents docsでは、Codexが別の作業単位を立て、広い調査や別観点のレビューを分ける用途が扱われています。これは、人間のレビューを消すためではなく、情報を整理して親threadへ戻すための仕組みとして考えます。

MCP docsでは、CodexへMCP serverを設定し、command、args、env、OAuth callbackなどを扱う方法が説明されています。MCPは便利な連携口ですが、外部toolや共有情報へ触れる入口でもあります。

この記事の扱う範囲

項目	役割
Skills	繰り返す作業手順、参照資料、補助scriptをまとめる
Plugins	Skills、Apps、MCP serversをbundleして配布する
Subagents	広い調査、ログ整理、別観点レビューを分担する
MCP	外部tool、社内情報、共有contextへの接続口
Permissions	filesystem、network、workspace、deny ruleを固定する
Approval	sandbox、MCP、request_permissions、skill scriptなどを止める条件

2026年6月1日時点で公開されているOpenAI公式Docsを確認しています。導入時には、利用中のCodex app、CLI、plugin、組織のmanaged configuration、permissions profileを改めて確認してください。

注意点

この記事は、Codexへ大量のPluginやMCPを入れるための記事ではありません。むしろ、どこまでを手順化し、どこから権限拡張として扱うかを切り分けるための記事です。

まず4つの責務に分ける

Visual責務別の置き場所最初の分類です。

項目	内容	見方
手順		SkillまたはAGENTS.md。
配布		Plugin。
分担		Subagent。
接続		MCPまたはApp。

分類が決まると、レビュー対象もはっきりします。

最初に、Codexの拡張を4つの責務に分けます。

責務	主な置き場所	例
手順	Skills / AGENTS.md	リリース手順、記事生成手順、レビュー手順
配布	Plugins	Skills、Apps、MCPをまとめて導入
分担	Subagents	広い調査、ログ分析、別観点レビュー
外部接続	MCP / Apps	GitHub、Slack、Drive、社内API

この分類を先に置くと、会話が楽になります。「Pluginを入れたい」ではなく、「これは手順なのか、外部接続なのか、配布単位なのか」と聞けるからです。

最初の判断

まず、チームで繰り返す作業かを見ます。毎回同じ手順で記事を作る、PRレビューする、リリースノートを書く、QAを回すならSkill候補です。

次に、配布したい単位かを見ます。Skillだけで足りるならPluginにしません。複数のSkills、外部App、MCP serverをまとめて入れる必要が出てからPluginにします。

さらに、作業を分ける必要があるかを見ます。大きな調査、複数ファイルのレビュー、長いログ分析はSubagentに向きます。最後に、外部serviceや社内情報へ接続するならMCPやAppとして権限を見る、という順番です。

混ぜると起きる問題

責務を混ぜると、レビュー対象がぼやけます。たとえば、あるPluginにSkill、App、MCP serverが入っている時、「便利そうだから入れる」だけでは、どの外部serviceへ接続し、どのtoolが実行でき、どの手順が自動で読まれるのかが分かりません。

チームでは、導入前に1枚の表へ分解します。

確認項目	見ること
Skill	何の手順を読ませるか
App	どの外部serviceへ接続するか
MCP	どのtoolを使えるか
Script	ローカルで何を実行するか
Approval	どこで人間確認へ戻すか

この表が作れないなら、まだチーム導入には早いです。

Skillsは作業手順として使う

VisualSkillに入れるもの再利用したい手順です。

Steps

決まった作業順。

Scripts

補助実行file。

References

必要な資料。

Assets

templateや素材。

Skillは作業の型であり、無制限の権限付与ではありません。

Skillsは、Codexへ「この種類の作業では、この手順で進めてほしい」と伝えるための置き場所です。OpenAI docsでは、Skillはdirectoryで、SKILL.mdを必須にし、scripts、references、assetsなどを置けると説明されています。

Skillのよいところは、最初から全文をcontextへ入れないことです。CodexはまずSkillのname、description、file pathを見て、必要になった時にSKILL.mdを読みます。これにより、長い手順を常にプロンプトへ貼る必要が減ります。

SKILL.mdに残すもの

Skillへ入れるのは、作業の型です。

入れるもの	例
発動条件	どんな依頼でこのSkillを使うか
手順	調査、編集、検証、報告の順番
helper script	毎回使う検証scriptや変換script
references	仕様書、チェックリスト、社内docs
assets	template、雛形、画像素材

たとえば、WordPress記事公開、TestFlight upload、Git commit作成、Japanese rewriteなど、同じ流れを何度も回す作業はSkillに向きます。

AGENTS.mdと分ける基準

AGENTS.mdはrepoの作業ルールです。Skillは作業種類ごとの手順です。ここを混ぜると、repo固有の禁止操作と、横断的なworkflowが混ざります。

目安はこうです。

置き場所	向いている内容
AGENTS.md	このrepoで守るルール、禁止操作、テスト、UI方針
Skill	ある種類の作業で毎回使う手順、script、reference
Prompt	その場限りの依頼条件

チームでCodexを使うなら、AGENTS.mdに「このrepoでは何をしてよいか」を置き、Skillに「この作業ではどう進めるか」を置くと整理しやすいです。AGENTS.mdの整備は、チーム向けAGENTS.mdテンプレートの記事と合わせて見ると流れがつかめます。

Pluginsは配布単位として扱う

VisualPluginに含まれるものまとめて導入する単位です。

項目	内容	見方
Skills		再利用手順。
Apps		外部サービス接続。
MCP servers		追加toolや情報源。
Policy		install前の確認。

Pluginは便利なbundleなので、含まれる権限を分解して確認します。

Pluginsは、Codexへ機能をまとめて追加する配布単位です。OpenAI Developersでは、PluginsがSkills、App integrations、MCP serversをbundleできると説明されています。

つまり、Pluginは単なる手順集ではありません。中に外部serviceとの接続やMCP serverが含まれる場合があります。チームで入れる前に、内容を分解して見ます。

pluginへ含めるもの

含まれるもの	確認すること
Skills	どの手順が有効になるか
Apps	どの外部serviceへ接続するか
MCP servers	どのtoolや情報源が増えるか
Scripts	何がローカルで実行されるか
Assets	どのtemplateや素材を使うか

たとえば、GitHub pluginならrepository、issue、pull requestを扱う文脈が出ます。Google Drive pluginならDrive、Docs、Sheets、Slidesなどの情報を扱う可能性があります。Slack pluginならchannel summaryやreply draftのような作業が想定されます。

install前の確認

Pluginを入れる前に、次の質問へ答えます。

何の作業を短くするために入れるのか
どの外部serviceへ接続するのか
read-onlyで足りるのか、write actionが必要なのか
どの人、repo、workspace、channelへ影響するのか
失敗時に誰が止めるのか

この確認を飛ばすと、Pluginが増えるほど権限の棚卸しが難しくなります。最初は、Skillだけで足りる作業をSkillにし、外部接続が必要になった段階でPluginを検討する方が安全です。

Subagentsは調査と分担に使う

VisualSubagent向きの作業並行しやすい調査です。

Review

別観点の確認。

Research

広い調査。

Triage

logや失敗原因の整理。

Summary

親threadへ結論を返す。

Subagentは責任を薄めるためではなく、調査を整理するために使います。

Subagentsは、広い調査や別観点の確認を分けるために使います。大きなrepoの影響調査、長いログの整理、複数候補の比較、レビュー観点の分担などでは有効です。

ただし、Subagentを使うと、最終責任が薄まるわけではありません。親threadで結論を統合し、人間が読むべき判断材料へまとめる必要があります。

向いている作業

Subagentに向いているのは、並行しやすく、結論を短く戻せる作業です。

作業	Subagentに渡す理由
影響範囲調査	呼び出し元、関連file、テスト範囲を別に見る
ログ分析	長いCI logから失敗原因候補を絞る
PRレビュー	セキュリティ、テスト、互換性など観点を分ける
仕様比較	複数docsやrelease noteを分担して読む

依頼時には、owner、inputs、expected output、done conditionを明確にします。「調べて」ではなく、「このfile群を見て、破壊的変更候補を3つ以内で返す」のように終わりを決めます。

任せない作業

Subagentに向かないのは、細かい編集と検証を何度も往復する作業です。実装中の小さな修正、test failureを見ながら即座に直す作業、ユーザー判断が頻繁に必要な作業は、親threadで扱う方が速いことがあります。

また、Subagentの出力をそのまま公開判断にしません。結論、根拠、不確実な点、残ったリスクを親threadで確認します。

MCPは外部toolへの権限として見る

VisualMCP確認項目外部接続の入口です。

項目	内容	見方
Command		起動方法。
Env		渡す環境変数。
OAuth		loginとcallback。
Tools		read/writeを分ける。

MCPを入れる時は、何が読めて何が実行できるかを先に見ます。

MCPは、Codexに外部toolや共有情報を渡す入口です。OpenAI DevelopersのMCP docsでは、[mcp_servers.<name>]にcommand、args、envなどを設定し、OAuth callback portやcallback URLも扱えることが説明されています。

MCPを「便利な追加機能」とだけ見ると危険です。MCP serverは、file、ticket、database、browser、cloud、社内APIなどへつながる可能性があります。どのtoolがread-onlyで、どのtoolがwriteできるかを必ず分けます。

OAuthとenv

MCP serverには、OAuth loginや環境変数が絡むことがあります。設定例でも、command、args、env_vars、env、OAuth callbackに関する項目が出ます。

チームでは、次を確認します。

項目	確認すること
command	何を起動するか
args	どのpackageやserverを呼ぶか
env_vars	どの環境変数を渡すか
OAuth	誰のaccountでloginするか
callback	localhostか、remote ingressか
scopes	server-advertised scopesと設定値

秘密情報や個人accountを雑に渡さないことが大事です。MCP serverの設定は、repoの依存関係と同じくらいレビュー対象になります。

read-onlyから始める

最初のMCPはread-onlyから始めます。issueを読む、docsを検索する、ticketを一覧する、metadataを見る、といった用途です。PR作成、ticket更新、file書き込み、production system変更は、別の承認を挟みます。

Codexの外部通信やMCP権限全般は、Codexにインターネットアクセスを許可する前の記事にも近いです。外部接続は、使えるかどうかではなく、どこまで許可するかで考えます。

チーム導入時の権限チェック

Visual権限チェック公開前に固定する項目です。

項目	内容	見方
Filesystem		read/write/deny。
Network		domain allowlist。
Approval		止める操作。
Skill/MCP		承認対象を分ける。

権限はあとから雰囲気で広げず、profileとして固定します。

Skills、Plugins、Subagents、MCPを入れる前に、permissionsとapprovalを固定します。OpenAI DevelopersのPermissions docsでは、filesystemのread/write/deny、networkのdomain allow/deny、workspace roots、local/private network guardなどが説明されています。

Agent approvals & security docsでは、approval policy、sandbox mode、granular approval policy、auto-reviewなどの組み合わせが扱われています。skill approvalやMCP elicitationも、承認対象として分けられます。

permissions profile

Permissions profileでは、まずread/write/denyを分けます。例として、repoはwriteできるが.envはdeny、networkはapi.openai.comと*.github.comだけallow、といった形です。

項目	最初の方針
filesystem	workspace内だけwrite、secret fileはdeny
network	必要domainだけallow
local network	localhostは明示的に扱う
Unix socket	Dockerなどは必要時だけ
global `*`	public web accessを意図する時だけ

Permissions docsでは、denyがwriteやreadより優先されること、network domainsにはallow/denyを設定できることも説明されています。広く許可してから注意するより、狭く始めて足りないものを足す方がレビューしやすいです。

approval policy

approval policyは、Codexの自律性を決めます。neverにすると承認promptなしで進みますが、sandboxの範囲とは別の話です。チーム導入では、read-only調査、workspace write、network access、MCP action、skill script実行を別々に考えます。

初期設定の例はこうです。

作業	方針
調査	read-only中心
小さな編集	workspace write
network	allowlist domainだけ
MCP write tool	人間承認
skill script	内容を確認してから

granular approval policyを使う場合は、sandbox approval、rules、MCP elicitation、request permissions、skill approvalを分けて考えます。どれを自動にし、どれを人間へ戻すかを、チームで明文化します。

導入初週の進め方

Visual1週間の導入順小さく試して広げます。

1日目
AGENTS.mdと既存手順を棚卸し。
2日目
1つだけSkill化。
3日目
Subagentへ調査だけ渡す。
5日目
Plugin候補の中身を確認。
7日目
MCPはread-onlyから試す。

初週は機能追加より、レビューできる置き場所を作ります。

初週は、いきなりPluginやMCPを増やさず、既存の作業を棚卸しします。

日	やること
1日目	AGENTS.md、既存手順、よく頼む作業を一覧する
2日目	1つの繰り返し作業だけSkillにする
3日目	Subagentへ調査だけ渡し、出力形式を固定する
4日目	permissions profileでsecret fileとnetworkを絞る
5日目	Plugin候補をSkills、Apps、MCP serversへ分解する
7日目	MCPをread-only用途で1つだけ試す

この順番なら、いきなり外部接続を増やさず、レビューしやすい型から始められます。Codex全体の導入設計は、Codex 101の記事と合わせて読むと、権限、AGENTS.md、評価タスクまでつながります。

また、ブラウザ操作やログイン済みChromeの扱いは、Codexにログイン済みChromeを渡す前の記事で別に整理しています。SkillsやPluginsを入れる前に、見せる情報の範囲も決めておきます。

FAQ

Visualよくある迷いCodex拡張で詰まりやすい点です。

Skill?

繰り返す手順。

Plugin?

配布したいbundle。

Subagent?

分担したい調査。

MCP?

外部tool接続。

迷ったら、権限が増えるかどうかを先に見ます。

SkillとAGENTS.mdはどちらを優先しますか？

役割が違います。AGENTS.mdはrepo固有のルール、Skillは作業種類ごとの手順です。このrepoで守る禁止操作やテストはAGENTS.md、WordPress公開やTestFlight uploadのような横断workflowはSkillに向きます。

PluginはSkillの上位互換ですか？

そうではありません。PluginはSkills、Apps、MCP serversをまとめられる配布単位です。Skillだけで足りるならPlugin化しなくてよいです。外部serviceやMCPが含まれるなら、導入前に権限を分解して確認します。

Subagentを使えばレビューを省けますか？

省けません。Subagentは調査や観点分担には向きますが、最終判断は親threadと人間レビューに戻します。Subagentの出力は、結論、根拠、未確認点へ整理して扱います。

MCPはいつ入れるべきですか？

外部toolや共有情報が本当に必要になってからです。最初はread-onlyで始め、write tool、ticket更新、PR作成、production接続は別承認にします。MCPは便利な拡張ではなく、外部権限として扱います。

次に読むなら

Codex 101をチーム導入に使う

Codex全体の権限、AGENTS.md、評価タスクを決める時に読みます。

チーム向けAGENTS.mdテンプレート

repo固有ルールとSkillの置き場所を分けたい時に使えます。

Codexにインターネットアクセスを許可する前に

MCPや外部通信を許可する前に、domain allowlistと承認境界を整理できます。

Codexにログイン済みChromeを渡す前に

PluginやMCPと合わせて、ブラウザ上で見せる情報の範囲も決めたい時に読みます。

参照した主な情報源

https://developers.openai.com/codex/skills
https://developers.openai.com/codex/plugins
https://developers.openai.com/codex/subagents
https://developers.openai.com/codex/mcp
https://developers.openai.com/codex/agent-approvals-security
https://developers.openai.com/codex/permissions

更新履歴

Visual確認と更新の記録Codex機能は更新されるため確認日を残します。

2026年6月1日
OpenAI DevelopersのSkills、Plugins、Subagents、MCP、Permissions、Securityを確認して初版を作成しました。

導入時には利用中のCodex app、CLI、plugin、permissions設定を確認してください。

2026年6月1日: OpenAI DevelopersのSkills、Plugins、Subagents、MCP、Agent approvals & security、Permissionsを確認して初版を作成しました。