Codex を社内ツールにつなぐ｜Plugins・connectors・MCP の違いと管理者が決めること

情報システム・セキュリティ担当にとって、Codex を社内ツールにつなぐ判断は「便利そうだから許可する」だけでは済みません。Plugins、connectors、MCP は近い文脈で語られますが、配布・接続・権限管理の観点が異なります。

本記事では、Codex MCP 連携を検討する際に押さえるべき仕組み、利用できる場所の違い、管理者が決める設定を、公式ドキュメントの範囲で整理します。

Plugins・connectors・MCP の役割を分けて理解する

Codex を社内ツールにつなぐとき、まず整理したいのは「Plugin」と「MCP」の役割です。

公式ドキュメントでは、Plugins は ChatGPT と Codex の機能を再利用可能なワークフローとして束ねる仕組みで、Skills や MCP servers を含められると説明されています。つまり Plugin は、利用者が発見・インストールするための「まとまり」です。一方、MCP server は、外部システムの情報や操作に接続するための構成要素として捉えると分かりやすいです。Plugins

MCP は Model Context Protocol の略で、モデルをツールやコンテキストにつなぐためのプロトコルです。公式ドキュメントでは、ChatGPT または Codex に第三者ドキュメントへのアクセスを与えたり、ブラウザや Figma のような開発者向けツールとやり取りさせたりする用途が説明されています。また、ChatGPT web は plugins から提供される remote MCP-backed tools を使え、ローカルの Codex クライアントは MCP servers に直接接続し、設定を共有できるとされています。Model Context Protocol

「connectors」という言葉は、公式ドキュメント上では hosted ChatGPT Work chat で plugin をインストールすると、bundled connectors と remote MCP tools を使える、という文脈で登場します。管理上は、connectors を単独の製品分類として扱うよりも、次のように分けて確認するのが実務的です。

用語	位置づけ	管理上の確認ポイント
Plugin	ChatGPT と Codex で使う機能を束ねる単位	誰に配布するか、どの workspace で利用可能にするか
MCP server	モデルをツールや外部コンテキストにつなぐ仕組み	接続方式、認証、利用できるツール、承認動作
connectors	hosted ChatGPT Work chat で plugin に含まれる接続機能として説明されるもの	plugin の中身として、どの外部サービスに接続するか

既存のセキュリティ統制全体との関係は、Codex のセキュリティ・ガバナンス整理も合わせて確認してください。

ChatGPT 全体の機能と Codex 固有の機能を分ける

連携設計では、「ChatGPT 全体で使える機能」と「Codex のクライアントで使う機能」を分けて考える必要があります。

公式ドキュメントでは、Plugins は ChatGPT の web、desktop、mobile の Chat / Work と、ChatGPT desktop app 内の Codex で使えるとされています。Codex CLI には Codex environments 向けの plugin browser があります。一方で、IDE extension は plugins をサポートしていないため、Codex 用に Plugin を参照・インストールするには ChatGPT desktop app または Codex CLI を使う必要があります。Plugins

MCP の扱いは少し異なります。公式ドキュメントでは、ChatGPT desktop app、Codex CLI、IDE extension が MCP servers をサポートし、同じ Codex host の MCP configuration を共有するとされています。設定ファイルは Codex の他設定と同じ config.toml に保存され、既定では ~/.codex/config.toml、信頼済みプロジェクトでは .codex/config.toml にスコープできます。Model Context Protocol

整理すると、Plugin Directory を通じた配布・発見は ChatGPT 全体の利用面を含む話であり、ローカルの MCP server 設定共有は Codex host 側の話です。両者を混同すると、「Web で使えるはず」「IDE extension で Plugin が使えるはず」といった誤解につながります。

なお、ローカル設定で MCP server を構成することと、データが外部に送られないことは同義ではありません。公式ドキュメントでは、ChatGPT が MCP server を通じてデータを送る場合、そのサービスの規約とプライバシーポリシーが適用されると説明されています。Plugins

利用できる場所の違い：Desktop、CLI、IDE、Web

利用できる場所を整理すると、管理者が利用者に案内すべき内容が明確になります。

