Codex plugins を組織に入れると、最初は「便利な拡張を追加する」だけに見えます。ですが実務では、plugin は skills、apps、MCP tools、browser extension、hooks をまとめて持ち込む入口になります。GitHub や Google Drive を読むだけのつもりが、外部データの同期、provider authentication、action controls、domain restrictions、lifecycle hooks、scheduled task での unattended run まで関係してくる。ここを曖昧にすると、便利な workflow がそのまま権限の抜け道になります。
この記事では、Codex の plugin governance に絞って整理します。plugin と skill の基本的な違いは Codex Plugins と Skills の違い、skill の作り方は Codex Skills 設計入門、定期実行で使う設計は Codex Automations 実践ガイド、組織ルール全体は AIコーディングツールの社内ガイドライン に分けています。
今回は「plugin を作る方法」ではなく、workspace admin / owner がどの plugin を誰に使わせ、どの underlying app permission まで許すかを扱います。
先に結論: plugin は機能単位ではなく許可単位で見る
私なら、Codex plugin を導入するときは名前や人気ではなく、次の5つで許可します。
| 観点 | 見るもの | 雑に許可したときの事故 |
|---|---|---|
| workflow | 何の仕事を任せる plugin か | 便利そうなものを広く入れる |
| included parts | skills / apps / MCP / hooks の内訳 | skill だけだと思って外部 action も許す |
| role access | どの workspace role へ Available / Installed にするか | 全員に初期導入される |
| app permissions | action controls / sync / domain / auth | plugin ではなく app 側で広く許す |
| run context | desktop / web / CLI / scheduled task | unattended で外部 action が走る |
plugin governance の中心は、「この plugin を入れてよいか」ではありません。この plugin が含む app、connector、MCP server、skill、hook を、誰が、どの surface で、どの権限まで使えるかです。
plugin listing では included parts を先に読む
OpenAI の現行 docs では、plugin は workflow capability の配布単位です。中身はひとつではなく、skills、apps、app templates、connectors、MCP servers、browser extensions、hooks などを含み得ます。
したがって、導入時に最初に見るべきなのは plugin 名ではなく included parts です。
plugin_review:
name: "github-pr-babysitter"
intended_workflow: "PR status を定期確認し、レビューコメント対応案を作る"
includes:
skills:
- "pr-follow-up"
apps:
- "GitHub"
mcp_servers:
- "github"
hooks:
- "post-task-summary"
required_actions:
read:
- "repository metadata"
- "pull requests"
- "review comments"
write:
- "draft branch changes"
- "optional PR comments"この時点で「read-only だと思っていたが write action もある」「skill だけだと思っていたが MCP server も同梱されている」と分かれば、許可判断が変わります。
特に hooks は見落としやすいです。Codex CLI では /hooks で lifecycle hooks を確認できます。plugin に hook が含まれるなら、どの event で何を実行するのか、managed hook なのか、ユーザーが disable できる hook なのかを確認します。外部接続より hook の方が危ない場面もあります。hook は会話中の判断ではなく lifecycle point で走るからです。
Workspace settings は Plugins と Apps の両方を見る
OpenAI Help Center の整理では、workspace admin は plugin availability を Workspace settings の Plugins で管理し、underlying app access は Apps 側でも管理します。ここが重要です。
plugin 側だけ見て「この plugin は Available」にしても、含まれる app が role に対して有効でなければ app-backed capability は使えません。逆に、app 側が広く許可されていると、複数 plugin が同じ app permission を継承します。
私なら、レビュー表を plugin と app に分けます。
| レイヤー | 決めること | 例 |
|---|---|---|
| Plugin | role ごとに Available / Installed / 未許可 | Engineering は Available、Security は Installed |
| App | role access、action controls、approval settings | GitHub read は許可、comment write は承認必須 |
| Sync | 何を index / sync してよいか | private docs は除外 |
| Domain | どの domain に到達してよいか | github.com と社内 GitHub Enterprise のみ |
| Auth | provider authentication の責任者 | 個人 OAuth か service account か |
この分離をしないと、「plugin は制限したのに app 側で別 plugin から同じ action が使える」状態になります。
Available と Installed は別の統制です
Workspace settings では plugin を role ごとに Available または Installed にできます。私はこれを、単なる便利設定ではなく rollout policy として扱います。
| 状態 | 使う場面 | 避けるべき場面 |
|---|---|---|
| Available | 使いたい人が自分で入れる | 必須 workflow |
| Installed | role に初期導入したい | 試験中 / risk 不明 |
| Not available | まだ許可しない | なし |
新しい plugin は、基本的に Available から始めます。Installed にするのは、仕事の型が固まり、app permission が最小化され、初回 run の出力形式まで確認できた後です。
特に Business / Enterprise / Edu workspace では、admin が全員の plugin rollout を決めることになります。ここで「便利だから Installed」にすると、利用者は最初からその workflow が組織公認だと受け取ります。まだ検証していない plugin を Installed にするのは、運用上かなり重い判断です。
app permission は action と sync を分ける
plugin governance で一番事故りやすいのは、read と write を同じ許可で見てしまうことです。
たとえば GitHub plugin を考えます。PR を読むだけなら pull_request:read 相当で足ります。レビューコメントを書く、branch を push する、issue label を変える、release を作るなら話が変わります。Google Drive でも、ファイル検索、文書閲覧、コメント、編集、共有設定変更は別のリスクです。
私なら app permission は最低限この5分類にします。
app_permission_tiers:
read_index:
default: allow
examples: ["search metadata", "list recent docs"]
read_content:
default: allow_for_limited_domains
examples: ["read file body", "read PR diff"]
draft:
default: allow
examples: ["draft reply", "prepare patch"]
write_internal:
default: require_approval
examples: ["post PR comment", "create branch"]
external_action:
default: deny_or_strict_approval
examples: ["send email", "share document", "trigger deploy"]この分類は AIコーディングツールの社内ガイドライン の入力境界 / 実行境界ともつながります。plugin は便利な workflow packaging ですが、最終的に守るべきなのは「どの情報を読み、どの action を実行したか」です。
scheduled task で使う plugin は別レビューにする
Codex や ChatGPT Work の scheduled tasks は、plugins と skills を使えます。ここが plugin governance の難所です。
通常の interactive run なら、人間が途中で違和感に気付けます。scheduled task ではそうはいきません。決まった cadence で背景実行され、local project や worktree に触り、connected tools を読み、結果を inbox に返します。便利ですが、許可判断は一段厳しくするべきです。
私なら、scheduled task で plugin を使う前に次を満たします。
- task prompt に plugin 名と使う範囲を書く
- app action は read / draft から始める
- local project ではなく worktree 実行を優先する
- first 3 runs は人間が確認する
- inbox summary に touched resources と skipped actions を返す
たとえば PR babysit automation なら、最初は「PR status と review comments を読む」「修正案を draft する」までにします。PR comment 投稿や branch push は、初期 rollout では承認付きにします。
Use the GitHub plugin only to read PR status, CI checks, review comments, and changed files.
Do not post comments or push commits unless this scheduled task has explicit approval for write actions.
Return: touched PRs, recommended action, skipped write actions, and unresolved risks.scheduled task では「毎回人間が見ている前提」を置かない方が安全です。
CLI / desktop / web / IDE extension で使える範囲を混同しない
OpenAI Learn の plugin docs では、plugins は ChatGPT Work on web、ChatGPT Work / Codex in desktop、Codex CLI などで扱えます。一方、IDE extension では plugin は使えないと整理されています。Codex CLI では /plugins で plugin browser を開き、install 後は新しい session で使う流れです。
この surface 差分は、社内手順に書くべきです。
| surface | plugin governance の注意 |
|---|---|
| ChatGPT web / Work | connected tools と workspace role を確認する |
| ChatGPT desktop / Codex | local project / worktree と組み合わせるため file access も見る |
| Codex CLI | /plugins、/apps、/mcp、/hooks で有効状態を確認する |
| IDE extension | plugin 前提の手順を書かない |
特に「IDE extension でも使えるはず」と思い込むと、手順が現場で止まります。plugin が必要な workflow は、実行 surface を明示してから配る方がよいです。
plugin catalog を作る
plugin を増やすほど、最終的には catalog が必要になります。MCP server catalog と同じで、allowlist だけでは説明責任が足りません。
私なら、最低限この項目で管理します。
| 項目 | 例 |
|---|---|
| plugin_name | github-pr-babysitter |
| owner | engineering-productivity |
| status | trial / approved / deprecated |
| roles | engineer, security-reviewer |
| surfaces | desktop, cli, scheduled |
| included_apps | GitHub |
| included_skills | pr-follow-up |
| included_mcp | github |
| hooks | none / post-task-summary |
| permissions | read_content, draft, write_internal: approval |
| review_date | 2026-09-03 |
| rollback | set plugin not available; revoke app auth |
この catalog があると、「誰がなぜ入れたのか」「どの role に配ったのか」「どの app permission を継承しているのか」を後から説明できます。特に app template を使う plugin は、template を作っただけでは使えません。admin が組織固有設定、draft app、publish、access assignment まで済ませたかを catalog に残します。
導入レビューのチェックリスト
最後に、私が plugin 導入前に見るチェックリストを置きます。
- plugin の目的は1文で説明できるか
- included skills / apps / MCP servers / hooks を列挙したか
- app permission を read / draft / write / external action に分けたか
- role ごとの Available / Installed を決めたか
- scheduled task で使うかを別に確認したか
- CLI / desktop / web / IDE extension の surface 差分を書いたか
- 初回3回分の review owner を決めたか
- rollback 手順を決めたか
この8項目を通らない plugin は、まだ組織配布には早いです。個人検証に留めるか、skill 単体で先に workflow を固めた方がよいです。
まとめ
Codex plugins は、外部接続を便利にするだけの仕組みではありません。skills、apps、MCP tools、browser extensions、hooks を workflow 単位で束ねるため、組織では governance の対象になります。
私なら、plugin governance は次の順で始めます。
- plugin listing の included parts を読む
- Workspace settings の Plugins と Apps を両方確認する
- Available から小さく始める
- app permission は read / draft / write / external action に分ける
- scheduled task で使う plugin は別レビューにする
- plugin catalog に owner、role、surface、permissions、rollback を残す
plugin と skill の違いを理解するだけでは足りません。組織で安全に使うには、plugin を「便利な拡張」ではなく「配布された権限」として扱う必要があります。