管理者向けロールアウトガイド

このガイドを使用して、次の管理境界にわたる ChatGPT Enterprise のロールアウトを計画します。

ワークスペースへのアクセス。
ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能で対象となる機能のローカルランタイムポリシー。
Codex cloud。
Platform API へのアクセス。
プラグインおよびコネクターへのアクセス。
接続先システムでの権限。

新規ロールアウトでは手順を順番に完了してください。1 つの境界だけを変更する場合は、リンク先のページを使用してください。

ローカルの Codex クライアント用のモデルゲートウェイを管理している場合は、ゲートウェイ経由で Codex を導入するを参照して、ゲートウェイの適合性確認、認証情報の配布、クライアントの引き継ぎを行ってください。導入環境でワークスペース機能を使用する場合は、ワークスペースへのアクセスを別途設定してください。

ワークスペース設定では、Codex and Work Local により、ローカルの Codex と Work へのアクセスが Allow members to use Codex and Work Locally にまとめられています。一部のワークスペースでは、代わりに独立した Codex Local セクションと Work Local セクションが用意されています。このレイアウトでは、Allow members to use Codex locally が Codex を制御し、Use Work locally が Work を制御します。一方を有効にしても、もう一方は有効になりません。これらのラベルはワークスペースの権限を示すものであり、別個の製品やクライアントを示すものではありません。トークンの権限と認証情報の有効期間の上限は、ワークスペースに応じて Access tokens セクションまたはローカルアクセスのセクションに表示されます。管理対象の構成は独立したポリシーレイヤーであり、これらのクライアントで対象となる機能について、サポートされるランタイムの動作を制約できます。このガイドでは、動作や提供状況が異なる場合、個々の画面領域の名称を明記します。

アクセス制御の概要については、ロールとワークスペースの権限を参照してください。 ChatGPT ワークスペースの最新の操作手順についてはヘルプセンターのガイダンスを、ローカルおよびホスト環境のランタイムの動作についてはリンク先の開発者向けドキュメントを参照してください。

エンタープライズ向けのセキュリティ、プライバシー、ランタイム保護については、エージェントの承認とセキュリティおよび Codex セキュリティホワイトペーパーを参照してください。

ステップ 1：担当者を割り当て、ロールアウト方法を選択する

ロールアウトの各部分に担当者を割り当てます。

ワークスペースへのアクセス： メンバーシップ、シート、ロール、サポート対象のワークスペース機能。
ローカルランタイムポリシー： 承認、権限プロファイル、ファイルシステムとネットワークへのアクセス、およびサポート対象のローカルクライアントに関するその他の要件。
Codex cloud： ホステッド環境、リポジトリ接続、クラウドランタイムポリシー。
接続先システム： プロバイダー側でのアプリケーションのインストール、アカウント、権限。
レポートとコンプライアンス： アナリティクスへのアクセス、監査データのエクスポート、後続システムでのデータ処理。

対象者ごとに、ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能、 Codex cloud のいずれで対象のローカル機能が必要か、またはそれらを組み合わせるかを決定します。ワークフローで API-key 認証を使用する場合、Platform API へのアクセスは、組織およびプロジェクトの独立した境界として扱ってください。

ステップ 2：ワークスペースへのアクセスと ID を設定する

ChatGPT ワークスペースのメンバーシップ、シート、グループ、サポート対象の RBAC 権限を使用して、対象者にサポート対象のワークスペース機能を付与します。同じロールがすべてのサーフェスを制御すると想定せず、現在のワークスペースガイダンスに照らして、ローカルクライアントと Codex cloud へのアクセスを確認してください。組み込みの管理ロールは、ワークスペースを管理する担当者だけに限定してください。

ワークスペースのコントロールとラベルは時間の経過とともに変わります。現在の手順については、次の情報源を参照してください。

想定した権限を持つメンバーで、サインインと機能へのアクセスをテストしてください。ワークスペースへのアクセス権を付与しても、接続先サービスのリポジトリ、ファイル、アクションへのアクセス権は付与されません。

Work Cloud によるローカルコンピューターアクセスを設定する

Work または dots のローカルコンピューターアクセスを導入する場合は、導入前に Agent Security でポリシーを確認してください。ポリシーの移行と機能へのアクセスは別々の変更です。確認フローでは、アクセスを有効にするためにポリシーを作成する必要はありません。管理対象のポリシーが有効な場合、サポートされる Global ポリシーがクラウドのオーケストレーションを管理します。接続されたコンピューターには、ローカル実行の要件とデバイス制御が適用されます。Work のクラウドコンテナーと dots のクラウドコンピューターには、それぞれ独自の実行構成と要件が適用されます。個別の設定手順と利用条件については、Work Cloud と dots のローカルコンピューターアクセスに従ってください。

