🧩 技術調査 - Codex for every role（職種別プラグインとSites）

検証日: 2026-06-04 / 対象発表: 2026-06-02 OpenAI「Codex for every role, tool, and workflow」
分類: Coding Agent / Knowledge Work（職種別プラグイン + Sites による知識労働の実行基盤化）

概要

2026-06-02、OpenAI は公式ブログ「Codex for every role, tool, and workflow」で Codex の拡張を発表しました。新要素は 3 つです。

発表の核心は「モデルが賢くなった」ことではありません。仕事を投入する単位が、その場限りのチャットから、道具・成果物・承認点・共有面を束ねた宣言的な「role（役割）パッケージ」へ移った点にあります。

Codex はもともと開発者向けコーディングツールとして始まりました。今回の拡張は、職種別プラグインによって「コーディング不要」でアナリスト・マーケター・投資家・バンカー等の知識労働者が Codex を使えるようにします。

OpenAI が示す普及指標は次のとおりです（いずれもベンダー自己申告・母数定義は非開示）。

• 週次ユーザー数: 500 万人超
• 非開発者の割合: 全体の約 20%
• 非開発者の成長速度: 開発者の 3 倍超

ローンチ済み 6 職種と近日提供予定の職種は次のとおりです。

ブログ発表では 6 職種・合計 62 のアプリと 110 のスキルがバンドルされたとされています（OpenAI 発表値。公式ブログは取得制限のためプロキシ経由で確認）。一方、公式 OSS テンプレートリポジトリ openai/role-based-plugins に現時点で公開されているのは 4 職種（Sales / Data Analytics / Product Design / Financial Markets）です。職種ラインアップと公開テンプレートは別管理で、発表職種の一部はテンプレート未公開です。近日提供予定の職種名はブログ発表由来で、リポジトリ README には未記載です。

類似製品との比較

特徴

役割のパッケージ化（Plugin = role の宣言的バンドル）

Codex の拡張は入れ子構造を持ちます。最小の Tool → MCP server → App / Connector → Skill（著作形式） → Plugin（配布単位）という積み上がりです。公式は "Skills are the authoring format, Plugins are the installable distribution unit" と明言します。

「分析担当」「営業担当」という役割が、使う道具（MCP / コネクター）・作る成果物・実行手順（skills）を 1 つの宣言的パッケージにまとめます。チャット 1 回ごとにツールを繋ぎ直すのではなく、ロール単位で導入する発想です。

MCP がコア接続

ツール接続は MCP（Model Context Protocol） がコアです。STDIO と Streamable HTTP の 2 形態を取ります。App / Connector も実体は OpenAI 管理の MCP ラッパであり、認証は bearer token / OAuth（codex mcp login）で行います。

2 レイヤー承認による実行制御

実行時の安全は 2 つのレイヤーが協調します。

• Sandbox（技術境界）: 新方式の permission profile プリセットはコロン付きの :read-only / :workspace / :danger-full-access、旧 sandbox_mode 値はコロン無しの read-only / workspace-write / danger-full-access。両者は相互排他で、どちらか一方を設定します。
• Approval policy（承認方針）: on-request / untrusted / never の 3 段階。何をするとき人間承認を挟むかを定義します。auto_review（承認を reviewer エージェントに委譲）は policy の値ではなく、別キー approvals_reviewer = "auto_review" で設定します（既定は user）。

ローカル CLI は OS サンドボックス（macOS Seatbelt / Linux bwrap+seccomp）、クラウドは隔離コンテナ + プロキシ網を使います。エージェント実行フェーズではネットワークが既定でオフになり、secrets はフェーズ開始前に削除されます。

Sites — 成果物が「本番 URL」として共有される

Sites は、プロンプトや既存プロジェクトを OpenAI 管理インフラ（Cloudflare Worker 互換ビルド + D1 / R2 ストレージ） に本番 URL でデプロイする面です。静的サイト・インタラクティブアプリ・データ可視化・内部ツール・ゲームを対象とします。

アクセス制御は admins only（既定）/ workspace / custom の 3 モード + Sign in with ChatGPT 認証を持ちます。Business は既定で有効、Enterprise は RBAC で管理者が有効化します（preview）。