領域	Plugin の扱い	MCP の扱い
ChatGPT web	Chat / Work で Plugin を利用可能	hosted ChatGPT Work chat では Plugin から remote MCP-backed tools を利用
ChatGPT desktop app	Chat / Work、および Codex で Plugin を利用可能	Codex host の MCP servers を設定可能
ChatGPT mobile	アカウントで利用可能な Plugin を Chat / Work で利用可能	公式ソース本文では、ローカル Codex MCP 設定の対象としては説明されていません
Codex CLI	/plugins で plugin browser を開ける	MCP servers を設定し、TUI で /mcp により active MCP servers を確認可能
IDE extension	Plugins はサポートされない	MCP servers をサポートし、Codex host の MCP configuration を共有

この違いは、社内展開の方針に直結します。たとえば「利用者には Plugin Directory から承認済み Plugin を使わせる」のか、「開発チームにはプロジェクト単位の MCP server 設定を配布する」のかで、管理対象が変わります。

Codex MCP 連携で確認すべき設定項目

Codex MCP 連携では、接続方式、認証、ツール単位の許可、承認動作を分けて確認します。

公式ドキュメントでは、Codex host に構成する MCP server の対応機能として、ローカルプロセスとして起動する STDIO servers と、アドレスにアクセスする Streamable HTTP servers が挙げられています。Streamable HTTP servers では Bearer token authentication、OAuth authentication、信頼された first-party server 向けの ChatGPT session authentication が説明されています。Model Context Protocol

設定ファイルでは、各 MCP server を [mcp_servers.<server-name>] テーブルで構成します。STDIO servers では command、args、env、env_vars、cwd などが示されています。Streamable HTTP servers では url、auth、bearer_token_env_var、http_headers、env_http_headers、http_headers_helper などが示されています。認証情報をどこから読み込むのか、静的ヘッダーを使うのか、OAuth ログインを必要とするのかを、情報システム側で把握しておく必要があります。Model Context Protocol

特に管理上重要なのは、ツールの利用範囲と承認です。公式ドキュメントでは、enabled_tools による許可リスト、disabled_tools による拒否リスト、default_tools_approval_mode によるツール既定の承認動作、tools.<tool>.approval_mode によるツール別の上書きが説明されています。承認モードには auto、prompt、writes、approve が示され、writes は read-only とマークされていないツールで確認を求めるものとされています。Model Context Protocol

Plugin 管理で決めること：配布、同期、既定インストール

組織で Plugin を使う場合、利用者任せにせず、管理者が marketplace と workspace access を設計します。

公式ドキュメントでは、workspace admins が GitHub から plugin marketplace を import し、リポジトリから plugins を最新状態に保てるとされています。marketplace は import 対象の plugins を列挙する JSON catalog です。Import 後、管理者は各 plugin の installation policy と required apps を設定します。Plugin management

管理画面での流れは、Admin > Plugins から marketplace を import する形です。Source には repository URL を入れ、必要に応じて Path や Branch、tag、commit を指定します。公式ドキュメントでは、非常に大きな marketplace の initial import は最大で 1 時間かかる場合があり、新しい marketplace では automatic daily sync が有効になるとされています。必要に応じて Sync now による更新要求も可能です。Plugin management

重要なのは、GitHub import と sync だけでは repository 側の installation や authentication policy が適用されない点です。公式ドキュメントでは、workspace admins が各 plugin について Available または Installed を eligible role ごとに選ぶと説明されています。また、required apps は有効化が必要で、メンバーには接続先サービスへのアクセスが必要です。Plugin の import は、アプリへのアクセス付与やメンバーのアカウント接続を自動で行うものではありません。Plugin management

管理項目	管理者が決めること	確認ポイント
Marketplace	どの GitHub repository を同期元にするか	参照先 repository を読めるアカウントか
Installation policy	役割ごとに Available / Installed をどうするか	対象 role に対して適切か
Required apps	Plugin が依存する app を有効にするか	対象メンバーに接続先サービス権限があるか
Sync	自動同期と Sync now の運用	repository 変更のレビュー手順があるか

Desktop only と外部サービス連携の扱い

Plugin 管理では、Desktop only の扱いにも注意が必要です。