Global 設定の管理にはポリシー API を使用します。Local または Codex Cloud の設定を管理するには、Agent Security UI を使用します。既存の Global API ワークフローは、移行後も引き続き利用できます。スクリプトと Terraform 連携をテストし、ポリシーの割り当てと順序が変わっていないことを確認してください。

同期を有効にする前に、互換性を確認してください。

ネットワークポリシー。環境ごとのオーバーライドが利用できる場合は、管理対象の構成に記載されている experimental_network の例外をテストしてください。環境で許可されていても、グローバルな制限が引き続き適用される場合があります。

エンタープライズ向けフック。 ワークスペースで有効になっている場合、Work Cloud のローカルコンピューターアクセスでは、サポート対象のライフサイクルイベントとツールイベントに対して、クラウドコーディネーター（オーケストレーター）上で実行される管理者定義の MCP フックを利用できます。クラウドオーケストレーションでは、ツールがローカルで実行される場合でも、コマンドフックやローカル構成またはプラグイン由来のフックはサポートされません。
サポートされないフック。 クラウドオーケストレーションでは、ツールがローカルで実行される場合でも、コマンドフックやローカル構成またはプラグイン由来のフックはサポートされません。オーケストレーションと実行の両方がローカルで行われる場合、既存のサポート対象フックは、ローカル専用の Work および Codex スレッドで引き続き動作します。管理者は、これらのワークフローに対して、サポート対象の管理対象フックを引き続き Agent Security で構成できます。
監査。 これらのフックを運用に使用する前に、コールバック接続をテストし、受信するイベントを確認したうえで、障害がタスクに及ぼす影響を確認してください。MCP フックは、Compliance API の完全な監査証跡を提供するものではありません。
データ要件。Work Cloud のローカルコンピューターアクセスは、厳密なゼロデータ保持を提供しません。データレジデンシーと推論レジデンシーの対象は、適格なコンテンツと、サポート対象のワークロード、リージョン、構成に限られます。Enterprise Key Management（EKM）は、適格なワークスペースに保存されたサポート対象のコンテンツに適用されます。Work は UAE の推論レジデンシーではサポートされません。いずれかのクラウドポリシーで enforce_residency が有効になっている場合、Work と dots の両方で ローカルコンピューターアクセスを許可 が無効になります。この保護措置は、ワークスペースのレジデンシーを構成するものではなく、それ自体で Work Cloud や dots を無効にするものでもありません。組織で ZDR が必要な場合は、この機能を有効にしないでください。

ワークスペースのオーナーは、対象のユーザーまたはグループの Work 権限を確認してください。Work Cloud を有効にしてから、ローカルコンピューターアクセスを許可 をオンにします。サポート対象のロール割り当てを使用してアクセス権を付与します。ロールとワークスペース権限を参照してください。

ステップ 3：ローカルランタイム要件を設定する

ローカル要件は、ユーザーが ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能でサポート対象のローカル実行を開始した際のランタイム動作を制限します。サポートされるクラウド、デバイス、またはシステムのチャネルを通じて requirements.toml を配布してください。このポリシーは、ChatGPT ワークスペースのロールおよびグループとは分けて管理します。

レガシーなサンドボックスモードの制限を前提として新しいデプロイを構築するのではなく、サポート対象のローカルクライアントでは権限プロファイルを使用してください。例：

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

サポート対象のブラウザおよびデスクトップ機能の各サーフェスで Computer Use を無効にするには、このエクスペリエンスに関与するすべての公開機能キーを制限します。