「全デプロイ URL が即"本番"」である点が最大の特徴であり、最大のリスクでもあります。Sites 専用の監査ログ・URL 自動失効・棚卸し機構は developer docs に記載が見当たらず[未確認]です。

エンタープライズ統制の継承

管理機能は managed_config.toml（デフォルト設定）と requirements.toml（強制ロック）の二層構造です。組織管理者が allowed_sandbox_modes / mcp_servers ホワイトリスト等を強制できます。

監査は Compliance API と Analytics API（スコープ codex.enterprise.analytics.read は公式確認済み）が担います。イベント型名（CODEX_LOG / CODEX_SECURITY_LOG）や plugin 呼び出し計測の有無は調査時点で公式ページに明示が見当たらず[要確認]です。ただし API キー経路は Compliance API の対象外で、監査ログの保持期間は最大 30 日です。SSO / SCIM・MFA・データ所在地・zero data retention は ChatGPT Enterprise の統制をそのまま継承します。

構造

システムコンテキスト図

コンテナ図

コンポーネント図（Plugin / Skill / App-Connector）

コンポーネント図（Sandbox / Approval Policy の 2 レイヤー協調）

コンポーネント図（Sites / 管理者ガバナンス / 監査 API）

データ

概念モデル

エンティティ間の所有関係を subgraph（入れ子）で、利用関係を矢印で示します。

情報モデル

主要エンティティの属性を定義します。型は汎用名で表記します。公式一次で確認できない属性は属性根拠表で「推測/補完」と明示します。

属性の根拠と補完注記

構築方法

必須パラメータ一覧

Codex CLI / App / IDE 拡張の導入前提

• Codex App: ChatGPT の Business / Enterprise / Edu プラン向けに提供。
• Codex CLI: npm install -g @openai/codex でインストール。~/.codex/config.toml を設定ファイルとして使用。
• IDE 拡張: VS Code 等の拡張として提供。CLI と設定ファイルを共有。
• Sites: 2026-06-02 時点で preview。ChatGPT Business はデフォルト有効、Enterprise は管理者が RBAC で有効化が必要。

プラグインの有効化（管理者 allowlist）

組織の管理者は allowlist モデルでプラグインを管理します。

• 全アプリはデフォルト無効。管理者が明示的に有効化したアプリのみメンバーが利用可能。
• 有効化の経路: Workspace settings > Apps で対象アプリを有効化。
• Enterprise / Edu では RBAC でユーザーまたはグループへのアクセスを個別に割り当て可能。

# 設定例: プラグインを無効化（アンインストールせずに保持）
[plugins."gmail@openai-curated"]
enabled = false

MCP サーバの設定（[mcp_servers.<name>]）

config.toml はユーザースコープ（~/.codex/config.toml）とプロジェクトスコープ（.codex/config.toml）の両方をサポートします。

STDIO 型（ローカルプロセス）の主な設定キー:

Streamable HTTP 型の主な設定キー:

共通オプションキー:

設定例:

# STDIO 型: Context7 MCP サーバ
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["LOCAL_TOKEN"]

# HTTP 型: Figma MCP サーバ（Bearer トークン認証）
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }

CLI でインタラクティブに追加することもできます。

codex mcp add <name> -- <command>

codex mcp login（OAuth 認証）

OAuth 対応の MCP サーバに対しては codex mcp login でブラウザ認証フローを実行します。

codex mcp login <server-name>

• MCP サーバが scopes_supported を広告している場合はそのスコープを優先し、なければ config.toml に設定したスコープにフォールバックします。
• コールバックは mcp_oauth_callback_port または mcp_oauth_callback_url で上書きできます。

managed_config.toml / requirements.toml の配置

配置パス:

優先順位（高→低）:

1. クラウド管理 requirements（ChatGPT Business / Enterprise）
2. macOS MDM managed preferences
3. システムレベルファイル（/etc/codex/requirements.toml 等）
4. ユーザー ~/.codex/config.toml
5. CLI 引数

requirements.toml のロック設定例:

# 管理者向けロック設定例
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_web_search_modes = ["cached"]

[features]
browser_use = false
computer_use = false

