2026年6月5日、OpenAIはChatGPT Enterprise向けのCodexで plugin sharing を既定有効にしたと案内しました。これは、各メンバーがローカルで作ったプラグインをワークスペース内で共有し、Codexのプラグインディレクトリから同僚がインストールできるようにする更新です。単なる配布機能ではなく、社内の手元ノウハウを再利用可能な運用部品に変える入口として見るべき変更です。
一方で、共有した瞬間に何でも安全になるわけではありません。OpenAIのドキュメントでは、既存の承認設定はそのまま適用され、外部サービス連携にはそれぞれの認証やデータ共有ポリシーが残ると明記されています。つまり企業側は「共有できるようになった」ことより、「どこまで共有してよいか」「誰が止めるか」「requirements.tomlで何を固定するか」を先に決める必要があります。
Codexのplugin sharingで何が変わったのか
OpenAI Help Centerの2026年6月5日付リリースノートでは、対象となるChatGPT Enterpriseワークスペースで plugin sharing がデフォルトで利用可能になったと説明されています。共有対象はローカルプラグインで、メンバーはCodexのプラグインディレクトリからその共有済みプラグインを見つけて導入できます。従来のように個人環境の中だけで完結していた社内用プラグインを、ワークスペース単位で横展開しやすくなったのが今回の本質です。
この変更は、役割別プラグインやSitesのようなOpenAI提供機能とは少し意味合いが違います。今回の主役は、現場メンバーや社内開発チームが自作したプラグインを、公式ディレクトリの流れに近い体験で配布できる点です。営業向けの提案準備、データ分析向けの定型クエリ、レビュー用の社内手順など、再利用したいワークフローを小さく共有しやすくなります。
共有されるものと、共有しても自動では解決しないもの
OpenAI DevelopersのPluginsドキュメントによると、プラグインをインストールするとワークフロー自体はCodexで使えるようになりますが、既存の承認設定は維持されます。さらに、プラグインにアプリが同梱されている場合はChatGPT側で追加セットアップやサインインを求められることがあり、MCPサーバーを含む場合も追加認証や環境準備が必要です。
ここで重要なのは、「共有できる」と「すぐ安全に業務利用できる」は別だという点です。たとえばSalesforce連携や社内MCP接続を束ねたプラグインを配っても、接続先の権限設計が粗いままだと、配布のしやすさだけが先に広がります。逆に承認、接続先、監査の責任分界が明確なら、現場は毎回ゼロから設定を作らずに済み、標準化の速度が大きく上がります。
requirements.tomlで管理者が最初に決めるべきこと
今回のアップデートで最も実務的なのは、管理者が cloud-managed の requirements.toml から plugin sharing を止められる点です。Build plugins と Configuration Reference の両方で、features.plugin_sharing = false を設定すると、ローカルで作成したプラグインのワークスペース共有を無効化できると案内されています。つまり、全社開放を前提にする必要はありません。
最初の運用では、1. 共有を既定で許可するか、2. 管理者承認後のみ共有可能にする代替手順を用意するか、3. 特定部門だけ先行解放するか、の三択で考えると整理しやすいです。特にセキュリティレビュー前の試作プラグインや、外部APIへ送信する処理を含むプラグインは、共有前にコードレビュー、利用目的、送信データの範囲を記録しておくべきです。
社内共有前のチェックリスト
実務上は、まず共有対象プラグインが何を束ねているかを棚卸ししてください。ローカルスクリプトだけなのか、外部アプリ認証を含むのか、MCPサーバーへ接続するのかで、求められる審査は変わります。次に、承認フローを確認します。既存の approval 設定で十分か、重要操作だけ追加確認が必要かを切り分けることが重要です。さらに、無効化手順も先に決めます。OpenAIのドキュメントではプラグイン本体をアンインストールしても、同梱アプリはChatGPT側で別管理になるため、停止手順を一本化しておかないと運用が崩れます。
そのうえで、共有するプラグインごとに「用途」「利用部門」「接続先」「保管データ」「停止責任者」を1枚で残す運用が有効です。plugin sharing は便利ですが、便利さだけで広げると“誰が作ったか分からない社内拡張”が増えやすくなります。逆に、この台帳を持っておけば、監査対応でも説明しやすく、使われていないプラグインの棚卸しもしやすくなります。
CodexやChatGPT Enterpriseを部門横断で広げる前に、プラグイン共有ルールやrequirements.tomlの設計を整理したい場合は、 HelloCraftAIへの相談はこちら 。
FAQ
Q. plugin sharingを有効にすると、すべての外部接続が自動で許可されますか。A. いいえ。OpenAIのドキュメントでは、既存の承認設定はそのまま適用され、外部サービスごとの認証やポリシーも残るとされています。共有は配布の入口であって、権限審査の代替ではありません。
Q. 管理者はあとから無効化できますか。A. 可能です。公式ドキュメントでは、cloud-managed requirements.toml に features.plugin_sharing = false を設定することで、ワークスペース共有を無効化できると案内されています。まずは限定運用で始め、問題がなければ広げる形が現実的です。
Q. どんな企業に向いていますか。A. 部門ごとに同じCodex手順を何度も再実装している企業、内製プラグインを個人管理からチーム運用へ移したい企業、監査可能な形で社内ノウハウを再利用したい企業と相性がよいです。逆に、接続先整理や責任分界が未整備の段階では、先にガバナンス設計を固める方が安全です。
今すぐ見るべき判断ポイント
今回の plugin sharing は、機能追加というより運用責任の再配置です。現場は共有しやすくなり、管理者は requirements.toml・承認・棚卸しの三点を明文化しやすくなりました。導入判断では、便利だから有効化するのではなく、どのプラグインを誰が共有し、どの接続先をどの承認レベルで扱うかまで決めて初めて本番運用に乗せる、という順番で進めるのが安全です。