[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 (Legacy) から引き継がれます。すでに Cloud を有効にしているワークスペースはアクセス権を維持し、Cloud が無効のワークスペースは管理者が有効にするまでオフのままです。アクセスには引き続き、ロールアウト状況とワークスペースの制限が適用されます。

各境界について計画してください。

対象ユーザーに クラウドで Codex を使用 権限を付与します。それとは別に、ワークスペース共有環境を作成および編集する担当者に ワークスペース環境を管理 権限を付与します。詳細は、ワークスペースのロールに関するガイダンスを参照してください。
サポート対象のソースシステム連携をインストールして構成します。
ソースシステムでのリポジトリアクセスを、各対象ユーザーに必要なリポジトリに限定します。
それらのリポジトリに対して、クラウド環境、シークレット、インターネットアクセス、およびサポート対象のクラウド管理要件を構成します。
コードレビューなど、任意のホスト型ワークフローを構成します。
代表的なメンバーでタスクへのアクセスを、指定した管理者で環境管理をテストします。各ユーザーのワークスペース、環境、リポジトリの権限を確認してください。

クラウド環境は、ローカルデバイスのポリシー、MDM 設定、ローカルのネットワークアクセスを引き継ぎません。サポート対象のクラウド管理要件は、ユーザーのコンピューターにインストールされた要件とは別に確認してください。接続先へのアクセスについてはサービスへの接続を、ワークスペースの要件によるクラウド環境の制約については Agent Securityを参照してください。

Codex cloud は、接続されたソースシステムが提供するリポジトリ権限と保護機能に従います。ワークスペースへのアクセス権があっても、これらの制御を回避することはできません。セットアップと実行時のガイダンスについては、クラウド環境を参照してください。

ステップ 6：プラグインと接続機能を設定する

プラグインのインストール、同梱スキル、コネクターを利用する機能、コネクターのアクション、ソースシステムの認可は、それぞれ別の判断事項として確認してください。コネクターを利用する機能を無効にしても、プラグインや同梱スキルが必ずしもアンインストールされるわけではありません。

プラグインまたはスキルをロールアウトに含める前に、次を行います。

提供元、責任者、対象者、レビュー日を確認します。
同梱スキル、コネクター、MCP servers、フック、および各機能に必要なデータとアクションを確認します。
機密性のないデータと必要最小限のアクセス権でテストします。
再レビューと廃止の担当者を記録します。

プラグインは、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 keys およびその他の連携用認証情報は、組織のシークレット管理システムに保存します。
後続システムおよび保持データへのアクセスを、承認された対象者に限定します。
エクスポートした Compliance API の記録を、その機密性と組織の保持ポリシーに従って保護し、現在の仕様に照らして収集および削除のワークフローをテストします。

ステップ 8：ロールアウトを検証し、維持する

Work Cloud のローカルコンピューターアクセスを有効にしたら、新しいタスクを作成し、別のサポート対象デバイスから会話を続けてください。既存のタスクは移行されず、元のローカル専用またはクラウド専用の動作を維持します。コンピューター上のファイルやツールが必要なステップでは、そのコンピューターをオンラインにしておいてください。ポリシーで許可されるべき操作とブロックされるべき操作をテストし、適用される承認、ファイルシステム制限、ネットワーク制限を、ローカル実行とクラウド実行でそれぞれ確認します。また、ローカルコンピューターが利用できない状態で新しいターンを開始するテストも行ってください。適格なタスクは、そのコンピューターのローカルファイルやツールにアクセスせずに、クラウドコンテナーで続行できます。ターンの途中で、タスクをローカル実行からクラウドに切り替えることはできません。

実際に適用されている設定と各テストの結果を記録してください。制限が想定どおりに機能しない場合は、ユーザーがその制限を前提に利用を始める前に問題を解決してください。同期の無効化については、ドキュメントに記載された動作に従ってください。アクセス権の削除、タスクの中断、データ保持は、それぞれ別の操作として扱ってください。

該当するすべての境界を、代表的な ID で検証します。

ChatGPT ワークスペースのメンバーシップ、シート、サポート対象ロールの権限。
ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能で対象となるローカル機能（サインインおよび実際に適用されるランタイム要件を含む）。
Codex cloud へのアクセス、環境設定、リポジトリ権限。
API-key ワークフロー用の Platform API 組織およびプロジェクトへのアクセス。
プラグインのインストール、同梱スキル、コネクターへのアクセス、サポート対象のアクション。
接続先システムの認可とデータアクセス。
担当管理者のアナリティクスおよびコンプライアンスへのアクセス。

各コントロールの担当者と、現在の手順を示す情報源を記録します。この記録により、 UI やポリシーが変更された場合でも、管理モデルを変更せずに管理者が手順を更新できます。

初回ロールアウト後は、アクセス、接続機能、クレジット使用量、サポートからのフィードバック、チームが実際に使用しているワークフローを確認します。それらの状況が変化したら、ロールアウト範囲と管理者向けガイダンスを調整してください。

Work Cloud のローカルコンピューターアクセスをオフにする必要がある場合

Work Cloud のローカルコンピューターアクセスをオフにすると、実行中のターンが中断されます。ユーザーは、既存のクラウド上の会話で新しいターンを開始できます。そのターンでは、ローカルファイルへのアクセスなしで Work Cloud が自動的に使用されます。中断後は新しいターンを開始するようユーザーに案内し、クラウドスレッドからローカルファイルを利用できなくなることを説明してください。

最近の検索

おすすめの検索

ドキュメントナビゲーション