[permissions.filesystem]
deny_read = ["/etc/passwd", "~/.ssh/**"]

[experimental_network]
enabled = false

ロック可能なキー: allowed_approval_policies / allowed_sandbox_modes / allowed_approvals_reviewers / allowed_web_search_modes / enforce_residency / mcp_servers（allowlist）/ [features] / [permissions.filesystem].deny_read / [rules] / [experimental_network] / [hooks]。

利用方法

プラグインの利用

Codex App での手順:

1. メインメニューから「Plugins」セクションを開く。
2. プラグインディレクトリを検索またはブラウズする（「Curated by OpenAI」「Shared with you」「Created by you」の 3 カテゴリ）。
3. プラグインを選択して「Add to Codex」をクリックする。
4. 外部アプリの認証が求められた場合は認証する。
5. 新しいスレッドを開始してプラグインを呼び出す。

呼び出し方法（2 種類）:

# 直接依頼
今日の未読 Gmail スレッドを要約して

# 明示的な参照（@ で指定）
@gmail 今日の未読スレッドを要約して

CLI では /plugins コマンドでブラウザを開きます。

approval policy の指定

auto_review（承認を reviewer エージェントに委譲）は approval policy の値ではなく、別キー approvals_reviewer で指定します（既定は user）。

# config.toml での永続設定
approval_policy = "on-request"
approvals_reviewer = "auto_review"   # 承認を reviewer エージェントへ委譲（任意）

# セッション中の切り替え
--ask-for-approval never
/permissions

sandbox mode / permission profiles

permission profiles（推奨・新方式）と sandbox mode（旧方式）は相互排他です。どちらか一方を設定します。

# config.toml: アクティブプロファイルの指定（組込みプリセットはコロン付き）
default_permissions = ":workspace"

コロン無しの workspace はカスタムプロファイル名として扱われ、[permissions.workspace] を別途定義しない限り組込みプリセットとは等価になりません。

カスタムプロファイルの定義例:

[permissions.project-edit]
extends = ":workspace"
description = "Project editing with API access"

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

旧 sandbox_mode は default_permissions を使わない既存設定との互換用です（permission profiles と同時設定不可）。

Sites のデプロイ

Sites は 保存（save）→ デプロイ（deploy） の 2 段階ワークフローです。発行される URL は全て即座に本番環境となります。

1. Codex のスレッドで @Sites にプロジェクトのデプロイを依頼する。
2. Sites が互換性を確認し、必要な修正を行った上でビルドする。
3. Save a version（レビュー用、本番化しない）または Deploy a version（本番 URL を発行）を選択する。
4. デプロイ成功後に本番 URL が報告される。

@Sites Deploy this project. Check whether it is compatible with Sites, make any required changes, and give me the deployment URL.

access mode の設定:

{
  "project_id": "<自動生成される project ID>",
  "d1": "DB",
  "r2": null
}

• 認証は Sign in with ChatGPT（ワークスペース認証済みユーザー ID）を使用します。
• 環境変数・シークレットは app サイドバーの Sites パネルから管理し、.openai/hosting.json や Git にコミットしません。更新後は再デプロイで反映します。

運用

プラグインの配布・有効化管理（RBAC allowlist）

• すべてのアプリはデフォルト無効。管理者が Workspace settings → Apps で明示的に有効化。
• Business / Enterprise / Edu では管理者がユーザーに対して app または plugin へのアクセスを RBAC で制御可能。Enterprise / Edu はカスタムロールにアプリを紐づけて割り当て可能。

Codex Policies ページ（クラウド側）

• requirements.toml のポリシーを作成し、user group に割当または default fallback policy を設定。
• 優先順位（高→低）: Cloud-managed requirements → macOS MDM → システム requirements.toml。

[未確認] 強制配布（force push to all users）の可否。確認できたのは allowlist enable までの間接統制のみです。

Compliance API（監査ログ・エクスポート）

