このガイドでは、ChatGPT Enterprise の導入計画を次の管理領域に分けて説明します。
- ワークスペースへのアクセス
- ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能の対象機能に適用するローカル実行ポリシー
- Codex Cloud
- Platform API へのアクセス
- プラグインとコネクタへのアクセス
- 接続先システムでの権限
新規導入の場合は、手順を順に進めてください。特定の管理領域だけを変更する場合は、該当するリンク先の手順を参照してください。
ローカルの Codex クライアント向けにモデルゲートウェイを管理している場合は、ゲートウェイの導入に沿って、ゲートウェイが要件を満たすかを確認し、認証情報の配布とクライアント側への引き継ぎを行います。ワークスペース機能を利用する場合は、ワークスペースへのアクセスを別途設定してください。
ワークスペース設定の Codex と Work のローカル利用では、メンバーに Codex と Work のローカル利用を許可で両方のアクセスをまとめて管理します。ワークスペースによっては、Codex のローカル利用と Work のローカル利用が別々のセクションに分かれています。この場合、Codex はメンバーに Codex のローカル利用を許可で、Work は Work をローカルで使用で管理します。一方を有効にしても、もう一方は有効になりません。これらのラベルはワークスペースの権限を示すもので、別々の製品やクライアントを指すものではありません。トークンの権限と認証情報の有効期間の上限は、ワークスペースに応じてアクセストークンまたはローカルアクセスのセクションに表示されます。管理対象の構成はこれとは別のポリシーで、各クライアントの対象機能について、サポートされている範囲で実行時の動作を制限できます。このガイドでは、動作や利用可否が異なる場合に、該当する利用環境を明記します。
アクセス制御の概要は、ロールとワークスペースの権限を参照してください。ChatGPT ワークスペースの最新の操作手順はヘルプセンターで、ローカル環境とホスト環境での実行時の動作はリンク先の開発者向けドキュメントで確認してください。
企業向けのセキュリティ、プライバシー、実行時の保護については、エージェントの承認とセキュリティおよび Codex セキュリティホワイトペーパーを参照してください。
ステップ 1：担当者と導入範囲の決定
次の領域ごとに、導入の担当者を決めます。
- ワークスペースへのアクセス： メンバーシップ、シート、ロール、サポート対象のワークスペース機能
- ローカル実行ポリシー： サポート対象のローカルクライアントに適用する承認、権限プロファイル、ファイルシステムとネットワークへのアクセス、その他の要件
- Codex Cloud： ホスト環境、リポジトリ接続、クラウド実行ポリシー
- 接続先システム： プロバイダー側でのアプリケーションのインストール、アカウント、権限
- レポートとコンプライアンス： 分析へのアクセス、監査データのエクスポート、エクスポート先でのデータの取り扱い
利用者層ごとに、ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能のどのローカル機能が必要か、Codex Cloud を利用するか、あるいは両方を組み合わせるかを決めます。API キー認証を使うワークフローでは、Platform API へのアクセスを、組織とプロジェクト単位で別途管理します。
ステップ 2：ワークスペースへのアクセスと ID の設定
ChatGPT ワークスペースのメンバーシップ、シート、グループ、サポート対象の RBAC 権限を使って、対象者に必要なワークスペース機能へのアクセスを付与します。同じロールでどの環境も管理できるとは限りません。ローカルクライアントと Codex Cloud へのアクセスは、ワークスペースの最新ガイドでそれぞれ確認してください。組み込みの管理ロールを付与するのは、ワークスペースの管理を担当する人に限ります。
ワークスペースの管理項目やラベルは変更されることがあります。最新の手順は次の資料で確認してください。
想定した権限を持つメンバーで、サインインと各機能へのアクセスをテストします。ワークスペースへのアクセスを付与しても、接続先サービスのリポジトリやファイルへのアクセス権、操作の実行権限は付与されません。
Work Cloud からのローカルコンピューターアクセスの設定
Work または dot からローカルコンピューターにアクセスできるようにする場合は、導入前にエージェントセキュリティでポリシーを確認してください。ポリシーの移行と機能へのアクセスの有効化は別々の変更です。アクセスを有効にする際の確認手順では、ポリシーを作成する必要はありません。管理ポリシーが有効な場合、クラウドでのオーケストレーションにはサポート対象のグローバルポリシーが適用されます。接続したコンピューターには、ローカルの実行要件とデバイスの制御が適用されます。Work のクラウドコンテナと dot のクラウドコンピューターには、それぞれ固有の実行設定と要件があります。それぞれの設定手順と利用条件は、Work Cloud と dot からのローカルコンピューターアクセスを参照してください。
グローバル設定はポリシー API で管理します。ローカル設定と Codex Cloud 設定は、エージェントセキュリティの UI で管理します。既存のグローバル設定用 API ワークフローは移行後も利用できます。スクリプトと Terraform 連携をテストし、ポリシーの割り当てと適用順序が変わっていないことを確認してください。
同期を有効にする前に、次の点を確認してください。
-
ネットワークポリシー： 環境ごとに設定を上書きしている場合は、ネットワークポリシーの優先順位と実行時の制限が想定どおりに適用されるかをテストしてください。環境側で許可しても、グローバルポリシーの制限が引き続き適用される場合があります。
-
企業向けフック： 導入するワークフローがフックに依存する場合は、クラウドでのオーケストレーションで実行されるハンドラーを確認してください。アクセスを有効にする前に、運用で使用するイベントと、想定する障害発生時の動作をテストしてください。監査記録の対象範囲も別途確認してください。
-
データ要件。Work Cloud からのローカルコンピューターアクセスでは、厳密なゼロデータ保持は保証されません。データレジデンシーと推論レジデンシーは、対象となるコンテンツ、およびサポートされているワークロード、リージョン、構成にのみ適用されます。Enterprise Key Management（EKM）の対象は、利用条件を満たすワークスペースに保存された、サポート対象のコンテンツです。UAE の推論レジデンシーでは Work はサポートされません。いずれかのクラウドポリシーで
enforce_residencyが有効な場合、Work と dot の両方でローカルコンピューターへのアクセスを許可が無効になります。この保護措置によってワークスペースのレジデンシーが設定されることはなく、この措置だけで Work Cloud や dot が無効になることもありません。組織でゼロデータ保持（ZDR）が必須の場合は、この機能を有効にしないでください。
ワークスペースのオーナーは、対象のユーザーまたはグループの Work 権限を確認します。Work Cloud を有効にしてから、ローカルコンピューターへのアクセスを許可をオンにしてください。サポート対象のロールを割り当ててアクセスを付与します。ロールとワークスペースの権限を参照してください。
ステップ 3：ローカル実行要件の設定
ユーザーが ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能でサポート対象の処理をローカルで開始すると、ローカル実行要件によって実行時の動作が制限されます。クラウド、デバイス、システムのいずれかでサポートされている配布方法を使い、requirements.toml を配布します。このポリシーは、ChatGPT ワークスペースのロールやグループとは別に管理してください。
新規導入では、従来のサンドボックスモードの制限を前提とせず、サポート対象のローカルクライアントには権限プロファイルを使用します。以下は設定例です。
default_permissions = ":workspace"
[allowed_permission_profiles]
":read-only" = true
":workspace" = trueサポート対象のブラウザ機能とデスクトップ機能のすべてで「コンピューターの使用」を無効にするには、関連する公開機能キーをそれぞれ無効にします。
[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false正式なキーの一覧、配布時の動作、適用の優先順位、その他の設定例は、管理対象の構成および requirements.toml リファレンスを参照してください。
ステップ 4：リポジトリ設定の標準化
リポジトリ単位で設定すると、ユーザーごとに同じ設定を繰り返さずに、プロジェクトのデフォルト設定、ルール、スキルを共有できます。各機能のドキュメントで指定された場所に従って、設定を .codex または .agents にコミットしてください。
| 種類 | 参照先 | 用途 |
|---|---|---|
| 構成 | 設定の基本 | サポート対象のローカルクライアントに、リポジトリ単位のデフォルト設定を適用 |
| ルール | ルール | サンドボックス外での実行に承認が必要なコマンドを制御 |
| スキル | スキルの作成 | サポート対象のクライアントでリポジトリのワークフローを利用可能にする |
リポジトリ設定では、デフォルト設定と再利用可能なワークフローを提供できます。ワークスペース、モデル、Platform API、接続先システムへのアクセスは付与できません。
ステップ 5：Codex Cloud の設定
Codex Cloud は、ホスト環境と、接続されたソースコードリポジトリを使用します。
Enterprise ワークスペースでは、Codex Cloud はデフォルトでオフです。クラウドで Codex を使用の設定は、従来版の Codex Cloud から引き継がれます。クラウドをすでに有効にしていたワークスペースでは引き続き利用でき、無効にしていたワークスペースでは、管理者が有効にするまでオフのままです。利用可否は、引き続き提供状況とワークスペースの制限によって決まります。
管理領域ごとに次の手順を進めます。
- 対象の利用者にクラウドで Codex を使用する権限を付与します。ワークスペースで共有する環境の作成や編集を担当する人には、ワークスペース環境を管理する権限を別途付与します。ワークスペースのロールに関するガイドを参照してください。
- サポート対象のソースコード管理システムとの連携機能をインストールし、設定します。
- ソースコード管理システム側で、各利用者層がアクセスできるリポジトリを必要なものだけに限定します。
- それらのリポジトリについて、クラウド環境、シークレット、インターネットアクセス、クラウドで管理できる実行要件を設定します。
- 必要に応じて、コードレビューなどのホスト環境で実行するワークフローを設定します。
- 対象者を代表するメンバーでタスクへのアクセスをテストし、指定した管理者で環境の管理をテストします。それぞれのワークスペース、環境、リポジトリに対する権限を確認してください。
クラウド環境は、ローカルデバイスのポリシー、MDM 設定、ローカルネットワークへのアクセスを継承しません。クラウドで管理できる実行要件は、ユーザーのコンピューターに配布した要件とは別に確認してください。接続先へのアクセスについてはサービスへの接続を、ワークスペースの要件によるクラウド環境の制限についてはエージェントセキュリティを参照してください。
Codex Cloud には、接続先のソースコード管理システムが提供するリポジトリの権限と保護が適用されます。ワークスペースへのアクセス権があっても、これらの制御は回避できません。設定手順と実行時の動作については、クラウド環境を参照してください。
ステップ 6：プラグインと連携機能の設定
プラグインのインストール、同梱のスキル、コネクタを使う機能、コネクタが実行する操作、接続先システムでの認可は、それぞれ個別に検討します。コネクタを使う機能を無効にしても、プラグインや同梱のスキルがアンインストールされるとは限りません。
プラグインやスキルを導入対象に含める前に、次の手順を実施してください。
- 提供元、管理責任者、対象者、レビュー日を確認します。
- 同梱のスキル、コネクタ、MCP サーバー、フックを確認し、各機能に必要なデータと操作を把握します。
- 機密性のないデータを使い、必要最小限のアクセス権でテストします。
- 再レビューと利用終了の責任者を記録します。
プラグインは、Web 版、デスクトップ版、モバイル版の ChatGPT の Chat と Work、ChatGPT デスクトップアプリの Codex、Codex CLI のプラグインブラウザで利用できます。IDE 拡張機能では利用できません。ChatGPT と Codex は共通の公開プラグインディレクトリを使用します。そのうちメンバーがアクセスできるプラグインは、ワークスペースの設定で決まります。
管理の仕組み全体については、プラグインの管理とスキルの管理を参照してください。
ステップ 7：ガバナンスと可観測性の設定
確認したい内容に応じて、レポート機能を選びます。
- ChatGPT ワークスペースと Codex の分析データを画面上で確認するには、ワークスペース分析を使用します。
- Codex Analytics API を通じて集計レポートをプログラムから取得するには、Analytics API を使用します。
- 監査や調査用の記録を取得するには、Compliance API を使用します。
- プランによって Codex の利用が対象の ChatGPT ワークスペースクレジットを消費する場合は、ChatGPT の使用量上限と支出管理を使用します。
連携を構築する際は、認証が必要な API リファレンスで、最新のアクセス要件、スキーマ、フィールド、データ保持、リクエスト時の動作を確認してください。
システム連携に伴うアクセスとデータを次のように保護します。
- API キーなどの連携用の認証情報は、組織のシークレット管理システムに保存します。
- 連携先のシステムや保持データにアクセスできる人を、承認済みの利用者に限定します。
- Compliance API からエクスポートした記録は、その機密性と組織の保持ポリシーに従って保護します。収集と削除のワークフローが現行の API 仕様に沿って動作することもテストしてください。
ステップ 8：導入結果の検証と継続的な管理
試験導入に参加するユーザーに、Work で新しいタスクを開始し、別のデバイスでそのタスクを続けるよう依頼します。コンピューターを接続した状態で、許可される操作とブロックされる操作をそれぞれ試し、承認要件、ファイルシステムへのアクセス、ネットワーク制限を確認してください。次に、コンピューターの接続を切り、新しいターンを開始します。クラウドコンテナからローカルファイルにアクセスできないことと、コンテナ自体の実行要件が適用されることを確認してください。
実際に適用された設定と各テストの結果を記録します。制限が想定どおりに機能しない場合は、ユーザーがその制限を前提に利用を始める前に問題を解決してください。同期を無効にする際は、ドキュメントに記載された動作を確認し、その手順に従います。アクセス権の取り消し、タスクの中断、データの保持は、それぞれ別の操作として扱ってください。
対象の利用者や管理者を代表するアカウントで、該当するすべての管理領域を検証します。
- ChatGPT ワークスペースのメンバーシップ、シート、サポート対象のロール権限
- ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能の対象ローカル機能（サインインと実際に適用される実行要件を含む）
- Codex Cloud へのアクセス、環境設定、リポジトリの権限
- API キーを使用するワークフローに必要な Platform API の組織とプロジェクトへのアクセス
- プラグインのインストール、同梱のスキル、コネクタへのアクセス、サポート対象の操作
- 接続先システムでの認可とデータへのアクセス
- 担当管理者の分析機能とコンプライアンス機能へのアクセス
各管理項目の担当者と、最新手順の参照先を記録してください。こうしておくと、UI やポリシーが変わっても、管理体制を維持したまま手順を更新できます。
初回導入後は、アクセス状況、連携機能、クレジットの使用量、サポートに寄せられた意見、各チームが実際に利用しているワークフローを確認します。状況の変化に応じて、導入範囲と管理者向けの手順を見直してください。
Work Cloud からのローカルコンピューターアクセスの無効化
ローカルコンピューターへのアクセスを許可をオフにすると実行中のターンが中断されることを、影響を受けるユーザーに伝えてください。引き続き Work へのアクセス権を持つメンバーは、既存のクラウド上の会話に新しいメッセージを送ると、ローカルファイルを使わずに会話を続けられます。