公式ドキュメントでは、mcp.json または .mcp.json で MCP servers を宣言する imported plugin は Desktop only とマークされ、ChatGPT desktop app でのみ動作するとされています。これは remote HTTPS URL を使う server も含み、inline server declarations など他の対応 MCP configuration forms にも同じ制限が適用されます。Plugin management

この仕様は、利用者への案内に影響します。たとえば「管理者が workspace に Plugin を追加したのに、ある利用者の環境では使えない」という問い合わせが起きた場合、対象 Plugin が Desktop only か、利用者が ChatGPT desktop app を使っているか、必要な認証を完了しているかを確認する必要があります。公式ドキュメントでは、Plugin が MCP server connection を必要とする場合、インストール時または初回利用時に connect や authenticate を求めることがあると説明されています。Plugins

また、外部サービスとの接続では、認証と権限の境界を明確にします。公式ドキュメントでは、MCP servers は GitHub、Slack、Google Drive などのシステムに対して tools や情報を接続し、認証を強制し、構造化データを返し、外部システムに対する actions を実行すると説明されています。さらに、外部サービスへの connections は、そのサービス自身の authentication と access controls を使うとされています。Plugins

そのため、社内ルールでは「Plugin を許可する」だけでなく、次の点を運用に落とし込む必要があります。

• 接続先サービス側で、どの権限を持つアカウントが使うのか
• 書き込みや送信に該当する操作は、どの承認動作にするのか
• 異動や退職時に、接続や権限をどのように見直すのか
• Plugin の更新や追加を、誰がどのタイミングで確認するのか

管理者向けチェックリスト：許可前に見るべき観点

最後に、情報システム・セキュリティ担当が Codex MCP 連携を許可する前のチェック観点を整理します。

第一に、利用目的です。単なる情報参照なのか、外部サービスへの更新・送信を伴うのかで、承認や監査の必要性が変わります。

第二に、接続方式です。Plugin 経由で使う remote MCP-backed tools なのか、Codex host に直接設定する MCP server なのかを切り分けます。Model Context Protocol

第三に、配布経路です。workspace admins が GitHub marketplace から import / sync する場合、repository の内容を事前に review する必要があります。公式ドキュメントでは、import 前に repository content を review すること、新しい plugins は Available installation と authentication on install で開始すること、future syncs が repository 内の新しい plugins を自動追加することが説明されています。Plugin management

第四に、実行時の承認です。Plugin capability が Codex host を通じて実行される場合、host の sandbox and approval policy が適用されると公式ドキュメントに記載されています。一方で、外部サービスへの connections は、そのサービス自身の認証とアクセス制御を使います。したがって、Codex 側の承認設定と、接続先サービス側の権限設定を別々に確認する必要があります。Plugins

観点	確認する質問
利用目的	読み取りだけか、外部サービスへの操作を含むか
接続方式	Plugin 経由か、Codex host の MCP server 直接設定か
配布経路	GitHub marketplace の内容を誰がレビューするか
認証	OAuth、Bearer token、環境変数などの扱いは明確か
権限	接続先サービス側のアカウント権限は適切か
承認	ツール実行時に prompt や writes などを使うべきか
変更管理	sync による追加・更新をどう確認するか

まとめ

Codex を社内ツールにつなぐ際は、Plugins、connectors、MCP を同じものとして扱わず、役割を分けて設計することが重要です。

Plugins は機能を束ねて配布・発見する単位、MCP は Codex や ChatGPT を外部ツールやコンテキストにつなぐ仕組みとして理解すると、管理項目が整理しやすくなります。connectors は、公式ドキュメント上では hosted ChatGPT Work chat で plugin に含まれる接続機能として説明されているため、plugin の中身として確認するのが現実的です。

特に情報システム・セキュリティ担当は、利用できるクライアント、Desktop only の制約、MCP server の接続方式、認証情報の扱い、ツール単位の許可・拒否、実行時承認、workspace での installation policy を確認する必要があります。利便性だけでなく、配布経路と変更管理まで含めて設計することで、社内利用に耐える Codex MCP 連携の運用に近づきます。

デジライズでは、Codex の法人導入や社内ツール連携に関するご相談を承ります。Plugin / MCP の利用方針、セキュリティ部門向けの運用ルール整理から始めたい場合は、現在の課題をお聞かせください。

関連記事

• Codex のセキュリティ・ガバナンス整理