• 主エンドポイント・パスとイベント種別名（/compliance/workspaces/{workspace_id}/logs 等、CODEX_LOG / CODEX_SECURITY_LOG）は調査時点で公式ページに明示が見当たらず[要確認・推測]。正本は ChatGPT 管理コンソールの API リファレンスを参照。
• エクスポート情報: プロンプト・レスポンス・メタデータ（workspace / user / timestamp / model）。
• 保持期間: 監査レコード最大 30 日。
• [重大な死角] API キー認証経由の Codex 利用は Compliance API export の対象外（API org 設定に従う）。

規制業種での完全監査証跡を要件とする場合、API キー認証ルートの利用者は監査対象から漏れます。SSO / ChatGPT 認証への一本化が必要です。

Analytics API

• ベース URL: https://api.chatgpt.com/v1/analytics/codex/
• 必要スコープ: codex.enterprise.analytics.read
• 主エンドポイント: /workspaces/{workspace_id}/usage / /code_reviews / /code_review_responses（公式確認済み）。
• 計測メトリクス: active users / completed runs / token・credit usage / code review activity（threads・turns・credits 等）。plugin calls（ロール別プラグイン呼び出し数）と lines of code は公式メトリクス一覧での明示が確認できず[要確認]。
• 粒度: daily / weekly UTC バケット。
• データ反映ラグは数時間〜最大 24 時間程度（公式の更新頻度記載に幅あり。通常 6〜12 時間）。

SCIM / SSO / MFA

• SSO: ChatGPT Enterprise 側で有効化済みが前提。Codex は継承して動作。
• SCIM: IdP 経由で Groups にユーザーを自動同期。「Codex Admin」グループを SCIM バックすることでメンバー変更が監査可能・中央管理になる。
• MFA: メール+パスワードログインの場合は Codex cloud アクセス前に MFA 設定が必須。SSO ユーザーは組織 SSO 管理者が MFA を強制。

データ所在地・Zero Data Retention（ZDR）

• ZDR の適用範囲: App / CLI / IDE のローカルサーフェス。コードは開発者環境に留まる。
• クラウド実行: ChatGPT Enterprise の retention / residency 設定に準拠。
• 暗号化: 保管時 AES-256 / 転送時 TLS 1.2 以上。エンタープライズデータはモデル学習に使用しない。

Sites の運用（本番 URL 管理）

• 全デプロイ URL = 本番扱い: 「Every Sites deployment URL is a production deployment.」（開発者 docs 一次本文）。
• レビューしたい場合は「デプロイせずに version を save」（save と deploy を分離）。
• シークレット管理: app サイドバーの Sites パネルから環境変数・シークレットを管理。.openai/hosting.json やソースにコミットしない。
• [未確認]: ストレージ上限・クォータ数値・カスタムドメイン可否・URL 失効/棚卸し・Sites 専用監査ログの有無。

ベストプラクティス

役割単位の導入境界設計

• 誤解: プラグインを全員に配ってから絞る。
• 反証: allowlist モデルでは全アプリがデフォルト無効であり、有効化しない限りメンバーは使えません。一度有効化したアプリの棚卸し機構はビルトインで提供されると明言されていません（[二次情報: explainx.ai]）。
• 推奨:
  1. 「Codex Admin」グループを最小権限で構成し、SCIM で IdP バックする。
  2. ロール別 user group（例: codex-analyst / codex-sales / codex-banking）を作成する。
  3. 各 group に対応するプラグインのアプリを allowlist で有効化する。
  4. group 単位で requirements.toml ポリシーを Policies ページから割当てる。
  5. Investment Banking / Equity Investing のような規制業種ロールは別 group に分離し、approval policy を on-request 以外に緩めない。

2 レイヤー承認の設計

• 誤解: approval policy を never にすると「承認不要で便利」になる。
• 反証: read-only + on-request 設定下でも MCP edit ツールが承認なしで実行される実装バグが報告されています（openai/codex#4152、Closed / 修正済み）。approval 設定が一貫して効くという前提はとりません。
• 推奨:

承認リクエストイベントが notify hook にログされない実装バグ（openai/codex#6024、Closed）があったため、承認の監査証跡は Compliance API ログで確認し、hook 経由の通知だけに依存しません。

Sites を「本番扱い」で運用する（既定 admins only + 棚卸し）

• 誤解: Sites は「プレビュー用の一時 URL」であり、運用中だけ気を付ければよい。
• 反証: デプロイ URL は全て即本番です。OpenAI 自社ドメイン上の URL は企業フィルタを素通りしうるリスクがあります。
• 推奨:
  • デプロイ前に「save」で内部レビューを完了させ、デプロイは最終承認後のみ実施する。
  • Enterprise では Sites を RBAC / Early Access でロックし、有効化するロールを絞る。
  • Analytics API でデプロイ済み Sites を定期取得し、使われていない Sites を decommission する棚卸しフローを設ける。
  • アクセスは「admins only」を起点に必要最小限へ広げる。

規制業種での human-in-the-loop 設計（FINRA 2026）

• 誤解: プラグインを導入すればコンプライアンスも自動的に満たされる。
• 反証: FINRA 2026 Annual Regulatory Oversight Report は AI エージェントに human-in-the-loop の監督・追跡・統制の文書化を求めています。Codex の Compliance API は prompt / response / metadata 中心で、agent reasoning の中間ステップの完全追跡は一次本文で確認できていません（[未確認]）。
• 推奨:
  • Equity Investing / Investment Banking プラグインの成果物は、必ず人間の専門家が最終レビューする承認ステップを社内フローに明示化する。
  • Written Supervisory Procedures（WSP）に Codex 利用のガバナンス・ベンダーリスク管理・エージェント監視手順を追記する。
  • 規制業種ワークスペースでは API キー認証を禁止し（Compliance API の死角）、全員 SSO / ChatGPT 認証に統一する。
  • Compliance API エクスポートを SIEM に接続し、30 日制限を超える長期保持を SIEM 側で設定する。

Codex CLI を更新する（CVE-2025-61260）

• 誤解: 社内環境で使うなら更新は後回しでよい。
• 反証: CVE-2025-61260（CVSS 3.1 base 9.8 CRITICAL、CISA-ADP 評価）は Codex CLI v0.23.0 以下に影響します。信頼できないリポジトリで Codex を実行すると、プロジェクトローカルの .env / .codex/config.toml（悪意ある MCP 設定を含む）をユーザー確認なしに自動読込し、コマンドが実行されます。
• 推奨:

# バージョン確認
codex --version

# 更新（npm 経由の場合）
npm install -g @openai/codex@latest

• 修正済みの後継バージョンへ更新する。
• 信頼できるリポジトリのみで Codex を実行する運用ポリシーを設け、外部・OSS リポジトリでの実行は承認済み環境に限定する。

トラブルシューティング

まとめ

Codex for every role の本質は、仕事の単位をチャットから「道具・成果物・承認点・共有面を束ねた役割パッケージ」へ宣言的に移したことにあり、plugin / skill / MCP の入れ子と 2 レイヤー承認がその設計の型を示します。一方で Sites や拡張プラグインは preview・価格未確定で、CVE-2025-61260 や監査ログの死角もあるため、当面は「設計リファレンス + 限定 PoC」として読むのが妥当です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式（発表・ドキュメント）
  • OpenAI: Codex for every role, tool, and workflow
  • Codex developer docs — plugins
  • Codex developer docs — skills
  • Codex developer docs — MCP
  • Codex developer docs — permissions
  • Codex developer docs — sandboxing
  • Codex developer docs — agent approvals and security
  • Codex developer docs — Sites
  • Codex developer docs — enterprise governance
  • Codex developer docs — managed configuration
  • Codex developer docs — admin setup
  • Codex developer docs — auth
  • Codex changelog
  • Model Context Protocol 仕様
• GitHub
  • openai/role-based-plugins
  • GitHub Issue openai/codex#4152（approval policy バイパス）
  • GitHub Issue openai/codex#6024（notify hook にログされない）
  • GitHub Issue openai/codex#24433（Computer Use 監査証跡なし）
• セキュリティ・規制
  • NVD: CVE-2025-61260（Codex CLI v0.23.0 以下, CVSS 9.8）
  • FINRA 2026 Annual Regulatory Oversight Report（GenAI）
• 日本語解説
  • gihyo.jp: Codex business workflows
  • Impress Watch（窓の杜）報道
  • Zenn（NTTデータ Tech）: Skills はチームで使われてはじめて意味を持つ